一、背景二、數據倉庫介紹三、維度建模介紹四、維度建模案例五、數倉分層六、問題

一、背景

數據倉庫的核心是展現層和提供優質的服務。ETL 及其規范、分層等所做的一切都是為了一個更清晰易用的展現層。

1. 數倉架構的原則：

底層業務的數據驅動為導向同時結合業務需求驅動

便于數據分析屏蔽底層復雜業務簡單、完整、集成的將數據暴露給分析層

底層業務變動與上層需求變動對模型沖擊最小化業務系統變化影響削弱在基礎數據層（資金訂單改造）結合自上而下的建設方法削弱需求變動對模型的影響數據水平層次清晰化

高內聚松耦合主題之內或各個完整意義的系統內數據的高內聚主題之間或各個完整意義的系統間數據的松耦合

構建倉庫基礎數據層使得底層業務數據整合工作與上層應用開發工作相隔離，為倉庫大規模開發奠定基礎倉庫層次更加清晰，對外暴露數據更加統一

數倉模型不只是考慮如何設計和實現功能，設計原則應該從訪問性能、數據成本、使用成本、數據質量、擴展性來考慮。如何搭建一個好的數據倉庫：

數倉設計的3個維度：

2. 主流建模方法

當前主流建模方法為：ER模型、維度模型。

ER模型常用于OLTP數據庫建模，應用到構建數倉時更偏重數據整合， 站在企業整體考慮，將各個系統的數據按相似性一致性、合并處理，為數據分析、決策服務，但并不便于直接用來支持分析。缺陷：需要全面梳理企業所有的業務和數據流，周期長，人員要求高。

維度建模是面向分析場景而生，針對分析場景構建數倉模型；重點關注快速、靈活的解決分析需求，同時能夠提供大規模數據的快速響應性能。針對性強，主要應用于數據倉庫構建和OLAP引擎低層數據模型。優點：不需要完整的梳理企業業務流程和數據，實施周期根據主題邊界而定，容易快速實現demo，而且相對來說便于理解、提高查詢性能、對稱并易擴展。

作為大數據板塊，數據來源更加廣泛，針對的業務域也更加寬廣，所以維度建模相對來說更加靈活并適用。

在討論維度建模之前，關注數倉和BI的基本目標是非常有意義的，在做日常的數據需求的時候，經常會遇到如下幾個痛點：

收集了海量數據，不知道如何去做ETL；

不同來源的數據該如何去聚合；

如何方便業務人員快速方便的獲取數據；

如何定義重要的數據指標；

如何確保數據準確性；

數據如何支持決策；

基于上面的痛點，就需要搭建一套DW/BI系統（當然現在市面上有很多類似的產品，例如：如：QuickBI、GrowingIO、猛犸等等），但是對于公司而言，適合自己的才是最好的，大部分公司選擇自己搭建或者利用開源的軟件（例如MateBase），這個系統必須滿足：

DW/BI系統能夠方便的存儲信息（或者說能跟現在主流的數據庫打通）。也就是說系統展現的內容必須是容易理解的，對于業務人員必須直觀而且好操作，數據結構和標示必須符合業務思維過程和詞匯，用戶能夠以各種形式切割和分析數據，同時能夠快速的將查詢結果反饋。

DW/BI系統必須以一致性的形式展現信息（指標的唯一性）。也就是說數據必須是可信的，同一指標定義在不同的數據源中，所含的意義必須相同，既同名同意性。

DW/BI系統能夠適應變化（模塊的低耦合）。當用戶需求、業務維度需要調整的調整的時候，設計的DW模型必須能夠兼容這些變化，已經存在數據和指標不應該被破壞或修改，就算一些指標的調整，也要以適當的方式描述變化，并對用戶完全透明。

DW/BI系統必須保證數據安全（數據安全）。能展示的數據必須是統計的結果數據，一些詳單展現和下載必須和平臺的權限系統掛鉤，避免數據泄漏。

DW/BI系統成功的標示是業務群體接收并使用，而且必須配套一個展現模塊的監控系統，能夠讓產品方知道各個模塊的使用情況，對一些訪問量比較少的模塊可以適當的調整和優化。

