新興資料倉儲設計與實踐手冊：從分層架構到實際應用（三）

海豚调度發表於2024-11-27
架構

本手冊將分為三部分發布，以幫助讀者逐步深入理解資料倉儲的設計與實踐。

  • 第一部分介紹資料倉儲的整體架構概述；
  • 第二部分深入討論ETL在數倉中的應用理論，ODS層的具體實現與應用；
  • 第三部分將圍繞DW資料倉儲層、ADS層和資料倉儲的整體趨勢展開；

透過這樣的結構，您可以系統地學習每一層次的內容和設計原則。

前情提要：
《新興資料倉儲設計與實踐手冊：從分層架構到實際應用（一）》https://mp.weixin.qq.com/s/_iYSM0sT_NOysducbxEJhg

《新興資料倉儲設計與實踐手冊：從分層架構到實際應用（二）》：http://mp.weixin.qq.com/s?__biz=MzkyODg0MzA1MQ==&mid=2247489134&idx=1&sn=47d09334fecb43ac2ee1beeb111c6abe&chksm=c37528ab9804979fefcb56f45551c409fd97d22453af0ae3b1df36de1026c42a3a61203c5a02#rd

技術方案設計

概念介紹

緩衝層（也稱介面層或Stage層）用於儲存每天的增量和變更資料。該層暫存從源系統採集的原始資料，以便後續資料處理和ETL流程的使用。

資料倉儲

資料生成方式

資料通常透過Kafka直接接入緩衝層，對於包含update、delete和insert操作的業務表，會每日生成變更日誌；而僅有insert操作的業務表，則直接將資料進入明細層。

建議方案： 使用Apache SeaTunnel或WhaleTunnel生成的CDC日誌直接進入緩衝層。如果業務涉及拉鍊資料，同樣將其存放於緩衝層，以確保資料變更的準確記錄。

日誌儲存方式

緩衝層的日誌資料以Impala外部表形式儲存，採用Parquet檔案格式。這種方式不僅提高了儲存效率，還便於MapReduce等處理引擎對資料的快速訪問和處理。

日誌清理策略

對於日誌資料，通常只保留最近幾天的資料以節省儲存空間。

建議方案：考慮長期儲存重要日誌資料，以便於歷史資料回溯和審計。

表的Schema和分割槽策略

通常按天分割槽資料，以partitioned by時間欄位進行儲存。這樣不僅簡化了資料管理，還能提升查詢效率。表的Schema設計遵循源系統的結構，以確保資料的一致性和完整性。

庫和表的命名規範

  • 庫名：ods，表示資料的貼源層。

  • 表名：格式建議為ods_日期_業務表名，例如ods_2024_10_sales，便於管理和查詢。

Hive表型別

在緩衝層中使用Hive的外部表管理資料，外部表的檔案可以儲存在非預設的HDFS路徑中，這樣當刪除表定義時，實際儲存檔案不會被刪除，保障資料安全。

業務表使用Hive的內部表，當刪除表定義時，關聯的HDFS檔案也會被刪除。此方式適合臨時或不重要的資料儲存，避免重要資料的誤刪。

DW資料倉儲層

資料倉儲層（DW層）是資料倉儲設計的核心層，負責對來自貼源層（ODS層）的資料進行主題化建模，以支援高效的業務分析和決策。

DW層根據業務主題劃分領域，為各主題構建清晰的資料檢視，過濾掉無關決策的資料，專注於支援企業關鍵分析。

在該層，通常會儲存業務系統的所有歷史資料，例如儲存10年以上的資料，為BI系統提供全面的歷史資料支援。

資料分層模型設計

DW層採用維度建模，將維度表和事實表建立外來鍵關聯關係，以減少資料冗餘、提高資料的組織效率。

維度模型不僅簡化了業務分析的複雜性，還提升了DW層的資料易用性。在彙總資料層中，透過寬表設計將不同統計維度關聯，建立高度複用的公共指標資料層，從而減少下游資料開發的重複勞動。

資料內容和結構

在DW層中，主要儲存三類資料：

  1. 明細事實資料：基於ODS層的原始資料加工而成，包含業務過程中的細節資訊。

  2. 維表資料：描述性資料（如客戶資訊、產品分類等），同樣從ODS層加工生成。

  3. 公共指標彙總資料：基於維表和明細資料彙總而成，為業務分析提供標準化的核心指標。

DW層的細分

