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

AI 系统越做越多、开发速度越来越快，为什么数据链路反而越来越长，数据工程也越来越复杂？

AI 系统增多，数据工程复杂度为何同步攀升？

Databend 今年接触到的一些客户，都在从事 AI 可观测性相关工作。这些项目给了我们很多启发：AI 进入企业之后，系统数量为何不降反增？一方面，AI 显著提升了开发效率，系统迭代速度加快；另一方面，相伴而生的数据工程也在变得日益复杂。

今天，我就围绕这个问题与大家展开讨论。这些实践不仅适用于模型公司，对制造业以及其他传统行业也颇具参考价值。

传统的数据工程链路通常较长。以模型应用为例，数据从模型 API 产生，经过 Tracing、Kafka、日志库和调度脚本，最终形成 Eval Dataset，或者进入 BI 系统供前端使用。

一旦将这串链路放入真实的大规模业务环境，复杂度便会迅速攀升。数据可能分散在火山云、阿里云、华为云等不同厂商的平台上，需要在不同云、不同数据库和多套脚本之间来回搬运、复制，同一种加工逻辑也可能被重复实现。

此时，问题已不仅是链路长、组件多、成本高，数据口径的统一也变得异常困难。在如此复杂的工程环境中，无论模型团队还是数据团队，想要获得一套可信、可复现的指标口径，都将面临严峻挑战。

如何量化模型与 Harness 的改动效果？

模型公司普遍会遇到一个问题：当团队进行 Prompt 或 Harness Engineering 时，如何证明某次调用链路的调整是有效的？改动之后，模型表现是变好了还是变差了？如果更换了模型，新模型相较于现有模型究竟有多大的性能提升？

这些问题无法仅凭主观感受判断，必须进行量化评估。

为此，Databend 构建了 Evot Demo——

trace.databend.cloud

这套 Demo 获得了模型和 Agent 企业的广泛认可，恰是它们所需的工具。Databend 已开始帮助这些企业构建 Evals 可视化能力。Evot 项目现已正式开源（https://github.com/evotai/evot），大家可在 GitHub 上下载并在本地运行。它能够清晰展示一次模型调用经过了哪些步骤、每步耗时、总执行步骤数，以及整条链路的完整过程。

然而，可视化仅是上层应用能力。真正的基础在于：如何将这些 Trace 数据持续写入湖仓，并加工成可供工程团队使用的 Eval Dataset。

我们常说，首先要获得一份可用的数据。有了数据，就有了评估一次发布和改动的客观依据。原始 Trace 必须经过加工，才能形成可供 LLM 研发和评测人员使用的数据集。

以往有人会嘲笑某些模型连 Tool 都不会调用。但当模型积累了足够多的真实调用数据并经过强化训练后，其工具使用能力会变得相当熟练。如今国内许多模型在 Tool Call 和企业内部 AI 任务处理上的进步非常显著，部分原因就在于相关的训练数据已日益丰富。

我们正在协助模型公司将上述数据收集、沉淀并提炼出来，用于强化训练，同时也服务于 Harness Engineering 的校验和迭代。

Agent Trace 的核心挑战：数据量巨大，JSON 结构持续变化

这条链路面临的最大挑战之一，是当 Agent 进入生产场景后，数据量会变得极为庞大。

前面讨论的很多 AI Agent 场景，数据量尚处于较小或可控范围，例如十几份文档，或者百万级以内的数据规模。而我们服务的头部模型企业，在 Agent 投产上线后，单次复杂任务可持续数小时，单条 Trace 达到 GB 级，Context Tokens 达到百万级，每天有近百 TB 数据持续入湖。

即便是在本地进行任务调试，并行运行十几个或二十个任务，也容易发现机器难以承载。进入生产环境后，系统还需持续处理来自上百乃至上千台服务器的数据。

这与工业制造中的机台数据颇为相似：数据量庞大、形态相对单一，但必须持续、稳定地完成清洗，才能高效地提供给下游使用。这也是我们处理 Trace 和 Evals 数据时最核心的工作之一。

另一个挑战在于** JSON Schema 会持续发生很大的变化**。不同模型之间，或同一模型的不同版本之间，JSON 结构可能迥异，字段会新增、缺失，数据类型也可能漂移。如何兼容上下游变化，确保模型在处理任务时不会因结构变化而报错，是一个非常现实的数据工程难题。

多云、多产品并存，数据被切割在不同平台

