一、數倉分層

在數字化時代，企業面臨著海量數據的挑戰，如何高效地管理和利用這些數據成為了關鍵。數據倉庫作為企業數據存儲、處理和分析的核心平臺，其重要性日益凸顯。而數倉建設的分層架構設計，則是提升數據倉庫效能、優化數據處理流程的重要保障。通過合理的分層架構，可以將復雜的數據處理任務分解為多個簡單的步驟，提高數據處理效率、增強數據可擴展性、便于數據管理和維護，同時優化查詢性能，為企業的決策提供更有力的支持。

二、數倉分層架構的基本概念

1. 定義

數倉分層架構是結合對業務場景、實際數據、使用系統的綜合分析，對數據模型進行的整體架構設計及層級劃分。它將數據倉庫劃分為不同的邏輯層次，每個層次負責特定的數據處理任務，使得數據在各層之間有序流轉，從而實現數據的高效管理和利用。

2. 常見分層方式

(1) 經典四層架構（最廣泛應用）

• ODS（Operation Data Store） - 操作數據存儲層：也稱為原始數據層或貼源層，存放未經過處理的原始數據至數據倉庫系統，結構上與源系統保持一致，是數據倉庫的數據準備區。主要完成基礎數據引入到數據倉庫的職責，同時記錄基礎數據的歷史變化。例如，某電商平臺將訂單系統、用戶系統等業務系統中的原始數據同步到 ODS 層，為后續的數據處理提供原材料。
• DWD（Data Warehouse Detail） - 數據倉庫明細層：對 ODS 層的數據進行清洗、轉換和整合，生成高質量的明細數據。該層以業務過程作為建模驅動，基于每個具體的業務過程特點，構建最細粒度的明細層事實表。可以結合企業的數據使用特點，將明細事實表的某些重要維度屬性字段做適當冗余，即寬表化處理。比如，對 ODS 層中的訂單數據進行清洗，去除無效數據、規范字段格式，同時關聯用戶維度信息，生成訂單明細寬表。
• DWS（Data Warehouse Summary） - 數據倉庫匯總層：基于 DWD 層的數據，按照業務需求進行聚合和匯總，生成寬表或主題表。以分析的主題對象作為建模驅動，基于上層的應用和產品的指標需求，構建公共粒度的匯總指標事實表，以寬表化手段物理化模型。構建命名規范、口徑一致的統計指標，為上層提供公共指標，建立匯總寬表。例如，按天對訂單明細數據進行匯總，統計每個用戶的訂單數量、訂單金額等指標，生成用戶訂單日匯總表。
• ADS（Application Data Service） - 數據應用層：面向最終業務需求，提供高度聚合的數據，直接支持報表、分析和應用。存放數據產品個性化的統計指標數據，根據 CDM 與 ODS 層加工生成。該層的數據高度定制化，直接為業務需求服務，具有業務邏輯的強約束性。比如，根據 DWS 層的匯總數據，生成面向運營人員的銷售報表、用戶留存率報表等，為業務決策提供支持。

(2) 阿里五層模型

在四層基礎上增加 DIM（維度層）和 DWM（中間層）：

• DIM（維度層）：基于維度建模理念思想，建立整個企業的一致性維度。降低數據計算口徑和算法不統一風險。公共維度層的表通常也被稱為邏輯維度表，維度和維度邏輯表通常一一對應。例如，建立商品維度表、用戶維度表、時間維度表等，為數據倉庫中的事實表提供維度信息。
• DWM（中間層）：在 DWD 層的數據基礎上，對數據做一些輕微的聚合操作，生成一系列中間結果表，提升公共指標的復用性，減少重復加工的工作。例如，對 DWD 層中的訂單明細數據按商品類別進行輕度聚合，統計每個商品類別的訂單數量、訂單金額等指標，生成商品類別中間表，為 DWS 層的匯總提供基礎。

(3) 三層簡化架構

