關于數據倉庫的架構及3大類組件工具選型

1 評論 10721 瀏覽 44 收藏 16 分鐘

編輯導語:數據分析的前期工作一定要確保無誤,才能保證后期在進行數據運用和構建時不出錯。當你拿到一個數據分析的任務時,你可以先到數據倉庫進行獲取。本文作者介紹了企業數據倉庫項目上的架構和組件工具管理問題,我們一起來看一下。

關于數據倉庫的概念、原理、建設方法論,網上已經有很多內容了,也有很多的經典書籍,本文更想聊聊企業數據倉庫項目上的架構和組件工具問題。

先來談談架構。

01 企業數據倉庫架構

關于數據倉庫,有一種簡單粗暴的說法,就是“任何數據倉庫都是通過數據集成工具連接一端的原始數據和另一端的分析界面的數據庫”。

數據倉庫用來管理企業龐大的數據集,提供轉換數據、移動數據并將其呈現給終端用戶的存儲機制。許多架構方法以這樣或那樣的方式擴展數據倉庫的能力,我們講集中討論最本質的問題,在不考慮過多技術細節的情況下,整個層次架構可以被劃分為4層:

  • 原始數據層(數據源)
  • 數據倉庫架構形態
  • 數據的采集、收集、清洗和轉換
  • 應用分析層

1. 單層架構(直連)

大多數情況下,數據倉庫是一個關系型數據庫,包含了允許多維數據的模塊,或者分為多個易于訪問的多主題信息域,最簡單的數據倉庫只有一層架構。

單層架構就以為著數據倉庫與分析接口直接連接(直連),終端用戶可以直接查詢。但簡單有其弊端和適用性:

傳統上數據倉庫的存儲從 100GB 起,直連可能會導致數據查詢處理速度慢,因為要直接從數據倉庫查詢準確的數據,或者是準確的輸入,過程中要過濾掉很多非必要數據,這對數據庫以及前端BI工具的性能要求相當高,基本性能不會太高。

另外,在處理復雜維度分析時性能也受限,由于其緩慢性和不可預測性,很少應用在大型數據平臺。要執行高級數據查詢,數據倉庫應該在低級實例下被擴展從而簡化數據查詢。

2. 兩層數據架構(數據集市層)

兩層架構就是在前端應用層和 EDW 層增加了數據集市層。數據集市是包含特定主題域信息的低級別存儲庫。簡而言之,它是一個在特定主題(例如銷售、運營、市場等)下延伸了 EDW 的較小數據庫。

這種方式解決了部門級數據查詢和分析的問題,每個部門都更容易訪問到所需數據,因為每個集市僅包含給定域信息,另外,數據集市限制了終端用戶對數據的訪問范圍,設置了一道數據權限。但是創建數據集市層需要額外的硬件資源,并集成它與數據平臺其他的數據庫。

3. 三層架構(OLAP)

在數據集市層之上,我們通常會使用聯機分析(OLAP)處理多維數據集(cube)。OLAP 數據集是一類從多維度描述數據的特定數據庫。關系型數據庫只能表示二維數據,而 OLAP 允許在多維度下編譯數據并且在維度之間移動。

OLAP專用于維度建模數據的分析,然后通過BI將OLAP的結果以圖表的方式展現出來。

OLAP 的業務價值在于允許對數據進行切片、切片以多維度分析,以提供對所有企業數據或特定數據集市的訪問,現在基本已成為主流的架構應用。

以下這張架構圖使用最廣泛的體系結構,它由頂層、中層和底層組成。

  • 底層:數據倉庫服務器的數據庫作為底層,通常是一個關系數據庫系統,使用后端工具將數據清理、轉換并加載到該層。
  • 中間層:數據倉庫中的中間層是使用ROLAP或MOLAP模型實現的OLAP服務器。對于用戶,此應用程序層顯示數據庫的抽象視圖,這一層還充當最終用戶和數據庫之間的中介。
  • 頂層:頂層是前端應用層,連接數據倉庫并從數據倉庫獲取數據或者API,通常的應用包括數據查詢、報表制作、BI數據分析、數據挖掘還有一些其他的應用開發。

