第1章 大數(shù)據(jù)領(lǐng)域建模綜述

1.1 為什么需要數(shù)據(jù)建模

有結(jié)構(gòu)地分類組織和存儲是我們面臨的一個挑戰(zhàn)。

數(shù)據(jù)模型強(qiáng)調(diào)從業(yè)務(wù)、數(shù)據(jù)存取和使用角度合理存儲數(shù)據(jù)。

數(shù)據(jù)模型方法，以便在性能、成本、效率之間取得最佳平衡

成本：良好的數(shù)據(jù)模型能極大地減少不必要的數(shù)據(jù)冗余，也能實現(xiàn)計算結(jié)果復(fù)用，極大地降低大數(shù)據(jù)系統(tǒng)中的存儲和計算成本。 效率：良好的數(shù)據(jù)模型能極大地改善用戶使用數(shù)據(jù)的體驗，提高使用數(shù)據(jù)的效率。 質(zhì)量：良好的數(shù)據(jù)模型能改善數(shù)據(jù)統(tǒng)計口徑的不一致性，減少數(shù)據(jù)計算錯誤的可能性。 1.2 關(guān)系數(shù)據(jù)庫系統(tǒng)和數(shù)據(jù)倉庫 1.3 從 OLTP 和 OLAP 系統(tǒng)的區(qū)別看模型方法論的選擇 OLTP 系統(tǒng)通常面向的主要數(shù)據(jù)操作是隨機(jī)讀寫，主要采用滿足 3NF 的實體關(guān)系模型存儲數(shù)據(jù)，從而在事務(wù)處理中解決數(shù)據(jù)的冗余和一 致性問題： OLAP 系統(tǒng)面向的主要數(shù)據(jù)操作是批量讀寫，事務(wù)處理中 的一致性不是OLAP 所關(guān)注的，其主要關(guān)注數(shù)據(jù)的整合，以及在一次性的復(fù)雜大數(shù)據(jù)查詢和處理中的性能，因此它需要采用一些不同的數(shù)據(jù)建模方法。 1.4 典型的數(shù)據(jù)倉庫建模方法論

1.4.1 ER 模型

采用 ER模型建設(shè)數(shù)據(jù)倉庫模型的出發(fā)點是整合數(shù)據(jù)，將各個系統(tǒng)中的數(shù)據(jù)以整個企業(yè)角度按主題進(jìn)行相似性組合和合并，并進(jìn)行一致性處理，為數(shù)據(jù)分析決策服務(wù)，但是并不能直接用于分析決策。 ER 模型在實踐中最典型的代表是 Teradata 公司基于金融業(yè)務(wù)發(fā)布 的 FS-LDM（Financial Services Logical Data Model），它通過對金融業(yè)務(wù)的高度抽象和總結(jié)，將金融業(yè)務(wù)劃分為10大主題，并以設(shè)計面向金融倉庫模型的核心為基礎(chǔ)，企業(yè)基于此模型做適當(dāng)調(diào)整和擴(kuò)展就能快速落地實施。

1.4.2 維度模型

維度建模從分析決策的需求出發(fā)構(gòu)建模型，為分析需求服務(wù)，因此它重點關(guān)注用戶如何更快速地完成需求分析，同時具有較好的大規(guī)模復(fù)雜查詢的響應(yīng)性能。其典型的代表是星形模型，以及在一些特殊場景下使用的雪花模型。設(shè)計步驟通常如下： 選擇需要進(jìn)行分析決策的業(yè)務(wù)過程。業(yè)務(wù)過程可以是單個業(yè)務(wù)事件，比如交易的支付、退款等；也可以是某個事件的狀態(tài)，比如當(dāng)前的賬戶余額等；還可以是一系列相關(guān)業(yè)務(wù)事件組成的業(yè)務(wù)流程，具體需要看我們分析的是某些事件發(fā)生情況，還是當(dāng)前狀態(tài)，或是事件流轉(zhuǎn)效率。 選擇粒度。在事件分析中，我們要預(yù)判所有分析需要細(xì)分的程度，從而決定選擇的粒度。粒度是維度的一個組合。 識別維表。選擇好粒度之后，就需要基于此粒度設(shè)計維表，包括維度屬性，用于分析時進(jìn)行分組和篩選。 選擇事實。確定分析需要衡量的指標(biāo)。

1.4.3 Data Vault 模型

它強(qiáng)調(diào)建立一個可審計的基礎(chǔ)數(shù)據(jù)層，也就是強(qiáng)調(diào)數(shù)據(jù)的歷史 性、可追溯性和原子性，而不要求對數(shù)據(jù)進(jìn)行過度的一致性處理和整合；同時它基于主題概念將企業(yè)數(shù)據(jù)進(jìn)行結(jié)構(gòu)化組織，并引入了更進(jìn)一步的范式處理來優(yōu)化模型，以應(yīng)對下游、系統(tǒng)變更的擴(kuò)展性。

1.4.4 Anchor 模型

Anchor 對 Data Vault 模型做了進(jìn)一步規(guī)范化處理， Lars.Ronnback 的初衷是設(shè)計一個高度可擴(kuò)展的模型，其核心思想是所有的擴(kuò)展只是添加而不是修改，因此將模型規(guī)范到 6NF ，基本變成了k-v 結(jié)構(gòu)化模型。 1.5 阿里巴巴數(shù)據(jù)模型實踐綜述 第一個階段：構(gòu)建在 Oracle 上，數(shù)據(jù)完全以滿足報表需求為目的 第二個階段：引入了當(dāng)時 MPP 架構(gòu)體系的 Greenplum，ODL（操作數(shù)據(jù)層）+BDL（基礎(chǔ)數(shù)據(jù)層）+IDL（接口數(shù)據(jù)層）+ADL （應(yīng)用數(shù)據(jù)層）；BDL希望引入 ER 模型，加強(qiáng) 數(shù)據(jù)的整合，構(gòu)建一致的基礎(chǔ)數(shù)據(jù)模型，但構(gòu)建 ER 模型時遇到了比較大的困難和挑戰(zhàn)，互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展、人員的快速變化、業(yè)務(wù)知識功底的不夠全面，導(dǎo)致 ER 模型設(shè)計遲遲不能產(chǎn)出。至此，我們也得到了一個經(jīng)驗：在不太成熟、快速變化的業(yè)務(wù)面前，構(gòu)建 ER 模型的風(fēng)險非常大，不太適合去構(gòu)建 ER 模型。 第三個階段：迎來了以Hadoop 為代表的分布式存儲計算平臺的快速發(fā)展，同時阿里巴 巴集團(tuán)自主研發(fā)的分布式計算平臺 MaxCompute 也在緊鑼密鼓地進(jìn)行著。以 Kimball 的維度建模為核心理念的模型方法論，構(gòu)建了阿里巴巴集團(tuán)的公共層模型數(shù)據(jù)架構(gòu)體系。 數(shù)據(jù)公共層建設(shè)的目的是著力解決數(shù)據(jù)存儲和計算的共享問題。數(shù)據(jù)每年以近 2.5 倍的速度在增長，數(shù)據(jù)的增長遠(yuǎn)遠(yuǎn)超過業(yè)務(wù)的增長。 統(tǒng)一化的集團(tuán)數(shù)據(jù)整合及管理的方法體系“OneData”：一致性的指標(biāo)定義體系、模型設(shè)計方法體系以及配套工具。 第2章 阿里巴巴數(shù)據(jù)整合及管理體系 面對爆炸式增長的數(shù)據(jù)，如何建設(shè)高效的數(shù)據(jù)模型和體系，對這些 數(shù)據(jù)進(jìn)行有序和有結(jié)構(gòu)地分類組織和存儲，避免重復(fù)建設(shè)和數(shù)據(jù)不一致性，保證數(shù)據(jù)的規(guī)范性，一直是大數(shù)據(jù)系統(tǒng)建設(shè)不斷追求的方向。 2.1 概述

