大資料：阿里資料倉庫建模及管理體系OneData

• 面對爆炸式增長的資料，如何建設高效的資料模型和體系，對這些資料進行有序和有結構地分類組織和存盤，避免重復建設和資料不一致性，保證資料的規范性，一直是大資料系統建設不斷追求的方向，

• 資料倉庫模型實施程序：

1. 首先，在建設大資料資料倉庫時，要進行充分的業務調研和需求分析，這是資料倉庫建設的基石，業務調研和需求分析做得是否充分直接決定了資料倉庫建設是否成功；
2. 其次，進行資料總體架構設計，主要根據資料域對資料進行劃分；按照維度建模理論，構建總線矩陣、抽象出業務程序和維度；
3. 再次，對報表抽象整理出相關指標體系，使用 OneData 工具完成指標規范定義和模型設計；
4. 最后，代碼研發和運維；

一、概述

• 阿里大資料建設方法論的核心：從業務架構設計到模型設計，從資料研發到資料服務，做到資料可管理化、可追溯、可規避重復建設；

1、定位及價值

• 建設統一的，規范的資料接入層（ODS）和資料中間層（DWD 和DWS），通過資料服務和資料產品，完成服務于阿里的大資料系統建設，即資料公共層建設，提供標準化的（Standard）、共享的（Shared）、資料服務（Service）能力，降低資料互通成本，釋放計算、存盤、人力等資源，以消除業務和技術之痛；

2、體系架構

• 業務板塊：根據業務屬性，將業務劃分出幾個相對獨立的板塊，使業務板塊之間的指標或業務重疊性較小 ；
• 規范定義：結合行業的資料倉庫建設經驗和阿里資料自身特點，設計出的一套資料規范命名體系，規范定義將會被用在模型設計中；
• 模型設計：以維度建模理論為基礎，基于維度建模總線架構，構建一致性的維度和事實（進行規范定義），同時，在落地表模型時，基于阿里自身業務特點，設計一套規范命名體系；

二、規范定義

• 規范定義指以維度建模作為理論基礎，構建總線矩陣，劃分和定義資料域、業務程序、維度、定量/原子指標、修飾型別、修飾詞、時間周期、派生指標，

• 

1、名詞術語

• 資料域：指面向業務分析，將業務程序或維度進行抽象的集合，

1. 將業務程序的一個個不可拆分的行為事件，如下單、支付等行為，進行分類，每一類行為事件的集合為一個資料域；
2. 資料域需要抽象提煉，并且長期維護和更新，但不能輕易變動；
3. 劃分資料域時（即對行為事件分類），要既能涵蓋當前所有的業務需求，又能在新業務進入時無影響地被包含進已有的資料域中和擴展新的資料域；

• 業務程序：指企業的業務活動事件，如下單、支付、退款都是業務程序；

1. 業務程序是一個不可拆分的行為事件，業務程序就是企業活動中的事件；

• 時間周期：用來明確資料統計的時間范圍或時間點；（如最近30天、自然周、截止當日等）
• 修飾型別：對修飾詞的抽象劃分；（比如，修飾詞花唄，它的修飾型別是支付方式）
• 修飾詞：隸屬于修飾型別，是指除了統計維度以外指標的業務場景的限定抽象；（如在修飾型別支付方式下：花唄、賬戶余額、余額寶、銀行卡，都是修飾詞）
• 度量 / 原子指標：度量和原子指標含義相同，對某一業務行為（或業務程序中的不可拆分的行為事件）的度量（如，花唄，花了多少錢，具體的金額數值就是度量）；

1. 度量 / 原子指標是業務定義中不可拆分的指標，具有明確業務含義的名詞；

• 維度：是度量的環境，用來反映業務的一類屬性（如，維度訂單，是交易域下的一類屬性），這類屬性的集合構成一個維度，也可稱為物體物件；

1. 維度屬于一個資料域；
2. 例1：地理維度，其中包含國家、地區、城市、大山、河流等，所有物體的位置資訊的集合，稱為地理維度；
3. 例2：時間維度，其中包含年、季、月、周、日、時等；