從功能應用和技術架構來展開,以下是一張中大型企業的很詳細的數據倉庫架構圖了。

數據倉庫的4層核心組件:底層源數據庫(數據存儲方案)、ETL、前端應用、還有OLAP服務。

02 數據倉庫數據庫

底層的數據倉庫服務器通常是一個關系數據庫系統(各種表關聯的sql統計會更方便一些,非關系型數據庫目前在這方面還是有所區別)。常用的方案有Oracle、db2、sqlserve 還有essbase、greenplum、teredata等數據倉庫專業解決方案。

1. 采用傳統關系型數據庫,或經過功能擴展的MPP數據庫

① 傳統的關系型數據庫有:oracle、mysql、DB2

② 大規模并行處理數據庫:Vertica、Teradata(商業)、Greenplum (開源)

Teradata老江湖了,銀行業使用較多,但成本也是真的貴,目前我們做項目較多的是用Greenplum,算是業界最快和最高性價比的高端數據倉庫解決方案,Greenplum是基于PostgreSQL的,于2015年開源。我知道的國內四大行有3家在用,5大物流公司有4家在用,不少公司在從Teradata 遷移到 GP。

2. 大數據平臺架構:Hadoop+Hive

這套方案有多通用不用多說了,通常是這樣的組合:TB級數據用PG,百TB級數據用GP,PB級i上數據用Hadoop。

下面整理了一張傳統數據倉庫架構、GP還有Hadoop大數據平臺的對比圖。

03 采集、收集、清洗和轉換工具(ETL)

數據來源、轉換和遷移工具用于執行將數據轉換為數據倉庫中的統一格式所需的所有轉換、摘要和所有更改,它們也稱為提取、轉換和加載工具。其功能包括:

1. 抽取

  • 全量抽?。哼m用于數據量小且不容易判斷其數據發生改變的諸如關系表,維度表,配置表等
  • 增量抽?。哼m用于數據量大,為了節省抽取時間而采用的抽取策略

2. 清洗

  • 空值處理:將空值替換為特定值或直接過濾掉
  • 驗證數據正確性:把不符合業務含義的數據做統一處理
  • 規范數據格式:比如把所有日期都規范成YYYY-MM-DD的格式
  • 數據轉碼:把一個源數據中用編碼表示的字段通過關聯編碼表轉換成代表其真實意義的值
  • 數據標準統一:比如在源數據中表示男女的方式有很多種,在抽取的時候直接根據模型中定義的值做轉化。

3. 轉化和加載

  • 轉換:用ODS中的增量或者全量數據來刷新DW中的表
  • 加載:每insert數據到一張表都可以稱為數據加載

關于ETL工具的選型,這里羅列了一張對比表,基本囊括常用的ETL工具。

04 前端應用工具

數據倉庫平臺的搭建,最終是為了梳理出有用數據、提供有價值信息,幫助業務做出正確決策。

前端應用工具主要就是和數據倉庫不同環節的數據交互,這些應用一般可以分為4類:

  • 數據查詢和報表工具
  • BI即席分析工具
  • 數據挖掘工具
  • 各種基于數據倉庫或數據集市的應用開發工具

其中數據分析工具主要針對OLAP服務器,報表工具、數據挖掘工具主要針對數據倉庫。

1. 數據查詢和報表工具

通常用來生成一些固定類報表,自動化報表,支持打印和計算等大批量批處理作業。

流行的報表工具,在舊數據倉庫時代主要是IBM的BO、Oracle的BIEE、還有微軟和cognos,整體打包在數據倉庫解決方案里,報表作為一個組件存在。但是隨著傳統型數倉,架構重成本貴,很多公司在項目上會自己考慮設計架構,而不是直接強套昂貴的解決方案,包括很多開源組件/平臺的使用。

