10分鐘帶你了解數據庫、數據倉庫、數據湖、數據中臺的區別與聯系(一)

3 評論 19605 瀏覽 93 收藏 16 分鐘

編輯導語:作為一名數據小白,在日常學習和工作中經常會接觸到數據。隨著用戶數據與業務數據的不斷累加,數據管理與處理愈發重要。本篇文章中,作者將一文說明數據庫、數據倉庫、數據湖、數據中臺的區別與聯系。

作為數據相關的產品小白,在日常學習工作中經常能看到或者聽到大家在討論數據庫,數據倉庫,數據集市,數據湖還有最近比較火的數據中臺,似乎這些名詞都與數據存在著聯系,查看各類相關書籍,大部分書籍中的內容過于專業晦澀難懂。

那么這篇文章結合我積累的相關方面知識,向大家介紹一下上述這些名詞的區別與聯系,以及在各類企業及業務上的適用范圍,如有不準確的地方,希望大家進行指正。

一、何為數據庫

相信大部分有些許技術背景的同學們都對數據庫有一定的了解,數據庫是“按照數據結構來組織、存儲和管理數據的倉庫”,一般分為“關系型數據庫”與“非關系型數據庫”。

1. 關系型數據庫

實際上過去的數據庫一共有三種模型,即層次模型,網狀模型,關系模型。

(1)首先層次模型的數據結構為樹狀結構,即是一種上下級的層級關系組織數據的一種方式:

(2)網狀模型的數據結構為網狀結構,即將每個數據節點與其他很多節點都連接起來:

(3)關系模型的數據結構可以看做是一個二維表格,任何數據都可以通過行號與列號來唯一確定:

由于相比于層次模型和網狀模型,關系模型理解和使用最簡單,最終基于關系型數據庫在各行各業應用了起來。

關系模型的數學原理涉及到關系,元組,屬性,笛卡爾積,域等等令人頭禿的數學術語,這里大家如果感興趣可以看看相關的文獻,我就不放出來催眠大家了,盡管數學原理非常復雜,但如果用日常學習工作的具體事務舉例,就相對容易理解。

我們以某公司的員工信息表為例,該公司的員工信息可以用一個表格存起來。并且定義如下:

同時部門ID對應這另一個部門表:

我們可以通過給定一個部門名稱,查到一條部門的記錄,根據部門ID,又可以查到該部門下的員工記錄,這樣二維的表格就通過ID映射建立了“一對多”的關系。

常用的關系型數據庫有Oracle,Microsoft SQL Sever,MySQL,DB2。數據庫的語言基本上圍繞著“增刪改查”來進行的,語法相對簡單,大家有興趣可以下載MySQL自學,網上有很多免費的資料。

2. 非關系型數據庫

非關系型數據庫是以對象為單位的數據結構,非關系型數據庫通常指數據以對象的形式存儲在數據庫中,而對象之間的關系通過每個對象自身的屬性來決定。

簡單來說非關系型數據庫與傳統的關系型數據庫的區別在于非關系型數據庫主要存儲沒有固定格式的超大規模數據,例如鍵值對型,文檔型,列存儲類數據,常見的非關系型數據庫有Hbase,Redis,MongoDB,Neo4j等?,F在我們通常所說的數據庫指的是關系型數據庫,非關系型數據庫大家了解即可。

二、數據庫→數據倉庫

1. 例子

隨著企業的發展,線上的業務系統隨著業務進行會源源不斷的產生數據,一般這些數據會存儲在我們企業的業務數據庫中,也就是上面講到的關系型數據庫,當然不同的企業使用的數據庫可能不盡相同例如上述的Oracle,Microsoft SQL Sever,MySQL等,但是底層的技術邏輯都大同小異,這些業務數據庫支撐著我們業務系統的正常運行。

但是當我們線上的業務系統運行超過一定時間后,內部積壓的數據會越來越多,對我們的業務數據庫會產生一定的負載,導致我們業務系統的運行速度較慢,這些數據中有很大一部分是冷數據,因為業務系統一般對我們近期的一些數據比如當天或一周內這些數據調用比較頻繁,對比較早的數據調用的頻率就會很低。

同時呢目前由于數據驅動業務概念的興起,各業務部門需要將業務系統的業務數據提取出來進行分析以便更好地進行輔助決策,但各部門需求的數據種類千差萬別,接口錯綜復雜,過多的數據查詢腳本以及接口的接入導致業務數據庫的穩定性降低。

為了避免冷數據與歷史數據收集對我們業務數據庫產生的影響,妨礙我們業務的正常運行,企業需要定期將我們冷數據從業務數據庫中轉移出來存儲到一個專門存放歷史數據的倉庫里面,各部門可以根據自身業務需要進行數據抽取,這個倉庫就是數據倉庫。

2. 數據倉庫的特性

結合上述例子,我們得出數據倉庫的以下特性:

  • 解耦:數據倉庫的誕生,本質是將數據的收集與分析進行解耦。
  • 整合:數據倉庫起到了對不同平臺,不同來源的數據的集成整合作用,通過抽取,清洗,轉換生成由面向事務轉化為面向主體的數據集合。
  • 穩定:數據倉庫的數據主要為決策者分析提供數據,一般僅允許查詢,不允許修改刪除,數據倉庫的數據僅定期需要由業務數據庫轉移,加載,刷新。
  • 歷史滯后:數據倉庫的數據會定期更新,每隔固定的時間間隔后,抽取業務數據庫系統中產生的數據通過數據的轉換集成,進入到數據倉庫中,所以數據倉庫的數據產出具有T+1的特性(離線數據倉庫)。

3. 數據庫VS數據倉庫

