大数据数仓建模体系

本体系严格聚焦于：

✅ What：每一层应该建什么
✅ Why：为什么这么建、职责边界、设计原则
✅ 不包含 How：不涉及 ETL 写法、任务调度、建表语法等实施细节

适用场景：企业资质评估、客户分层、销售跟进、资源匹配
核心实体：企业、联系人、联系方式、专利、软著、标签、来源等

技术约束：

• 无历史分区，仅维护当前最新全量状态
• 数据源为业务库 CDC 实时同步（10s Checkpoint）
• 查询/导出必须通过 ADS 层
• Doris 引擎支持 Array/Struct，但仅用于必要场景

🧱 一、整体分层架构

[ODS] → [DWD] → [DWS] → [DWT] → [ADS]

[ODS] → [DWD] → [DWS] → [DWT] → [ADS]

核心原则：

• 上游稳定，下游灵活：DWD/DWS/DWT 不因业务需求变更而修改
• ADS 是唯一出口：所有查询、导出、API 必须通过 ADS 层
• 分层解耦：每层职责单一，避免烟囱式开发

🗂 二、各层定位与职责（What & Why）

1. ODS 层（Operational Data Store）——贴源层

✅ 应该建什么（What）

• 与业务库结构完全一致的原始数据表
• 包含逻辑删除标记（is_deleted）、CDC 元字段（_op, _timestamp）
• 不做任何业务处理，保留脏数据、异常值、冗余字段

❓ 为什么这么建（Why）

• 职责：作为数据源的“镜像”，提供原始、可审计的数据底座
• 原则：
  • 不清洗、不映射、不删字段
  • 为后续建模提供完整原始输入
  • 支持 CDC 实时入仓，自动合并最新状态（通过 UNIQUE KEY）

2. DWD 层（Data Warehouse Detail）——明细建模层

✅ 应该建什么（What）

• 面向分析主题的原子事实表（如企业、联系人、联系方式、专利）
• 字段经过：
  • 清洗（过滤逻辑删除、空值处理、异常值剔除）
  • 标准化（统一命名、单位、码值）
  • 维度退化（冗余高频维度名称，如 province_name）
  • 多值字段用 Array 存储 ID（如 source_codes, tag_codes）
  • 预计算标志位（如 is_valid = ARRAY_CONTAINS(tag_codes, 'valid')）

❓ 为什么这么建（Why）

• 职责：提供“干净、可关联、可下钻”的原子明细数据
• 原则：
  • 不是 ODS 的简单复制，而是面向业务过程的重构
  • 字段精简：从 ODS 90+ 字段筛选出 40~60 个核心字段
  • 保持原子粒度：不聚合、不汇总业务指标
  • BI 友好：退化维度避免下游频繁 JOIN
  • 语义稳定：Array 存 ID（code），不存 name，保证历史一致性

📌 关键区分：

• 退化维度（允许）：province_code + province_name
• 聚合统计（禁止）：patent_count（应放 DWS）

3. DWS 层（Data Warehouse Summary）——轻度聚合层

✅ 应该建什么（What）

• 按主题、维度、指标进行轻度聚合
  • 如：企业专利总数、联系人有效率、渠道分布
• 字段包括：
  • 分组键（如 company_id, industry_code）
  • 聚合指标（COUNT, SUM, AVG, MAX）
  • 覆盖率、分布统计等通用指标

❓ 为什么这么建（Why）

• 职责：支撑多维分析、趋势统计、通用指标复用
• 原则：
  • 只做必要聚合：避免多维 GROUP BY（内存爆炸）
  • 不存明细：与 DWD 职责分离
  • 基于 DWD 预计算字段：避免重复 JOIN 和清洗逻辑
  • 口径统一：所有聚合基于同一份 DWD 数据，确保一致性

📌 禁止：

• 存储过程数据
• 做复杂业务逻辑
• 直接供业务查询（必须走 ADS）

4. DWT 层（Data Warehouse Theme）——主题画像层

✅ 应该建什么（What）

• 企业/联系人画像宽表，包含：
  • 稳定、高频、通用的业务状态标签（如 is_claimed, is_high_potential）
  • 特征工程结果（如 customer_value_score, company_grade）
  • 预计算的综合指标（如 contact_valid_rate）

❓ 为什么这么建（Why）

• 职责：提供“一眼看清主体特征”的数据产品
• 原则：
  • 只放画像特征，不放过程明细
  • 特征必须稳定：规则变更频率低（如月度更新）
  • 可被 DWS/ADS 依赖：作为稳定特征源
  • 支持 DWT 内部依赖：如 dwt_company_tag → dwt_company_grade

