最強最全的數倉建設規範指南,肝完後卷哭他們!

語言: CN / TW / HK

本文將全面講解數倉建設規範,從資料模型規範,到數倉公共規範,數倉各層規範,最後到數倉命名規範,包括表命名,指標欄位命名規範等!

一、資料模型架構原則

1、數倉分層原則

優秀可靠的數倉體系,往往需要清晰的資料分層結構,即要保證資料層的穩定又要遮蔽對下游的影響,並且要避免鏈路過長。那麼問題來了,一直在講數倉要分層,那數倉分幾層最好?

目前市場上主流的分層方式眼花繚亂,不過看事情不能只看表面,還要看到內在的規律, 不能為了分層而分層,沒有最好的,只有適合的。

分層是以解決當前業務快速的資料支撐為目的,為未來抽象出共性的框架並能夠賦能給其他業務線,同時為業務發展提供穩定、準確的資料支撐,並能夠按照已有的模型為新業務發展提供方向,也就是資料驅動和賦能。

一個好的分層架構,要有以下好處:

  • 清晰資料結構;

  • 資料血緣追蹤;

  • 減少重複開發;

  • 資料關係條理化;

  • 遮蔽原始資料的影響。

數倉分層要結合公司業務進行,並且需要清晰明確各層職責,一般採用如下分層結構:

資料分層架構

數倉建模在哪層建設呢?我們以維度建模為例,建模是在資料來源層的下一層進行建設,在上圖中,就是在DW層進行數倉建模,所以DW層是數倉建設的核心層。

下面詳細闡述下每層建設規範,和上圖的分層稍微有些區別:

1)資料來源層:ODS(Operational Data Store)

ODS 層,是最接近資料來源中資料的一層,為了考慮後續可能需要追溯資料問題,因此對於這一層就不建議做過多的資料清洗工作,原封不動地接入原始資料即可,至於資料的去噪、去重、異常值處理等過程可以放在後面的 DWD 層來做。

2)資料倉庫層:DW(Data Warehouse)

資料倉庫層是我們在做資料倉庫時要核心設計的一層,在這裡,從 ODS 層中獲得的資料按照主題建立各種資料模型。

DW 層又細分為 DWD(Data Warehouse Detail)層、DWM(Data WareHouse Middle)層和 DWS(Data WareHouse Servce) 層。

①資料明細層:DWD(Data Warehouse Detail)

該層一般保持和 ODS 層一樣的資料粒度,並且提供一定的資料質量保證。 DWD 層要做的就是將資料清理、整合、規範化、髒資料、垃圾資料、規範不一致的、狀態定義不一致的、命名不規範的資料都會被處 理。

同時,為了提高資料明細層的易用性, 該層會採用一些維度退化手法,將維度退化至事實表中,減少事實表和維表的關聯。

另外,在該層也會做一部分的資料聚合,將相同主題的資料彙集到一張表中,提高資料的可用性 。

②資料中間層:DWM(Data WareHouse Middle)

該層會在 DWD 層的資料基礎上,資料做輕度的聚合操作,生成一系列的中間表,提升公共指標的複用性,減少重複加工。

直觀來講,就是對通用的核心維度進行聚合操作,算出相應的統計指標。

在實際計算中,如果直接從 DWD 或者 ODS 計算出寬表的統計指標,會存在計算量太大並且維度太少的問題,因此一般的做法是,在 DWM 層先計算出多個小的中間表,然後再拼接成一張 DWS 的寬表。由於寬和窄的界限不易界定,也可以去掉 DWM 這一層,只留 DWS 層,將所有的資料再放在 DWS 亦可。

③資料服務層:DWS(Data WareHouse Servce)

DWS 層為公共彙總層,會進行輕度彙總,粒度比明細資料稍粗,基於 DWD 層上的基礎資料, 整合彙總成分析某一個主題域的服務資料,一般是寬表。 DWS 層應覆蓋 80% 的應用場景。又稱資料集市或寬表。