二、數據倉庫介紹?

1. 定義

數據倉庫，由數據倉庫之父Bill Inmon 在1991 年出版的“Building the Data Warehouse”定義且被廣泛接受的——面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用于支持管理決策。從定義上來看，數據倉庫的關鍵詞為面向主題、集成、穩定、反映歷史變化、支持管理決策，而這些關鍵詞的實現就體現在分層架構內。

說到數倉不可避免的和傳統的數據庫進行比對：

所以數倉是面向分析型的，主要集中在數據的ETL、數倉模型的建立、數據治理、數據質量的監控、數據資產的沉淀、數據指標體系的搭建，為了方便快速的達到數據獲取和數據支撐的目的，同時規避了數據指標不統一造成的數據準確性不足的問題以及重復建設的冗余而建立的一套公司層面或者業務支撐層面的一套規范化數據流向的方案。

2. 目的

數倉的核心是解決 ETL 任務及工作流的組織、數據的流向、讀寫權限的控制、不同需求的滿足等各類問題，并提供給分析人員一個清晰可用的展現層，方便快速的業務支撐。

3. 特征

1. 集成（面向主題）

數據是分散的，由于事務處理應用分散、蜘蛛網問題、數據不一致問題、外部數據和非結構化數據。數據倉庫中的數據是為分析服務的，而分析需要多種廣泛的不同數據源以便進行比較、鑒別，因此數據倉庫中的數據必須從多個數據源中獲取，這些數據源包括多種類型數據庫以及文件系統等，它們通過數據集成而形成數據倉庫中的數據。

這塊的集成主要集中在數據源大量的數據預處理工作（ETL），通常的模型方式是通過E-R模型進行數據整合。目的將各個系統中的數據以整個企業角度按主題進行相似性組合和合并，并進行一致性處理，為數據分析決策服務，但是并不能直接用于分析決策。

特點：

一般是公司總棧層面的整合，所以需要全面了解企業業務和數據；實施周期非常長，需要整合全部的數據，并在企業業務角度對數據進行相似性組合和合并，并進行一致性處理；對建模人員的能力要求非常高；

2. 相對穩定（非易失）

數據倉庫中的數據是經過抽取而形成的分析型數據，不具有原始性，主要供企業決策分析之用，執行的主要是‘查詢’操作，一般情況下不執行‘更新’操作。同時，一個穩定的數據環境也有利于數據分析操作和決策的制訂。

但這也不等于數據倉庫中的數據不需要‘更新’操作。一般來說會建立數倉模型一些數據的生命周期管理，依據數倉數據的重要程度、數據調用情況等等指標，對已有的數據進行規范化管理。

3. 反映歷史變化（全量或者增量變更）

數據倉庫中的數據必須以一定時間段為單位進行統一更新，因為數倉數據是支撐公司層面業務數據從開始到發展過程中的所有數據變化，所以需要進行數據全量存儲，并記錄歷史變化的過程，方便業務數據能夠溯源。

合并全量數據的方式有三種，分別為全量更新、增量變更及增量流水。

全量更新，數據抽取時把源系統表的數據全量抽取過來，這個一般是每天建立一個時間分區，保留全量的數據，不過缺點很明顯就是太占存儲空間。

增量變更及增量流水，數據抽取時把源系統表內變化的數據抽取過來。兩者區別是，增量變更的數據除了包含新增數據外，還包含對歷史數據有變更的數據，而增量流水的數據只包含新增數據。

增量流水的數據處理方法相對簡單，直接把增量數據入庫到表內即可。增量變更的數據一般采用拉鏈模型來處理，這樣既保證可以查詢到任意時刻的歷史全量快照，也可以減少數倉的存儲空間。

然而，拉鏈模型有兩個明顯的缺陷，一個是當發現拉鏈表內某一扣環的數據異常時，拉鏈表應如何恢復準確性與完整性，另一個是隨著數據不斷增加，拉鏈表會越來越大，每日拉鏈操作的效率會越來越低。

