數據倉庫深刻了解

2、數據倉庫與數據集市建模

前言

本文將詳細介紹數據倉庫維度建模技術，並重點討論三種基於ER建模/關係建模/維度建模的數據倉庫整體建模體系：規範化數據倉庫，維度建模數據倉庫，以及獨立數據集市。

維度建模的基本概念

維度建模(dimensional modeling)是專門用於分析型數據庫、數據倉庫、數據集市建模的方法。

它自己屬於一種關係建模方法，但和以前在操做型數據庫中介紹的關係建模方法相比增長了兩個概念：

1. 維度表(dimension)

表示對分析主題所屬類型的描述。好比"昨天早上張三在京東花費200元購買了一個皮包"。那麼以購買爲主題進行分析，可從這段信息中提取三個維度：時間維度(昨天早上)，地點維度(京東), 商品維度(皮包)。一般來講維度表信息比較固定，且數據量小。

2. 事實表(fact table)

表示對分析主題的度量。好比上面那個例子中，200元就是事實信息。事實表包含了與各維度表相關聯的外碼，並經過JOIN方式與維度表關聯。事實表的度量一般是數值類型，且記錄數會不斷增長，表規模迅速增加

維度建模的三種模式

1. 星形模式

星形模式(Star Schema)是最經常使用的維度建模方式，下圖展現了使用星形模式進行維度建模的關係結構：

能夠看出，星形模式的維度建模由一個事實表和一組維表成，且具備如下特色：

a. 維表只和事實表關聯，維表之間沒有關聯；

b. 每一個維表的主碼爲單列，且該主碼放置在事實表中，做爲兩邊鏈接的外碼；

c. 以事實表爲核心，維表圍繞核心呈星形分佈；

2. 雪花模式

雪花模式(Snowflake Schema)是對星形模式的擴展，每一個維表可繼續向外鏈接多個子維表。下圖爲使用雪花模式進行維度建模的關係結構：

星形模式中的維表相對雪花模式來講要大，並且不知足規範化設計。雪花模型至關於將星形模式的大維表拆分紅小維表，知足了規範化設計。然而這種模式在實際應用中不多見，由於這樣作會致使開發難度增大，而數據冗餘問題在數據倉庫裏並不嚴重。

3. 星座模式

星座模式(Fact Constellations Schema)也是星型模式的擴展。基於這種思想就有了星座模式：

前面介紹的兩種維度建模方法都是多維表對應單事實表，但在不少時候維度空間內的事實表不止一個，而一個維表也可能被多個事實表用到。在業務發展後期，絕大部分維度建模都採用的是星座模式。

4. 三種模式對比

概括一下，星形模式/雪花模式/星座模式的關係以下圖所示：

雪花模式是將星型模式的維表進一步劃分，使各維表均知足規範化設計。而星座模式則是容許星形模式中出現多個事實表。本文後面部分將具體講到這幾種模式的使用，請讀者結合實例體會。

實例：零售公司銷售主題的維度建模

在進行維度建模前，首先要了解用戶需求。而筆者在數據庫系列的第一篇就講過，ER建模是當前收集和可視化需求的最佳技術。所以假定和某零售公司進行屢次需求PK後，獲得如下ER圖：

隨後可利用建模工具將ER圖直接映射到關係圖：

需求蒐集完畢後，即可進行維度建模了。本例採用星形模型維度建模。但不論採起何種模式，維度建模的關鍵在於明確下面四個問題：

1. 哪些維度對主題分析有用？

本例中，根據產品(PRODUCT)、顧客(CUSTOMER)、商店(STORE)、日期(DATE)對銷售額進行分析是很是有幫助的；

2. 如何使用現有數據生成維表？

a. 維度PRODUCT可由關係PRODUCT，關係VENDOR，關係CATEGORY鏈接獲得；

b. 維度CUSTOMER和關係CUSTOMER相同；

c. 維度STORE可由關係STROE和關係REGION鏈接獲得；

d. 維度CALENDAR由關係SALESTRANSACTION中的TDate列分離獲得；

3. 用什麼指標來"度量"主題？

本例的主題是銷售，而銷量和銷售額這兩個指標最能直觀反映銷售狀況；

4. 如何使用現有數據生成事實表？

銷量和銷售額信息能夠由關係SALESTRANSACTION和關係SOLDVIA，關係PRODUCT鏈接獲得；

明確這四個問題後，便能輕鬆完成維度建模：

細心的讀者會發現三個問題：1. 維表不知足規範化設計(不知足3NF)；2. 事實表也不知足規範化設計(1NF都不知足)； 3. 維度建模中各維度的主碼由***ID變成***Key；

對於前兩個問題，因爲當前建模環境是數據倉庫，而沒有更新操做，因此不須要嚴格作規範化設計來消除冗餘避免更新異常。

所以雖然能夠以雪花模型進行維度建模，以下所示：

但這樣會加大查詢人員負擔：每次查詢都涉及到太多表了。所以在實際應用中，雪花模型僅是一種理論上的模型。星座模型則出如今"維度建模數據倉庫"中，本文後面將會講到。

對於第三個問題，***Key這樣的字段被稱爲代理碼(surrogate key)，它是一個經過自動分配整數生成的主碼，沒有任何其餘意義。使用它主要是爲了可以處理"緩慢變化的維度"，本文後面會仔細分析這個問題，這裏不糾結。