再深入一些,我們此時要引入兩個新的名詞OLTP(On-Line Transaction Processing)聯機事務處理與OLAP(On-Line Analytical Processing)聯機分析處理,乍聽兩個名詞感覺很高大上,我們此時要關注兩個單詞的區別,“Transaction”為事務,業務。

所以業務數據庫也就是我們之前講的關系型數據庫屬于OLTP類型,該類型側重于基本的,日常的事務處理,是業務系統的“壓艙石”,維持正常運行,而“Analytical”則為分析,數據倉庫就屬于OLAP類型,該類型側重于復雜的分析,查詢操作,是業務系統的“船帆”,提供決策支撐。

三、數據倉庫

相信通過上述的案例,我們對數據倉庫有了大致的認識,一個簡單的數據倉庫結構如下圖所示,那么接下來我們講講數據倉庫的相關知識點:

1. ETL(extraction-transformation-load)抽取-轉換-加載

(1)extraction(抽?。?/strong>

不是所有出現在業務數據庫中的數據都需要抽取,抽取需要在調研階段做大量的工作,首先要搞清楚數據是從幾個業務系統中來,各個業務系統的數據庫服務器運行什么,是否存在手工數據且手工數據量有多大,是否存在非結構化的數據,某些數據對于分析沒有任何價值,這類數據是否需要剔除,當收集完這些信息之后才可以進行數據抽取的設計。

(2)Transformer(轉換)

也就是數據的清洗,數據倉庫分為兩部分,ODS(操作數據存儲)及DS(數據倉庫),通常的做法是從業務系統到ODS做清洗,將臟數據與不完整數據過濾掉,在從ODS到OW的過程中轉換,進行一些業務規則的計算,聚合及數據轉換。

a. 數據清洗:業務系統→ODS的過程,過濾那些不符合要求的數據,將過濾的結果交給業務主管部門,確認是否過濾掉還是由業務單位修正之后再進行抽取。

b. 數據轉換:ODS→DS的過程,主要進行不同維度的數據轉換、數據顆粒度的轉換,以及一些業務規則的計算。

  • 不同維度數據轉換:將不同業務系統的相同類型的數據進行統一,例如編碼轉化:不同供應商在不同業務系統的編碼不同;字段轉換;度量單位的轉換等。
  • 數據顆粒度的轉換:業務系統存儲著顆粒度較細的數據,而數據倉庫的數據時用來分析的,不需要顆粒度很細的數據,所以會將業務系統數據按照數據倉庫的顆粒度進行轉換。
  • 業務規則的計算:企業有不同的數據指標以及業務規則,此時需要將這些數據指標計算好后存儲在數據倉庫中,供數據分析使用。

(3)Load(加載)

將清洗及轉換過的數據加載到數據倉庫,一般分為全量加載及增量加載。

  • 全量加載:一次性對所有數據進行加載。
  • 增量加載:首次進行全量加載,但是后面再繼續全量加載的話,會浪費極大的物理資源與時間成本。所以只考慮對新修改的記錄和新插入的記錄進行加載。

小結:ETL是數據倉庫開發中最耗資源的一環,因此該環節要整理各業務系統中雜亂無章的數據,工作量很大,但也是搭建數據倉庫的最重要的環節。

2. ODS 操作數據存儲

ODS(Operation Data Store)操作數據存儲在業務數據庫與數據倉庫之間形成一個隔離,其存在可以避免數據倉庫直接調用業務數據庫的數據,保持數據在結構上與業務數據庫一致,起到提高業務數據庫穩定性,降低數據抽取復雜性的作用。

鑒于ODS上述特點,數據會按照特定時間源源不斷地寫入ODS中,且一經寫入的數據不能被刪除,修改。所以為了提高ODS的運行效率,一般ODS會考慮使用分布式文件存儲系統。

3. DM數據集市

DM(Data Market)數據集市是以某個業務應用為出發點而建設的局部的數據倉庫,所以DM數據集市的特點在于結構清晰,針對性強且擴展性良好,由于僅僅對某一個領域建立,容易維護修改。

數據集市分為獨立數據集市與非獨立數據集市,其中獨立數據集市有獨有的源數據庫與ETL架構。而非獨立數據集市則沒有自己的源數據,全部數據位于數據倉庫,開發人員通過權限的設置,為用戶提供面向其業務的數據,該數據為數據倉庫的子集。

四、數據倉庫VS數據湖

對于管理企業的人員一般來說有兩種特征,開放性與有序性,創業公司的人思想往往比較開放,但管理大型公司的人更注重秩序,同理這個概念可以使用在如今的數據結構中,開放意味著容易接受新信息以及接納新的觀點,創業公司擁抱開放的原因他們必須學會打破常規,在市場中創造新的價值。

有序則指的是采取已證明是成功的模式,這通常意味著排除那些不太可能成功的想法和信息。

1. 開放性→數據湖

開放性的特征直接指向數據湖的概念,數據湖是新數據可以不受任何限制地進入的地方,在這里,任何數據都可以存在,因此這里是發現新想法,用數據實驗絕妙來源,但同時因為其對任何數據的開放性,使得其缺乏有意義的結構,對于數據量較大時,就顯得有些混亂了。

2. 有序性→數據倉庫

有序性直接指向數據倉庫,在數據倉庫中,我們將維度和指標視為可查詢的,這是可以統一管理,且更容易被不斷擴大的受眾消費。

五、后續

由于篇幅所限,本篇文章為《10分鐘帶你了解數據庫、數據倉庫、數據湖、數據中臺的區別與聯系》的第一部分,第二部分會為大家介紹湖倉一體,數據中臺的相關知識以及數據庫、數據倉庫、數據湖與數據中臺在各類企業及業務上的適用范圍。

 

本文由 @快樂的給予 原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 厲害,等待第二部門

    回復
  2. 期待第二部分~~

    來自廣東 回復
  3. 辛苦

    回復