資料倉儲，這個幾乎是所有大資料開發面試必問的話題。比如資料倉儲的分層架構？為什麼需要資料倉儲建模？資料倉儲建模的原則是什麼？結合業務舉例說明資料倉儲建模的步驟，以及注意事項？什麼是緩慢變化維？維度該如何選擇建設，原則是什麼，主鍵如何設計等等？

一眾問題搞得小夥伴們死去活來，甚至工作好幾年的小夥伴都沒搞清楚過，尤其是大廠特別愛問這些問題。有些小夥伴甚至覺得這些都是形而上學，不懂這些我不一樣搞了很多年開發？即使感興趣的買了一本厚厚的資料倉儲工具書也看不懂！那麼 實際資料倉儲建模到底是什麼，開發人員該掌握哪些？

記住：技術是服務於業務，發展於業務的。 大資料的本質就解決兩個問題：海量資料的儲存和海量資料的計算。大資料之所以有很多技術框架的發展，迭代，就是為了滿足不同的新的業務需求。故技術選型要結合業務，業務的發展也是技術的發展。

一、什麼是資料倉儲，其前世今生？

來一起看個官方定義：資料倉儲，英文名稱為DataWarehouse，可簡寫為DW或DWH。資料倉儲，是為企業所有級別的決策制定過程，提供所有型別資料支援的戰略集合。它出於分析性報告和決策支援目的而建立。為需要業務智慧的企業，提供指導業務流程改進、監視時間、成本、質量以及控制。

簡單點來說，現實情況是一個企業有很多資料來源，比如有的業務資料存放在Mysql,PG庫,有的存放在Oracle，有的日誌存放在Ftp，Nginx伺服器上等，有的是外部採集的爬蟲資料等等。那麼對於企業來說沉澱了這麼多資料，如何將這些資料放到一起進行資料融合，資料分析，給企業挖掘資料價值呢？這些不同資料來源，不同資料儲存格式，不同的資料更新週期，如果讓你把企業這些資料融合分析，你怎麼辦？

首先，你是不是要把這些不同資料按照統一的格式，一定的規範儲存到一起，然後在透過特定的工具做資料計算分析？那麼對於企業來說，把企業各種資料來源的資料放到一起儲存和計算的地方就叫資料倉儲（約定俗稱的叫法），所以本質上資料倉儲上融合各個資料來源，儲存加工資料的地方，早期大資料沒有發展起來的時候，企業資料倉儲的載體一般是Oracle，那時候主要給企業做BI報表（Business Intelligence商業智慧）。

後來隨著企業數字化，網際網路的發展，企業收集到資料越來越多，發現原有的技術框架已經滿足不了業務儲存和分析的需求了。於是乎就有了現在Hadoop生態為主的數倉倉庫。

二、資料倉儲發展歷程與內容

1.資料倉儲的發展大致經歷了這樣的三個過程：

簡單報表階段：這個階段，系統的主要目標是解決一些日常的工作中業務人員需要的報表，以及生成一些簡單的能夠幫助領導進行決策所需要的彙總資料。這個階段的大部分表現形式為資料庫和前端報表工具。

資料集市階段：這個階段，主要是根據某個業務部門的需要，進行一定的資料的採集，整理，按照業務人員的需要，進行多維報表的展現，能夠提供對特定業務指導的資料，並且能夠提供特定的領導決策資料。

資料倉儲階段：這個階段，主要是按照一定的資料模型，對整個企業的資料進行採集，整理，並且能夠按照各個業務部門的需要，提供跨部門的，完全一致的業務報表資料，能夠透過資料倉儲生成對對業務具有指導性的資料，同時，為領導決策提供全面的資料支援。

透過資料倉儲建設的發展階段，我們能夠看出，資料倉儲的建設和資料集市的建設的重要區別就在於資料模型的支援。因此，資料模型的建設，對於我們資料倉儲的建設，有著決定性的意義。

2.資料倉儲組成

多種多樣的資料來源

資料抽取、轉換、匯入（ETL）

操作型的資料和分析型的資料

主題模型

資料集市

報表、查詢、EIS工具(主管資訊系統---服務於組織的高層經理的一類特殊的資訊系統能夠迅速、方便、直觀（用圖形）地提供綜合資訊)

OLAP工具

資料探勘工具

後設資料

資料質量管理

資料標準化

資訊釋出

三、資料倉儲的特點和建設的原則

數倉倉庫的既然本質是給企業儲存計算各種資料來源資料融合分析的。首先如果企業資料規模小，資料來源單一，則無所謂，數倉倉庫怎麼搞都行。但是如果企業資料來源及其多而複雜，資料體量及其龐大，如PB規模的資料，同時資料倉儲的使用人員成千上萬，那麼如何管理這些海量的資料，如何設計資料的儲存，如何管理這些人員的使用等等，都是一個難題。

