為什麼數據倉庫要分層

A. 數倉建模分層理論

這篇文章較為完整、清晰的講述了數倉建模分層理論，要點如下：

1、分層的意義：清晰結構體系、數據血緣跟蹤、減少重復開發、復雜問題簡單化及統一數據口徑

2、ODS：用作緩沖，可以存一周左右，跟DWD大多重復，留存的目的還在於保持跟源端一致，方便追溯

3、DWD：針對ODS做數據的清洗和整合，在DWD層會根據維度模型，設計事實表和維度表，DWD層是一個非常規范的、高質量的、可信的數據明細層

4、DWS：基於DWD層形成某一主題的輕度匯總表或分析寬表，DWS形成大量維度退化的事實表以提高易用性，DWS層應覆蓋80%的應用場景

5、TDM：標簽層，通過統一的ID-Mapping 把各個業務板塊，各個業務過程中同一對象的數據打通，形成對象的全域數據標簽體系，方便深度分析、挖掘、應用，大家注意，這個ID不僅僅指客戶或用戶ID，也包括其它的主數據ID，其是全流程分析的基礎

6、ADS：數據應用層ApplicationDataService面向業務定製的應用數據，主要提供給數據產品和數據分析使用的數據，一般會放在ES，MYSQL，Redis等前端系統供線上系統使用，也可以放在Hive中供數據分析和數據挖掘使用

7、DM：主要是提供數據產品和數據分析的數據，主要解決部門用戶報表和分析需求而建立資料庫，數據集市就代表數據倉庫的主題域。DM 是面向單個主題的，所以它不會從全局考慮進行建設。

強烈推薦閱讀！

正文開始

簡單點兒，直接ODS+DM就可以了，將所有數據同步過來，然後直接開發些應用層的報表，這是最簡單的了；當DM層的內容多了以後，想要重用，就會再拆分一個公共層出來，變成3層架構,這個過程有點類似代碼重構，就是在實踐中不斷的進行抽象、總結。

數倉的建模或者分層，其實都是為了更好的去組織、管理、維護數據,所以當你站在更高的維度去看的話，所有的劃分都是為了更好的管理。小到JVM 內存區域的劃分，JVM 中堆空間的劃分(年輕代、老年代、方法區等)，大到國家的省市區的劃分，無一例外的都是為了更好的組織管理 。

所以數倉分層是數據倉庫設計中十分重要的一個環節， 優秀的分層設計能夠讓整個數據體系更容易理解和使用 。

這一節，我們主要是從整體上出發進行分析和介紹，就和上一節數倉建模方法論一樣，進度對比分析，更多細節的東西我們後面會單獨拆分出來，用案例進行演示，例如維度建模，維度表的設計，事實表的設計、以及如何設計標簽、如何管理標簽等等。

每一個數據分層都有它的作用域，這樣在使用表的時候能更方便的定位和理解。

由於最終給業務呈現的是一個能直接使用的業務表，但是表的數據來源有很多，如果有一張來源表出問題了，我們希望能夠 快速准確的定位到問題，並清楚它的影響范圍，從而及時給到業務方反饋，從而將損失降到最低 。

將一個復雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維護數據的准確性，當數據出現問題之後，可以不用修復所有的數據，只需要從有問題的步驟開始修復。

過數據分層提供統一的數據出口，統一對外輸出的數據口徑，這往往就是我們說的數據應用層。

前面我們說到分層其實是為了更好更快更準的組織管理，但是這個是從宏觀上來說的，接下來我們從微觀上也來看一下分層。

越靠上的層次，對應用越友好,比如ADS層，基本是完全為應用設計,從數據聚合程度來講，越上層的聚合程度越高，當然聚合程度越高可理解程度就越低。

數倉層內部的劃分不是為了分層而分層， 分層是為了解決 ETL 任務及工作流的組織、數據的流向、讀寫許可權的控制、不同需求的滿足等各類問題 ，當然我們常說的分層也是面向行業而言的，也是我們常用分層方法，但是你需要注意的是分層僅僅是手段而已。

