系列一我们用七篇文章走完了智驾数据闭环的全景 ------从 8 环节模型、厂商对标、架构蓝图、全局 ID、11 张 ADS 表、闭环度量到存储治理。但有一个关键问题始终没有展开：这 79+ 张 Paimon 表到底是怎么设计出来的？
很多团队做湖仓，最容易踩的坑不是选错引擎，而是分层混乱------ODS 层直接给业务查、DWD 层塞了聚合逻辑、ADS 层还在做 JOIN。结果就是：一张表改字段，下游五个报表全挂；一个新需求进来，没人敢动旧表，只能再建一张「差不多」的。
本文是系列二「湖仓实战」的开篇，完整拆解我们的四层建模思路：ODS 原样入湖保追溯、DWD 以 data_id 串联闭环链路、DWS 按业务维度预聚合、ADS 开箱即用服务应用。同时讲透 11 个数据域的划分逻辑与关键表结构设计。系列二后续文章会在此基础上深入 DDL 实战、双路查询、CDC 接入等工程细节。
一、四层架构：每层只干一件事
先回答一个根本问题：为什么要分层？ 答案是三个字------改得起 。不分层的湖仓，任何一环的变更都会像多米诺骨牌一样传导到下游。分层的核心价值是变更隔离：ODS 层对接源系统变化、DWD 层屏蔽上游差异、DWS 层固化业务口径、ADS 层适配展示需求。每一层只对自己的上游负责，下游不用关心上游怎么变。
|-----|-------|--------------------------------------------------------------------|
| 层级 | 核心职责 | 设计原则 |
| ODS | 原始同步层 | 源系统什么样，湖仓就存什么样；不加业务逻辑，只做字段映射与系统字段补充（_ingest_time / _source_system） |
| DWD | 明细数据层 | 以 data_id 为核心串联闭环链路；跨源 JOIN、清洗、标准化；是数据血缘与追溯的核心层 |
| DWS | 汇总指标层 | 按业务维度（日期/项目/模型/场景）预聚合；口径在此层固化，下游不再重复计算 |
| ADS | 应用数据层 | 面向具体应用/报表/大屏；开箱即用，零 JOIN；系列一已详解 11 张 ADS 表 |
这套分层不是拍脑袋定的。它对应的是数据从**「原始事实」→「业务明细」→「管理指标」→「产品视图」**的自然加工链路。每一层的表数量也在递增：ODS 层 28 张（对接所有源系统）→ DWD 层 27 张（跨源关联后反而更少，因为消除了冗余）→ DWS 层 14 张（按维度聚合）→ ADS 层 11 张（面向应用场景）。
二、ODS 层：源系统原样入湖，28 张表对接全链路
ODS 层的设计哲学就一句话：不改造、不丢失、可追溯。源系统的表结构什么样，ODS 层就存什么样------哪怕源系统字段命名不规范、类型不统一，也不在 ODS 层做修正。修正逻辑留给 DWD 层。这样做的好处是：当源系统升级导致字段变更时，ODS 层只需调整同步映射，不影响下游任何逻辑。
28 张 ODS 表按11 个数据域分组，每个数据域对应闭环中的一个业务环节：
|-------|-----------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------|
| 数据域 | ODS 表 | 来源系统 |
| 采集域 | ods_collect_task / ods_vehicle_info / ods_sensor_config / ods_data_file_meta | 采集管理系统 / 车辆管理系统 / 配置管理系统 / 文件管理系统 |
| 生产域 | ods_production_line_task / ods_argo_workflow / ods_annotation_task / ods_annotation_result / ods_qc_task / ods_qc_result / ods_manual_operation_log | 产线平台 MySQL / Argo 元数据库 / 标注平台 / 质检平台 / Kafka |
| 数据资产域 | ods_dataset_info / ods_dataset_version / ods_dataset_data_list / ods_scene_tag | 数据管理平台 MySQL / 场景标签系统 |
| 训练域 | ods_training_task / ods_training_metric / ods_model_version | 训练平台 MySQL / 模型管理平台 |
| 评测域 | ods_evaluation_task / ods_evaluation_result / ods_badcase_record | 评测平台 MySQL |
| 仿真域 | ods_simulation_scenario / ods_simulation_result | 仿真平台 MySQL |
| 回传域 | ods_vehicle_trigger_event / ods_vehicle_function_test / ods_shadow_mode_data | 车端回传 Kafka |
| 部署域 | ods_ota_task / ods_vehicle_software_version | OTA 平台 / 车辆管理平台 |
| 分析域 | ods_issue_record | 问题管理平台 MySQL |
| 挖掘域 | ods_mining_task / ods_mining_rule_config | 数据挖掘平台 MySQL（规则表经 Flink CDC 实时同步） |
| 质量门禁 | ods_quality_issue | 入湖质量门禁服务（隔离异常数据，可重放） |
每张 ODS 表统一追加两个系统字段：_ingest_time（入湖时间戳）和 _source_system（来源系统标识）。这两个字段是后续数据血缘追溯与问题定位的基础------当 ADS 层某张报表数据异常时，可以通过这两个字段快速回溯到源头。
三、DWD 层：以 data_id 串联闭环，27 张表构建全链路视图
DWD 层是整个湖仓的核心层。如果说 ODS 层是「原材料仓库」，DWD 层就是「精密装配车间」------它负责把来自 11 个不同源系统的数据，通过全局 data_id 串联成一条完整的闭环链路。
DWD 层的设计围绕三个关键词展开：
① data_id 贯穿 。系列一 S1-04 详解的三级 ID 体系（data_id → clip_id → image_id）在 DWD 层落地为物理主键或关联键。以 dwd_data_production_chain（数据生产主链路表）为例，它以 data_id 为主键，记录每个数据单元从采集、标注、质检到交付的完整状态与时间戳。这张表是后续所有效率分析、瓶颈定位、血缘追溯的起点。
② 闭环追溯表 。dwd_closed_loop_trace 是 DWD 层的「终极汇总表」------同样以 data_id 为主键，但它不记录过程细节，而是记录每个数据单元在闭环中的全局状态快照：被哪些训练任务用过、产出过哪些模型版本、在哪些评测任务中出现过、是否触发过 Badcase、是否被量产车触发过。这张表让「从 Badcase 回溯到原始采集 clip」成为一次简单的主键查询。
③ 挖掘域扩展 。DWD 层在闭环域之外，还承载了挖掘域的 8 张明细表------从抽帧图片、统一标签字典、数据级/图片级标签明细，到大模型推理任务、图片向量明细。其中 dwd_mining_image_vector_detail 是全湖体量最大的表（千万~亿级行 × 高维向量），也是全湖唯一的分区表（按 dt 分区），其余表均以 bucket + 主键 Upsert 管理。
四、DWS + ADS 层：指标固化与应用交付
DWS 层（14 张表） 的职责是「口径固化」。以 dws_closed_loop_efficiency（闭环效率指标表）为例，它按日期 + 项目维度预聚合了采集到交付耗时、训练耗时、评测耗时、完整闭环耗时、Badcase 解决率等核心指标。一旦这张表的计算逻辑确定，下游所有报表和看板都直接读它，不再重复 JOIN 和计算------这就是「口径固化」的价值：同一个指标，全公司只有一个算法。
ADS 层（11 张表） 在系列一 S1-05 已详细拆解。这里只强调一个设计要点：ADS 层的所有表都是零 JOIN的。每张 ADS 表已经包含了应用所需的全部字段，前端报表或大屏直接 SELECT 即可，不需要再做任何关联。这是分层建模的最终目标------让数据消费者用最简单的方式拿到最完整的数据。
|-----|------|------------------------------------------|
| 层级 | 表数量 | 核心特征 |
| ODS | 28 张 | 源系统原样同步，追加 _ingest_time / _source_system |
| DWD | 27 张 | data_id 串联闭环链路，跨源 JOIN 与标准化 |
| DWS | 14 张 | 按业务维度预聚合，口径固化 |
| ADS | 11 张 | 零 JOIN，开箱即用，面向应用 |
五、Paimon 关键设计决策：主键、Bucket 与 Changelog
选定了分层架构，接下来是引擎层面的设计决策。Paimon 作为湖仓引擎，有三个关键参数直接影响表的读写性能与数据一致性：
主键策略 。我们采用「业务主键 + NOT ENFORCED」模式。例如 ods_collect_task 以 collect_task_id 为主键，dwd_data_production_chain 以 data_id 为主键。NOT ENFORCED 表示 Paimon 不在写入时强制校验唯一性（由上游保证），但会基于主键做 Upsert 合并------这对 CDC 实时入湖场景至关重要。
Bucket 分桶 。Bucket 数决定了表的并行读写能力。我们的经验法则是：ODS 层小表 2-4 个 bucket，DWD 层核心表 16-32 个 bucket 。例如 dwd_collect_clip_detail 设 16 个 bucket（clip 级数据量大且查询频繁），dwd_production_artifact_detail 设 32 个 bucket（产物表是血缘核心，并发读写最高）。
Changelog 生产 。所有 ODS 层表统一设置 'changelog-producer' = 'input'，即基于输入数据直接生成变更日志。这对下游 Flink 实时消费至关重要------当 ODS 层数据更新时，DWD 层的 Flink 任务可以实时感知并增量更新，而不需要全量重算。
六、79+ 张表清单总览
前面各章分别讲解了 ODS / DWD / DWS / ADS 四层的设计思路，这里给出完整的表清单速查。ODS 层 28 张表已在第二章列出，下表补充 DWD 层 27 张、DWS 层 14 张、ADS 层 11 张的完整表名与说明。
DWD 层（27 张）------以 data_id 串联闭环链路
|-------|--------------------------------------------|------------------------|
| 数据域 | 表名 | 说明 |
| 采集域 | dwd_collect_clip_detail | 采集数据单元元信息（clip 级，血缘起点） |
| 生产域 | dwd_data_production_chain | 数据生产主链路表 |
| 生产域 | dwd_production_execution_detail | 产线执行明细 |
| 生产域 | dwd_production_artifact_detail | 处理产物元信息（血缘核心） |
| 生产域 | dwd_production_run_detail | 处理运行记录（含重跑信息） |
| 生产域 | dwd_manual_operation_detail | 人工操作明细 |
| 数据资产域 | dwd_dataset_version_detail | 数据集版本明细 |
| 数据资产域 | dwd_dataset_data_relation | 数据集-数据关联 |
| 数据资产域 | dwd_scene_tag_relation | 数据-场景标签关联 |
| 训练域 | dwd_training_task_detail | 训练任务明细 |
| 训练域 | dwd_training_metric_detail | 训练指标明细 |
| 评测域 | dwd_evaluation_task_detail | 评测任务明细 |
| 评测域 | dwd_evaluation_result_detail | 评测结果明细 |
| 评测域 | dwd_badcase_detail | Badcase 明细 |
| 仿真域 | dwd_simulation_result_detail | 仿真结果明细 |
| 回传域 | dwd_vehicle_trigger_detail | 车端触发事件明细 |
| 回传域 | dwd_shadow_mode_detail | 影子模式数据明细 |
| 部署域 | dwd_ota_deployment_detail | OTA 部署明细 |
| 部署域 | dwd_vehicle_software_distribution_detail | 车端软件版本分布 |
| 分析域 | dwd_issue_detail | 问题明细 |
| 挖掘域 | dwd_mining_task_detail | 挖掘任务明细 |
| 挖掘域 | dwd_mining_result_detail | 挖掘结果明细 |
| 挖掘域 | dwd_scene_gap_detail | 场景缺口清单 |
| 挖掘域 | dwd_mining_image_frame_detail | 抽帧图片明细 |
| 挖掘域 | dwd_mining_tag_dict_detail | 统一标签字典 |
| 挖掘域 | dwd_mining_data_tag_detail | 数据级标签明细（clip 级） |
| 挖掘域 | dwd_mining_image_tag_detail | 图片级标签明细 |
| 挖掘域 | dwd_mining_image_vector_detail | 图片向量明细（全湖唯一分区表） |
| 闭环域 | dwd_closed_loop_trace | 闭环全链路追溯表 |
| 闭环域 | dwd_closed_loop_storage_lifecycle | 存储生命周期状态明细 |
▎DWS 层（14 张）------口径固化，按维度预聚合
|-------|--------------------------------------|--------------|
| 数据域 | 表名 | 说明 |
| 生产域 | dws_production_efficiency_daily | 产线效率日指标 |
| 生产域 | dws_annotation_quality_daily | 标注质量日指标 |
| 数据资产域 | dws_dataset_statistics | 数据集统计指标 |
| 数据资产域 | dws_scene_distribution | 场景分布统计 |
| 训练域 | dws_training_efficiency_daily | 训练效率日指标 |
| 评测域 | dws_evaluation_summary | 评测汇总指标 |
| 评测域 | dws_badcase_statistics | Badcase 统计指标 |
| 回传域 | dws_trigger_statistics | 触发事件统计指标 |
| 部署域 | dws_deployment_statistics | 部署统计指标 |
| 闭环域 | dws_closed_loop_efficiency | 闭环效率指标 |
| 闭环域 | dws_data_contribution | 数据贡献度指标 |
| 闭环域 | dws_closed_loop_storage_cost_daily | 存储成本日指标 |
| 挖掘域 | dws_mining_efficiency_daily | 挖掘效率日指标 |
| 挖掘域 | dws_mining_tag_coverage_daily | 标签覆盖度日指标 |
▎ADS 层（11 张）------零 JOIN，开箱即用
|---------------------------------------|--------------|
| 表名 | 说明 |
| ads_closed_loop_dashboard | 闭环大盘指标 |
| ads_production_bottleneck_analysis | 产线瓶颈分析结果 |
| ads_badcase_root_cause_distribution | Badcase 根因分布 |
| ads_scene_library_summary | 场景库汇总 |
| ads_hard_case_library | 难例库 |
| ads_data_asset_catalog | 数据资产目录 |
| ads_model_version_comparison | 模型版本对比 |
| ads_ota_deployment_summary | OTA 部署汇总 |
| ads_trigger_heatmap | 触发事件热力图 |
| ads_storage_cost_dashboard | 存储成本看板 |
| ads_mining_tag_dashboard | 挖掘标签分布看板 |
💡 获取完整文档：本篇列出了 79+ 张表的表名与说明，但受限于篇幅，每张表的完整字段定义（DDL）与字段说明未能一一展开。
结语
用三句话带走本篇：分层是为了改得起 ------ODS 挡源系统变化、DWD 做跨源关联、DWS 固口径、ADS 零 JOIN；data_id 是闭环的脊梁 ------27 张 DWD 表以 data_id 为主键或关联键，让「从 Badcase 回溯到原始 clip」成为一次主键查询；79+ 张表不是堆出来的------11 个数据域 × 4 层架构，每张表都有明确的职责边界与上游依赖。
下一篇预告：系列二第 2 篇------《79+ 张表的设计思路：智驾湖仓表分层与命名规范》，讲透阿里数仓命名规范在智驾场景的落地、数据域划分逻辑与分区策略设计。我们下一篇见。
关注后回复「湖仓分层设计」即可获取包含全部字段结构的完整设计文档:
