數據建模是數據開發體系中的核心環節，它直接決定數據資產質量、可維護性、複用能力，以及最終對業務價值的支撐能力。建模不是單純字段命名與表結構設計，而是一套體系化的抽象方法論。此文將從模型體系説明開始，逐一拆解建模方式區別、典型適配場景與落地難點。
1. 為什麼需要數據建模
數據建模目標並非“定義表結構”，而是實現：
- 指標口徑統一
- 跨主題數據複用
- 明晰的層級數據血緣
- 業務行為結構化表達
- 一致的性能與可拓展性保障
- 避免煙囱式數據建設
建模設計週期越早落地，成本越低；系統越複雜、數據源越多，建模收益越明顯。
2. 常見模型體系概覽
業界主流建模體系主要包括：
| 模型體系 | 核心結構 | 適用核心 | 國內成熟度 |
|---|---|---|---|
| 維度建模（Kimball） | 事實表 + 維度表 | 企業分析報表，指標計算，多維查詢 | 極高 |
| 數據倉庫分層模型（DWD/DWS/ADS等） | 數據層級體系 | 統一指標輸出、數據複用 | 極高 |
| 3NF 範式建模（Inmon） | 實體結構關係庫 | 複雜業務、強事務一致性 | 中等 |
| 數倉寬表模型 | 單表包含大量指標 | 輕查詢業務、直觀應用層 | 高 |
| Data Vault 模型 | HUB + LINK + SAT | 多源多版本、業務快速變化 | 正在增加 |
| 指標體系模型（統一指標模型） | 業務過程實體拆解 | 統一指標標準 | 非常高 |
不同企業可能混合使用。
3. 維度建模解析
3.1 核心結構
維度建模由：
- 事實表（Fact）
- 維度表（Dim）
組成。
事實表三類：
| 類型 | 説明 |
|---|---|
| 事務型事實表 | 記錄狀態變化，如下單、支付 |
| 累積型快照表 | 覆蓋生命週期字段，如訂單生命週期 |
| 週期快照表 | 定期彙總，如日/月結算 |
維度表分類：
| 類型 | 特徵 |
|---|---|
| 標準維度 | 不隨事實變化 |
| SCD1 | 直接覆蓋 |
| SCD2 | 有生效區間 |
| SCD3 | 多版本保留部分歷史 |
3.2 適用場景
| 場景 | 為什麼合適 |
|---|---|
| OLAP分析，報表透視 | 維度下鑽能力強 |
| BI儀表盤輸出 | 事實粒度適配圖層 |
| 離線多維分析模型 | 數據口徑統一 |
| 多主題統一分析 | 高複用性 |
3.3 不合適場景
- 高頻精準強一致性業務
- 業務規則變化極快
- 單業務煙囱系統（沒必要）
4. 分層建模（典型國內數倉體系）
經典分層如下：
ODS → DWD → DWS → ADS
各層定義及價值
| 層級 | 定義 | 價值 |
|---|---|---|
| ODS | 原始數據 | 可追溯、不可變 |
| DWD | 明確定義的事實層 | 業務過程標準化 |
| DWS | 聚合模型層 | 指標封裝 |
| ADS | 應用層 | 服務報表/接口 |
為什麼國內成熟度高
- 國內強報表需求驅動
- 指標複用成本極高
- 企業數據開發團隊層級較清晰
5. 範式建模 (3NF)
面向概念：
- 實體
- 屬性
- 多對多關係拆關聯表
優點：
- 無冗餘
- 數據更新一致性好
- 實體級業務關係清晰
缺點：
- 不適用於分析型查詢
- JOIN 運行成本高
- 知識門檻高
適合場景：
✔ 銀行業核心賬務
✔ 電信計費系統
✔ 實時交易系統
不適合：
✘ 一般 BI
✘ OLAP
6. 寬表模型
示例
訂單寬表約包含：
- 用户信息
- 商品信息
- 價格維度
- 支付結果
- 配送結果
- 派送狀態
優勢：
- 上層使用簡單
- 查詢性能極佳
- 高併發適合實時接口
缺點：
- 血緣難追蹤
- 字段冗餘嚴重
- 多表來源導致更新鏈複雜
適合：
- ADS層
- API層
- 篩選查詢
不適合：
- 複雜多維分析
7. Data Vault
結構由：
| 模型類型 | 含義 |
|---|---|
| HUB | 業務主鍵實體 |
| LINK | 實體關係 |
| SAT | 屬性快照 |
適合 NoSQL 風格企業或數據源極複雜企業：
例如：
- 新業務上線頻繁
- 數據隨時變更
- 來源系統超過 10 個以上
典型行業：
- 物流
- 航空
- 醫療
- 金融風控
難點在於：
- 模型理解難
- BI層需要額外星型重建
8. 場景化選型指南表
| 場景 | 推薦模型 |
|---|---|
| 公司階段早期，只需分析 | 寬表 |
| 用户增長/交易分析 | 維度模型 |
| 跨系統數據統一 | 分層模型 |
| 屬於銀行/保險等核心業務 | 3NF |
| 業務頻繁變化，數據源不穩定 | Data Vault |
| 指標體系統一管理 | 指標模型體系 |
9. 如何避免錯誤選型
錯誤選型常見表現：
| 錯誤現象 | 實際根因 |
|---|---|
| 寬表反覆擴展 | 指標層缺失 |
| 事實表粒度不明確 | 建模未按業務過程拆解 |
| 維度表無限擴充 | SCD策略未制定 |
| 統計口徑反覆衝突 | 無統一指標口徑管理 |
| 數據查詢極慢 | 模型未考慮訪問模式 |
10. 推薦建模落地策略步驟
Step 1：業務過程識別
識別業務原子行為：
如：
- 下單
- 支付
- 發貨
- 簽收
- 評價
Step 2：抽取業務主實體
如：
- 用户
- 商品
- 訂單
- 物流
Step 3：確定事實粒度
粒度必須：
- 單一不可拆
- 明確唯一主鍵
- 可歷史追溯
Step 4：統一指標
定義：
- 計算邏輯
- 業務口徑
- 彙總週期
11. 示例模型設計（訂單域案例）
事實表示例：訂單事務表
| 字段 | 含義 |
|---|---|
| order_id | 訂單ID |
| user_id | 用户ID |
| sku_id | 商品ID |
| pay_time | 支付時間 |
| order_amount | 訂單金額 |
維度表：用户維度（SCD2）
| 字段 | 解釋 |
|---|---|
| user_key | surrogate key |
| user_id | 真實id |
| level | 用户等級 |
| start_time | 生效開始 |
| end_time | 生效結束 |
指標計算示例
GMV = sum(order_amount)
訂單支付用户數 = count(distinct user_id)
訂單數 = count(order_id)
12. 結語
不同建模體系沒有絕對優劣，它們由業務複雜度、技術成熟度、長期維護成本共同決定。
最關鍵思路為：
先認知業務過程，再拆粒度，後定義指標口徑，最後映射實體模型。
