數(shù)倉建模分層理論

分層建設理論

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

數(shù)倉的建?；蛘叻謱樱鋵嵍际菫榱烁玫娜ソM織、管理、維護數(shù)據(jù),所以當你站在更高的維度去看的話，所有的劃分都是為了更好的管理。小到JVM 內(nèi)存區(qū)域的劃分，JVM 中堆空間的劃分(年輕代、老年代、方法區(qū)等)，大到國家的省市區(qū)的劃分，無一例外的都是為了更好的組織管理。

所以數(shù)倉分層是數(shù)據(jù)倉庫設計中十分重要的一個環(huán)節(jié)，優(yōu)秀的分層設計能夠讓整個數(shù)據(jù)體系更容易理解和使用。

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

分層的意義

清晰數(shù)據(jù)結(jié)構(gòu)體系

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

數(shù)據(jù)血緣追蹤

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

減少重復開發(fā)和資源浪費

  • 規(guī)范數(shù)據(jù)分層，開發(fā)一些通用的中間層數(shù)據(jù)，能夠減少極大的重復計算；
  • 清晰明了的結(jié)構(gòu)使得開發(fā)、維護的成本降低；
  • 減少重復計算和存儲的資源浪費；

復雜問題簡單化

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

在實際的建設過程中，由于業(yè)務使用數(shù)據(jù)非常緊急以及統(tǒng)一數(shù)倉層建設跟不上業(yè)務的需要，所以DIM和ADS層可能直接使用ODS層進行快速的業(yè)務響應，但是這種不規(guī)范的操作可能導致數(shù)據(jù)口徑不一致，所以待數(shù)倉建設完畢，要切換到統(tǒng)一數(shù)倉層和DIM層。

統(tǒng)一數(shù)據(jù)口徑

過數(shù)據(jù)分層提供統(tǒng)一的數(shù)據(jù)出口，統(tǒng)一對外輸出的數(shù)據(jù)口徑，這往往就是我們說的數(shù)據(jù)應用層。

關(guān)于分層的一點思考

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

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

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

數(shù)倉的分層

ods 操作數(shù)據(jù)層

ODS 全稱是 OperationalDataStore，操作數(shù)據(jù)層存儲的是面向業(yè)務系統(tǒng)的數(shù)據(jù)，也是最接近數(shù)據(jù)源中數(shù)據(jù)的一層，數(shù)據(jù)源中的數(shù)據(jù)，經(jīng)過抽取、洗凈、傳輸，也就說傳說中的 ETL 之后，裝入本層。

其實這里說ETL 有點不合適了，其實更準確的是ELT,你可以細細品品

本層的數(shù)據(jù)，總體上大多是按照源頭業(yè)務系統(tǒng)的分類方式而分類的，前面我們說到為什么在數(shù)倉主要用維度建模的情況下，我們依然要學習范式建模呢，因為我們的數(shù)據(jù)源是范式建模的，所以學習范式建?？梢詭椭覀兏玫睦斫鈽I(yè)務系統(tǒng)，理解業(yè)務數(shù)據(jù)，所以你可以認為我們的ODS 層其實就是用的實范式建模。

但是，這一層面的數(shù)據(jù)卻不等同于原始數(shù)據(jù)。在源數(shù)據(jù)裝入這一層時，要進行諸如去噪(例如有一條數(shù)據(jù)中人的年齡是300歲，這種屬于異常數(shù)據(jù)，就需要提前做一些處理)、去重(例如在個人資料表中，同一ID卻有兩條重復數(shù)據(jù)，在接入的時候需要做一步去重)、字段命名規(guī)范等一系列操作。

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

其實關(guān)于這一層，很多人的理解不太一樣，那就是是否要進行數(shù)據(jù)清洗，其實還是取決于公司的使用習慣，其實有很多公司在這一層之前也會形成一個層，名字千奇百怪，但是它的目的是數(shù)據(jù)緩沖，然后進行清洗，清洗之后的數(shù)據(jù)存入ODS ,而這個時候緩沖層數(shù)據(jù)存放一般為一周左右，幾乎不會超過一個月；而ODS則永久存放。