模型公司都在高速迭代，基本都属于不差钱的公司。因此，只要云厂商推荐产品，它往往都会快速采用，非常容易形成多家云厂家，多个组件，形成复杂的数据底座。从整体上看每个产品都有其长处，但产品越上越多，数据就越容易被切割在不同的云环境中。

当团队需要查询一份数据时，可能会发现三朵云里的结果并不一致，甚至无法确定所需的数据究竟位于哪一朵云上。随之而来的，是跨云流转、多组件衔接、脚本与调度，以及扩容与排障等一系列问题。

在我们接触这家公司时，已有三名程序员专门维护这套数据工程。他们每天疲于奔命，几乎无法安稳休息。与此同时，公司预判即将发布的模型可能会引爆市场，并且正在为上市做准备，数据规模和业务压力还将继续上升。

以统一入口和统一湖仓，重构整条数据链路

进入项目后，我们首先将不同平台上的 Trace 汇入统一入口。无论数据来自火山云、阿里云还是华为云，都会先进入统一的 Kafka，再持续写入 Databend Cloud。目前，Databend Cloud 支持业界主流的公有云平台。

数据进入 Databend Cloud 后，我们在平台内部依次完成校验与解析、字段抽取、语义归一、Trace 聚合、质量检查和服务表刷新，最终形成可供评测和业务使用的数据。Kafka 到 Databend 的接入由平台组件直接完成，后续加工也可在平台内自动运行，因此对人工的依赖大幅减少。

在实际项目中，"客户说这是 JSON"并不等同于它一定是合法的 JSON。我们经常会遇到这样的情况：一个 Array 中同时混入数字和字符串；本应转义或规范嵌套的位置出现额外的大括号；字段格式不符合标准等。这些数据无法通过正常校验，系统会将其标记出来，再交由人工处理。

完成校验和解析后，我们还会从原始 JSON 中抽取 Model、Prompt、Tool 等字段，将原来堆砌在一个 JSON 中的数据展开成可持久使用的宽表，再按

trace_id

经过这套流程，数据可以持续不断地被加工，并持续向外提供服务。

ELT 不仅是减少数据搬运，更在于获得完整血缘

业界经常讨论 ETL、ELT，甚至"NO ETL"。对于 Databend 而言，ELT 意味着数据在同一个湖仓中完成处理，从而极大地简化了数据处理链路。

当加工过程在统一平台内完成后，A 表的数据来源、B 表的生成逻辑、某个字段依赖的上游字段，都能够被记录下来，形成完整的数据血缘。

Databend Cloud 平台内置了血缘能力。打开一张表，可以看到它依赖哪些上游表；继续查看某个字段，还能看到该字段与哪些来源字段相关。过去散落在多套脚本和多个组件中的加工逻辑，由此变得可追溯、可解释。

这也是客户深感意外的一点：统一数据加工不仅减少了组件，更让数据从"能用"升级为"知道为何这样用"。

Warehouse 按需启停，存储与计算各自弹性伸缩

用户通常有明确的需求：每天 8:00 自动开启一个 Warehouse 对外提供服务；20:00 以后，若无请求则自动关闭。这样才能真正做到有需要时加载服务，无需要时停止计算。

这一案例之所以必须部署在云上，另一原因在于数据规模过于庞大。如果采用私有化部署，仅存储成本就可能让项目难以承受。客户每天产生几百亿条数据，压缩后规模依然非常可观，且许多数据至少需要保存 6 个月。

云上对象存储无需预先购买大量预留空间，按实际使用量付费，更适合这种持续增长、需长期保留的海量数据场景。

Databend 采用存算分离架构，同一份数据可按不同业务切分计算集群：摄入集群专门负责数据进入，服务集群负责对外查询，加工集群负责数据处理。各集群负载相互隔离，但共享同一份数据。

计算节点是无状态的，因此可根据实际负载自动扩缩容，也可按业务拆分为不同集群。既可以单独建立数据加工集群，也可根据实际情况让摄入集群承担部分加工任务。

从三个人疲于维护，到约半名全职人力即可运营

改造完成后，效果显著。原本需要三名人员加班加点维护的业务，后来仅需约半名全职人力（0.5 FTE），且一名实习生即可完成日常运营，人力投入约为原来的六分之一。

