淺談數據倉庫的基本架構

本文轉載自查看原文 2018-04-12 10:26 1154 大數據技術

數據倉庫的目的是構建面向分析的集成化數據環境，為企業提供決策支持（Decision Support）。其實數據倉庫本身並不“生產”任何數據，同時自身也不需要“消費”任何的數據，數據來源於外部，並且開放給外部應用，這也是為什么叫“倉庫”，而不叫“工廠”的原因。因此數據倉庫的基本架構主要包含的是數據流入流出的過程，可以分為三層——源數據、數據倉庫、數據應用：

　　從圖中可以看出數據倉庫的數據來源於不同的源數據，並提供多樣的數據應用，數據自上而下流入數據倉庫后向上層開放應用，而數據倉庫只是中間集成化數據管理的一個平台。

　　數據倉庫從各數據源獲取數據及在數據倉庫內的數據轉換和流動都可以認為是ETL（抽取Extra, 轉化Transfer, 裝載Load）的過程，ETL是數據倉庫的流水線，也可以認為是數據倉庫的血液，它維系着數據倉庫中數據的新陳代謝，而數據倉庫日常的管理和維護工作的大部分精力就是保持ETL的正常和穩定。

　　下面主要簡單介紹下數據倉庫架構中的各個模塊，當然這里所介紹的數據倉庫主要是指網站數據倉庫。

1、數據倉庫的數據來源

　　其實之前的一篇文章已經介紹過數據倉庫各種源數據的類型——數據倉庫的源數據類型，所以這里不再詳細介紹。

　　對於網站數據倉庫而言，點擊流日志是一塊主要的數據來源，它是網站分析的基礎數據；當然網站的數據庫數據也並不可少，其記錄這網站運營的數據及各種用戶操作的結果，對於分析網站Outcome這類數據更加精准；其他是網站內外部可能產生的文檔及其它各類對於公司決策有用的數據。

2、數據倉庫的數據存儲

　　源數據通過ETL的日常任務調度導出，並經過轉換后以特性的形式存入數據倉庫。其實這個過程一直有很大的爭議，就是到底數據倉庫需不需要儲存細節數據，一方的觀點是數據倉庫面向分析，所以只要存儲特定需求的多維分析模型；另一方的觀點是數據倉庫先要建立和維護細節數據，再根據需求聚合和處理細節數據生成特定的分析模型。我比較偏向后面一個觀點：數據倉庫並不需要儲存所有的原始數據，但數據倉庫需要儲存細節數據，並且導入的數據必須經過整理和轉換使其面向主題。簡單地解釋下：

　　(1).為什么不需要所有原始數據？數據倉庫面向分析處理，但是某些源數據對於分析而言沒有價值或者其可能產生的價值遠低於儲存這些數據所需要的數據倉庫的實現和性能上的成本。比如我們知道用戶的省份、城市足夠，至於用戶究竟住哪里可能只是物流商關心的事，或者用戶在博客的評論內容可能只是文本挖掘會有需要，但將這些冗長的評論文本存在數據倉庫就得不償失；

　　(2).為什么要存細節數據？細節數據是必需的，數據倉庫的分析需求會時刻變化，而有了細節數據就可以做到以不變應萬變，但如果我們只存儲根據某些需求搭建起來的數據模型，那么顯然對於頻繁變動的需求會手足無措；

　　(3).為什么要面向主題？面向主題是數據倉庫的第一特性，主要是指合理地組織數據以方面實現分析。對於源數據而言，其數據組織形式是多樣的，像點擊流的數據格式是未經優化的，前台數據庫的數據是基於OLTP操作組織優化的，這些可能都不適合分析，而整理成面向主題的組織形式才是真正地利於分析的，比如將點擊流日志整理成頁面（Page）、訪問（Visit或Session）、用戶（Visitor）三個主題，這樣可以明顯提升分析的效率。

　　數據倉庫基於維護細節數據的基礎上在對數據進行處理，使其真正地能夠應用於分析。主要包括三個方面：

3、數據的聚合

　　這里的聚合數據指的是基於特定需求的簡單聚合（基於多維數據的聚合體現在多維數據模型中），簡單聚合可以是網站的總Pageviews、Visits、Unique Visitors等匯總數據，也可以是Avg. time on page、Avg. time on site等平均數據，這些數據可以直接地展示於報表上。

4、多維數據模型

　　多維數據模型提供了多角度多層次的分析應用，比如基於時間維、地域維等構建的銷售星形模型、雪花模型，可以實現在各時間維度和地域維度的交叉查詢，以及基於時間維和地域維的細分。所以多維數據模型的應用一般都是基於聯機分析處理（Online Analytical Process, OLAP）的，而面向特定需求群體的數據集市也會基於多維數據模型進行構建。

5、業務模型