所以在拉鏈和全量更新的時候，是根據業務表的具體情況來進行選擇的。一般來說，數據量很大，但是每天更新的占的比重很少，才會選擇拉鏈的模式。

數倉建設解決的痛點：

使用門檻高：數據工作是一個專業性特別強的一個工作，對于人員的要求比較高。在一些數據的工作當中需要人員有專業的數據基礎能力，這樣就導致了數據人力的缺失，可能會影響業務的數據支持力度；

口徑不一致：在使用數據過程當中，口徑不一致是特別常見的一種問題，這種問題可能會導致一種數據使用和分析的差異，而且會降低業務的數據分析效率，最終對業務決策造成嚴重影響；

數據可靠性低：在生產過程中，降低業務的數據分析效率，最終會對業務決策造成嚴重的影響，不僅數據鏈路過程很長，其中還會引入很多數據質量問題。并且，由于環節過多，也帶來了生產時間延遲的問題，可能直接影響到后續核心報表，推薦、模型的優化；

跨業務難度大：因為缺少一個統一的數據建設的規劃、標準和規范，所以難以指導各個業務或者整個生產鏈路的各個環節，以擁有一個標準化的生產和處理過程，就導致了多個業務的數據難以融合，難以發揮更大的數據價值；

接入成本高：這主要應用在一個新的業務場景下，也就是說，如果有新的業務接入或者新的場景需要使用數據，很多工作都需要人工處理。去申請各種資源、權限、找數據并且串聯整個數據的采集、生產、計算、同步和展示等各個環節，這是一個耗時長、效率低，最終還是很容易出錯的過程；

獲取數據難：可能在大家日常工作中會發現，我們數據的生產到最終使用，中間可能要經歷一個比較長的時間周期或者一個比較寬的團隊跨度，用戶可能無法很快地找到想要的數據，或者數據團隊生產出來的數據并沒有真正觸達到業務，來達到它的數據價值；

數據資產模糊：這個點可能和獲取數據難有一點點關聯，數據資產模糊的話更多的是在說我們需要對公司的數據資產做一個整體的管理，如果沒有這個整體的管理，就會導致對數據資產的級別和我們自己擁有什么數據資產都很模糊。最終就是導致數據的優勢難以發揮出來，而且雖然我們耗費了很多計算資源、人力資源、存儲資源，但沒有帶來相應的價值，最終導致資源效率極低。

針對上面的痛點，一般來說先是能夠達到快速的業務支撐的目的，在期間不可避免的出現重復建設和數據指標不統一的問題，在業務發展到一定程度再去補充數據治理的能力和數據指標監控能力能力。

治理工作的內容主要包括對數據和任務進行日常審計，然后通過數據血緣和使用情況，對數據的冗余度進行有效評估，并進行相應的優化，以減少資源和人力的浪費。

同時在生產過程中，如果出現生產不穩定的情況，我們也可以快速地發現問題，進而優化整個的生產鏈路，提高整個數據生態的健康度。

不過有一點，在數倉模型建設過程中，需要先規范好一些維度：

數據表創建的約束性：比如我們需要對表有的命名規范要求，如果沒有一個工具去管理，可能會因為大家對規范的理解不一致，最終導致落地過程中依然存在各種各樣的差異性；

數據信息的可描述性：指在創建表的過程中，為了快速地滿足業務，很少去添加一些相關的描述信息，導致數據缺少描述性。所以需要要求用戶在數據創建的過程中把信息描述的足夠精細，方便后續的數據使用過程；

數據建模體系的完整性：指在數據開發過程中，要有整體的業務考慮，落地一些通用性的維表，避免用戶為了快速地滿足業務需求跳過某些過程，最終導致建模的擴展性較差；

4、數據關系的維度與指標管理的系統性：數據的血緣關系、數據指標建立的標準、對外輸出統一的指標和維度，促使我們后續數據表和字段的相互關系是有記錄可查詢的，而且數倉的指標是唯一和準確的。

當然上面針對具體的公司，數倉這塊的側重點可能不一樣，需要做的工作也不盡相同。目前我們公司的架構如圖：

