AI 辅助 ETL 设计：先画出数据流向，再让模型生成代码

AI 辅助 ETL 设计先画出数据流向再让模型生成代码一、ETL 不是体力活是设计活大家好我是朱大喜。今天来聊一个加班重灾区——ETL 开发。不知道你身边有没有这样的同事接到一个数据接入需求二话不说直接开写 Spark/Flink写到一半发现上游字段找不到推倒重来又写一版最后三易其稿代码里塞满了临时补丁。这种情况我见过太多了本质上不是代码能力的问题而是跳过了设计环节。做 ETL 就像搬家。你不可能东西都不分类、新家布局都不看直接往卡车上搬箱子吧结果一定是到了新家发现锅碗瓢盆放不进厨房衣服进了卫生间。数据也一样——先搞清楚源在哪里、经哪些节点、最终落哪里把搬家路线画出来才是高效 ETL 开发的第一步。传统做法是分析师画数据流图开发照着写代码。但这里有个断层图是图代码是代码两者经常脱节。能不能让 AI 来桥接这个过程我的实践是你先画出 Mermaid 流向图把 AI 当翻译官让它把图形语义翻译成可执行代码。flowchart LR A[业务库 MySQLbr/订单表 orders] -- B[ETL 节点1br/字段映射与清洗] B -- C[ETL 节点2br/业务口径计算] C -- D[数据仓库 Hivebr/DWD 层订单明细] A -- E[日志采集 Flumebr/用户行为日志] E -- C C -- F[数据仓库 Hivebr/DWS 层用户画像] style A fill:#e1f5fe,stroke:#01579b style D fill:#e8f5e9,stroke:#1b5e20 style F fill:#e8f5e9,stroke:#1b5e20 style B fill:#fff3e0,stroke:#e65100 style C fill:#fff3e0,stroke:#e65100 style E fill:#e1f5fe,stroke:#01579b这张图的含义很清楚订单表从 MySQL 出发经过两层 ETL 加工分别落到 DWD 和 DWS 层同时用户行为日志也在第二个节点汇入形成订单和行为的关联。只要这张图的意思人类能读懂AI 就大概率能翻译出骨架代码。二、用 Mermaid 描述数据血缘不止是画图很多人觉得 Mermaid 只是个画流程图的工具。但在 AI 辅助 ETL 的场景里Mermaid 的本质是结构化地描述了数据之间的依赖关系。每个节点是一个处理步骤每条边是一条数据流转路径——这种形式对 LLM 来说非常友好因为它的语义密度高、歧义少。我用一个更生产级的例子来演示。假设我们要做一个电商 GMV 日报的 ETLflowchart TD subgraph 源端 S1[(MySQLbr/t_order)] S2[(MySQLbr/t_order_item)] S3[(MongoDBbr/user_profile)] end subgraph ODS层 O1[ODSbr/ods_order_di] O2[ODSbr/ods_order_item_di] O3[ODSbr/ods_user_profile_di] end subgraph DWD层 D1[DWDbr/dwd_trade_order_detail_dibr/关联订单商品金额] D2[DWDbr/dwd_user_info_dfbr/用户基础信息快照] end subgraph DWS层 W1[DWSbr/dws_trade_gmv_1dbr/GMV日汇总] end S1 -- O1 -- D1 S2 -- O2 -- D1 S3 -- O3 -- D2 D1 -- W1 D2 -- W1 style S1 fill:#fce4ec,stroke:#880e4f style S2 fill:#fce4ec,stroke:#880e4f style S3 fill:#fce4ec,stroke:#880e4f style W1 fill:#c8e6c9,stroke:#1b5e20,stroke-width:3px看到没有通过 subgraph 分组源端、ODS、DWD、DWS 各级数据仓库分层一目了然。每一层间的转换关系也用箭头清晰标注。把这个图 一段字段说明喂给 AI它就能生成每一层 INSERT SQL 或 PySpark 的骨架。三、从流向图到代码AI 翻译的实践技巧讲完画图来说说怎么做翻译。我提炼了几个好用的 prompt 模板。技巧一给 AI 看源数据字典光有流向图不够AI 需要知道每个表里到底有什么字段。你可以把关键的 DDL 摘出来-- 源表1: MySQL t_order订单主表 -- 关键字段 -- order_id BIGINT 订单ID主键 -- user_id BIGINT 用户ID -- order_amount DECIMAL 订单金额元 -- create_time DATETIME 创建时间 -- status TINYINT 状态 0-待支付 1-已支付 2-已取消 -- 给 AI 的 prompt 示例 -- 根据上方的 Mermaid 流向图和 DDL生成 ODS 层 -- ods_order_di 的 Flink CDC 同步代码要求 -- 1. 过滤掉 status2 的取消订单 -- 2. create_time 转换为 yyyy-MM-dd 的分区字段 dt -- 3. 添加 etl_time 字段记录处理时间戳这样一来AI 生成的代码就不会凭空捏造字段名准确率大幅提升。技巧二分层拆解逐层验收别指望一次 prompt 把 ODS → DWD → DWS 三层的代码全生成对。我建议的做法是按层级拆开# 第一轮生成 ODS 层同步代码 # prompt: 生成 Flink SQL 将 MySQL t_order 同步到 Hive ods_order_di # 按 create_time 日期分区幂等写入 # AI 输出的代码示例带注释 -- ODS 层MySQL t_order → Hive ods_order_di -- 之所以用 INSERT OVERWRITE 而不是 INSERT INTO -- 是因为日分区需要支持重跑覆盖写入是保证幂等的关键 INSERT OVERWRITE TABLE ods.ods_order_di PARTITION(dt${bizdate}) SELECT order_id, user_id, order_amount, create_time, -- 状态码保留原始值不做翻译语义转换统一在 DWD 层做 status, -- etl_time 用于数据质量回溯记录实际 ETL 时刻而非业务时间 CURRENT_TIMESTAMP() AS etl_time FROM mysql_catalog.trade_db.t_order WHERE DATE(create_time) ${bizdate};技巧三让 AI 自己写单元检测ETL 最容易出事的不是主流程而是边界情况——上游字段为 NULL、分区数据为空、类型转换溢出。这些检查逻辑又繁琐又容易漏恰好是 AI 的强项# prompt: 上面这段 ETL 代码请分析可能的边界问题 # 并写出对应的数据质量检测 SQL # AI 生成的质检 SQL 示例 -- 质检1: 检查日分区数据量是否异常 -- 为什么用过去7天均值做基准单日波动30%以内视为正常 -- 能过滤掉上游漏数、延迟等常见问题 SELECT ${bizdate} AS dt, COUNT(1) AS today_cnt, AVG(cnt) AS avg_7d_cnt, COUNT(1) * 1.0 / AVG(cnt) - 1 AS deviation FROM ( SELECT dt, COUNT(1) AS cnt FROM ods.ods_order_di WHERE dt BETWEEN DATE_SUB(${bizdate}, 7) AND ${bizdate} GROUP BY dt ) t HAVING ABS(deviation) 0.3; -- 质检2: 关键字段空值率 SELECT SUM(CASE WHEN order_amount IS NULL THEN 1 ELSE 0 END) / COUNT(1) AS null_rate FROM ods.ods_order_di WHERE dt ${bizdate} HAVING null_rate 0.05;你看AI 写业务代码不一定完美但写检查逻辑是一把好手——因为它本质上是穷举可能出错的地方这正是 LLM 的舒适区。四、我们团队的落地实践与踩坑说了这么多方法论来点真实的。我们团队目前是这么跑这套流程的1. 设计阶段人主导数据分析师用 Mermaid 画出数据流向标注字段映射关系。这一步必须人来做因为哪些字段要保留、哪些要丢弃是业务决策不能交给 AI。2. 代码生成AI 辅助把 Mermaid 图 DDL 加工规则说明一起喂给 AI生成各层 ETL 代码。这步 AI 可以搞定 70%但需要人工 review。3. 测试生成AI 高效产出让 AI 生成数据质量检测 SQL这步 AI 准确率能到 90% 以上。踩过的几个坑分享给你坑1Mermaid 图不能太抽象。节点名字只写清洗加工这种笼统的词AI 就只能瞎猜。节点名最好能体现实际表名和操作比如DWD-用户行为宽表关联。坑2DDL 喂太多会超 context。只给核心字段千万别把几百列的表结构全丢进去AI 会迷失在字段海洋里。坑3AI 不会主动考虑分区裁剪。生成 Hive SQL 时一定要在 prompt 里强调WHERE 条件带 dt 分区过滤否则全表扫描跑一天都出不来。五、总结这波 AI 辅助 ETL 的实践我最大的体会是AI 不是替你写代码而是帮你把设计文档翻译成代码。翻译的质量取决于源文档的质量——Mermaid 图就是最好的源文档格式结构化、语义明确、人类和机器都能读。具体操作可以总结为三步走人画流向图 → AI 做翻译 → 人做 code review。其中 AI 最擅长的是骨架代码生成和边界检测人最不可替代的是业务口径定义和关键逻辑判定。下次接到 ETL 需求别急着开 IDE先打开 Mermaid Live Editor 画张图。你会发现自己对数据流向的理解深了一层AI 生成的代码也会靠谱得多。—— 朱大喜和你一起用 AI 把数据活干得更聪明。