一、大數據領域建模綜述

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 指標體系

一、基本原則

組成體系之間的關系 派生指標由原子指標、時間周期修飾詞、若干其他修飾詞組合得到 ?

原子指標、修飾類型及修飾詞，直接歸屬在業務過程下，其中修飾詞繼承修飾類型的數據域 派生指標可以選擇多個修飾詞，修飾詞之間的關系為"或"或者"且"，由派生指標具體語義決定 派生指標唯一歸屬一個原子指標，繼承原子指標的數據域，與修飾詞的數據域無關 原子指標有確定的英文字段名、數據類型和算法說明；派生指標要繼承原子指標的英文名、數據類型和算法要求 命名約定 命名所用術語。指標命名盡量使用英文簡寫，其次是英文。太長也可以考慮漢語拼音首字母 業務過程。英文名：用英文或英文的縮寫或者中文拼音簡寫 原子指標。英文名：動作+度量 修飾詞。只有時間周期才會有英文名 派生指標。英文名：原子指標英文名+時間周期修飾詞(3位,例如_1d)+序號(4位，例如_001)

算法 算法概述一一算法對應的用戶容易理解的闡述。 舉例一一通過具體例子幫助理解指標算法。 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實施過程

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

（1）數據調研

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

（2）架構設計

數據域劃分

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

構建總線矩陣

在進行充分的業務調研和需求調研后，就要構建總線矩陣了。需要 做兩件事情：明確每個數據域下有哪些業務過程；業務過程與哪些維度相關，并定義每個數據域下的業務過程和維度。

規范定義

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

模型設計

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

總結

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

三、維度設計 3.1 維度設計基礎

3.1.1 維度的基本概念

維度建模中，將度量稱為“事實”，將環境描述為“維度”，維度是用于分析事實所需要的多樣環境。例如，在分析交易過程時，可以通過買家、賣家、商品和時間等維度描述交易發生的環境。 維度所包含的表示維度的列，稱為維度屬性。維度屬性是查詢約束條件、分組和報表標簽生成的基本來源，是數據易用性的關鍵。 維度使用主鍵標識其唯一性，主鍵也是確保與之相連的任何事實表 之間存在引用完整性的基礎。

3.1.2 維度的基本設計方法

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

確認維度屬性的幾點提示：

盡可能生成豐富的維度屬性 盡可能多地給出包括一些富有意義的文字性描述 區分數值型屬性和事實 如果通常用于查詢約束條件或分組統計，則是作為維度屬性；如果通常 用于參與度量的計算，則是作為事實。比如商品價格，可以用于查詢約 束條件或統計價格區間的商品數量，此時是作為維度屬性使用的；也可 以用于統計某類目下商品的平均價格，此時是作為事實使用的。另外， 如果數值型字段是離散值，則作為維度屬性存在的可能性較大；如果數 值型宇段是連續值，則作為度量存在的可能性較大，但并不絕對，需要 同時參考宇段的具體用途。 盡量沉淀出通用的維度屬性

3.1.3 一致性維度和交叉探查

共享維表。比如在阿里巴巴的數據倉庫中，商品、賣家、買家、 類目等維度有且只有一個。所以基于這些公共維度進行的交叉探查不會存在任何問題。 一致性上卷。其中一個維度的維度屬性是另一個維度的維度屬性 的子集，且兩個維度的公共維度屬性結構和內容相同。比如在阿 里巴巴的商品體系中，有商品維度和類目維度，其中類目維度的 維度屬性是商品維度的維度屬性的子集，且有相同的維度屬性和 維度屬性值。這樣基于類目維度進行不同業務過程的交叉探查也 不會存在任何問題。 交叉屬性。兩個維度具有部分相同的維度屬性。比如在商品維度中具有類目屬性，在賣家維度中具有主營類目屬性，兩個維度具有相同的類目屬性，則可以在相同的類目屬性上進行不同業務過程的交叉探查。 3.2 維度設計高級主題

3.2.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） 插入新的維度行。保留歷史數據，維度值變化前的事實和過去的維度值關聯，維度值變化后的事實和當前的維度值關聯。 添加維度列。采用第二種處理方式不能將變化前后記錄的事實歸一為變化前的維度或者歸一為變化后的維度（不同業務部門需要統計各自的業績，則需 要保留歷史數據）

3.3.2 快照維表