原来多组件之间需要人工处理时序衔接和数据维护；改造后，数据加工统一在平台内完成，异常情况可自动提醒，再按需处理。原本多套数据链路分别承载不同任务；改造后，每天近百 TB 数据可持续入湖，并统一汇聚到一处。

过去系统中有复杂的组件和各种接口，现在则由 Task 自动完成数据加工。Task 相当于平台内部的任务调度能力，任务报错后可被及时发现并按流程处理。

服务集群也可按时间自动启停。例如 8:00 开启，20:00 以后根据请求情况自动关闭；数据加载集群则可保持运行，继续实时接入数据。这样，摄入、加工和服务各自独立，不会因某一类负载影响整条链路。

从"接得住"到"变得动、跑得稳、用得好"

此次改造带来的收益可概括为四个阶段：接得住、变得动、跑得稳、用得好。

首先是接得住。客户原先之所以采用复杂的技术栈，是因为数据量过大，单一系统难以承载，只能不断寻找新的产品来应对。现在，只要数据是 JSON 格式，即可先写入 Databend Cloud。Databend Cloud 提供

VARIANT

其次是变得动。Warehouse 可根据负载拆分为不同业务集群，计算资源相互隔离。集群可按业务划分、按需配置算力，避免加工任务和在线服务互相抢占资源。

在数据编排方面，通常大数据团队会额外引入一套业务系统来做任务调度。Databend Cloud 提供 Stream 和 Task，Stream 可获取每张表的增量数据，由 Task 基于这些增量执行下游计算，无需额外开发一套增量识别和调度机制。

在典型链路中，产品改动后，真实 Trace 持续进入 Eval Dataset；团队可进行版本对比、回归下钻，最终支持发布决策。如果内部训练了一个新模型，也可让其重新运行历史数据，与历史结果比较，再通过模型评分判断是否达到预期。

企业内部也需要一套可量化的 AI 使用体系

Databend 在公司内部部署了一套类似 OpenRouter 的统一服务，为员工提供多种模型，并内置了自己的 Harness Engineering 能力。

收集完调用日志后，我们会将内部方案与 OpenCode、Pi 等不同 Agent 进行对比，评估我们的 Harness 是否有效，是否存在不必要的 Token 浪费。

很多人会抱怨，在 Claude Code 中仅说一句"Hi"，为何花费如此之高？这笔钱花得究竟值不值？有了完整的 Trace、成本和步骤数据，这些问题均可被量化，而不再只是凭感觉讨论。

平台还提供细粒度的权限管理和审计能力：谁连接了数据库、执行了什么 SQL、一次 SQL 请求了多少数据、消耗了多少计算和内存，均可从审计日志中直接查询。分析结果也可被共享，同时对核心数据和关键字段进行权限控制。

Kafka 一定是必需的吗？对象存储正在改变数据链路

我在云计算和大数据平台领域耕耘了五年多，日益强烈的一个感受是：在一些场景中，Kafka 甚至可能不再是必需组件。

这个观点听起来或许有些"反传统"。但对象存储本身具备 Notify 机制。如果所有应用都直接向对象存储写入数据，对象存储可以通过通知告知下游哪些数据发生了变化，系统只需持续消费增量数据即可。

过去在私有化环境中，我们常追求高并发、低延迟，希望以最少的成本获得最大的效能。但进入面向机器人和 Agent 的编程时代后，一些架构其实可以继续简化。链路少一层，就能节省一部分组件成本和运维成本。

对象存储还有一个特点：从全球不同地点向其写入数据，通常不收取写入费用，因此很适合构建全球统一的数据仓库或服务仓库。

相比之下，某些 Kafka 方案还会产生昂贵的公网流量费用，1GB 可能达到约 0.5 元。对大数据场景而言，这一成本非常可观，架构设计时需认真考量。

用 JSON、Task 和 Stream 应对持续变化的数据

面对结构持续变化的数据，我们倾向于先用 JSON 承接变化，然后在 Databend Cloud 平台内部迭代加工逻辑。

Task 用于任务和 DDL 编排，可支持不同形式的调度；Stream 捕获表上的增量数据；UDF 则可承担自定义加工和向下游分发的工作。由于 Databend 采用存算分离架构，存储和计算彼此独立，计算节点无状态，因此扩容和按业务拆分集群都较为便捷。

在海外市场，

Task + Stream + UDF

例如，在一局游戏结束后，系统需为玩家匹配下一局的队友，这类实时特征数据的加工就可采用类似方式完成。

