本文分享主題為數倉OneData體系建設的方法論。主要內容包括：

01、背景
首先來看數倉的方法論體系。
1. 數據倉庫

① 數據倉庫是什么
先通過一個生活場景中的案例來理解、認識數倉。

例如一家企業是做食品加工進出口業務的，需要采購大米、小麥等食品加工必需的原材料，采購時則需要通過運輸至貨品集中處進行卸貨，并按一定類別分類儲存，再通過處理將原材料加工成面粉、米粉等半成品，最終在通過一道加工程序將半成品處理加工為成品進行銷售。在數倉、數據中臺、湖倉一體的應用場景下，對外展現數據或提供數據服務時也需要將企業內外部把非結構化或半結構化的數據進行匯總到一個地方，無論是叫ODS（結構化數據）或暫存區，接下來會在數倉基礎數據區把數據根據不同的主題域（如客戶、產品、交易等）進行分類成明細數據，然后在匯總區依據共性維度把一些公共指標進行加工匯總或關聯聚合以保證數據指標的一致性，并減少冗余重復工作量，最后按業務的應用主題（如客戶分析、產品分析、風險分析等）進行深度加工匯總，最終對外提供服務（如固定報表、多維分析、對外的dataAPI、算法能力等）。其實數倉架構與生活場景的案例差不多，主要是對數據做相應的分層，每一層都有不同的作用。
② 數據倉庫方法論
數據倉庫從方法論角度看，在這個領域中主要分為兩種流派，分別由Bill Inmon及Ralph Kimball所倡導。
Ralph Kimball 基于整個原始數據源之上，通過ODS集成結構化的數據，再建設數據集市，數據集市做相應的數據展現或數據分析應用。優勢在于根據分析應用目的去建設主題分析的速度較快，前期建設成本、門檻低；不足在于經過長期累積，因各數據集市業務數據指標重復建設、口徑不一致而導致數據質量的下降，同時治理成本也比較高；
Bill Inmon 站在整個企業架構之上，匯總企業內外部的全部數據，根據業務屬性和業務要求建設統一的數倉模型，在模型內數據覆蓋比較廣且數據存在相互關聯、數據標準是一致的，通過對數據的標準化處理再把數據分發至數據集市做相應的應用。不足之處在于：首先，前期對建模人員的要求較高、需要站在整個企業架構之上了解企業全部業務；其次，因為覆蓋范圍比較廣，建設成本高和周期較長；2003年Bill Inmon提出CIF架構，融合了兩派方法論，目前大部分企業主要使用的也是CIF體系架構。
2. 數據模型
數據模型在數據倉庫中起到非常重要的作用，我們把數倉比作一輛汽車，數據模型就擔當了這輛汽車中的發動機角色。一個數據模型的穩定性、可擴展性、數據模型易用性等，是衡量數據建模水平的關鍵標準。

① OneData體系

OneData體系最初由阿里巴巴提出，最終的實現目標是數據的全局完整、含義一致、避免重復建設、對外提供統一的數據服務，目的是挖掘數據的價值、讓數據驅動業務創新。歸結起來，整個OneData的理念與Bill Inmon的理念、企業架構的思想是一致的。OneData的建設是要在底層由業務架構出發來推導、設計數據模型，從數據研發到數據服務，做到數據可管理、可追溯、可規避重復建設。OneData中有三個重要的特征： OneID：致力于實現數據的標準與統一 OneModel：致力于實現實體的統一，讓數據融通而非孤島存在，為精準的用戶畫像提供基礎； OneService：致力于實現數據服務的統一，讓數據復用而非復制。

3. 企業架構數據倉庫的關系

前面OneData體系中我們提到它是由整個企業架構來推導數據模型，那企業架構和數倉之間到底是什么關系呢？

企業架構稍微有點晦澀難懂，我們打個比方：一個企業的戰略可以看作為一個城市的頂層規劃或者定位；下一級則是城市的規劃，城市規劃就可以類比為企業架構，包含業務、應用、數據、技術四大架構。與數據相關的主要就是從業務流程推導業務對象或業務屬性，梳理出數據模型中的數據實體。

在整個企業數據架構規劃中，不可忽略的一塊就是數倉的規劃，數倉中有數據模型，數據模型在整個企業數據架構中會落地在數據倉庫中，也是數倉的參考模型。

02、數據建模流程工藝

1. OneData數據模型設計思路

建模的依據：整個建模流程中首先是建模的設計依據。上面我們講建模依據來源于企業架構、業務架構，還有行業最佳實踐、企業的應用需求； 模型層次劃分：有了建模設計依據之后，接下來就是模型層次的劃分，每一層用什么樣的設計模式。比如最頂層應用層通常使用星型模型或雪花模型；匯總層一般使用星型模型；到基礎層一般需要遵循數據三范式，提升數據穩定性和可用性。 模型設計思路：接下來就是整個模型的設計思路，設計理念（如統一共享、標準化等）、設計原則（可回溯、穩定性等）、設計策略、設計步驟等等。通過這樣的路徑產出的數據模型的復用性、穩定性等都會有比較高的提升。