核心：從業(yè)務(wù)架構(gòu)設(shè)計（如何快速上手工作）到模型設(shè)計，從數(shù)據(jù)研發(fā)到數(shù)據(jù)服務(wù)，做到數(shù)據(jù)可管理、可追溯、可規(guī)避重復(fù)建設(shè)。

2.1.1 定位及價值

建設(shè)統(tǒng)一的、規(guī)范化的數(shù)據(jù)接入層（ ODS ）和數(shù)據(jù)中間層（ DWD 和 DWS ），通過數(shù)據(jù)服務(wù)和數(shù)據(jù)產(chǎn)品，完成服務(wù)于阿里巴巴的大數(shù)據(jù)系 統(tǒng)建設(shè)，即數(shù)據(jù)公共層建設(shè)。

業(yè)務(wù)板塊：根據(jù)業(yè)務(wù)屬性劃分板塊，板塊之間的指標(biāo)或業(yè)務(wù)重疊性較小。

規(guī)范定義：一套數(shù)據(jù)規(guī)范命名體系，用在模型設(shè)計中

模型設(shè)計：以維度建模理論為基礎(chǔ)，基于維度建?？偩€架構(gòu)，構(gòu)建一致性的維度和事實(進(jìn)行規(guī)范定義)。

2.2 規(guī)范定義

規(guī)范定義指以維度建模作為理論基礎(chǔ)，構(gòu)建總線矩陣，劃分和定義 數(shù)據(jù)域、業(yè)務(wù)過程、維度、度量／原子指標(biāo)、修飾類型、修飾詞、時間周期、派生指標(biāo)。

2.2.1 名詞術(shù)語

數(shù)據(jù)域（主題域）

面向業(yè)務(wù)分析，將業(yè)務(wù)過程或者維度進(jìn)行抽象的集合。業(yè)務(wù)過程可以概括為一個個不可拆分的行為事件，在業(yè)務(wù)過程之下，可以定義指標(biāo)；維度是指度量的環(huán)境，如買家下單事件，買家是維度 。為保障整個體系的生命力 ， 數(shù)據(jù)域是需要抽象提煉，并且長期維護(hù)和更新的 ， 但不輕易變動。 常見主題域：用戶、渠道、營銷、流量、交易、財務(wù)、商品

業(yè)務(wù)過程

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

時間周期

用來明確數(shù)據(jù)統(tǒng)計的時間范圍或者時間點，如最近 30天、自然周、截至當(dāng)日等

修飾類型

是對修飾詞的一種抽象劃分 。修飾類型從屬于某個業(yè)務(wù)域，如日志域的訪問終端類型涵蓋無線端、 PC 端等修飾詞

修飾詞

指除了統(tǒng)計維度以外指標(biāo)的業(yè)務(wù)場景限定抽象 。修飾詞隸屬于一種修飾類型，如 在日志域的訪問終端類型下 ， 有修飾詞 PC 端、無線端等

度量/原子指標(biāo)

原子指標(biāo)和度量含義相同，基于某一業(yè)務(wù)事件行為下的度量，是業(yè)務(wù)定義中不可 再拆分的指標(biāo)，具有明確業(yè)務(wù)含義的名詞 ，如支付金額

維度

維度是度量的環(huán)境，用來反映業(yè)務(wù)的一類屬性 ，這類屬性的集合構(gòu)成一個維度 ，也可以稱為實體對象。維度屬于一個數(shù)據(jù)域，如地理維度（其中包括國家、地區(qū)、 省以及城市等級別的內(nèi)容)、時間維度(其中包括年、季、月、周、日等級別的內(nèi)容）

維度屬性

維度屬性隸屬于一個維度 ，如地理維度里面的國家名稱、國家 ID、省份名稱等都屬于維度屬性

派生指標(biāo)

派生指標(biāo)=一個原子指標(biāo)+多個修飾詞(可選)+時間周期+粒度?？梢岳斫鉃閷υ又笜?biāo)業(yè)務(wù)統(tǒng)計范圍的圈定。如原子指標(biāo)：支付金額，最近 1 天海外買家支付金額則為派生指標(biāo)(最近1天為時間周期 ， 海外為修飾詞 ， 買家作為維度，而不作為修飾詞)

2.2.2 指標(biāo)體系

一、基本原則