• 維度屬性：隸屬于一個維度，如地理維度里面的國家名稱、國家 ID、省份名稱等，都屬于維度屬性；
• 派生指標：派生指標 = 一個原子指標 + 多個修飾詞（可選）+ 時間周期；

1. 例：原子指標：支付金額，最近 1 天海外買家支付金額則為派生指標（最近 1 天為時間周期，海外為修飾詞，買家作為維度，而不作為修飾詞）

2、指標體系

　1）基本原則

　 1/1 組成體系之間的關系

1. 派生指標有原子指標、時間周期修飾詞、若干其他修飾詞組合得到；（見圖 9.3）
2. 原子指標、修飾型別及修飾詞，直接歸屬在業務程序下，其中修飾詞繼承修飾型別的資料域；
3. 派生指標可以選擇多個修飾詞，修飾詞之間的關系為“或”或者“且”，由具體的派生指標語意決定；
4. 派生指標唯一歸屬一個原子指標，繼承原子指標的資料域，與修飾詞的資料域無關；
5. 原子指標有確定的英文欄位名、資料型別和演算法說明；派生指標要繼承原子指標的英文名、資料型別和演算法要求；

　 1/2 命名約定

1. 命名所用術語：指標命名，盡量使用英文簡寫，其次是英文，當指標英文名太長時，可考慮用漢語拼音首字母命名（如中國制造用 zgzz），
2. 業務程序：英文名：用英文或英文的縮寫或者中文拼音簡寫；中文名：具體業務程序中文即可；
3. 原子指標：英文名：動作 + 度量；中文名：動作 + 度量；原子指標必須掛靠在某個業務程序下；
4. 修飾詞：只有時間周期才會有英文名，且長度為 2 位，加上 “-” 為 3 位（例 _1d ），其它修飾詞無英文名；
5. 派生指標：英文名：原子指標英文名 + 時間周期修飾詞（3 位）+ 序號（4 位，如 “_001”）；中文名：時間周期修飾詞 + [ 其它修飾詞 ] + 原子指標；

　 1/3 演算法

• 原子指標、修飾詞、派生指標的演算法說明必須讓各種使用人員看得明白，包括：

1. 演算法概述：演算法對應的用戶容易理解的闡述；
2. 舉例：通過具體例子幫助理解指標演算法；
3. SQL 演算法說明：對于派生指標給出 SQL 的寫法或者偽代碼；

　2）操作細則

　 2/1 派生指標的種類

• 派生指標可以分為三類：事務型指標、存量型指標、復合型指標；（按照特性不同，有些需要新建原子指標，有些可以在其他型別原子指標的基礎上增加修飾詞形成派生指標）

1. 事務型指標：是指對業務活動進行衡量的指標；（例：新發商品數、重發商品數、新增注冊會員數，這類指標需要維護原子指標及修飾詞，在此基礎上創建派生指標）
2. 存量型指標：是指對物體物件（如商品、會員）某些狀態的統計；（例：商品總數、注冊會員總數，這類指標需要維護原子指標及修飾詞，在此基礎上創建派生指標，對應的事件周期一般為 “歷史載至當前某個時間”）
3. 復合型指標：是在事務型指標和復合型指標的基礎上復合而成的；（例：瀏覽 UV - 下單買家數轉化率，有些需要創建新原子指標，有些則可以在事務型或存量型原子指標的基礎上增加修飾詞得到派生指標）

　 2/2 復合型指標的規則

• 比率型：創建原子指標，如 CTR、瀏覽 UV - 下單買家數轉化率、滿意率等；

1. 例：“最近 1 天店鋪首頁 CTR（點擊率）”，原子指標為 “CTR”，時間周期為 “最近 1 天”，修飾型別為 “頁面型別”，修飾詞為 “店鋪首頁”；

• 比例型：創建原子指標，如百分比、占比；

1. 例：“最近 1 天無線支付金額占比”，原子指標為 “支付金額占比”，修飾型別為 “終端型別”，修飾詞為 “無線”；

• 變化量型：不創建原子指標，增加修飾詞，在此基礎上創建派生指標；