三、維度建模介紹 1. DW/BI架構：

源事務：業務庫或者日志等各個方面的數據源，一般不維護歷史信息。

ETL：目的是構建和加載數據到展現區的目標維度模型中，劃分維度和事實。

模型：圍繞業務過程度量事件進行構建，為滿足用戶無法預估的需求，必須包含詳細的原子數據。

為避免數據的冗余存儲造成的浪費和低效，并方便多業務部門查詢方便以及同一指標的數據準確性和業務的擴展性，一般采取以下的架構模式：

2. 維度建模

用于度量的事實表，事實表一般會有兩個或者多個外健與維度表的主鍵進行關聯。事實表的主鍵一般是組合健，表達多對多的關系。

用于描述環境的維度表，單一主鍵。維度表的屬性是所有查詢約束和報表標示的來源。維度提供數據的入口點，提供所有DW/BI分析的最終標識和分組。

所以維度建模表示每個業務過程包含的事實表，事實表里面存儲事件的數值化度量，圍繞事實表的是多個維度表，維度表包含事件發生的實際存在的文本環境。

從圖表中能看出來，維度模型（星型模型）比較簡單，而且適于變化，各個維度的地位相同?？筛鶕I務情況進行新增或者修改（只要維度的單一值已經存在事實表中）。

雪花模型：

維度建模主要是4個主要決策：

選擇業務過程

業務過程是通常表示的是業務執行的活動，與之相關的維度描述和每個業務過程事件關聯的描述性環境。

通常由某個操作型系統支持，例如：訂單系統。

業務過程建立或獲取關鍵性能度量。

一系列過程產生一系列事實表。

聲明粒度

粒度傳遞的是與事實表度量有關的細節級別。

精確定義某個事實表的每一行表示什么。

對事實表的粒度要達成共識。

確認維度

健壯的維度集合來粉飾事實表。

維度表示承擔每個度量環境中所有可能的單值描述符。

確認事實

不同粒度的事實必須放在不同的事實表中。

事實表的設計完全依賴物理活動，不受最終報表的影響。

事實表通過外健關聯與之相關的維度。

查詢操作主要是基于事實表開展計算和聚合。

其中粒度是非常重要的，粒度用于確定事實表的行表示什么，建議從關注原子級別的粒度數據開始設計，因為原子粒度能夠承受無法預估的用戶查詢，而且原子數據可以以各種可能的方式進行上卷，而一旦選擇了高粒度，則無法滿足用戶下鉆細節的需求。

事實是整個維度建模的核心，其中雪花模型或者星型模型都是基于一張事實表通過外健關聯維表進行擴展，生成一份能夠支撐可預知查詢需求的模型寬表，而且最后的查詢也是落在事實表中進行。

目前常見的維度模型：

星型模型

每一個維表都與都與事實表相關聯。數據冗余量較大

雪花模型

有些維表可能不與事實表直接關聯，而是通過其他維表關聯到事實表。數據冗余量較小

星座模型

由多個事實表相組合，維表是公共的。企業中一般都是星座模型

注意：

維度表的唯一主鍵應該是代理健而不是來自系統的標示符，也就是所謂的自然健，因為自然鍵通常具有一定的業務含義，但日久天長，這些信息是有可能發生變化的，而代理健可以提高關聯效率并將關系數據庫設計和業務的解耦。

維度表和事實表關聯的每個連接應該基于無含義的整數代理健。

固定深度層次在維度表中應該扁平化，規范化的雪花模型不利于多屬性瀏覽，而且大量的表和連接操作會影響性能。

非完全獨立的維度應該合并為一個維度，將同一層次的元素標示為事實表中不同維度是錯誤的，會增加查詢和存儲負擔，最后變成蜈蚣表，例如：日維度、周維度、月維度等可以合并為一個周期維度。

四、維度建模案例

維度建模是一個迭代設計過程，設計工作從總線矩陣中抽取實體級別的初始圖形化模型開始，詳細建模過程要深入定義、資源、關系、數據質量問題以及每張表的數據轉換，主要目標是建立滿足用戶需求的模型，校驗可加載到模型中的數據，為ETL提供明確的方向。

