阿里巴巴大數據實踐之數據建模

Submitted by zhongzhimin on Mon, 07/31/2017 - 15:40
大數據建模

隨著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就是骨架上面的血肉??慈缦聦嵗▉碜訢ata Vault Modeling Guide,作者Hans Hultgren),如圖1所示。

?

1

圖1 ?Data Vault模型實例

?

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所示。

?

2

圖2 ?Anchor模型圖

?

阿里巴巴數據模型實踐綜述

?

阿里巴巴集團很早就已經把大數據作為其戰略目標實施,而且其各個業務也非常依賴數據支撐運營,那么阿里巴巴究竟采取何種方法構建自己的數據倉庫模型呢?阿里巴巴的數據倉庫模型建設經歷了多個發展階段。

?

第一個階段:完全應用驅動的時代,阿里巴巴的第一代數據倉庫系統構建在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”),其包括一致性的指標定義體系、模型設計方法體系以及配套工具。

Tags

冯仰妍破处门