AI应用时代的数据工程：从复杂链路走向统一数据底座

打开半夜的告警群最常见的消息不是“模型效果又有提升”而是“特征延迟了”“样本对不上”“知识库索引又没更新”。这两年AI应用从问答机器人做到Agent、从RAG做到多模态不少团队把大半精力放在模型选型和提示词工程上可真正到了上线阶段卡住进度的往往不是模型本身而是底层那套越来越拧巴的数据管道。我自己就踩过这么一回一个智能问答系统文档切片、向量化都做完了结果线上检索效果一直不对。排查了一整天最后发现知识库增量同步任务在两周前就静默失败生产环境检索的始终是旧索引。这种问题不是个例。说白了AI时代的数据工程正在经历一轮从“能用”到“可靠、可解释、可服务化”的强制升级而绝大多数团队手里的基础设施还停留在给人看报表的阶段这就造成了今天普遍存在的断层。这篇内容我想围绕“复杂链路”和“统一数据底座”这两个关键词把我这几年在数据平台、AI应用落地过程中看到的问题、踩过的坑、以及最终沉淀下来的迁移思路原原本本讲一遍。适合正在做AI应用开发、数据平台建设或者正被“数据链路常年告警”折磨的工程师和数据团队参考。1. AI应用井喷之后数据工程最先承压模型调优是在抬天花板数据工程是守地板。这句话我在不同团队里反复验证过。很多算法同学不理解为什么离线评测那么漂亮一上线效果就稀碎。说白了一半以上的“模型问题”深挖下去都是数据问题。1.1 很多所谓模型问题深层其实是数据问题举一个真实案例。某个营销推荐项目里算法同学用离线三天的“用户-商品交互表”做训练样本线上推理服务却直接读Kafka里的实时点击流。两边对“已读”这个行为的定义完全不一样离线样本里做了去重在线链路里没去重。模型离线AUC能到0.85上线之后点击率却纹丝不动。查来查去不是模型结构不够先进不是特征数量不够多就是训练和在线消费的数据没有对齐。这种不一致在复杂链路里几乎必然发生。旧体系下数据工程师按报表需求建宽表算法工程师按自己的理解从数仓拉数、加工特征两边各维护一套逻辑时间一长必然漂移。AI应用越复杂这种漂移被放得越大。尤其现在Agent开始自主调用工具、自主决策它拿到的数据如果本身就是脏的、错位的那后续所有推理、规划、执行都是在错误地基上盖楼。1.2 AI工作负载对数据栈的约束和人看报表完全不是一回事十年前的数据工程服务对象是BI报表消费方是人。人看到数字异常会自己判断“是不是统计口径变了”能容忍T1甚至T2的延迟偶尔数据有缺口也可以手动补救。但现在AI应用的数据消费方是机器推荐系统、风控模型、Agent调度器它们拿到数据就直接做决策没有“人肉兜底”的过程。这对数据底座提出了几条硬约束时效性上从小时级、天级推进到秒级甚至毫秒级语义上必须说清楚每个字段的口径、单位、版本不能靠猜链路上要有完整的血缘和可重放能力出了问题能追溯、能回算访问方式上要能通过API、特征服务、向量检索这些形式被程序消费而不是只会被SQL查询。人看报表的管道模型天然不满足这些约束。这也是为什么但凡AI应用做大了数据团队就会发现自己每天不是在搞算法而是在跟链路复杂性和数据一致性搏斗。2. 复杂链路是怎么一步步失控的没有哪个团队是故意把数据链路搞复杂的但走到一定程度链路就会自己长出“触手”。今天加一个同步任务明天补一张中间表后天为了修复某个线上问题再插一道清洗逻辑用不了一年链路就会复杂到没人说得清楚。2.1 链路越长故障定位越像玄学一个中等规模公司的智能应用数据链路往往长成这样业务库通过CDC进Kafka实时特征走Flink离线部分通过DataX或者Spark同步到数仓数仓内部再从ODS到DWD一路加工到DWS、ADS最后算法团队从ADS拉宽表或者再加工成训练样本和特征。单看每一环节好像都挺合理连起来就是一个巨大的故障放大器。我碰到过最典型的例子上游某个业务表把一个字段从字符串类型改成了Long本来是一个很常规的小改动因为血缘不透明没有人知道影响面。结果下游Hive SQL解析失败基础表任务挂掉依赖它的十二个任务连环失败最后引发的是算法同学在群里喊“特征延迟了”。排查这个故障三个人花了大半天。链路每多一层故障传播的概率和定位的成本都在指数级上升。2.2 特征重复建设每个团队都在造自己的轮子复杂链路带来的另一个严重问题是特征的重复建设。同一个“用户活跃度”推荐团队按自己的理解建一张表营销团队又按另一种口径建一张表Agent应用需要用户画像时再自己用SQL现算。三份数据三种结果存储和计算成本翻了几倍最要命的是口径不一致导致线上表现互相打架。我在不同团队里见过太多这种场景大家不是不想复用而是根本不知道别人已经建过类似特征或者知道了也不敢用因为说不清那个特征到底是怎么算出来的、更新策略是什么。特征没有统一注册、统一解释、统一版本管理就是一笔糊涂账。AI应用依赖大量特征这个痛点会被放大到不可忽视的程度。2.3 批流分裂和数据副本慢慢形成一片“数据迷宫”还有一个隐藏很深的失控点批流分裂。同一个指标离线数仓一天算一次实时计算每秒都在出结果两边业务口径、去重逻辑、时间窗口都略有差异。最终消费者问“今天的活跃用户到底是多少”离线报表给一个数实时大屏给另一个数算法任务跑出来可能又是第三个数。为了对齐数据各团队又习惯性地复制数据到自己这边加工于是一份数据被拷贝到分析库、算法库、特征库、缓存、向量库到处都有影子。到后面做治理时光是想搞清“这份数据从哪来、谁在用、哪个是最权威版本”就像在考古。这已经不是工具问题而是数据资产的复杂度膨胀问题。也就到了该谈“统一数据底座”的时候了。3. 统一数据底座到底“统一”了什么统一数据底座这个词被提得很多但很多团队的理解还停留在“把表都堆进一个数据湖里就是底座了”。这是一个很大的误会。真正值钱的不是把数据物理上放到一个地方而是把数据资产的“定义、口径、访问方式、生命周期”统一起来。3.1 底层的“统一”是逻辑统一不是物理集中我的实践共识是统一数据底座应该分层看。最底层是湖仓一体的存储层同时支持结构化表、非结构化文档和向量数据上面是统一计算层批处理和流处理共享同一套元数据再往上是统一数据目录、统一血缘、统一质量规则再上面是语义层把物理表和业务概念解耦最顶层是数据服务层提供在线API、特征服务、向量检索、文件导出这些标准的消费方式。这套架构里数据没必要全部物理搬到一个集群。各业务系统可以继续保留自己的库但逻辑上的目录、口径、Owner、血缘、服务出口必须收口。物理分散、逻辑统一才能既避免“把所有鸡蛋放在一个篮子里”又消除“各搞一套、互相看不懂”的乱象。拿乐高积木打比方以前每个团队自己捏泥巴做零件尺寸形状都不兼容底座要做的是提供统一规格的标准化积木谁需要谁拼装拼出来还能互相咬合。3.2 面向AI应用、Agent和模型部署的底座新能力底座的服务对象变了能力结构就得跟着变。现在我的团队评估数据底座主要看它能不能支撑这么几类AI数据消费方式。RAG知识库是一种典型。文档要经过清洗、切片、向量化还要做增量更新、版本管理这些本质上是数据工程问题。如果每个AI项目都自己搭一套文档管道结果就是一遍遍重复造轮子而且质量参差不齐。Agent工具调用是另一种。Agent要正确调用工具依赖的是工具名称、参数描述、返回值结构这些元数据是否足够准确。这些元数据应该从统一数据目录里同步而不是让应用开发人员手工敲一段描述塞给Agent不然改个字段名Agent就乱套了。还有模型训练和在线推理的一致性。训练时用离线批量计算的特征推理时在线实时算两边逻辑一旦没有强约束效果必然打折。Feature Store在这里的价值就是同一份特征定义同时驱动离线训练和在线读取避免我前面说的“离线去重、在线不去重”这类低级但致命的偏差。至于Spring AI、LangChain这些应用框架它们能不能顺畅地消费数据底层依赖的还是接口契约稳不稳定语义层描述清不清楚。3.3 更关键的是用“数据产品”替代“管道工具”思维统一底座容易做成“又上一个数据平台”但真正该变的是思维范式。复杂链路是管道思维一个需求拉一条临时管道用完就扔在那儿长草统一底座是产品思维每一份核心数据都是一个数据产品有明确的Owner、Schema、SLA、质量规则、版本记录、访问方式和使用示例。我内部定义数据产品至少要有八样东西负责人、字段说明、血缘信息、质量规则、更新SLA、版本号、访问入口、示例代码。没有这八样一份数据表就不能对外发布只能算临时文件。把数据当产品来管AI应用开发者才能做到自助式取数、按契约消费而不是每次都要私聊数据工程师“这个字段什么意思”“那张表可不可以给我开权限”。统一说到底统一的是资产定义和协作机制不是非得把所有人都塞进同一个系统。4. 从复杂链路迁移到统一底座的落地路线统一底座不是买一套软件装上去就算完它是一个从存量泥潭里一步步抽身、把新体系慢慢立起来的过程。这里我梳理了一条经过多次实践验证的迁移路线给准备动手的团队一个参考。4.1 第一步盘点全域数据资产先把血缘画出来不盘点就没有发言权。第一步要做的事是全域数据资产盘点把现状这个“谜团”先摊开。我的做法是从调度平台抓取所有任务依赖自动生成初版血缘图谱再用数据目录扫描所有表的字段、Owner、最近访问时间对于口径不明的表可以请有经验的数据工程师人工补充也可以借助现成的大模型工具辅助读旧SQL、推测业务含义把注释和标签补上最后产出一份现状清单标出哪些数据被重复建设、哪些链路最长最脆弱、哪些数据没人维护。这里要提醒一句盘点不是做成完美项目控制在两周以内目标是找出前三个“高重复、高成本、低可靠”的痛点数据域为下一步选场景做准备。4.2 第二步选准第一批迁移场景别想一口吃成胖子很多团队失败不是因为方向不对是因为想一次把所有管道全部重写。统一底座一定要选“北极星场景”切入标准很简单被多个团队复用、当前链路最长最容易出问题、对AI应用影响最大、同时迁移难度适中。我比较推荐的第一批场景通常是用户实时特征服务或者RAG知识库统一接入。举个例子如果公司里有三张以上“用户活跃度”相关特征表就可以考虑做统一特征服务把所有用户特征收口到Feature Store统一命名、统一粒度、统一版本实时和离线共用一套特征定义对外只提供一个API入口离线训练拉历史、在线推理查实时都从这个服务走。迁移完一个这种场景团队就能切实感受到“不再到处救火”的差别。4.3 第三步为数据定义契约和两级SLA复杂链路最缺的是规矩统一底座首先要立的就是数据契约。契约里写清楚表名和字段命名规范、数据类型、值域范围、更新频率、质量规则、负责人、消费方列表。字段“已读”到底指什么、去不去重这些都必须白纸黑字写进契约而不是留在老员工的脑子里。SLA要分两层。平台级SLA管管道本身任务要成功、要在指定时间窗口内跑完、资源不能被打爆产品级SLA面向数据消费者承诺数据新鲜度、可用性、质量门槛。两级SLA分开定义才不会出现“管道跑得好好的但AI应用拿到的数据口径不对”这类尴尬。4.4 第四步渐进式收敛不搞“推倒重来”我极其反对一个周末把旧管道全停掉、直接切换新底座的做法。历史数据要回填口径要验证消费方要适配这些都不可能瞬间完成。最稳妥的做法是“新旧并行、对账验证、灰度切流”。具体操作可以是新管道上线后旧管道继续跑一到两周每天自动对账比对核心字段的count、sum、去重数、主键完整性这些关键指标对账通过率超过阈值比如99.99%才开始灰度切流量切量时按消费方分批放行先从占5%流量的内部测试应用开始观察一段时间再逐步放大。整个过程中新需求必须走数据底座存量需求按数据域分批迁移。秩序不是靠一次切换建立起来的是靠“新项目走新路、老项目限期搬”的机制慢慢养成的。4.5 第五步底座要成为内部产品最好还是能被AI使用的产品迁移最终能不能成功取决于一个朴素标准数据工程师和算法工程师觉得“用底座比各搞各的更省事”。要做到这一点底座必须自助而且最好是能被AI进一步使用的。底座应该提供统一数据目录和语义搜索最好支持对话式查数用自然语言提问就能推荐数据表、解释字段口径提供统一的SQL/API访问入口算法和应用通过OpenAPI就能拉数据不用再申请各种临时账号内置可观测性数据质量状况、接口成功率、调用方排行都要一目了然。更进一步底座应该把LLM能力用起来根据血缘自动解析一张表的下游影响面辅助生成ETL模板对异常数据给出排查建议。这也是我最近经常和数据团队聊的“AI工程实践”方向——让数据底座本身成为AI友好的平台而不仅仅是给AI提供数据。5. 实践中踩过的坑和守住的原则讲完方法论照例说说坑。统一数据底座这件事理论看着不难落地到处都是暗礁。我自己就踩过几个比较典型的坑写出来给大家避一避。5.1 坑一统一底座建成了新的复杂链路第一次做底座时团队很容易用力过猛。今天看到好的编排工具上一个明天发现元数据平台缺能力再补一个后天又觉得数据质量必须自动化又引一套。结果底座自己长成了一个比原先更复杂的微服务大杂烩每个组件之间还要做集成、同步、权限打通运维成本比原来还高。我现在守的原则是底座的最小闭环能跑就不要急着加组件新增任何组件必须有明确的业务驱动力而不是“别人都有我也要有”优先选择与现有技术栈匹配的方案减少集成成本。还算有效的做法是如果某个新组件引入半年没有实际用户就直接关停。没有用户的功能就是负债放着只会越长越烂。5.2 坑二以为AI能自动解决数据质量问题这两年大模型很火有些团队天真地认为“数据脏就让大模型自动洗”。大模型确实能辅助做很多事情根据历史SQL生成质量规则、给异常数据打标签、解释一个突然的变化。但数据质量和业务逻辑强相关尤其涉及交易、风控这类强审计场景AI最多能做到“发现问题、推荐处置方案”不能完全替代规则校验和人工复核。我的建议是“AI辅助规则保险”组合。AI负责发现那些规则覆盖不到的边缘异常并且给出推荐动作规则引擎负责守住底线明确不符合质量门禁的数据坚决不允许流到下游。质量门禁设计时宁可保守也不能让坏数据静默通过AI应用被错误数据带偏比管道晚跑几分钟要严重得多。5.3 坑三只统计算不统服务还有一种常见误区是底座建了半天只把离线表收进统一数仓了但AI应用还是要自己去拉数、切分、缓存、算特征统计层统了服务层没统。AI是程序不是人它没法去查一个文档再决定要不要用这张表。底座要真想支撑AI应用服务化能力就必须单独建。我现在会把数据服务的接口当成一等公民来设计能在线查询就提供查询接口能批量导出就提供导出接口能订阅推送就开事件订阅需要时间回溯就要支持回放。内部甚至可以建一个“数据服务注册中心”所有服务接口统一登记AI Agent要访问数据时先来这里发现、再按契约调用。只有到这一步底座才真正算“服务化”了。5.4 持续治理机制比一次性建设更重要最后一个坑是运动式建设。团队集中火力干三六个月底座上线大家庆祝然后各回各家。半年后再看新的临时管道、新的口径分叉、新的孤岛又冒出来了。因为业务永远在变底座不可能一劳永逸。所以持续治理机制必须一开始就设计进去。我的做法是把数据资产登记做成强制流程新增数据资产必须先注册、后上线不注册就不给调度资源定期做血缘评审和口径对账把“埋了很久没人管”的表剪掉数据团队和算法团队轮值做数据治理值班谁的数据出了问题谁负责修到闭环。数据底座本质上是个生命体要给它配一个不停止的维护循环。6. 最后一点个人体会做了这么多年数据工程我越来越觉得统一数据底座这件事本质上不是在买工具、建平台而是在给AI应用造一个“数据操作系统”。不同AI应用跑在上面共享同一套数据资源、同一套口径标准、同一套服务接口才能保证它们不会各说各话、互相打架。这个系统不可能一夜建成也没有“彻底完工”的一天它需要在业务演进里持续迭代。我把自己的底线总结成了一句话给AI消费的数据必须是可解释、可回放、可重算的。可解释是任何字段都能说清口径来源可回放是任何时刻都能还原当时的数据快照可重算是任何指标都能用同一套逻辑重新算出来。守住这三条前面提到的种种链路问题大多会在萌芽阶段就被拦住。数据工程没有银弹但把底座做扎实绝对是我见过的最接近答案的做法。