AI时代数据工程重构：从复杂管道到统一数据底座的实践路径

过去一年，我所在的数据平台团队干了一件大事：把一张盘根错节的管道链路图，逐步收敛成一套统一的数据底座。这不算一次漂亮的技术翻新，而是被 AI 项目逼到墙角后的重构。当时团队同时支撑推荐、搜索增强和大模型应用三块业务，数据链路从业务库到数仓，从数仓到特征库，从特征库到训练样本，再到模型服务，每一段都有独立任务在跑。同一个日志字段被抽取了六遍，同一份用户行为数据在三个集群里各存一份，每次排查数据口径问题都要拉上七八个人对线半天。AI 时代的数据工程，真正困难的不是某个组件不会用，而是整条链路在协同的时候太脆。

这篇文章不打算堆砌概念，重点是我在整个过程中沉淀下来的拆解思路、迁移路径和踩坑记录。内容包括 AI 时代数据工程到底变了什么、复杂链路失效的原因、统一数据底座的设计与选型、从旧链路逐步迁移的实操方法，以及底座和特征工程、模型训练、Agent 应用之间怎么打通。适合正在被 AI 数据管道折腾的数据工程师、数据平台负责人，以及想了解数据底座落地形态的算法工程师和技术管理者。

1. AI 时代数据工程面临的核心挑战

1.1 数据价值定义变了：从报表驱动到模型驱动

传统数据工程很长一段时间都在服务报表和分析场景。数据从业务库抽到数仓，按主题域建模，层层汇总到宽表，最后输出给 BI 工具或运营后台。这类场景的核心要求是口径统一、结果可追溯、延迟容忍度高。昨天的数据今天出来的报表，决策上完全能接受。

AI 时代完全不是这么回事。模型训练需要的数据是面向时序、面向样本、面向特征分布的。它要求的不是某一个指标算对没有，而是整批数据的统计特性、时间窗口、标签分布是否合理。一个推荐模型的数据管道如果某个特征在夜间回填时用了不同的口径，白天在线推理时用的又是另一套逻辑，模型效果会立刻出现波动。报表出错了可以第二天修，模型喂脏数据了，用户马上就能感知到推荐内容变差。

这种转变意味着数据工程的目标从交付报表变成了交付可用的模型资产。数据不再是事后统计的原料，而是直接影响线上智能体验的生产要素。数据链路的稳定性、一致性和可回溯性，从原来的运维指标变成了产品核心指标。

1.2 链路数量不是加法增长，而是乘法爆炸

过去一个数据团队维护的核心链路可能就十几条。业务系统到数仓，数仓到报表，外加几个数据同步任务。管道虽然多，但结构相对简单，每个数据工程师都能在脑子里记住整张 DAG。

AI 时代的数据消费方式把链路数量推到了完全不同的量级。同一个原始日志，既要做离线特征，又要做实时特征，还要回填训练样本；同一个订单表，既要进数仓做经营分析，又要进特征库给模型服务，还要生成负样本和正样本的对齐表。推荐、搜索、广告、风控、客服机器人、大模型微调，每个场景都有一套自己的数据加工逻辑。

我见过最夸张的一张数据血缘图，光中间层就有四百多个节点，其中一半以上是重复的解析和清洗逻辑。每个算法团队都习惯自己拉一份数据到自己负责的存储里，自己写一套处理代码。这种方式起步很快，但业务一多，链路之间互相依赖、互相覆盖，最后谁也说不清楚一条数据从源头到模型服务究竟经历了哪些加工。

链路数量变多了，链路之间的交互也变复杂了。某个任务凌晨三点跑批超时，影响的可能不是早上的报表，而是下午模型更新的特征版本。这种连锁故障，是传统数据工程很少需要考虑的。

1.3 AI 工作负载重新定义了数据需求

AI 工作负载本身对数据平台提出了很多新要求。首先是训练与推理的一致性。离线训练时用回放的历史特征，在线推理时从特征服务实时取特征，两边只要有一个特征的计算逻辑、缺失值处理、分位数裁剪不一致，模型的离线评估和线上表现就会出现巨大偏差。这个坑几乎每个做推荐或广告的团队都会踩一遍。