1. 雪花模型案例

這是一個以客戶創建為事實表的售前流程的雪花模型。

事實表：客戶創建信息表

維度表：銷售信息表、店鋪信息表、跟進表/約見表/風控通過表/訂單表的維度上卷。

以上面的維度模型可以聚合出創建、跟進、風控等各個維度的上層展現的數據。

2. 擴展：實時即未來

目前不少公司都在嘗試以Flink、Kudu為基礎的實時數倉架構，里面的數倉分層模型和離線的數倉架構基本相同。

下圖為實時數倉架構，離線和實時的差不多，具體實時的架構圖見：

ODS原始層是存放原始數據，主要是埋點數據（日志數據）和業務操作數據（binlong），數據源主要是Mysql、HDFS、Kafka等

DW中間層主要存放ETL和主題匯總之后的中間層數據，這塊又分為：

DWD：事實表（data warehouse detail） 數據倉庫明細表，以業務過程作為建模驅動，基于每個具體的業務過程特點，構建最細粒度的明細層事實表。

DWS：事實表 （data warehouse summary） 數據倉庫輕度匯總層，按照各個業務域進行輕度匯總成分析某一個主題域的服務數據，一般是寬表。

DIM：維度表，公共維度層，基于維度建模理念思想，建立整個業務過程的一致性維度，主要使用 MySQL、Hbase、Redis 三種存儲引擎，對于維表數據比較少的情況可以使用 MySQL，對于單條數據大小比較小，查詢 QPS 比較高的情況，可以使用 Redis 存儲，降低機器內存資源占用，對于數據量比較大，對維表數據變化不是特別敏感的場景，可以使用HBase 存儲。

DM數據集市層，以數據域+業務域的理念建設公共匯總層，對于DM層比較復雜，需要綜合考慮對于數據落地的要求以及具體的查詢引擎來選擇不同的存儲方式，分為輕度匯總層和高度匯總層。

輕度匯總層以寬表的形式存在，主要是針對業務域進行快速方便的查詢；

高度匯總層由明細數據層或輕度匯總層通過聚合計算后寫入到存儲引擎中，產出一部分實時數據指標需求，靈活性比較差，主要做大屏展現。

理論上上面還一APP層，應用層，主要是通過這幾層之后，生成輕度或者高度匯總的數據，然后根據業務域進行接口封裝提供給上層使用。但是實時數倉面臨以下幾個實施關鍵點：

端到端數據延遲、數據流量的監控；

故障的快速恢復能力；

數據的回溯處理，系統支持消費指定時間段內的數據；

實時數據從實時數倉中查詢，T+1數據借助離線通道修正；

業務數據質量的實時監控；

思考：

實時數倉架構和數據中臺一樣，雖然都是屬于當前比較熱門的概念，但是對于實時數倉的狂熱追求大可不必。

首先，在技術上幾乎沒有難點，基于強大的開源中間件（例如：Flink、kudu等）實現實時數據倉庫的需求已經變得沒有那么困難。

其次，實時數倉的建設一定是伴隨著業務的發展而發展，武斷的認為實時數倉架構最符合當前公司的需求是不對的。實際情況中隨著業務的發展數倉的架構變得沒有那么非此即彼。

最后，如何順暢的將傳統的離線數倉+實時鏈路處理流程升級到實時數倉架構是個很大的問題，畢竟中間涉及到很多的數據模式、技術中間件、計算引擎都不太一樣。

常見的數倉命名規則：前綴（ODS/DWD/MID）+主題域（user/shp）+業務類型+自定義表名+后綴（dd/ds/pi）

五、數倉分層

數據倉庫分層沒有絕對的規范，適合的就是最好的，特別是企業已經有一個初版的數倉的時候，需要做好改造成本和可理解性之間的平衡。

數據倉庫是一套方法論，從規范定義、模型設計到數據服務，再到數據可管理、可追溯、可復用。

