随着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萬筆/秒，媒體直播大屏處理的總資料量高達百億級别且所有資料都需要做到實時、準确地對外披露……巨大的資訊量給資料采集、存儲和計算都帶來了極大的挑戰。《大資料之路：阿裡巴巴大資料實踐》就是在此背景下完成的。相信《大資料之路：阿裡巴巴大資料實踐》中的實踐和思考對同行會有很大的啟發和借鑒意義。
<a target="_blank">---阿裡大資料博文，問答，社群，實踐，有朋自遠方來，不亦說乎……</a>
<a href="https://mp.weixin.qq.com/s?src=3&timestamp=1501743110&ver=1&signature=ceyw2jtxbdv-z1yt0vrvfd80ofzmeg6cfnreirxf-wwted1wd0fratjon19hwjqukl*10fgznqf4l7wqekmxytbgooh0*cj42n9g3d3pas7sj3nu7klueawi0gskttn7sr6s0alumgdm5lsupyqkuc6l9owfk9vhtognofth9ag=" target="_blank">原文位址csdn公衆号</a>