ODS 全稱是 OperationalDataStore， 操作數據層存儲的是面向業務系統的數據 ，也是最接近數據源中數據的一層，數據源中的數據，經過抽取、洗凈、傳輸，也就說傳說中的 ETL 之後，裝入本層。

本層的數據，總體上大多是 按照源頭業務系統的分類方式而分類的 ，前面我們說到為什麼在數倉主要用維度建模的情況下，我們依然要學習範式建模呢，因為我們的數據源是範式建模的，所以學習範式建模可以幫助我們更好的理解業務系統，理解業務數據，所以你可以認為我們的ODS 層其實就是用的實範式建模。

這里的數據處理，並不涉及業務邏輯，僅僅是針對數據完整性以及重復值和空值的處理，其實就是做的是數據規約，數據清洗，但是為了考慮後續可能追溯數據源問題，因此 對這一層不建議做過多的數據清洗工作 ，原封不動接入源數據即可，至於數據的去噪，去重，異常值處理等過程可以放在後面的DW層

表名的設計 ODS_業務系統_表名_標記 ，這樣的設計可以保持與業務表名一致，又可以有清晰的層次，還可以區分來源。標記一般指的是其他數倉特有的屬性，例如表是天級的還是小時的，是全量的還是增量的。

ods 的設計可以保證所有的數據按照統一的規范進行存儲。

DW是數據倉庫的核心，從ODS層中獲得的數據按照主題建立各種數據模型。DW又細分數據明細層DWD 和輕度匯總層DWS

這一層和維度建模會有比較深的聯系，業務數據是按照 業務流程方便操作的角度 來組織數據的，而統一數倉層是 按照業務易理解的角度或者是業務分析的角度 進行數據組織的，定義了一致的指標、維度，各業務板塊、數據域都是按照統一的規范來建設，從而形成統一規范的 標准業務數據體系 ，它們通常都是基於Kimball的維度建模理論來構建的， 並通過一致性維度和數據匯流排來保證各個子主題的維度一致性 。

公共層的維度表中相同維度屬性在不同物理表中的欄位名稱、數據類型、數據內容必須保持一致，因為這樣可以降低我們在使用過程中犯錯誤的概率，例如使用了不正確的欄位，或者因為數據類型的原因導致了一些奇怪的錯誤

將維度所描述業務相關性強的欄位在一個物理維表實現。相關性強是指經常需要一起查詢或進行報表展現、兩個維度屬性間是否存在天然的關系等。例如，商品基本屬性和所屬品牌。

公告明細數據層，可以說是我們數倉建設的核心了。

DWD層要做的就是將 數據清理、整合、規范化、臟數據、垃圾數據、規范不一致的、狀態定義不一致的、命名不規范的數據都會被處理 。然後加工成面向數倉的基礎明細表，這個時候可以加工一些面向分析的大寬表。

DWD層應該是覆蓋所有系統的、完整的、干凈的、具有一致性的數據層。在DWD層會根據維度模型，設計事實表和維度表，也就是說DWD層是一個非常規范的、高質量的、可信的數據明細層。

DWS層為 公共匯總層 ，這一層會進行輕度匯總，粒度比明細數據稍粗， 基於DWD層上的基礎數據，整合匯總成分析某一個主題域的服務數據 ，一般是也是面向分析寬表或者是面向某個注意的匯總表。DWS層應覆蓋80%的應用場景，這樣我們才能快速響應數據需求，否則的話，如果很多需求都要從ods開始做的話，那說明我們的數倉建設是不完善的。

例如按照業務劃分，例如流量，訂單，用戶等，生成欄位比較多的寬表，用於後續的業務查詢，OLAP分析，數據分析等。

一般採用維度模型方法作為理論基礎，更多的採用一些維度退化手法，將維度退化至事實表中，減少維度表與事實表的關聯，提高明細數據表的易用性；同時在匯總數據層要加強指標的維度退化，採用更多的寬表化手段構建公共指標數據層，提升公共指標的復用性，減少重復加工 。

