本文目錄：

一、指導思想

二、數據調研

三、架構設計

四、指標體系搭建

五、模型設計

六、維度設計

七、事實表設計

八、其他規(guī)范

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

一、指導思想

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

其次，進行數據總體架構設計，主要是根據數據域對數據進行劃分；按照維度建模理論，構建總線矩陣，抽象出業(yè)務過程和維度。

再次，對報表需求進行抽象整理出相關指標體系，使用OneData工具完成指標規(guī)范定義和模型設計。最后，是代碼研發(fā)和運維。

其實施流程主要分為：數據調研、架構設計、規(guī)范定義和模型設計。

二、數據調研

1． 業(yè)務調研

需要確認要規(guī)劃進數倉的業(yè)務領域，以及各業(yè)務領域包含的功能模塊，以阿里的業(yè)務為例，可規(guī)劃如下矩陣：

2． 需求調研

了解需求方關系哪些指標？需要哪些維度、度量？數據是否沉淀到匯總層等到。

三、架構設計

1． 數據域的劃分

數據域是將業(yè)務過程或者維度進行抽象的集合，一般數據域和應用系統(tǒng)（功能模塊）有聯系，可以考慮將同一個功能模塊系統(tǒng)的業(yè)務過程劃分到一個數據域：

2． 構建總線矩陣

在進行充分的業(yè)務調研和需求調研后，就要構建總線矩陣了，需要做兩件事情：

明確每個數據域下有哪些業(yè)務過程。業(yè)務過程與哪些維度相關，并通過總線矩陣定義每個數據域下的業(yè)務過程和維度：

四、指標體系搭建

1． 基本概念

數據域：指面向業(yè)務分析，將業(yè)務過程或者維度進行抽象的集合。

業(yè)務過程：指企業(yè)的業(yè)務活動中的事件。

時間周期：用來明確數據統(tǒng)計的事件范圍或者時間點，如近30天、截至當前。

修飾類型：對修飾詞的一種抽象劃分。

修飾詞：指除統(tǒng)計維度外指標的業(yè)務場景限定抽象。抽象詞隸屬于一種抽象類型，如訪問終端類型下的pc、安卓、蘋果。

度量／原子指標：具有明確含義的業(yè)務名詞。如：支付金額。

維度：維度是度量的環(huán)境，用來反應業(yè)務的一類屬性，這類屬性的集合稱為一個維度，也可以稱為實體對象，如地理維度、時間維度。

維度屬性：對維度的描述，隸屬于一個維度。如：地理維度下的國家、省份。

派生指標：原子指標＋多個修飾詞（可選）＋時間周期。

明確原子指標、修飾詞、時間周期和派生指標的定義。

2． 操作細則

派生指標來源于三類指標：事務型指標、存量型指標和復合型指標。

事務型指標：指對業(yè)務活動進行衡量的指標。

存量型指標：指對實體對象某些狀態(tài)的統(tǒng)計。

復合型指標，在上述兩種指標基礎上復合而成的。

五、模型設計

1． 數據分層

業(yè)界對數倉分層的看法大同小異，大體上認為分為接入層、中間層和應用層三層，不過對中間層的理解有些差異。

2． 接入層（ods）

業(yè)務數據一般是采用dataX或者sqoop等以固定頻率同步到數倉中構建ODS層；

如果是日志數據則通過flume或者Kafka等同步到數倉中。

接入層一般不會對源數據做任何處理、清洗，便于之后回溯。

3． 明細層（dwd）

理論上明細層數據是對ods層數據進行清洗加工，提高ods層數據的可用性，對于dwd層數據是否同層引用的觀點需要權衡：

一般情況下dwd層不建議同層引用，這樣做可以減少明細層任務之間的依賴，減少節(jié)點深度。但是在某些場景下，ods層到dwd層數據加工邏輯復雜，計算開銷大，這時可以權衡考慮適當復用dwd表來構建新的dwd表。4． 匯總層（dws）

這一層依賴我們的指標體系，將dwd層的數據按照各個維度進行聚合計算。

5． 數據集市層（dwm）

當我們有一些跨業(yè)務域的聚合統(tǒng)計需求時，放到這一層。

6． 應用層（app）

這一層主要針對匯總層，進行相關指標的組合，生成報表。

六、維度設計

維度建模中，將度量稱為事實，維度用于分析事實所需要的多樣環(huán)境。維度的作用一般是查詢、分類匯總以及排序。

通過報表的約束條件，以及之前數據調研和業(yè)務方的溝通，我們可以獲得維度。