在 Kimball 的維度建模中，必須使用代理鍵（不具有業務含義的鍵，區別于自然鍵）作為每個維表的主鍵，用于處理緩慢變化維。 阿里不使用代理鍵的原因：數據量大、ETL復雜化；不直接使用拉鏈表的原因：解釋成本高、隨著時間的推移，分區數量會極度膨脹 阿里通過快照方式，每天保留一份全量快照數據，簡單而有效，方便好理解，但造成存儲浪費，因此配合極限存儲。

3.3.3 極限存儲

透明化 底層的數據還是歷史拉鏈存儲，但是上層做一個視圖操作或者在 Hive 里做一個 hook ，通過分析語句的語法樹，把對極限存儲前的表的 查詢轉換成對極限存儲表的查詢。 分月做歷史拉鏈表 每個月月初重新開始做歷史拉鏈表

局限性：首先，其產出效率很低，大部分極限存儲通常需要 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，因此在維度模型中對層次結構進行處理 層次結構扁平化

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

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

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 事實表設計方法

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

選擇業務過程及確定事實表類型

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

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

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

聲明粒度

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

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

確定維度

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

確定事實

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

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

冗余維度

在傳統的維度建模的星形模型中，對維度的處理是需要單獨存放在專門的維表中的，通過事實表的外鍵獲取維度。這樣做的目的是為了減少事實表的維度冗余，從而減少存儲消耗。而在大數據的事實表模型設計中，考慮更多的是提高下游用戶的使用效率，降低數據獲取的復雜性，減少關聯的表數量。所以通常事實表中會冗余方便下游用戶使用的常用維度，以實現對事實表的過濾查詢、控制聚合層次、排序數據以及定義主從關系等操作。

比如在淘寶訂單付款事務事實表中，通常會冗余大量的常用維度字段，以及商品類目、賣家店鋪等維度信息。

4.2 事務事實表

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

4.2.1 設計過程

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

選擇業務過程

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

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

確定粒度

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

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

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

確定維度

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

確定事實

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

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 兩種事實表對比

業務過程

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

粒度和維度

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

事實

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

下游業務使用

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

計算存儲成本

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

4.2.5 父子事實的處理方式e.g. 子訂單分攤的有效下單金額和支付金額

4.2.6 事實的設計準則

事實完整性：盡可能多地獲取所有的度量 事實一致性：事實表中統一計算可以保證度量的一致性（比如金額由數量*單價先在事實表算出來） 事實可加性：事務事實表中關注 更多的是可加性事實，下游用戶在聚合統計時更加方便 4.3 周期快照事實表 狀態度量，比如 賬戶余額、買賣家星級、商品庫存、賣家累積交易額等 無法聚集，比如溫度等 簡稱“快照事實表”：在確定的間隔內對實體的度量進行抽樣，這樣可以很容易地研究實體的度量值，而 不需要聚集長期的事務歷史

4.3.1 特性

用快照采樣狀態

快照粒度 快照需要采樣的周期以及什么將被采樣 e.g. 淘寶交易有針對賣家加類目的每月匯總事實表，每月統計一次， 同時維度也不僅一個，包含了賣家和類目。 密度與稀疏性 e.g. 針對賣家的歷史至今的下單和支付金額，無論 當天賣家是否有下單支付事實，都會給該賣家記錄一行。 半可加性 半可加性事實不能根據時間維度獲得有意義的匯總結 果 雖然不能匯總，但可以計算一些平均值

4.3.2 實例

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

4.3.3 注意事項

事務與快照成對設計 數據倉庫維度建模時，對于事務事實表和快照事實表往往都是成對 設計的，互相補充，以滿足更多的下游統計分析需求，特別是在事務事實表的基礎上可以加工快照事實表，如前面所述的淘寶賣家歷史至今快 照事實表，就是在事務事實表的基礎上加工得到的，既豐富了星形模型， 又降低了下游分析的成本。 附加事實 快照事實表在確定狀態度量時，一般都是保存采樣周期結束時的狀態度量。但是也有分析需求需要關注上一個采樣周期結束時的狀態度量，而又不愿意多次使用快照事實表，因此一般在設計周期快照事實表 時會附加一些上一個采樣周期的狀態度量。 周期到日期度量 在介紹淘寶賣家歷史至今快照事實表時，指定了統計周期是賣家歷史至今的一些狀態度量，比如歷史截至當日的下單金額、成交金額等。然 而在實際應用中，也有需要關注自然年至今、季度至今、財年至今的一些狀態度量，因此在確定周期快照事實表的度量時，也要考慮類似的度量值， 以滿足更多的統計分析需求。阿里巴巴數據倉庫在設計周期快照事實表 時，就針對多種周期到日期的度量設計了不同的快照事實表，比如淘寶 賣家財年至今的下單金額、淘寶商品自然年至今的收藏次數等。 4.4 累積快照事實表 研究事件之間時間間隔的需求 保存全量數據，存放加工后的事實，并將各維度常用屬性和訂單 雜項維度退化到此表中 e.g. 統計買家下單到支付的時長、買家支付到賣家發貨的時長、買家從下單到確認收貨的時長等