其次是样本的可复现性。模型调试过程中需要频繁回到某一天的数据快照重新训练，观察特征重要性或参数变化。如果底层的原始数据已经被覆盖，或者某个特征列被更新过，实验就无法还原。这要求数据底座具备时间旅行和版本管理能力，让数据像代码一样可以被 checkout 到任意提交点。

再就是流批一体化的压力。很多 AI 场景既需要批量回溯历史数据，也需要实时消费增量数据。如果离线管道和实时管道是两套独立的链路，数据处理逻辑必然出现分歧。统一数据底座需要提供同一份表的流式写入和批量读取能力，让离线特征和实时特征共享同一个 schema 和存储结构，而不是各建一套。

这些需求是传统数仓和传统数据湖单独都解决不好的，也是整个行业开始讨论湖仓一体和数据底座的根本原因。

2. 复杂链路为什么走不通了

2.1 复制链路是 SLA 的放大器

数据链路最典型的问题就是 Copy 太多。业务系统产生一份数据后，先被同步到 Kafka，再从 Kafka 落到数据湖，从数据湖清洗成 ODS，从 ODS 加工成 DWD，从 DWD 聚合出 ADS，从 ADS 同步到特征库，从特征库再导出训练样本。每一层都是一次物理复制，每一层都有自己的调度依赖和容错机制。

问题在于，链路越长，任何一个环节抖动都会向下游放大。我在团队里做过一次统计，一条用于推荐排序的特征链路，从原始埋点到模型训练一共经历了七个阶段，其中三次全量重算、两次增量合并。每个阶段的 SLA 如果都号称 99.9%，整条链路的有效 SLA 就已经不到 99.3%，也就是每个月至少有一天多的时间处于不可用或数据不完整状态。对一个线上模型来说，这是不可接受的。

更麻烦的是，复制出来的多份数据经常口径不一致。同一个"用户活跃度"字段，在数据仓库里可能定义成近七天登录次数，到了特征平台可能定义成近七天访问时长加权。算法团队发现问题后往往不会追溯源头，而是直接在样本里加工一份自己的活跃度特征，结果又制造了新的分叉。链路越复杂，口径碎片化越严重。

2.2 脏数据会被模型成倍放大

传统数据管道里的数据质量问题，通常表现为报表某个指标异常或某个维度缺失，一般靠数据质量规则巡检就能兜住。AI 场景下的脏数据问题隐蔽得多，也危险得多。

举个例子，我们曾遇到一个 CTR 模型的离线 AUC 始终比线上高两个百分点。排查了很久才发现，训练样本中的负样本生成逻辑依赖一份定时任务产出的曝光日志，这个任务偶尔会因为资源抢占延迟产出。延迟期间产生的样本里，大量点击事件因为还没到齐被误判成了未点击，导致负样本里混入了实际上会点击的正例。这种错误在单条样本上看几乎无法察觉，但累积到百万量级后，模型的排序行为明显被带偏。

还有更隐蔽的标签泄漏问题。某个特征在特征工程时无意中用到了未来时刻的窗口统计，离线训练时效果好得惊人，上线后效果断崖式下跌。这种问题在传统报表里根本不存在，因为报表不涉及未来数据。AI 的数据质量需要从字段级校验升级到样本级校验，需要实时监控特征分布、标签分布、样本时效，甚至需要做简单的模型敏感性测试来判断数据是否被污染。

2.3 成本失控：数据存了很多份，大部分时间在空转

复杂链路的另一个尖锐问题是成本。同一份用户行为日志，数仓一份、特征库一份、训练样本一份、算法团队本地调试再导一份，存储成本轻松翻四五倍。每次回填任务都是全量扫描这几个集群，计算资源被反复占用。

我们当时做过一次存储健康度检查，发现平台上 70% 以上的表在过去三十天没有任何查询或扫描记录。很多表是某个同学为了临时排查问题从生产库拷贝出来的，排完问题之后也没有清理。这种表在传统数据平台里也很常见，但 AI 链路的表往往体积更大、列更多，一次全量拷贝可能占几百 GB 甚至上 TB，放任不管的成本相当惊人。

