大数据数仓建模体系（完整增强版）

适用场景：企业资质评估、客户分层、销售跟进、资源匹配
核心实体：企业、联系人、联系方式、专利、软著、标签、来源等
技术栈：Doris + CDC 实时入仓（10s） + DolphinScheduler
约束条件：

• 无历史分区，仅维护当前最新全量状态
• 所有查询/导出必须通过 ADS 层
• Doris 支持 Array，但 ADS 层必须拍平

一、设计哲学

上游稳定，下游灵活；分层解耦，按需演进。

• 上游稳定：DWD/DWS/DWT 不因业务需求变更而修改，保障数据一致性与复用性
• 下游灵活：ADS 按场景定制，快速响应业务
• 分层解耦：每层职责单一，避免烟囱式开发
• 按需演进：支持从基础画像到群体特征的衍生扩展，但需通过版本化、显式依赖实现

二、整体分层架构

[业务库]
   ↓ 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

✅ 依赖方向规范：

• DWD 是所有下游的唯一事实来源
• DWS 与 DWT 均可依赖 DWD
• DWT 可依赖 DWS（仅限明确标注的群体特征，如 province_claim_rate）
• DWS 不应依赖 DWT（避免聚合层耦合画像逻辑）
• 禁止 DWS 与 DWT 循环依赖
• ADS 可自由依赖 DWD/DWS/DWT，但禁止直连 ODS

三、各层定位与职责

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

✅ 应该建什么（What）

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

❓ 为什么这么建（Why）

• 职责：作为数据源的“镜像”，提供可审计、可回溯的原始底座
• 原则：不做任何业务处理，为后续建模提供完整输入

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

✅ 应该建什么（What）

• 面向核心实体（非业务过程）的原子明细表，如：
  • dwd_company_base_full（企业）
  • dwd_contact_channel_full（联系方式）
  • dwd_patent_full（专利）
• 字段经过：
  • 清洗：过滤逻辑删除、空值处理、异常值剔除
  • 标准化：统一命名、单位（如注册资本 → 万元）、码值映射
  • 维度退化：冗余高频稳定维度名称（如 province_name）
  • Array 存 ID：source_codes ARRAY<VARCHAR>，不存 name
  • 预计算标志位：is_valid = ARRAY_CONTAINS(tag_codes, 'valid')

❓ 为什么这么建（Why）

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

📌 关键澄清：
本体系采用状态型数仓（维护当前最新全量），因此 DWD 表以核心实体为粒度，而非业务过程事件。
若未来需支持行为路径分析，可新增 dwd_xxx_event 表，但当前不推荐。

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

✅ 应该建什么（What）

• 按主题、维度、指标进行轻度聚合，如：
  • dws_company_summary：total_patent_count, valid_contact_rate
• 字段包括：
  • 分组键（如 company_id, province_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
  • 群体特征（需显式标注）：province_claim_rate, industry_avg_score
• 特征必须稳定、高频、通用，规则变更频率低（如月度更新）

❓ 为什么这么建（Why）

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

📌 演进型建模规范：

• 若需将 DWS 聚合结果作为新特征，应创建 增强型 DWT 表（如 dwt_company_profile_enhanced）
• 禁止直接修改原 DWT 表
• 群体特征字段命名需体现群体属性（如 province_xxx_rate）

📌 关键区分：

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

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

✅ 应该建什么（What）

• 一个需求 = 一张 ADS 表，如：
  • ads_sales_company_list
  • ads_unclaimed_company_export
• 字段特点：
  • 业务友好：is_valid=1 → '有效'
  • 拍平 Array：source_names_str = ARRAY_TO_STRING(...)
  • 宽表设计：JOIN DWD + DWS + DWT 形成最终视图
  • 预计算业务字段：如客户等级、导出时间

❓ 为什么这么建（Why）

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

四、配套规范体系

1. 命名规范

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

2. 字段规范

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

3. 数据安全与合规

• 敏感字段处理：
  • 身份证、手机号等 PII 字段在 DWD 层 删除或脱敏（如 hash、掩码）
  • 脱敏规则需在《清洗规则表》中明确定义
• 合规依据：遵循《个人信息保护法》《GDPR》等要求

4. 数据质量监控

五、演进型建模支持机制

需求是动态的，模型是可演进的。

场景示例：

业务原需求：导出“高潜企业清单”
新增需求：展示“各省高潜企业的平均专利数”及“该企业所在省的高潜密度”

推荐路径：

dwd_company_base_full
  ├─→ dwt_company_profile_v1（基础画像：is_high_potential）
  │     └─→ dws_province_high_potential_summary（聚合：各省高潜企业数）
  │           └─→ dwt_company_profile_v2（增强画像：province_high_potential_density）
  └─→ dws_company_summary（专利总数）
        └─→ ads_sales_company_list（最终出口）

dwd_company_base_full
  ├─→ dwt_company_profile_v1（基础画像：is_high_potential）
  │     └─→ dws_province_high_potential_summary（聚合：各省高潜企业数）
  │           └─→ dwt_company_profile_v2（增强画像：province_high_potential_density）
  └─→ dws_company_summary（专利总数）
        └─→ ads_sales_company_list（最终出口）

核心原则：

1. 基础画像保稳定：dwt_v1 不变
2. 群体特征另建表：dwt_v2 显式依赖 DWS
3. 依赖链路单向无环：DAG 结构，禁止循环
4. 元数据显式记录：血缘、用途、负责人

💡 设计口诀：
DWD建模要扁平，Array存ID别存名；
DWS聚合要轻量，DWT画像要稳定；
基础画像保稳定，群体特征另建表；
依赖链路要单向，演进不乱靠分层；
ADS出口唯一门，新人照做不出错！

六、总结：本体系的核心价值

这是一套真正面向生产、面向业务、面向长期演进的企业级数仓建模体系。