組成體系之間的關(guān)系 派生指標(biāo)由原子指標(biāo)、時間周期修飾詞、若干其他修飾詞組合得到 原子指標(biāo)、修飾類型及修飾詞，直接歸屬在業(yè)務(wù)過程下，其中修飾詞繼承修飾類型的數(shù)據(jù)域 派生指標(biāo)可以選擇多個修飾詞，修飾詞之間的關(guān)系為"或"或者"且"，由派生指標(biāo)具體語義決定 派生指標(biāo)唯一歸屬一個原子指標(biāo)，繼承原子指標(biāo)的數(shù)據(jù)域，與修飾詞的數(shù)據(jù)域無關(guān) 原子指標(biāo)有確定的英文字段名、數(shù)據(jù)類型和算法說明；派生指標(biāo)要繼承原子指標(biāo)的英文名、數(shù)據(jù)類型和算法要求 命名約定 命名所用術(shù)語。指標(biāo)命名盡量使用英文簡寫，其次是英文。太長也可以考慮漢語拼音首字母 業(yè)務(wù)過程。英文名：用英文或英文的縮寫或者中文拼音簡寫 原子指標(biāo)。英文名：動作+度量 修飾詞。只有時間周期才會有英文名 派生指標(biāo)。英文名：原子指標(biāo)英文名+時間周期修飾詞(3位,例如_1d)+序號(4位，例如_001) 算法 算法概述一一算法對應(yīng)的用戶容易理解的闡述。 舉例一一通過具體例子幫助理解指標(biāo)算法。 SQL 算法說明一一對于派生指標(biāo)給出SQL的寫法或者偽代碼。

二、操作細(xì)則

派生指標(biāo)可以分為三類：事務(wù)型指標(biāo)、存量型指標(biāo)和復(fù)合型指標(biāo)。

事務(wù)型指標(biāo)：是指對業(yè)務(wù)活動進(jìn)行衡量的指標(biāo)。例如新發(fā)商品數(shù)、 重發(fā)商品數(shù)、新增注冊會員數(shù)、訂單支付金額，這類指標(biāo)需維護(hù) 原子指標(biāo)及修飾詞，在此基礎(chǔ)上創(chuàng)建派生指標(biāo)。 存量型指標(biāo)：是指對實體對象(如商品、會員)某些狀態(tài)的統(tǒng)計。例如商品總數(shù)、注冊會員總數(shù)，這類指標(biāo)需維護(hù)原子指標(biāo)及修飾詞，在此基礎(chǔ)上創(chuàng)建派生指標(biāo)，對應(yīng)的時間周期 一般為“歷史截至當(dāng)前某個時間”。 復(fù)合型指標(biāo)：是在事務(wù)型指標(biāo)和存量型指標(biāo)的基礎(chǔ)上復(fù)合而成的。例如瀏覽 UV-下單買家數(shù)轉(zhuǎn)化率 ， 有些需要 創(chuàng) 建新原子指標(biāo)， 有些則可以在事務(wù)型或存量型原子指標(biāo)的基礎(chǔ)上增加修飾詞得到派生指標(biāo)。 2.3 模型設(shè)計

2.3.1 指導(dǎo)理論

數(shù)據(jù)模型的維度設(shè)計主要以維度建模理論為基礎(chǔ)，基于維度數(shù)據(jù)模型總線架構(gòu)，構(gòu)建一致性的維度和事實。

2.3.2 模型層次

操作數(shù)據(jù)層（ODS）：把操作系統(tǒng)數(shù)據(jù)幾乎無處理地存放在數(shù)據(jù)倉庫系統(tǒng)中。 公共維度模型層（CDM）：存放明細(xì)事實數(shù)據(jù)、維表數(shù)據(jù)及公共指標(biāo)匯總數(shù)據(jù) ，其中明細(xì)事實數(shù)據(jù)、維表數(shù)據(jù)一般根據(jù) ODS 層數(shù)據(jù)加工生成 ；公共指標(biāo)匯總數(shù)據(jù)一般根據(jù)維表數(shù)據(jù)和明細(xì)事實數(shù)據(jù)加工生成。 CDM 層又細(xì)分為 DWD 層和 DWS 層，分別是明細(xì)數(shù)據(jù)層和匯總數(shù)據(jù)層，采用維度模型方法作為理論基礎(chǔ) ，更多地采用一些維度退化手法， 將維度退化至事實表中，減少事實表和維表的關(guān)聯(lián) ，提高明細(xì)數(shù)據(jù)表的易用性；同時在匯總數(shù)據(jù)層， 加強(qiáng)指標(biāo)的維度退化， 采取更多的寬表化手段構(gòu)建公共指標(biāo)數(shù)據(jù)層，提升公共指標(biāo)的復(fù)用性，減少重復(fù)加工。其主要功能如下。 組合相關(guān)和相似數(shù)據(jù)：采用明細(xì)寬表，復(fù)用關(guān)聯(lián)計算，減少數(shù)據(jù)掃描。 公共指標(biāo)統(tǒng)一加工：基于 OneData體系構(gòu)建命名規(guī)范、口徑一致 和算法統(tǒng)一 的統(tǒng)計指標(biāo)，為上層數(shù)據(jù)產(chǎn)品、應(yīng)用和服務(wù)提供公共指標(biāo)建立邏輯匯總寬表。 建立一致性維度:建立一致的數(shù)據(jù)分析維表，降低數(shù)據(jù)計算口徑、算法不統(tǒng)一的風(fēng)險。 應(yīng)用數(shù)據(jù)層（ADS）：存放數(shù)據(jù)產(chǎn)品個性化的統(tǒng)計指標(biāo)數(shù)據(jù)，根據(jù) CDM 層與 ODS 層加工生成 。 個性化指標(biāo)加工：不公用性、復(fù)雜性(指數(shù)型、比值型、排名型指標(biāo))。 基于應(yīng)用的數(shù)據(jù)組裝 : 大寬表集市、橫表轉(zhuǎn)縱表、趨勢指標(biāo)串。

阿里巴巴通過構(gòu)建全域的公共層數(shù)據(jù)，極大地控制了數(shù)據(jù)規(guī)模的增長趨勢

模型架構(gòu)圖

數(shù)據(jù)調(diào)用服務(wù)優(yōu)先使用公共維度模型層( CDM )數(shù)據(jù)，當(dāng)公共層沒有數(shù)據(jù)時，需評估是否需要創(chuàng)建公共層數(shù)據(jù)，當(dāng)不需要建設(shè)公用的公共層時，方可直接使用操作數(shù)據(jù)層( ODS)數(shù)據(jù)。應(yīng)用數(shù)據(jù)層( ADS) 作為產(chǎn)品特有的個性化數(shù)據(jù)一般不對外提供數(shù)據(jù)服務(wù)，但是 ADS 作為被服務(wù)方也需要遵守這個約定。

2.3.3 基本原則

高內(nèi)聚和低耦合

一個邏輯或者物理模型由哪些記錄和字段組成，應(yīng)該遵循最基本的軟件設(shè)計方法論的高內(nèi)聚和低耦合原則。主要從數(shù)據(jù)業(yè)務(wù)特性和訪問特性兩個角度來考慮：將業(yè)務(wù)相近或者相關(guān)、粒度相同的數(shù)據(jù)設(shè)計為一個邏輯或者物理模型；將高概率同時訪問的數(shù)據(jù)放一起，將低概率同時訪問的數(shù)據(jù)分開存儲。

