基於OneData的資料倉儲建設

本文目錄：

一、指導思想

二、資料調研

三、架構設計

四、指標體系搭建

五、模型設計

六、維度設計

七、事實表設計

八、其他規範

OneData是阿里巴巴內部進行資料整合和管理方法體系和工具。

一、指導思想

首先，要進行充分的業務調研和需求分析。

其次，進行資料總體架構設計，主要是根據資料域對資料進行劃分;按照維度建模理論，構建匯流排矩陣，抽象出業務過程和維度。

再次，對報表需求進行抽象整理出相關指標體系，使用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. 事實表設計方法

1. 選擇業務過程及確認事實表型別。

2. 宣告粒度。

3. 確定維度。

4. 確定事實。

5. 冗餘維度。

5. 事實表

單事務事實表，針對每個業務過程設計一個事實表。這樣方便對每個業務過程進行獨立的分析研究。

多事務事實表，將不同的事實放到同一個事實表中，即同一個事實表包含不同的業務過程。

多事務事實表有兩種方法進行事實處理：

• 不同業務過程的事實使用不同的事實欄位進行存放;如果不是當前業務過程的度量，可以考慮用0值填充。

• 不同業務過程的事實使用同一個事實欄位進行存放，但增加一列作為業務過程標籤，記錄該事務是否在當天完成。

關於多事務事實表具體採用哪種方式進行事實處理：

在實際應用中，當業務過程度量比較相似、差異不大時，可以採取第二種多事務事實表的設計方式，使用同一個欄位來表示度量資料。但這種方式存在一個問題，在同一個週期內會存在多條記錄。

當不同業務過程的度量差異較大時，可以選擇第一種多事務事實表的設計方式，將不同業務過程的度量使用不同欄位冗餘到表中，非當前業務過程則置為0，這種方式存在的問題是度量欄位0值會比較多。

具體使用單事務事實表還是多事務事實表，需要從以下幾點分析：

• 業務過程

多個業務過程是否放到同一個事實表中，首先需要分析不同業務過程之間的相似性和業務源系統。

比如淘寶交易的下單、支付和成功完結三個業務過程存在相似性，並且都來自於一個應用系統-交易系統，適合放到同一個事務事實表。

• 粒度和維度

在考慮是採用單事務表還是多事務表時，一個關鍵點是粒度和維度。

在確定好業務過程後，需要基於不同的業務過程確定粒度和維度，當不同業務過程的粒度相同，同時擁有相似維度時，可以考慮採用多事務事實表。如果粒度不同，必定是存儲存在不同事務表中的。

• 事實

如果單一業務過程的事實較多，同時不同業務過程的事實又不相同，則考慮使用單事務事實表，處理更加清晰;

若使用多事務事實表，則會導致事實表零值或空值欄位較多。

• 下游業務使用

單事務事實表對於下游使用者而言更容易理解，關注哪個業務過程就使用相應的事務事實表;而多事務事實表包含多個業務過程，使用者使用時往往較為困惑。

6. 週期快照事實表

事務事實表可以很好的跟蹤一個事件，並進行度量分析。

然後，當需要一些狀態度量時，比如賬戶餘額、商品庫存、賣家累積交易額等，則需要聚集與之相關的事務才能進行識別計算，也就是週期快照事實表。

週期快照事實表在確定的間隔內對實體的度量進行抽樣，以研究實體的度量值，而不需要聚集長期的事務歷史。

7. 累積快照事實表

對於類似於研究事件之間時間間隔的需求，事務事實表處理邏輯複雜且效能差，採用累積快照事實表可以很好解決。

快照事實表中收集到到狀態度量都是半可加到，不能根據時間維度獲得有意義到彙總結果。

數倉在進行維度建模時，對於事務事實表和快照事實表往往都是成對設計，互相補充，以滿足更多下游統計分析需求，特別是在事務事實表基礎上可以加工快照事實表。

八、其他規範

1. 層次調研約定

1. 應用層優先呼叫公共層資料。

2. 已經存在的中間層資料，不允許應用層跨中間層從ODS層重複加工資料。

3. 中間層團隊應該積極瞭解應用層資料的建設需求，將公用的資料沉澱到公共層，為其他團隊提供資料服務。

4. 應用層團隊也需要積極配合中間層團隊進行資料公共層建設的改造和遷移。

5. 必須避免過度使用ODS層引用和不合理的資料複製和子集合冗餘。

2. 命名規範

表命名規範：<層次><業務域名稱><資料域名稱><業務過程名稱|自定義表名><重新整理週期+儲存策略>

欄位命名規範：

3. 開發規範

• 總原則

1. 原則上不能依賴非資料團隊節點。

2. 未獲得節點owner許可的情況下，不能擅自修改別人的節點。

3. 不能隨意變更節點owner，必須知會接收人並得到同意。