這篇文章較為完整、清晰的講述了數倉建模分層理論，要點如下：
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 是面向單個主題的，所以它不會從全局考慮進行建設，只專註於自己的數據、往往是某個業務線，例如流量主題、社交主題、電商主題等等。