过去一年我所在的数据平台团队干了一件大事把一张盘根错节的管道链路图逐步收敛成一套统一的数据底座。这不算一次漂亮的技术翻新而是被 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 高频问题速查表迁移和常态化运行过程中我们整理了一批高频问题。下面这张表按症状、可能原因、排查路径和解决建议四列做了梳理希望能帮大家少走弯路。症状可能原因排查路径解决建议在线推荐效果与离线评估差距大在线特征和离线特征计算逻辑不一致比对特征配置中心中同一特征在批处理和流处理任务的逻辑统一从特征配置中心下发计算逻辑上线前阻止版本不一致的实验训练样本中出现未来数据特征计算窗口包含未来时刻用数据版本回溯检查特征生成时间与样本时间特征任务增加时间窗校验在训练前对特征做泄漏检测回填任务耗时成倍增加旧链路和新底座任务并发双跑检查两套任务是否同时扫描同一份全量数据双跑期间新底座任务使用增量读取错峰调度数据对账出现零星差异上游源表在迁移期间被修改比对源数据快照与底座快照的生成时间建立迁移期间的源表冻结机制或对上游变更做版本追踪底座的表越来越多但很多没有 ownerCatalog 注册时没有强制填写负责人检查 Catalog 元数据的 owner 字段上线强制 owner 填写定期清理无主表和僵尸表6.2 我踩过的最深几个坑第一个坑是迁移初期没有对源头数据做版本冻结。我们迁移一张订单明细表时源集群里另一个维护任务同步对表做了字段更新导致双跑对账连续三天差异查了半天才发现是源头数据变了。后来所有迁移任务启动前必须先确认源表进入只读状态或者记录源表快照的版本号之后对账就有了明确基准。第二个坑是流批一体被想简单了。我们曾经试图让一套 Flink 任务同时承担实时特征计算和离线特征回填结果把任务复杂度推到很高出问题时两边一起挂。最终我们保留了离线批处理和实时流处理两条执行路径仅在存储层和配置层做统一执行引擎各干各的事。这反而让我们更快实现了目标。第三个坑是权限模型设计得过于复杂。最初我们想做到表内字段级、行级甚至单元格级的细粒度权限控制结果发现对训练任务来说频繁的权限校验会明显拖慢作业启动速度。后来收敛为表级和字段级两层权限行级权限仅用于少数敏感数据场景整体性能和安全性之间达成了平衡。第四个坑是样本级质量监控上线太晚。我们最早只做了表和字段级的监控模型效果下降后花费很大精力排查最后才发现问题出在样本里的标签延迟上。如果在底座化改造初期就同步上线特征分布差异检测这类问题会早很多天暴露。这轮底座化改造做完之后我最大的感受是数据工程在 AI 时代拼的已经不只是调度和清洗能力而是数据资产的组织能力。把一份数据管好、把血缘理清、把版本留住让所有智能应用都从同一套可信底座上取数整个数据团队的价值也会从支撑角色变成智能业务的基础设施。如果你也正被复杂链路折磨建议不要急着上更多工具先花时间把数据和链路盘点清楚底座化的收益远比你预想的大。