1. 例：“最近 1 天訂單支付金額上 1 天變化量”，原子指標為 “訂單支付金額”，時間周期為 “最近 1 天”，修飾型別為 “統計方法”，修飾詞為 “上 1 天變化量”；

• 變化率型：創建原子指標；

1. 例：“最近 7 天海外買家支付金額上 7 天變化率”，原子指標為 “支付金額變化率”，修飾型別為 “買家地域”（因為此需求中重點強調“海外買家”），時間周期為 “最近 7 天”，修飾詞為 “海外買家”；

• 統計型（均值、分位數）：不需要創建原子指標，增加修飾詞，在此基礎上創建派生指標；

1. 在修飾型別 “統計方法” 下增加修飾詞，如人均、日均、行業平均、商品平均、90 分位數、70分位數等；
2. 例：“自然月日均 UV（訪問量）”，原子指標為 “UV”，修飾型別為 “統計方法”，修飾詞為 “日均”；

• 排名型：創建原子指標，一般為 top_xxx_xxx ，有時會同時選擇 rank 和 top_xxx_xxx 組合使用；創建派生指標時選擇對應的修飾詞如下：

1. 統計方法（如降序、升序）
2. 排名名次（如 TOP10）
3. 排名范圍（如行業、省份、一級來源等）
4. 根據什么排序（如搜索次數、PV）

5. 

• 物件集合型：主要指資料產品和應用需要展現資料時，將一些物件以 k-v 對的方式存盤在一個欄位中，方便前端展現，比如趨勢圖、TOP 排名物件等，其定義方式是，創建原子指標，一般為 xxx 串；創建派生指標時選擇對應的修飾詞如下：

1. 統計方法（如降序、升序）
2. 排名名次（如 TOP10）
3. 排名范圍（如行業、區域）

4. 

　3）其他規則

• 上下層級同時存在時：如最近 1 天支付金額和最近 1 天 PC 端支付金額，建議使用前者，把 PC 端最為維度屬性存放在物理表中體現；
• 父子關系原子指標存在時：派生指標使用子原子指標創建派生指標；（如 PV、IPV（商品詳情頁 PV），當統計商品詳情頁 PV 時，優先選擇子原子指標）

三、模型設計

1、知道理論

• 資料模型的維度設計主要以維度建模理論為基礎，基于維度資料模型總線架構，構建一致性的維度和事實；

2、模型層次

• 主要分三層：操作資料層（ODS）、公共維度資料層（CDM）、應用資料層（ADS）；

• 

• 其中 CDM 資料層包括明細資料層（DWD）和匯總資料層（DWS）；

• 操作資料層（ODS）：把作業系統資料幾乎無處理的存放子資料倉庫系統中；

1. 同步：結構化資料增量或全量同步到 MaxCompute；
2. 結構化：非結構化（日志）結構化處理并存盤到 MaxCompute ；
3. 累積歷史、清洗：根據資料業務需求及稽核和審計要求保存歷史資料、清洗資料；

• 公共維度模型層（CDM）：存放明細事實資料、維表資料及公共指標匯總資料，其中明細事實資料、維表資料一般根據 ODS 層資料架構生成；公共指標匯總資料一般根據維表資料和明細事實資料加工生成；
• CDM 層又細分為 DWD 層和 DWS 層，分別是明細資料層和匯總資料層，采用維度模型方法作為理論基礎，采用一些維度退化手法，將維度退化至事實表中，減少事實表和維表的關聯，提高明細資料表的易用性；同時在匯總資料層，加強指標的維度退化，采取更多的寬表化手段構建公共指標資料層，提升公共指標的復用性，減少重復加工；

• 主要功能：

1. 組合相關和相似資料：采用明細寬表，復用關聯計算，減少資料掃描；
2. 公共指標統一加工：基于 OneData 體系構建命名規則、口徑一致和演算法統一的統計指標，為上層資料產品、應用和服務提供公共指標；建立邏輯匯總寬表；
3. 建立一致性維度：建立一致的資料分析維表，簡單資料計算口徑、演算法不統一的風險；

• 應用資料層（ADS）：存放資料產品個性化的統計指標資料，根據 CDM 層與 ODS 層加工；