核心模型與擴(kuò)展模型分離

建立核心模型與擴(kuò)展模型體系，核心模型包括的字段支持常用的核心業(yè)務(wù)，擴(kuò)展模型包括的字段支持個性化或少量應(yīng)用的需要 ，不能讓擴(kuò)展模型的宇段過度侵入核心模型，以免破壞核心模型的架構(gòu)簡潔性與可維護(hù)性。

公共處理邏輯下沉及單一

越是底層公用的處理邏輯越應(yīng)該在數(shù)據(jù)調(diào)度依賴的底層進(jìn)行封裝與實現(xiàn)，不要讓公用的處理邏輯暴露給應(yīng)用層實現(xiàn)，不要讓公共邏輯多處同時存在。

成本與性能平衡

適當(dāng)?shù)臄?shù)據(jù)冗余可換取查詢和刷新性能，不宜過度冗余與數(shù)據(jù)復(fù)制。

數(shù)據(jù)可回滾

處理邏輯不變，在不同時間多次運(yùn)行數(shù)據(jù)結(jié)果確定不變。

一致性

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

命名清晰、可理解

表命名需清晰、一致，表名需易于消費(fèi)者理解和使用。

2.4 模型實施

2.4.1 業(yè)界常用模型實施過程

構(gòu)建維度模型一般要經(jīng)歷四個階段：

第一個階段是高層模型設(shè)計時期 ，定義業(yè)務(wù)過程維度模型的范圍，提供每種星形模式的技術(shù)和功能描述；直接產(chǎn)出目標(biāo)是創(chuàng)建高層維度模型圖，它是對業(yè)務(wù)過程中的維表和事實表的圖形描述。確定維表創(chuàng)建初始屬性列表，為每個事實表創(chuàng)建提議度量； 第二個階段是詳細(xì)模型設(shè)計時期，對每個星形模型添加屬性和度量信息；確定每個維表的屬性和每個事實表的度量，并確定信息來源的位置、定義，確定屬性和度量如何填入模型的初步業(yè)務(wù)規(guī)則。 第三個階段是進(jìn)行模型的審查、再設(shè)計和驗證，本階段主要召集相關(guān)人員進(jìn)行模型的審查和驗證，根據(jù)審查結(jié)果對詳細(xì)維度進(jìn)行再設(shè)計。 第四個階段是產(chǎn)生詳細(xì)設(shè)計文檔，提交 ETL 設(shè)計和開發(fā)，最后，完成模型詳細(xì)設(shè)計文檔，提交 ETL 開發(fā)人員，進(jìn)入 ETL 設(shè)計和開發(fā)階段，由 ETL 人員完成物理模型的設(shè)計和開發(fā)。

2.4.2 OneData實施過程

指導(dǎo)方針 首先，在建設(shè)大數(shù)據(jù)數(shù)據(jù)倉庫時，要進(jìn)行充分的業(yè)務(wù)調(diào)研和需求分析。這是數(shù)據(jù)倉庫建設(shè)的基石，業(yè)務(wù)調(diào)研和需求分析做得是否充分直接決定了數(shù)據(jù)倉庫建設(shè)是否成功。 其次，進(jìn)行數(shù)據(jù)總體架構(gòu)設(shè)計，主要是根據(jù)數(shù)據(jù)域?qū)?shù)據(jù)進(jìn)行劃分；按照維度建模理論，構(gòu)建總線矩陣、抽象出業(yè)務(wù)過程和維度。 再次，對報表需求進(jìn)行抽象整理出相關(guān)指標(biāo)體系， 使用 OneData 工具完成指標(biāo)規(guī)范定義和模型設(shè)計。 最后，就是代碼研發(fā)和運(yùn)維。 實施工作流

（1）數(shù)據(jù)調(diào)研

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

（2）架構(gòu)設(shè)計

數(shù)據(jù)域劃分

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

構(gòu)建總線矩陣

在進(jìn)行充分的業(yè)務(wù)調(diào)研和需求調(diào)研后，就要構(gòu)建總線矩陣了。需要 做兩件事情：明確每個數(shù)據(jù)域下有哪些業(yè)務(wù)過程；業(yè)務(wù)過程與哪些維度相關(guān)，并定義每個數(shù)據(jù)域下的業(yè)務(wù)過程和維度。

規(guī)范定義

規(guī)范定義主要定義指標(biāo)體系，包括原子指標(biāo)、修飾詞、時間周期和 派生指標(biāo)。

模型設(shè)計

模型設(shè)計主要包括維度及屬性的規(guī)范定義，維表、明細(xì)事實表和匯 總事實表的模型設(shè)計。

總結(jié)

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

第3章 維度設(shè)計 3.1 維度設(shè)計基礎(chǔ)

3.1.1 維度的基本概念

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

3.1.2 維度的基本設(shè)計方法

選擇維度或新建維度。須保證維度的唯一性。 確定主維表。一般是ODS表，直接與業(yè)務(wù)系統(tǒng)同步。 確定相關(guān)維表。確定哪些表和主維表存在關(guān)聯(lián)關(guān)系，并選擇其中的某些表用于生成維度屬性。 確定維度屬性。第一階段從主維表中選擇維度屬性或生成新的維度屬性；第二階段是從相關(guān)維表中選擇維度屬性或生成新的維度屬性。

確認(rèn)維度屬性的幾點提示：

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

3.1.3 一致性維度和交叉探查

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

3.2.1 維度整合

應(yīng)用間差異： 應(yīng)用在編碼、命名習(xí)慣、度量單位等方面會存在很大的差異。 應(yīng)用出于性能和擴(kuò)展性的考慮，或者隨技術(shù)架構(gòu)的演變，以及業(yè)務(wù)的發(fā)展，采用不同的物理實現(xiàn)。 集成類型（同維度整合）： 命名規(guī)范的統(tǒng)一。表名、字段名等統(tǒng)一。 字段類型的統(tǒng)一。相同和相似字段的字段類型統(tǒng)一。 公共代碼及代碼值的統(tǒng)一。公共代碼及標(biāo)志性字段的數(shù)據(jù)類型、 命名方式等統(tǒng)一。 業(yè)務(wù)含義相同的表的統(tǒng)一。主要依據(jù)高內(nèi)聚、低耦合的理念，在物理實現(xiàn)中，將業(yè)務(wù)關(guān)系大、源系統(tǒng)影響差異小的表進(jìn)行整合：將業(yè)務(wù)關(guān)系小、源系統(tǒng)影響差異大的表進(jìn)行分而置之。通常有如下幾種集成方式： 采用主從表的設(shè)計方式，將兩個表或多個表都有的字段放在主表中（主要基本信息），從屬信息分別放在各自的從表中。對于主表中的主鍵，要么采用復(fù)合主鍵、源主鍵和系統(tǒng)或表 區(qū)別標(biāo)志：要么采用唯一主鍵、“源主鍵和系統(tǒng)或表區(qū)別標(biāo)志”生成新的主鍵。通常建議采用復(fù)合主鍵的方式。 直接合并，共有信息和個性信息都放在同一個表中。如果表字段的重合度較低，則會出現(xiàn)大量空值，對于存儲和易用性會有影響，需謹(jǐn)慎選擇。 不合并，因為源表的表結(jié)構(gòu)及主鍵等差異很大，無法合并，使用數(shù)據(jù)倉庫里的多個表存放各自的數(shù)據(jù)。 表整合： 垂直整合：不同的來源表包含相同的數(shù)據(jù)集，只是存儲 的信息不同，比如主表與擴(kuò)展表的整合，豐富其維度屬性。 水平整合：不同的來源表包含不同的數(shù)據(jù)集，不同子集之間無交叉，也可以存在部分交叉。 存在交叉，則需要去重 不存在交叉，則需要考慮不同子集的自然鍵是否存在沖突 如果不沖突， 則可以考慮將各子集的自然鍵作為整合后的表的自然鍵 設(shè)置超自然鍵，將來源表各子集的自然鍵加工成一個字段作為超自然鍵（即聯(lián)合主鍵，阿里采用該方法，并將來源字段作為分區(qū)字段）

3.2.2 水平拆分

如何設(shè)計維度：

模型設(shè)計重點考慮的三個原則： 擴(kuò)展性：當(dāng)源系統(tǒng)、業(yè)務(wù)邏輯變化時，能通過較少的成本快速擴(kuò) 展模型，保持核心模型的相對穩(wěn)定性。軟件工程中的高內(nèi)聚、低藕合的思想是重要的指導(dǎo)方針之一。 效能：在性能和成本方面取得平衡。通過犧牲一定的存儲成本， 達(dá)到性能和邏輯的優(yōu)化。 易用性：模型可理解性高、訪問復(fù)雜度低。用戶能夠方便地從模型中找到對應(yīng)的數(shù)據(jù)表，并能夠方便地查詢和分析。 模型設(shè)計重點考慮的兩個依據(jù)： 維度的不同分類的屬性差異情況。當(dāng)維度屬性隨類型變化較大時，采用方案 1 。 業(yè)務(wù)的關(guān)聯(lián)程度。兩個相關(guān)性較低的業(yè)務(wù)，稠合在一起弊大于利，對模型的穩(wěn)定性和易用性影響較大，采用方案 2。

方案參考：

方案 1 是將維度的不同分類實例化為不同的維度，同時在主維度中保存公共屬性，適合于當(dāng)維度屬性隨類型變化較大的情形 構(gòu)建商品維度、航旅商品維度：不同分類的商品，其維度屬性可能相同，也可能不同。比如航旅的商品和普 通的淘系商品，都屬于商品，都有商品價格、標(biāo)題、類型、上架時間、 類目等維度屬性，但是航旅的商品除了有這些公共屬性外，還有酒店、 景點、門票、旅行等自己獨(dú)特的維度屬性。 方案 2 是維護(hù)單一維度，包含所有可能的屬性 對淘系商品和 1688 商品構(gòu)建兩個維度，業(yè)務(wù)分析人員一般只針對本數(shù)據(jù)集市進(jìn)行統(tǒng)計分析。1688 業(yè)務(wù)變更，此維度需要變更， 淘寶業(yè)務(wù)變更亦然，穩(wěn)定性很差。

3.2.3 垂直拆分

出于擴(kuò)展性、產(chǎn)出時間、易用性等方面的考慮，設(shè)計主從維度。 主維表存放穩(wěn)定、產(chǎn)出時間早、熱度高的屬性； 從維表存放變化較快、產(chǎn) 出時間晚、熱度低的屬性。 設(shè)計了商品主維度和商品擴(kuò)展維度。其中商品主維度在每日的 1：30 左右產(chǎn)出，而商 品擴(kuò)展維度由于有冗余的產(chǎn)出時間較晚的商品品牌和標(biāo)簽信息，在每日 的 3：00 左右產(chǎn)出。 由于商品擴(kuò)展維度有冗余的庫存等變化較快 的數(shù)據(jù)，對于主維度進(jìn)行緩慢變化的處理較為重要。通過存儲的冗余和計算成本的增加，實現(xiàn)了商品主模型的穩(wěn)定和產(chǎn)出時間的提前。

3.2.4 歷史歸檔

歸檔策略 1：同前臺歸檔策略，在數(shù)據(jù)倉庫中實現(xiàn)前臺歸檔算法，定期對歷史數(shù)據(jù)進(jìn)行歸檔。但存在一些問題，一是前臺歸檔策略復(fù)雜，實現(xiàn)成本較高；二是前臺歸檔策略可能會經(jīng)常變化，導(dǎo)致數(shù)據(jù)倉庫歸檔算法也要隨之變化，維護(hù)和溝通成本較高。此方式適用于前臺歸檔策略 邏輯較為簡單，且變更不頻繁的情況。 歸檔策略 2 ：同前臺歸檔策略，但采用數(shù)據(jù)庫變更日志的方式。對 于如此龐大的數(shù)據(jù)量，阿里巴巴采用的數(shù)據(jù)抽取策略一般是通過數(shù)據(jù)庫 binlog 日志解析獲取每日增量，通過增量merge 全量的方式獲取最新的 全量數(shù)據(jù)。可以使用增量日志的刪除標(biāo)志，作為前臺數(shù)據(jù)歸檔的標(biāo)志。通過此標(biāo)志對數(shù)據(jù)倉庫的數(shù)據(jù)進(jìn)行歸檔。此方式不需要關(guān)注前臺歸檔策 略，簡單易行。但對前臺應(yīng)用的要求是數(shù)據(jù)庫的物理刪除只有在歸檔時 才執(zhí)行，應(yīng)用中的刪除只是邏輯刪除。 歸檔策略 3 ：數(shù)據(jù)倉庫自定義歸檔策略。可以將歸檔算法用簡單、直接的方式實現(xiàn)，但原則是盡量比前臺應(yīng)用晚歸檔、少歸檔。避免出現(xiàn)數(shù)據(jù)倉庫中已經(jīng)歸檔的數(shù)據(jù)再次更新的情況。 如果技術(shù)條件允許，能夠解析數(shù)據(jù)庫 binlog 日志，建議使用歸檔策略 2 ，規(guī)避前臺歸檔算法。具體可以根據(jù)自身數(shù)據(jù)倉庫的實際情況進(jìn)行選擇。 3.3 維度變化

3.3.1 緩慢變化維

在 Kimball 的理論中，有三種處理緩慢變化維的方式，可以根據(jù)業(yè)務(wù)需求來進(jìn)行選擇：

重寫維度值。不保留歷史數(shù)據(jù)， 始終取最新數(shù)據(jù)（假設(shè)業(yè)務(wù)需求方不關(guān)心歷史數(shù)據(jù)，則可以采用方案1） 插入新的維度行。保留歷史數(shù)據(jù)，維度值變化前的事實和過去的維度值關(guān)聯(lián)，維度值變化后的事實和當(dāng)前的維度值關(guān)聯(lián)。 添加維度列。采用第二種處理方式不能將變化前后記錄的事實歸一為變化前的維度或者歸一為變化后的維度（不同業(yè)務(wù)部門需要統(tǒng)計各自的業(yè)績，則需 要保留歷史數(shù)據(jù)）

3.3.2 快照維表

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

3.3.3 極限存儲

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

局限性：首先，其產(chǎn)出效率很低，大部分極限存儲通常需要 t-2 ；其次，對于變化頻率高的數(shù)據(jù)并不能達(dá)到節(jié)約成本的效果。

在做極限存儲前有一個全量存儲表，全量存儲表僅保留最近一段 時間的全量分區(qū)數(shù)據(jù)，歷史數(shù)據(jù)通過映射的方式關(guān)聯(lián)到極限存儲表。即用戶只訪問全量存儲表，所以對用戶來說極限存儲是不可見的。 對于部分變化頻率頻繁的宇段需要過濾。例如，用戶表中存在用戶積分宇段，這種宇段的值每天都在發(fā)生變化，如果不過濾的話，極限存儲就相當(dāng)于每個分區(qū)存儲一份全量數(shù)據(jù)，起不到節(jié)約存儲成本的效果。

3.3.4 微型維度

微型維度的創(chuàng)建是通過將一部分不穩(wěn)定的屬性從主維度中移出，并 將它們放置到擁有自己代理鍵的新表中來實現(xiàn)的。這些屬性相互之間沒有直接關(guān)聯(lián)，不存在自然鍵。通過為每個組合創(chuàng)建新行的一次性過程來加載數(shù)據(jù)。 比如淘寶用戶維度，用戶的注冊日期、年齡、性別、身份信息等基本不會發(fā)生變化，但用戶 VIP 等級、用戶信用評價等級會隨著用戶的行為不斷發(fā)生變化。 其中 VIP 等級共有 8 個值，即 -1 ～6 ；用戶信用評價等級共有 18 個值。假設(shè)基于 VIP 等級和用戶信用評價等級構(gòu)建微型維度，則在此微型維度中共有 8 x 18 個組合，即 144 條記錄，代理鍵可能是 1～ 144

阿里在實踐中并未使用此技術(shù)：

微型維度的局限性：必須是枚舉值，且考慮所有可能組合 ETL 邏輯復(fù)雜 破壞了維度的可瀏覽性 3.4 特殊維度

3.4.1 遞歸層次

維度的遞歸層次，按照層級是否固定分為均衡層次結(jié)構(gòu)（如一級類目、二級類目等）和非均衡層次結(jié)構(gòu)（如公司之間的公司，數(shù)量級別不固定） 遞歸 SQL 成本較高，且很多工具不支持遞歸SQL，因此在維度模型中對層次結(jié)構(gòu)進(jìn)行處理 層次結(jié)構(gòu)扁平化

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

層次橋接表 解決了層次結(jié)構(gòu)扁平化帶來的一些問題，加工邏輯復(fù)雜，使用邏輯復(fù)雜，實際工作很少應(yīng)用

3.4.2 行為維度

理解為事實衍生的維度，按照加工方式劃分：

另一個維度的過去行為，如買家最近一次訪問淘寶的時間、買家最近一次發(fā)生淘寶交易的時間等。 快照事實行為維度，如買家從年初截至當(dāng)前的淘寶交易金額、買 家信用分值、賣家信用分值等。 分組事實行為維度，將數(shù)值型事實轉(zhuǎn)換為枚舉值。如買家從年初截至當(dāng)前的淘寶交易金額按照金額劃分的等級、買家信用分值按 照分?jǐn)?shù)劃分得到的信用等級等。 復(fù)雜邏輯事實行為維度，通過復(fù)雜算法加工或多個事實綜合加工得到。如前面提到的賣家主營類目，商品熱度根據(jù)訪問、收藏、 加入購物車、交易等情況綜合計算得到。

對于行為維度，有兩種處理方式，其中一種是將其冗余至現(xiàn)有的維表中，如將賣家信用等級冗余至賣家維表中另一種是加工成單獨(dú)的行為維表，如賣家主營類目。具體采用哪種方式主要參考如下兩個原則：

第一，避免維度過快增長。比如對商品表進(jìn)行了極限存儲，如果將 商品熱度加入現(xiàn)有的商品維表中，則可能會使每日商品變更占比過高， 從而導(dǎo)致極限存儲效果較差。 第二，避免耦合度過高。比如賣家主營類目，加工邏輯異常復(fù)雜， 如果融合進(jìn)現(xiàn)有的賣家維表中，那么過多的業(yè)務(wù)稠合會導(dǎo)致賣家維表刷新邏輯復(fù)雜、維護(hù)性差、產(chǎn)出延遲等。

3.4.3 多值維度

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

多值維度的處理方式

降低事實表的粒度（子訂單建立事實） 采用多字段（售樓合同，多個買受方，已是最細(xì)粒度；由于個數(shù)不會太多，預(yù)留字段：買受方1，買受方2，買受方3） 橋接表：通過橋接表，則會產(chǎn)生多條重復(fù)記錄，業(yè)務(wù)上注意區(qū)分重復(fù)計算是否符合業(yè)務(wù)邏輯

3.4.4 多值屬性