就像一個小公司一樣，幾十人，上百人時可以透過人情事故管理，靈活高效氛圍好。但是一個幾萬人，幾十萬人的公司再去靠人情管理就不太現實了，這個時候怎麼辦？就要靠規章制度去約束規範大家，靠KPI考核大家了。同樣，資料倉儲的管理也是這樣，海量資料儲存計算的資料倉儲建設，也有一些原則和規範給大家參考。

1．資料倉儲的資料是面向主題的

什麼是主題呢？首先，主題是一個抽象的概念，是較高層次上企業資訊系統中的資料綜合、歸類並進行分析利用的抽象。在邏輯意義上，它是對應企業中某一宏觀分析領域所涉及的分析物件。面向主題的資料組織方式，就是在較高層次上對分析物件的資料的一個完整、一致的描述，能完整、統一地刻劃各個分析物件所涉及的企業的各項資料，以及資料之間的聯絡。所謂較高層次是相對面嚮應用的資料組織方式而言的，是指按照主題進行資料組織的方式具有更高的資料抽象級別。

說人話，就是企業資料倉儲中資料是分主題域的，比如以電商上行業為例，資料倉儲建設的主題分為：會員資訊主題域（會員資訊相關所有資料），訂單主題域，商家主題域，商品主題域等等。這些牽涉到資料建模的選型，為啥要這樣建設成主題，這是很多企業歷年經驗總結的，具體好處原因後面數倉建模模組時詳細分析。

2.資料倉儲的資料是整合的

資料倉儲的資料是從原有的分散的資料庫資料抽取來的。操作型資料與DSS分析型資料之間差別甚大。

第一，資料倉儲的每一個主題所對應的源資料在原有的各分散資料庫中有許多重複和不一致的地方，且來源於不同的聯機系統的資料都和不同的應用邏輯捆綁在一起；

第二，資料倉儲中的綜合資料不能從原有的資料庫系統直接得到。因此在資料進入資料倉儲之前，必然要經過統一與綜合，這一步是資料倉儲建設中最關鍵、最複雜的一步，所要完成的工作有：（1）要統一源資料中所有矛盾之處，如欄位的同名異義、異名同義、單位不統一、字長不一致，等等。 （2）進行資料綜合和計算。資料倉儲中的資料綜合工作可以在從原有資料庫抽取資料時生成，但許多是在資料倉儲內部生成的，即進入資料倉儲以後進行綜合生成的。

簡單點來說：就是資料倉儲中資料是很多資料來源資料融合後加工的，跟原來業務系統的資料差別會很大，比如資料根據各中國源資料彙總統計的，或者透過特定演算法ETL加工處理後得來的。所以叫整合的。

3. 資料倉儲的資料是不可更新的（相對穩定的）

資料倉儲的資料主要供企業決策分析之用，所涉及的資料操作主要是資料查詢，一般情況下並不進行修改操作。

資料倉儲的資料反映的是一段相當長的時間內歷史資料的內容，是不同時點的資料庫快照的集合，以及基於這些快照進行統計、綜合和重組的匯出資料，而不是聯機處理的資料。資料庫中進行聯機處理的資料經過整合輸入到資料倉儲中，一旦資料倉儲存放的資料已經超過資料倉儲的資料儲存期限，這些資料將從當前的資料倉儲中刪去。因為資料倉儲只進行資料查詢操作，所以資料倉儲管理系統相比資料庫管理系統而言要簡單得多。

資料庫管理系統中許多技術難點，如完整性保護、併發控制等等，在資料倉儲的管理中幾乎可以省去。但是由於資料倉儲的查詢資料量往往很大，所以就對資料查詢提出了更高的要求，它要求採用各種複雜的索引技術；同時由於資料倉儲面向的是商業企業的高層管理者，他們會對資料查詢的介面友好性和資料表示提出更高的要求。

簡單總結一下就是：資料倉儲中儲存的資料是一系列企業資料的歷史快照，不建議被修改（實際分析會有資料回補的情況）。使用者只能透過分析工具進行查詢和分析。

4.資料倉儲的資料是隨時間不斷變化的（時變性）

資料倉儲中的資料不可更新是針對應用來說的，也就是說，資料倉儲的使用者進行分析處理時是不進行資料更新操作的。但並不是說，在從資料整合輸入資料倉儲開始到最終被刪除的整個資料生存週期中，所有的資料倉儲資料都是永遠不變的。

資料倉儲的資料是隨時間的變化而不斷變化的，這是資料倉儲資料的第四個特徵。這一特徵表現在以下3方面：