DW層通常進一步劃分為三個子層：維度層（DIM）、明細資料層（DWD）和彙總資料層（DWS），並使用維度建模方法為資料設計結構，以確保高效的資料管理和訪問：

維度層（DIM，Dimension）

維度層以業務維度為建模核心，根據每個維度的業務語義，定義維度屬性和關聯關係，形成標準化的資料分析維表。此

層透過為各維度新增屬性、定義關聯關係等，明確計算邏輯，實現一致性的資料描述。為了避免在維度模型中出現冗餘資料，維度表通常採用雪花模型結構，透過拆分屬性表來減少資料重複，實現更加規範的維度建模。

明細資料層（DWD，Data Warehouse Detail）

明細資料層以具體的業務過程為核心進行建模，旨在捕捉業務活動的最細粒度資訊，構建詳細的事實表。這些事實表保留了業務過程的每一個細節，確保資料的完整性和精準性。

在實際設計中，對於一些關鍵的屬性欄位，可以適當進行冗餘處理，即採用寬表化設計，以提升查詢效率，減少多表關聯帶來的效能開銷。這種做法在確保資料精細化的同時，兼顧了系統的易用性和高效性。

彙總資料層（DWS，Data Warehouse Summary）

彙總資料層（DWS）以分析主題為核心進行建模，圍繞業務指標需求，構建標準化的彙總表，為上層應用提供一致的公共指標。

這一層基於寬表設計，將統計邏輯物理化，確保資料的命名規範和口徑一致，從而支援高效的分析查詢。彙總資料層包含多種主題的寬表和明細事實表，為業務提供統一的統計視角。

  • 主題域：以業務過程為視角，將業務活動進行抽象和分類。例如，下單、支付、退款等事件可歸類為不同的業務主題域，主要針對公共明細層（DWD）進行主題劃分。

  • 資料域：以分析需求為導向，將業務過程和維度進一步抽象，形成資料域。資料域劃分在公共彙總層（DWS）中進行，用於滿足各類業務分析需求。

層次結構與資料處理

  • DWD（Data Warehouse Details，資料明細層）：以業務過程為驅動，主要從ODS資料層抽取原始資料並進行清洗和規範化處理，確保資料的完整性和一致性。清洗內容包括去除空值、轉換髒資料、列舉值統一、以及異常值過濾等。

  • DWS（Data Warehouse Base，資料基礎層）：該層儲存客觀資料，主要作為中間層，為DWS層提供基礎指標支援。可以視為大量中間指標的儲存區，聚焦客觀的業務事實。

  • DWS（Data Warehouse Summary資料服務層）：基於DWB中的基礎資料，DWS層整合並彙總成以主題域為中心的寬表資料，用於OLAP分析、業務查詢和資料分發。DWS的寬表設計適用於高效查詢和聚合分析，滿足各種業務部門的統計需求。

資料彙總和輕度聚合

彙總資料層在資料服務和分析場景中發揮關鍵作用。主要對ODS和DWD層的資料進行輕度聚合和彙總，確保資料粒度適用於業務需求，支援複雜分析和快速響應上層查詢需求。

公共維度層（Dimension）

公共維度層（DIM）透過維度建模來構建企業的一致性維度，以確保在資料分析和計算過程中口徑統一，避免因演算法或指標不一致而引發的偏差。

維度層的主要目的是定義和標準化資料分析的基本屬性，例如國家程式碼、地理位置、產品分類等。透過為所有業務共享的維表建立統一的結構和命名規範，DIM層成為業務資料的標準參照層。

公共維度層的構成

維表：維表是邏輯維度的物理實現，將每個維度及其屬性具體化。為了提高查詢效率和降低資料冗餘，維表通常採用寬表設計原則。

高基數的維表（如使用者、商品等）可能包含數百萬甚至數億條記錄，而低基數的維表（如列舉配置、日期等）則記錄數相對較少。

維度層的設計要點

1） 維表設計原則在設計維表時，建議將單表的資料量控制在1000萬條以內。對於高基數表，可採用Map Join操作最佳化查詢效能。同時，避免頻繁更新維表，針對緩慢變化的維度（如商品分類）可採用拉鍊表方式記錄變更歷史。

2） 維表命名規範公共維度表命名通常以dim_開頭，表示與具體業務無關、可以在各個業務模組中複用的維度。例如，公共區域表命名為dim_pub_area，商品表命名為dim_asale_item。這種命名規範便於識別表用途和主題，提高資料管理的清晰度。