維表層，所以其實維度層就是大量維表構成的，為了統一管理這些維度表，所以我們就建設維度層，維度表本身也有很多類型，例如穩定維度維表，漸變維度維表。

維度指的是觀察事物的角度，提供某一業務過程事件涉及用什麼過濾和分類的描述屬性 ，"誰、什麼時候、什麼地點、為什麼、如何"幹了什麼，維度表示維度建模的基礎和靈魂。

所以可以看出，維度表包含了業務過程記錄的業務過程度量的上下文和環境。維度表都包含單一的主鍵列， 維度表設計的核心是確定維度欄位，維度欄位是查詢約束條件(where)、分組條件(group)、排序(order)，與報表標簽的基本來源 。

維度表一般為 單一主鍵 ，在ER模型中，實體為客觀存在的事務，會帶有自己的描述性屬性，屬性一般為文本性、描述性的，這些描述被稱為維度。維度建模的核心是 數據可以抽象為事實和維度 ，維度即觀察事物的角度，事實某一粒度下的度量詞， 維度一定是針對實體而言的 。

每個維度表都 包含單一的主鍵列 。維度表的主鍵可以作為與之關聯的任何事實表的外鍵，當然，維度錶行的描述環境應與事實錶行完全對應。維度表通常比較寬，是扁平型非規范表，包含大量的低粒度的文本屬性。例如customer（客戶表）、goods(商品表)、d_time(時間表)這些都屬於維度表，這些表都有一個唯一的主鍵，然後在表中存放了詳細的數據信息。

維度表通常比較寬 ，包含多個屬性、是扁平的規范表 ，實際應用中包含幾十個或者上百個屬性的維度並不少見，所以 維度表應該包括一些有意義的描述，方便下游使用 。

維度表的維度屬性，應該盡可能的豐富，所以維度表中，經常出現一些反範式的設計，把其他維度屬性並到主維度屬性中， 達到易用少關聯的效果。

維度表的設計包括維度選擇，主維表的確定，梳理關聯維度，定義維度屬性的過程。

維度的選擇一般從報表需求和從業務人員的交談中發現，主要用於過濾、分組、排序，主維度表一般從業務庫直接同步，比如用戶表，但是數倉的本身也會有自己的維度，這是因為數倉是面向分析的，所以會有很多從分析的角度出發的維度。

關聯維度主要是不同業務系統或者同一業務系統的表之間存在關聯性(範式建模)，根據對業務表的梳理，確定哪些表和主維度表之間存在關聯關系，並選擇其中的某些表用於生成維度屬性。

隨著互聯網的普及，獲客成本越來越高，這也使得公司對用戶運營提出了更高的要求，不僅需要精細化更需要個性化。解決這一問題的辦法之一就是建立相對完備的標簽系統，而數倉的標簽層對於標簽系統而言就像數據倉庫對於數據系統一樣，有著舉足輕重的地位，這樣的標簽系統需要與業務進行緊密結合， 從業務中獲取養分—用戶標簽，同時也要服務於業務—給用戶提供更加精準和個性的服務 。

底層的標簽系統就像一個索引，層層展示大千世界，而用戶就從這大千世界中不斷選擇一些東西表明自己的身份和喜好，也不斷反哺，使得這個大千世界更加豐富多彩。 其實到最後用戶就是一些標簽的集合。

對跨業務板塊、跨數據域的特定對象進行數據整合，通過統一的ID-Mapping 把各個業務板塊，各個業務過程中 同一對象的數據打通 ，形成對象的全域數據標簽體系，方便深度分析、挖掘、應用。ID-Mapping 可以認為是通過對象的標識對不同數據體系下相同對象進行關聯和識別。對象的標識可以標識一個對象，一般是對象的ID,比如手機號，身份證，登錄賬號

完成對象的ID 打通需要給對象設置一個超級ID,需要根據對象當前業務體系的ID和獲取得到或者計算得到超級ID,進而完成所有業務標識的ID打通一般來說ID打通是建設標簽體系的前提，如果沒有ID打通就無法收集到一個對象的全面信息，也就無法對這個對象進行全面的標簽刻畫。

