數倉建模分層理論

分層建設理論

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

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

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

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

分層的意義

清晰數據結構體系

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

數據血緣追蹤

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

減少重復開發和資源浪費

  • 規范數據分層,開發一些通用的中間層數據,能夠減少極大的重復計算;
  • 清晰明了的結構使得開發、維護的成本降低;
  • 減少重復計算和存儲的資源浪費;

復雜問題簡單化

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

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

統一數據口徑

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

關于分層的一點思考

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

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

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

數倉的分層

ods 操作數據層

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

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

本層的數據,總體上大多是按照源頭業務系統的分類方式而分類的,前面我們說到為什么在數倉主要用維度建模的情況下,我們依然要學習范式建模呢,因為我們的數據源是范式建模的,所以學習范式建??梢詭椭覀兏玫睦斫鈽I務系統,理解業務數據,所以你可以認為我們的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 是面向單個主題的,所以它不會從全局考慮進行建設,只專注于自己的數據、往往是某個業務線,例如流量主題、社交主題、電商主題等等。





作者:柯廣的網絡日志

微信公眾號:Java大數據與數據倉庫