設計原則

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

  • ods 層不做字段名歸一和字段類型統(tǒng)一的操作，如果需要則使用兼容的數(shù)據(jù)類型
  • 對于增量表，需要設計增量表(ODS_業(yè)務系統(tǒng)_表名_delta)和全量表,然后將增量表合并成全量表數(shù)據(jù)；
  • 對于半結(jié)構(gòu)化數(shù)據(jù)需要設計解析；
  • 由于業(yè)務數(shù)據(jù)庫（OLTP）基本按照維度模型建模，因此ODS層中的建模方式也是維度模型；

ods 的設計可以保證所有的數(shù)據(jù)按照統(tǒng)一的規(guī)范進行存儲。

DW 統(tǒng)一數(shù)倉層

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

這一層和維度建模會有比較深的聯(lián)系，業(yè)務數(shù)據(jù)是按照業(yè)務流程方便操作的角度來組織數(shù)據(jù)的，而統(tǒng)一數(shù)倉層是按照業(yè)務易理解的角度或者是業(yè)務分析的角度進行數(shù)據(jù)組織的，定義了一致的指標、維度，各業(yè)務板塊、數(shù)據(jù)域都是按照統(tǒng)一的規(guī)范來建設，從而形成統(tǒng)一規(guī)范的標準業(yè)務數(shù)據(jù)體系，它們通常都是基于Kimball的維度建模理論來構(gòu)建的，并通過一致性維度和數(shù)據(jù)總線來保證各個子主題的維度一致性。

如果 ods 層的數(shù)據(jù)就非常規(guī)整，基本能滿足我們絕大部分的需求，這當然是好的，這時候dwd層其實就簡單了很多，但是現(xiàn)實中接觸的情況是 ods 層的數(shù)據(jù)很難保證質(zhì)量，畢竟數(shù)據(jù)的來源多種多樣，推送方也會有自己的推送邏輯，在這種情況下，我們就需要通過額外的一層 dwd 來屏蔽一些底層的差異。有沒有很像JVM。

設計原則

一致性維度規(guī)范

公共層的維度表中相同維度屬性在不同物理表中的字段名稱、數(shù)據(jù)類型、數(shù)據(jù)內(nèi)容必須保持一致，因為這樣可以降低我們在使用過程中犯錯誤的概率，例如使用了不正確的字段，或者因為數(shù)據(jù)類型的原因?qū)е铝艘恍┢婀值腻e誤

維度的組合與拆分

將維度所描述業(yè)務相關(guān)性強的字段在一個物理維表實現(xiàn)。相關(guān)性強是指經(jīng)常需要一起查詢或進行報表展現(xiàn)、兩個維度屬性間是否存在天然的關(guān)系等。例如，商品基本屬性和所屬品牌。

DWD 明細數(shù)據(jù)層

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

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

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

DWS 輕度匯總層

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

例如按照業(yè)務劃分，例如流量，訂單，用戶等，生成字段比較多的寬表，用于后續(xù)的業(yè)務查詢，OLAP分析，數(shù)據(jù)分析等。

一般采用維度模型方法作為理論基礎(chǔ)，更多的采用一些維度退化手法，將維度退化至事實表中，減少維度表與事實表的關(guān)聯(lián)，提高明細數(shù)據(jù)表的易用性；同時在匯總數(shù)據(jù)層要加強指標的維度退化，采用更多的寬表化手段構(gòu)建公共指標數(shù)據(jù)層，提升公共指標的復用性，減少重復加工。

DIM 維度層

維表層，所以其實維度層就是大量維表構(gòu)成的，為了統(tǒng)一管理這些維度表，所以我們就建設維度層，維度表本身也有很多類型，例如穩(wěn)定維度維表，漸變維度維表。

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

比如，"小王早上在小賣部花費5元錢購買了包子"，時間維度——早上，地點維度——小賣部，商品維度——包子 那么事實表呢？

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

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

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

設計原則

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