计算侧的问题同样严重。同一个特征工程逻辑，推荐组写了一套 Spark 代码，广告组用 Flink 又写了一套，搜索组为了快速上线直接写了一个 Hive UDF。三套代码处理同一份数据，每天各跑一遍，浪费的资源成倍增加。链路多、重复计算多、口径分叉多，就是复杂链路阶段成本居高不下的直接原因。

3. 统一数据底座的设计思路

3.1 底座的本质：一份数据，多端共享

所谓统一数据底座，很多人第一反应是上一个新的数据平台，把所有数据都迁过去。我的理解完全不同。底座的本质不是物理集中，而是逻辑统一。核心原则是一份数据，多端共享，通过统一的元数据目录、存储格式和访问接口，让数仓分析、特征工程、模型训练、在线推理拿到的是同一份可信数据。

我们在设计目标里明确了几条硬性要求。第一，同一份业务数据在底座里只保留一份主拷贝，其他消费场景通过共享表或视图来访问，不再各自复制。第二，所有加工逻辑对底层存储透明，批处理和流处理读写同一张表，不再维护两套数据。第三，全链路血缘自动记录，从原始表到特征表到训练样本，任何一次加工都能追溯。第四，权限与脱敏策略在基地这一层统一管控，不允许各团队绕过平台自己授权。

这几个要求看着简单，落地时牵扯到的组件和协作关系非常多。但如果没有一开始就定下这几条原则，很容易在建底座的过程中又造出一个新的数据孤岛。

3.2 底座的分层架构与核心组件

我们最终落地的底座主要分四层。

存储层以对象存储和分布式文件系统为基底，使用支持事务的开放表格式统一管理结构化表和半结构化文件。这一层的关键能力是 ACID 事务、快照隔离和时间旅行，保证多任务并发读写时不会读到半成品数据。

元数据与目录层是底座的"中枢神经系统"。所有表、字段、分区、文件、Schema 信息都收敛到一个统一 Catalog 中，对外提供一致的元数据 API。数据工程师、算法工程师、分析师都通过这一层找到自己需要的数据，而不是靠口头询问或者翻文档。

计算层负责批处理、流处理、交互式查询和机器学习训练。批处理跑 Spark，流处理跑 Flink，交互式查询用 Trino，训练框架直接读取存储层的数据。这一层和应用层解耦，计算引擎可以按需伸缩，不需要跟随存储迁来迁去。

服务层面向具体业务场景，提供 SQL 查询接口、特征服务接口、数据导出接口和元数据 API。推荐场景从这里获取特征，BI 场景从这里查数，模型服务从这里完成在线特征的组装。

四层结构听起来并不复杂，真正的复杂度都在层与层之间的协议和一致性上。存储层的事务能力、计算层对表格式的支持程度、服务层的延迟指标，每一项都需要在选型阶段仔细验证。

3.3 技术选型：湖仓一体为什么适合 AI 时代

统一数据底座的技术选型，我们几乎没怎么犹豫就定了湖仓一体路线。原因很直接：AI 工作负载既需要数据湖的灵活性和低成本存储，也需要数据仓库的事务能力和高性能查询，湖仓一体正好补上了中间这块短板。

存储格式上，我们调研过 Delta Lake、Apache Iceberg 和 Apache Hudi，最终选了 Apache Iceberg。核心考量是 Iceberg 在快照隔离和时间旅行上的实现最干净，Schema 演进能力也最灵活，而且对 Spark、Flink、Trino 以及机器学习训练框架的适配都比较成熟。Hudi 在数据入湖的实时性上更强，但我们实时链路主要走 Kafka 到 Flink 到 Iceberg，需求集中在批量回放和一致性读取，Iceberg 更贴合。

这里也想提醒一点，湖仓一体的"一体化"不是让一套引擎干所有事。我们的架构里，批处理、流处理、交互式查询仍由不同引擎承担，只是因为大家读写同一套 Iceberg 表，数据不再需要跨系统拷贝。这比强行要求 Flink 同时把批处理也做了要务实得多。