3） 粒度定義維度表中的資料粒度是業務過程的最小描述單位。例如，一條訂單記錄的粒度可能為“每次下單”。粒度可透過維度屬性組合來描述，如“國家-城市-區縣”組合用於表示地理位置的細節。粒度定義需精細，以滿足後續分析需求。

維度建模步驟

  1. 選擇業務過程選擇業務系統中的關鍵業務過程（如下單、支付、物流等）進行建模。中小企業通常會選取所有業務過程，而大企業則聚焦於分析需求的主要業務線，以減少資料冗餘和維護成本。

  2. 宣告粒度粒度定義明確資料的細化程度。建議選擇最小粒度，以支援更細粒度的指標計算。例如，在訂單資料中，每個商品項代表一行資料記錄，粒度為“每次下單”。保持細粒度可以靈活支援不同的統計需求，避免資料粒度過粗導致的資訊丟失。

  3. 確定維度維度用來描述業務中的“誰、何處、何時”等資訊，幫助分析不同維度的指標變化。例如，為支援訂單量按時間、區域或使用者的統計分析，需定義時間、地區和使用者維度。維度表設計遵循星型模型原則，在必要時進行維度退化。

  4. 確定事實事實是業務中的度量資料，如訂單金額、購買次數等。事實表中的每條記錄反映某一業務活動的度量結果。透過寬表設計適當冗餘重要欄位，以提高查詢效率。DWD層（資料明細層）以業務過程為驅動，而DWS層（彙總層）則是以需求為導向，與維度建模無直接關聯。

主題、主題域與維度模型

  • 主題資料倉儲中的資料組織圍繞不同的主題（如財務、銷售、客戶）展開。主題定義了資料倉儲的主要分析方向，每個主題對應一個業務分析領域。例如，“財務分析”是一個主題，涵蓋收入、支出、盈利等指標。

  • 主題域主題域是多個相關主題的集合，便於資料的分層組織和分類管理。主題域的劃分應由業務部門與資料倉儲設計人員共同決定，考慮業務的關聯性和分析需求。例如，銷售主題域可包含訂單分析、客戶行為、廣告投放等主題。

主題域劃分原則

主題域的劃分邏輯可以基於不同的業務需求或部門需求：

  • 按業務過程：如電商平臺可設立“廣告域”、“客戶域”等主題域，進一步分為“庫存管理”、“銷售分析”等具體主題。

  • 按需求方：如財務部門的主題域可能包含“工資分析”、“投資回報分析”等內容。

  • 按功能或應用：如“朋友圈域”可包含使用者動態、廣告資料等，適用於社交平臺資料的主題劃分。

  • 按部門：如運營域、技術域，分別涵蓋與各部門工作相關的主題（如運營域中的“活動效果分析”）。

主題域劃分不必一次性完成，可採用迭代方式，從確定的主題開始逐步擴充套件，最終形成符合行業標準的主題模型。

資料明細層（Data Warehouse Detail）

資料明細層（DWD）是資料倉儲和業務系統間的隔離層，主要用於提升資料的質量和一致性，確儲存儲的資料符合分析需求。

DWD層接收並清洗來自ODS層的原始資料，透過去噪、去重、脫敏等處理後，生成乾淨、準確的明細資料表，以支援業務分析。該層還會適度進行維度退化處理，將一些必要的維度欄位直接儲存在事實表中，以減少表關聯，提高查詢效能。

資料清洗與處理

DWD層的資料需要符合嚴格的資料質量標準，資料在裝入前進行多種處理：

1、資料清洗

  • 去除空值、髒資料：例如丟失關鍵欄位（如訂單ID為空）的記錄、格式錯誤的資料。

  • 敏感資料脫敏：對手機號、身份證等敏感資訊進行加密或脫敏處理。

  • 去除無效資料：如無時間戳的資料（視業務需求）。

  • 會話切割：如針對App日誌資料的場景，將使用者進入後臺再返回前臺的操作分割為新的會話，方便後續行為分析。

2、資料對映與轉換

  • 地理位置對映：將GPS經緯度轉換為省市區地址，採用geohash或IP地址轉換庫（如ip2region）進行快速定位，也可藉助高德、百度地圖API。

  • 時間標準化：將時間戳轉換為年、月、日、周、季度等資訊。

  • 資料規範化：對來自不同來源的資料進行格式統一，例如布林值（0/1轉換為true/false）、空值（統一為null）、日期格式（標準化為YYYY-MM-dd HH:mm:ss）。

3、 維度退化

