上一篇文章讲透了 ODS→DWD→DWS→ADS 四层建模思路有读者留言「道理我都懂但 79 张表的名字到底怎么起的分区策略为什么有的用 dt、有的用 trigger_type、有的不用分区Bucket 数为什么有 1、2、4、8、16 这么多档」这些问题指向的是数仓设计中最容易被忽视、却最影响长期可维护性的三个基本功命名规范、数据域划分、物理存储策略。很多团队前期赶进度表名随意起、分区随意加结果半年后连表 owner 都搞不清。本文基于实际落地的 79 张 Paimon 表完整拆解一套四段式命名公式让每张表名字自带「层级域实体粒度」信息11 个数据域让表的归属一目了然分区与 Bucket 的决策矩阵让查询性能和写入吞吐达到最优平衡。文末附完整 DDL 实战示例。一、四段式命名公式看名字就知道表干什么命名规范参考阿里巴巴 OneData 数仓标准针对智驾场景适配。核心公式四段第一段层级前缀前缀层级含义ods_原始同步层源系统原样入湖不加业务逻辑dwd_明细数据层跨源 JOIN、清洗标准化以 data_id 串联闭环dws_汇总指标层按业务维度预聚合口径在此层固化ads_应用数据层面向报表/大屏/应用开箱即用第二段数据域数据域对应闭环中的业务环节11 个数据域覆盖全生命周期详见第二章。每个域用简短英文词根表示如 collect_、production_、mining_ 等。第三段业务实体核心对象「名词在前、修饰在后」下划线连接业务实体语义collect_task采集任务data_production_chain数据生产主链路vehicle_trigger_event车端触发事件closed_loop_trace闭环全链路追溯mining_image_vector挖掘图片向量第四段粒度后缀10 种标准后缀后缀语义所属层示例_detail明细表DWDdwd_training_task_detail_daily日粒度指标DWSdws_production_efficiency_daily_statistics多维度统计DWSdws_badcase_statistics_summary汇总指标DWS/ADSdws_evaluation_summary_relation关联关系表DWDdwd_scene_tag_relation_chain/_trace链路/追溯DWDdwd_closed_loop_trace_dashboard大屏看板ADSads_closed_loop_dashboard_analysis分析结果ADSads_production_bottleneck_analysis_info/_config基础信息/配置ODSods_vehicle_info_log/_event日志/事件ODSods_manual_operation_log实战拆解命名规范的价值表名即文档。新人入职不需要翻 200 页数仓字典看表名就知道 80% 的信息。二、11 个数据域让每张表都有「户口」数据域是表分类的「户口本」。按智驾数据闭环的8 个业务环节 3 个支撑域划分出 11 个数据域#数据域域前缀ODSDWDDWSADS核心含义1采集域collect_41——采集任务/车辆/传感器/clip2生产域production_8521产线/标注/质检/效率3数据资产域dataset_4321数据集/场景标签/资产目录4训练域training_3211训练任务/指标/模型版本5评测域evaluation_3322评测/Badcase/根因分布6仿真域simulation_21——仿真场景与运行结果7回传域trigger_3211触发事件/影子模式/热力图8部署域deployment_2211OTA 部署/车端版本9分析域issue_11——问题记录与分析10挖掘域mining_21021挖掘/抽帧/标签/向量/推理11闭环域closed_loop_—232追溯/存储生命周期/成本合计3230141187 张含质量门禁 1 张三个要点①挖掘域 DWD 最多10 张——挖掘平台是闭环「第二入口」抽帧/标签/向量/推理各环节需独立明细表。②闭环域没有 ODS 表——它是跨域整合域数据全部来自其他域 DWD 层加工。③质量门禁只有 1 张 ODS 表——异常隔离表 ods_quality_issue命中硬规则的数据在此隔离等待处置保证可重放。三、分区策略什么时候分区、什么时候不分区Paimon 表物理存储两个核心维度分区Partition切分目录Bucket打散数据。设计不当要么查询慢要么写入崩。分区决策三规则分区全景表表名分区字段类型原因dwd_mining_image_vector_detaildt日期全湖最大表按天降冷索引刷新ods_quality_issuedt日期异常隔离表按天 TTL 清理ods_vehicle_trigger_eventtrigger_type业务字段按触发类型过滤dwd_evaluation_result_detailevaluation_type业务字段离线/仿真/实车差异大ods_data_file_metafile_type业务字段文件类型差异大ods_production_kafka_eventevent_type业务字段事件类型数据量差异大四、Bucket 五档 changelog-producer 三选一分区解决「目录怎么切」Bucket 解决「文件怎么散」。Bucket 数太小单文件过大查询慢太大小文件过多 Compaction 压力大。我们实际落地了五档Bucket 五档决策表档位适用场景典型层级代表表1字典表/极小表ADSads_storage_cost_dashboard2DWS 汇总表 / 小 ADSDWS/ADSdws_production_efficiency_daily4中等体量 ODS/DWDODS/DWDods_collect_task / dwd_training_task_detail8大体量明细表DWDdwd_production_execution_detail16超大表 / 高并发写入DWDdwd_data_production_chain / dwd_mining_image_vector_detailchangelog-producer 三选一Paimon 的changelog-producer决定「怎么产生变更流」直接影响下游能否做实时订阅。三种模式对应三种数据特征模式适用场景原理inputODS CDC 透传 / Append-only 明细上游写入本身就是完整 changelog直接透传零额外开销lookupDWD Upsert 表需对比旧值写入时 lookup 旧值产生 -U/U 变更适合状态频繁更新的链路表full-compactionDWS/ADS 离线聚合在 full-compaction 时产生 changelog适合批量写入、低频更新的聚合表决策口诀ODS 从 CDC 来 →inputDWD 有 Upsert →lookupDWS/ADS 批量聚合 →full-compaction。选错最直接的后果该用 lookup 的表用了 input下游拿到的 changelog 缺少 -U 记录增量同步数据不一致。五、主键设计三原则 系统字段规范主键设计三原则系统字段规范每张表都统一挂载两组系统字段但 ODS 层和 DWD/DWS/ADS 层略有不同层级系统字段用途ODS_ingest_time _source_system入湖时间 来源系统标识支持多源追溯DWD/DWS/ADS_ingest_time update_time入湖时间 业务更新时间支持增量同步与变更追踪注意ODS 层用_source_system换掉update_time——因为 ODS 层不做业务更新记录「数据从哪个系统来」比「什么时候更新」更有意义。六、DDL 实战以 dwd_data_production_chain 为例把前面五章的规则串起来看一个完整的 DDL 建表语句。这是整个湖仓最核心的表——数据生产主链路表以 data_id 为主键串联采集→上云→标注→质检→交付全流程逐条对照本文规则设计维度本表选择决策依据命名规范dwd_ production_ data_production_chain明细层 生产域 数据生产链路主键PK(data_id)业务主键data_id 全局唯一标识分区不分区Upsert 表无明确分区维度Bucket16最高档全湖写入量最大的表高并发 Upsertchangelog-producerlookup状态频繁更新需产生 -U/U 变更流系统字段_ingest_time update_timeDWD 层标准配置结语79 张表的设计归结为一句话用规范换效率用一致性换可维护性。四段式命名让表名即文档11 数据域让每张表都有「户口」分区 / Bucket / changelog-producer 的决策矩阵让物理存储匹配查询模式主键三原则和系统字段规范让上下游对接零歧义。这套规范不是第一天就设计好的——是在前 20 张表上线后经历了「改一张表挂五个报表」「新人问这张表是干嘛的没人答得上」等痛点后逐步沉淀出来的。规范的价值不在于多完美而在于团队能坚持执行。下篇预告系列二第 3 篇将深入StarRocks Paimon 双路查询架构——ADS 表如何在 Paimon 湖仓侧做单一事实源同时通过 StarRocks 离线作业物化到内表实现毫秒级直查。涉及 External Catalog 直查 vs 内表物化的选型决策、双路同步链路设计、以及查询路由策略。敬请期待。 本文涉及 79 张 Paimon 表的完整 DDL篇幅有限仅展开了核心示例