e.g. 商品和 SKU、屬性、標(biāo)簽都是多對多的關(guān)系

多值屬性的處理方式：

保持維度主鍵不變，將多值屬性放在維度的一個屬性字段中（通過 k-v 對的形式放在 property 字段中，數(shù)據(jù)示例如下：10281239:156426871; 137396765:29229; 137400766:3226633） 保持維度主鍵不變，但將多值屬性放在維度的多個屬性字段中（賣家主營類目，只取TOP 3） 維度主鍵發(fā)生變化，一個維度值存放多條記錄，擴(kuò)展性好，使用方便（比如商品 SKU 維表，對于每個商品，有多少 SKU ，就有多少記錄，主鍵是商品的 ID 和 SKU 的 ID）

3.4.5 雜項維度

雜項維度是由操作型系統(tǒng)中的指示符或者標(biāo)志宇段組合而成的，一般不在一致性維度之列。 將這些字段建立到一個維表中，在事實表中只需保存一個外鍵即可。多個字段的不同取值組成 一條記錄，生成代理鍵，存入維表中，并將該代理鍵保存到相應(yīng)的事實表字段下。建議不要直接使用所有的組合生成完整的雜項維表，在抽取遇到新的組合時生成相應(yīng)的記錄即可。 阿里：存在非枚舉字段，如交易留言、交易屬性、交易標(biāo)簽等；通過子訂單維度實現(xiàn)，且作為邏輯模型，不進(jìn)行物理化。 第4章 事實表設(shè)計 4.1 事實表基礎(chǔ)

4.1.1 事實表特性

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

4.1.2 事實表設(shè)計原則

原則 1：盡可能包含所有與業(yè)務(wù)過程相關(guān)的事實

事實表設(shè)計的目的是為了度量業(yè)務(wù)過程，所以分析哪些事實與業(yè)務(wù)過程有關(guān)是設(shè)計中非常重要的關(guān)注點。在事實表中應(yīng)該盡量包含所有與業(yè)務(wù)過程相關(guān)的事實，即使存在冗余，但是因為事實通常為數(shù)字型，帶來的存儲開銷也不會很大。

原則 2：只選擇與業(yè)務(wù)過程相關(guān)的事實

在選擇事實時，應(yīng)該注意只選擇與業(yè)務(wù)過程有關(guān)的事實。比如在訂單的下單這個業(yè)務(wù)過程的事實表設(shè)計中 ，不應(yīng)該存在支付金額這個表示支付業(yè)務(wù)過程的事實。

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

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

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

粒度的聲明是事實表設(shè)計中不可忽視的重要一步，粒度用于確定事實表中一行所表示業(yè)務(wù)的細(xì)節(jié)層次，決定了維度模型的擴(kuò)展性，在選擇維度和事實之前必須先聲明粒度，且每個維度和事實必須與所定義的粒度保持一致。在設(shè)計事實表的過程中，粒度定義得越細(xì)越好，建議從最低級別的原子粒度開始，因為原子粒度提供了最大限度的靈活性，可以 支持無法預(yù)期的各種細(xì)節(jié)層次的用戶需求。在事實表中，通常通過業(yè)務(wù)描述來表述粒度，但對于聚集性事實表的粒度描述，可采用維度或維度屬性組合的方式。

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

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

原則 6：事實的單位要保持一致

對于同一個事實表中事實的單位，應(yīng)該保持一致。比如原訂單金額、 訂單優(yōu)惠金額、訂單運(yùn)費(fèi)金額這三個事實，應(yīng)該采用一致的計量單位， 統(tǒng) 一 為元或分，以方便使用。

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

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

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

在 Kimball 的維度建模中，通常按照星形模型的方式來設(shè)計，對于 維度的獲取采用的是通過事實表的外鍵關(guān)聯(lián)專門的維表的方式，謹(jǐn)慎使 用退化維度。而在大數(shù)據(jù)領(lǐng)域的事實表設(shè)計中，則大量采用退化維度的 方式，在事實表中存儲各種類型的常用維度信息。這樣設(shè)計的目的主要 是為了減少下游用戶使用時關(guān)聯(lián)多個表的操作，直接通過退化維度實現(xiàn) 對事實表的過濾查詢、控制聚合層次、排序數(shù)據(jù)以及定義主從關(guān)系等。通過增加冗余存儲的方式減少計算開銷，提高使用效率。

4.1.3 事實表設(shè)計方法

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

選擇業(yè)務(wù)過程及確定事實表類型

在明確了業(yè)務(wù)需求以后，接下來需要進(jìn)行詳細(xì)的需求分析，對業(yè)務(wù) 的整個生命周期進(jìn)行分析，明確關(guān)鍵的業(yè)務(wù)步驟，從而選擇與需求有關(guān)的業(yè)務(wù)過程。

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

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

聲明粒度

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

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

確定維度

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

確定事實

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

比如在淘寶訂單付款事務(wù)事實表中，同粒度的事實有子訂單分?jǐn)偟闹Ц督痤~、郵費(fèi)、優(yōu)惠金額等。

冗余維度

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

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

4.2 事務(wù)事實表

訂單作為交易行為的核心載體，直觀反映了交易的狀況。訂單的流轉(zhuǎn)會產(chǎn)生很多業(yè)務(wù)過程，而下單、支付和成功完結(jié)三個業(yè)務(wù)過程是整個 訂單的關(guān)鍵節(jié)點。獲取這三個業(yè)務(wù)過程的筆數(shù)、金額以及轉(zhuǎn)化率是日常 數(shù)據(jù)統(tǒng)計分析的重點，事務(wù)事實表設(shè)計可以很好地滿足這個需求。本節(jié) 將介紹三種不同事務(wù)事實表的設(shè)計方式，以及在淘寶交易訂單中關(guān)于郵 費(fèi)和折扣分?jǐn)偟阶佑唵蔚乃惴ā?

4.2.1 設(shè)計過程

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

選擇業(yè)務(wù)過程

圖 4.1 給出了淘寶交易訂單的流轉(zhuǎn)過程，其中介紹了四個重要過程：創(chuàng)建訂單、買家付款、 賣家發(fā)貨、買家 確認(rèn)收貨，即下單、支付 、 發(fā)貨和成功完結(jié)四個業(yè)務(wù)過程。這四個業(yè)務(wù)過程不僅是交易過程中的重要時間節(jié)點 ，而且也是下游統(tǒng)計分析的重點，因此淘寶交易事務(wù)事實表 設(shè)計著重從這四個業(yè)務(wù)過程進(jìn)行展開 。