緩慢變化維度問題

雖然，維表的數據比事實表更穩定。但不論如何維度在某些時候總會發生一些變化。在以前曾拋出一個問題：爲何維度建模後的關係不是***ID，而是***Key了。這樣作的目的其實就是爲了解決一種被稱爲緩慢維度變化(slowly changing dimension)的問題。在維度變化後，一部分歷史信息就被丟掉了。好比張三是某公司會員。

但僅僅這麼作仍是不夠的，代理碼須要配合時間戳，以及行標識符使用才能解決緩慢維度變化的問題。以下CUSTOMER表使用該方法避免緩慢維度變化：

能夠看到用戶張三對應新維度的TaxBracket狀態由Low變成了High。若是須要統計張三的相關行爲，那麼可讓全部記錄用CustomerID字段Join事實表；若是要統計當前TaxBracket爲Low的用戶狀態，則可將Row Indicator字段爲Current的記錄用CustomerKey字段Join事實表；若是要統計歷史TaxBracket狀態爲Low的用戶狀況，則只須要將TaxBracket屬性爲Low的用戶記錄的CustomerKey屬性與事實表關聯。

數據倉庫建模體系之規範化數據倉庫

所謂"數據倉庫建模體系"，指的是數據倉庫從無到有的一整套建模方法。最多見的三種數據倉庫建模體系分別爲：規範化數據倉庫，維度建模數據倉庫，獨立數據集市。不少書將它們稱爲"數據倉庫建模方法"，但筆者認爲數據倉庫建模體系更能準確表達意思，請容許我自做主張一次吧：）。下面首先來介紹規範化數據倉庫。

規範化數據倉庫(normalized data warehouse)顧名思義，其中是規範化設計的分析型數據庫，而後基於這個數據庫爲各部門創建數據集市。整體架構以下圖所示：

該建模體系首先對ETL獲得的數據進行ER建模，關係建模，獲得一個規範化的數據庫模式。而後用這個中心數據庫爲公司各部門創建基於維度建模的數據集市。各部門開發人員大都從這些數據集市提數，一般來講不容許直接訪問中心數據庫。

數據倉庫建模體系之維度建模數據倉庫

非維度建模數據倉庫(dimensionally modeled data warehouse)是一種使用交錯維度進行建模的數據倉庫，其整體架構以下圖所示：

該建模體系首先設計一組經常使用的度集合(conformed dimension)，而後建立一個大星座模型表示全部分析型數據。若是這種一致維度不知足某些數據分析要求，天然也可在數據倉庫之上繼續構建新的數據集市。

數據倉庫建模體系之獨立數據集市

獨立數據集市的建模體系是讓公司的各個組織本身建立並完成ETL，本身維護本身的數據集市。其整體架構以下圖所示：

從技術上來說這是一種很不值得推崇的方式，由於將使信息分散，影響了企業全局範圍內數據分析的效率。此外，各組織之間的ETL架構相互獨立沒法複用，也浪費了企業的開發資源。然而出於某些公司制度及預算方面的考慮，有時也會使用到這種建模體系。

三種數據倉庫建模體系對比

規範化數據倉庫和維度建模數據倉庫分別是Bill Inmon和Ralph Kimball提出的方法。關於哪一種方法更好，哪一種方法更優秀的爭論已經由來已久。但隨着這兩種數據倉庫應用愈來愈多，人們也逐漸瞭解到兩種數據倉庫的優劣之處，以下表所示：

產生這些區別的根本之處在於規範化數據倉庫須要對企業全局進行規範化建模，這將致使較大的工做量。但這一步必須完成好，才能繼續往上建設數據集市。所以也就致使規範化數據倉庫須要必定時間才能投入使用，敏捷性相對後者來講略差。可是規範化數據倉庫一旦創建好了，則之後數據就更易於管理。並且因爲開發人員不能直接使用其中心數據庫，更加確保了數據質量。還有因爲中心數據庫是採用規範化設計的，冗餘狀況也會更少。

然而另外一方面維度建模數據倉庫除了敏捷性更強，並且適用於業務變化比較頻繁的狀況，對開發人員的要求也沒有規範化數據倉庫那麼高。總之各有利弊，具體實施時須要仔細的權衡。

小結

數據倉庫建模是一個綜合性技術，須要使用到ER建模、關係建模、維度建模等技術。並且當企業業務複雜的時候，這部分工做更是須要專門團隊與業務方共同合做來完成。所以一個優秀的數據倉庫建模團隊既要有堅實的數據倉庫建模技術，還要有對現實業務清晰、透徹的理解。

3、數據倉庫系統的實現與使用（olap講解）

前言

上一章節重點講解了數據倉庫建模，它是數據倉庫開發中最核心的部分。然而完整的數據倉庫系統還會涉及其餘一些組件的開發，其中最主要的是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出來吧！須要進一步挖掘其價值吧！歡迎繼續關注！！

本文整理自：穆晨博客

數據倉庫深刻了解

1、數據倉庫概述

前言

數據庫的"分家"

操做型數據庫 VS 分析型數據庫

數據倉庫(data warehouse)定義

數據倉庫組件

數據集市(data mart)

數據倉庫開發流程

小結