數倉建模分層理論

分層建設理論

簡單點兒，直接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 是面向單個主題的，因此它不會從全局考慮進行建設，只專一於本身的數據、每每是某個業務線，例如流量主題、社交主題、電商主題等等。