前言
上一篇重點講解了數據倉庫建模，它是數據倉庫開發中最核心的部分。然而完整的數據倉庫系統還會涉及其他一些組件的開發，其中最主要的是ETL工程，在線分析處理工具(OLAP)和商務智能(BI)應用等。
本文將對這些方面做一個總體性的介紹(尤其是OLAP)，旨在讓讀者對數據倉庫的認識提升到一個全局性的高度。
創建數據倉庫
數據倉庫的創建方法和數據庫類似，也是通過編寫DDL語句來實現。在過去，數據倉庫系統大都建立在RDBMS上，因為維度建模其實也可以看做是關系建模的一種。但如今隨着開源分布式數據倉庫工具如Hadoop Hive，Spark SQL的興起，開發人員往往將建模和實現分離。使用專門的建模軟件進行ER建模、關系建模、維度建模，而具體實現則在Hive/Spark SQL下進行。沒辦法，誰讓這些開源工具沒有提供自帶的可視化建模插件呢:-(。
話說現在的開源分布式工具都是"散兵作戰"，完成一個大的項目要組合N個工具，沒有一個統一的開發平台。還有就是可視化效果比較差，界面很難看或者沒有界面。個人建議在資金足夠的情況下盡量使用商用大數據平台來開發，雖然這些商用產品廣告打得多少有點誇張，但是它們的易用性做的是真好。這里筆者推薦阿里雲的數加平台，附鏈接：https://data.aliyun.com/。
ETL：抽取、轉換、加載
在本系列第一篇中，曾大致介紹了該環節，它很可能是數據倉庫開發中最耗時的階段。本文將詳細對這個環節進行講解。
ETL工作的實質就是從各個數據源提取數據，對數據進行轉換，並最終加載填充數據到數據倉庫維度建模后的表中。只有當這些維度/事實表被填充好，ETL工作才算完成。接下來分別對抽取，轉換，加載這三個環節進行講解：
1. 抽取(Extract)
數據倉庫是面向分析的，而操作型數據庫是面向應用的。顯然，並不是所有用於支撐業務系統的數據都有拿來分析的必要。因此，該階段主要是根據數據倉庫主題、主題域確定需要從應用數據庫中提取的數。
具體開發過程中，開發人員必然經常發現某些ETL步驟和數據倉庫建模后的表描述不符。這時候就要重新核對、設計需求，重新進行ETL。正如數據庫系列的這篇中講到的，任何涉及到需求的變動，都需要重頭開始並更新需求文檔。
2. 轉換(Transform)
轉換步驟主要是指對提取好了的數據的結構進行轉換，以滿足目標數據倉庫模型的過程。此外，轉換過程也負責數據質量工作，這部分也被稱為數據清洗(data cleaning)。數據質量涵蓋的內容可具體參考這里。
3. 加載(Load)
加載過程將已經提取好了，轉換后保證了數據質量的數據加載到目標數據倉庫。加載可分為兩種L：首次加載(first load)和刷新加載(refresh load)。其中，首次加載會涉及到大量數據，而刷新加載則屬於一種微批量式的加載。
多說一句，如今隨着各種分布式、雲計算工具的興起，ETL實則變成了ELT。就是業務系統自身不會做轉換工作，而是在簡單的清洗后將數據導入分布式平台，讓平台統一進行清洗轉換等工作。這樣做能充分利用平台的分布式特性，同時使業務系統更專注於業務本身。
OLAP/BI工具
數據倉庫建設好以后，用戶就可以編寫SQL語句對其進行訪問並對其中數據進行分析。但每次查詢都要編寫SQL語句的話，未免太麻煩，而且對維度建模數據進行分析的SQL代碼套路比較固定。於是，便有了OLAP工具，它專用於維度建模數據的分析。而BI工具則是能夠將OLAP的結果以圖表的方式展現出來，它和OLAP通常出現在一起。(注：本文所指的OLAP工具均指代這兩者。)
在規范化數據倉庫中OLAP工具和數據倉庫的關系大致是這樣的： 
這種情況下，OLAP不允許訪問中心數據庫。一方面中心數據庫是采取規范化建模的，而OLAP只支持對維度建模數據的分析；另一方面規范化數據倉庫的中心數據庫本身就不允許上層開發人員訪問。而在維度建模數據倉庫中，OLAP/BI工具和數據倉庫的關系則是這樣的：
在維度建模數據倉庫中，OLAP不但可以從數據倉庫中直接取數進行分析，還能對架構在其上的數據集市群做同樣工作。對該部分講解感到模糊的讀者請重看上篇中三種數據倉庫建模體系部分。
數據立方體(Data Cube)
在介紹OLAP工具的具體使用前，先要了解這個概念：數據立方體(Data Cube)。
很多年前，當我們要手工從一堆數據中提取信息時，我們會分析一堆數據報告。通常這些數據報告采用二維表示，是行與列組成的二維表格。但在真實世界里我們分析數據的角度很可能有多個，數據立方體可以理解為就是維度擴展后的二維表格。下圖展示了一個三維數據立方體：
盡管這個例子是三維的，但更多時候數據立方體是N維的。它的實現有兩種方式，本文后面部分會講到。其中上一篇講到的星形模式就是其中一種，該模式其實是一種連接關系表與數據立方體的橋梁。但對於大多數純OLAP使用者來講，數據分析的對象就是這個邏輯概念上的數據立方體，其具體實現不用深究。對於這些OLAP工具的使用者來講，基本用法是首先配置好維表、事實表，然后在每次查詢的時候告訴OLAP需要展示的維度和事實字段和操作類型即可。
下面介紹數據立方體中最常見的五大操作：切片，切塊，旋轉，上卷，下鑽。
1. 切片和切塊(Slice and Dice)
在數據立方體的某一維度上選定一個維成員的操作叫切片，而對兩個或多個維執行選擇則叫做切塊。下圖邏輯上展示了切片和切塊操作：
這兩種操作的SQL模擬語句如下，主要是對WHERE語句做工作：
# 切片
SELECT Locates.地區, Products.分類, SUM(數量)
FROM Sales, Dates, Products, Locates
WHERE Dates.季度 = 2
AND Sales.Date_key = Dates.Date_key
AND Sales.Locate_key = Locates.Locate_key
AND Sales.Product_key = Products.Product_key
GROUP BY Locates.地區, Products.分類
# 切塊
SELECT Locates.地區, Products.分類, SUM(數量)
FROM Sales, Dates, Products, Locates
WHERE (Dates.季度 = 2 OR Dates.季度 = 3) AND (Locates.地區 = '江蘇' OR Locates.地區 = '上海')
AND Sales.Date_key = Dates.Date_key
AND Sales.Locate_key = Locates.Locate_key
AND Sales.Product_key = Products.Product_key
GROUP BY Dates.季度, Locates.地區, Products.分類
2. 旋轉(Pivot)
旋轉就是指改變報表或頁面的展示方向。對於使用者來說，就是個視圖操作，而從SQL模擬語句的角度來說，就是改變SELECT后面字段的順序而已。下圖邏輯上展示了旋轉操作：
3. 上卷和下鑽(Rol-up and Drill-down)
上卷可以理解為"無視"某些維度；下鑽則是指將某些維度進行細分。下圖邏輯上展示了上卷和下鑽操作：
這兩種操作的SQL模擬語句如下，主要是對GROUP BY語句做工作：
# 上卷
SELECT Locates.地區, Products.分類, SUM(數量)
FROM Sales, Products, Locates
WHERE Sales.Locate_key = Locates.Locate_key
AND Sales.Product_key = Products.Product_key
GROUP BY Locates.地區, Products.分類
# 下鑽
SELECT Locates.地區, Dates.季度, Products.分類, SUM(數量)
FROM Sales, Dates, Products, Locates
WHERE Sales.Date_key = Dates.Date_key
AND Sales.Locate_key = Locates.Locate_key
AND Sales.Product_key = Products.Product_key
GROUP BY Dates.季度.月份, Locates.地區, Products.分類
4. 其他OLAP操作
除了上述的幾個基本操作，不同的OLAP工具也會提供自有的OLAP查詢功能，如鑽過，鑽透等，本文不一一進行講解。通常一個復雜的OLAP查詢是多個這類OLAP操作疊加的結果。
OLAP的架構模式
1. MOLAP(Multidimensional Online Analytical Processing)
MOLAP架構會生成一個新的多維數據集，也可以說是構建了一個實際數據立方體。其架構如下圖所示：
在該立方體中，每一格對應一個直接地址，且常用的查詢已被預先計算好。因此每次的查詢都是非常快速的，但是由於立方體的更新比較慢，所以是否使用這種架構得具體問題具體分析。
2. ROLAP(Relational Online Analytical Processing)
ROLAP架構並不會生成實際的多維數據集，而是使用星形模式以及多個關系表對數據立方體進行模擬。其架構如下圖所示：
顯然，這種架構下的查詢沒有MOLAP快速。因為ROLAP中，所有的查詢都是被轉換為SQL語句執行的。而這些SQL語句的執行會涉及到多個表之間的JOIN操作，沒有MOLAP速度快。
3. HOLAP(Hybrid Online Analytical Processing)
這種架構綜合參考MOLAP和ROLAP而采用一種混合解決方案，將某些需要特別提速的查詢放到MOLAP引擎，其他查詢則調用ROLAP引擎。
筆者發現一個有趣的現象，很多工具的發展都滿足這個規律：工具A被創造，投入使用后發現缺點；然后工具B為了彌補這個缺點而被創造，但是帶來了新的缺點；然后就會用工具C被創造，根據不同情況調用A和B。比較無語......
小結
本文是數據倉庫系列的最后一篇。一路下來，讀者有木有發現數據倉庫系統的開發是一個非常浩大的工程呢？
確實，整個數據倉庫系統的開發會涉及到各種團隊：數據建模團隊，業務分析團隊，系統架構團隊，平台維護團隊，前端開發團隊等等。對於志在從事這方面工作的人來說，需要學習的還有很多。但對於和筆者一樣志在成為一名優秀"數據科學家"的人來說，這些數據基礎知識已經夠用了。筆者看來，數據科學家的核心競爭優勢在三個方面：數據基礎，數據可視化，算法模型。這三個方面需要投入的時間成本遞增，而知識的重要性遞減。因此，數據庫系列和數據倉庫系列是性價比最高的兩個系列哦。
接下來，我將把目光聚焦到數據可視化系列，以及醞釀了很久的數據挖掘系列上來。數據管理好了，需要酷炫的show出來吧！需要進一步挖掘其價值吧！歡迎繼續關注！！