分層建設理論
簡單點兒，直接ODS+DM就可以了，將所有資料同步過來，然後直接開發些應用層的報表，這是最簡單的了；當DM層的內容多了以後，想要重用，就會再拆分一個公共層出來，變成3層架構,這個過程有點類似程式碼重構，就是在實踐中不斷的進行抽象、總結。
數倉的建模或者分層，其實都是為了更好的去組織、管理、維護資料,所以當你站在更高的維度去看的話，所有的劃分都是為了更好的管理。小到JVM 記憶體區域的劃分，JVM 中堆空間的劃分(年輕代、老年代、方法區等)，大到國家的省市區的劃分，無一例外的都是為了更好的組織管理。
所以數倉分層是資料倉儲設計中十分重要的一個環節，優秀的分層設計能夠讓整個資料體系更容易理解和使用。
這一節，我們主要是從整體上出發進行分析和介紹，就和上一節數倉建模方法論一樣，進度對比分析，更多細節的東西我們後面會單獨拆分出來，用案例進行演示，例如維度建模，維度表的設計，事實表的設計、以及如何設計標籤、如何管理標籤等等。
分層的意義
清晰資料結構體系
每一個資料分層都有它的作用域，這樣在使用表的時候能更方便的定位和理解。
資料血緣追蹤
由於最終給業務呈現的是一個能直接使用的業務表，但是表的資料來源有很多，如果有一張來源表出問題了，我們希望能夠快速準確的定位到問題，並清楚它的影響範圍，從而及時給到業務方反饋，從而將損失降到最低。
減少重複開發和資源浪費
- 規範資料分層，開發一些通用的中間層資料，能夠減少極大的重複計算；
- 清晰明瞭的結構使得開發、維護的成本降低；
- 減少重複計算和儲存的資源浪費；
複雜問題簡單化
將一個複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維護資料的準確性，當資料出現問題之後，可以不用修復所有的資料，只需要從有問題的步驟開始修復。
在實際的建設過程中，由於業務使用資料非常緊急以及統一數倉層建設跟不上業務的需要，所以DIM和ADS層可能直接使用ODS層進行快速的業務響應，但是這種不規範的操作可能導致資料口徑不一致，所以待數倉建設完畢，要切換到統一數倉層和DIM層。
統一資料口徑
過資料分層提供統一的資料出口，統一對外輸出的資料口徑，這往往就是我們說的資料應用層。
關於分層的一點思考
前面我們說到分層其實是為了更好更快更準的組織管理，但是這個是從巨集觀上來說的，接下來我們從微觀上也來看一下分層。
越靠上的層次，對應用越友好,比如ADS層，基本是完全為應用設計,從資料聚合程度來講，越上層的聚合程度越高，當然聚合程度越高可理解程度就越低。
數倉層內部的劃分不是為了分層而分層，分層是為了解決 ETL 任務及工作流的組織、資料的流向、讀寫許可權的控制、不同需求的滿足等各類問題，當然我們常說的分層也是面向行業而言的，也是我們常用分層方法，但是你需要注意的是分層僅僅是手段而已。
數倉的分層
ods 運算元據層
ODS 全稱是 OperationalDataStore，運算元據層儲存的是面向業務系統的資料，也是最接近資料來源中資料的一層，資料來源中的資料，經過抽取、洗淨、傳輸，也就說傳說中的 ETL 之後，裝入本層。
其實這裡說ETL 有點不合適了，其實更準確的是ELT,你可以細細品品
本層的資料，總體上大多是按照源頭業務系統的分類方式而分類的，前面我們說到為什麼在數倉主要用維度建模的情況下，我們依然要學習正規化建模呢，因為我們的資料來源是正規化建模的，所以學習正規化建模可以幫助我們更好的理解業務系統，理解業務資料，所以你可以認為我們的ODS 層其實就是用的實正規化建模。
但是，這一層面的資料卻不等同於原始資料。在源資料裝入這一層時，要進行諸如去噪(例如有一條資料中人的年齡是300歲，這種屬於異常資料，就需要提前做一些處理)、去重(例如在個人資料表中，同一ID卻有兩條重複資料，在接入的時候需要做一步去重)、欄位命名規範等一系列操作。
這裡的資料處理，並不涉及業務邏輯，僅僅是針對資料完整性以及重複值和空值的處理，其實就是做的是資料規約，資料清洗，但是為了考慮後續可能追溯資料來源問題，因此對這一層不建議做過多的資料清洗工作，原封不動接入源資料即可，至於資料的去噪，去重，異常值處理等過程可以放在後面的DW層
其實關於這一層，很多人的理解不太一樣，那就是是否要進行資料清洗，其實還是取決於公司的使用習慣，其實有很多公司在這一層之前也會形成一個層，名字千奇百怪，但是它的目的是資料緩衝，然後進行清洗，清洗之後的資料存入ODS ,而這個時候緩衝層資料存放一般為一週左右，幾乎不會超過一個月；而ODS則永久存放。
設計原則
表名的設計 ODS_業務系統_表名_標記，這樣的設計可以保持與業務表名一致，又可以有清晰的層次，還可以區分來源。標記一般指的是其他數倉特有的屬性，例如表是天級的還是小時的，是全量的還是增量的。
- ods 層不做欄位名歸一和欄位型別統一的操作，如果需要則使用相容的資料型別
- 對於增量表，需要設計增量表(ODS_業務系統_表名_delta)和全量表,然後將增量表合併成全量表資料；
- 對於半結構化資料需要設計解析；
- 由於業務資料庫（OLTP）基本按照維度模型建模，因此ODS層中的建模方式也是維度模型；
ods 的設計可以保證所有的資料按照統一的規範進行儲存。
DW 統一數倉層
DW是資料倉儲的核心，從ODS層中獲得的資料按照主題建立各種資料模型。DW又細分資料明細層DWD 和輕度彙總層DWS
這一層和維度建模會有比較深的聯絡，業務資料是按照業務流程方便操作的角度來組織資料的，而統一數倉層是按照業務易理解的角度或者是業務分析的角度進行資料組織的，定義了一致的指標、維度，各業務板塊、資料域都是按照統一的規範來建設，從而形成統一規範的標準業務資料體系，它們通常都是基於Kimball的維度建模理論來構建的，並通過一致性維度和資料匯流排來保證各個子主題的維度一致性。
如果 ods 層的資料就非常規整，基本能滿足我們絕大部分的需求，這當然是好的，這時候dwd層其實就簡單了很多，但是現實中接觸的情況是 ods 層的資料很難保證質量，畢竟資料的來源多種多樣，推送方也會有自己的推送邏輯，在這種情況下，我們就需要通過額外的一層 dwd 來遮蔽一些底層的差異。有沒有很像JVM。
設計原則
一致性維度規範
公共層的維度表中相同維度屬性在不同物理表中的欄位名稱、資料型別、資料內容必須保持一致，因為這樣可以降低我們在使用過程中犯錯誤的概率，例如使用了不正確的欄位，或者因為資料型別的原因導致了一些奇怪的錯誤
維度的組合與拆分
將維度所描述業務相關性強的欄位在一個物理維表實現。相關性強是指經常需要一起查詢或進行報表展現、兩個維度屬性間是否存在天然的關係等。例如，商品基本屬性和所屬品牌。
DWD 明細資料層
公告明細資料層，可以說是我們數倉建設的核心了。
DWD層要做的就是將資料清理、整合、規範化、髒資料、垃圾資料、規範不一致的、狀態定義不一致的、命名不規範的資料都會被處理。然後加工成面向數倉的基礎明細表，這個時候可以加工一些面向分析的大寬表。
DWD層應該是覆蓋所有系統的、完整的、乾淨的、具有一致性的資料層。在DWD層會根據維度模型，設計事實表和維度表，也就是說DWD層是一個非常規範的、高質量的、可信的資料明細層。
DWS 輕度彙總層
DWS層為公共彙總層，這一層會進行輕度彙總，粒度比明細資料稍粗，基於DWD層上的基礎資料，整合彙總成分析某一個主題域的服務資料，一般是也是面向分析寬表或者是面向某個注意的彙總表。DWS層應覆蓋80%的應用場景，這樣我們才能快速響應資料需求，否則的話，如果很多需求都要從ods開始做的話，那說明我們的數倉建設是不完善的。
例如按照業務劃分，例如流量，訂單，使用者等，生成欄位比較多的寬表，用於後續的業務查詢，OLAP分析，資料分析等。
一般採用維度模型方法作為理論基礎，更多的採用一些維度退化手法，將維度退化至事實表中，減少維度表與事實表的關聯，提高明細資料表的易用性；同時在彙總資料層要加強指標的維度退化，採用更多的寬表化手段構建公共指標資料層，提升公共指標的複用性，減少重複加工。
DIM 維度層
維表層，所以其實維度層就是大量維表構成的，為了統一管理這些維度表，所以我們就建設維度層，維度表本身也有很多型別，例如穩定維度維表，漸變維度維表。
維度指的是觀察事物的角度，提供某一業務過程事件涉及用什麼過濾和分類的描述屬性，"誰、什麼時候、什麼地點、為什麼、如何"幹了什麼，維度表示維度建模的基礎和靈魂。
比如，"小王早上在小賣部花費5元錢購買了包子"，時間維度——早上，地點維度——小賣部，商品維度——包子 那麼事實表呢？
所以可以看出，維度表包含了業務過程記錄的業務過程度量的上下文和環境。維度表都包含單一的主鍵列，維度表設計的核心是確定維度欄位，維度欄位是查詢約束條件(where)、分組條件(group)、排序(order)，與報表標籤的基本來源。
維度表一般為單一主鍵，在ER模型中，實體為客觀存在的事務，會帶有自己的描述性屬性，屬性一般為文字性、描述性的，這些描述被稱為維度。維度建模的核心是資料可以抽象為事實和維度，維度即觀察事物的角度，事實某一粒度下的度量詞，維度一定是針對實體而言的。
每個維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關聯的任何事實表的外來鍵，當然，維度錶行的描述環境應與事實錶行完全對應。 維度表通常比較寬，是扁平型非規範表，包含大量的低粒度的文字屬性。例如customer（客戶表）、goods(商品表)、d_time(時間表)這些都屬於維度表，這些表都有一個唯一的主鍵，然後在表中存放了詳細的資料資訊。
設計原則
維度表通常比較寬，包含多個屬性、是扁平的規範表，實際應用中包含幾十個或者上百個屬性的維度並不少見，所以維度表應該包括一些有意義的描述，方便下游使用。
維度表的維度屬性，應該儘可能的豐富，所以維度表中，經常出現一些反正規化的設計，把其他維度屬性併到主維度屬性中，達到易用少關聯的效果。
維度表的設計包括維度選擇，主維表的確定，梳理關聯維度，定義維度屬性的過程。
維度的選擇一般從報表需求和從業務人員的交談中發現，主要用於過濾、分組、排序，主維度表一般從業務庫直接同步，比如使用者表，但是數倉的本身也會有自己的維度，這是因為數倉是面向分析的，所以會有很多從分析的角度出發的維度。
關聯維度主要是不同業務系統或者同一業務系統的表之間存在關聯性(正規化建模)，根據對業務表的梳理，確定哪些表和主維度表之間存在關聯關係，並選擇其中的某些表用於生成維度屬性。
TDM 標籤資料層
隨著網際網路的普及，獲客成本越來越高，這也使得公司對使用者運營提出了更高的要求，不僅需要精細化更需要個性化。解決這一問題的辦法之一就是建立相對完備的標籤系統，而數倉的標籤層對於標籤系統而言就像資料倉儲對於資料系統一樣，有著舉足輕重的地位，這樣的標籤系統需要與業務進行緊密結合，從業務中獲取養分—使用者標籤，同時也要服務於業務—給使用者提供更加精準和個性的服務。
底層的標籤系統就像一個索引，層層展示大千世界，而使用者就從這大千世界中不斷選擇一些東西表明自己的身份和喜好，也不斷反哺，使得這個大千世界更加豐富多彩。其實到最後使用者就是一些標籤的集合。
對跨業務板塊、跨資料域的特定物件進行資料整合，通過統一的ID-Mapping 把各個業務板塊，各個業務過程中同一物件的資料打通，形成物件的全域資料標籤體系，方便深度分析、挖掘、應用。ID-Mapping 可以認為是通過物件的標識對不同資料體系下相同物件進行關聯和識別。 物件的標識可以標識一個物件，一般是物件的ID,比如手機號，身份證，登入賬號
一個自然人他有身份證號碼進行唯一標識，但是在醫保的時候他使用的實醫保賬號，繳納水電費的時候又是不同的賬號，使用手機的時候又是裝置賬號，上網的時候是網商賬號。在確認物件後，由於同一物件在不同的業務體系中的物件標識是不一樣的，因此需要將同一物件上的不同ID 標識打通，以便所有的業務資料都能夠在該物件上打通。這就是ID-Mapping。
完成物件的ID 打通需要給物件設定一個超級ID,需要根據物件當前業務體系的ID和獲取得到或者計算得到超級ID,進而完成所有業務標識的ID打通一般來說ID打通是建設標籤體系的前提，如果沒有ID打通就無法收集到一個物件的全面資訊，也就無法對這個物件進行全面的標籤刻畫。
傳統的計算方法要有 ID-ID之間的兩兩關係，例如郵箱和手機號可以打通，手機號和身份證號可以打通，那麼郵箱就和身份證號可以打通，但是當資料量非常大，且業務板塊非常多的時候，例如有上一個物件，每個物件有數十種ID,這個時候打通就需要非常漫長的計算
那麼什麼是標籤呢，利用原始資料，通過一定的邏輯加工產出直接能被業務所直接使用的、可閱讀的，有價值的資料。標籤類目，是標籤的分類組織方式，是標籤資訊的一種結構化描述，目的是管理、查詢，一般採用多級類目，一般當一個物件的標籤個數超過50個的時候，業務人員查詢標籤就會變得非常麻煩，這個時候我們往往會通過標籤類目進行組織管理
標籤的分類
標籤按照產生和計算方式的不同可分為屬性標籤，統計標籤，演算法標籤，關聯標籤。
屬性標籤
物件本身的性質就是屬性標籤，例如使用者畫像的時候打到使用者身上的標籤。
統計標籤
物件在業務過程中產生的原子指標，通過不同的計算方法可以生成統計標籤。
演算法標籤
物件在多個業務過程中的特徵規律通過一定的演算法產出的標籤。
關聯標籤
物件在特定的業務過程會和其他物件關聯，關聯物件的標籤也可以打在主物件上。
設計原則
我們的標籤一定是針對使用者的，而不是一些虛假、高大上、無用的標籤，一定要真實反映使用者行為喜好的，所以我們不能只依賴人工智慧演算法的分析，來完成對一個使用者標籤的建立與定期維護，我們需要走出去和使用者互動，引導使用者使用，要抓住使用者痛點，及時獲取使用者反饋，形成閉環。
如何引導使用呢？這個方式有很多我們就不再這裡介紹了，後面我們會專門介紹這一層的建設細節。
ADS 層
資料應用層ApplicationDataService面向業務定製的應用資料，主要提供給資料產品和資料分析使用的資料，一般會放在ES，MYSQL，Redis等系統供線上系統使用，也可以放在Hive中供資料分析和資料探勘使用，或者使用一下其他的大資料工具進行儲存和使用。
數倉層，DIM 層，TDM 層是相對穩定的，所以無法滿足靈活多變業務需求，所以這和數倉層的規範和劃分相矛盾，所以我們在此基礎上建立了另外一個層，這就是ADS 層，解決了規劃穩定和靈活多變之間的矛盾。其實到這裡你也就慢慢的看明白了，分層和分類其實沒多大差別，其實就是相似的放在一起，有點程式碼重構的意味啊。
資料應用層，按照業務的需要，然後從統一數倉層和DIM進行取數，並面向業務的特殊需求對資料進行加工,以滿足業務和效能的需求。ADS 層因為面向的實眾多的需求，所以這一層沒有太多的規範，只需要按照命名規範來進行就可以了。
設計原則
前面也說了，ADS 層因為面向的實眾多的需求，所以這一層沒有太多的規範，但是ADS 層的建設是強業務推動的，業務部門需要參與到ADS 的建設中來，至少我們得了解使用者的痛點才能對症施藥啊。
實現流程
理清需求，瞭解業務方對資料內容、使用方式(怎麼互動的，報表、介面、即席查詢、線上查詢、指標查詢、搜尋)、效能的要求。
盤點現有的數倉表是否可以支援，看以前有沒有類似的需求，有沒有可以複用的介面、報表什麼的。
程式碼實現，選擇合適的儲存引擎和查詢引擎，配置線上監控然後交付。
使用場景與效能
- 針對業務方的使用場景，我們需要設計出高效，滿足要求的ADS 層表
- 如果是多維分析，為了減少連線，提升效能，我們一般採用大寬表設計，使用高效能引擎支撐
- 如果是特定指標查詢，一般採用KV的形式組織
- 如果是搜尋場景，一般採用搜尋引擎
DM 資料集市層
主要是提供資料產品和資料分析的資料，一般會存放在ES、Mysql、也可能直接儲存在hive中或者druid供資料分析和資料探勘使用。主要解決部門使用者報表和分析需求而建立資料庫，資料集市就代表資料倉儲的主題域。
DM 是面向單個主題的，所以它不會從全域性考慮進行建設，只專注於自己的資料、往往是某個業務線，例如流量主題、社交主題、電商主題等等。