选型过程中最容易忽略的是权限体系。底座上会同时跑分析师查询、算法训练任务和线上特征服务，不同角色的访问权限必须精确隔离。我们直接基于统一 Catalog 的授权模型，接入了公司的统一鉴权平台，避免后期为了权限问题再补一层代理。

4. 从复杂链路迁移到统一底座的实操路径

4.1 第一步：先画数据流向图，别急着搬数据

一个常见的错误是底座平台刚搭好，就急着把数据往里灌。我们吃过这个亏，第一批迁移的表在目标平台跑起来后才发现，源头还有两个兄弟任务在同步同一份数据，底座里的数据根本不是唯一版本，整个双跑对账过程混乱无比。

正确的做法是先用两到三周做一次彻底的数据流向盘点。把每一条业务链路从源端系统开始梳理：原始数据落在哪里，经过哪些任务加工，中间复制了多少份，最终被哪些下游消费。画完这张图后，你会很清楚地看到哪些表是真正被高频使用的，哪些表只是某个人临时拷贝的中间产物，哪些任务其实已经没人依赖只是调度器还在每天跑。

盘点的输出是一张迁移优先级列表。我们当时把表分成了三类。第一类是核心高频表，直接影响推荐和模型训练，优先迁移但必须做最充分的验证。第二类是普通分析表，迁移风险低，可以批量处理。第三类是僵尸表和重复表，直接在源端下线，不在底座里重建。这三类表在整体存量里的比例大致是 2:6:2，处理完第三类表之后，存量存储一下就降下来了。

4.2 第二步：统一元数据与数据目录先行

物理数据可以晚一点搬，元数据目录必须最先落。所有迁移到底座的表，都要先注册到统一 Catalog 中，填充表描述、字段说明、数据负责人、更新频率、SLA 要求等基本信息。这一步看着琐碎，却决定了后续治理体系能不能跑起来。

我们当时成立了一个临时的数据治理小组，每个团队抽调一名数据工程师，集中花了两周时间把全平台上千张活跃表的元数据补齐。这个过程很痛苦，因为很多表根本没有 owner，已经离职同学的账号下面还挂着几十张生产表。补元数据的过程中顺便清理了权限和依赖，把那些无主表全部下线或转交。

另外一个好用的技巧是给每张表在 Catalog 里打标签，比如"核心链路""训练样本""特征来源""临时表"。标签可以直接作为迁移任务排期和权限管理的依据。比如带有"训练样本"标签的表，迁移时必须做完整的回归验证；带有"临时表"标签的表，统一设置三十天自动过期。

4.3 第三步：链路重构，从"搬数据"转为"共享表"

复杂链路时代，每个团队都习惯把数据往自己地盘上搬一份。迁移到底座后，第一件事就是扭转这种习惯，建立共享表机制。所谓共享表，就是同一份数据只存在一个物理位置，各团队通过授权后的引用方式访问，不需要再次拷贝。

实际操作中有两个很管用的手段。一是用视图来兼容旧有消费方式。很多下游任务直接读取某个固定库表名，如果只改存储不通知下游，必然引发大面积故障。我们在迁移时先创建同名视图指向底座真实表，让下游无感切换，等消费全部稳定后再慢慢把视图替换成物理表或统一逻辑视图。二是把原来靠管道复制的加工动作改为计算下推和物化视图。比如原来特征组每天把订单表从数仓拷贝到特征库，再在特征库算特征。底座化之后，特征直接在订单表之上每天增量计算，结果落在特征表里，省掉了一次全量拷贝。

这里有一个需要特别注意的点：迁移不是简单地把表文件搬过去就完了，SQL 任务的方言迁移、资源队列配置、调度依赖改造每一项都有工作量。我们把每个迁移任务拆成了数据迁移、任务改造、回归验证三个阶段，每个阶段都设了明确的完成标准，避免迁移过程中影子链路无限期并存。

4.4 第四步：双跑、灰度、切流、断旧