維度表的維度屬性，應該盡可能的豐富，所以維度表中，經(jīng)常出現(xiàn)一些反范式的設計，把其他維度屬性并到主維度屬性中，達到易用少關(guān)聯(lián)的效果。

維度表的設計包括維度選擇，主維表的確定，梳理關(guān)聯(lián)維度，定義維度屬性的過程。

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

關(guān)聯(lián)維度主要是不同業(yè)務系統(tǒng)或者同一業(yè)務系統(tǒng)的表之間存在關(guān)聯(lián)性(范式建模)，根據(jù)對業(yè)務表的梳理，確定哪些表和主維度表之間存在關(guān)聯(lián)關(guān)系，并選擇其中的某些表用于生成維度屬性。

TDM 標簽數(shù)據(jù)層

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

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

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

一個自然人他有身份證號碼進行唯一標識，但是在醫(yī)保的時候他使用的實醫(yī)保賬號，繳納水電費的時候又是不同的賬號，使用手機的時候又是設備賬號，上網(wǎng)的時候是網(wǎng)商賬號。在確認對象后，由于同一對象在不同的業(yè)務體系中的對象標識是不一樣的，因此需要將同一對象上的不同ID 標識打通，以便所有的業(yè)務數(shù)據(jù)都能夠在該對象上打通。這就是ID-Mapping。

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

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

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

標簽的分類

標簽按照產(chǎn)生和計算方式的不同可分為屬性標簽，統(tǒng)計標簽，算法標簽，關(guān)聯(lián)標簽。

屬性標簽

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

統(tǒng)計標簽

對象在業(yè)務過程中產(chǎn)生的原子指標，通過不同的計算方法可以生成統(tǒng)計標簽。

算法標簽

對象在多個業(yè)務過程中的特征規(guī)律通過一定的算法產(chǎn)出的標簽。

關(guān)聯(lián)標簽

對象在特定的業(yè)務過程會和其他對象關(guān)聯(lián)，關(guān)聯(lián)對象的標簽也可以打在主對象上。

設計原則

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

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

ADS 層

數(shù)據(jù)應用層ApplicationDataService面向業(yè)務定制的應用數(shù)據(jù)，主要提供給數(shù)據(jù)產(chǎn)品和數(shù)據(jù)分析使用的數(shù)據(jù)，一般會放在ES，MYSQL，Redis等系統(tǒng)供線上系統(tǒng)使用，也可以放在Hive中供數(shù)據(jù)分析和數(shù)據(jù)挖掘使用，或者使用一下其他的大數(shù)據(jù)工具進行存儲和使用。

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

數(shù)據(jù)應用層，按照業(yè)務的需要，然后從統(tǒng)一數(shù)倉層和DIM進行取數(shù)，并面向業(yè)務的特殊需求對數(shù)據(jù)進行加工,以滿足業(yè)務和性能的需求。ADS 層因為面向的實眾多的需求，所以這一層沒有太多的規(guī)范，只需要按照命名規(guī)范來進行就可以了。

設計原則

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

實現(xiàn)流程

理清需求，了解業(yè)務方對數(shù)據(jù)內(nèi)容、使用方式(怎么交互的，報表、接口、即席查詢、在線查詢、指標查詢、搜索)、性能的要求。

盤點現(xiàn)有的數(shù)倉表是否可以支持，看以前有沒有類似的需求，有沒有可以復用的接口、報表什么的。

代碼實現(xiàn)，選擇合適的存儲引擎和查詢引擎，配置線上監(jiān)控然后交付。

使用場景與性能
  • 針對業(yè)務方的使用場景，我們需要設計出高效，滿足要求的ADS 層表
  • 如果是多維分析，為了減少連接，提升性能，我們一般采用大寬表設計，使用高性能引擎支撐
  • 如果是特定指標查詢，一般采用KV的形式組織
  • 如果是搜索場景，一般采用搜索引擎

DM 數(shù)據(jù)集市層

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

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





作者：柯廣的網(wǎng)絡日志

微信公眾號：Java大數(shù)據(jù)與數(shù)據(jù)倉庫