299
阿裏巴巴大數據實踐之數據建模
隨著DT時代互聯網、智能設備及其他信息技術的發展，數據爆發式增長，如何將這些數據進行有序、有結構地分類組織和存儲是我們麵臨的一個挑戰。
為什麼需要數據建模
如果把數據看作圖書館裏的書，我們希望看到它們在書架上分門別類地放置；如果把數據看作城市的建築，我們希望城市規劃布局合理；如果把數據看作電腦文件和文件夾，我們希望按照自己的習慣有很好的文件夾組織方式，而不是糟糕混亂的桌麵，經常為找一個文件而不知所措。
數據模型就是數據組織和存儲方法，它強調從業務、數據存取和使用角度合理存儲數據。Linux的創始人Torvalds有一段關於“什麼才是優秀程序員”的話：“爛程序員關心的是代碼，好程序員關心的是數據結構和它們之間的關係”，其闡述了數據模型的重要性。有了適合業務和基礎數據存儲環境的模型，那麼大數據就能獲得以下好處。
性能：良好的數據模型能幫助我們快速查詢所需要的數據，減少數據的I/O吞吐。
成本：良好的數據模型能極大地減少不必要的數據冗餘，也能實現計算結果複用，極大地降低大數據係統中的存儲和計算成本。
效率：良好的數據模型能極大地改善用戶使用數據的體驗，提高使用數據的效率。
質量：良好的數據模型能改善數據統計口徑的不一致性，減少數據計算錯誤的可能性。
因此，毋庸置疑，大數據係統需要數據模型方法來幫助更好地組織和存儲數據，以便在性能、成本、效率和質量之間取得最佳平衡。
關係數據庫係統和數據倉庫
E .F .Codd是關係數據庫的鼻祖，他首次提出了數據庫係統的關係模型，開創了數據庫關係方法和關係數據理論的研究。隨著一大批大型關係數據庫商業軟件（如Oracle、Informix、DB2等）的興起，現代企業信息係統幾乎都使用關係數據庫來存儲、加工和處理數據。數據倉庫係統也不例外，大量的數據倉庫係統依托強大的關係數據庫能力存儲和處理數據，其采用的數據模型方法也是基於關係數據庫理論的。雖然近年來大數據的存儲和計算基礎設施在分布式方麵有了飛速的發展，NoSQL技術也曾流行一時，但是不管是Hadoop、Spark還是阿裏巴巴集團的MaxCompute係統，仍然在大規模使用SQL進行數據的加工和處理，仍然在用Table存儲數據，仍然在使用關係理論描述數據之間的關係，隻是在大數據領域，基於其數據存取的特點在關係數據模型的範式上有了不同的選擇而已。關於範式的詳細說明和定義，以及其他一些關係數據庫的理論是大數據領域建模的基礎，有興趣的讀者可以參考相關的經典數據庫理論書籍，如《數據庫係統概念》。
從OLTP和OLAP係統的區別看模型方法論的選擇
OLTP係統通常麵向的主要數據操作是隨機讀寫，主要采用滿足3NF的實體關係模型存儲數據，從而在事務處理中解決數據的冗餘和一致性問題；而OLAP係統麵向的主要數據操作是批量讀寫，事務處理中的一致性不是OLAP所關注的，其主要關注數據的整合，以及在一次性的複雜大數據查詢和處理中的性能，因此它需要采用一些不同的數據建模方法。
典型的數據倉庫建模方法論
ER模型
數據倉庫之父Bill Inmon提出的建模方法是從全企業的高度設計一個3NF模型，用實體關係（Entity Relationship，ER）模型描述企業業務，在範式理論上符合3NF。數據倉庫中的3NF與OLTP係統中的3NF的區別在於，它是站在企業角度麵向主題的抽象，而不是針對某個具體業務流程的實體對象關係的抽象。其具有以下幾個特點：
需要全麵了解企業業務和數據。
實施周期非常長。
對建模人員的能力要求非常高。
采用ER模型建設數據倉庫模型的出發點是整合數據，將各個係統中的數據以整個企業角度按主題進行相似性組合和合並，並進行一致性處理，為數據分析決策服務，但是並不能直接用於分析決策。
其建模步驟分為三個階段。
高層模型：一個高度抽象的模型，描述主要的主題以及主題間的關係，用於描述企業的業務總體概況。
中層模型：在高層模型的基礎上，細化主題的數據項。
物理模型（也叫底層模型）：在中層模型的基礎上，考慮物理存儲，同時基於性能和平台特點進行物理屬性的設計，也可能做一些表的合並、分區的設計等。
ER模型在實踐中最典型的代表是Teradata公司基於金融業務發布的FS-LDM（Financial Services Logical Data Model），它通過對金融業務的高度抽象和總結，將金融業務劃分為10大主題，並以設計麵向金融倉庫模型的核心為基礎，企業基於此模型做適當調整和擴展就能快速落地實施。
維度模型
維度模型是數據倉庫領域的Ralph Kimball大師所倡導的，他的The Data Warehouse Toolkit-The Complete Guide to Dimensional Modeling是數據倉庫工程領域最流行的數據倉庫建模的經典。
維度建模從分析決策的需求出發構建模型，為分析需求服務，因此它重點關注用戶如何更快速地完成需求分析，同時具有較好的大規模複雜查詢的響應性能。其典型的代表是星形模型，以及在一些特殊場景下使用的雪花模型。其設計分為以下幾個步驟。
選擇需要進行分析決策的業務過程。業務過程可以是單個業務事件，比如交易的支付、退款等；也可以是某個事件的狀態，比如當前的賬戶餘額等；還可以是一係列相關業務事件組成的業務流程，具體需要看我們分析的是某些事件發生情況，還是當前狀態，或是事件流轉效率。
選擇粒度。在事件分析中，我們要預判所有分析需要細分的程度，從而決定選擇的粒度。粒度是維度的一個組合。
識別維表。選擇好粒度之後，就需要基於此粒度設計維表，包括維度屬性，用於分析時進行分組和篩選。
選擇事實。確定分析需要衡量的指標。
Data Vault模型
Data Vault是Dan Linstedt發起創建的一種模型，它是ER模型的衍生，其設計的出發點也是為了實現數據的整合，但不能直接用於數據分析決策。它強調建立一個可審計的基礎數據層，也就是強調數據的曆史性、可追溯性和原子性，而不要求對數據進行過度的一致性處理和整合；同時它基於主題概念將企業數據進行結構化組織，並引入了更進一步的範式處理來優化模型，以應對源係統變更的擴展性。Data Vault模型由以下幾部分組成。
Hub：是企業的核心業務實體，由實體key、數據倉庫序列代理鍵、裝載時間、數據來源組成。
Link：代表Hub之間的關係。這裏與ER模型最大的區別是將關係作為一個獨立的單元抽象，可以提升模型的擴展性。它可以直接描述1:1、1:n和n:n的關係，而不需要做任何變更。它由Hub的代理鍵、裝載時間、數據來源組成。
Satellite：是Hub的詳細描述內容，一個Hub可以有多個Satellite。它由Hub的代理鍵、裝載時間、來源類型、詳細的Hub描述信息組成。
Data Vault模型比ER模型更容易設計和產出，它的ETL加工可實現配置化。通過Dan Linstedt的比喻更能理解Data Vault的核心思想：Hub可以想象成人的骨架，那麼Link就是連接骨架的韌帶，而Satellite就是骨架上麵的血肉。看如下實例（來自Data Vault Modeling Guide，作者Hans Hultgren），如圖1所示。
Anchor模型
Anchor對Data Vault模型做了進一步規範化處理，Lars. Rönnbäck的初衷是設計一個高度可擴展的模型，其核心思想是所有的擴展隻是添加而不是修改，因此將模型規範到6NF，基本變成了k-v結構化模型。我們看一下Anchor模型的組成。
Anchors：類似於Data Vault的Hub，代表業務實體，且隻有主鍵。
Attributes：功能類似於Data Vault的Satellite，但是它更加規範化，將其全部k-v結構化，一個表隻有一個Anchors的屬性描述。
Ties：就是Anchors之間的關係，單獨用表來描述，類似於Data Vault的Link，可以提升整體模型關係的擴展能力。
Knots：代表那些可能會在多個Anchors中公用的屬性的提煉，比如性別、狀態等這種枚舉類型且被公用的屬性。
在上述四個基本對象的基礎上，又可以細劃分為曆史的和非曆史的，其中曆史的會以時間戳加多條記錄的方式記錄數據的變遷曆史。
Anchor模型的創建者以此方式來獲取極大的可擴展性，但是也會增加非常多的查詢join操作。創建者的觀點是，數據倉庫中的分析查詢隻是基於一小部分字段進行的，類似於列存儲結構，可以大大減少數據掃描，從而對查詢性能影響較小。一些有數據表裁剪（Table Elimination）特性的數據庫如MariaDB的出現，還會大量減少join操作。但是實際情況是不是如此，還有待商榷。下麵是一個Anchor模型圖（來自Anchor Modeling-Agile Information Modeling in Evolving Data Environments，作者Lars. Rönnbäck），如圖2所示。
阿裏巴巴數據模型實踐綜述
阿裏巴巴集團很早就已經把大數據作為其戰略目標實施，而且其各個業務也非常依賴數據支撐運營，那麼阿裏巴巴究竟采取何種方法構建自己的數據倉庫模型呢？阿裏巴巴的數據倉庫模型建設經曆了多個發展階段。
第一個階段：完全應用驅動的時代，阿裏巴巴的第一代數據倉庫係統構建在Oracle上，數據完全以滿足報表需求為目的，將數據以與源結構相同的方式同步到Oracle（稱作ODS層），數據工程師基於ODS數據進行統計，基本沒有係統化的模型方法體係，完全基於對Oracle數據庫特性的利用進行數據存儲和加工，部分采用一些維度建模的緩慢變化維方式進行曆史數據處理。這時候的數據架構隻有兩層，即ODS+DSS。
第二個階段：隨著阿裏巴巴業務的快速發展，數據量也在飛速增長，性能成為一個較大的問題，因此引入了當時MPP架構體係的Greenplum，同時阿裏巴巴的數據團隊也在著手進行一定的數據架構優化，希望通過一些模型技術改變煙囪式的開發模型，消除一些冗餘，提升數據的一致性。來自傳統行業的數據倉庫工程師開始嚐試將工程領域比較流行的ER模型+維度模型方式應用到阿裏巴巴集團，構建出一個四層的模型架構，即ODL（操作數據層）+BDL（基礎數據層）+IDL（接口數據層）+ADL（應用數據層）。ODL和源係統保持一致；BDL希望引入ER模型，加強數據的整合，構建一致的基礎數據模型；IDL基於維度模型方法構建集市層；ADL完成應用的個性化和基於展現需求的數據組裝。在此期間，我們在構建ER模型時遇到了比較大的困難和挑戰，互聯網業務的快速發展、人員的快速變化、業務知識功底的不夠全麵，導致ER模型設計遲遲不能產出。至此，我們也得到了一個經驗：在不太成熟、快速變化的業務麵前，構建ER模型的風險非常大，不太適合去構建ER模型。
第三個階段：阿裏巴巴集團的業務和數據還在飛速發展，這時候迎來了以Hadoop為代表的分布式存儲計算平台的快速發展，同時阿裏巴巴集團自主研發的分布式計算平台MaxCompute也在緊鑼密鼓地進行著。我們在擁抱分布式計算平台的同時，也開始建設自己的第三代模型架構，這時候需要找到既適合阿裏巴巴集團業務發展，又能充分利用分布式計算平台能力的數據模型方式。我們選擇了以Kimball的維度建模為核心理念的模型方法論，同時對其進行了一定的升級和擴展，構建了阿裏巴巴集團的公共層模型數據架構體係。
數據公共層建設的目的是著力解決數據存儲和計算的共享問題。阿裏巴巴集團當下已經發展為多個BU，各個業務產生龐大的數據，並且數據每年以近2.5倍的速度在增長，數據的增長遠遠超過業務的增長，帶來的成本開銷也是非常令人擔憂的。
阿裏巴巴數據公共層建設的指導方法是一套統一化的集團數據整合及管理的方法體係（在內部這一體係稱為“OneData”），其包括一致性的指標定義體係、模型設計方法體係以及配套工具。
本文節選自《大數據之路：阿裏巴巴大數據實踐》一書，阿裏巴巴數據技術及產品部所著。
在阿裏巴巴集團內，數據人員麵臨的現實情況是：集團數據存儲已經達到EB級別，部分單張表每天的數據記錄數高達幾千億條；在2016年“雙11購物狂歡節”的24小時中，支付金額達到了1207億元人民幣，支付峰值高達12萬筆/秒，下單峰值達17.5萬筆/秒，媒體直播大屏處理的總數據量高達百億級別且所有數據都需要做到實時、準確地對外披露……巨大的信息量給數據采集、存儲和計算都帶來了極大的挑戰。《大數據之路：阿裏巴巴大數據實踐》就是在此背景下完成的。相信《大數據之路：阿裏巴巴大數據實踐》中的實踐和思考對同行會有很大的啟發和借鑒意義。
阿裏巴巴大數據-玩家社區 https://yq.aliyun.com/teams/6/
---阿裏大數據博文，問答，社群，實踐，有朋自遠方來，不亦說乎……
最後更新：2017-08-13 22:37:29