告訴我！數據倉庫 DWD 層怎么建？
作者：甜獲師兄
DWD（Data Warehouse Detail）層是數據倉庫的核心加工區域，承擔著將原始數據轉換為可用分析數據的重要職責。
DWD（Data Warehouse Detail）層是數據倉庫體系中的明細數據層，位于ODS（Operational Data Store，原始數據層）之上，DIM（維度層）和DWS（數據服務層）之下。它是數據倉庫的核心加工區域，承擔著將原始數據轉換為可用分析數據的重要職責。
DWD層的主要特點是：
- 面向主題：按業務領域進行數據組織
- 粒度統一：保持相同業務過程的數據粒度一致
- 結構規范：字段命名和定義遵循統一標準
- 歷史完整：保留歷史變更數據，確保可追溯性
一、DWD層建設的基本思路
1. 業務分域設計
DWD層首先應該按照業務域（Domain）進行劃分，常見的業務域包括：用戶域：用戶基礎信息、注冊、登錄、地址等
- 商品域：商品、類目、品牌等基礎數據
- 交易域：訂單、支付、退款等交易過程數據
- 流量域：點擊、曝光、跳出等用戶行為數據
- 營銷域：活動、優惠券、秒殺等營銷數據
- 庫存域：庫存、倉儲等供應鏈數據
- 互動域：評論、收藏、分享等社交數據
這種分域方式讓數據架構更清晰，方便不同業務部門使用自己關心的數據。
2. 明確數據模型類型
DWD層主要包含兩類數據模型：
- 事實表：記錄業務事件，通常包含度量值和外鍵
- 維度表：描述業務對象的屬性，如用戶、商品、時間等
根據數據更新方式，DWD表可以分為：
- 全量表（Full）：每次加載會覆蓋所有歷史數據
- 增量表（Inc）：只加載新增或變化的數據
- 拉鏈表：記錄數據的歷史變更，保留所有版本信息
3. 數據加工規范
DWD層的數據加工遵循以下規范：字段規范：統一字段命名和數據類型，如id、create_time等
- 數據清洗：處理空值、異常值、重復值等
- 數據轉換：類型轉換、編碼轉換、格式標準化
- 數據整合：關聯多個來源的數據，豐富信息維度
- 指標計算：生成基礎派生指標
4. 分區與性能優化
為提高查詢效率，DWD層通常采用分區策略：
- 按時間分區：最常見的方式，如按天分區（k1字段）
- 按業務分區：某些場景下按業務線或地區分區
- 復合分區：時間+業務的組合分區策略
二、DWD層建設實踐案例 - 用戶地址表設計與實現
下面以dwd_user_address_full表為例，詳細說明DWD層表的設計和實現過程。
1. 需求分析
用戶地址信息是電商系統的重要基礎數據，需要支持：
- 用戶歷史地址查詢
- 配送范圍分析
- 區域銷售分布統計
2. 數據源分析
從ODS層，我們有兩個相關表：
- ods_user_address_full：用戶地址基本信息
- ods_base_province_full：省份信息
通過分析表結構，發現：
- 用戶地址表包含用戶ID、省份ID等基本信息
- 省份表包含省份名稱、地區編碼等信息
- 缺少專門的城市和區縣表
3. 表結構設計
CREATE TABLE dwd.dwd_user_address_full
(
`id` VARCHAR(255) COMMENT '地址ID',
`k1` DATE COMMENT '數據日期',
`user_id` STRING COMMENT '用戶ID',
`province_id` STRING COMMENT '省份ID',
`province_name` STRING COMMENT '省份名稱',
`city_id` STRING COMMENT '城市ID',
`city_name` STRING COMMENT '城市名稱',
`district_id` STRING COMMENT '區縣ID',
`district_name` STRING COMMENT '區縣名稱',
`detail_address` STRING COMMENT '詳細地址',
`consignee` STRING COMMENT '收貨人',
`phone_num` STRING COMMENT '聯系電話',
`is_default` STRING COMMENT '是否默認地址',
`create_time` DATETIME COMMENT '創建時間',
`operate_time` DATETIME COMMENT '操作時間',
`postal_code` STRING COMMENT '郵政編碼',
`full_address` STRING COMMENT '完整地址'
)
ENGINE=OLAP
UNIQUE KEY(`id`, `k1`)
DISTRIBUTED BY HASH(`id`);4. ETL實現
-- 用戶域用戶地址全量表
INSERT INTO dwd.dwd_user_address_full(id, k1, user_id, province_id, province_name,
city_id, city_name, district_id, district_name, detail_address, consignee,
phone_num, is_default, create_time, operate_time, postal_code, full_address)
select
ua.id,
date('${pdate}') as k1, -- 使用參數日期作為k1值
ua.user_id,
ua.province_id,
bp.name as province_name,
ua.city_id,
bp.area_code as city_name, -- 這里假設使用area_code作為城市名稱，實際應根據實際情況調整
ua.district_id,
bp.iso_code as district_name, -- 這里假設使用iso_code作為區域名稱，實際應根據實際情況調整
ua.user_address as detail_address, -- 將user_address字段映射為detail_address
ua.consignee,
ua.phone_num,
ua.is_default,
now() as create_time, -- 使用當前時間作為create_time
now() as operate_time, -- 使用當前時間作為operate_time
null as postal_code, -- 暫無此數據，可根據實際情況調整
concat(bp.name, ' ', bp.area_code, ' ', bp.iso_code, ' ', ua.user_address) as full_address -- 完整地址拼接
from
(
select
id,
user_id,
province_id,
province_id as city_id, -- 暫用province_id代替city_id
province_id as district_id, -- 暫用province_id代替district_id
user_address,
consignee,
phone_num,
is_default
from ods.ods_user_address_full
) ua
left join
(
select
id,
name,
area_code,
iso_code
from ods.ods_base_province_full
) bp
on ua.province_id = bp.id;三、DWD層建設的經驗總結
- 統一規范先行：在開始建設前，制定統一的命名規范和數據標準
- 分階段建設：先搭建核心業務域，后擴展其他業務域
- 靈活處理數據缺失：面對不完美的數據源，使用合理的替代方案
- 重視文檔和注釋：詳細記錄表結構、字段含義和處理邏輯
- 持續優化：隨著業務發展，不斷完善DWD層數據模型
責任編輯：趙寧寧
來源：
大數據技能圈
