阿裡巴巴巨量資料實踐之資料建模

摘要： 隨著DT年齡互連網、智慧型裝置及其他資訊技術的發展，資料爆發式增長，如何將這些資料進行有序、有結構地分類組織和隱藏是我們面臨的一個挑戰。為什麼需要資料建模如果把資料看作圖書館裡的書，我們希望看到它們在書架上分門別類地置放；如果把資料看作城市的建築，我們希望城市規劃佈局合理；如果把資料看作電腦檔案和資料夾，我們希望按照自己的習慣有很好的資料夾組織方式，而不是糟糕混亂的桌面，經常為找一個檔案而不知所措。

隨著DT年齡互連網、智慧型裝置及其他資訊技術的發展，資料爆發式增長，如何將這些資料進行有序、有結構地分類組織和隱藏是我們面臨的一個挑戰。

如果把資料看作圖書館裡的書，我們希望看到它們在書架上分門別類地置放；如果把資料看作城市的建築，我們希望城市規劃佈局合理；如果把資料看作電腦檔案和資料夾，我們希望按照自己的習慣有很好的資料夾組織方式，而不是糟糕混亂的桌面，經常為找一個檔案而不知所措。

資料模型就是資料群組織和隱藏方法，它強調從商務、資料存取和使用角度合理隱藏資料。Linux的創始人Torvalds有一段關於“什麼才是優秀程式師”的話：“爛程式師關心的是代碼，好程式師關心的是資料結構和它們之間的關聯”，其闡述了資料模型的重要性。有了適合商務和基礎資料存放區環境的型號，那麼巨量資料就能獲得以下好處。

效能：良好的資料模型能說明我們快速查詢所需要的資料，減少資料的I/O吞吐。

成本：良好的資料模型能極大地減少不必要的資料冗餘，也能實現計算結果複用，極大地降低巨量資料系統中的隱藏和計算成本。

效率：良好的資料模型能極大地改善用戶使用資料的體驗，提高使用資料的效率。

品質：良好的資料模型能改善資料統計口徑的不一致性，減少資料計算錯誤的可能性。

因此，毋庸置疑，巨量資料系統需要資料模型方法來說明更好地組織和隱藏資料，以便在效能、成本、效率和品質之間取得最佳平衡。

E .F.Codd是關聯式資料庫的鼻祖，他首次提出了資料庫系統的關聯式模式，開創了資料庫關聯方法和關聯資料理論的研究。隨著一大批大型關聯式資料庫商務軟體（如Oracle、Informix、DB2等）的興起，現代公司資訊系統幾乎都使用關聯式資料庫來隱藏、加工和處理資料。資料倉儲系統也不例外，大量的資料倉儲系統依託強大的關聯式資料庫能力隱藏和處理資料，其採用的資料模型方法也是基於關聯式資料庫理論的。雖然近年來巨量資料的隱藏和計算基礎設施在分散式方面有了飛速的發展，NoSQL技術也曾流行一時，但是不管是Hadoop、Spark還是阿裡巴巴集團的MaxCompute系統，仍然在大規模使用SQL進行資料的加工和處理，仍然在用Table隱藏資料，仍然在使用關聯理論標題資料之間的關聯，只是在巨量資料領域，基於其資料存取的特點在關聯資料模型的範式上有了不同的選擇而已。關於範式的詳細說明和定義，以及其他一些關聯式資料庫的理論是巨量資料領域建模的基礎，有興趣的讀者可以參考相關的經典資料庫理論書籍，如《資料庫系統概念》。

OLTP系統通常面向的主要資料動作是推測讀寫，主要採用滿足3NF的實體關聯型號隱藏資料，從而在交易處理中解決資料的冗餘和一致性問題；而OLAP系統面向的主要資料動作是批量讀寫，交易處理中的一致性不是OLAP所追隨的，其主要追隨資料的整合，以及在一次性的複雜巨量資料查詢和處理中的效能，因此它需要採用一些不同的資料建模方法。

ER型號

資料倉儲之父Bill Inmon提出的建模方法是從全企業的高度設計一個3NF型號，用實體關聯（Entity Relationship，ER）型號標題企業商務，在範式理論上符合3NF。資料倉儲中的3NF與OLTP系統中的3NF的區別在於，它是站在企業角度面向主題的抽象，而不是針對某個具體商務程序的實體物件關聯的抽象。其具有以下幾個特點：

需要全面瞭解企業商務和資料。

實施週期非常長。

對建模人員的能力要求非常高。

採用ER型號建設資料倉儲型號的出發點是整合資料，將各個系統中的資料以整個企業角度按主題進行相似性群組和合併，並進行一致性處理，為資料分析決策服務，但是並不能直接用於剖析決策。

