一、資料倉儲建模的意義
如果把資料看作圖書館裡的書，我們希望看到它們在書架上分門別類地放置；如果把資料看作城市的建築，我們希望城市規劃布局合理；如果把資料看作電腦檔案和資料夾，我們希望按照自己的習慣有很好的資料夾組織方式，而不是糟糕混亂的桌面，經常為找乙個檔案而不知所措。
資料模型就是資料組織和儲存方法，它強調從業務、資料訪問和使用角度合理儲存資料。linux的創始人torvalds有一段關於「什麼才是優秀程式設計師」的話：「爛程式設計師關心的是**，好程式設計師關心的是資料結構和它們之間的關係」，最能夠說明資料模型的重要性。
只有資料模型將資料有序的組織和儲存起來之後，大資料才能得到高效能、低成本、高效率、高質量的使用。
效能：幫助我們快速查詢所需要的資料，減少資料的i/o吞吐，提高使用資料的效率，如寬表。
成本：極大地減少不必要的資料冗餘，也能實現計算結果復用，極大地降低儲存和計算成本。
效率：在業務或系統發生變化時，可以保持穩定或很容易擴充套件，提高資料穩定性和連續性。
質量：良好的資料模型能改善資料統計口徑的不一致性，減少資料計算錯誤的可能性。資料模型能夠促進業務與技術進行有效溝通，形成對主要業務定義和術語的統一認識，具有跨部門、中性的特徵，可以表達和涵蓋所有的業務。
大資料系統需要資料模型方法來幫助更好地組織和儲存資料，以便在效能、成本、效率和質量之間取得最佳平衡！
下圖是個示例，通過統一資料模型，遮蔽資料來源變化對業務的影響，保證業務的穩定，表述了資料倉儲模型的一種價值：
二、資料倉儲分層的設計
為了實現以上的目的，資料倉儲一般要進行分層的設計，其能帶來五大好處：
清晰資料結構：每乙個資料分層都有它的作用域，這樣我們在使用表的時候能更方便地定位和理解。
資料血緣追蹤：能夠快速準確地定位到問題，並清楚它的危害範圍。
減少重複開發：規範資料分層，開發一些通用的中間層資料，能夠減少極大的重複計算。
把複雜問題簡單化：將複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。當資料出現問題之後，不用修復所有的資料，只需要從有問題的步驟開始修復。
遮蔽原始資料的異常：不必改一次業務就需要重新接入資料。
以下是我們的一種分層設計方法，資料緩衝區（ods）的資料結構與源系統完全一致。基礎資料模型(dwd)和融合資料模型（dwi與dwa）是大資料平台重點建設的資料模型。應用層模型由各應用按需自行建設，其中基礎資料模型一般採用er模型，融合資料模型採用維度建模思路。
三、兩種經典的資料倉儲建模方法
前面的分層設計中你會發現有兩種設計方法，關係建模和維度建模，下面分別簡單介紹其特點和適用場景。
1、維度建模
（1）定義
維度模型是資料倉儲領域另一位大師ralph kimball 所倡導的。維度建模以分析決策的需求出發構建模型，構建的資料模型為分析需求服務，因此它重點解決使用者如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應效能，更直接面向業務。
典型的代表是我們比較熟知的星形模型：
星型模型由乙個事實表和一組維表組成。每個維表都有乙個維作為主鍵，所有這些維的主鍵組合成事實表的主鍵。強調的是對維度進行預處理，將多個維度集合到乙個事實表，形成乙個寬表。
這也是我們在使用hive時，經常會看到一些大寬表的原因，大寬表一般都是事實表，包含了維度關聯的主鍵和一些度量資訊，而維度表則是事實表裡面維度的具體資訊，使用時候一般通過join來組合資料，相對來說對olap的分析比較方便。
（2）建模方法
通常需要選擇某個業務過程，然後圍繞該過程建立模型，其一般採用自底向上的方法，從明確關鍵業務過程開始，再到明確粒度，再到明確維度，最後明確事實，非常簡單易懂。
以下是阿里的onedata的建模工作流，可以參考。
（3）優缺點
優點：技術要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，較好的大規模複雜查詢的響應效能
缺點：維度表的冗餘會較多，視野狹窄
2、關係建模
（1）定義
是資料倉儲之父inmon推崇的、從全企業的高度設計乙個3nf模型的方法，用實體加關係描述的資料模型描述企業業務架構，在正規化理論上符合3nf，站在企業角度面向主題的抽象，而不是針對某個具體業務流程的實體物件關係抽象。
它更多是面向資料的整合和一致性治理，正如inmon所希望達到的「single version of the truth」。
當有乙個或多個維表沒有直接連線到事實表上，而是通過其他維表連線到事實表上時，其**就像多個雪花連線在一起，故稱雪花模型。
雪花模型是對星型模型的擴充套件。它對星型模型的維表進一步層次化，原有的各維表可能被擴充套件為小的事實表，形成一些區域性的 "層次 " 區域，這些被分解的表都連線到主維度表而不是事實表。
雪花模型更加符合資料庫正規化，減少資料冗餘，但是在分析資料的時候，操作比較複雜，需要join的表比較多所以其效能並不一定比星型模型高。
（2）建模方法
關係建模常常需要全域性考慮，要對上游業務系統的進行資訊調研，以做到對其業務和資料的基本了解，要做到主題劃分，讓模型有清晰合理的實體關係體系，以下是方法的示意：
以下是中國移動的概念模型的一種示例，如果沒有自頂向下的視野，基本是總結不出來的：
（3）優缺點
缺點：需要全面了解企業業務、資料和關係；實施週期非常長，成本昂貴；對建模人員的能力要求也非常高，容易爛尾。
3、建模方法比較
一般來講，維度模型簡單直觀，適合業務模式快速變化的行業，關係模型實現複雜，適合業務模式比較成熟的行業，阿里原來用關係建模，現在基本都是維度建模的方式了。
運營商以前都是關係建模，現在其實邊界越來越模糊，很多大資料業務變化很快，採用維度建模也比較方便，不需要頂層設計。
四、企業建模的三點經驗
維度建模就不說了，只要能理解業務過程和其中涉及的相關資料、維度就可以，但自頂向下的關係建模難度很大，以下是關係建模的三個建設要點。
1、業務的理解：找到企業內最理解業務和源系統的人，梳理出現狀，比如運營商就要深刻理解三域（o/b/m），概念建模的挑戰就很大，現在做到b域的概念建模已經很不容易。
2、資料及關係的理解：各個域的系統建設的時候沒有統一文件和規範，要梳理出邏輯模型不容易，比如運營商的事件主題下的邏輯模型就非常複雜。
3、標準化的推進：資料倉儲建模的任何實體都需要標準化命名，否則未來的管理成本巨大，也是後續資料有效治理的基礎，以下是我們的乙個命名規範示例：
資料倉儲 建模
粒度概述 粒度問題時設計資料倉儲的乙個最重要方面。粒度時指資料倉儲的資料單位中儲存資料的細化或綜合成都的級別。細化程度越高，粒度就越小 相反，細化程度越低，粒度級就越大。資料的粒度一直時乙個設計問題。資料倉儲環境中粒度之所以時主要的設計問題，是因為它深深地影響存放在資料倉儲中的資料量的大小。同時影響...
資料倉儲建模
是原始資料,儲存總hdfs上 lzo壓縮 解壓速度非常快 允許在壓縮部分以損失壓縮速度為代價提高壓縮率，解壓速度不會降低。演算法無損,執行緒安全 需構建維度模型,一般採用星型模型,呈現的狀態一般為星座模型 維度建模的過程 選擇業務 一條業務線對應一張事實表 宣告粒度 精確定義事實表中的一行資料表示什...
資料倉儲建模參考
資料倉儲建模案例 資料倉儲建模規範1.0 資料倉儲優化資料分析 資料倉儲的建模方法 資料倉儲維度集定義 寬表的思考 寬表從字面意義上講就是字段比較多的資料庫表。通常是指業務主題相關的指標 維度 屬性關聯在一起的一張資料庫表。由於把不同的內容都放在同一張表儲存，寬表已經不符合三正規化的模型設計規範，隨...