適用于初創公司或簡單業務：

• ODS：數據接入，存儲從業務系統中直接采集的原始數據。
• DW：整合建模（合并 DWD/DWS），完成數據的清洗、轉換和聚合，構建數據倉庫的核心模型。
• APP：應用集市，面向具體的業務應用，提供數據服務。

三、數倉分層架構的原因

1. 數據解耦與模塊化

通過分層，可以將復雜的數據處理流程解耦為多個獨立的部分，每一層處理特定的數據任務。這使得數據處理更加模塊化，便于開發、維護和功能更迭。同時，分層架構使得數據血緣關系更加清晰，便于問題定位和避免重復計算。例如，當源業務系統的業務規則發生變化時，只需調整 ODS 層或 DWD 層的數據處理邏輯，而無需對整個數據倉庫進行重構。

2. 提升數據處理效率

數據倉庫通常包含多個來源的數據，且需要經過多個處理階段，如數據抽取、數據清洗、數據轉換和數據加載等。將數據按照層次結構組織，可以提高處理效率，減少數據重復處理和多次掃描的問題。通過預計算、維度退化、數據聚合等手段，將數據按照預期的功能進行冗余存儲，實現以空間換時間的目的，從而滿足不同使用場景和數據粒度的需求。比如，在 DWS 層進行數據的預聚合，減少了上層應用在查詢時的計算量，提高了查詢性能。

3. 增強數據可擴展性

當源業務系統的業務規則發生變化時，只需調整相應層次的數據處理邏輯，而無需對整個數據倉庫進行重構。這有助于降低維護成本，提高數據倉庫的可擴展性。例如，隨著業務的發展，需要增加新的數據源或業務指標，只需在相應的層次進行擴展和調整即可。

4. 便于數據管理和維護

分層建設使得數據倉庫中的數據更加有序，便于進行數據備份、數據恢復和數據歸檔等管理操作。同時，不同層次的數據可以采用不同的安全措施，提高數據的安全性。例如，對 ODS 層的數據進行全量備份，對 DWS 層和 ADS 層的數據進行定期備份；對敏感數據在 DWD 層進行脫敏處理，確保數據的安全性。

5. 優化查詢性能

數據倉庫中的數據通常需要進行復雜的分析和查詢。將數據按照層次結構組織可以優化查詢路徑，減少數據掃描和查詢時間，提高查詢性能。例如，上層應用在進行數據分析時，可以直接從 DWS 層或 ADS 層獲取已經匯總好的數據，避免了從大量的明細數據中進行查詢和計算。

四、數倉建設分層架構過程中的注意要點

1. 架構規范

(1) 明確分層原則

通常遵循自下而上的 ODS、DWD、DWS、ADS 架構，各層有明確的作用和職責。ODS 近乎原樣存儲從源系統抽取的數據，起到緩沖和備份源數據作用；DWD 對 ODS 數據初步清洗、標準化，為上層提供統一格式明細數據；DWS 按照主題域聚合 DWD 數據，如按銷售、財務等主題匯總，提供分析型數據；ADS 面向具體業務應用，如報表、數據挖掘需求定制數據。例如，在設計數倉架構時，要明確每個層次的功能定位，避免層次之間的職責混淆。

(2) 數據流向清晰

嚴格規定各層數據單向流動，禁止跨多層回溯調用，一般只允許相鄰層間交互，即 ODS -> DWD -> DWS -> ADS，確保數據處理流程有序，易于維護與追蹤。比如，ADS 層的數據只能從 DWS 層獲取，不能跨越 DWS 層直接從 DWD 層或 ODS 層獲取數據。

2. 層間調用規范

(1) 下層服務上層

下層數據層為直接上層提供數據支撐，上層只能從緊鄰下層獲取所需數據，不能跨層調用。例如 DWS 層構建的銷售主題匯總數據，供 ADS 層銷售報表應用直接使用，而不能從 ODS 層跨越 DWD 層直接取用原始銷售數據。