（1）資料倉儲隨時間變化不斷增加新的資料內容。資料倉儲系統必須不斷捕捉OLTP資料庫中變化的資料，追加到資料倉儲中去，也就是要不斷地生成OLTP資料庫的快照，經統一整合後增加到資料倉儲中去；但對於確實不再變化的資料庫快照，如果捕捉到新的變化資料，則只生成一個新的資料庫快照增加進去，而不會對原有的資料庫快照進行修改。

（2）資料倉儲隨時間變化不斷刪去舊的資料內容。資料倉儲的資料也有儲存期限，一旦超過了這一期限，過期資料就要被刪除。只是資料倉儲內的資料時限要遠遠長於操作型環境中的資料時限。在操作型環境中一般只儲存有60~90天的資料，而在資料倉儲中則需要儲存較長時限的資料（如5~10年），以適應DSS進行趨勢分析的要求。

（3）資料倉儲中包含有大量的綜合資料，這些綜合資料中很多跟時間有關，如資料經常按照時間段進行綜合，或隔一定的時間片進行抽樣等等。這些資料要隨著時間的變化不斷地進行重新綜合。因此，資料倉儲的資料特徵都包含時間項，以標明資料的歷史時期。

四、資料倉儲的分層架構原因與分層原則

1.資料倉儲要不要分層？

資料倉儲既然是資料儲存計算的地方，那麼為什麼需要分層呢？同樣也是資料規模，業務場景決定。可以說很多公司資料倉儲建設剛起步時，大部分的資料都是經過粗暴的資料接入，進行ETL後就直接對接業務，生成報表或者匯入業務系統直接使用。

後來隨著公司業務的發展，資料的沉澱，資料倉儲發展到一定階段，發現資料的使用雜亂無章，各種業務都是從原始資料直接計算而得。造成各種重複計算（可能兩張表只差了幾個欄位，但每個人都跑了一次），嚴重浪費了計算資源和儲存資源，企業負擔成本極大。這個時候大家就要想著如何規範化儲存和計算了，如何最大化降低企業成本。尤其資料規模越大的公司，需求越強烈。

當然你公司資料規模小，非不分層可不可以，當然可以。也沒必要搞那麼規範，規範的不好之處就是要付出很大的人力成本去實施規範，監督規範的實施。最終的選擇要結合你們企業的成本去考量，一切都要結合實際。

2.數倉分層的好處有哪些？

歷史血的教訓，各大廠總結了下數倉分層的好處：

清晰資料結構：每一個資料分層都有它的作用域，這樣我們在使用表的時候能更方便地定位和理解。

資料血緣追蹤：簡單來講可以這樣理解，我們最終給業務誠信的是一能直接使用的張業務表，但是它的來源有很多，如果有一張來源表出問題了，我們希望能夠快速準確地定位到問題，並清楚它的危害範圍。

減少重複開發：規範資料分層，開發一些通用的中間層資料，能夠減少極大的重複計算。

把複雜問題簡單化。講一個複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維護資料的準確性，當資料出現問題之後，可以不用修復所有的資料，只需要從有問題的步驟開始修復。

遮蔽原始資料的異常。不必改一次業務就需要重新接入資料，或者業務改了資料，也不一定對現在有影響

遮蔽業務的影響，不必改一次業務就需要重新接入資料。

3.資料倉儲該如何分層及如何設計分層？

數倉的分層好處有那麼多？那麼該如何分層？一切其實還是結合企業的實際情況，業務場景，資料規模，可以粗放型，也可以豐富更多的細節。

具體數倉的分層設計，如何結合業務對企業資料倉儲分層？主流大廠的數倉分層架構情況，設計原則等，分層如何命名？這些內容太多了，後面詳細一章節結合案例分析。也可以先參考：資料倉儲的四個層次設計

五、資料倉儲建模的選型與建模原則

前面聊過資料倉儲發展到規範化建設需要分層架構。那麼每一層的資料建模的原則應該是什麼樣的呢？以及為什麼需要資料建模？資料建模有哪些選型？

1.為什麼需要資料建模？

2.資料建模有哪些方法？這些模型的特點是什麼？

3.資料建模的原則是什麼？

4.企業數倉建設如何選擇建模，各種模型的對比？

六、資料倉儲維度建模的實施與注意事項

1.維度建模有哪些步驟及其作用？

2.結合企業案例演示完整維度建模使用？

3.維度建模的注意事項？

七、數倉的資料治理與安全

1.數倉的資料治理的必要性？

2.從哪些維度資料治理？

3.資料治理與管理體系建設？

總結

總結：前面7個章節涵蓋了數倉的前世今生，發展迭代，以及當前在企業中的應用，簡單介紹了整個數倉體系與框架。 學習的過程是要先見森林，再見樹木，最後再見森林的過程。

原文來源：滌生手記