維度通過主鍵與事實表進行關聯，維度表的主鍵分為代理鍵和自然鍵兩種；代理鍵不具有業(yè)務含義，一般用于處理緩慢變化維度，自然鍵則具有業(yè)務含義。

1． 維度設計基本方法選擇或者新建一個維度，通過之前總線矩陣的構建掌握了目前數倉架構中的維度。確定主維表。此處主維表一般是ODS表，直接與業(yè)務系統(tǒng)同步。確定相關維表。數倉是業(yè)務源系統(tǒng)的數據整合，不同業(yè)務系統(tǒng)或者同一業(yè)務系統(tǒng)中的表之間存在關聯性。跟據對業(yè)務的梳理，我們可以確認哪些表和主維表存在關聯關系，并選擇其中的某些表用于生成維度屬性。確定維度屬性。本步驟分為兩階段，第一階段是從主維表中選擇維度屬性或生成新的維度屬性；第二階段是從相關維表中選擇維度屬性或生成新的維度屬性。2． 規(guī)范化和反規(guī)范化

當具有多層次的維度屬性，按照第三范式進行規(guī)范化后形成一系列維度表，而非單一維度表，這種建模稱為雪花模式。

將維度的屬性層次合并到單個維度中的操作稱為反規(guī)范化。

3． 一致性維度和交叉探查

我們存在很多需求是對于不同數據域的業(yè)務過程或同一數據域的不同業(yè)務過程合并在一起觀察。例如：對于日志數據域統(tǒng)計商品維度的近一天PV和UV；對于交易數據域統(tǒng)計商品維度近一天的GMV。

這種將不同數據域的商品事實合并在一起進行數據探查，稱為交叉探查。

數倉能進行交叉探查的前提是，不同數據域要具有一致性維度。

4． 維度整合

由于數倉的數據源來源于不同的應用系統(tǒng)，應用系統(tǒng)之間相互獨立，因此對同一信息的描述、存儲都可能具有差異。

而這些具有差異的數據進入數倉后需要整合在一起：

命名規(guī)范的統(tǒng)一。表名、字段名等統(tǒng)一。字段類型的統(tǒng)一。相同和相似字段的字段類型統(tǒng)一。公共代碼以及代碼值的統(tǒng)一。業(yè)務含義相同的表的統(tǒng)一。主要依據高內聚、低耦合的理念，將業(yè)務關系大，源系統(tǒng)影響差異小的表進行整合。

表級別的整合主要有兩種形式：

垂直整合，即不同來源表包含相同的數據集，只是存儲的信息不同，可以整合到同一個維度模型中。

水平整合，即不同來源表包含不同的數據集，這些子集之間無交叉或存在部分交叉，如果有交叉則去重；如果無交叉，考慮不同子集的自然鍵是否沖突，不沖突則可以將各子集自然鍵作為整合后的自然鍵，或者將各自然鍵加工成一個超自然鍵。

5． 拉鏈表

拉鏈表，又稱為極限存儲技術。假設某一張表是用來存儲全量用戶信息的，一般我們的處理方式是，用每個分區(qū)去存儲每天全量數據的快照，這種方式的問題是，如果我希望保存用戶的所有歷史狀態(tài)，我可能需要永久保存每一個歷史分區(qū)。

如果使用拉鏈表，每個分區(qū)可以保存每個用戶在當天的歷史狀態(tài)，同時歷史分區(qū)也可以進行清理。

這樣，雖然單個分區(qū)中存儲的數據變多了，但是某些歷史分區(qū)的數據被清理后，整個表存儲的數據會變少了，因為很多沒有變化的用戶信息快照被清理了。

6． 微型維度

微型維度的創(chuàng)建是通過將一部分不穩(wěn)定的屬性從相對穩(wěn)定的主維度中移除，放置到擁有自己代理鍵的新表來實現。

7． 遞歸層次

遞歸層次指的是某維表的實例值的層次關系，維度的遞歸層次分為有固定數量級別的均衡層次結構和無固定數量級別的非均衡層次結構。

由于數倉中一般不支持遞歸SQL的功能來處理這種層次結構，所以需要用到其他方式。

層次結構扁平化，適合均衡層次結構維度。層次橋接表，適合非均衡層次結構維度。

8． 多值維度

多值維度指事實表的一條記錄在某維度表中有多條記錄與之對應。

針對多值維度，常見的處理方式有三種：

降低事實表的粒度。列擴展。較為通用的方式，采用橋接表。9． 雜項維度

雜項維度是由操作型系統(tǒng)中的指示符或者標志字段組合而成，一般不在一致性維度之列。

這些維度如果作為事實存在事實表中，則會導致事實表占用空間變大；如果單獨建立維表，則會出現許多零碎的小維表。