(2) 接口標準化

相鄰層間數據交互接口需統一規范，包括數據格式（如日期統一為“YYYY-MM-DD”）、傳輸協議（常用 HTTP、FTP 等），確保不同層開發團隊協作順暢，數據傳輸穩定高效。

3. 需求實現方案規范

(1) 基于分層設計

接到業務需求，首先分析應在數倉哪一層實現，如簡單報表需求多在 ADS 層通過關聯已有匯總數據快速滿足；復雜分析需求可能需從 DWD 層開始重新聚合、加工數據。例如，對于簡單的日報表需求，可以直接從 ADS 層獲取已經匯總好的數據進行展示；對于復雜的多維度分析需求，則需要從 DWD 層的數據開始進行重新計算和聚合。

(2) 方案評審

需求實現方案需組織跨團隊評審，涵蓋業務、開發、運維等人員，確保方案既滿足業務目標，又遵循架構規范，不破壞已有數據生態，如評估新方案對數據存儲、計算資源的影響。

4. 模型規范

(1) 模型設計規范

• 主題域劃分：依據業務核心流程，劃分如客戶、產品、訂單、財務等主題域，每個主題域獨立建模，便于管理與理解。例如在客戶主題域，圍繞客戶基本信息、購買行為、忠誠度等構建實體關系模型。
• 采用星型/雪花型架構：事實表處于中心，關聯多個維度表。星型架構維度表直接與事實表連接，簡潔高效，適用于快速查詢場景；雪花型架構維度表有層級細分，規范化程度高，適合復雜分析，依業務需求權衡選用。

(2) 模型命名規范

• 統一前綴：不同層級模型采用特定前綴區分，如 DWD 層模型前綴為“dwd_”，DWS 層為“dws_”，便于識別與管理，像“dwd_sales_detail”表明是明細數據層銷售明細模型。
• 表意清晰：名稱包含業務主體與關鍵信息，如“dws_financial_report_monthly”能直觀反映是財務主題、月度匯總報表模型，方便開發、運維人員快速定位。

(3) 詞根管理規范

• 建立詞根庫：梳理業務常用術語，提煉詞根，如“sale”代表銷售、“cust”代表客戶，所有相關模型、字段命名盡量基于這些詞根拓展，保證語義連貫性。
• 定期維護：隨著業務發展，新術語涌現，定期更新詞根庫，確保命名體系與時俱進，同時回溯審查已有模型命名，必要時調整優化。

(4) 指標體系建設規范

• 指標定義統一：對業務關鍵指標，如銷售額、利潤率、客戶留存率等，明確定義計算口徑、時間范圍、數據來源，確保不同報表、分析場景下指標含義一致。例如，銷售額定義為含稅訂單金額，統計周期為自然月。
• 分層構建：底層指標基于明細數據計算，為上層復合指標提供支撐，像日銷售額是基礎指標，月銷售額可由日銷售額匯總得到，構建層次分明的指標體系，滿足不同業務深度需求。

5. 流程規范

(1) 需求承接規范

• 需求收集：主動與業務部門溝通，定期組織需求調研會，通過問卷調查、業務訪談等形式，全方位收集數據需求，包括報表需求、數據分析需求、數據挖掘需求等。
• 需求文檔化：將收集到的需求整理成詳細規范的文檔，涵蓋需求背景、目標、詳細功能描述、預期交付時間等，便于后續開發、測試、驗收環節對照執行，避免需求模糊引發項目風險。

(2) 運維機制規范

• 監控體系：建立全方位數據監控，包括數據質量（準確性、完整性、一致性）監控，通過數據校驗規則比對；任務執行狀態監控，實時查看 ETL 任務、數據處理任務是否成功執行，利用工具如 Zabbix、Prometheus 實現可視化監控。
• 故障應急：制定詳細故障應急預案，依據故障影響范圍、嚴重程度分級，不同級別啟動相應處理流程，從故障發現、通知責任人到恢復系統正常運行各環節明確時間節點與操作步驟，如數據延遲故障，5 分鐘內發現通知，30 分鐘內定位修復。