其建模步驟分為三個階段。

高層型號：一個高度抽象的型號，標題主要的主題以及主題間的關聯，用於標題企業的商務母體概況。

中層型號：在高層型號的基礎上，細化主題的資料項目。

物理型號（也叫底層型號）：在中層型號的基礎上，考慮實體儲存體，同時基於效能和平臺特點進行物理屬性的設計，也可能做一些表的合併、分區的設計等。

ER型號在實踐中最典型的代表是Teradata公司基於金融商務發佈的FS-LDM（Financial Services LogicalData Model），它通過對金融商務的高度抽象和總結，將金融商務劃分為10大主題，並以設計面向金融倉庫型號的核心為基礎，企業基於此型號做適當調整和擴充就能快速落地實施。

維度型號

維度型號是資料倉儲領域的Ralph Kimball大師所宣導的，他的The Data WarehouseToolkit-The Complete Guide to Dimensional Modeling是資料倉儲工程領域最流行的資料倉儲建模的經典。

維度建模從剖析決策的需求出發構建型號，為剖析需求服務，因此它焦點追隨用戶如何更快速地完成需求剖析，同時具有較好的大規模複雜查詢的回應效能。其典型的代表是星形型號，以及在一些特殊場景下使用的雪花型號。其設計分為以下幾個步驟。

選擇需要進行剖析決策的商務程序。商務程序可以是單個商務活動，比如交易的支付、退款等；也可以是某個活動的狀態，比如本期的帳戶餘額等；還可以是一系列相關商務活動組成的商務程序，具體需要看我們剖析的是某些活動發生情況，還是目前狀態，或是活動流轉效率。

選擇細微性。在活動剖析中，我們要預判所有剖析需要細分的程度，從而決定選擇的細微性。細微性是維度一個群組。

辨識維表。選擇好細微性之後，就需要基於此細微性設計維表，包括維度屬性，用於剖析時進行分組和篩選。

選擇事實。確定剖析需要衡量的指標。

DataVault型號

DataVault是Dan Linstedt發起建立的一種型號，它是ER型號的衍生，其設計的出發點也是為了實現資料的整合，但不能直接用於資料分析決策。它強調建立一個可審計的基礎資料層，也就是強調資料的歷史性、可追溯性和不可部分完成的作業，而不要求對資料進行過度的一致性處理和整合；同時它基於主題概念將企業資料進行結構化組織，並引入了更進一步的範式處理來優化型號，以應對源系統變更的擴充性。DataVault型號由以下幾部份組成。

Hub：是企業的核心商務實體，由實體key、資料倉儲序列專員鍵、裝載時間、資料來源組成。

Link：代表Hub之間的關聯。這裡與ER型號最大的區別是將關聯作為一個硬地的單元抽象，可以升階型號的擴充性。它可以直接標題1:1、1:n和n:n的關聯，而不需要做任何變更。它由Hub的專員鍵、裝載時間、資料來源組成。

Satellite：是Hub的詳細標題內容，一個Hub可以有多個Satellite。它由Hub的專員鍵、裝載時間、來源類型、詳細的Hub標題資訊組成。

DataVault型號比ER型號更容易設計和產出，它的ETL加工可實現設定化。通過Dan Linstedt的比喻更能理解Data Vault的核心思想：Hub可以想像成人的骨架，那麼Link就是串連骨架的韌帶，而Satellite就是骨架上面的血肉。看如下實例（來自DataVault Modeling Guide，作者HansHultgren），如圖1所示。

br />

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之間的關聯，單獨用表來標題，類似於DataVault的Link，可以升階整體型號關聯的擴充能力。

Knots：代表那些可能會在多個Anchors中公用的屬性的提煉，比如性別、狀態等這種列舉類型且被公用的屬性。

在上述四個基本物件的基礎上，又可以細劃分為歷史的和非歷史的，其中歷史的會以時間戳記加多條記錄的方式記錄資料的變遷歷史。

Anchor型號的建立者以此方式來追蹤極大的可擴充性，但是也會增加非常多的查詢join動作。建立者的觀點是，資料倉儲中的剖析查詢只是基於一小部份欄位進行的，類似於列隱藏結構，可以大大減少資料掃描，從而對查詢效能影響較小。一些有資料工作表裁切（TableElimination）屬性的資料庫如MariaDB的出現，還會大量減少join動作。但是實際情況是不是如此，還有待商榷。下面是一個Anchor型號圖（來自Anchor Modeling-AgileInformation 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/

---阿裡巨量資料博文，問答，社群，實踐，有朋自遠方來，不亦說乎……

相關產品：

1. 巨量資料計算服務(MaxCompute)