很多人都關注數倉分層的具體分法和邏輯，而且目前市場上主流的分層方式眼花繚亂，不過看事情不能只看表面，還要看到內在的規律，不能因為分層而分層。

分層的目的解決當前業務快速的數據支撐目的，為未來抽象出共性的框架并能夠賦能給其他業務線，同時為業務發展提供穩定、準確的數據支撐，并能夠按照已有的模型為新業務發展提供方向，也就是數據驅動和賦能。

好分層架構，有以下好處：

清晰數據結構：每一個數據分層都有對應的作用域，在使用數據的時候能更方便的定位和理解。

數據血緣追蹤：提供給業務人員或下游系統的數據服務時都是目標數據，目標數據的數據來源一般都來自于多張表數據。若出現目標數據異常時，清晰的血緣關系可以快速定位問題所在。而且，血緣管理也是元數據管理重要的一部分。

減少重復開發：數據的逐層加工原則，下層包含了上層數據加工所需要的全量數據，這樣的加工方式避免了每個數據開發人員都重新從源系統抽取數據進行加工。

數據關系條理化：源系統間存在復雜的數據關系，比如客戶信息同時存在于核心系統、信貸系統、理財系統、資金系統，取數時該如何決策呢？數據倉庫會對相同主題的數據進行統一建模，把復雜的數據關系梳理成條理清晰的數據模型，使用時就可避免上述問題了。

屏蔽原始數據的影響：數據的逐層加工原則，上層的數據都由下一層的數據加工獲取，不允許跳級取數。而原始數據位于數倉的最底層，離應用層數據還有多層的數據加工，所以加工應用層數據的過程中就會把原始數據的變更消除掉，保持應用層的穩定性。

一般來說數倉分層有以下幾個共性：

源系統數據歸集到數倉的緩沖層，或稱為貼源層（ODS）；

主要收集來自各業務線或行業內的外部數據并對數據進行匯總，ODS層不承擔任何的數據清洗和治理的工作，在數據上和業務系統保持一致，ODS層采用分區表的形式按批次存儲據,ODS層保留了業務系統的原始數據，不對外開放查詢。

ODS層主要以全量方式同步數據，保留全量數據恢復的能力，同步的數據為T+1的新增和變更記錄，永久保存歷史數據。

數據倉庫層，具備數據標準化及合并全量數據的標準層，其中數倉建模主要集中在這一層（DW）。

具備主題劃分及明細數據整合的主題層（DM）。

具備提供數據服務給下游系統使用的集市層，或稱為應用層（APP）；

當然這個分層可以進一步拆分，其中最主要的是DW層的模型建立：

其實相對來說數倉模型的建設并不復雜，只要關注以下幾點就行：

OneData：數倉所有數據只加工一次，對應到數倉的設計層面，要求有統一的維度，對于明細層數據，相同粒度的度量只加工一次，對于匯總層的數據，相同粒度的指標只存在一份。避免重復建設的問題；

OneIndex：數倉指標體系都具有唯一性，通過原子指標+派生指標來規范所有的指標系統，避免數據不一致性的問題；

OneService：數據服務劃清了數據和應用的邊界，數據服務提供的是加工好的指標數據，應用通過數據服務，直接獲取計算的結果，強制把公共計算邏輯下沉到數據層面，提高了數據的共享能力，避免通過不同層次獲取數據導致的數據準確性和安全性的問題；

OneLine：最大程度上保障數據流轉的透明性，不同層級做不同層級的數據處理邏輯，不可逆向依賴，方便后續數據血緣關系、數據地圖的建立，避免數據雜亂，無法溯源；

OneEntity：這塊主要是模型方面的建設，同一個用戶，在同一個模型中，可能存在重復的記錄，如何識別兩個 ID 是同一個用戶，做到所有用戶只有唯一的 ID 標識，這個是 OneEntity 要解決的問題，其實歸根結底就是ID-Mapping問題。

六、問題?

1. 維度建模的缺點

維度建模之前需要進行大量的數據預處理，因此會導致大量的數據處理工作（ETL）。

當業務發生變化，需要重新進行維度的定義時，往往需要重新進行維度數據的預處理。而在這些與處理過程中，往往會導致大量的數據冗余。

