阿里大數(shù)據(jù)之路：數(shù)據(jù)模型篇大總結

阿里大數(shù)據(jù)之路：數(shù)據(jù)模型篇大總結第1章大數(shù)據(jù)領域建模綜述1.1為什么需要數(shù)據(jù)建模有結構地分類組織和存儲是我們面臨的一個挑戰(zhàn)。數(shù)據(jù)模型強調從業(yè)務、數(shù)據(jù)存取和使用角度合理存儲數(shù)據(jù)。數(shù)據(jù)模型方法，以便在性能、成本、效率之間取得最佳平衡成本：良好的數(shù)據(jù)模型能極大地減少不必要的數(shù)據(jù)冗余，也能實現(xiàn)計算結果復用，極大地降低大數(shù)據(jù)系統(tǒng)中的存儲和計算成本。效率：良好的數(shù)據(jù)模型能極大地改善用戶使用數(shù)據(jù)的體驗，提高使用數(shù)據(jù)的效率。質量：良好的數(shù)據(jù)模型能改善數(shù)據(jù)統(tǒng)計口徑的不一致性，減少數(shù)據(jù)計算錯誤的可能性。1.2關系數(shù)據(jù)庫系統(tǒng)和數(shù)據(jù)倉庫1.3從OLTP和OLAP系統(tǒng)的區(qū)別看模型方法論的選擇OLTP系統(tǒng)通常面向的主要數(shù)據(jù)操作是隨機讀寫，主要采用滿足3NF的實體關系模型存儲數(shù)據(jù)，從而在事務處理中解決數(shù)據(jù)的冗余和一致性問題：OLAP系統(tǒng)面向的主要數(shù)據(jù)操作是批量讀寫，事務處理中的一致性不是OLAP所關注的，其主要關注數(shù)據(jù)的整合，以及在一次性的復雜大數(shù)據(jù)查詢和處理中的性能，因此它需要采用一些不同的數(shù)據(jù)建模方法。1.4典型的數(shù)據(jù)倉庫建模方法論1.4.1ER模型采用ER模型建設數(shù)據(jù)倉庫模型的出發(fā)點是整合數(shù)據(jù)，將各個系統(tǒng)中的數(shù)據(jù)以整個企業(yè)角度按主題進行相似性組合和合并，并進行一致性處理，為數(shù)據(jù)分析決策服務，但是并不能直接用于分析決策。ER模型在實踐中最典型的代表是Teradata公司基于金融業(yè)務發(fā)布的FS-LDM（FinancialServicesLogicalDataModel），它通過對金融業(yè)務的高度抽象和總結，將金融業(yè)務劃分為10大主題，并以設計面向金融倉庫模型的核心為基礎，企業(yè)基于此模型做適當調整和擴展就能快速落地實施。1.4.2維度模型維度建模從分析決策的需求出發(fā)構建模型，為分析需求服務，因此它重點關注用戶如何更快速地完成需求分析，同時具有較好的大規(guī)模復雜查詢的響應性能。其典型的代表是星形模型，以及在一些特殊場景下使用的雪花模型。設計步驟通常如下：選擇需要進行分析決策的業(yè)務過程。業(yè)務過程可以是單個業(yè)務事件，比如交易的支付、退款等；也可以是某個事件的狀態(tài)，比如當前的賬戶余額等；還可以是一系列相關業(yè)務事件組成的業(yè)務流程，具體需要看我們分析的是某些事件發(fā)生情況，還是當前狀態(tài)，或是事件流轉效率。選擇粒度。在事件分析中，我們要預判所有分析需要細分的程度，從而決定選擇的粒度。粒度是維度的一個組合。識別維表。選擇好粒度之后，就需要基于此粒度設計維表，包括維度屬性，用于分析時進行分組和篩選。選擇事實。確定分析需要衡量的指標。1.4.3DataVault模型它強調建立一個可審計的基礎數(shù)據(jù)層，也就是強調數(shù)據(jù)的歷史性、可追溯性和原子性，而不要求對數(shù)據(jù)進行過度的一致性處理和整合；同時它基于主題概念將企業(yè)數(shù)據(jù)進行結構化組織，并引入了更進一步的范式處理來優(yōu)化模型，以應對下游、系統(tǒng)變更的擴展性。1.4.4Anchor模型Anchor對DataVault模型做了進一步規(guī)范化處理，Lars.Ronnback的初衷是設計一個高度可擴展的模型，其核心思想是所有的擴展只是添加而不是修改，因此將模型規(guī)范到6NF，基本變成了k-v結構化模型。1.5阿里巴巴數(shù)據(jù)模型實踐綜述第一個階段：構建在Oracle上，數(shù)據(jù)完全以滿足報表需求為目的第二個階段：引入了當時MPP架構體系的Greenplum，ODL（操作數(shù)據(jù)層）+BDL（基礎數(shù)據(jù)層）+IDL（接口數(shù)據(jù)層）+ADL（應用數(shù)據(jù)層）；BDL希望引入ER模型，加強數(shù)據(jù)的整合，構建一致的基礎數(shù)據(jù)模型，但構建ER模型時遇到了比較大的困難和挑戰(zhàn)，互聯(lián)網(wǎng)業(yè)務的快速發(fā)展、人員的快速變化、業(yè)務知識功底的不夠全面，導致ER模型設計遲遲不能產(chǎn)出。至此，我們也得到了一個經(jīng)驗：在不太成熟、快速變化的業(yè)務面前，構建ER模型的風險非常大，不太適合去構建ER模型。第三個階段：迎來了以Hadoop為代表的分布式存儲計算平臺的快速發(fā)展，同時阿里巴巴集團自主研發(fā)的分布式計算平臺MaxCompute也在緊鑼密鼓地進行著。以Kimball的維度建模為核心理念的模型方法論，構建了阿里巴巴集團的公共層模型數(shù)據(jù)架構體系。數(shù)據(jù)公共層建設的目的是著力解決數(shù)據(jù)存儲和計算的共享問題。數(shù)據(jù)每年以近2.5倍的速度在增長，數(shù)據(jù)的增長遠遠超過業(yè)務的增長。統(tǒng)一化的集團數(shù)據(jù)整合及管理的方法體系“OneData”：一致性的指標定義體系、模型設計方法體系以及配套工具。第2章阿里巴巴數(shù)據(jù)整合及管理體系面對爆炸式增長的數(shù)據(jù)，如何建設高效的數(shù)據(jù)模型和體系，對這些數(shù)據(jù)進行有序和有結構地分類組織和存儲，避免重復建設和數(shù)據(jù)不一致性，保證數(shù)據(jù)的規(guī)范性，一直是大數(shù)據(jù)系統(tǒng)建設不斷追求的方向。2.1概述核心：從業(yè)務架構設計（如何快速上手工作）到模型設計，從數(shù)據(jù)研發(fā)到數(shù)據(jù)服務，做到數(shù)據(jù)可管理、可追溯、可規(guī)避重復建設。2.1.1定位及價值建設統(tǒng)一的、規(guī)范化的數(shù)據(jù)接入層（ODS）和數(shù)據(jù)中間層（DWD和DWS），通過數(shù)據(jù)服務和數(shù)據(jù)產(chǎn)品，完成服務于阿里巴巴的大數(shù)據(jù)系統(tǒng)建設，即數(shù)據(jù)公共層建設。業(yè)務板塊：根據(jù)業(yè)務屬性劃分板塊，板塊之間的指標或業(yè)務重疊性較小。規(guī)范定義：一套數(shù)據(jù)規(guī)范命名體系，用在模型設計中模型設計：以維度建模理論為基礎，基于維度建?？偩€架構，構建一致性的維度和事實(進行規(guī)范定義)。2.2規(guī)范定義規(guī)范定義指以維度建模作為理論基礎，構建總線矩陣，劃分和定義數(shù)據(jù)域、業(yè)務過程、維度、度量／原子指標、修飾類型、修飾詞、時間周期、派生指標。2.2.1名詞術語數(shù)據(jù)域（主題域）面向業(yè)務分析，將業(yè)務過程或者維度進行抽象的集合。業(yè)務過程可以概括為一個個不可拆分的行為事件，在業(yè)務過程之下，可以定義指標；維度是指度量的環(huán)境，如買家下單事件，買家是維度。為保障整個體系的生命力，數(shù)據(jù)域是需要抽象提煉，并且長期維護和更新的，但不輕易變動。常見主題域：用戶、渠道、營銷、流量、交易、財務、商品業(yè)務過程指企業(yè)的業(yè)務活動事件，如下單、支付、退款都是業(yè)務過程。請注意，業(yè)務過程是一個不可拆分的行為事件，通俗地講，業(yè)務過程就是企業(yè)活動中的事件時間周期用來明確數(shù)據(jù)統(tǒng)計的時間范圍或者時間點，如最近30天、自然周、截至當日等修飾類型是對修飾詞的一種抽象劃分。修飾類型從屬于某個業(yè)務域，如日志域的訪問終端類型涵蓋無線端、PC端等修飾詞修飾詞指除了統(tǒng)計維度以外指標的業(yè)務場景限定抽象。修飾詞隸屬于一種修飾類型，如在日志域的訪問終端類型下，有修飾詞PC端、無線端等度量/原子指標原子指標和度量含義相同，基于某一業(yè)務事件行為下的度量，是業(yè)務定義中不可再拆分的指標，具有明確業(yè)務含義的名詞，如支付金額維度維度是度量的環(huán)境，用來反映業(yè)務的一類屬性，這類屬性的集合構成一個維度，也可以稱為實體對象。維度屬于一個數(shù)據(jù)域，如地理維度（其中包括國家、地區(qū)、省以及城市等級別的內(nèi)容)、時間維度(其中包括年、季、月、周、日等級別的內(nèi)容）維度屬性維度屬性隸屬于一個維度，如地理維度里面的國家名稱、國家ID、省份名稱等都屬于維度屬性派生指標派生指標=一個原子指標+多個修飾詞(可選)+時間周期+粒度。可以理解為對原子指標業(yè)務統(tǒng)計范圍的圈定。如原子指標：支付金額，最近1天海外買家支付金額則為派生指標(最近1天為時間周期，海外為修飾詞，買家作為維度，而不作為修飾詞)2.2.2指標體系一、基本原則組成體系之間的關系派生指標由原子指標、時間周期修飾詞、若干其他修飾詞組合得到原子指標、修飾類型及修飾詞，直接歸屬在業(yè)務過程下，其中修飾詞繼承修飾類型的數(shù)據(jù)域派生指標可以選擇多個修飾詞，修飾詞之間的關系為"或"或者"且"，由派生指標具體語義決定派生指標唯一歸屬一個原子指標，繼承原子指標的數(shù)據(jù)域，與修飾詞的數(shù)據(jù)域無關原子指標有確定的英文字段名、數(shù)據(jù)類型和算法說明；派生指標要繼承原子指標的英文名、數(shù)據(jù)類型和算法要求命名約定命名所用術語。指標命名盡量使用英文簡寫，其次是英文。太長也可以考慮漢語拼音首字母業(yè)務過程。英文名：用英文或英文的縮寫或者中文拼音簡寫原子指標。英文名：動作+度量修飾詞。只有時間周期才會有英文名派生指標。英文名：原子指標英文名+時間周期修飾詞(3位,例如_1d)+序號(4位，例如_001)算法算法概述一一算法對應的用戶容易理解的闡述。舉例一一通過具體例子幫助理解指標算法。SQL算法說明一一對于派生指標給出SQL的寫法或者偽代碼。二、操作細則派生指標可以分為三類：事務型指標、存量型指標和復合型指標。事務型指標：是指對業(yè)務活動進行衡量的指標。例如新發(fā)商品數(shù)、重發(fā)商品數(shù)、新增注冊會員數(shù)、訂單支付金額，這類指標需維護原子指標及修飾詞，在此基礎上創(chuàng)建派生指標。存量型指標：是指對實體對象(如商品、會員)某些狀態(tài)的統(tǒng)計。例如商品總數(shù)、注冊會員總數(shù)，這類指標需維護原子指標及修飾詞，在此基礎上創(chuàng)建派生指標，對應的時間周期一般為“歷史截至當前某個時間”。復合型指標：是在事務型指標和存量型指標的基礎上復合而成的。例如瀏覽UV-下單買家數(shù)轉化率，有些需要創(chuàng)建新原子指標，有些則可以在事務型或存量型原子指標的基礎上增加修飾詞得到派生指標。2.3模型設計2.3.1指導理論數(shù)據(jù)模型的維度設計主要以維度建模理論為基礎，基于維度數(shù)據(jù)模型總線架構，構建一致性的維度和事實。2.3.2模型層次操作數(shù)據(jù)層（ODS）：把操作系統(tǒng)數(shù)據(jù)幾乎無處理地存放在數(shù)據(jù)倉庫系統(tǒng)中。公共維度模型層（CDM）：存放明細事實數(shù)據(jù)、維表數(shù)據(jù)及公共指標匯總數(shù)據(jù)，其中明細事實數(shù)據(jù)、維表數(shù)據(jù)一般根據(jù)ODS層數(shù)據(jù)加工生成；公共指標匯總數(shù)據(jù)一般根據(jù)維表數(shù)據(jù)和明細事實數(shù)據(jù)加工生成。CDM層又細分為DWD層和DWS層，分別是明細數(shù)據(jù)層和匯總數(shù)據(jù)層，采用維度模型方法作為理論基礎，更多地采用一些維度退化手法，將維度退化至事實表中，減少事實表和維表的關聯(lián)，提高明細數(shù)據(jù)表的易用性；同時在匯總數(shù)據(jù)層，加強指標的維度退化，采取更多的寬表化手段構建公共指標數(shù)據(jù)層，提升公共指標的復用性，減少重復加工。其主要功能如下。組合相關和相似數(shù)據(jù)：采用明細寬表，復用關聯(lián)計算，減少數(shù)據(jù)掃描。公共指標統(tǒng)一加工：基于OneData體系構建命名規(guī)范、口徑一致和算法統(tǒng)一的統(tǒng)計指標，為上層數(shù)據(jù)產(chǎn)品、應用和服務提供公共指標建立邏輯匯總寬表。建立一致性維度:建立一致的數(shù)據(jù)分析維表，降低數(shù)據(jù)計算口徑、算法不統(tǒng)一的風險。應用數(shù)據(jù)層（ADS）：存放數(shù)據(jù)產(chǎn)品個性化的統(tǒng)計指標數(shù)據(jù)，根據(jù)CDM層與ODS層加工生成。個性化指標加工：不公用性、復雜性(指數(shù)型、比值型、排名型指標)?；趹玫臄?shù)據(jù)組裝:大寬表集市、橫表轉縱表、趨勢指標串。阿里巴巴通過構建全域的公共層數(shù)據(jù)，極大地控制了數(shù)據(jù)規(guī)模的增長趨勢模型架構圖數(shù)據(jù)調用服務優(yōu)先使用公共維度模型層(CDM)數(shù)據(jù)，當公共層沒有數(shù)據(jù)時，需評估是否需要創(chuàng)建公共層數(shù)據(jù)，當不需要建設公用的公共層時，方可直接使用操作數(shù)據(jù)層(ODS)數(shù)據(jù)。應用數(shù)據(jù)層(ADS)作為產(chǎn)品特有的個性化數(shù)據(jù)一般不對外提供數(shù)據(jù)服務，但是ADS作為被服務方也需要遵守這個約定。2.3.3基本原則高內(nèi)聚和低耦合一個邏輯或者物理模型由哪些記錄和字段組成，應該遵循最基本的軟件設計方法論的高內(nèi)聚和低耦合原則。主要從數(shù)據(jù)業(yè)務特性和訪問特性兩個角度來考慮：將業(yè)務相近或者相關、粒度相同的數(shù)據(jù)設計為一個邏輯或者物理模型；將高概率同時訪問的數(shù)據(jù)放一起，將低概率同時訪問的數(shù)據(jù)分開存儲。核心模型與擴展模型分離建立核心模型與擴展模型體系，核心模型包括的字段支持常用的核心業(yè)務，擴展模型包括的字段支持個性化或少量應用的需要，不能讓擴展模型的宇段過度侵入核心模型，以免破壞核心模型的架構簡潔性與可維護性。公共處理邏輯下沉及單一越是底層公用的處理邏輯越應該在數(shù)據(jù)調度依賴的底層進行封裝與實現(xiàn)，不要讓公用的處理邏輯暴露給應用層實現(xiàn)，不要讓公共邏輯多處同時存在。成本與性能平衡適當?shù)臄?shù)據(jù)冗余可換取查詢和刷新性能，不宜過度冗余與數(shù)據(jù)復制。數(shù)據(jù)可回滾處理邏輯不變，在不同時間多次運行數(shù)據(jù)結果確定不變。一致性具有相同含義的字段在不同表中的命名必須相同，必須使用規(guī)范定義中的名稱。命名清晰、可理解表命名需清晰、一致，表名需易于消費者理解和使用。2.4模型實施2.4.1業(yè)界常用模型實施過程構建維度模型一般要經(jīng)歷四個階段：第一個階段是高層模型設計時期，定義業(yè)務過程維度模型的范圍，提供每種星形模式的技術和功能描述；直接產(chǎn)出目標是創(chuàng)建高層維度模型圖，它是對業(yè)務過程中的維表和事實表的圖形描述。確定維表創(chuàng)建初始屬性列表，為每個事實表創(chuàng)建提議度量；第二個階段是詳細模型設計時期，對每個星形模型添加屬性和度量信息；確定每個維表的屬性和每個事實表的度量，并確定信息來源的位置、定義，確定屬性和度量如何填入模型的初步業(yè)務規(guī)則。第三個階段是進行模型的審查、再設計和驗證，本階段主要召集相關人員進行模型的審查和驗證，根據(jù)審查結果對詳細維度進行再設計。第四個階段是產(chǎn)生詳細設計文檔，提交ETL設計和開發(fā)，最后，完成模型詳細設計文檔，提交ETL開發(fā)人員，進入ETL設計和開發(fā)階段，由ETL人員完成物理模型的設計和開發(fā)。2.4.2OneData實施過程指導方針首先，在建設大數(shù)據(jù)數(shù)據(jù)倉庫時，要進行充分的業(yè)務調研和需求分析。這是數(shù)據(jù)倉庫建設的基石，業(yè)務調研和需求分析做得是否充分直接決定了數(shù)據(jù)倉庫建設是否成功。其次，進行數(shù)據(jù)總體架構設計，主要是根據(jù)數(shù)據(jù)域對數(shù)據(jù)進行劃分；按照維度建模理論，構建總線矩陣、抽象出業(yè)務過程和維度。再次，對報表需求進行抽象整理出相關指標體系，使用OneData工具完成指標規(guī)范定義和模型設計。最后，就是代碼研發(fā)和運維。實施工作流（1）數(shù)據(jù)調研業(yè)務調研：需要了解各個業(yè)務領域、業(yè)務線的業(yè)務有什么共同點和不同點，以及各個業(yè)務線可以細分為哪幾個業(yè)務模塊，每個業(yè)務模塊具體的業(yè)務流程又是怎樣的。業(yè)務調研是否充分，將會直接決定數(shù)據(jù)倉庫建設是否成功需求調研：需求調研的途徑有兩種：一是根據(jù)與分析師、業(yè)務運營人員的溝通（郵件、IM）獲知需求；二是對報表系統(tǒng)中現(xiàn)有的報表進行研究分析；（2）架構設計數(shù)據(jù)域劃分數(shù)據(jù)域是指面向業(yè)務分析，將業(yè)務過程或者維度進行抽象的集合。業(yè)務過程可以概括為一個個不可拆分的行為事件，如下單、支付、退款。數(shù)據(jù)域需要抽象提煉，并且長期維護和更新，但不輕易變動。構建總線矩陣在進行充分的業(yè)務調研和需求調研后，就要構建總線矩陣了。需要做兩件事情：明確每個數(shù)據(jù)域下有哪些業(yè)務過程；業(yè)務過程與哪些維度相關，并定義每個數(shù)據(jù)域下的業(yè)務過程和維度。規(guī)范定義規(guī)范定義主要定義指標體系，包括原子指標、修飾詞、時間周期和派生指標。模型設計模型設計主要包括維度及屬性的規(guī)范定義，維表、明細事實表和匯總事實表的模型設計?？偨YOneData的實施過程是一個高度迭代和動態(tài)的過程，一般采用螺旋式實施方法。在總體架構設計完成之后，開始根據(jù)數(shù)據(jù)域進行迭代式模型設計和評審。在架構設計、規(guī)范定義和模型設計等模型實施過程中，都會引入評審機制，以確保模型實施過程的正確性。第3章維度設計3.1維度設計基礎3.1.1維度的基本概念維度建模中，將度量稱為“事實”，將環(huán)境描述為“維度”，維度是用于分析事實所需要的多樣環(huán)境。例如，在分析交易過程時，可以通過買家、賣家、商品和時間等維度描述交易發(fā)生的環(huán)境。維度所包含的表示維度的列，稱為維度屬性。維度屬性是查詢約束條件、分組和報表標簽生成的基本來源，是數(shù)據(jù)易用性的關鍵。維度使用主鍵標識其唯一性，主鍵也是確保與之相連的任何事實表之間存在引用完整性的基礎。3.1.2維度的基本設計方法選擇維度或新建維度。須保證維度的唯一性。確定主維表。一般是ODS表，直接與業(yè)務系統(tǒng)同步。確定相關維表。確定哪些表和主維表存在關聯(lián)關系，并選擇其中的某些表用于生成維度屬性。確定維度屬性。第一階段從主維表中選擇維度屬性或生成新的維度屬性；第二階段是從相關維表中選擇維度屬性或生成新的維度屬性。確認維度屬性的幾點提示：盡可能生成豐富的維度屬性盡可能多地給出包括一些富有意義的文字性描述區(qū)分數(shù)值型屬性和事實如果通常用于查詢約束條件或分組統(tǒng)計，則是作為維度屬性；如果通常用于參與度量的計算，則是作為事實。比如商品價格，可以用于查詢約束條件或統(tǒng)計價格區(qū)間的商品數(shù)量，此時是作為維度屬性使用的；也可以用于統(tǒng)計某類目下商品的平均價格，此時是作為事實使用的。另外，如果數(shù)值型字段是離散值，則作為維度屬性存在的可能性較大；如果數(shù)值型宇段是連續(xù)值，則作為度量存在的可能性較大，但并不絕對，需要同時參考宇段的具體用途。盡量沉淀出通用的維度屬性3.1.3一致性維度和交叉探查共享維表。比如在阿里巴巴的數(shù)據(jù)倉庫中，商品、賣家、買家、類目等維度有且只有一個。所以基于這些公共維度進行的交叉探查不會存在任何問題。一致性上卷。其中一個維度的維度屬性是另一個維度的維度屬性的子集，且兩個維度的公共維度屬性結構和內(nèi)容相同。比如在阿里巴巴的商品體系中，有商品維度和類目維度，其中類目維度的維度屬性是商品維度的維度屬性的子集，且有相同的維度屬性和維度屬性值。這樣基于類目維度進行不同業(yè)務過程的交叉探查也不會存在任何問題。交叉屬性。兩個維度具有部分相同的維度屬性。比如在商品維度中具有類目屬性，在賣家維度中具有主營類目屬性，兩個維度具有相同的類目屬性，則可以在相同的類目屬性上進行不同業(yè)務過程的交叉探查。3.2維度設計高級主題3.2.1維度整合應用間差異：應用在編碼、命名習慣、度量單位等方面會存在很大的差異。應用出于性能和擴展性的考慮，或者隨技術架構的演變，以及業(yè)務的發(fā)展，采用不同的物理實現(xiàn)。集成類型（同維度整合）：命名規(guī)范的統(tǒng)一。表名、字段名等統(tǒng)一。字段類型的統(tǒng)一。相同和相似字段的字段類型統(tǒng)一。公共代碼及代碼值的統(tǒng)一。公共代碼及標志性字段的數(shù)據(jù)類型、命名方式等統(tǒng)一。業(yè)務含義相同的表的統(tǒng)一。主要依據(jù)高內(nèi)聚、低耦合的理念，在物理實現(xiàn)中，將業(yè)務關系大、源系統(tǒng)影響差異小的表進行整合：將業(yè)務關系小、源系統(tǒng)影響差異大的表進行分而置之。通常有如下幾種集成方式：采用主從表的設計方式，將兩個表或多個表都有的字段放在主表中（主要基本信息），從屬信息分別放在各自的從表中。對于主表中的主鍵，要么采用復合主鍵、源主鍵和系統(tǒng)或表區(qū)別標志：要么采用唯一主鍵、“源主鍵和系統(tǒng)或表區(qū)別標志”生成新的主鍵。通常建議采用復合主鍵的方式。直接合并，共有信息和個性信息都放在同一個表中。如果表字段的重合度較低，則會出現(xiàn)大量空值，對于存儲和易用性會有影響，需謹慎選擇。不合并，因為源表的表結構及主鍵等差異很大，無法合并，使用數(shù)據(jù)倉庫里的多個表存放各自的數(shù)據(jù)。表整合：垂直整合：不同的來源表包含相同的數(shù)據(jù)集，只是存儲的信息不同，比如主表與擴展表的整合，豐富其維度屬性。水平整合：不同的來源表包含不同的數(shù)據(jù)集，不同子集之間無交叉，也可以存在部分交叉。存在交叉，則需要去重不存在交叉，則需要考慮不同子集的自然鍵是否存在沖突如果不沖突，則可以考慮將各子集的自然鍵作為整合后的表的自然鍵設置超自然鍵，將來源表各子集的自然鍵加工成一個字段作為超自然鍵（即聯(lián)合主鍵，阿里采用該方法，并將來源字段作為分區(qū)字段）3.2.2水平拆分如何設計維度：模型設計重點考慮的三個原則：擴展性：當源系統(tǒng)、業(yè)務邏輯變化時，能通過較少的成本快速擴展模型，保持核心模型的相對穩(wěn)定性。軟件工程中的高內(nèi)聚、低藕合的思想是重要的指導方針之一。效能：在性能和成本方面取得平衡。通過犧牲一定的存儲成本，達到性能和邏輯的優(yōu)化。易用性：模型可理解性高、訪問復雜度低。用戶能夠方便地從模型中找到對應的數(shù)據(jù)表，并能夠方便地查詢和分析。模型設計重點考慮的兩個依據(jù)：維度的不同分類的屬性差異情況。當維度屬性隨類型變化較大時，采用方案1。業(yè)務的關聯(lián)程度。兩個相關性較低的業(yè)務，稠合在一起弊大于利，對模型的穩(wěn)定性和易用性影響較大，采用方案2。方案參考：方案1是將維度的不同分類實例化為不同的維度，同時在主維度中保存公共屬性，適合于當維度屬性隨類型變化較大的情形構建商品維度、航旅商品維度：不同分類的商品，其維度屬性可能相同，也可能不同。比如航旅的商品和普通的淘系商品，都屬于商品，都有商品價格、標題、類型、上架時間、類目等維度屬性，但是航旅的商品除了有這些公共屬性外，還有酒店、景點、門票、旅行等自己獨特的維度屬性。方案2是維護單一維度，包含所有可能的屬性對淘系商品和1688商品構建兩個維度，業(yè)務分析人員一般只針對本數(shù)據(jù)集市進行統(tǒng)計分析。1688業(yè)務變更，此維度需要變更，淘寶業(yè)務變更亦然，穩(wěn)定性很差。3.2.3垂直拆分出于擴展性、產(chǎn)出時間、易用性等方面的考慮，設計主從維度。主維表存放穩(wěn)定、產(chǎn)出時間早、熱度高的屬性；從維表存放變化較快、產(chǎn)出時間晚、熱度低的屬性。設計了商品主維度和商品擴展維度。其中商品主維度在每日的1：30左右產(chǎn)出，而商品擴展維度由于有冗余的產(chǎn)出時間較晚的商品品牌和標簽信息，在每日的3：00左右產(chǎn)出。由于商品擴展維度有冗余的庫存等變化較快的數(shù)據(jù)，對于主維度進行緩慢變化的處理較為重要。通過存儲的冗余和計算成本的增加，實現(xiàn)了商品主模型的穩(wěn)定和產(chǎn)出時間的提前。3.2.4歷史歸檔歸檔策略1：同前臺歸檔策略，在數(shù)據(jù)倉庫中實現(xiàn)前臺歸檔算法，定期對歷史數(shù)據(jù)進行歸檔。但存在一些問題，一是前臺歸檔策略復雜，實現(xiàn)成本較高；二是前臺歸檔策略可能會經(jīng)常變化，導致數(shù)據(jù)倉庫歸檔算法也要隨之變化，維護和溝通成本較高。此方式適用于前臺歸檔策略邏輯較為簡單，且變更不頻繁的情況。歸檔策略2：同前臺歸檔策略，但采用數(shù)據(jù)庫變更日志的方式。對于如此龐大的數(shù)據(jù)量，阿里巴巴采用的數(shù)據(jù)抽取策略一般是通過數(shù)據(jù)庫binlog日志解析獲取每日增量，通過增量merge全量的方式獲取最新的全量數(shù)據(jù)?？梢允褂迷隽咳罩镜膭h除標志，作為前臺數(shù)據(jù)歸檔的標志。通過此標志對數(shù)據(jù)倉庫的數(shù)據(jù)進行歸檔。此方式不需要關注前臺歸檔策略，簡單易行。但對前臺應用的要求是數(shù)據(jù)庫的物理刪除只有在歸檔時才執(zhí)行，應用中的刪除只是邏輯刪除。歸檔策略3：數(shù)據(jù)倉庫自定義歸檔策略?？梢詫w檔算法用簡單、直接的方式實現(xiàn)，但原則是盡量比前臺應用晚歸檔、少歸檔。避免出現(xiàn)數(shù)據(jù)倉庫中已經(jīng)歸檔的數(shù)據(jù)再次更新的情況。如果技術條件允許，能夠解析數(shù)據(jù)庫binlog日志，建議使用歸檔策略2，規(guī)避前臺歸檔算法。具體可以根據(jù)自身數(shù)據(jù)倉庫的實際情況進行選擇。3.3維度變化3.3.1緩慢變化維在Kimball的理論中，有三種處理緩慢變化維的方式，可以根據(jù)業(yè)務需求來進行選擇：重寫維度值。不保留歷史數(shù)據(jù)，始終取最新數(shù)據(jù)（假設業(yè)務需求方不關心歷史數(shù)據(jù)，則可以采用方案1）插入新的維度行。保留歷史數(shù)據(jù)，維度值變化前的事實和過去的維度值關聯(lián)，維度值變化后的事實和當前的維度值關聯(lián)。添加維度列。采用第二種處理方式不能將變化前后記錄的事實歸一為變化前的維度或者歸一為變化后的維度（不同業(yè)務部門需要統(tǒng)計各自的業(yè)績，則需要保留歷史數(shù)據(jù)）3.3.2快照維表在Kimball的維度建模中，必須使用代理鍵（不具有業(yè)務含義的鍵，區(qū)別于自然鍵）作為每個維表的主鍵，用于處理緩慢變化維。阿里不使用代理鍵的原因：數(shù)據(jù)量大、ETL復雜化；不直接使用拉鏈表的原因：解釋成本高、隨著時間的推移，分區(qū)數(shù)量會極度膨脹阿里通過快照方式，每天保留一份全量快照數(shù)據(jù)，簡單而有效，方便好理解，但造成存儲浪費，因此配合極限存儲。3.3.3極限存儲透明化底層的數(shù)據(jù)還是歷史拉鏈存儲，但是上層做一個視圖操作或者在Hive里做一個hook，通過分析語句的語法樹，把對極限存儲前的表的查詢轉換成對極限存儲表的查詢。分月做歷史拉鏈表每個月月初重新開始做歷史拉鏈表局限性：首先，其產(chǎn)出效率很低，大部分極限存儲通常需要t-2；其次，對于變化頻率高的數(shù)據(jù)并不能達到節(jié)約成本的效果。在做極限存儲前有一個全量存儲表，全量存儲表僅保留最近一段時間的全量分區(qū)數(shù)據(jù)，歷史數(shù)據(jù)通過映射的方式關聯(lián)到極限存儲表。即用戶只訪問全量存儲表，所以對用戶來說極限存儲是不可見的。對于部分變化頻率頻繁的宇段需要過濾。例如，用戶表中存在用戶積分宇段，這種宇段的值每天都在發(fā)生變化，如果不過濾的話，極限存儲就相當于每個分區(qū)存儲一份全量數(shù)據(jù)，起不到節(jié)約存儲成本的效果。3.3.4微型維度微型維度的創(chuàng)建是通過將一部分不穩(wěn)定的屬性從主維度中移出，并將它們放置到擁有自己代理鍵的新表中來實現(xiàn)的。這些屬性相互之間沒有直接關聯(lián)，不存在自然鍵。通過為每個組合創(chuàng)建新行的一次性過程來加載數(shù)據(jù)。比如淘寶用戶維度，用戶的注冊日期、年齡、性別、身份信息等基本不會發(fā)生變化，但用戶VIP等級、用戶信用評價等級會隨著用戶的行為不斷發(fā)生變化。其中VIP等級共有8個值，即-1～6；用戶信用評價等級共有18個值。假設基于VIP等級和用戶信用評價等級構建微型維度，則在此微型維度中共有8x18個組合，即144條記錄，代理鍵可能是1～144阿里在實踐中并未使用此技術：微型維度的局限性：必須是枚舉值，且考慮所有可能組合ETL邏輯復雜破壞了維度的可瀏覽性3.4特殊維度3.4.1遞歸層次維度的遞歸層次，按照層級是否固定分為均衡層次結構（如一級類目、二級類目等）和非均衡層次結構（如公司之間的公司，數(shù)量級別不固定）遞歸SQL成本較高，且很多工具不支持遞歸SQL，因此在維度模型中對層次結構進行處理層次結構扁平化扁平化僅包含固定數(shù)量的級別，對于非平衡層次結構，可以通過預留級別的方式來解決，但擴展性較差（圖為阿里巴巴中文站的類目體系，粗體部分為回填內(nèi)容）層次橋接表解決了層次結構扁平化帶來的一些問題，加工邏輯復雜，使用邏輯復雜，實際工作很少應用3.4.2行為維度理解為事實衍生的維度，按照加工方式劃分：另一個維度的過去行為，如買家最近一次訪問淘寶的時間、買家最近一次發(fā)生淘寶交易的時間等。快照事實行為維度，如買家從年初截至當前的淘寶交易金額、買家信用分值、賣家信用分值等。分組事實行為維度，將數(shù)值型事實轉換為枚舉值。如買家從年初截至當前的淘寶交易金額按照金額劃分的等級、買家信用分值按照分數(shù)劃分得到的信用等級等。復雜邏輯事實行為維度，通過復雜算法加工或多個事實綜合加工得到。如前面提到的賣家主營類目，商品熱度根據(jù)訪問、收藏、加入購物車、交易等情況綜合計算得到。對于行為維度，有兩種處理方式，其中一種是將其冗余至現(xiàn)有的維表中，如將賣家信用等級冗余至賣家維表中另一種是加工成單獨的行為維表，如賣家主營類目。具體采用哪種方式主要參考如下兩個原則：第一，避免維度過快增長。比如對商品表進行了極限存儲，如果將商品熱度加入現(xiàn)有的商品維表中，則可能會使每日商品變更占比過高，從而導致極限存儲效果較差。第二，避免耦合度過高。比如賣家主營類目，加工邏輯異常復雜，如果融合進現(xiàn)有的賣家維表中，那么過多的業(yè)務稠合會導致賣家維表刷新邏輯復雜、維護性差、產(chǎn)出延遲等。3.4.3多值維度e.g.交易父訂單事實表與商品表多值維度的處理方式降低事實表的粒度（子訂單建立事實）采用多字段（售樓合同，多個買受方，已是最細粒度；由于個數(shù)不會太多，預留字段：買受方1，買受方2，買受方3）橋接表：通過橋接表，則會產(chǎn)生多條重復記錄，業(yè)務上注意區(qū)分重復計算是否符合業(yè)務邏輯3.4.4多值屬性e.g.商品和SKU、屬性、標簽都是多對多的關系多值屬性的處理方式：保持維度主鍵不變，將多值屬性放在維度的一個屬性字段中（通過k-v對的形式放在property字段中，數(shù)據(jù)示例如下：10281239:156426871;137396765:29229;137400766:3226633）保持維度主鍵不變，但將多值屬性放在維度的多個屬性字段中（賣家主營類目，只取TOP3）維度主鍵發(fā)生變化，一個維度值存放多條記錄，擴展性好，使用方便（比如商品SKU維表，對于每個商品，有多少SKU，就有多少記錄，主鍵是商品的ID和SKU的ID）3.4.5雜項維度雜項維度是由操作型系統(tǒng)中的指示符或者標志宇段組合而成的，一般不在一致性維度之列。將這些字段建立到一個維表中，在事實表中只需保存一個外鍵即可。多個字段的不同取值組成一條記錄，生成代理鍵，存入維表中，并將該代理鍵保存到相應的事實表字段下。建議不要直接使用所有的組合生成完整的雜項維表，在抽取遇到新的組合時生成相應的記錄即可。阿里：存在非枚舉字段，如交易留言、交易屬性、交易標簽等；通過子訂單維度實現(xiàn)，且作為邏輯模型，不進行物理化。第4章事實表設計4.1事實表基礎4.1.1事實表特性事實表作為數(shù)據(jù)倉庫維度建模的核心，緊緊圍繞著業(yè)務過程來設計，通過獲取描述業(yè)務過程的度量來表達業(yè)務過程，包含了引用的維度和與業(yè)務過程有關的度量。事實表中一條記錄所表達的業(yè)務細節(jié)程度被稱為粒度。通常粒度可以通過兩種方式來表述：一種是維度屬性組合所表示的細節(jié)程度：一種是所表示的具體業(yè)務含義。作為度量業(yè)務過程的事實，一般為整型或浮點型的十進制數(shù)值，有可加性、半可加性和不可加性三種類型。可加性事實是指可以按照與事實表關聯(lián)的任意維度進行匯總。半可加性事實只能按照特定維度匯總，不能對所有維度匯總，比如庫存可以按照地點和商品進行匯總，而按時間維度把一年中每個月的庫存累加起來則毫無意義。完全不具備可加性，比如比率型事實。對于不可加性事實可分解為可加的組件來實現(xiàn)聚集。維度屬性也可以存儲到事實表中，這種存儲到事實表中的維度列被稱為“退化維度”。與其他存儲在維表中的維度一樣，退化維度也可以用來進行事實表的過濾查詢、實現(xiàn)聚合操作等。事實表有三種類型:事務事實表、周期快照事實表和累積快照事實表。事務事實表用來描述業(yè)務過程，跟蹤空間或時間上某點的度量事件，保存的是最原子的數(shù)據(jù)，也稱為“原子事實表“。周期快照事實表以具有規(guī)律性的、可預見的時間間隔記錄事實，時間間隔如每天、每月、每年等。累積快照事實表用來表述過程開始和結束之間的關鍵步驟事件，覆蓋過程的整個生命周期，通常具有多個日期字段來記錄關鍵時間點，當過程隨著生命周期不斷變化時，記錄也會隨著過程的變化而被修改。4.1.2事實表設計原則原則1：盡可能包含所有與業(yè)務過程相關的事實事實表設計的目的是為了度量業(yè)務過程，所以分析哪些事實與業(yè)務過程有關是設計中非常重要的關注點。在事實表中應該盡量包含所有與業(yè)務過程相關的事實，即使存在冗余，但是因為事實通常為數(shù)字型，帶來的存儲開銷也不會很大。原則2：只選擇與業(yè)務過程相關的事實在選擇事實時，應該注意只選擇與業(yè)務過程有關的事實。比如在訂單的下單這個業(yè)務過程的事實表設計中，不應該存在支付金額這個表示支付業(yè)務過程的事實。原則3：分解不可加性事實為可加的組件對于不具備可加性條件的事實，需要分解為可加的組件。比如訂單的優(yōu)惠率，應該分解為訂單原價金額與訂單優(yōu)惠金額兩個事實存儲在事實表中。原則4：在選擇維度和事實之前必須先聲明粒度粒度的聲明是事實表設計中不可忽視的重要一步，粒度用于確定事實表中一行所表示業(yè)務的細節(jié)層次，決定了維度模型的擴展性，在選擇維度和事實之前必須先聲明粒度，且每個維度和事實必須與所定義的粒度保持一致。在設計事實表的過程中，粒度定義得越細越好，建議從最低級別的原子粒度開始，因為原子粒度提供了最大限度的靈活性，可以支持無法預期的各種細節(jié)層次的用戶需求。在事實表中，通常通過業(yè)務描述來表述粒度，但對于聚集性事實表的粒度描述，可采用維度或維度屬性組合的方式。原則5：在同一個事實表中不能有多種不同粒度的事實事實表中的所有事實需要與表定義的粒度保持一致，在同一個事實表中不能有多種不同粒度的事實。原則6：事實的單位要保持一致對于同一個事實表中事實的單位，應該保持一致。比如原訂單金額、訂單優(yōu)惠金額、訂單運費金額這三個事實，應該采用一致的計量單位，統(tǒng)一為元或分，以方便使用。原則7：對事實的null值要處理對于事實表中事實度量為null值的處理，因為在數(shù)據(jù)庫中null值對常用數(shù)字型字段的SQL過濾條件都不生效，比如大于、小于、等于、大于或等于、小于或等于，建議用零值填充。原則8：使用退化維度提高事實表的易用性在Kimball的維度建模中，通常按照星形模型的方式來設計，對于維度的獲取采用的是通過事實表的外鍵關聯(lián)專門的維表的方式，謹慎使用退化維度。而在大數(shù)據(jù)領域的事實表設計中，則大量采用退化維度的方式，在事實表中存儲各種類型的常用維度信息。這樣設計的目的主要是為了減少下游用戶使用時關聯(lián)多個表的操作，直接通過退化維度實現(xiàn)對事實表的過濾查詢、控制聚合層次、排序數(shù)據(jù)以及定義主從關系等。通過增加冗余存儲的方式減少計算開銷，提高使用效率。4.1.3事實表設計方法對于維度模型設計采用四步設計方法：選擇業(yè)務過程、聲明粒度、確定維度、確定事實。選擇業(yè)務過程及確定事實表類型在明確了業(yè)務需求以后，接下來需要進行詳細的需求分析，對業(yè)務的整個生命周期進行分析，明確關鍵的業(yè)務步驟，從而選擇與需求有關的業(yè)務過程。業(yè)務過程通常使用行為動詞表示業(yè)務執(zhí)行的活動。比如圖4.1中的淘寶訂單流轉的業(yè)務過程有四個：創(chuàng)建訂單、買家付款、賣家發(fā)貨、買家確認收貨。在明確了流程所包含的業(yè)務過程后，需要根據(jù)具體的業(yè)務需求來選擇與維度建模有關的業(yè)務過程。比如是選擇買家付款這個業(yè)務過程，還是選擇創(chuàng)建訂單和買家付款這兩個業(yè)務過程，具體根據(jù)業(yè)務情況來確定。在選擇了業(yè)務過程以后，相應的事實表類型也隨之確定了。比如選擇買家付款這個業(yè)務過程，那么事實表應為只包含買家付款這一個業(yè)務過程的單事務事實表；如果選擇的是所有四個業(yè)務過程，并且需要分析各個業(yè)務過程之間的時間間隔，那么所建立的事實表應為包含了所有四個業(yè)務過程的累積快照事實表。聲明粒度粒度的聲明是事實表建模非常重要的一步，意味著精確定義事實表的每一行所表示的業(yè)務含義，粒度傳遞的是與事實表度量有關的細節(jié)層次。明確的粒度能確保對事實表中行的意思的理解不會產(chǎn)生混淆，保證所有的事實按照同樣的細節(jié)層次記錄。應該盡量選擇最細級別的原子粒度，以確保事實表的應用具有最大的靈活性。同時對于訂單過程而言，粒度可以被定義為最細的訂單級別。比如在淘寶訂單中有父子訂單的概念，即一個子訂單對應一種商品，如果拍下了多種商品，則每種商品對應一個子訂單:這些子訂單一同結算的話，則會生成一個父訂單。那么在這個例子中，事實表的粒度應該選擇為子訂單級別。確定維度完成粒度聲明以后，也就意味著確定了主鍵，對應的維度組合以及相關的維度字段就可以確定了，應該選擇能夠描述清楚業(yè)務過程所處的環(huán)境的維度信息。比如在淘寶訂單付款事務事實表中，粒度為子訂單，相關的維度有買家、賣家、商品、收貨人信息、業(yè)務類型、訂單時間等維度。確定事實事實可以通過回答“過程的度量是什么”來確定。應該選擇與業(yè)務過程有關的所有事實，且事實的粒度要與所聲明的事實表的粒度一致。事實有可加性、半可加性、非可加性三種類型，需要將不可加性事實分解為可加的組件。比如在淘寶訂單付款事務事實表中，同粒度的事實有子訂單分攤的支付金額、郵費、優(yōu)惠金額等。冗余維度在傳統(tǒng)的維度建模的星形模型中，對維度的處理是需要單獨存放在專門的維表中的，通過事實表的外鍵獲取維度。這樣做的目的是為了減少事實表的維度冗余，從而減少存儲消耗。而在大數(shù)據(jù)的事實表模型設計中，考慮更多的是提高下游用戶的使用效率，降低數(shù)據(jù)獲取的復雜性，減少關聯(lián)的表數(shù)量。所以通常事實表中會冗余方便下游用戶使用的常用維度，以實現(xiàn)對事實表的過濾查詢、控制聚合層次、排序數(shù)據(jù)以及定義主從關系等操作。比如在淘寶訂單付款事務事實表中，通常會冗余大量的常用維度字段，以及商品類目、賣家店鋪等維度信息。4.2事務事實表訂單作為交易行為的核心載體，直觀反映了交易的狀況。訂單的流轉會產(chǎn)生很多業(yè)務過程，而下單、支付和成功完結三個業(yè)務過程是整個訂單的關鍵節(jié)點。獲取這三個業(yè)務過程的筆數(shù)、金額以及轉化率是日常數(shù)據(jù)統(tǒng)計分析的重點，事務事實表設計可以很好地滿足這個需求。本節(jié)將介紹三種不同事務事實表的設計方式，以及在淘寶交易訂單中關于郵費和折扣分攤到子訂單的算法。4.2.1設計過程任何類型的事件都可以被理解為一種事務。比如交易過程中的創(chuàng)建訂單、買家付款，物流過程中的攬貨、發(fā)貨、簽收，退款中的申請退款、申請小二介入等，都可以被理解為一種事務。事務事實表，即針對這些過程構建的一類事實表，用以跟蹤定義業(yè)務過程的個體行為，提供豐富的分析能力，作為數(shù)據(jù)倉庫原子的明細數(shù)據(jù)。下面以淘寶交易事務事實表為例，闡述事務事實表的一般設計過程。選擇業(yè)務過程圖4.1給出了淘寶交易訂單的流轉過程，其中介紹了四個重要過程：創(chuàng)建訂單、買家付款、賣家發(fā)貨、買家確認收貨，即下單、支付、發(fā)貨和成功完結四個業(yè)務過程。這四個業(yè)務過程不僅是交易過程中的重要時間節(jié)點，而且也是下游統(tǒng)計分析的重點，因此淘寶交易事務事實表設計著重從這四個業(yè)務過程進行展開。Kimball維度建模理論認為，為了便于進行獨立的分析研究，應該為每個業(yè)務過程建立一個事實表。對于是否將不同業(yè)務過程放到同一個事實表中，將在下一節(jié)中詳細介紹。確定粒度業(yè)務過程選定以后，就要針對每個業(yè)務過程確定一個粒度，即確定事務事實表每一行所表達的細節(jié)層次。下面先介紹淘寶訂單的產(chǎn)生過程。對于每一種商品產(chǎn)生的訂單就稱為子訂單，子訂單記錄了父訂單的訂單號，并且有子訂單標志。如果在同一個店鋪只購買了一種商品，則會將父子訂單進行合并，只保留一條訂單記錄。如圖4.2和圖4.3所示示例。賣家發(fā)貨這個業(yè)務過程可以選擇子訂單粒度，即將每個子訂單作為賣家發(fā)貨事實表的一個細節(jié)。然而，在實際操作中發(fā)現(xiàn)，賣家發(fā)貨更多的是物流單粒度而非子訂單粒度，同一個子訂單可以拆開成多個物流單進行發(fā)貨。在事務事實表設計過程中，秉承確定為最細粒度的原則，因此對于賣家發(fā)貨確定為物流單粒度，和其他三個業(yè)務過程不同，這樣可以更好地給下游統(tǒng)計分析帶來靈活性。確定維度選定好業(yè)務過程并且確定粒度后，就可以確定維度信息了。在淘寶交易事務事實表設計過程中，按照經(jīng)常用于統(tǒng)計分析的場景，確定維度包含:買家、賣家、商品、商品類目、發(fā)貨地區(qū)、收貨地區(qū)、父訂單維度以及雜項維度。由于訂單的屬性較多，比如訂單的業(yè)務類型、是否無線交易、訂單的attributes屬性等，對于這些使用較多卻又無法歸屬到上述買賣家或商品維度中的屬性，則新建一個雜項維度進行存放，如圖4.4所示。確定事實作為過程度量的核心，事實表應該包含與其描述過程有關的所有事實。以淘寶交易事務事實表為例，選定三個業(yè)務過程一一下單、支付和成功完結，不同的業(yè)務過程擁有不同的事實。比如在下單業(yè)務過程中，需要包含下單金額、下單數(shù)量、下單分攤金額；在支付業(yè)務過程中，包含支付金額、分攤郵費、折扣金額、紅包金額、積分金額；在完結業(yè)務過程中包含確認收貨金額等。由于粒度是子訂單，所以對于一些父訂單上的金額需要分攤到子訂單上，比如父訂單郵費、父訂單折扣等。5.冗余維度在確定維度時，包含了買賣家維度、商品維度、類目維度、收發(fā)貨維度等，Kimball維度建模理論建議在事實表中只保存這些維表的外鍵，而淘寶交易事務事實表在Kimball維度建模基礎之上做了進一步的優(yōu)化，將買賣家星級、標簽、店鋪名稱、商品類型、商品特征、商品屬性、類目層級等維度屬性都冗余到事實表中，提高對事實表進行過濾查詢、統(tǒng)計聚合的效率，如圖4.5所示。4.2.2單事務事實表單事務事實表，顧名思義，即針對每個業(yè)務過程設計一個事實表。這樣設計的優(yōu)點不言而喻，可以方便地對每個業(yè)務過程進行獨立的分析研究。1688交易流程則采用這種模式構建事務事實表。1688交易和淘寶交易相似，主要流程也是下單、支付、發(fā)貨和完結，而在這四個關鍵流程中1688交易選擇下單和支付兩個業(yè)務過程設計事務事實表，分別是1688交易訂單下單事務事實表和1688交易訂單支付事務事實表。選定業(yè)務過程后，將對每個業(yè)務過程確定粒度、維度和事實。對于1688交易訂單下單事務事實表，確定子訂單粒度，選擇買家、賣家、商品、父訂單、收貨地區(qū)維度，事實包含下單分攤金額和折扣金額，如圖4.6所示；而對于1688交易訂單支付事務事實表，粒度和維度與交易訂單下單事務事實表相同，所表達的事實則不一樣，包含支付金額、支付調整金額和支付優(yōu)惠等，如圖4.7所示；1688交易針對下單和支付分別建立單事務事實表后，每天的下單記錄則進入當天的下單事務事實表中，每天的支付記錄進入當天的支付事務事實表中，由于事實表具有稀疏性質，因此只有當天數(shù)據(jù)才會進入當天的事實表中。下面以具體交易訂單為例，展示單事務事實表的設計實例。4.2.3多事務事實表多事務事實表，將不同的事實放到同一個事實表中，即同一個事實表包含不同的業(yè)務過程。多事務事實表在設計時有兩種方法進行事實的處理：①不同業(yè)務過程的事實使用不同的事實字段進行存放；②不同業(yè)務過程的事實使用同一個事實字段進行存放，但增加一個業(yè)務過程標簽。如何選擇：當不同業(yè)務過程的度量比較相似、差異不大時，可以采用第二種多事務事實表的設計方式，使用同一個字段來表示度量數(shù)據(jù)。但這種方式存在一個問題一一在同一個周期內(nèi)會存在多條記錄（如淘寶收藏商品事務事實表，增加【收藏刪除類型】，collect/delete）當不同業(yè)務過程的度量差異較大時，可以選擇第一種多事務事實表的設計方式，將不同業(yè)務過程的度量使用不同字段冗余到表中，非當前業(yè)務過程則置零表示。這種方式所存在的問題是度量字段零值較多（如淘寶交易事務事實表，針對不同業(yè)務過程如下單，則打一個是否當天下單的標簽）4.2.4兩種事實表對比業(yè)務過程對于單事務事實表，一個業(yè)務過程建立一個事實表，只反映一個業(yè)務過程的事實；對于多事務事實表，在同一個事實表中反映多個業(yè)務過程。多個業(yè)務過程是否放到同一個事實表中，首先需要分析不同業(yè)務過程之間的相似性和業(yè)務源系統(tǒng)。比如淘寶交易的下單、支付和成功完結這三個業(yè)務過程是存在相似性的，都屬于訂單處理中的一環(huán)，并且都來自于交易系統(tǒng)，因此適合放到同一個事務事實表中。粒度和維度在考慮是采用單事務事實表還是多事務事實表時，另一個關鍵點就是粒度和維度，在確定好業(yè)務過程后，需要基于不同的業(yè)務過程確定粒度和維度，當不同業(yè)務過程的粒度相同，同時擁有相似的維度時，此時就可以考慮采用多事務事實表。如果粒度不同，則必定是不同的事實表。比如交易中支付和發(fā)貨有不同的粒度，則無法將發(fā)貨業(yè)務過程放到淘寶交易事務事實表中。事實對于不同的業(yè)務過程，事實往往是不同的，單事務事實表在處理事實上比較方便和靈活，僅僅體現(xiàn)同一個業(yè)務過程的事實即可，而多事務事實表由于有多個業(yè)務過程，所以有更多的事實需要處理。如果單一業(yè)務過程的事實較多，同時不同業(yè)務過程的事實又不相同，則可以考慮使用單事務事實表，處理更加清晰;若使用多事務事實表，則會導致事實表零值或空值字段較多。下游業(yè)務使用單事務事實表對于下游用戶而言更容易理解，關注哪個業(yè)務過程就使用相應的事務事實表；而多事務事實表包含多個業(yè)務過程，用戶使用時往往較為困惑。1688和淘寶交易分別采用了這兩種方式，從日常使用來看，對于淘寶交易事務事實表下游用戶確實有一定的學習成本。計算存儲成本針對多個業(yè)務過程設計事務事實表，是采用單事務事實表還是多事務事實表，對于數(shù)據(jù)倉庫的計算存儲成本也是參考點之一，當業(yè)務過程數(shù)據(jù)來源于同一個業(yè)務系統(tǒng)，具有相同的粒度和維度，且維度較多而事實相對不多時，此時可以考慮使用多事務事實表，不僅其加工計算成本較低，同時在存儲上也相對節(jié)省，是一種較優(yōu)的處理方式。4.2.5父子事實的處理方式e.g.子訂單分攤的有效下單金額和支付金額4.2.6事實的設計準則事實完整性：盡可能多地獲取所有的度量事實一致性：事實表中統(tǒng)一計算可以保證度量的一致性（比如金額由數(shù)量*單價先在事實表算出來）事實可加性：事務事實表中關注更多的是可加性事實，下游用戶在聚合統(tǒng)計時更加方便4.3周期快照事實表狀態(tài)度量，比如賬戶余額、買賣家星級、商品庫存、賣家累積交易額等無法聚集，比如溫度等簡稱“快照事實表”：在確定的間隔內(nèi)對實體的度量進行抽樣，這樣可以很容易地研究實體的度量值，而不需要聚集長期的事務歷史4.3.1特性用快照采樣狀態(tài)快照粒度快照需要采樣的周期以及什么將被采樣e.g.淘寶交易有針對賣家加類目的每月匯總事實表，每月統(tǒng)計一次，同時維度也不僅一個，包含了賣家和類目。密度與稀疏性e.g.針對賣家的歷史至今的下單和支付金額，無論當天賣家是否有下單支付事實，都會給該賣家記錄一行。半可加性半可加性事實不能根據(jù)時間維度獲得有意義的匯總結果雖然不能匯總，但可以計算一些平均值4.3.2實例單維度的每天快照事實表混合維度的每天快照事實表直接使用操作型系統(tǒng)的數(shù)據(jù)作為周期快照事實表的數(shù)據(jù)源進行加工，e.g.淘寶賣家信用分/DSR快照事實表/貨值拍照表全量快照事實表：e.g.淘寶好中差評快照事實表，無事實的事實表，更多關注評價的狀態(tài)4.3.3注意事項事務與快照成對設計數(shù)據(jù)倉庫維度建模時，對于事務事實表和快照事實表往往都是成對設計的，互相補充，以滿足更多的下游統(tǒng)計分析需求，特別是在事務事實表的基礎上可以加工快照事實表，如前面所述的淘寶賣家歷史至今快照事實表，就是在事務事實表的基礎上加工得到的，既豐富了星形模型，又降低了下游分析的成本。附加事實快照事實表在確定狀態(tài)度量時，一般都是保存采樣周期結束時的狀態(tài)度量。但是也有分析需求需要關注上一個采樣周期結束時的狀態(tài)度量，而又不愿意多次使用快照事實表，因此一般在設計周期快照事實表時會附加一些上一個采樣周期的狀態(tài)度量