對於一些高基數的維度欄位（如訂單ID），直接儲存在事實表中而不建立單獨的維度表。這些退化維度可以簡化資料結構，減少關聯，提升資料查詢的效率。

明細粒度事實表設計

DWD層以業務過程為核心進行建模，根據每個業務過程（如下單、支付、退款等）的特點，構建最細粒度的事實表。這些明細事實表保留了業務過程的全部細節，且一般會將一些常用的維度欄位冗餘儲存，採用寬表設計以提升效能。這些事實表也被稱為“邏輯事實表”。

資料質量控制

DWD層的資料粒度與ODS層保持一致，但在此基礎上提供更嚴格的資料質量保證。DWD層還會適度進行維度退化，例如將商品類別的多級維度（如一級、二級、三級類別）或時間、地域等常用維度直接儲存在事實表中，簡化關聯，提高資料的使用效率。

  • 清洗比例：對於大資料量的資料，建議清洗掉低於0.01%的資料，如每萬條記錄中去除一條不合規資料。

  • 表數量最佳化：透過合併相似資料，合理控制表數量，將過多的表精簡為更易管理的結構。例如，將上萬張表最佳化為三千張或一千張表，以便於後續的維護和擴充套件。

總結來說，DWD層在保持細粒度的前提下，提供規範化、清洗後的明細資料，為上層的業務應用和分析提供了乾淨、標準化的資料支撐。

這一層的最佳化和處理不僅提升了資料倉儲的效能，還顯著降低了資料冗餘，提高了資料的可用性和易用性。

明細粒度事實表設計原則

  1. 單維度關聯：每個明細粒度事實表只應與一個核心維度關聯，保持資料模型簡單、清晰。

  2. 業務過程相關性：僅包含與業務過程直接相關的事實資料，確保每個事實表準確反映其特定業務過程。

  3. 宣告粒度：在定義維度和事實之前，必須先明確資料粒度，即一行資料代表的具體業務意義。

  4. 一致性和可加性：確保事實的單位一致，且儘量將不可加的事實分解為可加性元件，以支援更廣泛的統計需求。

  5. 統一粒度：一個事實表中僅能包含單一粒度的事實資料，避免混合不同粒度的事實。

  6. 處理Null值：對Null值進行合理處理，以避免資料分析過程中產生意外結果。

  7. 退化維度應用：使用退化維度（如訂單ID等高頻維度）直接冗餘儲存在事實表中，以簡化資料表關聯，提升查詢效率。

資料處理與儲存方案

資料合成：採用全量合成策略，每天合併前天的全量資料和昨天的新增資料，生成一個新的資料表，覆蓋舊錶。同時，使用歷史映象按周、月或年儲存快照。

日誌儲存方式：使用Impala的外部表和Parquet檔案格式儲存日誌資料。建議在DWD層和下層資料均使用Impala內表，以實現更高效的靜態或動態分割槽管理。

分割槽設計：預設按天建立分割槽。如果資料沒有時間屬性，可根據業務需求選擇合適的分割槽欄位。

庫與表命名規範：庫名為dwd，表名格式建議為dwd_日期_業務表名。對於增量表和全量表，用i表示增量，f表示全量。例如：

  • dwd_asale_trd_ordcrt_trip_di：表示A電商公司航旅機票訂單下單的增量事實表，按日更新。

  • dwd_asale_itm_item_df：表示A電商公司商品快照的全量事實表，按日重新整理。

明細粒度事實表設計示例

  • 以交易商品資訊事實表（dwd_asale_trd_itm_di）為例：

CREATE TABLE IF NOT EXISTS dwd_asale_trd_itm_di
(
  item_id BIGINT COMMENT '商品ID',
  item_title STRING COMMENT '商品名稱',
  item_price DOUBLE COMMENT '商品價格',
  item_stuff_status BIGINT COMMENT '商品新舊程度_0全新1閒置2二手',
  item_prov STRING COMMENT '商品省份',
  item_city STRING COMMENT '商品城市',
  cate_id BIGINT COMMENT '商品類目ID',
  cate_name STRING COMMENT '商品類目名稱',
  commodity_id BIGINT COMMENT '品類ID',
  commodity_name STRING COMMENT '品類名稱',
  buyer_id BIGINT COMMENT '買家ID'
)
COMMENT '交易商品資訊事實表'
PARTITIONED BY (ds STRING COMMENT '日期')
LIFECYCLE 400;

此表設計為按天分割槽，資料儲存生命週期為400天，用於儲存每日更新的商品交易資訊。透過ds欄位管理資料的時間分割槽，便於查詢和管理。