按照業務劃分,如主題域流量、訂單、使用者等,生成欄位比較多的寬表,用於提供後續的業務查詢,OLAP 分析,資料分發等。

一般來講,該層的資料表會相對比較少,一張表會涵蓋比較多的業務內容,由於其欄位較多,因此一般也會稱該層的表為寬表。

3)資料應用層:APP(Application)

在這裡,主要是提供給資料產品和資料分析使用的資料,一般會存放在 ES、 PostgreSql、Redis 等系統中供線上系統使用,也可能會存在 Hive 或者 Druid 中供資料分析和資料探勘使用。比如我們經常說的報表資料,一般就放在這裡。

4)維表層(Dimension)

如果維表過多,也可針對維表設計單獨一層,維表層主要包含兩部分資料:

高基數維度資料: 一般是使用者資料表、商品資料表類似的資料表。資料量可能是千萬級或者上億級別。

低基數維度資料: 一般是配置表,比如列舉值對應的中文含義,或者日期維表。資料量可能是個位數或者幾千幾萬。

2、主題域劃分原則

1) 按照 業務或業務過程劃分

業務容易理解,就是指的功能模組/業務線。

業務過程:指企業的業務活動事件,如下單、支付、退款都是業務過程。不過需要注意的是,一個業務過程是一個不可拆分的行為事件,通俗的講,業務過程就是企業活動中的事件。

2) 按照資料域劃分

資料域是指面向業務分析,將業務過程或者維度進行抽象的集合。其中,業務過程可以概括為一個個不可拆分的行為事件,在業務過程下,可以定義指標,維度是指度量的環境,如買家下單事件,買家是維度。為保障整個體系的生命力,資料域是需要抽象提煉,並且長期維護和更新的,但不輕易變動。在劃分資料域時,既能涵蓋當前所有的業務需求,又能在新業務進入時無影響地被包含進已有的資料域中和擴充套件新的資料域。

3、資料模型設計原則

1) 高內聚、低耦合

主題內部高內聚、 不同主題間低耦合。 明細層按照業務過程劃分主題,彙總層按照“實體+ 活動”劃分不同分析主題,應用層根據應用需求劃分不同應用主題。

2) 核心模型和擴充套件模型要分離

建立核心模型與擴充套件模型體系,核心模型包括的欄位支援常用的核心業務,擴充套件模型包括的欄位支援個性化或少量應用的需要, 不能讓擴充套件模型的欄位過度侵入核心模型,以免破壞核心模型的架構簡潔性與可維護性。

3) 公共處理邏輯下沉及單一

越是底層公用的處理邏輯越應該在資料排程依賴的底層進行封裝與實現,不要讓公用的處理邏輯暴露給應用實現, 不要讓公共邏輯多處同時存在。

4) 成本與效能平衡

適當的資料冗餘可換取查詢和重新整理效能,不宜過度冗餘與資料複製。

5) 資料可回滾

處理邏輯不變,在不同時間多次執行資料結果確定不變。

二、數倉公共開發規範

1、層次呼叫規範

穩定業務 按照標準的資料流向進行開發,即 ODS –> DWD –> DWS –> APP。 非穩定業務 或探索性需求,可以遵循 ODS -> DWD -> APP 或者 ODS -> DWD -> DWM ->APP 兩個模型資料流。

在保障了資料鏈路的合理性之後,也必須保證模型分層引用原則:

  • 正常流向:ODS -> DWD -> DWM -> DWS -> APP,當出現 ODS -> DWD -> DWS -> APP 這種關係時,說明主題域未覆蓋全。應將 DWD 資料落到 DWM 中,對於使用頻度非常低的表允許 DWD -> DWS。

  • 儘量避免出現 DWS 寬表中使用 DWD 又使用(該 DWD 所歸屬主題域)DWM 的表。

  • 同一主題域內對於 DWM 生成 DWM 的表,原則上要儘量避免,否則會影響 ETL 的效率。

  • DWM、DWS 和 APP 中禁止直接使用 ODS 的表, ODS 的表只能被 DWD 引用。

  • 禁止出現反向依賴 ,例如 DWM 的表依賴 DWS 的表。