這時，通常的解決方案是建立雜項維度，將這些字段建立到一個維表中，在事實表中只需保存一個外鍵即可，雜項維度可以理解為將許多小維表通過行轉列的方式存儲到一張大維表中的處理方案。

10． 退化維度

指維度屬性直接存儲到事實表中的維度。

七、事實表設計

事實表中一條記錄所表達的業(yè)務細節(jié)程度稱為粒度。

1． 事實類型

作為度量業(yè)務過程的事實，有可加性、半可加性和不可加性三種類型：

可加性事實指可以按照與事實表關聯的任意維度進行匯總。

半可加事實只能按照特定維度匯總，不能對所有維度匯總。

不可加性事實完全不具備可加性，比如比例事實。對于不可加性事實可考慮分解為可加的組件來實現聚合。

2． 事實表類型

最常見的事實表有三種類型：事務事實表、周期快照事實表和累積快照事實表。

事務事實表用來描述業(yè)務過程，表示對應時空上某點的度量事件，保存的是最原子的數據，也稱為原子事實表。在實際使用中，一般作為明細層使用，例如下單明細、支付明細等。

周期快照事實表的一行，以具有規(guī)律性的時間間隔記錄事實。如每日庫存快照表、每日用戶余額快照表。

累積快照事實表用來表述過程開始和結束之間的關鍵步驟事件，覆蓋過程的整個生命周期，通常具有多個日期字段來記錄關鍵時間點，當過程隨著生命周期不斷變化時，記錄也會隨著過程的變化而被修改。以事務事實表中提到的訂單例子為例，可以做一個和訂單相關的，涉及訂單下單、推單、搶單、支付等各個環(huán)節(jié)的一張訂單全生命周期快照表。

此外，還有一種無事實的事實表，單純只記錄某一動作發(fā)生，其事件的量化是非數字的，比較典型的例子是訪問點擊日志。

3． 事實表設計原則盡可能包含所有與業(yè)務過程相關的事實。只選擇與業(yè)務過程相關的事實。分解不可加性事實為可加的組件。在選擇維度和事實之前必須先聲明粒度。在同一個事實表中不能有多種不同粒度的事實。事實的單位要保持一致。對事實的null值要處理，建議用0填充。使用退化維度提高事實表的易用性。4． 事實表設計方法選擇業(yè)務過程及確認事實表類型。聲明粒度。確定維度。確定事實。冗余維度。5． 事實表

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

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

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

不同業(yè)務過程的事實使用不同的事實字段進行存放；如果不是不是當前業(yè)務過程的度量，可以考慮用0值填充。不同業(yè)務過程的事實使用同一個事實字段進行存放，但增加一列作為業(yè)務過程標簽，記錄該事務是否在當天完成。

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

在實際應用中，當業(yè)務過程度量比較相似、差異不打時，可以采取第二種多事務事實表的設計方式，使用同一個字段來表示度量數據。但這種方式存在一個問題，在同一個周期內會存在多條記錄。

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

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

業(yè)務過程

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

比如淘寶交易的下單、支付和成功完結三個業(yè)務過程存在相似性，并且都來自于一個應用系統(tǒng)－交易系統(tǒng)，適合放到同一個事務事實表。

粒度和維度

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

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

事實

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

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

下游業(yè)務使用

單事務事實表對于下游用戶而言更容易理解，關注哪個業(yè)務過程就使用相應的事務事實表；而多事務事實表包含多個業(yè)務過程，用戶使用時往往較為困惑。

6． 周期快照事實表

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

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

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

7． 累積快照事實表

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

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

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

八、其他規(guī)范

1． 層次調研約定應用層優(yōu)先調用公共層數據。已經存在的中間層數據，不允許應用層跨中間層從ODS層重復加工數據。中間層團隊應該積極了解應用層數據的建設需求，將公用的數據沉淀到公共層，為其他團隊提供數據服務。應用層團隊也需要積極配合中間層團隊進行數據公共層建設的改造和遷移。必須避免過度使用ODS層引用和不合理的數據復制和子集合冗余。2． 命名規(guī)范

表命名規(guī)范：＜層次＞＜業(yè)務域名稱＞＜數據域名稱＞＜業(yè)務過程名稱｜自定義表名＞＜刷新周期＋存儲策略＞

字段命名規(guī)范：

3． 開發(fā)規(guī)范總原則原則上不能依賴非數據團隊節(jié)點。未獲得節(jié)點owner許可的情況下，不能擅自修改別人的節(jié)點。不能隨意變更節(jié)點owner，必須知會接收人并得到同意。