資料服務層（Data Warehouse Service）

資料服務層（DWS）是基於資料明細層（DWD）構建的彙總層，面向特定業務主題，以寬表形式組織資料，支援分析和業務查詢。該層的資料根據不同的主題和分析需求，透過對明細資料進行輕度聚合而成，減少維度數量，以便進行快速、高效的查詢。

設計理念與結構

DWS層透過將DWD層的明細資料按主題域（如訂單、使用者、商品）進行彙總，為分析場景提供預處理的資料支援。資料粒度由細粒度提升至彙總粒度，以更適合多場景的業務查詢需求。例如，按交易來源或型別對交易資料進行彙總，可以快速生成每天各主題的行為統計，如商品復購率、使用者活躍度等。

特點和用途

  • 面向主題：DWS層按業務主題劃分資料，如銷售、庫存、客戶等，生成覆蓋多個指標的寬表。每張寬表通常包含較多欄位，支援複雜的業務分析與資料分發。

  • 少表寬表設計：DWS層表數量相對較少，每張寬表涵蓋多個業務內容，減少表關聯，提升OLAP分析和查詢效能。

  • 一致性整合：透過整合多箇中間層資料（如DWD層），形成一致的企業級彙總事實表（如使用者事實表、渠道事實表、終端事實表等），保證資料口徑的一致性。

資料聚合與彙總示例

  • 按天輕度彙總：基於DWD資料，對各主題物件（如購買行為）按天進行統計。例如，統計某商品的日復購率或銷售額，方便後續的時間序列分析。

  • 主題寬表示例：按照業務主題，生成具有較多欄位的寬表，用於業務查詢、OLAP分析等。例如，dws_sales_summary寬表可包含銷售額、復購率、使用者地域分佈等欄位。

  • 多層次分析：以不同維度進行彙總，如最近一天特定類目（如廚具）商品在各省的銷售總額，或者Top 10商品的銷售額，支援靈活的多維分析。

場景應用與效率提升

透過彙總層的預聚合，DWS層可以滿足80%的常見業務分析需求，減少直接查詢ODS層的計算壓力。例如，按7天、30天、90天等時間視窗的使用者行為分析在DWS層中可以更加高效。

  • 實時分析支援：對DWS層資料進行輕度彙總，有助於實現實時或準實時的使用者畫像、銷售趨勢分析等需求。

  • 典型分析場景：如使用者在不同時間段登入的IP及購買商品數量、各地區的購買力分佈等。這些分析支援業務決策和營銷策略調整。

命名和分割槽規範

  • 表命名規範：建議DWS層表名以dws_主題_寬表描述命名，如dws_sales_summary或dws_user_activity.

  • 分割槽設計：通常按天或周建立分割槽，便於時間序列查詢；若無時間屬性，則根據業務需求自定義分割槽欄位。

透過DWS層的資料彙總與主題劃分，企業可以在彙總寬表的基礎上，迅速提取核心業務指標，為上層業務查詢、報表和OLAP分析提供高效、結構化的資料支援。

資料服務層（DWS）職責與設計原則

DWS層（資料彙總層）基於DWD層的明細資料，按業務主題對資料進行聚合，以寬表形式儲存，支援業務查詢、OLAP分析和資料分發。

DWS層將多個DWD層表中分散的資料進行彙總，按主題整合到單一寬表中，例如使用者、訂單、商品、物流等。每張寬表涵蓋相關主題的多個維度和指標欄位，以滿足業務方的多維度分析需求。

DWS層的核心任務

  1. 主題彙總將DWD層的明細資料按照業務主題進行聚合，建立單獨的寬表。例如，在“使用者”主題下，使用者註冊資訊、收貨地址和徵信資料等內容可以整合到一張寬表中，方便後續的資料查詢和分析。

  2. 主題建模針對特定業務主題，如流量、訂單、使用者，構建資料模型，將相關資料從DWD層抽取並聚合。DWS層提供的寬表通常按時間分層，如按天、月彙總的流量會話、每日新增使用者、每日活躍使用者等。

  3. 維度彙總提前將查詢需求中的常用維度資料進行聚合處理。例如，將營銷渠道、使用者來源等維度資料提前整合，簡化後續的查詢邏輯。

