資料模型就是資料組織和儲存方法，它強調從業務、資料存取和使用角度合理儲存資料。
隨著DT時代網際網路、智慧裝置及其他資訊科技的發展，資料爆發式增長，如何將這些資料進行有序、有結構地分類組織和儲存是我們面臨的一個挑戰。
如果把資料看作圖書館裡的書，我們希望看到它們在書架上分門別類地放置；如果把資料看作城市的建築，我們希望城市規劃佈局合理；如果把資料看作電腦檔案和資料夾，我們希望按照自己的習慣有很好的資料夾組織方式，而不是糟糕混亂的桌面，經常為找一個檔案而不知所措。
資料模型就是資料組織和儲存方法，它強調從業務、資料存取和使用角度合理儲存資料。Linux的創始人Torvalds有一段關於“什麼才是優秀程式設計師”的話：“爛程式設計師關心的是程式碼，好程式設計師關心的是資料結構和它們之間的關係”，其闡述了資料模型的重要性。有了適合業務和基礎資料儲存環境的模型，那麼大資料就能獲得以下好處。
- 效能：良好的資料模型能幫助我們快速查詢所需要的資料，減少資料的I/O吞吐。
- 成本：良好的資料模型能極大地減少不必要的資料冗餘，也能實現計算結果複用，極大地降低大資料系統中的儲存和計算成本。
- 效率：良好的資料模型能極大地改善使用者使用資料的體驗，提高使用資料的效率。
- 質量：良好的資料模型能改善資料統計口徑的不一致性，減少資料計算錯誤的可能性。
因此，毋庸置疑，大資料系統需要資料模型方法來幫助更好地組織和儲存資料，以便在效能、成本、效率和質量之間取得最佳平衡。
1．關聯式資料庫系統和資料倉儲
E .F .Codd是關聯式資料庫的鼻祖，他首次提出了資料庫系統的關係模型，開創了資料庫關係方法和關係資料理論的研究。隨著一大批大型關聯式資料庫商業軟體（如Oracle、Informix、DB2等）的興起，現代企業資訊系統幾乎都使用關聯式資料庫來儲存、加工和處理資料。資料倉儲系統也不例外，大量的資料倉儲系統依託強大的關聯式資料庫能力儲存和處理資料，其採用的資料模型方法也是基於關聯式資料庫理論的。
雖然近年來大資料的儲存和計算基礎設施在分散式方面有了飛速的發展，NoSQL技術也曾流行一時，但是不管是Hadoop、Spark還是阿里巴巴集團的MaxCompute系統，仍然在大規模使用SQL進行資料的加工和處理，仍然在用Table儲存資料，仍然在使用關係理論描述資料之間的關係，只是在大資料領域，基於其資料存取的特點在關係資料模型的正規化上有了不同的選擇而已。關於正規化的詳細說明和定義，以及其他一些關聯式資料庫的理論是大資料領域建模的基礎，有興趣的讀者可以參考相關的經典資料庫理論書籍，如《資料庫系統概念》。
2．從OLTP和OLAP系統的區別看模型方法論的選擇
OLTP系統通常面向的主要資料操作是隨機讀寫，主要採用滿足3NF的實體關係模型儲存資料，從而在事務處理中解決資料的冗餘和一致性問題；而OLAP系統面向的主要資料操作是批量讀寫，事務處理中的一致性不是OLAP所關注的，其主要關注資料的整合，以及在一次性的複雜大資料查詢和處理中的效能，因此它需要採用一些不同的資料建模方法。
3．典型的資料倉儲建模方法論
- ER模型
資料倉儲之父Bill Inmon提出的建模方法是從全企業的高度設計一個3NF模型，用實體關係（Entity Relationship，ER）模型描述企業業務，在正規化理論上符合3NF。資料倉儲中的3NF與OLTP系統中的3NF的區別在於，它是站在企業角度面向主題的抽象，而不是針對某個具體業務流程的實體物件關係的抽象。其具有以下幾個特點：
1）需要全面瞭解企業業務和資料；
2）實施週期非常長；
3）對建模人員的能力要求非常高；
採用ER模型建設資料倉儲模型的出發點是整合資料，將各個系統中的資料以整個企業角度按主題進行相似性組合和合並，並進行一致性處理，為資料分析決策服務，但是並不能直接用於分析決策。其建模步驟分為三個階段：
1）高層模型：一個高度抽象的模型，描述主要的主題以及主題間的關係，用於描述企業的業務總體概況。
2）中層模型：在高層模型的基礎上，細化主題的資料項。
3）物理模型（也叫底層模型）：在中層模型的基礎上，考慮物理儲存，同時基於效能和平臺特點進行物理屬性的設計，也可能做一些表的合併、分割槽的設計等。
ER模型在實踐中最典型的代表是Teradata公司基於金融業務釋出的FS-LDM（Financial Services Logical Data Model），它通過對金融業務的高度抽象和總結，將金融業務劃分為10大主題，並以設計面向金融倉庫模型的核心為基礎，企業基於此模型做適當調整和擴充套件就能快速落地實施。
- 維度模型
維度模型是資料倉儲領域的Ralph Kimball大師所倡導的，他的The Data Warehouse Toolkit-The Complete Guide to Dimensional Modeling是資料倉儲工程領域最流行的資料倉儲建模的經典。
維度建模從分析決策的需求出發構建模型，為分析需求服務，因此它重點關注使用者如何更快速地完成需求分析，同時具有較好的大規模複雜查詢的響應效能。其典型的代表是星形模型，以及在一些特殊場景下使用的雪花模型。其設計分為以下幾個步驟。
選擇需要進行分析決策的業務過程。業務過程可以是單個業務事件，比如交易的支付、退款等；也可以是某個事件的狀態，比如當前的賬戶餘額等；還可以是一系列相關業務事件組成的業務流程，具體需要看我們分析的是某些事件發生情況，還是當前狀態，或是事件流轉效率。
1）選擇粒度：在事件分析中，我們要預判所有分析需要細分的程度，從而決定選擇的粒度。粒度是維度的一個組合。
2）識別維表：選擇好粒度之後，就需要基於此粒度設計維表，包括維度屬性，用於分析時進行分組和篩選。
3）選擇事實：確定分析需要衡量的指標。
- Data Vault模型
Data Vault是Dan Linstedt發起建立的一種模型，它是ER模型的衍生，其設計的出發點也是為了實現資料的整合，但不能直接用於資料分析決策。它強調建立一個可審計的基礎資料層，也就是強調資料的歷史性、可追溯性和原子性，而不要求對資料進行過度的一致性處理和整合；同時它基於主題概念將企業資料進行結構化組織，並引入了更進一步的正規化處理來優化模型，以應對源系統變更的擴充套件性。Data Vault模型由以下幾部分組成。
1）Hub：是企業的核心業務實體，由實體key、資料倉儲序列代理鍵、裝載時間、資料來源組成。
2）Link：代表Hub之間的關係。這裡與ER模型最大的區別是將關係作為一個獨立的單元抽象，可以提升模型的擴充套件性。它可以直接描述1:1、1:n和n:n的關係，而不需要做任何變更。它由Hub的代理鍵、裝載時間、資料來源組成。
3）Satellite：是Hub的詳細描述內容，一個Hub可以有多個Satellite。它由Hub的代理鍵、裝載時間、來源型別、詳細的Hub描述資訊組成。
Data Vault模型比ER模型更容易設計和產出，它的ETL加工可實現配置化。通過Dan Linstedt的比喻更能理解Data Vault的核心思想：Hub可以想象成人的骨架，那麼Link就是連線骨架的韌帶，而Satellite就是骨架上面的血肉。看如下例項（來自Data Vault Modeling Guide，作者Hans Hultgren），如圖所示。
Data Vault模型例項
- Anchor模型
Anchor對Data Vault模型做了進一步規範化處理，Lars. Rönnbäck的初衷是設計一個高度可擴充套件的模型，其核心思想是所有的擴充套件只是新增而不是修改，因此將模型規範到6NF，基本變成了k-v結構化模型。我們看一下Anchor模型的組成。
1）Anchors：類似於Data Vault的Hub，代表業務實體，且只有主鍵。
2）Attributes：功能類似於Data Vault的Satellite，但是它更加規範化，將其全部k-v結構化，一個表只有一個Anchors的屬性描述。
3）Ties：就是Anchors之間的關係，單獨用表來描述，類似於Data Vault的Link，可以提升整體模型關係的擴充套件能力。
4）Knots：代表那些可能會在多個Anchors中公用的屬性的提煉，比如性別、狀態等這種列舉型別且被公用的屬性。
在上述四個基本物件的基礎上，又可以細劃分為歷史的和非歷史的，其中歷史的會以時間戳加多條記錄的方式記錄資料的變遷歷史。
Anchor模型的建立者以此方式來獲取極大的可擴充套件性，但是也會增加非常多的查詢join操作。建立者的觀點是，資料倉儲中的分析查詢只是基於一小部分欄位進行的，類似於列儲存結構，可以大大減少資料掃描，從而對查詢效能影響較小。一些有資料表裁剪（Table Elimination）特性的資料庫如MariaDB的出現，還會大量減少join操作。但是實際情況是不是如此，還有待商榷。下面是一個Anchor模型圖（來自Anchor Modeling-Agile Information Modeling in Evolving Data Environments，作者Lars. Rönnbäck），如圖所示。
Anchor模型圖
注：本書中出現的部分專有名詞、專業術語、產品名稱、軟體專案名稱、工具名稱等，是淘寶（中國）軟體有限公司內部專案的慣用詞語，如與第三方名稱雷同，實屬巧合。
-
節選自《大資料之路：阿里巴巴大資料實踐》