目錄
一、起因
據IDC報告，預計到2020年全球數據總量將超過40ZB(相當於4萬億GB)，這一數據量是2013年的10倍。正在“爆炸式”增長的數據的潛在巨大價值正在被髮掘，它有可能成爲商業世界的“新能源”，變革我們的生產，影響我們生活。當我們面對如此龐大的數據之時，如果我們不能有序、有結構的進行分類組織和存儲，那麼在價值被發現前，也許數據成本災難已經來臨。它猶如堆積如山的垃圾，給我們企業帶來的是極大的成本，而且非常難以消費和發掘價值，也許數據更可悲的命運是在價值發現之前它以死去。不得已的歷史數據清理還在進行中嗎？
那麼，企業大數據體系的數據架構應該如何建立？如何保障數據快速支撐業務並且驅動業務發展？在2016數據庫技術大會上，數據中臺的高級技術專家王賽結合阿里數據的實踐成果，按照背景、方法思路以及如何落地實現、效果如何的邏輯，爲大家詳細介紹阿里數據中臺的祕密武器——OneData體系。
二、背景
在企業發展初期，數據研發模式一般緊貼業務的發展而演變的，數據體系也是基於業務單元垂直建立，不同的垂直化業務，帶來不同的煙囪式的體系。但隨着企業的發展，一方面數據規模在快速膨脹，垂直業務單元也越來越多，另一方面基於大數據的業務所需要的數據不僅僅是某個垂直單元的，使用數據類型繁多(Variety)的數據才能具備核心競爭力。跨垂直單元的數據建設接踵而至，混亂的數據調用和拷貝，重複建設帶來的資源浪費，數據指標定義不同而帶來的歧義、數據使用門檻越來越高……這些問題日益凸顯，成爲企業發展迫在眉睫必須要解決的問題。
1）數據標準不統一
在建立OneData之前，阿里數據有30000多個指標，其中，即使是同樣的命名，但定義口徑卻不一致。例如，僅uv這樣一個指標，就有十幾種定義。帶來的問題是：都是uv，我要用哪個？ 都是uv，爲什麼數據卻不一樣？
2）服務業務能力
由於數據模式是跟着垂直業務，導致一開始只支持了淘寶、天貓、1688等少數業務團隊。而更多有個性化需求的業務團隊卻無法提供更多支持。
3）計算存儲成本
由於沒有統一的規範標準管理，造成了重複計算等資源浪費。而數據表的層次、粒度不清晰，也使得重複存儲嚴重，僅淘系的數據表就超過了25000張，集團總數據的存儲量每年以2.5倍的速度在增長，可以預見的未來的將會帶來巨大的數據成本負擔，我們不得不去做一些改變。
4）研發成本
每個工程師都需要從頭到尾瞭解研發流程的每個細節，對同樣的“坑”每個人都會重新踩一遍，對研發人員的時間和精力成本造成浪費
建立的方法和思路
基於這樣的問題和挑戰，阿里集團規劃建設一個全集團的全域數據公共層，將公共的數據、計算沉澱於此，降低數據存儲和計算成本，提升數據互通和消費的效率，從而支撐快速數據業務應該的創新。公共層中重要的一環是數據模型的構建，那麼我們先從行業看看一些方法體系和經驗：
三、他山之石——行業內是如何做的？
A、實體關係（ER）模型
數據倉庫之父Immon的方法從全企業的高度設計一個3NF模型，用實體加關係描述的數據模型描述企業業務架構，在範式理論上符合3NF，它與OLTP系統中的3NF的區別，在於數據倉庫中的3NF上站在企業角度面向主題的抽象，而不是針對某個具體業務流程的實體對象關係抽象，它更多的是面向數據的整合和一致性治理，正如Immon所希望達到的：“single version of the truth”。但是要採用此方法進行構建，也有其挑戰：
- 需要全面瞭解企業業務和數據
- 實施週期非常長
- 對建模人員的能力要求也非常高
B、維度模型
維度模型是數據倉庫領域另一位大師Ralph Kimall所倡導，它的《The DataWarehouse Toolkit-The Complete Guide to Dimensona Modeling》是數據倉庫工程領域最流行的數倉建模經典。
維度建模以分析決策的需求出發構建模型，構建的數據模型爲分析需求服務，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應性能。典型的代表是我們比較熟知的星形模型，以及在一些特殊場景下適用的雪花模型。
C、DataVault
DataVault是Dan Linstedt發起創建的一種模型方法論，它是在ER關係模型上的衍生，同時設計的出發點也是爲了實現數據的整合，並非爲數據決策分析直接使用。它強調建立一個可審計的基礎數據層，也就是強調數據的歷史性可追溯性和原子性，而不要求對數據進行過度的一致性處理和整合；同時也基於主題概念將企業數據進行結構化組織，並引入了更進一步的範式處理來優化模型應對源系統變更的擴展性。它主要由：Hub（關鍵核心業務實體）、Link（關係）、Satellite（實體屬性）三部分組成 。
D、Anchor模型
Anchor模型是由Lars. Rönnbäck設計的，初衷是設計一個高度可擴展的模型，核心思想：所有的擴展只是添加而不是修改，因此它將模型規範到6NF，基本變成了K-V結構模型。Anchor模型由：Anchors 、Attributes 、Ties 、Knots 組成，相關細節可以參考《Anchor Modeling-Agile Information Modeling in Evolving Data Environments》
四、阿里的數倉模型體系要如何構建？
阿里巴巴集團在很早就已經把大數據做爲戰略目標實施，而且其各個業務也非常依賴數據支撐運營，那麼阿里究竟採取何種方法構建自己的體系？阿里的數據倉庫模型建設經歷的多個發展週期：
第一階段：
完全應用驅動的時代，阿里巴巴第一代的數據倉庫系統構建在Oracle上，數據完全以滿足報表需求爲目的出發，將數據以與源結構相同的方式同步到Oracle後，我們叫ODS（Operational Data Store）層，數據工程師基於ODS數據進行統計，基本沒有模型方法體系，完全基於對Oralce數據庫特性的利用進行數據存儲和加工，部分採用了一些維度建模的緩慢變化維方式進行歷史數據處理。那時候的數據架構只有兩次層ODS+DSS。
第二階段：
隨着阿里業務的快速發展，數據量也在飛速增長，性能已經是一個較大問題，因此引入了當時MPP架構體系的Greenplum，同時阿里的數據團隊也在着手開始進行一定的數據架構優化，希望通過一些模型技術改變煙囪式的開發模型，消除一些冗餘，提升數據的一致性。來做傳統行業數倉的工程師，開始嘗試將工程領域比較流行的ER模型+維度模型方式應用的阿里集團，構建出一個四層的模型架構ODL（操作數據層）+BDL(基礎數據層)+IDL（接口數據層）+ADS(應用數據層)。ODL保持和源系統保持一致，BDL希望引入ER模型，加強數據的整合，構建一致的基礎數據模型，IDL基於維度模型方法構建集市層，ADL完成應用的個性化和基於展現需求的數據組裝。其中我們在構建ER模型遇到了比較大的困難和挑戰，互聯網業務的快速發展，人員的快速迭代變化，業務知識功底的不夠全面導致ER模型設計遲遲不能產出，至此，我們也得到了一個經驗，在一個不太成熟，快速變化的業務面前，構建ER模型的風險非常大，不太適合去構建。
第三階段：
阿里集團的業務和數據還在飛速發展，這個時候迎來了以hadoop爲代表的分佈式存儲計算平臺的快速發展，同時阿里集團自主研發的數加大規模計算服務MaxCompute（原ODPS）也在緊鑼密鼓的進行中；我們在擁抱分佈式計算平臺的同時，也開始建設我們的第三代模型架構，我們需要找到一個核心問題，找打適合阿里集團業務發展，又能充分利用分佈是計算平臺能力的數據模型方式。
我們選擇了以Kimball的維度建模爲核心理念基礎的模型方法論，同時對其進行了一定的升級和擴展，構建了阿里集團的數據架構體系——OneData
OneData體系分爲：數據規範定義體系、數據模型規範設計、ETL規範研發以及支撐整個體系從方法到實施的工具體系。
落地實現
A）數據規範定義
將此前個性化的數據指標進行規範定義，抽象成：原子指標、時間週期、其他修飾詞等三個要素。
例如，以往業務方提出的需求是：最近7天的成交。而實際上，這個指標在規範定義中，應該結構化分解成爲：
原子指標（支付訂單金額 ）+修飾詞-時間週期（最近7天）+修飾詞-賣家類型（淘寶）
B）數據模型架構
將數據分爲ODS（操作數據）層、CDM（公共維度模型）層、ADS（應用數據）層。
其中：
ODS層主要功能
這裏先介紹一下阿里雲數加大數據計算服務MaxCompute，是一種快速、完全託管的TB/PB級數據倉庫解決方案，適用於多種數據處理場景，如日誌分析，數據倉庫，機器學習，個性化推薦和生物信息等。
- 同步：結構化數據增量或全量同步到數加MaxCompute（原ODPS）；
- 結構化：非結構化(日誌)結構化處理並存儲到MaxCompute（原ODPS）；
- 累積歷史、清洗：根據數據業務需求及稽覈和審計要求保存歷史數據、數據清洗；
CDM層主要功能
CDM層又細分爲DWD層和DWS層，分別是明細寬表層和公共彙總數據層，採取維度模型方法基礎，更多采用一些維度退化手法，減少事實表和維度表的關聯，容易維度到事實表強化明細事實表的易用性；同時在彙總數據層，加強指標的維度退化，採取更多寬表化的手段構建公共指標數據層，提升公共指標的複用性，減少重複的加工。
ADS層主要功能
- 個性化指標加工：不公用性；複雜性（指數型、比值型、排名型指標）
- 基於應用的數據組裝：大寬表集市、橫錶轉縱表、趨勢指標串
其模型架構圖如下，阿里通過構建全域的公共層數據，極大的控制了數據規模的增長趨勢，同時在整體的數據研發效率，成本節約、性能改進方面都有不錯的結果。
C）研發流程和工具落地實現
將OneData體系貫穿於整個研發流程的每個環節中，並通過研發工具來進行保障。
實施效果
- 數據標準統一：數據指標口徑一致，各種場景下看到的數據一致性得到保障
- 支撐多個業務，極大擴展性：服務了集團內部45個BU的業務，滿足不同業務的個性化需求
- 統一數據服務：建立了統一的數據服務層，其中離線數據日均調用次數超過22億；實時數據調用日均超過11億
- 計算、存儲成本：指標口徑複用性強，將原本3型分層0000多個指標精簡到3000個；模、粒度清晰，數據表從之前的25000張精簡到不超過3000張。
- 研發成本：通過數據分域、模型分層，強調工程師之間的分工和協作，不再需要從頭到尾每個細節都瞭解一遍，節省了工程師的時間和精力。