(3) 上線流程規范

• 預上線測試：在正式上線前，進行多輪測試，包括單元測試，開發人員自測代碼功能；集成測試，模擬真實業務場景，檢驗不同模塊、組件協同工作能力；用戶驗收測試，邀請業務用戶驗證是否滿足需求，所有測試通過方可進入下一步。
• 灰度上線：對于重大變更或新功能，采用灰度上線策略，先在小部分用戶或業務場景試用，收集反饋，確認無誤后逐步擴大范圍，降低整體上線風險。

(4) 模型設計流程規范

• 業務調研：深入了解業務需求、流程，與業務專家溝通，確定模型服務的業務場景、目標，如為精準營銷構建客戶畫像模型，需調研營銷流程與客戶特征需求。
• 設計文檔：依據調研結果，撰寫詳細模型設計文檔，包括模型架構圖、實體關系圖、字段定義、數據來源、預期性能指標等，作為后續開發依據，并在團隊內部評審，確保設計合理性。

6. 管理規范

(1) 監控告警規范

• 告警閾值設定：針對數據質量、任務執行等監控指標，結合業務容忍度與歷史數據波動，設定合理告警閾值。如數據準確性低于 95%、任務延遲超過 10 分鐘觸發告警，確保問題能及時被發現。
• 告警渠道：利用多種渠道發送告警，如郵件、短信、企業即時通訊工具，優先選擇能及時觸達責任人的方式，且告警信息包含問題描述、影響范圍、緊急程度、建議處理措施等，便于快速響應。

(2) 存儲管理規范

• 分區策略：根據數據特性，如時間序列數據按年、季、月、日分區；地域數據按地區分區，便于數據查詢、管理，減少全表掃描，提高查詢效率，如查詢某季度銷售數據，直接定位季度分區即可。
• 存儲介質選型：熱數據（近期頻繁訪問）優先選用高性能關系型數據庫，如 Oracle、MySQL；冷數據（歷史久遠、訪問少）考慮分布式存儲，如 Hadoop HDFS，平衡存儲成本與訪問效率。

(3) 數據安全管理規范

• 訪問權限控制：基于角色的訪問控制（RBAC），為不同崗位人員（如業務分析師、開發人員、運維人員）設定不同權限，業務分析師只能查詢 ADS 層報表數據，開發人員有權限修改開發層模型數據，防止越權訪問。
• 數據脫敏：對敏感數據，如客戶身份證號、銀行卡號，在非必要場景進行脫敏處理，采用哈希、替換等方法，保證數據可用性同時保護隱私，如身份證號保留前 6 位和后 4 位，中間用星號代替。

五、特殊場景下數倉建設分層架構的處理方法

1. 小型團隊或簡單業務

適用場景為數據量小（如日增量<GB 級）、業務邏輯簡單（如僅需幾張報表）。此時省去分層設計的開發和管理成本，可快速交付。但業務擴展后可能面臨重構壓力。例如，某創業公司初期業務簡單，數據量較小，直接從原始數據層進行簡單的數據處理和報表生成，滿足業務需求。隨著業務的發展，數據量和業務復雜度增加，再考慮對數據倉庫進行分層設計和重構。

2. 實時數據流處理

適用于需要實時響應的場景（如監控、風控），數據直接從消息隊列（如 Kafka）寫入 OLAP 引擎（如 Doris）。使用流式處理（Flink）+ 實時數倉（如 ClickHouse），跳過傳統分層。例如，某金融機構的實時風控系統，通過 Flink 對 Kafka 中的實時交易數據進行實時處理和分析，將結果直接寫入 ClickHouse 供實時查詢和監控。