　　這里的業務模型指的是基於某些數據分析和決策支持而建立起來的數據模型，比如我之前介紹過的用戶評價模型、關聯推薦模型、RFM分析模型等，或者是決策支持的線性規划模型、庫存模型等；同時，數據挖掘中前期數據的處理也可以在這里完成。

6、數據倉庫的數據應用

　　之前的一篇文章——數據倉庫的價值中介紹過數據倉庫的四大特性上的價值體現，但數據倉庫的價值遠不止這樣，而且其價值真正的體現是在數據倉庫的數據應用上。圖中羅列的幾種應用並未包含所有，其實一切基於數據相關的擴展性應用都可以基於數據倉庫來實現。

7、報表展示

　　報表幾乎是每個數據倉庫的必不可少的一類數據應用，將聚合數據和多維分析數據展示到報表，提供了最為簡單和直觀的數據。

8、即席查詢

　　理論上數據倉庫的所有數據（包括細節數據、聚合數據、多維數據和分析數據）都應該開放即席查詢，即席查詢提供了足夠靈活的數據獲取方式，用戶可以根據自己的需要查詢獲取數據，並提供導出到Excel等外部文件的功能。

9、數據分析

　　數據分析大部分可以基於構建的業務模型展開，當然也可以使用聚合的數據進行趨勢分析、比較分析、相關分析等，而多維數據模型提供了多維分析的數據基礎；同時從細節數據中獲取一些樣本數據進行特定的分析也是較為常見的一種途徑。

10、數據挖掘

　　數據挖掘用一些高級的算法可以讓數據展現出各種令人驚訝的結果。數據挖掘可以基於數據倉庫中已經構建起來的業務模型展開，但大多數時候數據挖掘會直接從細節數據上入手，而數據倉庫為挖掘工具諸如SAS、SPSS等提供數據接口。

11、元數據管理

　　元數據（Meta Date），其實應該叫做解釋性數據，或者數據字典，即數據的數據。主要記錄數據倉庫中模型的定義、各層級間的映射關系、監控數據倉庫的數據狀態及ETL的任務運行狀態。一般會通過元數據資料庫（Metadata Repository）來統一地存儲和管理元數據，其主要目的是使數據倉庫的設計、部署、操作和管理能達成協同和一致。

　　最后做個Ending，數據倉庫本身既不生產數據也不消費數據，只是作為一個中間平台集成化地存儲數據；數據倉庫實現的難度在於整體架構的構建及ETL的設計，這也是日常管理維護中的重頭；而數據倉庫的真正價值體現在於基於其的數據應用上，如果沒有有效的數據應用也就失去了構建數據倉庫的意義。

12、一種Hadoop多維分析平台的架構

整個架構由四大部分組成：數據采集模塊、數據冗余模塊、維度定義模塊、並行分析模塊。如圖上圖所示。
數據采集模塊采用了Cloudera的Flume，將海量的小日志文件進行高速傳輸和合並，並能夠確保數據的傳輸安全性。單個collector宕機之后，數據也不會丟失，並能將agent數據自動轉移到其他的colllecter處理，不會影響整個采集系統的運行。如圖5所示。
數據冗余模塊不是必須的，但如果日志數據中沒有足夠的維度信息，或者需要比較頻繁地增加維度，則需要定義數據冗余模塊。通過冗余維度定義器定義需要冗余的維度信息和來源（數據庫、文件、內存等），並指定擴展方式，將信息寫入數據日志中。在海量數據下，數據冗余模塊往往成為整個系統的瓶頸，建議使用一些比較快的內存NoSQL來冗余原始數據，並采用盡可能多的節點進行並行冗余；或者也完全可以在Hadoop中執行批量Map，進行數據格式的轉化。
維度定義模塊是面向業務用戶的前端模塊，用戶通過可視化的定義器從數據日志中定義維度和度量，並能自動生成一種多維分析語言，同時可以使用可視化的分析器通過GUI執行剛剛定義好的多維分析命令。
並行分析模塊接受用戶提交的多維分析命令，並將通過核心模塊將該命令解析為Map-Reduce，提交給Hadoop集群之后，生成報表供報表中心展示。
核心模塊是將多維分析語言轉化為MapReduce的解析器，讀取用戶定義的維度和度量，將用戶的多維分析命令翻譯成MapReduce程序。核心模塊的具體邏輯如圖下圖所示。

上圖中根據JobConf參數進行Map和Reduce類的拼裝並不復雜，難點是很多實際問題很難通過一個MapReduce Job解決，必須通過多個MapReduce Job組成工作流（WorkFlow），這里是最需要根據業務進行定制的部分。圖7是一個簡單的MapReduce工作流的例子。
MapReduce的輸出一般是統計分析的結果，數據量相較於輸入的海量數據會小很多，這樣就可以導入傳統的數據報表產品中進行展現。