4.4.1 設計過程

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

4.4.2 特點

數據不斷更新 多業務過程日期

4.4.3 特殊處理

非線性過程 業務過程的統一 針對業務關鍵里程碑構建全面的流程 循環流程的處理：主要問題是解決一個業務過程存在多個里程碑日期的問題。使用業務過程第一次發生的日期還是最后一次發生的日期，決定權在商業用 戶，而不是設計或開發人員。 多源過程 針對多源業務建模，主要考慮事實表的粒度問題。對于退款，由于每個子訂單可能 存在多次退款，此時如果要將退款相關業務過程加入模型中，則需要和 商業用戶確定存在多次退款時如何取舍，確保模型粒度不變。 業務過程取舍 對于多源業務過程，模型的精合度過高，此時需要根據商業用戶需求，選取關鍵的里程碑。

4.4.4 物理實現

全量表的形式：此全量表一般為日期分區表，每天的 分區存儲昨天的全量數據和當天的增量數據合并的結果，保證每條記錄 的狀態最新。此種方式適用于全量數據較少的情況。 全量表的變化形式：比如針對交易訂單，我們以 200 天作為訂單從產生到消亡的最大間隔。設計最近 200 天的交易訂單累積快照事實表，每天的分 區存儲最近 200 天的交易訂單而 200 天之前的訂單則按照 gmt_create 創 建分區存儲在歸檔表中。 業務實體的結束時間分區：每天的分區存放當天結 束的數據，設計一個時間非常大的分區，比如 3000-12-31 ，存放截至當前未結束的數據。由于每天將當天結束的數據歸檔至當天分區中，時間 非常大的分區數據量不會很大， ETL 性能較好；并且無存儲的浪費，對于業務實體的某具體實例，在該表的全量數據中唯一。但接口等原因，存在結束標志的確認問題，有以下兩個方案： 使用相關業務系統的業務實體的結束標志作為此業務 系統的結束標志。 和前端業務系統確定口徑或使用前端歸檔策略。 4.5 三種事實表的比較

?

4.6 無事實的事實表

事件類的，記錄事件的發生。比如用戶的瀏覽日志。 條件、范圍或資格類的，記錄維度與維度多對多之間的關系。比如客戶和銷售人員的分配情況、產品的促銷范圍等。

4.7 聚集型事實表DWS

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

4.7.1 聚集的基本原則

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

4.7.2 聚集的基本步驟

確定聚集維度

在原始明細模型中會存在多個描述事實的維度，如日期、商品類別、 賣家等，這時候需要確定根據什么維度聚集，如果只關心商品的交易額 情況，那么就可以根據商品維度聚集數據。

確定一致性上鉆 這時候要關心是按月匯總還是按天匯總，是按照商品匯總還是按照 類目匯總，如果按照類目匯總，還需要關心是按照大類匯總還是小類匯 總。當然，我們要做的只是了解用戶需要什么，然后按照他們想要的進行聚集。 確定聚集事實 在原始明細模型中可能會有多個事實的度量，比如在交易中有交易 額、交易數量等，這時候要明確是按照交易額匯總還是按照成交數量匯總。

4.7.3 阿里公共匯總層

基本原則 數據公用性 不跨數據域 區分統計周期：在表的命名上要能說明數據的統計周期，如 1d 表示最近 1 天，td 表示截至當天， nd 表示最近 N 天 交易匯總表設計 最近1天商品粒度匯總表 最近N天賣家粒度匯總表 最近1天賣家、買家、商品粒度匯總表 最近1天二級類目匯總表

4.7.4 聚集補充說明

聚集是不跨越事實的：橫向鉆取是針對多個事實基于一致性維度進行的分析，很多時候采用融合事實表，預先存放橫向鉆取的結果，從而提高查詢性能。 聚集帶來的問題：當子類目對應的一級類目發生變更時，先前存在的、已經被匯總到聚集表中的數據需要被重新調整。這一額外工作隨著業務復雜性的增加，會導致多數 ETL 人員選擇簡單強力的方法，刪除并重新聚集數據。