1. 個性指標加工：不公用性、復雜性（指數型、比值型、排名型指標）；
2. 基于應用的資料組裝：大寬表集市、橫表轉縱表、趨勢指標串；

• 

• 資料呼叫服務優先使用公共維度模型層（CDM）資料，當公共層沒有資料時，需評估是否需要創建公共層資料，當不需要建設公用的公共層時，方可直接使用操作資料層（ODS）資料；
• 應用資料層（ADS）作為產品特有的個性化資料一般不對外提供資料服務，但是 ADS 作為被服務方也需要遵守上述（條件 1）約定；

3、基本原則

1. 高內聚和低耦合：將業務相近或者相關、粒度相同的資料設計為一個邏輯或者物理模型；將高概率同時訪問的資料放一起，將低概率同時訪問的資料分開存盤；
2. 核心模型與擴展模型分離：核心模型包括的欄位支持常用的核心業務，擴展型包括的欄位支持個性化或少了應用的需要，不能讓擴展模型的欄位過多侵入核心模型，以免破壞核心模型的架構簡潔性與可維護性；
3. 公共處理邏輯下沉及單一：越是底層公用的處理邏輯越應該在資料調度依賴的底層進行封裝與實作，不要讓公用的處理邏輯暴露給應用層實作，不要讓公共邏輯多處同時存在；
4. 成本與性能平衡：適當的資料冗余可以換錢查詢和重繪性能，不宜過度冗余與資料復制；
5. 資料可回滾：處理邏輯不變，在不同時間多次運行資料結果確定不變；
6. 一致性：具有相同含義的欄位在不同表中的命名必須相同，必須使用規范定義中的名稱；
7. 命名清晰、可理解：表名需易于消費者理解和使用；

四、模型實施

• 如何從具體的需求或專案轉換為可實施的解決方案，如何進行需求分析、架構設計、詳細模型設計等，則是模型實施程序中討論的內容；

1、業界常用的模型實施程序

　1/1）Kimball 模型實施程序

• Kimball 維度建模主要討論需求分析、高層模型、詳細模型和模型審查整個程序；
• 構建維度模型主要經歷 4 個階段：

　　1/1/1）高層模型設計

• 定義業務程序維度模型的范圍，提供每種星形模式的技術和功能描述；
• 產出目標：創建高層維度模型圖，是對業務程序中的維表和事實表的圖形描述；
• 確定維表創建初始屬性串列，為每個事實表的創建提議度量；

　　1/1/2）詳細模型設計

• 對每個星形模型添加屬性和度量資訊；
• 詳細的維度建模程序是為高層模型填補缺失的資訊，解決設計問題，并不斷測驗模型能否滿足業務需求，確保模型的完備性；
• 確定每個維表的屬性和每個事實表的度量，并確定資訊來源的位置、定義，確定屬性和度量如何填入模型的初步業務規則；

　　1/1/3）模型審查、再設計和驗證

• 主要召集相關人員進行模型的審查和驗證，根據審查結果對詳細維度進行再設計；

　　1/1/4）提交 ETL 設計和開發

• 完成模型詳細設計檔案，提交給 ETL 開發人員，進入 ETL 設計和開發階段，由 ETL 人員完成物理模型的設計和開發；

　1/2）Inmon 模型實施程序

• Inmon 對資料模型的定位：扮演著通往資料倉庫其他部分的智能路線圖的角色；（建立一個路線圖——資料模型，描述資料倉庫各部分是如何結合在一起的）

• Inmon 將模型分為 3 個層次：ERD（Entity Relationship Diagram，物體關系圖）層、DIS（Data Item Set，資料項集）層、物理層（Physical Model，物理模型）；

• ERD 層是資料模型的最高層，描述公司業務中的物體或主題域以及他們之間的關系；

• DIS 層是資料模型的中間層，描述資料模型的關鍵字、屬性以及細節資料之間的關系；

• 物理層是資料模型的最底層，描述資料模型的物理特性；

• Inmon 對于構建資料倉庫模型建議采用螺旋式開發方法，采用迭代方式完成多次需求；但需要采用統一的 ERD 模型，才能夠將每次迭代的結果整合在一起；