設計規範

  • 寬表設計DWS層通常為每個主題提供1至3張寬表，寬表覆蓋多個業務指標，能夠滿足70%以上的業務需求。典型的寬表包括使用者行為寬表、商品寬表、物流寬表和售後寬表等。其中，使用者行為寬表是欄位最豐富的，可能包含60至200個欄位，以支援更全面的使用者分析。

  • 命名和分割槽規範

    1. 命名：DWS層表名以dws_開頭，後接業務主題和時間週期標識（如_1d代表每日彙總，_1w代表每週彙總）。

    2. 分割槽：通常按天或小時建立分割槽（如_hh表示小時分割槽），如無時間維度，則根據業務邏輯選擇分割槽欄位。

    3. 示例命名：

      1. dws_asale_trd_byr_subpay_1d：按買家粒度的交易分階段付款每日彙總。

      2. dws_asale_trd_itm_slr_hh：按賣家粒度的商品小時彙總。

  • 資料儲存DWS層資料採用Impala內表和Parquet檔案格式儲存，具備高效的查詢效能。一般以覆蓋舊錶的方式更新資料，定期生成歷史快照用於資料存檔和溯源分析。

典型的DWS寬表設計示例

  • 使用者維度寬表示例
CREATE EXTERNAL TABLE dws_sale_detail_daycount (
  user_id STRING COMMENT '使用者ID',
  user_gender STRING COMMENT '使用者性別',
  user_age STRING COMMENT '使用者年齡',
  user_level STRING COMMENT '使用者等級',
  buyer_nick STRING COMMENT '買家暱稱',
  mord_prov STRING COMMENT '地址',
  login_count BIGINT COMMENT '當日登入次數',
  cart_count BIGINT COMMENT '加入購物車次數',
  order_count BIGINT COMMENT '當日下單次數',
  order_amount DECIMAL(16,2) COMMENT '當日下單金額',
  payment_count BIGINT COMMENT '當日支付次數',
  payment_amount DECIMAL(16,2) COMMENT '當日支付金額',
  confirm_paid_amt_sum_1d DOUBLE COMMENT '最近一天訂單已確認收貨的金額總和',
  order_detail_stats ARRAY<STRUCT<sku_id:STRING, sku_num:BIGINT, order_count:BIGINT, order_amount:DECIMAL(20,2)>> COMMENT '下單明細統計'
)
COMMENT '每日購買行為'
PARTITIONED BY (`dt` STRING)
STORED AS PARQUET
LOCATION '/warehouse/gmall/dws/dws_sale_detail_daycount/'
TBLPROPERTIES("parquet.compression" = "lzo");

  • 商品維度寬表示例
CREATE TABLE IF NOT EXISTS dws_asale_trd_itm_ord_1d (
  item_id BIGINT COMMENT '商品ID',
  item_title STRING COMMENT '商品名稱',
  cate_id BIGINT COMMENT '商品類目ID',
  cate_name STRING COMMENT '商品類目名稱',
  confirm_paid_amt_sum_1d DOUBLE COMMENT '最近一天訂單已確認收貨的金額總和'
)
COMMENT '商品粒度交易最近一天彙總事實表'
PARTITIONED BY (ds STRING COMMENT '分割槽欄位YYYYMMDD')
LIFECYCLE 36000;

ADS資料應用層

資料應用層（（ADS，Application Data Store）用於儲存個性化的統計指標和報表資料，為資料產品、業務應用和資料分析提供專門的資料支援。

ADS層的資料是高度彙總或定製化的資料集，覆蓋流量、訂單、使用者等主題，以寬表形式儲存，支援多維分析、查詢、資料分發等。該層的資料粒度通常較粗，涵蓋彙總資料和部分重要的明細資料，滿足使用者對近期資料的分析需求。

ADS層的核心功能

  1. 應用場景定製在DWS層基礎上，面向應用場景進一步聚合資料，生成高定製化的寬表（如使用者行為、訂單趨勢）。這些資料可以直接供業務系統呼叫或匯入至應用系統（如MySQL、Redis、Druid）中，用於前端展示、實時查詢和分析。

  2. 滿足部門需求ADS層的資料按業務部門需求進行劃分，僅包含與部門分析相關的資料子集。例如，流量資料集市提供流量分析指標，使用者資料集市提供活躍度、轉化率等使用者行為資料，為業務方提供更直觀的分析資料。

  3. 資料集市和寬表支援資料集市在ADS層按主題劃分，如流量、訂單、使用者等，生成欄位豐富的寬表。這些寬表彙總了各類業務指標和維度，支援多種分析需求，廣泛用於OLAP分析、KPI展示和業務監控。

