一、為什麼需要模組化
資料模型就是資料組織和存儲方法，它強調從業務、資料存取和使用角度合理存儲資料。
合理的資料模型：
性能：快速查詢所需要的資料，減少資料的吞吐。
成本：極大地減少不必要的資料備援，也能實作計算結果複用，極大地降低大資料系統中的存儲和計算成本。
效率：極大地改善使用者使用資料的體驗，提高使用資料的效率。
品質：良改善資料統計口徑的不一緻性，減少資料計算錯誤的可能性。
二、模型設計
操作資料層(ODS)、明細資料層(DWD)、彙總資料層(DWS)、次元表(DIM)、應用資料層(ADS)
操作資料層：把作業系統資料幾乎無處理地存放在資料倉庫系統中。
明細資料層：采用些次元退化手法，将次元退化至事實表中，減少事實表和維表的關聯，提高明細資料易用性;
彙總資料層：基于OneData體系建構命名規範、口徑和算法統一的統計名額，為上層資料産品、應用和服務提供公共名額建立邏輯彙總寬表。
加強名額的次元退化，采取更多的寬表手段建構公共名額資料層，提升公共名額的複用性，減少重複加工;
應用資料層：存放資料産品個性化的統計名額資料，根據CDM層與ODS層加工生成；個性化名額加工：不公用性、複雜性(指數型、比值型、排名型名額)。
基于應用的資料組裝 大寬表集市、橫表轉縱表、趨勢名額串；
資料調用服務優先使用公共次元模型層(CDM)資料，當公共層沒有資料時，需評估是否需要建立公共層資料，當不需要建設公用的公共層時，
方可直接使用操作資料層(ODS)資料。應用資料層(ADS)作為産品特有的個性化資料一般不對外提供資料服務，但是ADS作為被服務方也需要遵守這個約定。
三、OneData 實施工作流
1.資料調研：業務調研(了解業務)、需求調研(需求溝通、報表需求)
2.架構設計: 資料域劃分(面向分析，将業務過程\次元抽象)、建構總線矩陣(每個資料域包含哪些業務過程、及業務過程涉及的次元)、
3.規範定義：定義名額體系(原子名額、修飾詞、時間周期、派生名額)
4.模型涉及: 次元及屬性、維表及事實表模型設計
四、維表的設計
1.确定次元屬性的提示：
盡可能生成豐富的次元屬性
盡可能多給出一些富有意義的文字描述
區分數值型屬性和事實
盡量沉澱出通用的次元屬性(淘寶商品的 property 字段，使用 key:value 方式存儲多個商品屬性)
2.次元反範式化
将次元的屬性層次合并到單個次元中的操作稱為反規範化。分析系統的主要目的是用于資料分析和統計，
如何更友善使用者進行統計分析決定了分析系統的優劣。采用雪花模式，使用者在統計分析的過程中需要量的關聯操作，
使用複雜度高，同時查詢性能很差；而采用反規範化處理，則友善、易用且性能好。
3.次元整合
3.1 采用主從表的設計方式，将兩個表或多個表都有的字段放在主表中(主要基本資訊),從屬資訊分别放在各自的從表中。
3.2 對于主表中的主鍵，要麼采用複合主鍵、源主鍵和系統或表差別标志：要麼采用唯一主鍵、"源主鍵和系統或表差別标志"
生成新的主鍵。通常建議采用複合主鍵的方式。
3.3 不合并，因為源表的表結構及主鍵等差異很大，無法合并。
4.遞歸層次
按照層級是否固定分為均衡層次結構和非均衡層次結構。
1. 層次結構扁平化
類目名稱
類目層級
一級類目ID
一級類目名稱
二級類目ID
二級類目名稱
三級類目ID
三級類目名稱
四級類目ID
四級類目名稱
五級類目ID
五級類目名稱
是否葉子類日
2.層次橋接表
父關鍵字
子關鍵字
父層數
層級間隔
層名
底端辨別
頂端辨別
5.行為次元(事實次元)
如賣家主營類目次元、主營品牌次元，通過賣家的商品分布和交易分布情況，采用算法計算得到。
類似的次元，都和事實相關，如交易、物流等，稱之為"行為次元"，或"事實衍生的次元"。
分類：
另外一個次元的過去行為，如賣家/買家最近一次通路/交易時間。
快照事實行為次元，買家從年初直接交易金額、買家信用分值、賣家信用分值等。
分組事實行為次元，将數值型轉換為枚舉項，如買家年初至今交易金額等級、買家信用分值劃分信用等級。
複雜邏輯事實行為次元，通過算法加工多個事實表綜合加工得到。比如商品熱度根據通路、收藏、加入購物車、交易等綜合計算得到。
行為次元，兩種處理方式：
将其備援至現有的次元表中，比如賣家信用等級備援至賣家次元表中。
加工成單獨的行為次元表，比如賣家主營類目。
具體采用哪種方式參考以下原則：
第一、避免次元過快增長。第二避免耦合度過高(ETL邏輯複雜，維護性差、産出延遲)。
6.多值次元
一種情況是事實表的一條記錄在某維表中有多條記錄與之對應。比如淘寶訂單，一筆訂單有多件商品。
常見三種處理方式：
降低事實表粒度，每個子訂單隻有一種商品對應。
采用多字段，通過預留字段的存放，比如增加買受方一、買受方二、買受方三、其他買受方
采用通用的橋接表。橋接表包含和事實表關聯的分組KEY，以及作為買受方維表外鍵的買受方ID。
(若事實表中一條記錄對應兩個買受方，則橋接表建立兩條記錄，分組KEY相同)
7.多值屬性
維表中某個屬性字段同時有多個值，稱之為"多值屬性"。比如一個商品，其商品的标簽有多個。
常見的處理方式：
保持次元主鍵不變，将多值屬性放在次元的一個屬性字段中。(以通過k-v對的形式放在property字段中)
保持主鍵不變，将多值屬性放在多個屬性字段中。(需要預留字段，擴充性差)
維表主鍵發生變化，一個次元值存放多條記錄，每個商品有多少屬性，就多少條記錄。
8.雜項次元
雜項次元是由操作型系統中的訓示符或者标志字段組合而成，一般不在一緻性次元之列。比如淘寶交易訂單
的交易類型字段，支付狀态、物流狀态等，它們在源系統中直接儲存在交易表中。
一個事實表中可能存在多個類似字段，若作為事實存放在事實表中，會導緻占用空間過大。若單獨建立維表，
外鍵關聯到事實表，會出現次元過多的情況；
通常的解決方案就是建立雜項次元 ，将這些字段建立到維表中，在事實表中隻需儲存一個外鍵即可。
多個字段的不同取值組成一條記錄，生成代理鍵，存人維表中，并将該代理鍵儲存到相應的事實表字段下。
建議不要直接使用所有的組合生成完整 的雜項維表，在抽取遇到新的組合時生成相應的記錄即可。
雜項次元 ETL 過程比一般次元略微複雜些。
阿裡實踐，明細整合層的事實表，建立的雜項次元會采用實體的主鍵作為雜項次元的主鍵(比如:訂單ID作為主鍵)。
五、事實表設計
1.事實表特性
粒度指事實表中一條記錄所表達的業務細節程度。
通常粒度可以通過兩種方式來表述：
一種是次元屬性組合所表示的細節程度：一種是所表示的具體業務含義。
可加型(可按照任意次元彙總)、半可加型(按照特定次元彙總，比如庫存不可按日期累加)、不可加性(比率型)。
不可加型可分解來實作聚集
次元屬性可以存儲到事實表中，成為"退化次元"。
事實表三種類型:
事務事實表(最原子資料)
周期快照事實表(按日、天等間隔記錄事實)
累積快照事實表(覆寫整個生命周期，具有多個日期記錄關鍵時間點)。
2.事實表的設計方法
選擇業務過程、聲明粒度、确認次元、确認事實、備援次元。
傳統的次元模組化星型模型中，對次元的處理需要單獨存放，通過事實表外鍵擷取次元，目的為了減少事實表的次元備援，進而減少存儲消耗。
而在大資料的事實表模型設計中，考慮更多的是提高下遊使用者的使用效率，減低資料擷取複雜性，減少關聯的表數量。
是以通過會備援常用次元。
3.單事務事實表、多事務事實表
單事務事實表，即針對每個業務過程設計一個事實表。比如淘寶訂單，下單->付款->發貨->完結，産生四條事實。
多事務事實表(仍有多條事實)，即同一個事實表包含不同的業務過程
設計時有兩種方法：
A:不同業務過程使用不同的事實字段進行存放，并增加标志字段。淘寶訂單舉栗：
訂單ID、是否當日下單、是否當日支付、是否當天完結、下單時間、支付時間、完結時間....
好處是：對于當日完成多個業務過程的記錄進行合并，若業務過程不在同一天仍會産生新的事實，曆史事實不更新。
B：不同業務過程使用統一事實字段進行存放，但增加業務過程标簽。(收藏/删除采用同一個字段)。淘寶收藏集舉栗：
業務日期、商品ID、收藏時間、删除時間、收藏删除類型
好處是：相比單事務表就是不同業務過程合并了一張表。
4.周期快照事實表
預定的間隔采樣狀态度量。這個東東跟聚集表不同，周期快照事實表一般都是儲存采樣周期結束時的狀态度量，
這些狀态度量都是半可加事實，比如年初至今、曆史至今金額、買家數等。淘寶栗子：
業務日期、賣家ID、自然年初截至當日下單金額、XXXX下單買家數、XXXX支付金額、XXXX支付買家數
5.累計快照事實表
累積快照事實表的典型特征是多業務過程日期，用于計算業務過程之間的時間間隔。還有個作用是儲存全量資料。
訂單ID、買家ID、下單時間、支付時間、發貨時間、确認發貨時間、狀态(下單、支付、發貨)等等。(不同的業務過程僅更新時間字段，不産生新記錄)
6.聚集型事實表
按照各個次元進行彙總統計，減少從明細表查詢帶來的性能問題。
阿裡的設計原則不建議聚集資料跨資料域。
4.