如果只是依靠單純的維度建模，不能保證數據來源的一致性和準確性，而且在數據倉庫的底層，不是特別適用于維度建模的方法。

維度建模的領域主要適用與數據集市層，它的最大的作用其實是為了解決數據倉庫建模中的性能問題。維度建模很難能夠提供一個完整地描述真實業務實體之間的復雜關系的抽象方法。

當前公司的數倉模型架構：

首先對ETL得到的數據進行ER建模，關系建模，得到一個規范化的公司層面的數據倉庫模式。然后用這個中心倉數據庫為公司各部門建立基于維度建模的數據集市。

而維度建模都集中在各個DM層里面，也就是針對具體的業務線或者主題域，這樣緊緊圍繞著業務模型，可以直觀的反映出業務模型中的業務問題。

2. 分層的誤區

數倉層內部的劃分不是為了分層而分層，分層是為了解決 ETL 任務及工作流的組織、數據的流向、讀寫權限的控制、不同需求的滿足等各類問題。

業界較為通行的做法將整個數倉層又劃分成了 dwd、dwb、dws、dim、mid 等等很多層。然而我們卻始終說不清楚這幾層之間清晰的界限是什么，或者說我們能說清楚它們之間的界限，復雜的業務場景卻令我們無法真正落地執行。

所以數據分層這塊一般來說三層是最基礎的：

至于DW層如何進行切分，是根據具體的業務需求和公司場景自己去定義，一般來說需要：

分層是解決數據流向和快速支撐業務的目的；

必須按照主題域和業務域進行貫穿；

層級之間不可逆向依賴。

如果依賴ODS層數據可以完成數據支撐，那么業務方直接使用落地層這也有利于快速、低成本地進行一些數據方面的探索和嘗試。

確定分層規范后，后續最好都遵循這個架構，約定成俗即可；

血緣關系、數據依賴、數據字典、數據命名規范等配套先行；

DW 內的分層沒有最正確的，只有最適合你的。

3. 寬表的誤區

在數倉層開始引入了寬表。所謂寬表，迄今為止并沒有一個明確的定義。通常做法是把很多的維度、事實上卷或者下鉆之后關聯到某一個事實表中，形成一張既包含了大量維度又包含了相關事實的表。

寬表的使用，有其一定的便利性。使用方不需要再去考慮跟維度表的關聯，也不需要了解維度表和事實表是什么東西。

但是隨著業務的增長，我們始終無法預見性地設計和定義寬表究竟該冗余多少維度，也無法清晰地定義出寬表冗余維度的底線在哪里。

一個可能存在的情況是，為了滿足使用上的需求，要不斷地將維表中已經存在的列增加到寬表中。這直接導致了寬表的表結構頻繁發生變動。

目前我們所采用的做法是：

根據主題域和業務域，將某個業務的所有節點梳理清楚；

將關鍵節點的數據作為事實表依據，然后橫向擴充其他事實表上卷數據（包含一些統計指標），同時縱向的添加該節點上一些主鍵對應的維度；

寬表的涉及不依賴具體的業務需求而是根據整體業務線相匹配；

盡量用維度建模代替寬表；

為什么說盡量用維度建模代替寬表，就算字段和數據會冗余，維度建模的方式也會表全量數據的寬表模式較好，原因：

維度建模是以某一個既定的事實為依據，既然是事實表，那么這塊的業務如果不變動的情況下，事實表的粒度基本不會改變；

事實表和維度表解耦，維度表的變更事實表基本不會影響，結果表也只需要回刷一下數據流程即可；

新增維度完全可以按照星型模型或者雪花模型動態添加新維度；

維度模型可以作為寬表的基礎，一旦確定全部的數據流程，可以通過維度模型再生成對應寬表進行快速的業務支撐；

4. 指標管理

數倉模型中，最重要的模塊可能就是數據治理，我們在建立數倉分層的時候，雖然解決 ETL 任務及工作流的組織、數據的流向、讀寫權限的控制、不同需求的滿足等各類問題，但是在給業務方提供不同數據需求的情況下不可避免的會發生一下幾個問題：