📌 关键区分：

• 画像特征（放 DWT）：is_claimed, company_grade
• 临时标签（放 ADS）：销售私有打标、临时活动标签

5. ADS 层（Application Data Store）——应用出口层

✅ 应该建什么（What）

• 按业务场景定制的结果表
  • 如：ads_sales_company_list, ads_unclaimed_company_export
• 字段特点：
  • 业务友好：格式化（is_valid=1 → '有效'）
  • 拍平 Array：source_names_str = ARRAY_TO_STRING(...)
  • 宽表设计：JOIN DWD + DWS + DWT 形成最终视图
  • 预计算业务字段：如客户等级、导出时间

❓ 为什么这么建（Why）

• 职责：作为唯一查询/导出入口，收敛所有业务需求
• 原则：
  • 一个需求 = 一张 ADS 表
  • 禁止直接查 DWD/DWS/DWT
  • 可冗余、可重复、可宽表：不追求范式，只追求易用
  • 上游稳定：DWD/DWS/DWT 不因 ADS 需求变更而修改

📜 三、配套规范体系（What & Why）

1. 命名规范

Why：清晰表达层级、主题、用途，便于管理和协作

2. 字段规范

Why：统一语义，降低理解成本，提升复用性

3. 数据质量监控（What to Monitor）

4. 演进型建模规范（支持需求动态演进）

✅ 应该建什么（What）
当新业务需求需基于现有 DWT 标签进行聚合，或需将 DWS 聚合结果反哺为画像特征时，应通过 分层增强、版本隔离、显式依赖 的方式实现，而非修改原始模型。
典型场景包括：

• 将 DWT 中的 is_high_potential 作为维度，聚合出“各省高潜企业数量”（DWS）；
• 将 DWS 中的“区域领取率”作为群体特征，加入企业画像（DWT_enhanced）。

❓ 为什么这么建（Why）
数仓模型需兼顾 稳定性 与 灵活性：

• 上游稳定：基础 DWD/DWT 表不应因新需求频繁变更，保障下游复用一致性；
• 下游灵活：通过新增增强层表，支持复杂衍生逻辑，避免“为新需求重构全链路”；
• 依赖可控：明确区分“个体特征”与“群体特征”，防止循环依赖与逻辑混乱。

📌 核心原则

1. 允许 DWT → DWS → DWT_enhanced，但禁止循环依赖
   • DWS 聚合必须基于 基础 DWT（如 dwt_company_profile）；
   • 若需将聚合结果作为新特征，应创建 增强型 DWT 表（如 dwt_company_profile_enhanced），而非修改原表；
   • 禁止 DWS 直接依赖含群体特征的 DWT_enhanced。
2. 特征分类清晰
   • 个体特征（放基础 DWT）：is_claimed, patent_count > 5；
   • 群体特征（放增强 DWT）：province_claim_rate, industry_avg_score，字段名需体现群体属性。
3. 命名与文档显式标识
   • 增强表命名建议：dwt_<主体>_profile_enhanced 或 dwt_<主体>_profile_v2；
   • 在元数据中明确标注：“本表依赖 DWS 聚合结果，用于群体特征扩展”。

💡 设计口诀补充：
“基础画像保稳定，群体特征另建表；
依赖链路要单向，演进不乱靠分层。

🧩 四、架构全景图（What）

[业务库]
   ↓ CDC (10s)
[ODS] —— 贴源、UNIQUE KEY、保留原始结构
   ↓
[DWD] —— 清洗、标准化、退化维度、Array 存 ID
   ↓
[DWS] —— 轻度聚合、通用指标、当前状态统计
   ↓
[DWT] —— 企业/联系人画像、稳定业务标签、特征工程
   ↓
[ADS] —— 唯一出口、拍平、格式化、宽表、按需定制
   ↓
BI / 报表 / 导出 / API

[业务库]
   ↓ CDC (10s)
[ODS] —— 贴源、UNIQUE KEY、保留原始结构
   ↓
[DWD] —— 清洗、标准化、退化维度、Array 存 ID
   ↓
[DWS] —— 轻度聚合、通用指标、当前状态统计
   ↓
[DWT] —— 企业/联系人画像、稳定业务标签、特征工程
   ↓
[ADS] —— 唯一出口、拍平、格式化、宽表、按需定制
   ↓
BI / 报表 / 导出 / API

✅ 五、总结：这套建模体系的核心价值

这是一套 真正面向生产、面向业务、面向长期演进 的数仓建模体系，可作为企业级标准文档使用。