傳統的計算方法要有 ID-ID之間的兩兩關系，例如郵箱和手機號可以打通，手機號和身份證號可以打通，那麼郵箱就和身份證號可以打通，但是當數據量非常大，且業務板塊非常多的時候，例如有上一個對象，每個對象有數十種ID,這個時候打通就需要非常漫長的計算

那麼什麼是標簽呢，利用原始數據，通過一定的邏輯加工產出直接能被業務所直接使用的、可閱讀的，有價值的數據。標簽類目，是標簽的分類組織方式，是標簽信息的一種結構化描述，目的是管理、查找，一般採用多級類目，一般當一個對象的標簽個數超過50個的時候，業務人員查找標簽就會變得非常麻煩，這個時候我們往往會通過標簽類目進行組織管理

標簽按照產生和計算方式的不同可分為屬性標簽，統計標簽，演算法標簽，關聯標簽。

對象本身的性質就是屬性標簽，例如用戶畫像的時候打到用戶身上的標簽。

對象在業務過程中產生的原子指標，通過不同的計算方法可以生成統計標簽。

對象在多個業務過程中的特徵規律通過一定的演算法產出的標簽。

對象在特定的業務過程會和其他對象關聯，關聯對象的標簽也可以打在主對象上。

我們的標簽一定是針對用戶的，而不是一些虛假、高大上、無用的標簽，一定要真實反映用戶行為喜好的，所以我們不能只依賴人工智慧演算法的分析，來完成對一個用戶標簽的建立與定期維護，我們需要走出去和用戶交互，引導用戶使用，要抓住用戶痛點，及時獲取用戶反饋，形成閉環。

如何引導使用呢？這個方式有很多我們就不再這里介紹了，後面我們會專門介紹這一層的建設細節。

數據應用層ApplicationDataService面向業務定製的應用數據，主要提供給數據產品和數據分析使用的數據，一般會放在ES，MYSQL，Redis等系統供線上系統使用，也可以放在Hive中供數據分析和數據挖掘使用，或者使用一下其他的大數據工具進行存儲和使用。

數倉層，DIM 層，TDM 層是相對穩定的，所以無法滿足靈活多變業務需求 ，所以這和數倉層的規范和劃分相矛盾，所以我們在此基礎上建立了另外一個層，這就是ADS 層，解決了規劃穩定和靈活多變之間的矛盾。其實到這里你也就慢慢的看明白了，分層和分類其實沒多大差別，其實就是相似的放在一起，有點代碼重構的意味啊。

數據應用層，按照業務的需要，然後從統一數倉層和DIM進行取數，並面向業務的特殊需求對數據進行加工,以滿足業務和性能的需求。ADS 層因為面向的實眾多的需求，所以這一層沒有太多的規范，只需要按照命名規范來進行就可以了。

前面也說了，ADS 層因為面向的實眾多的需求，所以這一層沒有太多的規范，但是ADS 層的建設是強業務推動的，業務部門需要參與到ADS 的建設中來，至少我們得了解用戶的痛點才能對症施葯啊。

理清需求，了解業務方對數據內容、使用方式(怎麼交互的，報表、介面、即席查詢、在線查詢、指標查詢、搜索)、性能的要求。

盤點現有的數倉表是否可以支持，看以前有沒有類似的需求，有沒有可以復用的介面、報表什麼的。

代碼實現，選擇合適的存儲引擎和查詢引擎，配置線上監控然後交付。

主要是提供數據產品和數據分析的數據，一般會存放在ES、Mysql、也可能直接存儲在hive中或者druid供數據分析和數據挖掘使用。主要 解決部門用戶報表和分析需求 而建立資料庫，數據集市就代表數據倉庫的主題域。

DM 是面向單個主題的，所以它不會從全局考慮進行建設，只專注於自己的數據、往往是某個業務線，例如流量主題、社交主題、電商主題等等。

B. 各位大神，數據倉庫分層 DWD DWB DWS 分別是什麼縮寫啊