有關報表工具,現在項目上用的比較多的是帆軟FineReport,針對不同企業數倉架構以及報表需求的適用性較廣。比如對接各種數據庫直接生成報表;對采集整理后的數據進行多維報表展現,支撐業務分析報表;對接集團性數據倉庫,構建數據中心平臺,形成決策分析平臺。

2. BI即席分析工具

BI一般都集成了OLAP服務器和報表展示功能。分析型BI基于多維數據庫的概念,能多維視角分析數據,通常是從數據倉庫中抽取詳細數據的一個子集并經過必要的聚集存儲到OLAP存儲器中供前端BI分析工具讀取。

BI在前端通過拖拽數據字段,多維度實施展現數據,最終生成各種分析報告。常用的BI工具有PowerBI、Tableau、FineBI,還有開源的superset。個人使用多用前兩者,企業項目上選型多用FineBI,因為要考慮性能、服務方案等。剩余就是自研或者開源,superset算是比較公認的開源BI。

BI工具做什么的不多說了,在項目選型的時候主要考慮上手難度(考慮沒技術基礎的業務用),數據處理性能,其他就是技術選型的事,還有成本。

3. 數據挖掘工具

OLAP是將數據多維視角呈現分析,數據挖掘則是應用的算法來揭示數據的規律性,比如相關性、模式和趨勢等。數據挖掘工具就是做這個的,它能讓一些算法和過程自動化。

舉個例子,比如銀行里數據倉庫以面向“客戶”為主題進行數據的存儲,OLAP可以實現數據按照客戶的基本信息、儲蓄賬戶信息、歷史余額信息、銀行交易日志等,以報表或者可視化的方式呈現分析,多方面掌握客戶動態,發現數據的問題,更好的針對不同類型用戶進行特定性營銷。而數據挖掘則是通過歷史數據建立模型,在擬合歷史的基礎上,分析未來趨勢,判斷哪些因素的改變將很可能意味著客戶的最終流失,進而避免其發生。

常用的數據挖掘工具,R、Python還有SPSS,基本都是開源個人可用的。和BI和報表不同,市面上少有為客戶提供定制化數據分析和挖掘的商業工具或者項目服務,因為行業性太強,需要非常熟悉業務、數據、平臺,所以我見過基本都是自己養數據分析團隊或者挖這類的人才。

4. 應用開發

以上報表型、分析型的數據產品,但也會有延申出來的各種特定業務的數據決策系統,比如銀行業基于管理層監控的的行長駕駛艙、零售業基于門店數據經營的決策系統,以及電商平臺的營銷參謀(輸入營銷目標及參數,比如要開展雙十一母嬰市場的促銷活動,系統可以基于以往海量數據計算出應該選擇什么品類的商品,在什么用戶群中,以什么形式開展活動效果會更佳),都是基于這樣的邏輯——基于業務深度應用。此時數倉就是提供一個服務平臺的角色,比如現在很火的數據中臺也大體是這個邏輯,將數據服務化,具體不懂就不班門弄斧了。

這樣的服務,當然需要自己開發。

在這三層之間其實還有中間層OLAP服務器,典型實現為ROLAP模型或MOLAP模型?,F在很多成熟的BI工具都是集成了OLAP服務器的,所以通常我們只需要選擇ETL工具以及存儲方案和可視化BI方案即可,所以OLAP本文也就不多講了。

 

作者:商業智能研究,專注企業數據化運營和數字化轉型,公眾號:商業智能研究,分享有關企業數據建設的一切知識!

本文由 @商業智能研究 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 這文章稍微有點老了,現在一般不用關系型數據庫搞數倉了,前沿已經在討論數據湖 來替代傳統hadoop數倉的弊端了

    來自上海 回復