資料生成和儲存方式

  • 資料生成ADS層的資料來源於DWD和DWS層，按業務需求從這些基礎層資料中抽取並加工。ADS層表的資料更新頻率依賴於業務需求，可以是每日或每小時重新整理。

  • 儲存與分割槽使用Impala內表和Parquet格式儲存ADS資料，按天或業務欄位進行分割槽，以最佳化查詢效率。對於沒有時間屬性的表，根據具體業務選擇適當的分割槽欄位。

  • 表命名規範庫名暫定為ads，表名格式建議為ads_主題_業務表名，按業務需求進行定製。

資料應用層示例

  • 使用者行為寬表用於儲存使用者的互動、消費等行為資料，包含各類使用者活動資訊，如評論、點贊、收藏、分享、GMV等欄位。每張寬表大約包含60-200個欄位，滿足多維度的使用者分析需求。

CREATE TABLE app_usr_interact (
  user_id STRING COMMENT '使用者ID',
  nickname STRING COMMENT '使用者暱稱',
  register_date STRING COMMENT '註冊日期',
  register_from STRING COMMENT '註冊來源',
  remark STRING COMMENT '細分渠道',
  province STRING COMMENT '註冊省份',
  pl_cnt BIGINT COMMENT '評論次數',
  ds_cnt BIGINT COMMENT '打賞次數',
  sc_add BIGINT COMMENT '新增收藏',
  sc_cancel BIGINT COMMENT '取消收藏',
  gzg_add BIGINT COMMENT '關注商品',
  gzg_cancel BIGINT COMMENT '取消關注商品',
  zhi_cnt BIGINT COMMENT '點贊次數',
  share_cnts BIGINT COMMENT '分享次數',
  bl_cnt BIGINT COMMENT '爆料數',
  gmv_amount BIGINT COMMENT '成交金額',
  gmv_sales BIGINT COMMENT '訂單數'
)
PARTITIONED BY (dt STRING)
STORED AS PARQUET;
  • 商品銷售彙總表

彙總商品的銷售資料，按日或更細粒度進行儲存，為分析商品的銷售趨勢、庫存管理等提供支援。

CREATE TABLE IF NOT EXISTS dws_asale_trd_itm_ord_1d (
  item_id BIGINT COMMENT '商品ID',
  item_title STRING COMMENT '商品名稱',
  cate_id BIGINT COMMENT '商品類目ID',
  confirm_paid_amt_sum_1d DOUBLE COMMENT '訂單確認收貨的金額總和'
)
PARTITIONED BY (ds STRING COMMENT '分割槽欄位YYYYMMDD')
LIFECYCLE 36000;

常用分析指標與應用場景

  1. 使用者活躍度

    1. 日活、周活、月活：統計使用者的活躍頻率，透過裝置ID計算不同時間範圍內的活躍使用者。

    2. 留存率：統計新增使用者的留存情況，計算1天、7天等時間範圍內的使用者留存率。

  2. 使用者增長與迴流

    1. 新增使用者：基於每日新增使用者的統計。

    2. 迴流使用者：分析在一段時間內迴歸活躍的使用者數量。

  3. 使用者轉化與行為分析

    1. 轉化率：從商品詳情到下單、支付的轉化率。

    2. 復購率：按使用者或商品的復購情況統計，支援商品或品類的復購趨勢分析。

  4. 商品分析

    1. 銷售額和GMV：按商品或品類計算銷售額和GMV，分析熱銷產品。

    2. Top N商品：計算銷售排名前N的商品，支援流行度和消費偏好的分析。

  5. 使用者留存與流失分析

    1. 沉默使用者：統計登入時間為7天前且登入頻率極低的使用者。

    2. 流失使用者：識別近期未登入或活躍度降低的使用者，便於後續的使用者運營和召回策略。

資料應用層的角色與更新策略

  • 應用層角色ADS層主要面向業務方和資料產品團隊，資料經過多層處理和彙總後直接支援報表、KPI、OLAP分析和儀表盤等應用。作為面向終端使用者的資料集市，ADS層能夠快速響應業務需求。

  • 更新方式舊資料通常採用覆蓋更新，按業務需求定期重新整理，確保資料時效性。

臨時表支援

  • TMP層資料處理過程中常需臨時表以支援複雜計算，ADS層提供獨立的TMP層（DW TMP）用於儲存這些中間計算結果，避免主資料表的反覆更新，提高資料處理的效率和穩定性。

透過ADS層的資料集市和寬表設計，企業能夠更靈活地支援多種資料產品和分析需求，為業務增長、使用者行為分析、市場洞察等提供強有力的資料支撐。

