全文共5773個字，建議閱讀15分鐘
本文目錄：
一、指導思想
二、資料調研
三、架構設計
四、名額體系搭建
五、模型設計
六、次元設計
七、事實表設計
八、其他規範
OneData是阿裡巴巴内部進行資料整合和管理方法體系和工具，文末下載下傳OneData數倉建設PPT。
一、指導思想
首先，要進行充分的業務調研和需求分析。
其次，進行資料總體架構設計，主要是根據資料域對資料進行劃分；按照次元模組化理論，建構總線矩陣，抽象出業務過程和次元。
再次，對報表需求進行抽象整理出相關名額體系，使用OneData工具完成名額規範定義和模型設計。最後，是代碼研發和運維。
其實施流程主要分為：資料調研、架構設計、規範定義和模型設計。
二、資料調研
1. 業務調研
需要确認要規劃進數倉的業務領域，以及各業務領域包含的功能子產品，以阿裡的業務為例，可規劃如下矩陣：
2. 需求調研
了解需求方關系哪些名額？需要哪些次元、度量？資料是否沉澱到彙總層等到。
三、架構設計
1. 資料域的劃分
資料域是将業務過程或者次元進行抽象的集合，一般資料域和應用系統(功能子產品)有聯系，可以考慮将同一個功能子產品系統的業務過程劃分到一個資料域：
2. 建構總線矩陣
在進行充分的業務調研和需求調研後，就要建構總線矩陣了，需要做兩件事情：
- 明确每個資料域下有哪些業務過程。
- 業務過程與哪些次元相關，并通過總線矩陣定義每個資料域下的業務過程和次元：
四、名額體系搭建
1. 基本概念
資料域：指面向業務分析，将業務過程或者次元進行抽象的集合。
業務過程：指企業的業務活動中的事件。
時間周期：用來明确資料統計的事件範圍或者時間點，如近30天、截至目前。
修飾類型：對修飾詞的一種抽象劃分。
修飾詞：指除統計次元外名額的業務場景限定抽象。抽象詞隸屬于一種抽象類型，如通路終端類型下的pc、安卓、蘋果。
度量/原子名額：具有明确含義的業務名詞。如：支付金額。
次元：次元是度量的環境，用來反應業務的一類屬性，這類屬性的集合稱為一個次元，也可以稱為實體對象，如地理次元、時間次元。
次元屬性：對次元的描述，隸屬于一個次元。如：地理次元下的國家、省份。
派生名額：原子名額+多個修飾詞(可選)+時間周期。
明确原子名額、修飾詞、時間周期和派生名額的定義。
2. 操作細則
派生名額來源于三類名額：事務型名額、存量型名額和複合型名額。
事務型名額：指對業務活動進行衡量的名額。
存量型名額：指對實體對象某些狀态的統計。
複合型名額，在上述兩種名額基礎上複合而成的。
五、模型設計
1. 資料分層
業界對數倉分層的看法大同小異，大體上認為分為接入層、中間層和應用層三層，不過對中間層的了解有些差異。
2. 接入層(ods)
業務資料一般是采用dataX或者sqoop等以固定頻率同步到數倉中建構ODS層；
如果是日志資料則通過flume或者Kafka等同步到數倉中。
接入層一般不會對源資料做任何處理、清洗，便于之後回溯。
3. 明細層(dwd)
理論上明細層資料是對ods層資料進行清洗加工，提高ods層資料的可用性，對于dwd層資料是否同層引用的觀點需要權衡：
- 一般情況下dwd層不建議同層引用，這樣做可以減少明細層任務之間的依賴，減少節點深度。
- 但是在某些場景下，ods層到dwd層資料加工邏輯複雜，計算開銷大，這時可以權衡考慮适當複用dwd表來建構新的dwd表。
4. 彙總層(dws)
這一層依賴我們的名額體系，将dwd層的資料按照各個次元進行聚合計算。
5. 資料集市層(dwm)
當我們有一些跨業務域的聚合統計需求時，放到這一層。
6. 應用層(app)
這一層主要針對彙總層，進行相關名額的組合，生成報表。
六、次元設計
次元模組化中，将度量稱為事實，次元用于分析事實所需要的多樣環境。次元的作用一般是查詢、分類彙總以及排序。
通過報表的限制條件，以及之前資料調研和業務方的溝通，我們可以獲得次元。
次元通過主鍵與事實表進行關聯，次元表的主鍵分為代理鍵和自然鍵兩種；代理鍵不具有業務含義，一般用于處理緩慢變化次元，自然鍵則具有業務含義。
1. 次元設計基本方法
- 選擇或者建立一個次元，通過之前總線矩陣的建構掌握了目前數倉架構中的次元。
- 确定主維表。此處主維表一般是ODS表，直接與業務系統同步。
- 确定相關維表。數倉是業務源系統的資料整合，不同業務系統或者同一業務系統中的表之間存在關聯性。跟據對業務的梳理，我們可以确認哪些表和主維表存在關聯關系，并選擇其中的某些表用于生成次元屬性。
- 确定次元屬性。本步驟分為兩階段，第一階段是從主維表中選擇次元屬性或生成新的次元屬性；第二階段是從相關維表中選擇次元屬性或生成新的次元屬性。
2. 規範化和反規範化
當具有多層次的次元屬性，按照第三範式進行規範化後形成一系列次元表，而非單一次元表，這種模組化稱為雪花模式。
将次元的屬性層次合并到單個次元中的操作稱為反規範化。
3. 一緻性次元和交叉探查
我們存在很多需求是對于不同資料域的業務過程或同一資料域的不同業務過程合并在一起觀察。例如：對于日志資料域統計商品次元的近一天PV和UV；對于交易資料域統計商品次元近一天的GMV。
這種将不同資料域的商品事實合并在一起進行資料探查，稱為交叉探查。
數倉能進行交叉探查的前提是，不同資料域要具有一緻性次元。
4. 次元整合
由于數倉的資料源來源于不同的應用系統，應用系統之間互相獨立，是以對同一資訊的描述、存儲都可能具有差異。
而這些具有差異的資料進入數倉後需要整合在一起：
- 命名規範的統一。表名、字段名等統一。
- 字段類型的統一。相同和相似字段的字段類型統一。
- 公共代碼以及代碼值的統一。
- 業務含義相同的表的統一。主要依據高内聚、低耦合的理念，将業務關系大，源系統影響差異小的表進行整合。
表級别的整合主要有兩種形式：
垂直整合，即不同來源表包含相同的資料集，隻是存儲的資訊不同，可以整合到同一個次元模型中。
水準整合，即不同來源表包含不同的資料集，這些子集之間無交叉或存在部分交叉，如果有交叉則去重；如果無交叉，考慮不同子集的自然鍵是否沖突，不沖突則可以将各子集自然鍵作為整合後的自然鍵，或者将各自然鍵加工成一個超自然鍵。
5. 拉連結清單
拉連結清單，又稱為極限存儲技術。假設某一張表是用來存儲全量使用者資訊的，一般我們的處理方式是，用每個分區去存儲每天全量資料的快照，這種方式的問題是，如果我希望儲存使用者的所有曆史狀态，我可能需要永久儲存每一個曆史分區。
如果使用拉連結清單，每個分區可以儲存每個使用者在當天的曆史狀态，同時曆史分區也可以進行清理。
這樣，雖然單個分區中存儲的資料變多了，但是某些曆史分區的資料被清理後，整個表存儲的資料會變少了，因為很多沒有變化的使用者資訊快照被清理了。
6. 微型次元
微型次元的建立是通過将一部分不穩定的屬性從相對穩定的主次元中移除，放置到擁有自己代理鍵的新表來實作。
7. 遞歸層次
遞歸層次指的是某維表的執行個體值的層次關系，次元的遞歸層次分為有固定數量級别的均衡層次結構和無固定數量級别的非均衡層次結構。
由于數倉中一般不支援遞歸SQL的功能來處理這種層次結構，是以需要用到其他方式。
- 層次結構扁平化，适合均衡層次結構次元。
- 層次橋接表，适合非均衡層次結構次元。
8. 多值次元
多值次元指事實表的一條記錄在某次元表中有多條記錄與之對應。
針對多值次元，常見的處理方式有三種：
- 降低事實表的粒度。
- 列擴充。
- 較為通用的方式，采用橋接表。
9. 雜項次元
雜項次元是由操作型系統中的訓示符或者标志字段組合而成，一般不在一緻性次元之列。
這些次元如果作為事實存在事實表中，則會導緻事實表占用空間變大；如果單獨建立維表，則會出現許多零碎的小維表。
這時，通常的解決方案是建立雜項次元，将這些字段建立到一個維表中，在事實表中隻需儲存一個外鍵即可，雜項次元可以了解為将許多小維表通過行轉列的方式存儲到一張大維表中的處理方案。
10. 退化次元
指次元屬性直接存儲到事實表中的次元。
七、事實表設計
事實表中一條記錄所表達的業務細節程度稱為粒度。
1. 事實類型
作為度量業務過程的事實，有可加性、半可加性和不可加性三種類型：
可加性事實指可以按照與事實表關聯的任意次元進行彙總。
半可加事實隻能按照特定次元彙總，不能對所有次元彙總。
不可加性事實完全不具備可加性，比如比例事實。對于不可加性事實可考慮分解為可加的元件來實作聚合。
2. 事實表類型
最常見的事實表有三種類型：事務事實表、周期快照事實表和累積快照事實表。
事務事實表用來描述業務過程，表示對應時空上某點的度量事件，儲存的是最原子的資料，也稱為原子事實表。在實際使用中，一般作為明細層使用，例如下單明細、支付明細等。
周期快照事實表的一行，以具有規律性的時間間隔記錄事實。如每日庫存快照表、每日使用者餘額快照表。
累積快照事實表用來表述過程開始和結束之間的關鍵步驟事件，覆寫過程的整個生命周期，通常具有多個日期字段來記錄關鍵時間點，當過程随着生命周期不斷變化時，記錄也會随着過程的變化而被修改。以事務事實表中提到的訂單例子為例，可以做一個和訂單相關的，涉及訂單下單、推單、搶單、支付等各個環節的一張訂單全生命周期快照表。
此外，還有一種無事實的事實表，單純隻記錄某一動作發生，其事件的量化是非數字的，比較典型的例子是通路點選日志。
3. 事實表設計原則
- 盡可能包含所有與業務過程相關的事實。
- 隻選擇與業務過程相關的事實。
- 分解不可加性事實為可加的元件。
- 在選擇次元和事實之前必須先聲明粒度。
- 在同一個事實表中不能有多種不同粒度的事實。
- 事實的機關要保持一緻。
- 對事實的null值要處理，建議用0填充。
- 使用退化次元提高事實表的易用性。
4. 事實表設計方法
- 選擇業務過程及确認事實表類型。
- 聲明粒度。
- 确定次元。
- 确定事實。
- 備援次元。
5. 事實表
單事務事實表，針對每個業務過程設計一個事實表。這樣友善對每個業務過程進行獨立的分析研究。
多事務事實表，将不同的事實放到同一個事實表中，即同一個事實表包含不同的業務過程。
多事務事實表有兩種方法進行事實處理：
- 不同業務過程的事實使用不同的事實字段進行存放；如果不是不是目前業務過程的度量，可以考慮用0值填充。
- 不同業務過程的事實使用同一個事實字段進行存放，但增加一列作為業務過程标簽，記錄該事務是否在當天完成。
關于多事務事實表具體采用哪種方式進行事實處理：
在實際應用中，當業務過程度量比較相似、差異不打時，可以采取第二種多事務事實表的設計方式，使用同一個字段來表示度量資料。但這種方式存在一個問題，在同一個周期内會存在多條記錄。
當不同業務過程的度量差異較大時，可以選擇第一種多事務事實表的設計方式，将不同業務過程的度量使用不同字段備援到表中，非目前業務過程則置為0，這種方式存在的問題是度量字段0值會比較多。
具體使用單事務事實表還是多事務事實表，需要從以下幾點分析：
- 業務過程
多個業務過程是否放到同一個事實表中，首先需要分析不同業務過程之間的相似性和業務源系統。
比如淘寶交易的下單、支付和成功完結三個業務過程存在相似性，并且都來自于一個應用系統-交易系統，适合放到同一個事務事實表。
- 粒度和次元
在考慮是采用單事務表還是多事務表時，一個關鍵點是粒度和次元。
在确定好業務過程後，需要基于不同的業務過程确定粒度和次元，當不同業務過程的粒度相同，同時擁有相似次元時，可以考慮采用多事務事實表。如果粒度不同，必定是存存儲在不同僚務表中的。
- 事實
如果單一業務過程的事實較多，同時不同業務過程的事實又不相同，則考慮使用單事務事實表，處理更加清晰；
若使用多事務事實表，則會導緻事實表零值或空值字段較多。
- 下遊業務使用
單事務事實表對于下遊使用者而言更容易了解，關注哪個業務過程就使用相應的事務事實表；而多事務事實表包含多個業務過程，使用者使用時往往較為困惑。
6. 周期快照事實表
事務事實表可以很好的跟蹤一個事件，并進行度量分析。
然後，當需要一些狀态度量時，比如賬戶餘額、商品庫存、賣家累積交易額等，則需要聚集與之相關的事務才能進行識别計算，也就是周期快照事實表。
周期快照事實表在确定的間隔内對實體的度量進行抽樣，以研究實體的路徑成本，而不需要聚集長期的事務曆史。
7. 累積快照事實表
對于類似于研究事件之間時間間隔的需求，事務事實表處理邏輯複雜且性能差，采用累積快照事實表可以很好解決。
快照事實表中收集到到狀态度量都是半可加到，不能根據時間次元獲得有意義到彙總結果。
數倉在進行次元模組化時，對于事務事實表和快照事實表往往都是成對設計，互相補充，以滿足更多下遊統計分析需求，特别是在事務事實表基礎上可以加工快照事實表。
八、其他規範
1. 層次調研約定
- 應用層優先調用公共層資料。
- 已經存在的中間層資料，不允許應用層跨中間層從ODS層重複加工資料。
- 中間層團隊應該積極了解應用層資料的建設需求，将公用的資料沉澱到公共層，為其他團隊提供資料服務。
- 應用層團隊也需要積極配合中間層團隊進行資料公共層建設的改造和遷移。
- 必須避免過度使用ODS層引用和不合理的資料複制和子集合備援。
2. 命名規範
表命名規範：<層次><業務域名稱><資料域名稱><業務過程名稱|自定義表名><重新整理周期+存儲政策>
字段命名規範：
3. 開發規範
- 總原則
- 原則上不能依賴非資料團隊節點。
- 未獲得節點owner許可的情況下，不能擅自修改别人的節點。
- 不能随意變更節點owner，必須知會接收人并得到同意。
--END--