弹性计算和多集群隔离同样至关重要。当湖仓中出现热点数据、并发突然上升时，Multi-Cluster Warehouse 可在授权和资源上限范围内自动拉起更多计算集群，应对查询并发。

在福建省大数据集团的场景中，平台直接对全省民生数据提供服务，也采用类似方式自动扩展计算资源，对外承接点式查询。

工业制造：先统一可信数据，再谈分析和 AI

在进入更多分析和 AI 应用之前，企业首先需要一份统一、可用于决策的数据。

Databend 服务过一个工业制造项目。该平台接入了大量机台，一台机器每天可能产生约 50 GB 数据。单个目录里的文件多到连

ls

在 Raw 层，我们强调"保真"：源端数据是什么样，进入 Databend 后就保持什么样，首先确保两端一致。这一层也可理解为脏数据层。

在此基础上，再通过 Task 和 Stream 对增量数据进行实时、自动的加工和分发，最后建立统一的数据服务，并根据实际使用量配置计算资源。

这类工业数据与 Agent Trace 看似属于不同领域，但数据工程问题非常相似：都具有规模大、持续产生、结构可能不够规整等特点，都需要先稳定接入，再完成清洗、加工、服务和治理。

从 AI 应用到省级数据平台：几类典型实践

除了模型公司和工业制造，我们还服务了几类具有代表性的客户。

第一类是服务海量用户的在线 App，比如沉浸式翻译。经常阅读海外资料或外文内容的朋友，应该对这款产品很熟悉。对方当时的一句话让我印象很深：公司原本已被大数据和数据分析问题困扰已久，不知如何是好，后来发现了 Databend。

沉浸式翻译是我们上线最快的客户之一：0.5 天完成概念验证，次日即成为正式客户。如今，对方的 AI 数据分析、向量化记忆以及长期任务，都运行在我们的平台上。

第二类是前面提到的基础模型与 AI 企业。这类客户需要持续处理大规模的 Trace、构建 Evals、比较模型和 Harness 版本，并将数据继续用于训练和发布决策。

第三类是大型政企，如福建省大数据集团省级数据汇聚平台。Databend 已经成为该平台统一数据底座，原先使用的 Hadoop、MPP、Spark 等多种湖仓和计算组件统一到同一套产品上。过去，数据需先通过 Spark 或 Hive 等系统加工，再写回存储；现在，可在 Databend 中通过统一 SQL 完成数据加工，用 SQL 替代部分原有的 Spark 作业，大大减少人力的投入。Databend 已承接省级数据汇聚平台，数据规模达到数 PB 级别，工程复杂度极高。

第四类是金融企业，例如中信信托。Databend 为其承担统一归档和湖仓整合能力。可将 Databend 理解为一个"大号数据库"。金融机构中有不少千亿行级别的表，若长期置于传统服务型数仓或基于 NVMe 的产品中，成本会非常高。因此，可将冷数据和温数据逐步归档，在统一平台中完成加工后，再提供给其他服务层, 相当于提供一个温数据层。

面向未来：打造 AI 和 Agent 的统一数据底座

Databend 致力于支持分析检索和智能应用的统一访问。在数据形态上，平台可承载结构化、半结构化和非结构化数据，并支持统一检索；在工程层面，可通过统一 SQL，以及 Task、Stream、UDF 等能力，简化数据管道。

Databend 还提供弹性计算和多集群隔离。面对热点数据和突发并发，系统可在用户授权的范围内自动扩展 Warehouse，提升对外服务能力。

面向未来，我们将自身定位为 AI 和 Agent 的数据底座。用户无需显式考虑分区，也无需手工设计大量索引。只要 SQL 能表达需求，优化器就应尽可能将其高效执行。哪些执行计划不合理、哪些查询需优化，应更多地由系统承担，而非全部压在使用者身上。

政府项目的数据加工逻辑往往极为复杂，一次任务可能关联几十张表。经过这类项目的磨砺，平台在复杂 SQL 和大规模工程场景中的稳定性也得到了提升。

AI 时代的数据工程，不只是"把数据存下来"。真正有价值的数据底座，需要接得住持续增长的数据，跟得上结构和业务变化，跑得稳复杂任务，并最终让数据真正被模型、Agent 和业务用起来。

Databend 的目标是以云原生能力简化数据工程、减少人员和成本投入，为现代应用和 AI 工作负载提供一个更简洁、更具弹性的一体化数据平台。