DW ：data warehouse 翻譯成數據倉庫

DW數據分層，由下到上為 DWD,DWB,DWS

DWD：data warehouse detail 細節數據層，有的也稱為 ODS層，是業務層與數據倉庫的隔離層。

DWB：data warehouse base 基礎數據層，存儲的是客觀數據，一般用作中間層，可以認為是大量指標的數據層。

DWS：data warehouse service 服務數據層，基於DWB上的基礎數據，整合匯總成分析某一個主題域的服務數據，一般是寬表。

(2)為什麼數據倉庫要分層擴展閱讀

數據倉庫分層的原因

1、通過數據預處理提高效率，因為預處理，所以會存在冗餘數據

2、如果不分層而業務系統的業務規則發生變化，就會影響整個數據清洗過程，工作量巨大

3、通過分層管理來實現分步完成工作，這樣每一層的處理邏輯就簡單了

標準的數據倉庫分層：ods（臨時存儲層），pdw（數據倉庫層），mid（數據集市層），app（應用層）

4、空間換時間。通過建設多層次的數據模型供用戶使用，避免用戶直接使用操作型數據，可以更高效的訪問數據。

5、把復雜問題簡單化。講一個復雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維護數據的准確性，當數據出現問題之後，可以不用修復所有的數據，只需要從有問題的步驟開始修復。

6、便於處理業務的變化。隨著業務的變化，只需要調整底層的數據，對應用層對業務的調整零感知

C. 什麼是數據倉庫，數據倉庫如何分層

數據倉庫分層的原因
1通過數據預處理提高效率，因為預處理，所以會存在冗餘數據
2如果不分層而業務系統的業務規則發生變化，就會影響整個數據清洗過程，工作量巨大
3通過分層管理來實現分步完成工作，這樣每一層的處理邏輯就簡單了

標準的數據倉庫分層：ods（臨時存儲層），pdw（數據倉庫層），mid（數據集市層），app（應用層）
ods：歷史存儲層，它和源系統數據是同構的，而且這一層數據粒度是最細的，這層的表分為兩種，一種是存儲當前需要載入的數據，一種是用於存儲處理完後的數據。
pdw：數據倉庫層，它的數據是干凈的數據，是一致的准確的，也就是清洗後的數據，它的數據一般都遵循資料庫第三範式，數據粒度和ods的粒度相同，它會保存bi系統中所有歷史數據
mid：數據集市層，它是面向主題組織數據的，通常是星狀和雪花狀數據，從數據粒度將，它是輕度匯總級別的數據，已經不存在明細的數據了，從廣度來說，它包含了所有業務數量。從分析角度講，大概就是近幾年
app：應用層，數據粒度高度匯總，倒不一定涵蓋所有業務數據，只是mid層數據的一個子集。

數據倉庫的目的是構建面向分析的集成化數據環境，為企業提供決策支持。數據倉庫的context也可以理解為：數據源，數據倉庫，數據應用

數據倉庫可以理解為中間集成化數據管理的一個平台
etl（抽取extra，轉化transfer，裝載load）是數據倉庫的流水線，也可以認為是數據倉庫的血液。
數據倉庫的存儲並不需要存儲所有原始數據，因為比如你存儲冗長的文本數據完全沒必要，但需要存儲細節數據，因為需求是多變的，而且數據倉庫是導入數據必須經過整理和轉換使它面向主題，因為前台資料庫的數據是基於oltp操作組織優化的，這些可能不適合做分析，面向主題的組織形式才有利於分析。
多維數據模型就是說可以多維度交叉查詢和細分，應用一般都是基於聯機分析處理（online analytical process OLAP），面向特定需求群體的數據集市會基於多位數據模型構建
而報表展示就是將聚合數據和多維分析數據展示到報表，提供簡單和直觀的數據。
元數據，也叫解釋性數據，或者數據字典，會記錄數據倉庫中模型的定義，各層級之間的映射關系，監控數據倉庫的數據狀態和etl的任務運行狀態。一般通過元數據資料庫來統一存儲和管理元數據。