今天來介紹數據中臺的第二篇，第二篇共分爲三個大部分分別對應的是阿里的數據中臺三大體系(阿里的數據中臺體系架構見上一篇)，OneData體系，OneEntity體系，OneService體系，三大體系相輔相成、相互依賴，OneData體系爲基礎。這次我們把OneData體系分爲兩部分介紹，因爲OneData體系包括數據模型設計和數據資產管理兩部分，今天我們介紹OneData的數據模型篇章。
1. 煙囪式開發帶來的困擾和資源浪費
阿里的數據中臺治理主要是在2014年開始的，在2014年以前，阿里的大數據建設處於煙囪式開發狀態，這樣的開發帶來了許多業務的困擾和資源的浪費，2014數據依賴如下圖
由圖可見
數據流向會亂，無方向性的
數據管理式無序的，處於失控狀態
除了浪費研發人力和計算存儲資源、也必然滿足不了業務的需求
當然，這個問題被放大式在本身業務以極快的速度發展的前提下，這樣的開發導致的問題我們從兩個方面來看
業務困擾
在混亂的開發中，會造成諸多的數據問題，如因爲指標的定義問題，導致同一指標有多個數據，最常見的指標爲UV,總結最業務的困擾主要一下三點
數據統一：數據標準規範難（命名不規範、口徑不統一、算法不一致），數據任務響應慢，從而導致業務部門產生困擾而導致不滿
數據未打通：各個數據團隊各自爲政，存在嚴重的數據孤島現狀；缺乏數據融通，數據價值發掘不夠，從而導致業務部門看不清數據
成爲成本中心且服務化不足：數據無方向性，依賴混亂，，數據管理無序，失控，成本化嚴重，面向應用的服務化投入不足甚至缺失。
技術困擾
浪費主要分兩方面看，一方面是開發人力技術的浪費，開發人員日常在數據異常排查和數據調研上疲於奔命。另外一個是計算存儲資源的浪費，在沒有公共層的情況下，數據重複存儲和計算非常常見。簡單的總結爲一下的三點
研發苦惱：煙囪式開發週期長、效率低
維護困難:源系統乎或業務變成不能及時反應到數據上，加之數據不標準，不規範，上線難，下線更難。
時效性差：重複建設導致任務鏈路冗長、任務繁多，計算資源緊張；數據批量計算慢，時效性不強且覆蓋 業務範圍窄，即時查詢返回結果慢
2. 數據公公層建設
從上面的問題來看，數據的公共層建設是一件迫在眉睫的事情，那麼數據公共層建設到底該如何進行，建設之前又要如何準備。
這裏就是OneData體系建設數據建設篇，OneData體系的主要四個組成部分爲
規範化數據建模：規範化數據建模，特別關注數據規範定義、數據模型設計和ETL開發等全流程
規範化研發工具：用來落地和承載規範化建模的工具
數據模型數據小庫：規範化數據建模產生的所有分層數據模型的數據被統一存放在數據小庫中
面向應用的數據監控：所有的數據在面向應用是都會被監控和調用，且對上線、下線調優監控則會反饋到規範化數據建模中。
四個部分的運行圖如下
從四部分看，首先應該是執行數據建模規範，其中包括數據規範定義、數據模型設計、ETL開發規範。各個規範都有對應的規範文件輸出。
在OneDataIII體系體系中，升級了原有的體系，講數據規範定義，數據模型設計，ETL開發連在一起，時間設計即開發，所建即所得。即將數據規範定義從工具層面的數據命名+結構化抽象定義合二而一，與數據模型設計連接，進而直接影響ETL.
$\color{red}{下面是核心部分} $
也就數說數據規範定義完成之後，每一個指標都可以根據結構化明明規則和計算邏輯快速相應到對應的物理上存在的數據表中。
因此在理論上，只要某個指標能夠被規範定義（除非複雜到無法被規範定義的指標），而一系列經過規範定義的指標則會根據相同的計算粒度，彙集到若干物理上存在的表中或者邏輯上存在的表中，這樣生成的物理表或者邏輯表，其代碼都可以自動化生成。而中間生成過程則不必關心，因爲這是系統內部的只能黑盒要以智能化的方式來解決的。並且從長遠來看，只能黑盒不僅要實現代碼自動化生成，還要關注自動化生成代碼機器任務調度所對應的計算邏輯，特別是從全局來看，這些計算邏輯能不能勝於人工做法，甚至勝於人工做法
具體的OneData體系的方法論，包含三個關鍵點分別是數據倉庫規劃、數據規範定義、數據模型設計，這裏我們不介紹技術細節，後面技術細節在《大數據之路：阿里大數據實踐》一書中會重點講述。
1. 數據倉庫規劃和數據規範定義
數據規範定義是與需求分析和產品設計同時進行的工作，數據規範定義是在開發之前，以業務的視角進行數據統一和標準定義，確保計算的口徑一致，算法一致，甚至命名是規範且統一的，後續的數據模型設計和ETL開發都是在此基礎上進行的
那麼數據規範定義到底是如何實現的呢
抽象出業務板塊 我們基於對業務和數據的理解，對數據進行基於業務的抽象，這種抽象要求不會隨着業務團隊的組織架構變動而變動。例如阿里的除了公共板塊外還會劃分出如電商，金融，雲業務等板塊。
抽象出數據域 在業務板塊下面由抽象出數據域，以電商業務板塊爲例，可以抽象出交易、會員、商店、瀏覽、搜搜、廣告、公共、等不以團隊轉移的數據區域。
抽象出數業務過程 在數據域下又抽象出業務過程，例如對於交易的數據域，可以抽象出加入購物車、下單、支付、確認收貨、申請退款等。
抽象出維度 也可以在數據與下抽象出維度，訂單維度、買家維度、賣家維度、在會員數據域下抽象出會員維度等
那麼下面我們可以基於業務過程和維度，可以進一步定義一下
原子指標 例如 支付的業務過程中可以定義 ‘支付訂單金額’、'支付買家數’等原子指標，原子子表自帶算法，可解讀的中英文命名，數據類型等，並會被後續的派生指標繼承；
定義業務限定：在支付業務過程中可以定義業務限定，即最終計算派生指標的一些限制條件，入支付方式是支付寶、銀聯等
定義計算週期：計算週期是一個非常特殊的業務限定條件，例如最近1天、最近7天、最近30天，幾乎所有的最終面向業務的數據都有計算週期這個限制條件，因此其不屬於任何一個數據域下的任何一個業務過程，需要獨立定義
定義計算粒度：關於維度，如BU維度，下會定義出很多維度屬性，同時也會產生一些計算粒度
最後基於原子指標，計算週期、業務限定、計算粒度可以結構化定義出派生指標，並以繼承原子指標的數據類型、算法、以及可以解讀的中英文命名爲主，結合計算週期，業務限定和計算粒度的算法，中英文命名形成派生指標的算法，中英文命名。假派生指標是 最近30天天貓支付支付寶支付訂單金額，則原子指標是 訂單支付金額，計算週期是最近30天，業務限定是支付寶支付，計算粒度是天貓。如果釘釘最近7天天貓支付寶支付訂單金額，則只需要用同樣的方法將最近30天調整爲最近7天即可快速定義。如果此時存在指標命名一樣但結構不同，或者命名不同但結構相同，則系統會校驗並給出錯誤提示。
2. 數據模型設計
經典的數據模型有很多理論和實戰指導，但是阿里在結合自身的業務做了改進和突破
首先，數據設計模型是建立在數據規範定義的基礎上，這就從業務應用或者需求來源空值了數據模型設計的重要輸入源頭，其次，對數據迷行嚴格分層，在統一數據公共層的同事允許數據應用層百花齊放，第三 從業務和技術雙視角出發，嚴格遵循數據模型設計的高內聚低耦合的六項技術要求
1. 高內聚低耦合
主要是指從數據業務特性和訪問特性兩個角度來考慮，將業務相近或者相關的數據設計爲一個邏輯或者物理模型；將高概率同時訪問的數據放在一起，將低概率同時訪問的數據分開存儲。
2. 核心模型和拓展模型分離
建立核心模型和拓展模型體系，核心模型包括子彈支持常用的核心業務，拓展模型包括字段支持個性化和少量應用的需要，不能讓拓展模型的字段過度入侵到核心模型，以免破壞核心迷行的架構簡潔性和可維護性
3. 公共邏輯下沉及單一
越是底層公用的處理邏輯越應該在數據調用依賴的底層進行封裝與實現，不要讓公共邏輯暴露在應用層實現，不要讓公共邏輯多出同時存在。
4. 成本與性能平衡
適當的數據冗餘可換取查詢和刷新性能，不以過度冗餘與數據複製
5.數據可回滾
處理邏輯不變，在不同時間多次運行數據結果確定不變
6.一致性
具有相同含義的字段在不同的表中命名必須相同，必須使用規範定義的名稱
7.表名清晰可理解
表名需要清晰，一直，表名易與消費者理解和使用
最後增加模型架構的流程圖，不做過多解釋，歡迎點贊訂閱，多多支持！