資料模型建設方法總結（全）

本資料來源于網際網路，僅供學習交流使用，版權歸屬出版商或者作者所有。如有侵權，請聯系本号進行删除并先行道歉！

一、大資料領域模組化綜述

1.1 為什麼需要資料模組化

• 有結構地分類組織和存儲是我們面臨的一個挑戰。
• 資料模型強調從業務、資料存取和使用角度合理存儲資料。
• 資料模型方法，以便在性能、成本、效率之間取得最佳平衡
• 成本：良好的資料模型能極大地減少不必要的資料備援，也能實作計算結果複用，極大地降低大資料系統中的存儲和計算成本。
• 效率：良好的資料模型能極大地改善使用者使用資料的體驗，提高使用資料的效率。
• 品質：良好的資料模型能改善資料統計口徑的不一緻性，減少資料計算錯誤的可能性。

1.2 關系資料庫系統和資料倉庫

1.3 從 OLTP 和 OLAP 系統的差別看模型方法論的選擇

• OLTP 系統通常面向的主要資料操作是随機讀寫，主要采用滿足 3NF 的實體關系模型存儲資料，進而在事務進行中解決資料的備援和一 緻性問題：
• OLAP 系統面向的主要資料操作是批量讀寫，事務進行中 的一緻性不是OLAP 所關注的，其主要關注資料的整合，以及在一次性的複雜大資料查詢和進行中的性能，是以它需要采用一些不同的資料模組化方法。

1.4 典型的資料倉庫模組化方法論

1.4.1 ER 模型

• 采用 ER模型建設資料倉庫模型的出發點是整合資料，将各個系統中的資料以整個企業角度按主題進行相似性組合和合并，并進行一緻性處理，為資料分析決策服務，但是并不能直接用于分析決策。
• ER 模型在實踐中最典型的代表是 Teradata 公司基于金融業務釋出 的 FS-LDM（Financial Services Logical Data Model），它通過對金融業務的高度抽象和總結，将金融業務劃分為10大主題，并以設計面向金融倉庫模型的核心為基礎，企業基于此模型做适當調整和擴充就能快速落地實施。

1.4.2 次元模型

• 次元模組化從分析決策的需求出發構模組化型，為分析需求服務，是以它重點關注使用者如何更快速地完成需求分析，同時具有較好的大規模複雜查詢的響應性能。其典型的代表是星形模型，以及在一些特殊場景下使用的雪花模型。設計步驟通常如下：
• 選擇需要進行分析決策的業務過程。業務過程可以是單個業務事件，比如交易的支付、退款等；也可以是某個事件的狀态，比如目前的賬戶餘額等；還可以是一系列相關業務事件組成的業務流程，具體需要看我們分析的是某些事件發生情況，還是目前狀态，或是事件流轉效率。
• 選擇粒度。在事件分析中，我們要預判所有分析需要細分的程度，進而決定選擇的粒度。粒度是次元的一個組合。
• 識别維表。選擇好粒度之後，就需要基于此粒度設計維表，包括次元屬性，用于分析時進行分組和篩選。
• 選擇事實。确定分析需要衡量的名額。

1.4.3 Data Vault 模型

• 它強調建立一個可審計的基礎資料層，也就是強調資料的曆史 性、可追溯性和原子性，而不要求對資料進行過度的一緻性處理和整合；同時它基于主題概念将企業資料進行結構化組織，并引入了更進一步的範式處理來優化模型，以應對下遊、系統變更的擴充性。

1.4.4 Anchor 模型

• Anchor 對 Data Vault 模型做了進一步規範化處理， Lars.Ronnback 的初衷是設計一個高度可擴充的模型，其核心思想是所有的擴充隻是添加而不是修改，是以将模型規範到 6NF ，基本變成了k-v 結構化模型。

1.5 阿裡巴巴資料模型實踐綜述

• 第一個階段：建構在 Oracle 上，資料完全以滿足報表需求為目的
• 第二個階段：引入了當時 MPP 架構體系的 Greenplum，ODL（操作資料層）+BDL（基礎資料層）+IDL（接口資料層）+ADL （應用資料層）；BDL希望引入 ER 模型，加強 資料的整合，建構一緻的基礎資料模型，但建構 ER 模型時遇到了比較大的困難和挑戰，網際網路業務的快速發展、人員的快速變化、業務知識功底的不夠全面，導緻 ER 模型設計遲遲不能産出。至此，我們也得到了一個經驗：在不太成熟、快速變化的業務面前，建構 ER 模型的風險非常大，不太适合去建構 ER 模型。
• 第三個階段：迎來了以Hadoop 為代表的分布式存儲計算平台的快速發展，同時阿裡巴 巴集團自主研發的分布式計算平台 MaxCompute 也在緊鑼密鼓地進行着。以 Kimball 的次元模組化為核心理念的模型方法論，建構了阿裡巴巴集團的公共層模型資料架構體系。
• 資料公共層建設的目的是着力解決資料存儲和計算的共享問題。資料每年以近 2.5 倍的速度在增長，資料的增長遠遠超過業務的增長。
• 統一化的集團資料整合及管理的方法體系“OneData”：一緻性的名額定義體系、模型設計方法體系以及配套工具。

二、阿裡巴巴資料整合及管理體系

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

2.1 概述

核心：從業務架構設計（如何快速上手工作）到模型設計，從資料研發到資料服務，做到資料可管理、可追溯、可規避重複建設。

2.1.1 定位及價值

建設統一的、規範化的資料接入層（ ODS ）和資料中間層（ DWD 和 DWS ），通過資料服務和資料産品，完成服務于阿裡巴巴的大資料系統建設，即資料公共層建設。

業務闆塊：根據業務屬性劃分闆塊，闆塊之間的名額或業務重疊性較小。

規範定義：一套資料規範命名體系，用在模型設計中

模型設計：以次元模組化理論為基礎，基于次元模組化總線架構，建構一緻性的次元和事實(進行規範定義)。

2.2 規範定義

規範定義指以次元模組化作為理論基礎，建構總線矩陣，劃分和定義 資料域、業務過程、次元、度量／原子名額、修飾類型、修飾詞、時間周期、派生名額。

2.2.1 名詞術語

資料域（主題域）

• 面向業務分析，将業務過程或者次元進行抽象的集合。業務過程可以概括為一個個不可拆分的行為事件，在業務過程之下，可以定義名額；次元是指度量的環境，如買家下單事件，買家是次元 。為保障整個體系的生命力 ， 資料域是需要抽象提煉，并且長期維護和更新的 ， 但不輕易變動。
• 常見主題域：使用者、管道、營銷、流量、交易、财務、商品

業務過程

• 指企業的業務活動事件，如下單、支付、退款都是業務過程。請注意，業務過程 是一個不可拆分的行為事件 ， 通俗地講 ，業務過程就是企業活動中的事件

時間周期

• 用來明确資料統計的時間範圍或者時間點，如最近 30天、自然周、截至當日等

修飾類型

• 是對修飾詞的一種抽象劃分 。修飾類型從屬于某個業務域，如日志域的通路終端類型涵蓋無線端、 PC 端等修飾詞

修飾詞

• 指除了統計次元以外名額的業務場景限定抽象 。修飾詞隸屬于一種修飾類型，如 在日志域的通路終端類型下 ， 有修飾詞 PC 端、無線端等

度量/原子名額