3. 探索性分析或臨時需求

適用于臨時數據探查、PoC 驗證，可直接在原始數據層（ODS）或數據湖中操作。通過 Trino、Spark SQL 直接查詢原始數據，快速輸出結果。例如，數據分析師在進行新的業務分析探索時，直接從 ODS 層的數據中進行查詢和分析，無需對數據進行復雜的處理和分層。

4. 現代架構的演進

(1) Data Lakehouse

結合數據湖的靈活性和數倉的管理能力（如 Delta Lake、Iceberg），部分場景可替代分層。Data Lakehouse 可以存儲各種類型的數據，包括結構化、半結構化和非結構化數據，同時支持數據的管理和分析。例如，某企業使用 Delta Lake 構建 Data Lakehouse，將原始數據存儲在 Delta Lake 中，同時通過 SQL 進行數據的查詢和分析，無需進行復雜的分層架構設計。

(2) Serverless 查詢引擎

如 BigQuery、Snowflake，通過虛擬化層自動優化查詢，降低對分層的依賴。這些 Serverless 查詢引擎可以根據查詢需求自動分配計算資源，無需用戶進行復雜的資源管理和分層設計。例如，某公司使用 Snowflake 進行數據查詢和分析，Snowflake 會自動對查詢進行優化，提高查詢性能。

5. 實時數倉場景

(1) 即席查詢

實時要求非常高，要求寫入即可查，更新即反饋，有即席查詢需求，且資源較為充足，查詢復雜度較低。將操作層（ODS 層）的數據經過簡單的清理、關聯，然后存儲到明細數據，暫不做過多的二次加工匯總，明細數據直接寫入 Hologres。Flink 加工增量數據，實時更新明細數據至 Hologres，MaxCompute 加工后的離線表寫入 Hologres。因為上層的分析 SQL 無法固化，在 CDM/ADS 層以視圖（View）封裝成 SQL 邏輯。上層應用直接查詢封裝好的 View，實現即席查詢。例如，某電商平臺的實時數據分析系統，對用戶的實時行為數據進行即席查詢和分析，通過上述架構實現快速響應和靈活查詢。

(2) 分鐘級準實時

有實時需求，以分析為主，實時性滿足分析時數據在業務場景具備實時含義，不追求數據產生到分析的秒級絕對值，但開發效率優先。將操作層（ODS 層）的數據經過簡單的清理、關聯，然后存儲到明細數據，暫不做過多的二次加工匯總，明細數據直接寫入 Hologres。Flink 加工增量數據實時更新明細數據至 Hologres。CDM/ADS 層為實際的物理表，通過 DataWorks 等調度工具調度周期性寫入數據。前端實時請求實際的物理表，數據的實時性依賴 DataWorks 調度周期配置，例如 5 分鐘調度、10 分鐘調度等，實現分鐘級準實時。比如，某企業的運營監控系統，對業務數據進行分鐘級的實時分析和監控，采用該方案平衡了時效性與開發效率。

(3) 增量數據實時統計

實時需求簡單、數據更新少、只需要增量數據即可統計結果，以大屏和風控等在線服務場景為主，需要數據產生到分析盡量實時，可以接受一定開發效率的降低和計算成本的上升。增量計算的數據由 Flink 進行清洗加工轉換和聚合匯總，ADS 層應用數據存儲在 Hologres 中。Flink 加工的結果集采取雙寫的方式，一方面繼續投遞給下一層消息流 Topic，一方面 Sink 到同層的 Hologres 中，方便后續歷史數據的狀態檢查與刷新。在 Flink 內通過增量流、增量流連接靜態維表、增量流連接增量流這三種場景統計出數據，寫入 Hologres。Hologres 通過表的形式直接對接上層應用，實現應用實時查詢。例如，某金融機構的實時風控大屏，對交易數據的增量進行實時統計和展示，采用該方案滿足了實時性要求。