Kimball 維度建模理論認(rèn)為，為了便于進(jìn)行獨(dú)立的分析研究，應(yīng)該為每個業(yè)務(wù)過程建立一個事實表。對于是否將不同業(yè)務(wù)過程放到同一個事實表 中，將在下一節(jié)中詳細(xì)介紹。

確定粒度

業(yè)務(wù)過程選定以后，就要針對每個業(yè)務(wù)過程確定一個粒度，即確定事務(wù)事實表每一行所表達(dá)的細(xì)節(jié)層次。下面先介紹淘寶訂單的產(chǎn)生過程。

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

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

確定維度

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

確定事實

作為過程度量的核心，事實表應(yīng)該包含與其描述過程有關(guān)的所有事實。以淘寶交易事務(wù)事實表為例，選定三個業(yè)務(wù)過程一一下單、支付和 成功完結(jié)，不同的業(yè)務(wù)過程擁有不同的事實。比如在下單業(yè)務(wù)過程中， 需要包含下單金額、下單數(shù)量、下單分?jǐn)偨痤~；在支付業(yè)務(wù)過程中，包含支付金額、分?jǐn)傕]費(fèi)、折扣金額、紅包金額、積分金額；在完結(jié)業(yè)務(wù)過程中包含確認(rèn)收貨金額等。由于粒度是子訂單，所以對于一些父訂單上的金額需要分?jǐn)偟阶佑唵紊希热绺赣唵梧]費(fèi)、父訂單折扣等。

5.冗余維度

在確定維度時，包含了買賣家維度、商品維度、類目維度 、收發(fā)貨維度等， Kimball維度建模理論建議在事實表中只保存這些維表的外鍵， 而淘寶交易事務(wù)事實表在 Kimball 維度建?；A(chǔ)之上做了進(jìn) 一 步的優(yōu) 化，將買賣家星級、標(biāo)簽、店鋪名稱、商品類型、商品特征、商品屬性、 類目層級等維度屬性都冗余到事實表中，提高對事實表進(jìn)行過濾查詢、統(tǒng)計聚合的效率，如圖 4.5 所示 。

4.2.2 單事務(wù)事實表

單事務(wù)事實表，顧名思義，即針對每個業(yè)務(wù)過程設(shè)計一個事實表。這樣設(shè)計的優(yōu)點不言而喻，可以方便地對每個業(yè)務(wù)過程進(jìn)行獨(dú)立的分析研究。1688 交易流程則采用這 種模式構(gòu)建事務(wù)事實表。

1688 交易和淘寶交易相 似，主要流程也是下單、支付、發(fā)貨和完結(jié)，而在這四個關(guān)鍵流程中 1688 交易選擇下單和支付兩個業(yè)務(wù)過程設(shè) 計事務(wù)事實表，分別是1688交易訂單下單事務(wù)事實表和1688交易訂單支付事務(wù)事實表。

選定業(yè)務(wù)過程后，將對每個業(yè)務(wù)過程確定粒度、維度和事實。對于 1688 交易訂單下單事務(wù)事實表，確定子訂單粒度，選擇買家、賣家、商品、父訂單、收貨地區(qū)維度，事實包含下單分?jǐn)偨痤~和折扣金額，如 圖4.6 所示；而對于 1688 交易訂單支付事務(wù)事實表 ，粒度和維度與交易訂單下單事務(wù)事實表相同，所表達(dá)的事實則不 一樣 ，包含支付金額、支付調(diào)整金額和支付優(yōu)惠等，如圖4.7 所示；

1688 交易針對下單和支付分別建立單事務(wù)事實表后，每天的下單記錄則進(jìn)入當(dāng)天的下單事務(wù)事實表中，每天的支付記錄進(jìn)入當(dāng)天的支付事務(wù)事實表中，由于事實表具有稀疏性質(zhì) ，因此只有當(dāng)天數(shù)據(jù)才會進(jìn)入當(dāng)天的事實表中。下面以具體交易訂單為例 ，展示單事務(wù)事實表的設(shè)計實例。

4.2.3 多事務(wù)事實表

多事務(wù)事實表，將不同的事實放到同一個事實表中，即同一個事實表包含不同的業(yè)務(wù)過程。多事務(wù)事實表在設(shè)計時有兩種方法進(jìn)行事實的處理：

①不同業(yè)務(wù)過程的事實使用不同的事實字段進(jìn)行存放； ②不同業(yè)務(wù)過程的事實使用同一個事實字段進(jìn)行存放，但增加一個業(yè)務(wù)過程標(biāo)簽。

如何選擇：

當(dāng)不同業(yè)務(wù)過程的度量比較相似、差異不大時，可以采用第 二種 多事務(wù)事實表的設(shè)計方式，使用同 一個字段來表示度量數(shù)據(jù) 。但 這種方式存在一個問題一一在同一個周期內(nèi)會存在多條記錄（如淘寶收藏商品事務(wù)事實表，增加【收藏刪除類型】，collect/delete） 當(dāng)不同業(yè)務(wù)過程的度量差異較大時，可以選擇第一種多事務(wù)事實 表的設(shè)計方式，將不同業(yè)務(wù)過程的度量使用不同 字段冗余到 表 中，非當(dāng)前業(yè)務(wù)過程則置零表示。這種方式所存在的問題是度量字段零值較多（如淘寶交易事務(wù)事實表，針對不同業(yè)務(wù)過程如下單，則打一個是否當(dāng)天下單的標(biāo)簽）

4.2.4 兩種事實表對比

業(yè)務(wù)過程

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

粒度和維度

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

事實

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

下游業(yè)務(wù)使用

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

計算存儲成本

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

4.2.5 父子事實的處理方式

e.g. 子訂單分?jǐn)偟挠行聠谓痤~和支付金額

4.2.6 事實的設(shè)計準(zhǔn)則

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

4.3.1 特性

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

4.3.2 實例

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

4.3.3 注意事項

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

4.4.1 設(shè)計過程

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

4.4.2 特點

數(shù)據(jù)不斷更新 多業(yè)務(wù)過程日期

4.4.3 特殊處理

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

4.4.4 物理實現(xiàn)

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

4.6 無事實的事實表

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

4.7 聚集型事實表DWS

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

4.7.1 聚集的基本原則

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

4.7.2 聚集的基本步驟

確定聚集維度

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

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

4.7.3 阿里公共匯總層

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

4.7.4 聚集補(bǔ)充說明

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