• ERD 模型是高度抽象的資料模型，描述企業完整的資料，而每次迭代則是完成 ERD 模型的子集，通過 DIS 和物理資料模型實作；

　1/3）其他模型實施程序

1. 業務建模，生成業務模型，主要解決業務層面的分解和程式化；
2. 領域建模，生成領域模型，主要是對業務模型進行抽象處理，生成領域概念模型；
3. 邏輯建模，生成邏輯模型，主要將領域模型的概念物體以及物體之間的關系進行資料庫層次的邏輯化；
4. 物理建模，生成物理模型，主要解決邏輯模型針對不同關系資料庫的物理化以及性能等一些具體的技術問題；

2、OneData 實施程序

　2/1）指導方針

• 首先，在建設大資料資料倉庫時，要進行充分的業務調研和需求分析，這是資料倉庫建設的基石，業務調研和需求分析做得是否充分直接決定了資料倉庫建設是否成功；
• 其次，進行資料總體架構設計，主要根據資料域對資料進行劃分；按照維度建模理論，構建總線矩陣、抽象出業務程序和維度；
• 再次，對報表抽象整理出相關指標體系，使用 OneData 工具完成指標規范定義和模型設計；
• 最后，代碼研發和運維；

　2/2）實施作業流

　　2/2/1）資料調研

• 業務調研

1. 不但只了解具體的需求，還要明白需求的資料在業務中的意義，幫助我們更好的建倉建模，特別是在劃分資料域時；
2. 了解各個業務領域、業務線的業務有什么共同點和不同點，以及各個業務線可以細分為那幾個業務模塊，每個業務模塊具體的業務流程有事怎樣的；
3. 一般各個業務領域獨自建設資料倉庫，業務領域內的業務線由于業務相似、業務相關性較大，進行統一集中建設；

• 例：

  

• 需求調研

1. 收集資料使用者的需求；（可以找分析師、業務運營人員了解他們有什么資料訴求，一般更多的就是報表需求）
2. 需求調研的兩種途徑：一是與分析師、業務運營人員的溝通（郵件、IM）獲知需求；二是對報表系統中現有的報表進行研究分析；（很多時候，都是由具體的資料需求驅動資料倉庫團隊去了解業務系統的業務資料）

• 例：分析師需要了解大淘寶（淘寶、天貓、天貓國際）一級類目的成交金額

• 獲知需求后，需要考慮的問題：

1. 根據什么（維度）匯總，匯總什么（度量 / 原子指標）？（這里類目是維度，金額是度量）
2. 明細資料和匯總資料應該怎么設計？
3. 這是一個公用的報表嗎？
4. 是需要沉淀到匯總表里面，還是在報表工具中進行匯總？

　　2/2/2）架構設計

• 資料域劃分（將各個業務行為分類）

• 資料域：指面向業務分析，將業務程序或者維度進行抽象的集合；
• 業務程序可以概括為一個個不可拆分的行為事件，如下單、支付、退款；
• 為保障整個體系的生命力，資料域需要抽象提煉，并且長期維護和更新，但不輕易變動；

• 劃分資料域原則：既能涵蓋當前所有的業務需求，又能在新業務進入時無影響地被包含進已有的資料域中，或者擴展新的資料域；

• 例（將業務行為分類劃分資料域）：

• 

• 

• 構建總線矩陣

• 明確每個資料域下有哪些業務程序；
• 業務程序與哪些維度相關，并定義每個資料域下的業務程序和維度；
• 例（構建采購分銷資料域的總線矩陣）：

• 

　2/3）規范定義

• 主要定義指標體系，包括原子指標、修飾詞、時間周期、派生指標；

　2/4）模型設計

• 主要包括維度及屬性的規范定義，維表、明細事實表、匯總事實表的模型設計；

　2/5）總結

• OneData 的實施程序是一個高度迭代和動態的程序，一般采用螺旋式實施方法；
• 在總體架構設計完成后，開始根據資料域進行迭代式模型設計和評審；
• 在架構設計、規范定義、模型設計等模型實施程序中，都會引入評審機制，以確保模型實施程序的正確性；