2. 數據倉庫數據模型設計流程

數據倉庫數據模型的設計包括如下步驟：

需求分析：包括業務需求和數據需求

數據源的分析：會產生相應的分析報告

現有模型滿足度及差異分析：每個行業每個領域中的企業可能會有自己的數據模型產品或行業解決方案，有沉淀的內容，我們的數據模型產品在需求及數據源側（也就是前面第一、二步的需求分析和數據源分析）做相應的比對和差異分析；

概念模型設計、邏輯模型設計、邏輯模型物理化：必不可少的過程；

模型實施、模型驗證及調優

03、最佳實踐

接下來舉三個例子與大家做交流分享。

1. 百度展示廣告EDW建設

① 項目背景

2015年，百度高速發展，每個產品線、事業部都建了自己的數據集市，也發揮了很大的價值。但發展后期發現存在很多問題，煙囪式建設導致業務數據不全，雖然也能通過數據共享拿到數據，但各業務建設時有些共性指標定義不一致、標準不一致。所以啟動了一個數據治理項目，但本質上沒有解決這個問題。最后啟動了EDW建設的項目，希望把企業級所有數據匯總起來加工并對外提供數據應用或數據服務。

② 建設過程

在建設數據倉庫的過程中，根據企業架構方法論，從頂層業務架構開始梳理，然后是應用架構。

在梳理業務架構時，我們參考了行業領先實踐，把業務能力、業務流程、業務活動全部梳理出來后，把每個活動中涉及的業務信息（在華為叫業務對象）也梳理出來。梳理完之后通過業務對象的細化和展開規范化形成了數據的實體，最后把它進一步細化形成邏輯實體，針對數據存儲組件形成物理表，最終形成數倉的數據模型。

業務信息（業務對象）的梳理是非常關鍵的動作，在這里我們可以參考行業領先的實踐，在這個項目中主要對標了IAB的信息模型，提煉了關鍵的業務對象。

廣告業務中有很多參與方，包括需求方（DSP）、供應方（媒體等APP對應的SSP），需求方和供應方之間進行交易則需要經過ADX（廣告交易服務），針對用戶推送個性化的廣告則需要DMP（數據管理服務），還有風險管理（如反作弊）以及財務管理等，進而細分梳理出關鍵的業務對象。

梳理出關鍵的業務對象后，對其進行了相應的沉淀，并最終得到了關鍵的數據實體。這些關鍵的數據實體將近有八九十個，最后對其進行相應的邏輯劃分、聚合，最終形成了10大主題域。這10大主題域構成了EDW數倉的基礎層，由此之上再進行公共維度的加工形成匯總層，另外針對用戶或業務部門的分析需求形成了數據集市應用。

2. 華為數據底座

數據底座最開始是華為提出的，因為華為認為無論是數倉建設還是大數據平臺，都是數據管道。最關鍵的是數據管道里面流淌的數據或數據內容。

在華為做數據底座時做的比較好的地方就是數據入湖，建立了六大數據標準。所有能夠獲取到的數據都往數據湖匯聚，包括物理入湖和虛擬入湖（在數據量比較少的情況下或者對原系統影響不大的情況下采用了數據虛擬入湖，其實數據最終進入了數據中臺中）；

在數據入湖治理方面的六大數據標準：

明確數據Owner：來自于哪個業務、哪個流程，需要由明確的業務組織認責。

發布數據標準

定義數據密級

明確數據源：數據需要有可信的數據源（源系統），盡量不要拿二手數據，有失真的風險；

數據質量評估：在數據湖中不會對數據做清洗、轉換，保證入湖數據質量的達標、可靠；

元數據注冊：所有數據入湖之前都需要采集元數據，編制數據目錄，這樣保證入湖的所有數據都是查找、可追溯、可管理的，也就是數據可用、可控，否則就是garbage in, garbage out, 數據湖變成數據沼澤。

3. 銀行數據倉庫模型設計

金融行業的傳統數據模型設計和數據倉庫模型設計是存在差異的。

我們在做傳統數據模型設計時，主要有以下幾點問題：

自底向上：我們是根據業務部門的需求進行設計；

局部覆蓋：由于是需求驅動，只能覆蓋特定需求；

基于現狀：基于當前的業務流程、功能現狀去構建設計數據模型。

但是做數倉的時候，主要是以下幾點：

自頂向下：從頂層規劃開始，基于業務流程、業務對象、抽象實體、實體細化去設計模型的；

全局覆蓋：全面覆蓋業務場景，不局限于特定場景或需求；

考慮未來：從架構層面梳理，考慮行業通用性。

優秀案例（Teradata數據倉庫模型）

在銀行業，Teradata FS-LDM的10大主題域分別是當事人、產品、協議、事件、區域、渠道、行銷活動、資產、財務、內部機構。

04心得總結

頂層設計：OneData體系建設，需要頂層設計，從業務架構推導出數據模型。

數據分層：數據倉庫中，需要不同的分層，來保證數據模型穩定性，可擴展性和可用性，以便數據模型適應業務場景的變化。

規范性：數據模型的設計規范性、數據標準化（命名、值域等）、服務接口。