指標定義不夠清晰明確，兩個頁面上的指標定義其實是不同的，但是展示給商家看到的可能是同一個中文名稱。又或者同樣一個含義的指標在不同的界面上展示的名稱卻不相同，讓人產生歧義。

同一個指標因為由不同的數據開發同學來制作，可能會被重復開發，不但造成資源浪費，還會造成維護困難。

對于需要新開發的指標，不僅缺少開發工具簡化開發流程，甚至該使用哪些表，不該使用哪些表很大程度上都要憑借數據開發同學與數倉同學的經驗。如果稍微馬虎一點或者缺乏經驗，比如使用了某些業務域下特有的表或者不是由數倉提供的統一中間層的表就可能會使用錯誤的數據，造成后期返工等情況。

而且在數據需求越來越多，數據中臺提供的指標也日益豐富。但是指標定義混亂，描述不清會嚴重影響數據的可信度和數據開發的成本，所以就需要搭建一個指標系統，來維護已有的數據指標，并為未來可能新增的指標建立相應的規范。

如何去建立好這個指標庫或者指標系統呢。

一般來說指標系統主要分為：原子指標和派生指標

在數倉分層的時候，進行維度建模，那么就必須指定好相應的主題域和事實表處理的最小邏輯（也就是事實），那么在這個基礎上可以先定義原子指標。

原子指標：原子指標和度量含義相同，基于某一業務事件行為下的度量，是業務定義中不可再拆分的指標，具有明確業務含義的名詞 ，如支付金額。原子指標描述的其實是一種指標的類型，比如訂單支付金額，支付訂單數，下單訂單數，PV，UV 等等。但是僅僅一個原子指標是不能直接取數的。

但業務方更關心的指標，是有實際業務含義，可以直接取數據的指標。比如店鋪近1天訂單支付金額就是一個派生指標，會被直接在產品上展示給商家看。這個指標卻不能直接從數倉的統一中間層里取數（因為沒有現成的事實字段，數倉提供的一般都是大寬表）。需要有一個橋梁連接數倉中間層和業務方的指標需求，于是便有了派生指標。

派生指標=維度+原子指標+修飾詞。當維度，原子指標，修飾詞都確定的時候就可以唯一確定一個派生指標，同時給出具體數值。

例如：店鋪近1天訂單支付金額中店鋪是維度，近1天是一個時間類型的修飾詞，支付金額是一個原子指標。

業務方制作每一個派生指標都是通過選擇維度，原子指標，修飾詞三種元數據來定義的，相對于使用名稱來區別不同指標，更可以保證指標的唯一性。如果2個派生指標是不同的，那他們的組成部分一定會有區別，或是不同維度，或是不同原子指標，修飾詞。

所以在指標管理的過程中，指標庫給予每個指標一個精確且唯一的定義。通過指標庫可以快速且規范的查詢，開發和使用指標。

指標庫主要提供如下服務：

通過設置指標的組成要素來唯一精確定義每個指標（派生指標）。

通過指標在業務域內唯一的性質，解決指標重復定義，重復開發，部分數據對不上的問題。

通過將數倉中間層錄入指標庫為新制作指標提供指導性的 SQL 或庫表推薦。

打通其他各數據平臺：

打通數據開發平臺和統一數據服務平臺，為指標的定義，調度，在線使用提供一條龍服務，簡化開發流程。

打通數據資產管理平臺，沉淀指標的資產價值。

打通 BI 平臺，提供拖拽維度，指標生成報表的功能。

其中派生指標的生成是通過：業務域+維度+原子指標+修飾詞來唯一確定的。

在數倉搭建的時候，業務域、維度、原子指標都是已經明確的，而修飾詞是維度的某一些特殊的值，對應 SQL 中的 where 過濾條件。所以如果在數據產品的層面在某個業務域對指標數據定義、生產、使用等過程的流程規范化與平臺化，那么就能夠從源頭上解決上面出現的數據指標不統一、重復開發、指標體系不好維護的問題。