舉例:

2、資料型別規範

需統一規定不同的資料的資料型別,嚴格按照規定的資料型別執行:

  • 金額: double 或 使用 decimal(28,6) 控制精度等,明確單位是分還是元。

  • 字串: string。

  • id類: bigint。

  • 時間: string。

  • 狀態: string

3、資料冗餘規範

寬表的冗餘欄位要確保:

  • 冗餘欄位要使用高頻,下游3個或以上使用。

  • 冗餘欄位引入不應造成本身資料產生過多的延後。

  • 冗餘欄位和已有欄位的重複率不應過大,原則上不應超過60%,如需要可以選擇join或原表拓展。

4、NULL欄位處理規範

  • 對於維度欄位,需設定為-1

  • 對於指標欄位,需設定為 0

5、指標口徑規範

保證主題域內,指標口徑一致,無歧義。

通過資料分層,提供統一的資料出口,統一對外輸出的資料口徑,避免同一指標不同口徑的情況發生。

1) 指標梳理

指標口徑的不一致使得資料使用的成本極高,經常出現口徑打架、反覆核對資料的問題。在資料治理中,我們將需求梳理到的所有指標進行進一步梳理,明確其口徑,如果存在兩個指標名稱相同,但口徑不一致,先判斷是否是進行合併,如需要同時存在,那麼在命名上必須能夠區分開。

2) 指標管理

指標管理分為原子指標維護和派生指標維護。

原子指標:

  • 選擇原子指標的歸屬產線、業務板塊、資料域、業務過程

  • 選擇原子指標的統計資料來源於該業務過程下的原始資料來源

  • 錄入原子指標的英文名稱、中文名稱、概述

  • 填寫指標函式

  • 系統根據指標函式自動生成原子指標的定義表示式

  • 系統根據指標定義表示式以及資料來源表生成原子指標SQL

派生指標:

  • 在原子指標的基礎之上選擇了一些維度或者修飾限定詞。

6、資料表處理規範

1) 增量表

新增資料,增量資料是上次匯出之後的新資料。

  • 記錄每次增加的量,而不是總量;

  • 增量表,只報變化量,無變化不用報;

  • 每天一個分割槽。

2) 全量表

每天的所有的最新狀態的資料。

  • 全量表,有無變化,都要報;

  • 每次上報的資料都是所有的資料(變化的 + 沒有變化的);

  • 只有一個分割槽。

3) 快照表

按日分割槽,記錄截止資料日期的全量資料。

  • 快照表,有無變化,都要報;

  • 每次上報的資料都是所有的資料(變化的 + 沒有變化的);

  • 一天一個分割槽。

4) 拉鍊表

記錄截止資料日期的全量資料。

  • 記錄一個事物從開始,一直到當前狀態的所有變化的資訊;

  • 拉鍊表每次上報的都是歷史記錄的最終狀態,是記錄在當前時刻的歷史總 量;

  • 當前記錄存的是當前時間之前的所有歷史記錄的最後變化量(總量);

  • 只有一個分割槽。

7、表的生命週期管理

這部分主要是要通過對歷史資料的等級劃分與對錶型別的劃分生成相應的生命週期管理矩陣。

1) 歷史資料等級劃分

主要將歷史資料劃分P0、Pl、P2、P3 四個等級,其具體定義如下:

  • P0 :非常重要的主題域資料和非常重要的應用資料,具有不可恢復性,如交易、日誌、集團 KPI 資料、 IPO 關聯表。

  • Pl :重要的業務資料和重要的應用資料,具有不可恢復性,如重要的業務產品資料。

  • P2 :重要的業務資料和重要的應用資料,具有可恢復性,如交易線 ETL 產生的中間過程資料。

  • P3 :不重要的業務資料和不重要的應用資料,具有可恢復性,如某些 SNS 產品報表。