• 原子名額和度量含義相同，基于某一業務事件行為下的度量，是業務定義中不可 再拆分的名額，具有明确業務含義的名詞 ，如支付金額

次元

• 次元是度量的環境，用來反映業務的一類屬性 ，這類屬性的集合構成一個次元 ，也可以稱為實體對象。次元屬于一個資料域，如地理次元（其中包括國家、地區、 省以及城市等級别的内容)、時間次元(其中包括年、季、月、周、日等級别的内容）

次元屬性

• 次元屬性隸屬于一個次元 ，如地理次元裡面的國家名稱、國家 ID、省份名稱等都屬于次元屬性

派生名額

• 派生名額=一個原子名額+多個修飾詞(可選)+時間周期+粒度。可以了解為對原子名額業務統計範圍的圈定。如原子名額：支付金額，最近 1 天海外買家支付金額則為派生名額(最近1天為時間周期 ， 海外為修飾詞 ， 買家作為次元，而不作為修飾詞)

2.2.2 名額體系

一、基本原則

1. 組成體系之間的關系

• 派生名額由原子名額、時間周期修飾詞、若幹其他修飾詞組合得到

• 原子名額、修飾類型及修飾詞，直接歸屬在業務過程下，其中修飾詞繼承修飾類型的資料域
• 派生名額可以選擇多個修飾詞，修飾詞之間的關系為"或"或者"且"，由派生名額具體語義決定
• 派生名額唯一歸屬一個原子名額，繼承原子名額的資料域，與修飾詞的資料域無關
• 原子名額有确定的英文字段名、資料類型和算法說明；派生名額要繼承原子名額的英文名、資料類型和算法要求

1. 命名約定

• 命名所用術語。名額命名盡量使用英文簡寫，其次是英文。太長也可以考慮漢語拼音首字母
• 業務過程。英文名：用英文或英文的縮寫或者中文拼音簡寫
• 原子名額。英文名：動作+度量
• 修飾詞。隻有時間周期才會有英文名
• 派生名額。英文名：原子名額英文名+時間周期修飾詞(3位,例如_1d)+序号(4位，例如_001)

1. 算法

• 算法概述一一算法對應的使用者容易了解的闡述。
• 舉例一一通過具體例子幫助了解名額算法。
• SQL 算法說明一一對于派生名額給出SQL的寫法或者僞代碼。

二、操作細則

派生名額可以分為三類：事務型名額、存量型名額和複合型名額。

• 事務型名額：是指對業務活動進行衡量的名額。例如新發商品數、 重發商品數、新增注冊會員數、訂單支付金額，這類名額需維護 原子名額及修飾詞，在此基礎上建立派生名額。
• 存量型名額：是指對實體對象(如商品、會員)某些狀态的統計。例如商品總數、注冊會員總數，這類名額需維護原子名額及修飾詞，在此基礎上建立派生名額，對應的時間周期 一般為“曆史截至目前某個時間”。
• 複合型名額：是在事務型名額和存量型名額的基礎上複合而成的。例如浏覽 UV-下單買家數轉化率 ， 有些需要 創 建新原子名額， 有些則可以在事務型或存量型原子名額的基礎上增加修飾詞得到派生名額。

2.3 模型設計

2.3.1 指導理論

資料模型的次元設計主要以次元模組化理論為基礎，基于次元資料模型總線架構，建構一緻性的次元和事實。

2.3.2 模型層次

• 操作資料層（ODS）：把作業系統資料幾乎無處理地存放在資料倉庫系統中。
• 公共次元模型層（CDM）：存放明細事實資料、維表資料及公共名額彙總資料 ，其中明細事實資料、維表資料一般根據 ODS 層資料加工生成 ；公共名額彙總資料一般根據維表資料和明細事實資料加工生成。
• CDM 層又細分為 DWD 層和 DWS 層，分别是明細資料層和彙總資料層，采用次元模型方法作為理論基礎 ，更多地采用一些次元退化手法， 将次元退化至事實表中，減少事實表和維表的關聯 ，提高明細資料表的易用性；同時在彙總資料層， 加強名額的次元退化， 采取更多的寬表化手段建構公共名額資料層，提升公共名額的複用性，減少重複加工。其主要功能如下。
• 組合相關和相似資料：采用明細寬表，複用關聯計算，減少資料掃描。
• 公共名額統一加工：基于 OneData體系建構命名規範、口徑一緻 和算法統一 的統計名額，為上層資料産品、應用和服務提供公共名額建立邏輯彙總寬表。
• 建立一緻性次元:建立一緻的資料分析維表，降低資料計算口徑、算法不統一的風險。
• 應用資料層（ADS）：存放資料産品個性化的統計名額資料，根據 CDM 層與 ODS 層加工生成 。
• 個性化名額加工：不公用性、複雜性(指數型、比值型、排名型名額)。
• 基于應用的資料組裝 : 大寬表集市、橫表轉縱表、趨勢名額串。

阿裡巴巴通過建構全域的公共層資料，極大地控制了資料規模的增長趨勢

模型架構圖

• 資料調用服務優先使用公共次元模型層( CDM )資料，當公共層沒有資料時，需評估是否需要建立公共層資料，當不需要建設公用的公共層時，方可直接使用操作資料層( ODS)資料。應用資料層( ADS) 作為産品特有的個性化資料一般不對外提供資料服務，但是 ADS 作為被服務方也需要遵守這個約定。

2.3.3 基本原則

• 高内聚和低耦合

一個邏輯或者實體模型由哪些記錄和字段組成，應該遵循最基本的軟體設計方法論的高内聚和低耦合原則。主要從資料業務特性和通路特性兩個角度來考慮：将業務相近或者相關、粒度相同的資料設計為一個邏輯或者實體模型；将高機率同時通路的資料放一起，将低機率同時通路的資料分開存儲。

• 核心模型與擴充模型分離

建立核心模型與擴充模型體系，核心模型包括的字段支援常用的核心業務，擴充模型包括的字段支援個性化或少量應用的需要 ，不能讓擴充模型的宇段過度侵入核心模型，以免破壞核心模型的架構簡潔性與可維護性。

• 公共處理邏輯下沉及單一

越是底層公用的處理邏輯越應該在資料排程依賴的底層進行封裝與實作，不要讓公用的處理邏輯暴露給應用層實作，不要讓公共邏輯多處同時存在。

• 成本與性能平衡

适當的資料備援可換取查詢和重新整理性能，不宜過度備援與資料複制。

• 資料可復原

處理邏輯不變，在不同時間多次運作資料結果确定不變。

• 一緻性

具有相同含義的字段在不同表中的命名必須相同，必須使用規範定義中的名稱。

• 命名清晰、可了解

表命名需清晰、一緻，表名需易于消費者了解和使用。

2.4 模型實施

2.4.1 業界常用模型實施過程

建構次元模型一般要經曆四個階段：

• 第一個階段是高層模型設計時期 ，定義業務過程次元模型的範圍，提供每種星形模式的技術和功能描述；直接産出目标是建立高層次元模型圖，它是對業務過程中的維表和事實表的圖形描述。确定維表建立初始屬性清單，為每個事實表建立提議度量；
• 第二個階段是詳細模型設計時期，對每個星形模型添加屬性和度量資訊；确定每個維表的屬性和每個事實表的度量，并确定資訊來源的位置、定義，确定屬性和度量如何填入模型的初步業務規則。
• 第三個階段是進行模型的審查、再設計和驗證，本階段主要召集相關人員進行模型的審查和驗證，根據審查結果對詳細次元進行再設計。
• 第四個階段是産生詳細設計文檔，送出 ETL 設計和開發，最後，完成模型詳細設計文檔，送出 ETL 開發人員，進入 ETL 設計和開發階段，由 ETL 人員完成實體模型的設計和開發。

2.4.2 OneData實施過程

1. 指導方針

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

1. 實施工作流

（1）資料調研

1. 業務調研：需要了解各個業務領域、業務線的業務有什麼共同點和不同點 ，以及各個業務線可以細分為哪幾個業務子產品，每個業務子產品具體的業務流程又是怎樣的。業務調研是否充分，将會直接決定資料倉庫 建設是否成功
2. 需求調研：需求調研的途徑有兩種：一是根據與分析師、業務營運人員的溝通 （郵件、 IM ）獲知需求；二是對報表系統中現有的報表進行研究分析；

（2）架構設計

1. 資料域劃分

資料域是指面向業務分析，将業務過程或者次元進行抽象的集合。業務過程可以概括為 一 個個不可拆分的行為事件，如下單、支付、退款。資料域需要抽象提煉，并且長期維護和更新，但不輕易變動。

1. 建構總線矩陣

在進行充分的業務調研和需求調研後，就要建構總線矩陣了。需要 做兩件事情：明确每個資料域下有哪些業務過程；業務過程與哪些次元相關，并定義每個資料域下的業務過程和次元。

1. 規範定義

規範定義主要定義名額體系，包括原子名額、修飾詞、時間周期和 派生名額。

1. 模型設計

模型設計主要包括次元及屬性的規範定義，維表、明細事實表和彙 總事實表的模型設計。

1. 總結

OneData 的實施過程是一個高度疊代和動态的過程， 一般采用螺旋式實施方法。在總體架構設計完成之後，開始根據資料域進行疊代式模型設計和評審。在架構設計、規範定義和模型設計等模型實施過程中， 都會引入評審機制，以確定模型實施過程的正确性。

三、次元設計

3.1 次元設計基礎

3.1.1 次元的基本概念

• 次元模組化中，将度量稱為“事實”，将環境描述為“次元”，次元是用于分析事實所需要的多樣環境。例如，在分析交易過程時，可以通過買家、賣家、商品和時間等次元描述交易發生的環境。
• 次元所包含的表示次元的列，稱為次元屬性。次元屬性是查詢限制條件、分組和報表标簽生成的基本來源，是資料易用性的關鍵。
• 次元使用主鍵辨別其唯一性，主鍵也是確定與之相連的任何事實表 之間存在引用完整性的基礎。

3.1.2 次元的基本設計方法

1. 選擇次元或建立次元。須保證次元的唯一性。
2. 确定主維表。一般是ODS表，直接與業務系統同步。
3. 确定相關維表。确定哪些表和主維表存在關聯關系，并選擇其中的某些表用于生成次元屬性。
4. 确定次元屬性。第一階段從主維表中選擇次元屬性或生成新的次元屬性；第二階段是從相關維表中選擇次元屬性或生成新的次元屬性。

确認次元屬性的幾點提示：

1. 盡可能生成豐富的次元屬性
2. 盡可能多地給出包括一些富有意義的文字性描述
3. 區分數值型屬性和事實

• 如果通常用于查詢限制條件或分組統計，則是作為次元屬性；如果通常 用于參與度量的計算，則是作為事實。比如商品價格，可以用于查詢約 束條件或統計價格區間的商品數量，此時是作為次元屬性使用的；也可 以用于統計某類目下商品的平均價格，此時是作為事實使用的。另外， 如果數值型字段是離散值，則作為次元屬性存在的可能性較大；如果數 值型宇段是連續值，則作為度量存在的可能性較大，但并不絕對，需要 同時參考宇段的具體用途。

1. 盡量沉澱出通用的次元屬性

3.1.3 一緻性次元和交叉探查

• 共享維表。比如在阿裡巴巴的資料倉庫中，商品、賣家、買家、 類目等次元有且隻有一個。是以基于這些公共次元進行的交叉探查不會存在任何問題。
• 一緻性上卷。其中一個次元的次元屬性是另一個次元的次元屬性 的子集，且兩個次元的公共次元屬性結構和内容相同。比如在阿 裡巴巴的商品體系中，有商品次元和類目次元，其中類目次元的 次元屬性是商品次元的次元屬性的子集，且有相同的次元屬性和 次元屬性值。這樣基于類目次元進行不同業務過程的交叉探查也 不會存在任何問題。
• 交叉屬性。兩個次元具有部分相同的次元屬性。比如在商品次元中具有類目屬性，在賣家次元中具有主營類目屬性，兩個次元具有相同的類目屬性，則可以在相同的類目屬性上進行不同業務過程的交叉探查。

3.2 次元設計進階主題

3.2.1 次元整合

1. 應用間差異：

• 應用在編碼、命名習慣、度量機關等方面會存在很大的差異。
• 應用出于性能和擴充性的考慮，或者随技術架構的演變，以及業務的發展，采用不同的實體實作。

1. 內建類型（同次元整合）：

• 命名規範的統一。表名、字段名等統一。
• 字段類型的統一。相同和相似字段的字段類型統一。
• 公共代碼及代碼值的統一。公共代碼及标志性字段的資料類型、 命名方式等統一。
• 業務含義相同的表的統一。主要依據高内聚、低耦合的理念，在實體實作中，将業務關系大、源系統影響差異小的表進行整合：将業務關系小、源系統影響差異大的表進行分而置之。通常有如下幾種內建方式：
• 采用主從表的設計方式，将兩個表或多個表都有的字段放在主表中（主要基本資訊），從屬資訊分别放在各自的從表中。對于主表中的主鍵，要麼采用複合主鍵、源主鍵和系統或表 差別标志：要麼采用唯一主鍵、“源主鍵和系統或表差別标志”生成新的主鍵。通常建議采用複合主鍵的方式。
• 直接合并，共有資訊和個性資訊都放在同一個表中。如果表字段的重合度較低，則會出現大量空值，對于存儲和易用性會有影響，需謹慎選擇。
• 不合并，因為源表的表結構及主鍵等差異很大，無法合并，使用資料倉庫裡的多個表存放各自的資料。

1. 表整合：

• 垂直整合：不同的來源表包含相同的資料集，隻是存儲 的資訊不同，比如主表與擴充表的整合，豐富其次元屬性。
• 水準整合：不同的來源表包含不同的資料集，不同子集之間無交叉，也可以存在部分交叉。
• 存在交叉，則需要去重
• 不存在交叉，則需要考慮不同子集的自然鍵是否存在沖突
• 如果不沖突， 則可以考慮将各子集的自然鍵作為整合後的表的自然鍵
• 設定超自然鍵，将來源表各子集的自然鍵加工成一個字段作為超自然鍵（即聯合主鍵，阿裡采用該方法，并将來源字段作為分區字段）

3.2.2 水準拆分

如何設計次元：

• 模型設計重點考慮的三個原則：
• 擴充性：當源系統、業務邏輯變化時，能通過較少的成本快速擴 展模型，保持核心模型的相對穩定性。軟體工程中的高内聚、低藕合的思想是重要的指導方針之一。
• 效能：在性能和成本方面取得平衡。通過犧牲一定的存儲成本， 達到性能和邏輯的優化。
• 易用性：模型可了解性高、通路複雜度低。使用者能夠友善地從模型中找到對應的資料表，并能夠友善地查詢和分析。
• 模型設計重點考慮的兩個依據：
• 次元的不同分類的屬性差異情況。當次元屬性随類型變化較大時，采用方案 1 。
• 業務的關聯程度。兩個相關性較低的業務，稠合在一起弊大于利，對模型的穩定性和易用性影響較大，采用方案 2。

方案參考：

• 方案 1 是将次元的不同分類執行個體化為不同的次元，同時在主次元中儲存公共屬性，适合于當次元屬性随類型變化較大的情形
• 建構商品次元、航旅商品次元：不同分類的商品，其次元屬性可能相同，也可能不同。比如航旅的商品和普 通的淘系商品，都屬于商品，都有商品價格、标題、類型、上架時間、 類目等次元屬性，但是航旅的商品除了有這些公共屬性外，還有酒店、 景點、門票、旅行等自己獨特的次元屬性。
• 方案 2 是維護單一次元，包含所有可能的屬性
• 對淘系商品和 1688 商品建構兩個次元，業務分析人員一般隻針對本資料集市進行統計分析。1688 業務變更，此次元需要變更， 淘寶業務變更亦然，穩定性很差。

3.2.3 垂直拆分

• 出于擴充性、産出時間、易用性等方面的考慮，設計主從次元。
• 主維表存放穩定、産出時間早、熱度高的屬性；
• 從維表存放變化較快、産 出時間晚、熱度低的屬性。
• 設計了商品主次元和商品擴充次元。其中商品主次元在每日的 1：30 左右産出，而商 品擴充次元由于有備援的産出時間較晚的商品品牌和标簽資訊，在每日 的 3：00 左右産出。
• 由于商品擴充次元有備援的庫存等變化較快 的資料，對于主次元進行緩慢變化的處理較為重要。通過存儲的備援和計算成本的增加，實作了商品主模型的穩定和産出時間的提前。

3.2.4 曆史歸檔

• 歸檔政策 1：同前台歸檔政策，在資料倉庫中實作前台歸檔算法，定期對曆史資料進行歸檔。但存在一些問題，一是前台歸檔政策複雜，實作成本較高；二是前台歸檔政策可能會經常變化，導緻資料倉庫歸檔算法也要随之變化，維護和溝通成本較高。此方式适用于前台歸檔政策 邏輯較為簡單，且變更不頻繁的情況。
• 歸檔政策 2 ：同前台歸檔政策，但采用資料庫變更日志的方式。對 于如此龐大的資料量，阿裡巴巴采用的資料抽取政策一般是通過資料庫 binlog 日志解析擷取每日增量，通過增量merge 全量的方式擷取最新的 全量資料。可以使用增量日志的删除标志，作為前台資料歸檔的标志。通過此标志對資料倉庫的資料進行歸檔。此方式不需要關注前台歸檔策 略，簡單易行。但對前台應用的要求是資料庫的實體删除隻有在歸檔時 才執行，應用中的删除隻是邏輯删除。
• 歸檔政策 3 ：資料倉庫自定義歸檔政策。可以将歸檔算法用簡單、直接的方式實作，但原則是盡量比前台應用晚歸檔、少歸檔。避免出現資料倉庫中已經歸檔的資料再次更新的情況。
• 如果技術條件允許，能夠解析資料庫 binlog 日志，建議使用歸檔政策 2 ，規避前台歸檔算法。具體可以根據自身資料倉庫的實際情況進行選擇。

3.3 次元變化

3.3.1 緩慢變化維

在 Kimball 的理論中，有三種處理緩慢變化維的方式，可以根據業務需求來進行選擇：

1. 重寫次元值。不保留曆史資料， 始終取最新資料（假設業務需求方不關心曆史資料，則可以采用方案1）
2. 插入新的次元行。保留曆史資料，次元值變化前的事實和過去的次元值關聯，次元值變化後的事實和目前的次元值關聯。
3. 添加次元列。采用第二種處理方式不能将變化前後記錄的事實歸一為變化前的次元或者歸一為變化後的次元（不同業務部門需要統計各自的業績，則需 要保留曆史資料）

3.3.2 快照維表

• 在 Kimball 的次元模組化中，必須使用代理鍵（不具有業務含義的鍵，差別于自然鍵）作為每個維表的主鍵，用于處理緩慢變化維。
• 阿裡不使用代理鍵的原因：資料量大、ETL複雜化；不直接使用拉連結清單的原因：解釋成本高、随着時間的推移，分區數量會極度膨脹
• 阿裡通過快照方式，每天保留一份全量快照資料，簡單而有效，友善好了解，但造成存儲浪費，是以配合極限存儲。

3.3.3 極限存儲

1. 透明化

• 底層的資料還是曆史拉鍊存儲，但是上層做一個視圖操作或者在 Hive 裡做一個 hook ，通過分析語句的文法樹，把對極限存儲前的表的 查詢轉換成對極限存儲表的查詢。

1. 分月做曆史拉連結清單

• 每個月月初重新開始做曆史拉連結清單

局限性：首先，其産出效率很低，大部分極限存儲通常需要 t-2 ；其次，對于變化頻率高的資料并不能達到節約成本的效果。

• 在做極限存儲前有一個全量存儲表，全量存儲表僅保留最近一段 時間的全量分區資料，曆史資料通過映射的方式關聯到極限存儲表。即使用者隻通路全量存儲表，是以對使用者來說極限存儲是不可見的。
• 對于部分變化頻率頻繁的宇段需要過濾。例如，使用者表中存在使用者積分宇段，這種宇段的值每天都在發生變化，如果不過濾的話，極限存儲就相當于每個分區存儲一份全量資料，起不到節約存儲成本的效果。

3.3.4 微型次元

• 微型次元的建立是通過将一部分不穩定的屬性從主次元中移出，并 将它們放置到擁有自己代理鍵的新表中來實作的。這些屬性互相之間沒有直接關聯，不存在自然鍵。通過為每個組合建立新行的一次性過程來加載資料。
• 比如淘寶使用者次元，使用者的注冊日期、年齡、性别、身份資訊等基本不會發生變化，但使用者 VIP 等級、使用者信用評價等級會随着使用者的行為不斷發生變化。
• 其中 VIP 等級共有 8 個值，即 -1 ～6 ；使用者信用評價等級共有 18 個值。假設基于 VIP 等級和使用者信用評價等級建構微型次元，則在此微型次元中共有 8 x 18 個組合，即 144 條記錄，代理鍵可能是 1～ 144

阿裡在實踐中并未使用此技術：

• 微型次元的局限性：必須是枚舉值，且考慮所有可能組合
• ETL 邏輯複雜
• 破壞了次元的可浏覽性

3.4 特殊次元

3.4.1 遞歸層次

• 次元的遞歸層次，按照層級是否固定分為均衡層次結構（如一級類目、二級類目等）和非均衡層次結構（如公司之間的公司，數量級别不固定）
• 遞歸 SQL 成本較高，且很多工具不支援遞歸SQL，是以在次元模型中對層次結構進行處理

1. 層次結構扁平化

扁平化僅包含固定數量的級别，對于非平衡層次結構，可以通過預留級别的方式來解決，但擴充性較差（圖為阿裡巴巴中文站的類目體系，粗體部分為回填内容）

1. 層次橋接表

• 解決了層次結構扁平化帶來的一些問題，加工邏輯複雜，使用邏輯複雜，實際工作很少應用

3.4.2 行為次元

了解為事實衍生的次元，按照加工方式劃分：

• 另一個次元的過去行為，如買家最近一次通路淘寶的時間、買家最近一次發生淘寶交易的時間等。
• 快照事實行為次元，如買家從年初截至目前的淘寶交易金額、買 家信用分值、賣家信用分值等。
• 分組事實行為次元，将數值型事實轉換為枚舉值。如買家從年初截至目前的淘寶交易金額按照金額劃分的等級、買家信用分值按 照分數劃分得到的信用等級等。
• 複雜邏輯事實行為次元，通過複雜算法加工或多個事實綜合加工得到。如前面提到的賣家主營類目，商品熱度根據通路、收藏、 加入購物車、交易等情況綜合計算得到。

對于行為次元，有兩種處理方式，其中一種是将其備援至現有的維表中，如将賣家信用等級備援至賣家維表中另一種是加工成單獨的行為維表，如賣家主營類目。具體采用哪種方式主要參考如下兩個原則：

• 第一，避免次元過快增長。比如對商品表進行了極限存儲，如果将 商品熱度加入現有的商品維表中，則可能會使每日商品變更占比過高， 進而導緻極限存儲效果較差。
• 第二，避免耦合度過高。比如賣家主營類目，加工邏輯異常複雜， 如果融合進現有的賣家維表中，那麼過多的業務稠合會導緻賣家維表重新整理邏輯複雜、維護性差、産出延遲等。

3.4.3 多值次元

• e.g. 交易父訂單事實表 與 商品表

多值次元的處理方式

• 降低事實表的粒度（子訂單建立事實）
• 采用多字段（售樓合同，多個買受方，已是最細粒度；由于個數不會太多，預留字段：買受方1，買受方2，買受方3）
• 橋接表：通過橋接表，則會産生多條重複記錄，業務上注意區分重複計算是否符合業務邏輯

3.4.4 多值屬性

e.g. 商品和 SKU、屬性、标簽都是多對多的關系

多值屬性的處理方式：

• 保持次元主鍵不變，将多值屬性放在次元的一個屬性字段中（通過 k-v 對的形式放在 property 字段中，資料示例如下：10281239:156426871; 137396765:29229; 137400766:3226633）
• 保持次元主鍵不變，但将多值屬性放在次元的多個屬性字段中（賣家主營類目，隻取TOP 3）
• 次元主鍵發生變化，一個次元值存放多條記錄，擴充性好，使用友善（比如商品 SKU 維表，對于每個商品，有多少 SKU ，就有多少記錄，主鍵是商品的 ID 和 SKU 的 ID）

3.4.5 雜項次元

• 雜項次元是由操作型系統中的訓示符或者标志宇段組合而成的，一般不在一緻性次元之列。
• 将這些字段建立到一個維表中，在事實表中隻需儲存一個外鍵即可。多個字段的不同取值組成 一條記錄，生成代理鍵，存入維表中，并将該代理鍵儲存到相應的事實表字段下。建議不要直接使用所有的組合生成完整的雜項維表，在抽取遇到新的組合時生成相應的記錄即可。
• 阿裡：存在非枚舉字段，如交易留言、交易屬性、交易标簽等；通過子訂單次元實作，且作為邏輯模型，不進行實體化。

四、事實表設計

4.1 事實表基礎

4.1.1 事實表特性

• 事實表作為資料倉庫次元模組化的核心，緊緊圍繞着業務過程來設計，通過擷取描述業務過程的度量來表達業務過程，包含了引用的次元和與業務過程有關的度量。
• 事實表中一條記錄所表達的業務細節程度被稱為粒度。通常粒度可以通過兩種方式來表述：一種是次元屬性組合所表示的細節程度：一種是所表示的具體業務含義。
• 作為度量業務過程的事實，一般為整型或浮點型的十進制數值，有可加性、半可加性和不可加性三種類型。
• 可加性事實是指可以按照與事實表關聯的任意次元進行彙總。
• 半可加性事實隻能按照特定次元彙總， 不能對所有次元彙總，比如庫存可以按照地點和商品進行彙總，而按時間次元把一年中每個月的庫存累加起來則毫無意義。
• 完全不具備可加性，比如比率型事實。對于不可加性事實可分解為可加的元件來實作聚集。
• 次元屬性也可以存儲到事實表中，這種存儲到事實表中的次元列被稱為“退化次元”。與其他存儲在維表中的次元一樣 ，退化次元也可以 用來進行事實表的過濾查詢、實 現聚合操作等。
• 事實表有三種類型 : 事務事實表、周期快照事實表和累積快照事實表。
• 事務事實表用來描述業務過程，跟蹤空間或時間上某點的度量事件，儲存的是最原子的資料，也稱為“原子事實表“。
• 周期快照事實表以具有規律性的、可預見的時間間隔記錄事實 ，時間間隔如每天、每月、每年等。
• 累積快照事實表用來表述過程開始和結束之間的關鍵步驟事件，覆寫過程的整個生命周期，通常具有多個日期字段來記錄關鍵時間點，當過程随着生命周期不斷變化時，記錄也會随着過程的變化而被修改。

4.1.2 事實表設計原則

原則 1：盡可能包含所有與業務過程相關的事實

• 事實表設計的目的是為了度量業務過程，是以分析哪些事實與業務過程有關是設計中非常重要的關注點。在事實表中應該盡量包含所有與業務過程相關的事實，即使存在備援，但是因為事實通常為數字型，帶來的存儲開銷也不會很大。

原則 2：隻選擇與業務過程相關的事實

• 在選擇事實時，應該注意隻選擇與業務過程有關的事實。比如在訂單的下單這個業務過程的事實表設計中 ，不應該存在支付金額這個表示支付業務過程的事實。

原則 3：分解不可加性事實為可加的元件

對于不具備可加性條件的事實，需要分解為可加的元件。比如訂單的優惠率，應該分解為訂單原價金額與訂單優惠金額兩個事實存儲在事實表中。

原則 4：在選擇次元和事實之前必須先聲明粒度

• 粒度的聲明是事實表設計中不可忽視的重要一步，粒度用于确定事實表中一行所表示業務的細節層次，決定了次元模型的擴充性，在選擇次元和事實之前必須先聲明粒度，且每個次元和事實必須與所定義的粒度保持一緻。在設計事實表的過程中，粒度定義得越細越好，建議從最低級别的原子粒度開始，因為原子粒度提供了最大限度的靈活性，可以 支援無法預期的各種細節層次的使用者需求。在事實表中，通常通過業務描述來表述粒度，但對于聚集性事實表的粒度描述，可采用次元或次元屬性組合的方式。

原則 5：在同一個事實表中不能有多種不同粒度的事實

事實表中的所有事實需要與表定義的粒度保持一緻，在同一個事實表中不能有多種不同粒度的事實。

原則 6：事實的機關要保持一緻

對于同一個事實表中事實的機關，應該保持一緻。比如原訂單金額、 訂單優惠金額、訂單運費金額這三個事實，應該采用一緻的計量機關， 統 一 為元或分，以友善使用。

原則 7：對事實的 null 值要處理

對于事實表中事實度量為 null 值的處理，因為在資料 庫中 null 值 對常用數字型字段的 SQL 過濾條件都不生效，比如大于、小于、等于、 大于或等于、小于或等于，建議用零值填充。

原則 8：使用退化次元提高事實表的易用性

• 在 Kimball 的次元模組化中，通常按照星形模型的方式來設計，對于 次元的擷取采用的是通過事實表的外鍵關聯專門的維表的方式，謹慎使 用退化次元。而在大資料領域的事實表設計中，則大量采用退化次元的 方式，在事實表中存儲各種類型的常用次元資訊。這樣設計的目的主要 是為了減少下遊使用者使用時關聯多個表的操作，直接通過退化次元實作 對事實表的過濾查詢、控制聚合層次、排序資料以及定義主從關系等。通過增加備援存儲的方式減少計算開銷，提高使用效率。

4.1.3 事實表設計方法

對于次元模型設計采用四步設計方法：選擇業務過程、聲明粒度、确定次元、确定事實。

1. 選擇業務過程及确定事實表類型

在明确了業務需求以後，接下來需要進行詳細的需求分析，對業務 的整個生命周期進行分析，明确關鍵的業務步驟，進而選擇與需求有關的業務過程。

業務過程通常使用行為動詞表示業務執行的活動。比如圖 4.1中的淘寶訂單流轉的業務過程有四個：建立訂單、買家付款、賣家發貨、買家确認收貨。在明确了流程所包含的業務過程後，需要根據具體的業務需求來選擇與次元模組化有關的業務過程。比如是選擇買家付款這個業務過程，還是選擇建立訂單和買家付款這兩個業務過程，具體根據業務情 況來确定。

在選擇了業務過程以後，相應的事實表類型也随之确定了。比如選擇買家付款這個業務過程，那麼事實表應為隻包含買家付款這一個業務過程的單事務事實表；如果選擇的是所有四個業務過程，并且需要分析各個業務過程之間的時間間隔，那麼所建立的事實表應為包含了所有四個業務過程的累積快照事實表。

1. 聲明粒度

粒度的聲明是事實表模組化非常重要的一步，意味着精确定義事實表 的每一行所表示的業務含義，粒度傳遞的是與事實表度量有關的細節層次。明确的粒度能確定對事實表中行的意思的了解不會産生混淆，保證所有的事實按照同樣的細節層次記錄。

應該盡量選擇最細級别的原子粒度，以確定事實表的應用具有最大的靈活性。同時對于訂單過程而言，粒度可以被定義為最細的訂單級别。比如在淘寶訂單中有父子訂單的概念，即一個子訂單對應一種商品，如 果拍下了多種商品，則每種商品對應一個子訂單:這些子訂單一同結算 的話，則會生成一個父訂單。那麼在這個例子中，事實表的粒度應該選擇為子訂單級别。

1. 确定次元

完成粒度聲明以後，也就意味着确定了主鍵，對應的次元組合以及相關的次元字段就可以确定了，應該選擇能夠描述清楚業務過程所處的環境的次元資訊。比如在淘寶訂單付款事務事實表中，粒度為子訂單，相關的次元有買家、賣家、商品、收貨人資訊 、業務類型、訂單時間等次元。

1. 确定事實

事實可以通過回答“過程的度量是什麼”來确定。應該選擇與業務 過程有關的所有事實，且事實的粒度要與所聲明的事實表的粒度一緻。事實有可加性、半可加性、非可加性三種類型 ， 需要将不可加性事實分解為可加的元件。

比如在淘寶訂單付款事務事實表中，同粒度的事實有子訂單分攤的支付金額、郵費、優惠金額等。

1. 備援次元

在傳統的次元模組化的星形模型中，對次元的處理是需要單獨存放在專門的維表中的，通過事實表的外鍵擷取次元。這樣做的目的是為了減少事實表的次元備援，進而減少存儲消耗。而在大資料的事實表模型設計中，考慮更多的是提高下遊使用者的使用效率，降低資料擷取的複雜性，減少關聯的表數量。是以通常事實表中會備援友善下遊使用者使用的常用次元，以實作對事實表的過濾查詢、控制聚合層次、排序資料以及定義主從關系等操作。

比如在淘寶訂單付款事務事實表中，通常會備援大量的常用次元字段，以及商品類目、賣家店鋪等次元資訊。

4.2 事務事實表

訂單作為交易行為的核心載體，直覺反映了交易的狀況。訂單的流轉會産生很多業務過程，而下單、支付和成功完結三個業務過程是整個 訂單的關鍵節點。擷取這三個業務過程的筆數、金額以及轉化率是日常 資料統計分析的重點，事務事實表設計可以很好地滿足這個需求。本節 将介紹三種不同僚務事實表的設計方式，以及在淘寶交易訂單中關于郵 費和折扣分攤到子訂單的算法。

4.2.1 設計過程

任何類型的事件都可以被了解為一種事務。比如交易過程中的建立 訂單、買家付款，物流過程中的攬貨、發貨、簽收，退款中的申請退 款、 申請小二介入等，都可以被了解為一種事務。事務事實表， 即針對這些過程建構的一類事實表，用以跟蹤定義業務過程的個體行為，提供豐富的分析能力，作為資料倉庫原子的明細資料。下面以淘寶交易事務事實表為例，闡述事務事實表的一般設計過程。

1. 選擇業務過程

圖 4.1 給出了淘寶交易訂單的流轉過程，其中介紹了四個重要過程：建立訂單、買家付款、 賣家發貨、買家 确認收貨，即下單、支付 、 發貨和成功完結四個業務過程。這四個業務過程不僅是交易過程中的重要時間節點 ，而且也是下遊統計分析的重點，是以淘寶交易事務事實表 設計着重從這四個業務過程進行展開 。

Kimball 次元模組化理論認為，為了便于進行獨立的分析研究，應該為每個業務過程建立一個事實表。對于是否将不同業務過程放到同一個事實表 中，将在下一節中詳細介紹。

1. 确定粒度

業務過程標明以後，就要針對每個業務過程确定一個粒度，即确定事務事實表每一行所表達的細節層次。下面先介紹淘寶訂單的産生過程。

對于每一種商品産生的訂單就稱為子訂單，子訂單記錄了父訂單的訂單号，并且有子訂單标志。如果在同一個店鋪隻購買了一種商品，則會将父子訂單進行合并，隻保留一條訂單記錄。如圖 4.2 和圖 4.3 所示示例。

賣家發貨這個業務過程可以選擇子訂單粒度，即将每個子訂 單作為賣家發貨事實表的一個細節。然而，在實際操作中發現，賣家發貨更多的是物流單粒度而非子訂單粒度，同 一個子訂單可以拆開成多個物流單進行發貨。在事務事實表設 計過程中，秉承确定為最細粒度的原則，是以對于賣家發貨确定為物流單粒度，和其他三個業務過程不同，這樣可以更好地給下遊統計分析帶來靈活性。

1. 确定次元

標明好業務過程并且确定粒度後，就可以确定次元資訊了。在淘寶交易事務事實表設計過程中，按照經常用于統計分析的場景，确定次元包含: 買家、賣家、商品、商品類目、發貨地區、收貨地區、父訂單次元以及雜 項次元。由于訂單的屬性較多，比如訂單的業務類型、是否無線交易、訂單的 attributes 屬性等，對于這些使用較多卻又無法歸屬到上述買賣家或商品次元中的屬性，則建立一個雜項次元進行存放，如圖 4.4所示。

1. 确定事實

作為過程度量的核心，事實表應該包含與其描述過程有關的所有事實。以淘寶交易事務事實表為例，標明三個業務過程一一下單、支付和 成功完結，不同的業務過程擁有不同的事實。比如在下單業務過程中， 需要包含下單金額、下單數量、下單分攤金額；在支付業務過程中，包含支付金額、分攤郵費、折扣金額、紅包金額、積分金額；在完結業務過程中包含确認收貨金額等。由于粒度是子訂單，是以對于一些父訂單上的金額需要分攤到子訂單上，比如父訂單郵費、父訂單折扣等。

5.備援次元

在确定次元時，包含了買賣家次元、商品次元、類目次元 、收發貨次元等， Kimball次元模組化理論建議在事實表中隻儲存這些維表的外鍵， 而淘寶交易事務事實表在 Kimball 次元模組化基礎之上做了進 一 步的優 化，将買賣家星級、标簽、店鋪名稱、商品類型、商品特征、商品屬性、 類目層級等次元屬性都備援到事實表中，提高對事實表進行過濾查詢、統計聚合的效率，如圖 4.5 所示 。

4.2.2 單事務事實表

單事務事實表，顧名思義，即針對每個業務過程設計一個事實表。這樣設計的優點不言而喻，可以友善地對每個業務過程進行獨立的分析研究。1688 交易流程則采用這 種模式建構事務事實表。

1688 交易和淘寶交易相 似，主要流程也是下單、支付、發貨和完結，而在這四個關鍵流程中 1688 交易選擇下單和支付兩個業務過程設 計事務事實表，分别是1688交易訂單下單事務事實表和1688交易訂單支付事務事實表。

標明業務過程後，将對每個業務過程确定粒度、次元和事實。對于 1688 交易訂單下單事務事實表，确定子訂單粒度，選擇買家、賣家、商品、父訂單、收貨地區次元，事實包含下單分攤金額和折扣金額，如 圖4.6 所示；而對于 1688 交易訂單支付事務事實表 ，粒度和次元與交易訂單下單事務事實表相同，所表達的事實則不 一樣 ，包含支付金額、支付調整金額和支付優惠等，如圖4.7 所示；

1688 交易針對下單和支付分别建立單事務事實表後，每天的下單記錄則進入當天的下單事務事實表中，每天的支付記錄進入當天的支付事務事實表中，由于事實表具有稀疏性質 ，是以隻有當天資料才會進入當天的事實表中。下面以具體交易訂單為例 ，展示單事務事實表的設計執行個體。

4.2.3 多事務事實表

多事務事實表，将不同的事實放到同一個事實表中，即同一個事實表包含不同的業務過程。多事務事實表在設計時有兩種方法進行事實的處理：

• ①不同業務過程的事實使用不同的事實字段進行存放；
• ②不同業務過程的事實使用同一個事實字段進行存放，但增加一個業務過程标簽。

如何選擇：

• 當不同業務過程的度量比較相似、差異不大時，可以采用第 二種 多事務事實表的設計方式，使用同 一個字段來表示度量資料 。但 這種方式存在一個問題一一在同一個周期内會存在多條記錄（如淘寶收藏商品事務事實表，增加【收藏删除類型】，collect/delete）
• 當不同業務過程的度量差異較大時，可以選擇第一種多事務事實 表的設計方式，将不同業務過程的度量使用不同 字段備援到 表 中，非目前業務過程則置零表示。這種方式所存在的問題是度量字段零值較多（如淘寶交易事務事實表，針對不同業務過程如下單，則打一個是否當天下單的标簽）

4.2.4 兩種事實表對比

1. 業務過程

對于單事務事實表，一個業務過程建立一個事實表，隻反映一個業務過程的事實 ；對于多事務事實表，在同 一個事實表 中反映多個業務過程。多個業務過程是否放到同一 個事實表中，首先需要分析不同業務過 程之間的相 似性和業務源系統。比如淘寶交易的下單、支付和成功完結 這三個業務過程是存在相似性的，都屬于訂單進行中的 一環，并且都來自于交易系統 ，是以适合放到同 一個事務事實表中。

1. 粒度和次元

在考慮是采用單事務事實表還是多事務事實表時，另一個關鍵點就是粒度和次元，在确定好業務過程後，需要基于不同的業務過程确定粒度和次元，當不同業務過程的粒度相同，同時擁有相似的次元時，此時就可以考慮采用多事務事實表。如果粒度不同，則必定是不同的事實表。比如交易中支付和發貨有不同的粒度，則無法将發貨業務過程放到淘寶交易事務事實表中。

1. 事實

對于不同的業務過程，事實往往是不同的，單事務事實表在處理事實上比較友善和靈活，僅僅展現同一個業務過程的事實即可， 而多事務事實表由于有多個業務過程， 是以有更多的事實需要處理。如果單一業務過程的事實較多，同時不同業務過程的事實又不相同，則可以考慮使 用單事務事實表，處理更加清晰 ; 若使用多事務事實表， 則會導緻事實表零值或空值字段較多。

1. 下遊業務使用

單事務事實表對于下遊使用者而言更容易了解 ， 關注哪個業務過程就使用相應的事務事實表；而多事務事實表包含多個業務過程，使用者使用時往往較為困惑。1688 和淘寶交易分别采用了這兩種方式，從日常使用來看，對于淘寶交易事務事實表下遊使用者确實有 一定的學習成本 。

1. 計算存儲成本

針對多個業務過程設計事務事實表，是采用單事務事實表還是多事務事實表，對于資料倉庫的計算存儲成本也是參考點之 一 ，當業務過程 資料來源于同 一個業務系統，具有相同的粒度和次元，且次元較多而事實相對不多時，此時可以考慮使用多事務事實表，不僅其加工計算成本 較低，同時在存儲上也相對節省，是一種較優的處理方式。

4.2.5 父子事實的處理方式

• e.g. 子訂單分攤的有效下單金額和支付金額

4.2.6 事實的設計準則

1. 事實完整性：盡可能多地擷取所有的度量
2. 事實一緻性：事實表中統一計算可以保證度量的一緻性（比如金額由數量*單價先在事實表算出來）
3. 事實可加性：事務事實表中關注 更多的是可加性事實，下遊使用者在聚合統計時更加友善

4.3 周期快照事實表

• 狀态度量，比如 賬戶餘額、買賣家星級、商品庫存、賣家累積交易額等
• 無法聚集，比如溫度等
• 簡稱“快照事實表”：在确定的間隔内對實體的度量進行抽樣，這樣可以很容易地研究實體的路徑成本，而 不需要聚集長期的事務曆史

4.3.1 特性

1. 用快照采樣狀态

1. 快照粒度

• 快照需要采樣的周期以及什麼将被采樣
• e.g. 淘寶交易有針對賣家加類目的每月彙總事實表，每月統計一次， 同時次元也不僅一個，包含了賣家和類目。

1. 密度與稀疏性

• e.g. 針對賣家的曆史至今的下單和支付金額，無論 當天賣家是否有下單支付事實，都會給該賣家記錄一行。

1. 半可加性

• 半可加性事實不能根據時間次元獲得有意義的彙總結 果
• 雖然不能彙總，但可以計算一些平均值

4.3.2 執行個體

• 單次元的每天快照事實表
• 混合次元的每天快照事實表
• 直接使用操作型系統的資料作為周期快照事實表的數 據源進行加工，e.g. 淘寶賣家信用分 / DSR 快照事實表 / 貨值拍照表
• 全量快照事實表：e.g. 淘寶好中差評快照事實表，無事實的事實表，更多關注評價的狀态

4.3.3 注意事項

1. 事務與快照成對設計

• 資料倉庫次元模組化時，對于事務事實表和快照事實表往往都是成對 設計的，互相補充，以滿足更多的下遊統計分析需求，特别是在事務事實表的基礎上可以加工快照事實表，如前面所述的淘寶賣家曆史至今快 照事實表，就是在事務事實表的基礎上加工得到的，既豐富了星形模型， 又降低了下遊分析的成本。

1. 附加事實

• 快照事實表在确定狀态度量時，一般都是儲存采樣周期結束時的狀态度量。但是也有分析需求需要關注上一個采樣周期結束時的狀态度量，而又不願意多次使用快照事實表，是以一般在設計周期快照事實表 時會附加一些上一個采樣周期的狀态度量。

1. 周期到日期度量

• 在介紹淘寶賣家曆史至今快照事實表時，指定了統計周期是賣家曆史至今的一些狀态度量，比如曆史截至當日的下單金額、成交金額等。然 而在實際應用中，也有需要關注自然年至今、季度至今、财年至今的一些狀态度量，是以在确定周期快照事實表的度量時，也要考慮類似的路徑成本， 以滿足更多的統計分析需求。阿裡巴巴資料倉庫在設計周期快照事實表 時，就針對多種周期到日期的度量設計了不同的快照事實表，比如淘寶 賣家财年至今的下單金額、淘寶商品自然年至今的收藏次數等。

4.4 累積快照事實表

• 研究事件之間時間間隔的需求
• 儲存全量資料，存放加工後的事實，并将各次元常用屬性和訂單 雜項次元退化到此表中
• e.g. 統計買家下單到支付的時長、買家支付到賣家發貨的時長、買家從下單到确認收貨的時長等

4.4.1 設計過程

• 累積快照事實表解決的最重要的問題 是統計不同業務過程之間的時間間隔，建議将每個過程的時間間隔作為事實放在事實表中（設計過程同4.2.1）

4.4.2 特點

1. 資料不斷更新
2. 多業務過程日期

4.4.3 特殊處理

1. 非線性過程

• 業務過程的統一
• 針對業務關鍵裡程碑建構全面的流程
• 循環流程的處理：主要問題是解決一個業務過程存在多個裡程碑日期的問題。使用業務過程第一次發生的日期還是最後一次發生的日期，決定權在商業用 戶，而不是設計或開發人員。

1. 多源過程

• 針對多源業務模組化，主要考慮事實表的粒度問題。對于退款，由于每個子訂單可能 存在多次退款，此時如果要将退款相關業務過程加入模型中，則需要和 商業使用者确定存在多次退款時如何取舍，確定模型粒度不變。

1. 業務過程取舍

• 對于多源業務過程，模型的精合度過高，此時需要根據商業使用者需求，選取關鍵的裡程碑。

4.4.4 實體實作

1. 全量表的形式：此全量表一般為日期分區表，每天的 分區存儲昨天的全量資料和當天的增量資料合并的結果，保證每條記錄 的狀态最新。此種方式适用于全量資料較少的情況。
2. 全量表的變化形式：比如針對交易訂單，我們以 200 天作為訂單從産生到消亡的最大間隔。設計最近 200 天的交易訂單累積快照事實表，每天的分 區存儲最近 200 天的交易訂單而 200 天之前的訂單則按照 gmt_create 創 建分區存儲在歸檔表中。
3. 業務實體的結束時間分區：每天的分區存放當天結 束的資料，設計一個時間非常大的分區，比如 3000-12-31 ，存放截至目前未結束的資料。由于每天将當天結束的資料歸檔至當天分區中，時間 非常大的分區資料量不會很大， ETL 性能較好；并且無存儲的浪費，對于業務實體的某具體執行個體，在該表的全量資料中唯一。但接口等原因，存在結束标志的确認問題，有以下兩個方案：

• 使用相關業務系統的業務實體的結束标志作為此業務 系統的結束标志。
• 和前端業務系統确定口徑或使用前端歸檔政策。

4.5 三種事實表的比較

4.6 無事實的事實表

• 事件類的，記錄事件的發生。比如使用者的浏覽日志。
• 條件、範圍或資格類的，記錄次元與次元多對多之間的關系。比如客戶和銷售人員的配置設定情況、産品的促銷範圍等。

4.7 聚集型事實表DWS

• 公共彙總層：比如賣家最近 1 天的交易彙總表、賣家最近 N 天的交易彙總表、賣家自然年交易彙總表等。

4.7.1 聚集的基本原則

• 一緻性。表必須提供與查詢明細粒度資料一緻的查詢結果。
• 避免單一表設計。不要在同一個表中存儲不同層次的聚集資料；否則将會導緻雙重計算或出現更糟糕的事情。在聚集表中有些行 存放按天彙總的交易額，有些行存放按月彙總的交易額，這将會讓使用者産生誤用導緻重複計算。行之有效的另一種方法是把按天與按月彙總的交易額用兩列存放，但是需要在列名或者列注釋上能分辨出來。
• 聚集粒度可不同。聚集并不需要保持與原始明細粒度資料一樣的粒度，聚集隻關心所需要查詢的次元。

4.7.2 聚集的基本步驟

1. 确定聚集次元

在原始明細模型中會存在多個描述事實的次元，如日期、商品類别、 賣家等，這時候需要确定根據什麼次元聚集，如果隻關心商品的交易額 情況，那麼就可以根據商品次元聚集資料。

1. 确定一緻性上鑽

• 這時候要關心是按月彙總還是按天彙總，是按照商品彙總還是按照 類目彙總，如果按照類目彙總，還需要關心是按照大類彙總還是小類彙 總。當然，我們要做的隻是了解使用者需要什麼，然後按照他們想要的進行聚集。

1. 确定聚集事實

• 在原始明細模型中可能會有多個事實的度量，比如在交易中有交易 額、交易數量等，這時候要明确是按照交易額彙總還是按照成交數量彙總。

4.7.3 阿裡公共彙總層

1. 基本原則

• 資料公用性
• 不跨資料域
• 區分統計周期：在表的命名上要能說明資料的統計周期，如 1d 表示最近 1 天，td 表示截至當天， nd 表示最近 N 天

1. 交易彙總表設計

• 最近1天商品粒度彙總表
• 最近N天賣家粒度彙總表
• 最近1天賣家、買家、商品粒度彙總表
• 最近1天二級類目彙總表

4.7.4 聚集補充說明

• 聚集是不跨越事實的：橫向鑽取是針對多個事實基于一緻性次元進行的分析，很多時候采用融合事實表，預先存放橫向鑽取的結果，進而提高查詢性能。
• 聚集帶來的問題：當子類目對應的一級類目發生變更時，先前存在的、已經被彙總到聚集表中的資料需要被重新調整。這一額外工作随着業務複雜性的增加，會導緻多數 ETL 人員選擇簡單強力的方法，删除并重新聚集資料。來源：五分鐘學大資料