如何用 AI 设计数据管道

搭数据管道，难在哪一步

从源库把数据搬到数仓看似只是"抽取—转换—加载"，但真正的难点在选型和取舍：是批处理还是实时流？延迟要求几分钟还是几小时？日处理量是百万行还是十亿行？错误数据怎么处理、跑挂了怎么重放？这些决定了该用 Airflow 还是 Flink、该建什么样的表模型、要不要做数据质量校验。选错方向，轻则后期返工，重则数据不可靠、排查无从下手。再加上一条 Spark 聚合或一个 DAG 跑得过慢时，瓶颈往往藏在执行计划、分区和缓存里，不展开看根本定位不到。

这个技能能帮你设计和优化什么

它覆盖数据系统的四块工作。技术选型层面，它根据需求在批处理、流处理和 Lakehouse 架构之间给出选型路径，明确什么场景该用 Airflow、dbt，什么场景该上 Kafka、Flink、Spark Streaming。编排配置层面，它生成 Airflow 编排、数据抽取和仓库加载的配置思路。数据质量层面，它建立完整性、新鲜度、唯一性等校验，以及数据契约、血缘和可观测性机制，让数据出问题时能被及时发现、能追溯。性能调优层面，它分析 Spark、SQL 和 DAG 的执行瓶颈，给出分区、缓存等具体优化建议。

把可观测性和数据契约前置进设计，是这套思路的关键：可靠的数据基础设施不是事后补监控，而是在管道设计阶段就把"怎么发现错误、怎么重放、怎么追溯"想清楚。

怎么用它

用法是把数据来源、目标仓库、延迟与规模要求，或当前遇到的性能问题用自然语言交给它，由它给出选型与配置方案。例如可以这样对它说：

它适合这些场景：企业要从 PostgreSQL 同步数据到 Snowflake 或 BigQuery；事件流需要在 Kafka、Flink 或 Spark Streaming 中实时处理；数据团队要为核心表建立完整性、新鲜度和唯一性校验；现有 Airflow DAG 或 Spark 作业跑得过慢、需要定位瓶颈。适合数据工程师、数据平台负责人、分析工程师、后端团队以及正在建设现代数据栈的企业技术团队。

大家常问

数据仓库为什么要做 ODS、DWD、DWS、ADS 这样的分层？

分层本质是分治：不分层时源系统一改字段就传导到所有下游，多团队重复清洗、口径打架、排查无从下手。ODS 贴源保留原始镜像，DWD 清洗建模出一致明细，DWS 按公共维度预聚合，ADS 面向具体报表服务。每层只做一件事，变更隔离、口径统一、问题可沿层追溯。

批处理和实时流处理在数据工程里怎么区分，各适合什么场景？

本质差异不在快慢，而在数据边界：批处理面对有界数据，假设"已就绪、一次算完"，适合 T+1 报表等延迟宽松场景；流处理面对无界数据，逐条或微批处理持续到达的事件，需引入水位线界定迟到，适合实时大屏、监控告警等秒级响应场景。两者都需要、按需求选。

数据工程里的数据血缘是什么，主要解决什么问题？

数据血缘是对数据从源头经过哪些变换、流向何处的全链路追踪，本质是一张"表/字段为节点、转换为边"的有向无环图。它主要解决三类问题：报表异常时沿血缘向上溯源定位根因；上游字段要改时下钻评估影响范围；以及合规审计中追踪敏感字段的完整传播路径。

数据管道重跑时为什么要做幂等处理？

因为管道失败、回溯历史、逻辑升级都需要重跑，而重跑是数据工程的常态而非应急。不幂等时每跑一次就叠加污染，明细翻倍、聚合指标倍增。幂等指同一输入跑多少次结果都一致，靠分区覆盖写、按业务主键去重、事务性提交实现，保证无论重跑多少次交付的数据都正确可信。