底座迁移最稳妥的节奏是双跑一段时间再切流。每条核心链路迁移后，先在底座和旧平台同时运行相同的任务job，产出的数据进行自动对账。对账维度包括记录数、关键字段的汇总值、抽样明细等。对账差异为 0 且持续一周，才允许把下游消费切到新链路。

灰度切换按业务影响范围分批执行。影响面最小的分析师报表先切，业务影响中等的离线特征链路第二批切，直接面向线上推理的实时特征链路最后切。每一批切换都设置回滚预案，一旦出现数据异常或任务失败，立即把消费切回旧平台，同时保留双跑任务继续产出。

双跑阶段最需要注意的是资源成本。两边跑同样的任务，计算资源等于翻倍。我们当时的处理是优先保证旧平台任务运行，新底座任务放在低峰期执行，并利用 Iceberg 的增量读取能力，尽量把对账任务做成增量式，避免每天全量重算。

断旧的条件是：新链路稳定运行超过两周，并且至少完整跑过一轮月度级别的全量回溯任务。这时候旧平台的表进入只读状态，再观察一周，确认没有下游依赖后完成下线。我们在断旧阶段清理掉的旧表有一大半是几个月没被访问的僵尸表，真正需要保留的备份很少。

4.5 第五步：治理与安全体系同步上线

数据底座如果没有配套治理，很容易在建好的新平台上又长出新的链路乱麻。我们在底座上线同期，把数据治理的几项基础能力全部补齐。

数据质量方面，搭建了覆盖表级、分区级、字段级和样本级四个维度的监控体系。表级监控关注产出时间和记录数波动，分区级监控关注分区完整性和同步延迟，字段级监控关注空值率和枚举值分布，样本级监控针对训练样本增加特征分布差异检测，每天自动比对最新样本与历史样本在关键特征上的分布差异。这条样本级监控后来多次提前发现了链路问题，挽救了模型的线上效果。

权限与安全方面，底座内所有表的访问都需要通过统一权限平台申请。敏感字段统一脱敏，算法训练任务默认只能读取脱敏后的特征表，需要读取明文的场景单独审批。血缘系统基于 Catalog 的元数据自动构建，支持从一张原始表追踪到所有下游特征和样本，也支持从一张样本表反查它的全部上游来源。

5. AI 工程实践与数据底座的融合

5.1 特征平台：在线离线一致性的解法

模型特征的一致性问题是 AI 数据链路的顽疾。复杂链路阶段，离线特征和在线特征两套逻辑并存，哪怕代码完全一样，只要底层存储的数据不同，结果就会产生偏差。统一数据底座为这个问题提供了一条干净的解法和路径。

我们的特征平台直接建立在底座之上。离线特征通过批处理任务从底座明细表计算后写入特征表，在线特征由 Flink 任务消费同一份 Kafka 原始数据，经过同样的特征计算逻辑写入在线特征存储。两边共用同一个特征配置中心，所有特征的计算逻辑、参数和版本号都从这里下发，避免了各写一套的混乱。

特征配置中心上线后，我们要求算法团队在发起模型实验之前必须确认特征版本。实验平台会自动比对训练时使用的特征版本与当前在线特征版本是否一致，如果不一致直接阻断实验。这个机制看起来严格，却避免了很多次因为特征不同导致的无谓调试。

5.2 训练样本与数据版本：让实验可复现

模型训练的可复现性越来越重要。你没法用一套过了一周就无法重放的数据，去支撑快速迭代的实验。底座的 Iceberg 表天然支持时间旅行，我们借此建立了训练样本的版本管理机制。

每次模型训练前，训练框架会读取指定时间戳对应的数据快照。即使原始业务表后续被删除或更新，Iceberg 的快照仍然保留，训练实验可以随时回放到任意快照点。这个能力上线之后，算法团队调试模型的效率明显提升，以往因为数据覆盖而出现的实验不可复现问题基本绝迹。

样本管理上，我们为每份训练样本记录了快照时间、特征版本、数据抽取 SQL、原始表清单和生成时间。这些信息统一写入样本元数据表，训练平台在启动任务时自动关联。如果后续发现某个样本存在质量问题，可以通过血缘快速定位到所有使用这份样本训练的模型，及时安排重新训练。