2) 表型別劃分

①事件型流水錶(增量表)

事件型流水錶(增量表)指資料無重複或者無主鍵資料,如日誌。

②事件型映象表(增量表)

事件型映象表(增量表)指業務過程性資料,有主鍵,但是對於同樣主鍵的屬性會發生緩慢變化,如交易、訂單狀態與時間會根據業務發生變更。

③維表

維表包括維度與維度屬性資料,如使用者表、商品表。

④Merge 全量表

Merge 全量表包括業務過程性資料或者維表資料。由於資料本身有新增的或者發生狀態變更,對於同樣主鍵的資料可能會保留多份,因此可以對這些資料根據主鍵進行 Merge 操作,主鍵對應的屬性只會保留最新狀態,歷史狀態保留在前一天分割槽 中。例如,使用者表、交易表等都可以進行 Merge 操作。

⑤ETL 臨時表

ETL 臨時表是指 ETL 處理過程中產生的臨時表資料,一般不建議保留,最多7天。

⑥TT 臨時資料

TT 拉取的資料和 DbSync 產生的臨時資料最終會流轉到 DS 層,ODS 層資料作為原始資料保留下來,從而使得 TT&DbSync 上游資料成為臨時資料。這類資料不建議保留很長時間,生命週期預設設定為 93天,可以根據實際情況適當減少保留天數。

⑦普通全量表

很多小業務資料或者產品資料,BI一般是直接全量拉取,這種方式效率快,對儲存壓力也不是很大,而且表保留很長時間,可以根據歷史資料等級確定保留策略。

通過上述歷史資料等級劃分與表型別劃分,生成相應的生命週期管理矩陣,如下表所示:

三、數倉各層開發規範

1、ODS層設計規範

1)同步規範:

2)表分類與生命週期:

①ods流水全量表:

  • 不可再生的永久儲存;

  • 日誌可按留存要求;

  • 按需設定保留特殊日期資料;

  • 按需設定保留特殊月份資料;

②ods映象型全量表:

  • 推薦按天儲存;

  • 對歷史變化進行保留;

  • 最新資料儲存在最大分割槽;

  • 歷史資料按需保留;

③ods增量資料:

  • 推薦按天儲存;

  • 有對應全量表的,建議只保留14天資料;

  • 無對應全量表的,永久保留;

④ods的etl過程中的臨時表:

  • 推薦按需保留;

  • 最多保留7天;

  • 建議用完即刪,下次使用再生成;

⑤BDSync非去重資料:

  • 通過中間層保留,預設用完即刪,不建議保留。

3)資料質量:

  • 全量表必須配置唯一性欄位標識;

  • 對分割槽空資料進行監控;

  • 對列舉型別欄位,進行列舉值變化和分佈監控;

  • ods表資料量級和記錄數做環比監控;

  • ods全表都必須要有註釋;

2、公共維度層設計規範

1) 設計準則

①一致性

共維度在不同的物理表中的欄位名稱、資料型別、資料內容必須保持一致(歷史原因不一致,要做好版本控制)

②維度的組合與拆分

  • 組合原則:

將維度與關聯性強的欄位進行組合,一起查詢,一起展示,兩個維度必須具有天然的關係,如:商品的基本屬性和所屬品牌。

無相關性:如一些使用頻率較小的雜項維度,可以構建一個集合雜項維度的特殊屬性。

行為維度:經過計算的度量,但下游當維度處理,例:點選量 0-1000,100-1000等,可以做聚合分類。

針對重要性,業務相關性、源、使用頻率等可分為核心表、擴充套件表。

資料記錄較大的維度,可以適當冗餘一些子集。

2) 儲存及生命週期管理

建議按天分割槽。

1) 儲存及生命週期管理

建議按天分割槽。