層次呼叫規範

在資料倉儲分層架構中，必須遵循嚴格的呼叫規範，以確保資料流動的單向性，避免複雜的依賴關係和反向呼叫。

  • 禁止反向呼叫：下層資料不可呼叫上層資料，保持資料流向的單向性和清晰性。

  • 呼叫規範：

    • ODS層：僅允許被DWD層呼叫。

    • DWD層：允許被DWS和ADS層呼叫。

    • DWS層：僅允許被ADS層呼叫。

    • ADS層：可呼叫DWD、DWS及其他ADS表，但建議優先使用匯總度更高的資料，以減少資料冗餘和效能消耗。

呼叫路徑概述

資料的標準呼叫路徑包括：

  • ODS -> DWD -> DWS -> ADS

  • ODS -> DWD -> ADS

資料倉儲技術趨勢與小結

資料倉儲分層架構為企業構建了高效、穩定的海量資料管理體系，支援資料治理、業務邏輯隔離、資料追蹤和複用。透過ODS、DWD、DWS和ADS的分層設計，資料在逐層傳遞和加工中實現標準化和清洗，確保了一致性和資料可追溯性。

這一架構不僅提高了資料使用的規範性，還降低了系統耦合，提升了資料共享的便捷性。

  • ODS層：作為原始資料接入層，ODS層負責保留細粒度資料，透過ETL或CDC方式捕獲源系統的變更資料，確保資料完整性。

  • DWD層：標準化資料並進行清洗和脫敏，去除冗餘，確保資料一致性，為後續分析和建模提供了基礎。

  • DWS層：將DWD資料聚合為符合業務主題的寬表，構建面向主題的資料服務，最佳化計算效能並促進資料複用。

  • ADS層：進一步聚合資料，生成高效能、面向應用的寬表，支援資料產品和業務應用場景，如OLAP分析、KPI監控和儀表盤展示。

隨著資料規模和資料來源的多樣化，資料倉儲的架構和技術也在不斷演進，當前的主要趨勢包括：

  1. 實時資料處理與CDC技術傳統的批次資料處理已經無法滿足現代企業的需求，CDC技術成為資料實時同步和更新的主流方法，確保資料倉儲中資料的實時性。

  2. 資料湖與資料倉儲的融合資料湖（Data Lake）與資料倉儲的融合正在成為行業的熱門趨勢，例如Data Lakehouse架構，將資料湖的靈活性與資料倉儲的高效分析能力相結合，為企業提供更強的資料管理能力。

  3. DataOps與自動化資料管理隨著企業對資料管理自動化要求的提高，DataOps逐漸成為資料管理的核心工具。例如，白鯨開源的DataOps工具能夠實現從資料採集到資料質量控制的全流程自動化管理。

結合新一代資料湖倉（Hudi、Iceberg、GaussDB、Redshift、Greenplum、Doris、Starrocks、偶數、PieDB、MatrixDB等）配合白鯨開源的DataOps工具，可以快速根據本文的設計實踐建立起批流一體的資料湖倉。

整體上，無論是湖、倉、實時數倉、都要遵循分層設計架構明確了各層的呼叫邊界，禁止反向呼叫，確保資料流動順暢，降低了系統複雜度。

白鯨開源的WhaleStudio以DolphinScheduler和SeaTunnel為基礎，增加大量商業版功能，全面支援資料倉儲分層的批流資料的整合與資料開發，在中國銀行、中信證券、中信建投證券、中國人保、中國人壽、旺旺集團等都有實際DataOps案例，並全面替換Informatica和Talend等傳統ETL工具。

為當前業務和未來擴充套件提供了穩定、高效的資料支援。結構化的資料流轉路徑為企業的數字化轉型和資料驅動決策提供了強有力的支援，推動業務的智慧化和資料化發展。

結語

資料倉儲的分層設計和模型方法為企業提供了強大的資料管理能力，不僅能夠應對複雜的業務需求變化，還能在保障系統穩定性和資料質量的同時提升運營效率。

透過合理分層，資料倉儲可以高效地儲存、處理和分析資料，實現資料價值的最大化。

感謝您閱讀本手冊的每一部分，希望這些內容對您構建現代化資料倉儲體系有所幫助。透過三部分的系統性講解，相信您已經對資料倉儲的四層架構及其應用有了更深的理解。請繼續關注我們的更多技術分享，與我們一起探索資料驅動的未來。

本文由 白鯨開源 提供釋出支援！

相關文章