5.3 Agent 与 RAG 应用的数据闭环

大模型应用的兴起，给数据底座带来了新的数据类型和数据消费模式。RAG 场景需要把文档、知识库内容切分、向量化后存储；Agent 场景需要维护会话历史、工具调用记录和反馈数据。如果这些数据仍然由各业务团队自行搭建管道，很快又会形成新的烟囱。

我们把 RAG 的知识数据也收纳进了统一底座。原始文档进入存储层后，通过统一的切分和向量化管道生成向量和文本对应关系，向量索引独立存储在向量数据库中，但原始数据、切分片段、向量化的版本信息都登记在 Catalog 里。这样知识数据和企业内部业务数据天然共享同一套治理和权限体系。

更重要的是反馈闭环。Agent 应用的每一次对话效果、用户反馈、工具调用结果都会回流到底座，经过处理后变成强化学习或模型微调的训练数据。这个过程如果缺少统一底座，反馈数据只会散落在各类日志中无法有效利用。底座化之后，反馈回流可以复用已有的特征表和样本表链路，数据价值被完整沉淀下来。

5.4 模型评测与管理：底座的另一个隐藏价值

模型评测离不开数据集管理和评测结果追踪，这两件事本质上都是数据工程问题。我们基于底座建立了统一的评测集管理机制。每一个评测数据集都登记在 Catalog 中，标注来源、创建时间、适用任务类型、版本号，评测过程产生的中间结果和结论也沉淀为数据表。

这样做的价值在于，评测数据不再散落在各算法工程师的本地目录或临时表里。团队做模型选型时，可以直接通过服务层查询到所有候选模型在同一评测集上的历史效果，方便横向比较。模型上线后，系统还会自动采集线上与评测集上的指标差异，一旦偏差超过阈值就触发提醒，帮助我们及早发现数据漂移或样本分布变化。

6. 常见问题与排查技巧实录

6.1 高频问题速查表

迁移和常态化运行过程中，我们整理了一批高频问题。下面这张表按症状、可能原因、排查路径和解决建议四列做了梳理，希望能帮大家少走弯路。

6.2 我踩过的最深几个坑

第一个坑是迁移初期没有对源头数据做版本冻结。我们迁移一张订单明细表时，源集群里另一个维护任务同步对表做了字段更新，导致双跑对账连续三天差异，查了半天才发现是源头数据变了。后来所有迁移任务启动前，必须先确认源表进入只读状态，或者记录源表快照的版本号，之后对账就有了明确基准。

第二个坑是流批一体被想简单了。我们曾经试图让一套 Flink 任务同时承担实时特征计算和离线特征回填，结果把任务复杂度推到很高，出问题时两边一起挂。最终我们保留了离线批处理和实时流处理两条执行路径，仅在存储层和配置层做统一，执行引擎各干各的事。这反而让我们更快实现了目标。

第三个坑是权限模型设计得过于复杂。最初我们想做到表内字段级、行级甚至单元格级的细粒度权限控制，结果发现对训练任务来说频繁的权限校验会明显拖慢作业启动速度。后来收敛为表级和字段级两层权限，行级权限仅用于少数敏感数据场景，整体性能和安全性之间达成了平衡。

第四个坑是样本级质量监控上线太晚。我们最早只做了表和字段级的监控，模型效果下降后花费很大精力排查，最后才发现问题出在样本里的标签延迟上。如果在底座化改造初期就同步上线特征分布差异检测，这类问题会早很多天暴露。

这轮底座化改造做完之后，我最大的感受是，数据工程在 AI 时代拼的已经不只是调度和清洗能力，而是数据资产的组织能力。把一份数据管好、把血缘理清、把版本留住，让所有智能应用都从同一套可信底座上取数，整个数据团队的价值也会从支撑角色变成智能业务的基础设施。如果你也正被复杂链路折磨，建议不要急着上更多工具，先花时间把数据和链路盘点清楚，底座化的收益远比你预想的大。