导读

在大规模微服务架构中，雪崩故障是极具破坏力却又难以预防的系统性威胁。本文基于百度搜索架构与运维团队的实战经验，深入解析雪崩从“非稳态”到“自强化崩溃”的微观演化机制，揭示重试风暴、容量退化等正反馈回路的形成过程。文章提出系统化的治理思路，并详细介绍百度落地的多项核心实践，包括重试预算、队列限流、全局TTL控制等自愈机制，以及秒级流量调度与降级预案。通过真实案例与生产数据，为行业提供了一套可借鉴的雪崩预防与治理框架。

说明：本文是由2025 SRECon会议的《Preventing Avalanche Failures in Large-Scale Microservice Systems》的演讲者翻译并整理而成。

01 摘要

大规模微服务系统在享受分布式架构带来的灵活性和扩展性的同时，也面临着雪崩故障的严重威胁。雪崩是一种系统性故障模式，破坏力极大，难以预防，会给企业带来巨大损失。

本文深入分析雪崩的形成机理和演进模式，建立理论模型，从微观层面推导灾变过程，并通过真实生产案例验证了雪崩的快速演化路径。接着，通过系统化的思辨，探讨可能的治理方法。然后，介绍了百度的系统性的雪崩治理框架及一系列的核心实践机制。最后总结了近几年的治理成果，为行业提供了可借鉴的实践经验。

02 背景

大规模微服务系统本质是一张由大量节点和依赖交织而成的网络。请求从入口gateway进入系统，再层层向下形成深度调用链，往往还伴随着交叉依赖与高扇出。这种特点虽然带来了灵活性与扩展性，但天然埋着三类稳定性风险：其一是“未知中的未知”，如冷门链路、冷门代码在突发场景被激活；其二是容量级联风险，任一节点变慢都会把反压沿链路放大回传；其三是重试风暴，自我强化的流量会指数级扩散。在这种架构中，任何局部抖动都会以毫秒级在系统中传播。理解这张网络，就为理解‘雪崩’发生的原因奠定了基础。

大规模微服务系统依靠多种高可用机制来提升性能，表现为：

• 分布式架构避免单点故障并带来弹性扩展能力；

• 缓存抵挡流量激增并降低延迟；

• 重试实现瞬时恢复并提高成功率；

• 请求队列平滑流量尖刺并维持稳定吞吐量。

然而，在雪崩条件下，同样的机制会翻转到另一面，表现为：

• 分布式架构引入复杂依赖和更大的爆炸半径；

• 缓存失效引发流量洪峰和延迟激增；

• 不受控的重试导致指数级流量风暴；

• 后端变慢导致队列超时和入队失败。

03 直观感受雪崩的威力

这里举一个真实的例子给大家直观感受雪崩的威力。在一个IDC中，少量实例出现轻微健康退化，引发中等程度的延迟上升和轻微的可用性下降——没什么令人担忧的，只是典型的小波动。几乎同时，随着上游重试机制启动指数退避策略，流量迅速激增，导致服务在几秒内变得不可用。

然后，根据预定义的SLA执行自动预案，将大量负载从受影响的IDC转移到其他健康的IDC。但这些"健康"的IDC，只能在正常容量范围内运行，此时突然遭受显著的放大了的流量冲击，也变得过载。

紧急扩容马上被触发，扩充并启动更多的实例，但级联过载的蔓延的速度仍然比我们扩容策略的响应速度更快。

紧接着，多项尝试止损的动作被并行执行——流量比例调整、缓存命中率优化、超时时间缩减——然而它们在呈指数级的故障放大效应面前仍然无效。此刻，系统处理的主要是重试流量，其数量远超设计容量，线程池完全耗尽，请求队列被已超过SLA阈值并且注定要失败的请求填满。

这进一步引发了所有IDC的级联故障，最终导致系统级的完全崩溃，影响了大量用户。

在这个案例中，起初只是一个影响了少量实例的小问题，最终演变成了完全的系统崩溃。整个过程在仅仅2分钟内发生——这是大规模微服务系统在雪崩场景下如何自我毁灭的可怕呈现。

04 雪崩的特点

以上，我们直观感受到了雪崩的威力。那么，什么是雪崩？让我们从4个雪崩的特点来介绍雪崩。雪崩发生前，系统都会首先进入“非稳定”状态，这种状态“貌似正常、实则脆弱”。各项指标也许还在阈值内，但可用余量极少，表现为：负载上升，延迟上涨……此时的系统对扰动极为敏感，任何轻微扰动都会使它偏离稳定状态。

第二个特点是需要小的触发源扭转状态。触发源可能是多种多样的，比如，流量尖刺、网络瞬时抖动、硬件故障、软件冷门逻辑被触发……。它们本身并不致命，但在不稳定状态边缘，哪怕微小的触发都足以把系统推过临界点。真正导致系统边界违规的不是触发的强度，而是系统自身余量不足。然而，微小触发仍然是必要条件。

一旦越过临界点，系统会迅速进入自强化阶段，这是雪崩最典型的一个特点。在这种情形下，高可用优化机制统统都站到了反面。系统每增加一点恶化，高可用机制就产生一些正向反馈，从而导致进一步恶化。这条恶化-反馈循环持续加强，复杂且迅速。图中展示了几个例子。回路一：请求失败导致重试，然后导致负载上升，进而导致更多失败，最终形成指数级的重试风暴；回路二：少量实例略不健康导致被摘除，然后导致剩余实例更忙，进而导致更多实例被判不健康，最终引起容量指数级退化；回路三：错误事件导致大量的日志和监控，然后导致I/O用量上升，进而导致更多错误，最终使性能进一步恶化。

随着自强化阶段的持续，系统很快进入到失控和崩溃状态，这种状态最大的特点是无法靠自身恢复。线程池被耗尽，请求队列被已超时或必然失败的请求塞满，后端被无意义工作占满并拖慢，上游开始全面超时。

常见修复措施并不能奏效，甚至适得其反。比如，临时扩容往往慢于正反馈的加速导致资源就绪时系统早已熔毁，调cache难以解决重试反馈带来的流量放大，等等。需要专用的机制才能缓解，就像不能灭火器扑灭一颗正在爆炸中的核弹。唯有改变微观机制上的反馈结构，才能真正抑制雪崩。

让我们简要回顾雪崩的4个特征来理解雪崩的定义：

• 非稳态：系统看似正常但余量极少，对扰动高度敏感；

• 微小触发：流量尖刺或网络抖动等轻微扰动就能推动系统越过临界点；

• 自强化：高可用机制创建正反馈循环，通过重试风暴和容量损失放大恶化；

• 无法自我恢复：系统崩溃，资源耗尽。常见修复措施适得其反，需要专门干预。

05 理论模型

让我们从微观层面看一下雪崩。首先，我们看一个基本的模型。在这个模型中，流量以rps的吞吐流经一个服务的请求队列；然后，该服务的workers以concurrency的并发度处理队列中的请求，并发向后端进一步处理。在正常情况下，发向后端的吞吐也是rps。从请求到达本服务到本服务处理完成，所用的时间是latency。

基于Little's Law，我们有这样的公式：rps <= concurrency / latency。

真实的系统可以看做基础模型的管道似的级联连接。在这套连接系统中，需要保持任意位置的吞吐在实际流量之上，即在任意位置，都要维持这个rps <= concurrency / latency式子满足。

整个系统的吞吐受限于最薄弱的环节。需要精心地维持各环节脆弱的平衡。若任何位置的平衡哪怕短时间被打破，也会迅速触发级联反应，使系统雪崩。

06 微观灾变过程

接下来，让我带大家从微观层面看一下雪崩过程发生了什么。在这个抽象例子中，拓扑结构为 gateway → A → B → C，其中服务C变慢并成为触发点。

这张图使用“状态聚焦”的视角展示雪崩的快速微观演化过程。首先说明图中颜色的含义：红色代表恶化；灰色表示此阶段暂无新增变化。我们仅高亮当前需要重点关注的信号。

• 在健康状态下：系统延迟低，排队最少，吞吐量最优。

• 在触发阶段：C开始变慢，其延迟明显上升。

• 随着问题扩散，B和A的线程利用率和延迟几乎同时激增，而吞吐量和队列长度保持相对不变，显示出典型的’严重积压前的快速传播’行为。

• 随即来到堆积阶段：当并发达到上限后，B 和 A 的队列开始快速堆积，表明排队机制已被触发。

• 很快系统进入重试状态，B的超时触发上游重试。B接收到更多流量，而好吞吐比例下降，显示服务质量正在恶化。

• 接下来，流量开始放大，gateway级重试被触发，在A处造成流量激增，在B处造成第二次流量激增。对B产生的压力导致好吞吐进一步下降。

• 最终迅速坍塌到雪崩阶段：重试的重试形成正反馈循环，线程与队列被大量无效工作占满，系统彻底崩溃。

请注意三个关键点：线程利用率首先增加，队列长度快速跟进，吞吐量表现出两次或更多的快速跃升。

07 真实案例验证

让我们用真实的生产数据来验证前面的模型。由于这个故障发生在几年前，我们现在展示的这些指标是当时能够获取到的最完整的一组，尽管未能把前面模型里提到的所有指标都收集到。左边这个小图把B的总时间拆成了三部分：排队时间、本地处理时间、以及后端时间；右边的三张曲线的时间轴是对齐的。

这次故障仍然是C变慢了。首先，B的后端时间、整体延迟、线程使用量几乎同时抬升，与此同时，A的整体延迟也开始上涨。紧接着，B的排队时间开始上涨，很快，A的排队时间也跟着抬头——这正对应前一页的“扩散到堆积”的阶段转换。

接着我们发现一个有趣的现象：B的本地处理时间不增反降。其实原因很简单：线程更多时间在等后端返回，CPU空出来了，局部被处理到的请求就显得更快，这是常见的“局部变快错觉”。

再看吞吐曲线：A和B的RPS先出现一次阶跃，这是gateway的重试流量被激发；随后B的RPS再次跃升，这是A触发了二次重试。虽然我们没有直接画出“重试率”和“好吞吐占比”，但“排队时间增长”和“RPS两次阶跃”的组合，足以验证雪崩过程中由重试的驱动的故障放大路径。

整个过程大约发生在三分钟之内。

08 系统性思辨

既然我们理解了什么是雪崩以及它们在微观机制层面是如何工作的，让我们采用系统性方法来分析我们的选择。我想通过一个结构化的框架带着你来思考。在这个框架中，我们将检查雪崩的每个特征，并问：“我们能在这里干预吗？”通过这种系统性分析，我们能发现应该在哪些地方进行发力，以及哪些方法是现实的而非理想化的。

首先，是非稳态的避免。对于大规模分布式系统来说，完全避免非稳态是不现实的。系统本质上是面临无限触发源的复杂网络，其中HA机制更是一把双刃剑。它们从根本上是具有内在不稳定性的脆弱管道的级联。

尽管如此，我们仍然可以通过一些措施提升系统进入不稳定状态的阈值，使其更难进入不稳定状态，在面对更多触发源时能从容地运行。

接下来，我们思考能否消除所有触发源。实际上，这是完全不可行的。触发源对应的是一个无限的开放空间，不可枚举——包括网络抖动、流量尖刺、软件缺陷、硬件故障以及无数其他不可预测的因素。

虽然我们可以通过设计冗余机制来减轻干扰对系统稳定性的影响，但这种方法有两个主要局限性：首先是巨大的成本。例如，在网络基础设施层实施冗余链路聚合，在数据中心基础设施层面建设多套制冷系统，等等。而且，建设冗余机制往往涉及跨职能基础设施工程工作，实施困难且超出SRE的职责范畴。

接下来，我们能否消除自强化反馈回路呢？不可行！因为这些回路与HA机制内在相关，迫使我们必须做出权衡。

然而，将缓解机制嵌入到反馈回路内部，通过改变微观层面的反馈结构，可以将指数级放大转化为线性、可控的影响，大大降低其破坏力。就像用控制棒来阻止核反应中失控的中子放大。

最后，我们来探讨能否防止系统崩溃。这是可行的，主要通过两种互补的方法：最大化可用吞吐量与构建弹性恢复机制。即使系统超越临界阈值，我们仍可通过建立内部容错机制与外部干预预案，避免系统全面崩溃，并为系统创造多次恢复机会。

经过以上分析，我们发现可以在这些关键点实施雪崩治理工作，如右图所示。接下来，我们将详细介绍我们的核心实践。

09 我们的实践

前面说过，由于触发源众多，无法逐一验证系统在各种触发源下的行为，因此我们将所有触发源抽象为有限的几类场景，确保系统在这些场景下保持稳定——最大限度保持好吞吐。

这些场景分为两个维度：第一个维度是流量压力：包括流量逐步上升和瞬时激增。第二个维度是系统容量变化：包括绝对容量减少（如服务下线）和相对容量退化（如响应变慢）。

针对这四类场景，我们直接在生产环境中进行系统化验证：对于流量风险，我们在生产环境执行全链路压测，模拟流量的渐进式增长和瞬时尖刺。对于容量问题，我们在生产环境开展混沌工程，在真实环境下模拟服务容量缩减和延迟注入。

通过生产环境验证，我们提前发现潜在风险，确保系统在雪崩场景下保持最大可用吞吐的预期行为，结果可信且能代表实际系统性能。

早期检测对雪崩预防至关重要。我们建立了全面的监控系统，跟踪先导指标：

• 端到端失败数量

• 所有服务的通用指标，包括实例健康状态、实例CPU/内存/磁盘/IO利用率，以及coredump计数，等等

• 核心服务关键指标：包括请求队列长度、线程利用率、分位点延迟，等等

• 分片服务：分片丢失率

所有指标都是以秒级实时进行监控，并建立预警策略，使我们能第一时间感知到异常。

我们对系统自身的改进是建设一系列的"自愈"能力。首先是"重试预算"，用于在client侧就地收敛重试风暴。每个请求携带"全链路重试状态"信息，RPC组件据此识别两类重试：直接重试（本服务对下游）与间接重试（上游祖先节点发起）。RPC组件维护一个"预算池"，对两类重试流量配置不同的预算阈值，超过预算即快速失败。预算策略会随后端服务容量自适应调整，以充分使用后端容量。该机制把自增负载限制在可控范围内，避免指数级扩散。

在服务器端，我们还构建了一个称为“队列限流”的吞吐保护机制。我们将服务侧的请求队列做成多级优先级队列，并设置限流器。请求入队前先经过优先级过滤，在拥塞时，高优先级的请求允许通过，低优先级的请求被丢弃；限流器则根据实际处理速率自适应放行，同时，对于队列中超时的请求也会及时排出。在server侧容量到达瓶颈时，这套机制让有限的算力用于处理“好吞吐”。

我们也在系统中建设了更精细化的减少无谓的算力浪费的机制，即，全局TTL控制。每个请求在入口获得初始TTL，并随着请求在全链路传递；在各处理阶段结束后，按实际消耗的时间扣减TTL，并判断剩余值。若剩余TTL仍然大于0，则将这个新TTL作为后续阶段的TTL继续传递；否则，立即在此位置结束并返回。

虽然自愈机制已经将雪崩风险降至非常低的水平，但我们仍然为极其罕见的雪崩场景设计了多维度的秒级干预系统。

第一个维度是跨数据中心流量切换。我们实时监控多个敏感指标，当发生异常时，全局流量控制器在一秒内将流量从受影响的IDC迁移到其他IDC。

第二个维度是系统流量降级。流量分为不同等级，非用户流量（缓存刷新、预取等）按层级逐步减少直至关闭，为更高价值的用户请求让路。

第三个维度是架构裁剪。服务被分为不同级别（L2：低价值召回，L1：精确排序，L0：核心召回）。当损失发生时，我们做出秒级决策并按优先级逐步关闭服务级别。

第四个维度是超时套餐切换。多套系统级超时套餐根据损害程度自动适配，在吞吐和质量之间精妙地平衡。

10 治理结果

最后总结一下我们在治理雪崩上的成果。几年前，雪崩给我们的系统带来了比较多的PV损失，经过以上深入分析和系统治理，近几年完全没发生过雪崩，并且也几乎没有雪崩引起的PV损失。

导读

面对传统数据接入流程人力高、周期长、质量难控的痛点，本文提出了“数据平台智能化入库”的整体解决方案。方案以大型语言模型（LLM）为核心，结合代码生成流与执行流构建“智能代码闭环”，实现从数据Schema识别、结构化映射、质量规则抽取到入库包构建的全流程自动化。通过“生成-执行-反馈”闭环机制，系统能持续自我优化、沉淀知识与代码资产，大幅缩短接入周期（从3个月降至3天内）、降低人工成本（从4人月降至零人工干预），并显著提升系统可控性与扩展性，为企业级数据治理与智能化运营奠定了坚实技术基础。

01 背景与挑战

1.1 业务背景与需求场景

在当代企业数据治理体系中，数据平台承担着汇聚多源异构数据、支撑数据分析与业务决策的核心职能。典型业务场景包括：

• 跨部门数据整合与分析
• 实时业务监控与决策支持
• 用户行为分析与个性化推荐
• 企业级数据资产沉淀与管理

这些场景要求数据接入流程具备高效率、高准确性和强可扩展性，以适应快速变化的业务需求。

1.2 传统数据接入方案

传统数据接入采用全人工对接模式，其核心流程包括：

1. 需求沟通阶段（约2周）

• 业务方与百度产品经理多次会议明确需求

• 架构师参与评估技术可行性与方案设计

• 确定数据格式、传输方式、更新频率等细节

2. 开发实施阶段（约6周）

• 业务方开发团队按照百度数据标准进行适配开发

• 百度架构师团队提供技术指导与方案评审

• 双方开发团队协调接口对接与联调测试

3. 测试验证阶段（约1周）

• 数据质量验证与一致性检查

• 性能压力测试与稳定性评估

• 安全合规性审查与漏洞修复

4. 上线运维阶段（持续）

• 生产环境部署与监控

• 异常处理与应急响应

• 定期维护与迭代更新

1.3 痛点分析与技术挑战

1.3.1 效率瓶颈突出

• 人力成本极高：平均需要4人月（1PM+1架构师+2开发）对接一个业务方

• 接入周期漫长：从启动到上线平均需要2-3个月时间

• 扩展性受限：人力投入随业务量增长线性增加，无法支撑业务快速扩展

1.3.2 质量保障困难

• 标准落地不一致：人工理解偏差导致数据标准执行不统一

• 错误反馈滞后：数据质量问题往往在后期才发现，修复成本高

• 知识沉淀不足：对接经验难以标准化和复用

1.3.3 技术复杂度高

• 异构数据源适配：不同业务系统数据类型、格式、协议差异大

• 实时性要求挑战：既要保证数据处理的准确性，又要满足低延迟要求

• 规模扩展难题：传统人工方式无法应对数据量和业务量的快速增长

1.4 智能化转型的必然性

面对这些挑战，数据平台数据接入必须向自动化、智能化方向转型：

• 降低人力成本：从4人月/业务降到接近零人工干预

• 提升接入效率：从数月缩短到3天内完成新业务接入

• 保证数据质量：通过智能校验确保数据标准统一执行

• 支持大规模扩展：智能系统可并行处理多个业务接入请求

02 整体技术架构与核心流程

我们提出的“数据平台数据智能化入库”解决方案，其核心目标是将传统高度依赖人工配置、规则编写与经验判断的数据入库流程，转变为一种高度自动化、自适应的智能化流水线。整套架构的设计哲学是：以大型语言模型（LLM）为核心驱动力，以“代码即资产”为核心理念，通过“生成-执行-反馈”的闭环，将LLM的认知与泛化能力固化为可重复、高效率、易维护的业务逻辑代码。

整个系统的顶层架构如下图所示，它清晰地勾勒了从原始数据输入到最终数据入库的全过程，以及支撑该过程的智能闭环体系：

该架构的核心可以概括为两条主线：

1. 水平流水线（核心流程）：描述了数据处理的四个阶段，是业务价值实现的直接体现。

2. 垂直闭环（技术核心）：即“智能代码闭环逻辑”，它像大脑和神经系统一样渗透并赋能每一个阶段，是实现智能化的关键技术保障。

2.1 核心流程详解

如架构图所示，整个智能化入库流程分为四个层层递进、环环相扣的关键阶段。每个阶段都共享同一套智能代码闭环逻辑，但在具体任务、模型输入输出和后处理上各有侧重，共同构成了一个完整的数据处理管道（Pipeline）。

阶段一：数据原始Schema智能识别

技术目标：理解未知结构数据的组织方式、字段语义、数据类型及潜在质量问题，为后续处理奠定基础。

技术难点与深度：

1. 多模态与非均匀结构：数据源可能是结构化的CSV、半结构化的JSON/XML、甚至非结构化的日志或PDF文本。模型必须具备多模态理解能力和强大的模式泛化能力，从杂乱元数据中提取关键信息。

2. 语义歧义消解：识别类似ctime,create_time,生成时间等不同命名实际上属于同一语义范畴。这要求模型具备深厚的领域知识沉淀。

3. 异常值与模式冲突检测：在首行看似是INT类型的字段中，可能存在N/A、NULL、“-”等异常值，模型需要推断出真实的数据类型并提出清洗建议。

智能化实现：

此阶段的“代码生成流”会驱使基础模型（如CodeLLama, DeepSeek-Coder）分析数据样本。Prompt会精心设计，要求模型输出的不是简单描述，而是可执行的数据分析代码（例如生成Pandas DataFrame的dtypes分析、describe统计、唯一值枚举、异常值检测规则的代码）。生成的代码在CodeServer执行后，其输出（数据profile报告）会成为反馈，用于优化下一次的代码生成或用于模型微调。

阶段二：结构化数据抽取与映射

技术目标：将原始数据，无论是简单的行列转换还是复杂的嵌套解析，规整为目标数据库所需的扁平化结构。

技术难点与深度：

1. 复杂嵌套结构解析：处理JSON中多层嵌套的List和Object，并将其安全地展开为一维表结构，同时处理好父子关系的映射，防止数据丢失或错乱。

2. 跨表关联与实体识别：从多个数据文件中识别出可关联的键（如user_id），并自动建议表关系模型。这涉及实体统一和消歧等NLP核心难题。

3. 高性能转换逻辑：生成的代码不仅要逻辑正确，还需考虑大数据量下的性能（如避免逐行处理，尽量使用向量化操作）。

智能化实现：

此阶段Prompt会包含第一阶段识别出的Schema，并指示模型生成数据转换代码（如Pandas数据处理管道、PySpark SQL查询或自定义解析函数）。模型需要理解目标表结构，并编写出包含类型转换、字段拆分、嵌套展开等逻辑的高质量代码。代码执行流的效率优势在此淋漓尽致，一次生成，后续百万条数据都复用同一份高性能代码执行。

阶段三：数据质量规则与筛条件的智能抽取

技术目标：从业务需求描述或数据样本中，自动提取出数据清洗的质量规则（如：金额字段必须大于0）和面向业务查询的常用筛选项（如：按地区=、时间=筛选）。

技术难点与深度：

1. 从自然语言到规则逻辑的转化：理解“取最近3个月的有效数据”这类业务口语，并将其转化为WHERE date >= ‘2024-02-17’ AND status = ‘active‘这样的精确SQL条件。这是一项复杂的语义解析（Text-to-SQL）任务。

2. 规则冲突检测：自动识别并解决生成的规则间可能存在的矛盾（如规则A要求字段不为空，规则B又允许其为空）。

3. 规则合理性评估：生成的规则是否过于宽松或严格，需要有一定的业务先验或通过历史数据验证进行反馈。

智能化实现：

Prompt会引导模型将模糊的需求转化为精确的、可组合的条件判断逻辑代码或配置参数（如生成一套用于数据清洗的Python函数或一套可供下游系统调用的筛选器配置JSON）。这是将业务知识固化到系统中的关键一步。

阶段四：数据入库包的自动构建与执行

技术目标：将前三个阶段的产出物（表结构、转换代码、清洗规则）打包成一个可独立部署、版本化管理、一键执行的“数据入库包”。

技术难点与深度：

1. 工作流编排：生成的代码需要按照正确的依赖关系组织成执行工作流（例如：先建表 -> 然后跑数据转换 -> 最后执行数据质量检查）。

2. 原子性与可逆性：保障执行过程的原子性（全部成功或全部回滚），并提供版本回退的能力，这要求生成代码中融入事务管理逻辑。

3. 自动化部署集成：如何将最终合格的代码包无缝对接到CI/CD流程或调度系统中，实现真正的“无人值守”。

智能化实现：

此阶段模型的角色更像是一个自动化架构师。它根据前序步骤的产出，生成诸如 Dockerfile、SQL 建表语句、Airflow DAG 定义文件或 Shell 部署脚本等，将分散的代码模块整合为一个完整、健壮的数据管道应用。

2.2 架构优势总结

通过“智能代码闭环逻辑”赋能的核心四阶段架构，我们实现了：

1. 能力固化与性能飞跃：将LLM的智能一次性沉淀为代码，执行效率相比纯模型调用提升百倍，极大降低了对模型实时性与算力的依赖。

2. 卓越的可调试性与可控性：每一阶段的产出都是代码或配置，完全透明、可版本控制、可人工Review与干预，实现了智能与人工的完美协同。

3. 持续进化能力：闭环中的反馈机制为模型的持续优化（通过SFT和RL）提供了高质量的数据来源，系统会越用越聪明，成功率不断提升。

4. 清晰的职责边界：该架构明确了LLM的职责是“编写代码”，而CodeServer的职责是“执行代码”，二者各司其职，使得系统更加稳定和模块化。

此架构不仅解决了当前数据入库的痛点，更为企业构建了一个持续积累、不断优化的“数据知识库”和“自动化代码库”，为未来的数据治理与应用打下了坚实的技术基础。

03 智能入库的技术闭环

在数据平台“数据智能化入库”的全流程中，智能代码闭环逻辑 是实现自动化与自适应优化的核心引擎。它的本质是通过 代码生成流（Code Generation Flow） 与 代码执行流（Code Execution Flow） 的协同，形成一个“自我进化”的技术闭环，将大模型的自然语言处理与工程化执行环境深度结合，从而达到 自动生成 → 自动执行 → 自动优化 → 自动部署 的能力。

3.1 双流并行的核心思路

智能代码闭环逻辑由两条并行的主线构成：

1. 代码生成流（Code Generation Flow）

• 通过大模型理解数据特征和业务目标，自动生成可运行的逻辑代码。

• 在生成过程中引入模式识别、Prompt 优化、上下文记忆机制，确保输出代码具有 业务适配性、鲁棒性和可维护性。

• 生成代码不仅包括数据解析、清洗、抽取逻辑，还涵盖数据条件处理、数据入库包构建、Schema 管理等全链路自动化操作。

2. 代码执行流（Code Execution Flow）

• 所有生成的代码都被自动推送至

CodeServer 执行环境，形成标准化的任务流。

• 执行过程中严格控制依赖版本、逻辑分支与错误回滚机制，保证代码执行的可追溯与可控性。

• 执行结果与异常会实时反馈给生成流，用于二次修正与自适应优化。

这两条流相互作用，构建了一个持续收敛的 智能闭环。

3.2 代码生成流的完整流程

代码生成流并非简单的“一次性代码生成”，而是一个带有反馈自适应机制的复杂工程化过程：

“模式识别 → 代码生成 → 执行校验 → 自适应优化 → 部署上线”，并加入自动化 CR Gate与人机协作。

1. 模式识别与需求建模

• 通过大模型对原始数据 Schema、样本数据进行分析，抽取元信息（字段类型、依赖关系、语义标签）。

• 结合业务侧规则，自动生成逻辑约束与需求规格说明（Specification）。

• 技术难点：需要跨越 非结构化到结构化语义转换，同时保证生成结果能够驱动下游逻辑。

2. 智能代码生成

• 基于识别结果自动生成 ETL（Extract-Transform-Load）、Schema 适配、清洗、数据入库等多类代码。

• 引入 模板驱动 + 大模型自由生成 的混合模式，确保生成的代码既符合业务通用逻辑，又能保持灵活性。

• 技术难点：需要解决 代码可编译性与业务正确性 的双重挑战。

3. 自动化校验与反馈

• 在 CodeServer 中执行生成代码，收集运行日志、错误栈、性能指标。

• 自动对比结果与预期，生成反馈信号。

• 技术难点：错误可能出现在数据层（Schema 不匹配）、逻辑层（业务规则缺失）、执行层（依赖冲突），闭环系统需要自动分类与修复。

4. 自适应优化与Prompt迭代

• 根据反馈结果自动调整 Prompt，或更换基础模型（如 Code LLM → 专用 SFT 模型）。

• 可结合 RLHF/代码打分器，通过强化学习优化生成逻辑。

• 技术难点：如何避免“震荡式优化”（模型不断在两个错误之间切换），需要引入收敛判定机制。

5. 自动部署与人工干预

• 最终验证通过的代码自动上线至执行流，作为标准任务模块。

• 在自动部署前触发 代码 CR（Code Review） 流程，支持人工审查与修订。

• 技术难点：需要保证部署过程安全可控，同时能在人工介入与智能优化之间平衡。

整个闭环在每个阶段都遵循同一套迭代模式：模式识别 → 自动生成代码 → 代码校验与反馈 → 自适应优化 → 部署/触发。下面把每一步拆解为技术要点与工程实现：

3.2.1 模式识别（Schema & 元信息推断）

• 目标：从样本数据中识别字段、类型、语义（时间/金额/ID/地名/指标）以及表间关系（主外键、实体归属）。

• 混合方法：

        统计与启发式：空值率、唯一值率、类型分布、正则候选（日期/邮箱/UUID）用于初筛。

        嵌入与聚类：对文本字段建立文本/列级向量（例如基于token embedding或sentence embedding），通过聚类区分自由文本 vs 枚举 vs 代码值等。

        LLM 语义推断：对列样本与上下文使用大模型输出列的语义标签（例如：{"col":"trade_time","type":"timestamp","semantic":"交易时间"}），并给出置信度与解释。对于复杂嵌套JSON，采用分层解析策略（先抽样确定结构，再全量扫面）。

• 输出：候选Schema（字段名/类型/nullable/示例/语义标签/置信度）写入元数据仓库，供下游CodeGen调用。

• 难点与对策：

        字段语义不唯一：使用多模型投票（统计+embedding+LLM），并保留不确定列供人工复核；

        极端稀疏或混合型列（如ID混合文本）：启用规则引擎回退（正则、字典）。

3.2.2 自动生成代码（解析、清洗、数据入库脚本）

• 目标：根据候选Schema与业务约束自动生成可执行的ETL/ELT代码、SQL建表DDL或数据入库包。

• 模式：

        模板化生成：将常见操作（日期格式化、货币归一、异常值剔除、字段映射）抽成模板片段，LLM负责拼接并补全业务特例逻辑。

        AST/代码骨架：LLM生成代码时同时产出中间AST或结构化输出（例如JSON形式的操作步骤），以便静态分析与快速修改。

        测试驱动生成：同时自动生成单元/集成测试（小样本断言），以及基于property-based tests的约束（如：主键唯一、外键完整性、列值范围）。

• 工程要点：

        限制能力：对LLM生成代码的能力进行语法/安全限制（沙箱API、资源限制、禁止系统调用）。

        可解释的代码注释：强制在生成代码里内嵌可追溯的注释（生成者版本、prompt id、时间戳），便于回溯。

3.2.3 代码校验与反馈（CodeServer 执行）

• 目标：在受控环境执行生成代码，收集执行结果、异常与性能指标，形成可训练的反馈数据。

• 关键组件：执行沙箱（CodeServer）——负责安全执行、资源隔离、输入/输出挂载与审计日志。

• 测试套件：

        单元测试：断言核心转换逻辑；

        性能测试：采样数据上跑批量执行以估计时延与内存使用；

        回归/一致性测试：与历史版本比对（例如同源数据处理结果的差异率）。

• 异常采集与分类：语法错误、运行时异常、数据不一致、性能瓶颈、业务规则违背（例如金额为负但不可负）等都需要被分类并打标签（error taxonomy），以驱动后续优化。

3.2.4 自适应优化（Prompt、模型与训练回路）

• 目标：通过数据驱动方式持续提升模型在生成正确代码与正确抽取方面的成功率，并降低人工干预率。

• 方法栈：

        Prompt 版本管理：记录prompt、模板、示例输入-输出对。优先做prompt工程优化（few-shot、chain-of-thought、structured-output constraints）。

        SFT（Supervised Fine-Tuning）：将高质量的人标或已验证代码片段并入训练集，做周期性SFT；

        强化策略训练（CodeServer trace driven）：将执行成功/失败作为奖励信号，训练奖励模型或使用RL（离线RL或基于策略梯度的微调）提高生成器的长期回报（具体实施需注意样本偏差与安全控制）；

        自动化A/B测试：对新prompt/模型做小流量评估，采集关键指标再决定是否推广。

• 数据回路：执行Trace（包含代码、输入样本、执行结果、错误类型、人工修订历史）拼成训练样本，按label刷入训练仓库。

3.2.5 自动部署与触发（CR 流程与治理）

• 自动PR与人工审批：通过自动化工具将生成代码封装为变更请求（PR），执行静态策略检查（安全、合规、命名规范），当满足高置信条件可自动合并并部署，否则进入人工审查流程。

• 部署策略：金丝雀/分批上线、变更影响评估（schema迁移锁、回滚脚本）、自动化回滚阈值（如数据偏差超过阈值）。

• 新数据触发：数据落地或对象存储到达新文件时自动触发分类识别并调用已上线代码或触发新代码生成流程。

3.3 代码执行流的核心机制

与代码生成流互补，代码执行流强调 稳定性与可控性：

• 版本化管理：执行逻辑与模型访问解耦，每一次更新都通过版本化控制，可快速回滚。

• 异常检测与容错：通过日志追踪与异常监控体系，自动分类问题（数据错误 / 逻辑错误 / 环境错误），实现快速修复。

• 人工干预能力：在执行中可随时切换业务逻辑版本，支持定制化处理。

• 高效执行：相比直接依赖大模型在线推理，执行流运行在编译后的固定逻辑上，性能提升可达 百倍以上。

04 模型训练与持续优化

• 针对不同阶段，采用专属基础模型、个性化Prompt及后训练数据集

• 难点优先通过模型结构与Prompt优化，常态下使用SFT训练

• 引入CodeServer的强化学习机制，将代码执行结果反馈给模型，形成“代码-模型-业务”三位一体的持续学习系统

• 对于模型失效或边缘场景，支持人工审核与快速回溯修正，保证系统稳健性

05 技术创新与价值

1. 模式驱动与自动代码生成深度融合：大幅降低人工介入，提高入库效率与准确性

2. 全流程可追溯、可自愈：闭环反馈机制保障数据资产治理质量

3. 模型与代码双重强化学习：以执行结果反哺模型训练，技术深度行业领先

4. 弹性扩展与自动适配新数据源：支持多类数据源与业务变化，极大增强系统通用性与可维护性

06 未来展望

• 引入多模态大模型，提升非结构化数据（如图片、文本、视频）入库能力

• 深度集成数据质量检测、异常识别与业务语义理解，为数据平台智能治理提供更强保障

• 打造端到端的“智能数据工厂”，支撑企业级数据资产的自动化、智能化运营

结语：

数据平台智能化入库，是AI与数据工程深度融合的前沿技术。通过模式识别、自动代码生成与循环反馈的闭环体系，我们不仅显著提升了数据入库的自动化和智能化水平，还为企业数据资产的高效治理奠定了坚实基础。欢迎大家交流探讨，共同推进数据智能领域的发展！

导读

面对百度APP日均数千亿PV、超百PB数据规模带来的巨大挑战，我们完成了数据仓库的系统性升级。本文详细阐述了通过"两步走"策略解决资源压力、处理延迟和架构瓶颈的全过程：第一阶段聚焦日志清洗环节的稳定性与成本优化，第二阶段实现实时离线链路解耦、核心数据隔离及计算框架容错能力提升。此次升级显著提升了数据处理时效性、系统稳定性和成本效益，为业务发展提供了更坚实的数据支撑。

背景

百度APP及其产品矩阵作为百度体量最大的C端业务线，在数据处理全链路面临规模与架构的双重挑战。日志清洗环节因日均几千亿PV、超百PB的庞大数据规模，导致计算资源持续承压、处理延迟频发，加之历史遗留的复杂日志格式，清洗稳定性与时效性逐步下降，存储成本高昂。与此同时上游日志数据仍存在实时与离线链路耦合、核心与边缘数据未有效隔离、计算框架容错能力不足等结构性问题，影响关键数据产出的稳定与时效。整体系统切换与优化面临高额的历史负担和技术重构成本，下游业务的数据可用性、决策及时性及深度运营分析均受到显著制约。

基于以上问题，我们制定了“两步走”的升级策略：第一阶段优先解决日志清洗环节的稳定性和存储成本问题；第二阶段在此基础上，重点推进数仓上层架构优化，包括实时与离线链路解耦、核心数据隔离处理以及计算框架容错能力提升，逐步实现整体数据仓库的高效、稳定与可持续升级。

01 第一阶段：多日志源整合

1. 2023年之前架构

在百度APP及其产品矩阵的数据体系建设过程中，日志清洗作为整个数据流水线的起始环节，其处理稳定性和产出时效性始终处于关键地位，是保障下游业务数据可用性与决策及时性的重中之重。然而，随着业务规模持续扩大和用户体量快速增长，每日产生的日志量急剧上升，由此带来的巨大计算压力使得整个清洗链路频繁面临资源瓶颈与处理延迟，稳定性和时效性均逐步下滑，难以满足下游各业务方对数据交付时间和质量的要求。与此同时，数据入口的分散催生了大量烟囱式的开发与冗余的计算逻辑，不仅推高了运维成本，更在源头形成了数据孤岛。下游基于此类数据构建的数仓架构必然复杂化，多表的 JOIN 与理解成本高昂，使得整个数据建设环节背负着日趋沉重的成本与协作压力。

2. 问题分析

2.1 旧架构分析

2.1.1 数据孤岛化加剧，认知与使用成本高昂

现有架构对每类日志采用独立落表方式，导致数据存储呈现碎片化状态。这种设计造成同一业务实体的相关信息分散在不同表中，形成严重的数据割裂。下游用户在使用数据时，不得不通过多表关联才能获取完整信息，不仅大幅增加了技术实现难度，更带来了沉重的认知负担。用户需要理解多张表的结构和关联关系，极易产生理解偏差，进而影响数据分析的准确性和可靠性。

2.1.2 关联查询性能瓶颈，制约数据价值释放

与此同时，多表关联查询模式给系统带来了巨大的性能压力。随着数据量的持续增长，表连接操作的成本呈指数级上升，查询响应时间显著延长。特别是在需要跨多个表进行关联分析的场景下，系统往往需要耗费大量计算资源和时间，无法满足业务对高效数据分析和快速决策的需求，严重制约了数据价值的及时释放。

此外，原始日志结构中普遍存在的复杂嵌套格式（如多层JSON、数组结构等）大幅增加了数据清洗和解析的复杂度。大量业务自定义字段缺乏统一规范，导致解析逻辑冗余且低效，进一步降低了整体处理性能。这些因素共同加剧了数据处理的延迟与资源消耗，形成系统性瓶颈。

2.1.3 维护复杂度与脆弱性并存，系统稳定性堪忧

独立的数据处理流水线，导致系统维护点分散。任何逻辑变更或schema调整都需要在多处同步实施，极大地增加了维护工作量。这种架构的脆弱性也显著提高了出错风险，单个任务修改的错误可能引发连锁反应，影响整个数据链路的稳定性。

特别需要指出的是，当前采用的UDW数仓及配套ETL框架仍是2012年上线的技术方案，已明显落后于业界主流水平。该框架存在诸多局限性：首先，其兼容性差，难以与现有开源生态工具链高效集成；其次，基于C++的MR计算框架稳定性不足，日常运行中容易出现各种异常；最后，开发调试效率低下，严重制约了数据需求的迭代速度。这些技术债务不仅增加了系统的维护复杂度，更成为制约数据平台发展的关键瓶颈。

2.2 重构思路分析

理想状态：从数据架构的理想设计来看，基于通用宽表数据建模方法论，采用“一步到位”的方式直接产出高度整合、面向主题的Turing宽表，是最为高效和优雅的解决方案。它能够减少中间冗余加工环节，提升数据一致性和复用度。

升级成本：下游业务方因历史原因，数据应用架构高度依赖传统UDW模式的数据组织与服务方式，迁移至Turing宽表体系涉及大量脚本改造、逻辑核对与业务适配工作，技术切换和数据迁移成本极高，导致架构升级短期难以实施。

思考：为实现数据架构的平滑升级，本次重构方案采用渐进式过渡策略，在着力解决现有架构核心痛点的同时，必须充分考虑百度业务数据链路长、历史包袱重的现实情况，审慎平衡技术先进性与落地可行性。方案设计严格遵循"平滑过渡、风险可控、成本最优"三大原则。

需要特别指出的是，由于现有数据体系深度嵌入各业务线的策略计算与离线分析环节，其紧密的耦合关系导致配套升级难度极大、周期长。这不仅涉及底层数据表的更替、依赖路径修改，更要求对依赖原有数据模型的下游业务进行协同改造和全面适配，沟通和推进难度极大。所以在保障业务连续性的前提下，如何有序推进全链路的升级切换是本次升级的重中之重。

建模思路：

（1）降低迁移成本

在数据中间层设计上，方案延续使用刻钟级UDW表作为缓冲层，通过将多个离散的UDW表整合为统一的宽表模型，进一步降低下游的使用和理解成本。同时，对表schema实施精细化改造，包括消除冗余字段、统一数据标准、优化存储格式，并重构字段逻辑以提升数据一致性。这种设计既保持了与现有下游系统的兼容性，又显著降低了数据使用复杂度。

（2）双轨输出机制

为确保迁移过程的平稳性，方案采用双轨输出机制：一方面继续提供优化后的UDW宽表，保障现有作业的无缝运行；另一方面通过聚合加工生成小时级Turing表，作为统一对外输出的日志宽表。这种渐进式迁移路径使下游用户可根据自身情况灵活选择切换时机，最大限度降低升级成本。

（3）兼顾历史和未来

此次架构优化为后续全面升级奠定了坚实基础。通过UDW层的预处理和Turing表的逐步推广，最终将实现架构的完全过渡，在提升系统性能的同时确保业务连续性，达成技术演进与业务稳定之间的最佳平衡。

3. 解决方案

过渡方案设计与实施：稳时效、降成本、提效率的综合治理

面对日志清洗环节日益严峻的稳定性、时效性及成本压力，我们制定并实施了一套详尽的过渡性解决方案。该方案并未激进地推行一步到位的Turing宽表迁移，而是立足于现有技术生态，以快速解决下游业务最迫切的痛点为目标，重点攻坚“产出时效不稳定”、“存储计算成本高”及“明细数据查询效率低下”三大核心问题。

3.1 优化处理粒度与逻辑沉淀，保障时效与复用性

为彻底扭转小时级任务积压与延迟的局面，我们首先对调度周期进行了粒度细化，将日志清洗任务从小时级调度全面提升至刻钟级（15分钟）。这一调整显著降低了单次任务的处理数据量和计算压力，使数据产出的延迟大幅减少，稳定性和时效性得到了根本保障。在技术选型上，我们并未盲目更换计算框架，而是继续沿用成熟稳定的C++/MR框架，确保了迁移过程的平稳性与可靠性。

同时，我们致力于提升数据的易用性与标准化程度。针对下游业务方需要反复从复杂JSON、Map等嵌套字段中解析提取关键信息的痛点，我们进行了大规模的业务通用逻辑下沉工作。将超过100个高频访问的埋点属性进行预解析、扁平化处理，转化为单独的标准化字段。这不仅极大减轻了下游的数据预处理负担，更直接提升了基于这些字段的查询过滤与聚合分析效率，为下游开发节省了大量时间。

3.2 兼顾历史依赖与未来演进，提供平滑迁移路径

我们充分认识到下游业务对原有UDW数仓体系的强依赖性。为保障业务的连续性，我们并未强制要求所有方立即迁移，而是采取了双轨并行的支撑策略。在产出新一代数据模型的同时，我们继续提供UDW中间表，确保那些尚未准备好迁移至Turing宽表的业务方能够无缝对接，无需修改现有代码，极大降低了方案的落地门槛和风险。

3.3 深度优化存储与查询，实现性能跨越式提升

为进一步降低存储成本并提升Turing宽表的查询性能，我们对其存储结构进行了深度优化。

• 合并小文件与高效压缩：海量小文件是制约查询性能的首要元凶。我们通过按设备ID、点位ID、时间戳等关键字段进行精细排序，将数据写入为连续有序的大文件，从而将单天高达800万个小文件合并至60万左右，文件数量减少了近93%。在存储格式上，我们选用Parquet列式存储，并经过充分调研测试，采用了ZSTD压缩算法。ZSTD在压缩比、压缩/解压速度上取得了最佳平衡，且完美支持多线程，最终实现了每天节省超过420TB的巨大存储开销，成本效益极其显著。

4. 新的问题&解决策略

问题1：宽表数据量膨胀导致的查询性能下降

解决策略：为应对宽表数据量激增对查询性能带来的挑战，我们实施了体系化的查询加速方案，显著提升海量数据下的检索效率

• 强制分区限制策略：在查询引擎层上线了强制要求限制分区条件的规则，避免了全表扫描带来的巨额元数据开销，大幅提升元数据检索效率。

• 查询结果缓存：对常见的热点查询结果进行缓存，对于重复性查询实现了秒级响应。

• 智能资源调度：根据查询的计算复杂度，系统自动将其调度到不同配置的资源池中执行，简单查询快速返回，复杂查询获得充足资源，实现了集群资源的高效利用。

问题2：分区数量增多导致点位所在的分区变得困难

解决策略：针对分区维度增加后，数据定位难度加大的问题，我们通过元数据管理与平台化集成提供解决方案：

• 新建分区元数据集，以天为粒度预先计算并存储所有点位与分区的映射关系，形成高效的点位分区定位查询，为点位所在分区快速检索提供基础支撑。

• 与现有点位管理平台深度集成，在其点位查询界面新增【查一查】功能。用户可通过界面化操作直接获取精准的数据分区信息及查询SQL模板，极大提升了用户使用的效率，降低了用户使用成本。

02 第二阶段：全面提速

1. 2023→2024年架构

随着业务发展，该数仓已完成由UDW（统一数据工作台）向Turing（新数据工作台）的改造，并初步建立起体系化的数据模型与分层数据集，显著提升了数据复用性和分析效率。基于这些宽表与数据集，大部分常规分析场景已能够快速响应。然而，在数据加工的最上游，即明细数据宽表的生产环节之前依旧包含缓冲的刻钟级udw表，因此仍存在若干架构性瓶颈。首先，实时数据处理链路与离线批处理链路相互耦合，资源竞争与依赖关系复杂，影响了整体任务的稳定性和时效性；其次，核心业务指标与非核心附属数据未被有效拆分处理，导致关键数据产出易受边缘数据波动或延迟的干扰；此外，当前的计算框架对于数据迟到、重复、异常值等复杂情况的处理灵活度不足，容错与自适应能力有待加强。

为彻底解决这些问题，进一步提升数据产出的时效性、准确性和稳定性，以更好地赋能百度APP及其产品矩阵及各下游业务的数据分析与决策，亟需结合各数据点位的实际使用情况和业务优先级，对最上游的日志ETL（抽取、转换、加载）处理流程进行系统性的优化与重构。

2. 问题分析

当前数据ETL处理流程面临以下几个核心挑战，这些问题不仅影响数据产出的效率与稳定性，也为下游业务数据的准确性和及时性带来风险。

2.1 开发框架灵活性不足，资源协调与弹性扩展能力受限

目前的ETL任务仍沿用原有UDW大表处理框架，通过单机Hadoop Client提交任务，并依赖QE（底层为mapreduce引擎）进行计算。该框架在资源调度和权限管理方面已逐渐暴露出瓶颈。同时udw是2012年提出的数仓建设方案，随着开源计算、存储技术的发展，udw性能逐步落后业界，部分功能不具备继续升级迭代可行性。一旦出现上游数据延迟、队列资源拥塞或系统异常，容易导致任务大规模积压。由于缺乏跨队列或跨资源的调度容灾能力，无法协调其他计算资源执行任务回溯与补偿，最终将直接影响整体数据产出时效，甚至波及下游多条业务线的核心数据应用。

2.2 核心与非核心数据处理耦合，异常影响范围扩散

在日志清洗ETL环节中，核心业务数据点位与非核心业务数据点位、以及实时与离线数据流目前尚未进行有效拆分处理。这种架构层面的耦合导致一旦上游数据源或计算过程中发生异常，其影响面会迅速扩大，不仅关键业务指标受到冲击，非核心业务数据的问题也可能反向干扰核心链路的稳定性。缺乏业务优先级识别和隔离机制，降低了计算链路的整体容错能力和故障隔离水平。

2.3 计算链路冗长复杂，维护困难且稳定性面临挑战

当前处理流程中包含UDW中间缓冲层，导致计算环节增多、链路层级深化。较长的依赖链不仅增加了数据产出的端到端延迟，也显著提高了运维监控和故障定位的复杂度。任何环节出现性能波动或失败都易引起连锁反应，威胁整体任务的稳定性和时效性，同时也带来较高的人力维护成本。

2.4 实时与离线数据源不一致，存在冗余计算与口径偏差

百度APP及其产品矩阵业务当前使用的实时计算链路和离线数据链路在核心指标上并未实现数据源统一，两条链路独立处理且并行存在。这导致相同指标需要在不同流程中重复计算，既造成资源浪费，也增加了数据口径对齐的难度。长期来看，此类架构问题会直接影响关键指标的一致性和可信度，对业务决策准确性构成潜在风险。

2.5 存储无序增长，数据冗余和存储成本与日俱增

随着业务规模的持续扩张和流量快速增长，支撑核心业务的明细数据宽表总量已达到百PB级别，存储与计算成本压力日益凸显。然而，不同业务域对数据的保留周期和使用频率存在显著差异，全部数据长期存储既不经济也无必要。

3. 解决方案

3.1 ETL框架升级

在完成由多张udw表到Turing表的优化工作完成后，数据处理的时效性与稳定性虽然取得了一定改善，但仍存在进一步提升的空间。具体而言，原有的C++ MR计算框架在任务运行过程中逐渐暴露出两类典型问题：一是容易发生计算长尾现象，个别任务实例处理缓慢，拖慢整个作业完成进度；二是基于单机调度的模式存在可靠性瓶颈，整体资源协调和任务容错能力有限。这些问题导致数据产出的延迟风险依然较高，难以完全满足业务对数据时效日益提升的要求。

为解决上述痛点，经过充分的技术调研与架构评估，我们决定将计算框架升级为TM+Spark的组合方案。其中，TM（Task Manager）作为厂内自研的高性能流式处理框架，在多个关键维度上显著优于原有的C++ MR架构。

TM（Task Manager）：更高的容错性和更强的稳定性

首先，在容错性方面，TM具备更为智能和敏捷的错误恢复机制。当某个计算实例发生故障或执行缓慢时，TM调度系统能够迅速感知并主动发起抢占操作，将当前Task动态迁移至新的实例继续处理，从而有效避免传统MR框架中由于个别长尾任务导致的整体作业延迟。这一机制极大提升了作业的稳健性和执行效率。

其次，在调度稳定性方面，TM基于Opera调度系统进行资源管理与任务分配，这一调度架构具有高度解耦和资源隔离的特点。每个任务实例独立运行，互不干扰，有效避免了在MR模式下由于同一队列中其他高负载或异常作业所带来的负面冲击，从而保障关键数据处理任务的稳定性和可预期性。

此外，TM框架也在输出存储效率方面做出了重要升级。它原生支持输出Parquet列式存储格式，并集成ZSTD压缩算法，在减少存储空间占用的同时大幅提升了后续查询操作的I/O效率。这一改进使得数据在写入阶段就具备更优的列组织结构和压缩特性，为下游分析提供了高性能的数据基础。

主流开源框架Flink和TM的对比如下：

Spark：通过构建DAG，计算更高效；利用RDD或者DataFrame减少IO耗时；多线程机制，执行速度更快。

Spark对比MR的核心优势：

• 速度：基于内存计算，无需反复做读写操作，更加高效

• 高度集成：spark丰富的API和高级抽象的函数可以轻松实现复杂的逻辑计算和处理，无需和MR一般需要编写复杂的处理逻辑

• 计算模型：内置的RDD数据结构可以提高数据计算的容错性；查询优化和执行优化可以适应复杂数据的处理和查询

结合Spark通用计算引擎强大的分布式内存计算能力和丰富的生态组件，新框架不仅解决了之前C++ MR模式中的长尾与调度瓶颈，还进一步实现了处理链路的统一与优化。Spark的高扩展性和TM的流式稳健性相结合，共同构建出一个容错能力强、资源利用高效、运维负担低的新一代数据处理架构，为业务提供更低延迟、更高可靠性的数据服务。

3.2 日志分类分级

3.2.1 埋点上线不规范，被动兼容推高处理成本

在当前百度APP及其产品矩阵业务高速发展的背景下，日均处理日志量已达3000亿PV的庞大规模，数据流的稳定、高效与成本可控变得至关重要。

原有的埋点分类和校验存在两个突出的问题：

• 上报不规范：存在大量不经过日志中台统一校验而直接上线的业务打点，这些“非规范”打点格式各异、质量参差不齐，极易引发解析异常。

• 处理成本高：下游的日志清洗ETL环节被迫陷入“被动兼容”的循环中，需要频繁地跟进制订适配规则以解析这些非标数据，不仅带来了极高的运维成本，更因计算资源的无效消耗而加剧了整体处理链路的负担，严重制约了数据产出的时效性与稳定性。

3.2.2 通过协同治理实现日志中台全流量覆盖

为从根本上破解这一难题，我们基于对百度APP及其产品矩阵数据全链路的深入洞察，发起了一项跨体系的协同治理工程。联合了日志中台团队、各业务研发团队、QA质量保障团队及PMO项目管理团队，形成了强有力的专项工作组。

第一阶段的核心任务是对所有日志模块进行全域梳理。我们共同制定了统一的《新增业务模块接入日志中台规范》与《日志埋点规范》，明确了从数据采集、上报到校验的完整标准流程，并强力推动百度APP及其产品矩阵（包括主客户端及相关创新业务）的全量需求空间、代码仓库及日志模块，完成向日志中台的标准化接入迁移。这一举措将日志中台的流量覆盖能力从治理前的约80%一举提升至100%****，实现了全流量管控。

更重要的是，我们在日志中台增强了多项主动校验能力：包括日志长度校验、关键公共参数完整性校验、以及精确到需求ID的粒度校验。这使得任何不合规的打点企图在测试和上线阶段就能被即时发现和拦截，实现了“问题早发现、早解决”的闭环管理，从而构筑起覆盖全场景的打点需求上线质量保障体系，从源头上杜绝了异常日志的产生。

3.2.3 打破“只上不下”僵局，建立埋点生命周期管理

在成功建立起“入口”管控机制后，我们将治理重心转向对历史存量埋点的“出口”梳理与优化。长期以来，由于缺乏有效的评估手段，点位数据存在着“只增不减”的痼疾，大量废弃或无效点位持续消耗着巨额的计算和存储资源。为此，我们创新性地从鉴权信息入手，通过对十几类不同下游使用场景（包括内部报表、算法模型、RDC数据转发服务等）的全面调研与信息收集，并对相关日志解析链路进行深度分析，首次精准地绘制出以百度APP及其产品矩阵全量15000多个点位为起点的、覆盖所有下游应用场景的“点位全链路使用地图”。

基于这张价值地图，我们清晰地识别出超过10000个点位已无任何下游业务使用或价值极低。通过严格的评估与协作流程，我们果断对这些埋点进行了下线处理，下线比例高达存量点位的71%。此次大规模治理行动，不仅直接释放了海量的计算和存储资源，有效缓解了系统瓶颈，更打破了长达多年的“埋点只上不敢下”的历史僵局，建立了点位的全生命周期管理模式，为后续数据的精细化管理与成本优化奠定了坚实基础。

3.3 AB实验数据扇出处理

3.3.1 现状与问题

在数据驱动的业务迭代中，A/B实验平台的指标建设和效果评估能力至关重要。然而，随着业务快速扩张和实验复杂度的提升，原有的实验数仓架构逐渐显露出严重瓶颈。平台最初是在通用数仓分层模型的基础上，采用“每个指标单独计算”的模式进行建设。这种设计在初期虽然灵活，但随着实验数量和指标数量的急剧增长，计算链路变得异常复杂、冗余且难以维护。由于缺少与公司数据中台团队的深度协同和标准化约束，每次新增实验指标都需要大量重复开发，导致实验数据需求的交付周期不断延长，严重拖慢了业务迭代速度，引发了业务团队的负反馈。

3.3.2 解决方案

（1）分析过程

理想的解决方案是直接复用百度APP及其产品矩阵已有的标准化大宽表进行实验指标配置。即基于一张集成所有关键维度与指标的大宽表，快速定义和产出实验分析所需的数据集。然而，现实情况却更为复杂：百度APP及其产品矩阵客户端同时线上进行的实验数量极多，平均每个cuid（用户唯一标识）对应的实验ID（sid）字符长度已超过2400字符。这个长度几乎相当于单条日志原始存储容量的40%，如果直接将实验ID维度接入宽表，将导致每条日志存储膨胀近一倍。这不仅会带来极高的存储成本，也会大幅增加下游所有数据应用的数据扫描量和传输开销，严重拖慢查询性能，进而影响整个数据链路的效率。

（2）设计思路

面对这一独特挑战，我们并未选择传统的宽表集成方案，而是从数据生成的源头实施了更根本的架构优化。我们重点对实验ID映射关系进行了拆分和重构：将sid与核心行为数据解耦，设计并建设了独立的sid维表。该维表直接从日志源头统一生成，整合了来自客户端的实验曝光及分组信息，并实现了对业务方、评估方各自独立建设的多套映射关系的全面统一。这一举措不仅从本质上避免了主宽表的存储膨胀，还彻底解决了因数据来源不一致而导致的实验效果评估diff问题，显著提高了实验数据的准确性和可信度。

（3）成果与收益

在此基础上，A/B实验平台的分析查询不再依赖于对超大宽表的直接扫描，而是通过sid维表与核心行为宽表进行动态拼接的方式实现指标计算。

在指标口径对齐方面，已完成实验类指标与OKR指标的口径统一工作，累计对齐上线指标2000余个，覆盖多个主题和维度。实验指标改由数据中心宽表统一生产，显著减少了以往在指标口径沟通与对齐方面的成本；在实验效率提升显著，指标开发环节通过复用宽表及数仓下沉逻辑，并升级计算框架，使常规需求开发周期从原先2周以上缩短至1周内，开发效率提升超50%。同时核心指标计算SLA由T+14小时提升至T+10小时，处理时效明显提高；在计算资源成本方面，通过整体数据流复用和抽样日志整合优化，实现了计算资源成本的有效降低。另外，联动产品及策略团队治理并下线无效实验指标超1800+，释放的资源进一步支撑了新场景的指标建设需求。

4. 分级存储治理

随着业务规模的持续扩张与产品矩阵的不断丰富，百度APP及其产品矩阵业务的日志数据量呈现指数级增长，单张核心Turing数据表的存储量已达到百PB级别，面临巨大的存储与成本压力。传统的统一存储周期策略难以适应当前复杂的使用场景：一方面，大量短期数据被无效保留，占用巨额存储资源；另一方面，部分核心业务场景仍需依赖长周期历史数据进行跨年指标对比、关键数据需求回溯与深度建模分析。

为解决这一矛盾，我们针对Turing表启动了多维度的精细化存储治理工作。通过深入分析业务使用特征与数据访问频率，我们建立了差异化的数据生命周期管理机制，实施**“热->温->冷”**三级数据分层存储策略。对高频访问的近期数据全部保留，对访问频率较低的长期历史数据自动进行转储、压缩或者裁剪等，并配套建立完备的数据取回与回溯流程。

该项治理在充分保障核心业务长周期数据使用需求的前提下，显著压缩了整体存储规模，实现了存储成本的大幅优化，为未来数据的可持续增长与高效管理奠定了坚实基础。

具体实施策略：

03 总结与展望

随着业务规模的持续扩张和产品矩阵的不断丰富，数据量呈现指数级增长，这一趋势持续驱动着数据处理架构与模型的演进与迭代，同时也对数据分析的敏捷性、易用性和可靠性提出了更高要求。在数仓系统全面升级的过程中，我们着力优化数据处理全链路，通过改进调度机制、减少计算环节、强化故障自动恢复能力，显著缩短了整个数据处理流程的时长，有效识别并排除多项潜在稳定性风险。此外，依托于对全端埋点体系的系统化梳理与标准化规范，构建了高质量、可复用的数据资产底座。

本次整体架构的升级为业务提供了坚实的数据支撑，在数据时效性、准确性和使用便捷性方面均实现显著提升。作为百度体系内最核心且数据规模最大的业务板块，百度APP仍面临数据持续激增带来的诸多挑战，包括埋点规范统一难度高、技术栈兼容与选型约束多、日志解析复杂度高、存储结构灵活多变以及成本控制压力增大等问题。

面向未来，我们将持续推进数仓架构的深度优化，重点围绕埋点治理、架构升级、效能提升、存储模型优化和资源精细化管理等方面展开工作。目标是构建一套具备更高时效性、更优数据模型、更低存储与计算成本的全新一代数仓链路，为业务创新与决策提供高效、可靠、低成本的数据服务能力。

导读

随着人工智能技术的迅猛发展，AIGC（AI-Generated Content，人工智能生成内容）正逐步重塑内容创作行业的格局。尤其在视频内容领域，传统制作流程周期长、成本高、依赖人工创作，已难以满足日益增长的内容消费需求。AIGC技术的引入，为视频创作带来了前所未有的效率与可能性。AIGC工具在短视频应用率从22 年不足5%跃升到25年35%。电商场景下，越来越多的平台帮助商家进行AIGC商品视频的创作，帮助其提高商品转化率。基于上述两点，电商搜索在今年开始探索AIGC视频自动化生产方案，尝试基于视频自动化混剪，来满足搜索场景下日益增长的内容需求。

01 早期项目演进与问题

项目早期我们整体视频创作中基于大模型完成分镜脚本生成 + 分镜图片素材检索，其他视频元素（脚本脉络/视频标题/布局/音效/特效等）全部通过规则进行选择和生成。但整体后验效果不佳，通过后验分析我们发现了两个很大的问题：

• 规则式方案导致视频整体模板化、同质性严重。

• 整体视频素材大部分由口播加静态图片素材组成，比较死板，吸引力弱。

为解决上述2类问题，我们进行了新一版迭代。主要升级点：

• 规则式视频生成方案升级成 MultiAgent协同视频生成系统，最大化视频先后验指标为目标，动态调度视频元素。

• 素材供给和类型更丰富（视频素材、泛图表），增加视频素材多维度优选能力，大幅提升高清视频素材的时长占比，显著增强视频吸引力。

02 MultiAgent视频生成系统

通过搭建MultiAgent协同视频生成系统，基于视频内容高效满足和视频画面丰富多样为优化目标，模拟人类视频制作流程，完成分镜脚本生成>多类型素材生成->大模型剪辑成片多轮推理。

2.1 分镜脚本生成Agent

分镜脚本生成在项目初期面临两大问题：

问题1：如何提升脚本准确率?

电商场景下品牌/品类/商品信息需要大量准确数据支撑 => 直接根据互联网语料生成准确率不到80%。

解法：脚本生成信息来源以电商高精知识图谱为主，第三方优质视频文案（B站视频等）为辅，保证核心主体信息准确的同时丰富故事细节，脚本可用率大大提升。如下是一个Case：

西门子是什么品牌

---

提到西门子，很多人第一反应是家里那台带液晶屏的冰箱，或是洗衣机上那个会发光的LOGO。

但你可能不知道，这个看似普通的家电品牌，背后藏着足以改变人类工业史的惊人故事。

1847年，当维尔纳·冯·西门子在柏林一间小作坊里敲打出第一台电报机时，没人能想到这家公司会成为工业界的隐形冠军。

最让人震撼的是西门子的重生能力。

二战期间80%工厂被炸毁，这个德国品牌却用短短五年就杀回巅峰。

就像他们1910年卖给中国石龙坝水电站的发电机——这台百岁高龄的工业活化石，至今还在云南吭哧吭哧运转。

这种近乎变态的耐久度，解释了为什么全球70%的高端燃气轮机市场都被西门子垄断。

但西门子真正的可怕之处在于无处不在。

你手机摄像头里的光学系统，医院CT机的核心部件，甚至造芯片用的UV光刻机，背后都是西门子的技术。

更夸张的是，历史上32位诺贝尔奖得主都依赖西门子显微镜做研究。

这种渗透到科技毛细血管的能力，让它在工业4.0时代依然稳坐神坛。

2024年最新财报暴露了这家老牌巨头的野心：单季度新订单223亿欧元，折合人民币超1700亿元。

更惊人的是研发投入——63亿欧元相当于每天烧掉1.7亿人民币搞创新。

从1872年进入中国交付首台电报机，到如今智能工厂解决方案遍布长三角，西门子用152年时间证明：真正的工业王者，从来都是闷声改变世界。

下次当你打开西门子冰箱取饮料时，不妨多看一眼那个蓝色LOGO。

它不仅是德国制造的品质象征，更是一台持续运转178年的超级印钞机——平均每1.5小时就能创造1个诺贝尔奖级别的技术突破，这样的品牌基因，恐怕连特斯拉都要喊声老师。

---

问题2：如何提升脚本吸引力？

通用大模型生成脚本冗长拖沓且AI感强 => 无法快速满足用户需求以及脚本吸引力不足。

问题2解法：构建优秀脚本脉络及风格集合，针对不同Query动态选择脚本脉络、风格，提高脚本吸引力。

风格2：历史叙事类风格

---

开头：

1.通过悬念钩子式开场，把观众带入好奇与期待的情绪，通过颠覆认知的事实陈述，带给观众强烈的入门吸引力。

主体文案

1．通过时间锚点与关键事件叙事，把观众带入到故事中，通过细节化描述，带给观众身临其境的代入感。

2. 通过数据具象化与生活类比，把观众带入真实可感的认知场景，通过技术术语降维解读，带给观众易懂的专业洞察。

3. 通过对比与隐喻强化冲突，把观众带入情感共鸣的高潮，通过辉煌与危机并行的结构，带给观众深度反思的平衡视角。

4．通过转折点戏剧化呈现，把观众带入叙事节奏的起伏中，通过第三方视角引用，带给观众客观可信的品牌背书。

5．通过金句收尾与主题升华，把观众带入余韵悠长的结尾氛围，通过历史寓言或隐喻，带给观众启发性的价值总结。

6. 通过语言节奏控制，把观众带入流畅紧凑的阅读体验，通过文化元素融合，带给观众多元化的审美共鸣。

结尾：添加和用户的互动

---

效果示例如下：

谁能想到，如今遍布全球的西门子帝国，最初竟诞生在德国柏林一家熟肉店的后院！（开头直接回答用户问题）

1847年，当维尔纳·冯·西门子脱下普鲁士军装，租下那间飘着烤猪肘香味的作坊时，连隔壁面包师傅都嘲笑这个整天摆弄电线的年轻人。

可就是这个被当作怪人的前炮兵军官，用一根电报线撬动了整个工业革命。

故事要从德国北部的小村庄伦特说起。1816年出生的维尔纳从小就有种特殊天赋——他能把拆散的怀表重新组装成会转动的钟，还能用勺子电解出银层给朋友做生日礼物。（通过细节化描述，带给观众身临其境的代入感）

这种对电的痴迷，最终让他在1847年创立了西门子-哈尔斯克公司。

注意，这家公司的第一个爆款产品不是冰箱也不是发电机，而是指针式电报机！

当时的欧洲正处在通信革命前夜。柏林至法兰克福的电报线路项目，让西门子赚到第一桶金。

但真正让公司腾飞的，是维尔纳三兄弟的全球布局战略：大哥坐镇柏林搞研发，二弟威廉攻克英国市场，三弟卡尔甚至把电线铺到了沙皇的冬宫。

到1879年柏林工业博览会上，西门子已经能骄傲地展示世界首辆电力列车——比爱迪生发明电灯还早两年！

如今178年过去，这个德国品牌早已超越国界。2024财年第一季度，西门子新订单额飙升至223亿欧元，在190个国家拥有32万员工。

从你家冰箱里的PT净味技术，到医院的核磁共振设备，甚至太空站的供电系统，那个曾在肉店后院闻着香味饿肚子的发明家，真的让全人类都通上了他的电。

不过最讽刺的是，当年维尔纳为省钱发明的电镀术，如今却成了西门子高端家电的标配工艺。

下次当你打开那台标着SIEMENS的冰箱时，别忘了里面藏着个德国工业史上最美味的创业故事——毕竟没有哪家世界500强，是从闻着烤猪肘香味开始的。

2.2 多类型素材生成

目前AIGC视频中，电商视频素材相比于通用场景素材，存在两点挑战：

• 视频素材少

     原始视频少：业界通用视频素材对于电商信息，特别是长尾商品信息覆盖较少。

     可用视频少：在电商类视频中，对品牌商品等实体一致性要求极高，进一步加剧视频供给问题。

• 传统视频检索准确率低：电商场景下对于品牌/商品实体一致性要求极高，传统通用视频检索系统在电商场域下实体理解效果差，检索准确率低，导致视频不可用。

针对上述两个挑战，我们提出了两步解决方案：

• 泛图表生成，进一步增加差异化供给： 基于大模型代码生成能力，自动化构建30+个泛图表模板，并通过MCP形式对外开放；通过大模型规划能力，根据脚本选择最优图表模板并生成泛图表内容，端到端图表生成可用率达92%。

图表效果如下：

整体流程如下：

• 素材多维度优选：基于多模态视频理解大模型，从电商实体一致性，视频清晰度等多维度构建端到端优选能力，提升视频素材质量，视频粒度准确率大大提升。

  实体一致：基于Qwen2.5-VL-32B模型，对视频中实体细节进行多维度理解推理，尤其注重商品实体一致性。

清晰度高：通过自研模型对视频清晰度划分清晰/普通/模糊三档，对模糊类视频进行过滤。

2.3 大模型剪辑成片

通过大模型多轮规划推理，进行素材/布局/动效/音效等多视频元素全局优选，完成最终视频剪辑并成片。整体流程如下：

03 后续方向演进

• 端到端剧本生成：

     现有问题：现有的2.0框架本质上与传统检索系统类似，存在多个子Agent模块前后依赖，这导致了不同链路目标不一致等问题，制约了视频效果的增长。

     解决方案：构建剧本生成Agent，基于大模型进行端到端的完整剧本生成。通过端到端的剧本撰写，视频的画面，脚本，BGM可以实现优化目标的统一化。

• AIGC生成式视频：

     现有问题：目前视频是基于现有的视频素材打碎重组（混剪）而成的，在很多时候都面临供给不足的问题，而AIGC生成（文生图/视频）的方式能较好的解决这样的问题。

     目前困难：AIGC生成目前的可用率仍不足，会出现文字乱码，人物/实体错误，物理规律不遵循等问题，在电商商品场景下尤为明显，这些仍需要进一步去探索和尝试。

导读

本文主要介绍基于流批一体建设的Feed实时数仓在业务高速发展和降本增效的大环境下，所面临的问题和挑战，以及对应的解决方案。文章分为四个部分，首先介绍下旧的Feed实时数仓的整体架构设计；然后介绍随着业务的不断发展，旧的架构所面临的问题；第三部分是文章的重点，着重介绍重构升级后的Feed实时数仓架构设计，以及在重构升级过程中所遇到的关键性问题和解决方案；第四部分是总结和规划，Feed实时数仓重构升级后，带来了什么样的收益和业务效果，以及对实时数仓未来发展的一个思路探讨。

01 简介

Feed实时数仓是一个基于 feed 日志产出 15 分钟的流批日志表，主要用于对日志原始字段的解析，并下沉简单业务逻辑。该表保留最细粒度的用户明细数据，是Feed数据的最底层数仓宽表。其整体架构设计如下图所示

数据源：Feed实时数仓的数据源主要是各种日志打点数据，主要包括手百端打点和服务端打点。通过使用MEG日志中台提供的一站式打点方案，对用户的行为明细打点数据进行收集管理。

数据采集：数据采集过程，首先通过minos（百度自研的新一代的流式日志传输系统）的agent服务将打点服务的日志进行采集传输到实时流中，然后由日志中台的清源系统进行统一的清洗，对所有的日志打点数据进行格式化，统一schema。清源系统会将统一处理后的数据，传输到厂内消息队列bigpipe中（百度自研的分布式中间件系统）。

数据清洗：数据清洗分为两阶段。

第一阶段为基于TM流式框架搭建的Feed流式计算作业，该作业订阅消息队列bigpipe中的数据，对日志的原始字段进行解析，并下沉一些简单的Feed业务逻辑。流式计算处理结束之后，根据打点数据的生成时间进行落盘，生成刻钟级目录的数据。

第二阶段为基于StreamCompute框架搭建的批处理作业，该作业的任务是对第一阶段产出的刻钟级目录数据进行字段结构统一，并生成hive、spark等查询引擎能够直接查询的orc格式文件，最后将数据导入到实时数仓中。

数据仓库：

Feed实时数仓作为底层明细数据，虽然是DWD表，但保留着ods层数据的特点，存储着Feed日志打点的基础数据。

Feed业务基于实时数仓的数据，对复杂的业务逻辑进行下沉，产出小时级的离线DWD表，作为 feed 主要对外服务的数据表。并在DWD表的基础上，拼接其他主题数据，进行数据聚合，产出ads 层的主题宽表、中间表。

Feed评估业务基于Feed实时数仓，对cuid进行聚合，产出cuid粒度的评估中间数仓宽表。

数据应用：Feed实时数仓下游的数据应用，主要包括策略信号、实时应用、实时报表等高时效性的应用，主要用来检测数据趋势，观察实验策略、热点活动等带来的数据变化，主要是对Feed的分发、时长、au等指标的影响。

02 实时数仓面临的核心问题

随着业务的不断发展，越来越多的下游业务开始接入Feed实时数仓，比如商业、电商、直播等业务。Feed实时数仓急需解决以下几个问题

1. 计算过程繁琐，成本高时效慢

Feed实时数仓的整体架构为流处理+批处理的架构。其中流处理主要进行日志的ETL处理，订阅消息队列bigpipe中的实时流数据，进行清洗加工，产出统一的proto格式数据；批处理过程是对ETL后的proto格式数据进行格式转换，生成可供hive查询引擎直接查询的orc格式数据。

时效慢：流+批的数据处理架构，使得实时数仓数据的产出时间达到了45分钟，端到端数据应用的产出时间更是达到了50分钟以上。

随着手百业务的不断发展，实验评估、直播、电商等业务对数据的时效性提出了更高的要求。比如Feed实验对照组需要更快的实时监控来观测不同的实验策略对Feed的分发时长带来的收益，电商直播需要更快的实时监控来观察不同的分发策略对于直播间观看情况的影响。50分钟的实时监控已经无法满足这类高时效性的业务场景，尤其是重要时事热点、重大直播活动等热点项目。

成本高：实时计算处理过程使用了TM+SC两套流式架构，其中TM部分承担流式数据的清洗和简单的指标计算，SC部分主要是负责批处理的字段结构统一工作。流+批的处理架构成本偏高，其中TM部分需要240w/年，而SC部分需要360w/年，其负责的字段结构统一工作和消耗的成本明显不成正比。SC架构本是百度自研的一站式流式计算服务，在此项目中用来进行批处理的工作，造成了严重的资源浪费。

2. 下游业务多，指标对不齐

随着电商、直播等业务的发展，越来越多的业务开始接入Feed数据，原本只是为单一Feed业务提供的实时数仓宽表，其下游不断增加，包括且不限于评估实验、分润、商业、电商、直播、百家号等业务。由于Feed实时数仓只是数据清洗之后的用户明细数据，并不包括指标和维度相关的信息，比如点击、展现、播放时长、互动等指标，入口来源、视频类型、干预类型等维度信息。各下游在使用这些指标、维度时都需要根据宽表中的基础数据进行计算。由于下游使用方比较多，且分属不同的部门，计算口径往往无法统一。

以Feed实验评估业务为例，随着Feed业务的发展，核心指标口径也不断变化，导致实验指标和Feed大盘指标无法完全对齐，已经严重影响Feed业务迭代。对于口径对不齐问题，评估中心，数据中心做过专项治理，对齐Feed大盘+视频口径，解决了部分问题；但随着业务持续迭代，数据对不齐问题再次加剧，所以急需从根本上解决指标对不齐的问题。

3. 系统架构冗杂，稳定性差

Feed实时数仓整体架构从日志采集端到应用端，每个阶段的作业都未区分核心和非核心数据。尤其是数据采集部分和数据清洗部分，都是漏斗形架构。这样的架构就会出现，若非核心数据流量暴涨，会引起整体链路上的水位延迟，甚至会阻塞核心数据的处理，最终影响核心数据的使用。

03 实时数仓重构方案

3.1 整体架构

新的实时数仓架构，从数据采集到数仓阶段全部进行了重构升级。

数据采集：

对日志打点从业务、点位重要度 两个维度进行拆分。下图以Feed、手百业务为例，日志中台的清源系统拆分出Feed核心作业、Feed非核心作业，分别处理Feed的核心和非核心数据，核心和非核心日志打点输出到不同的消息队列中，从源头实现核心和非核心数据的解耦。

**数据清洗：**对应核心和非核心消息队列，建立两个独立的数据清洗作业（核心作业和非核心作业）。

1). 字段抽取逻辑保持不变，依旧只是对数据进行简单的清洗。

2). 增加指标计算环节，该指标计算环节对应原架构中Feed离线数仓的小时级明细宽表的逻辑，将离线的复杂业务逻辑下沉到流式计算环节。最终产出的的实时数仓中包含了计算好的指标结果，由于Feed实时数仓为Feed数据的唯一出口，下游在使用时候可以忽略Feed业务逻辑的计算，直接使用Feed实时数仓产出的指标字段，从而解决下游指标对不齐的问题。

3). 删除流转批的处理环节，将字段格式统一的工作集成到流式计算环节中。基于TM流式框架实现了包括字段抽取+指标计算+字段格式统一的全部流式计算处理，减少了流转批的过程，节省大量计算资源，同时还提高数据产出时效性。

数据仓库：新版的Feed实时数据的字段结构与原架构中的Feed离线DWD数仓宽表保持一致，对Feed离线DWD数仓宽表中所有的复杂业务逻辑进行了下沉，新版Feed实时数仓=Feed离线DWD数仓宽表的实时化。下游应用直接通过简单的count/sum操作就能得到feed的各种指标结果，指标查询效率提升90%。

3.2 关键问题解决方案

3.2.1 离线复杂业务逻辑实时化解决方案

由于Feed实时数仓是Feed所有数据的唯一出口，将Feed离线DWD数仓宽表中的复杂业务逻辑下沉到实时数仓中，将从根本上解决下游各业务指标口径对不齐的问题。离线复杂业务逻辑下沉到流式，主要存在以下两个问题。

3.2.1.1 离线和实时数据计算维度不一致

实时数仓和离线数仓建模维度不一样，业务逻辑无法直接下沉。旧的实时数仓是面向数据源建模，所有的字段抽取逻辑是基于不同的日志源进行抽取，比如端打点日志、PC打点日志、服务端日志等；而Feed离线数仓是基于业务建模，分成了点击、展现、时长、互动等业务分区，业务逻辑、指标计算也是在这些业务维度基础上进行处理。

解决方案：

在流式计算环节中，业务逻辑处理分为三层进行。如下图所示，第一层依旧进行字段抽取的数据清洗处理；第二部分根据根据关键字段信息，对所有日志数据进行业务逻辑分区；第三部分，该部分处理逻辑对齐离线的复杂业务逻辑，不同的业务分区，执行不同的业务逻辑计算。最终生成业务维度的实时数仓底层数据。

3.2.1.2 下游用户无法直接进行切换

原Feed实时数仓和Feed离线DWD数仓宽表，数仓建模维度不一样。原Feed实时数仓是简单清洗的日志明细表，只是对日志的字段进行简单的裁剪；Feed离线DWD数仓是对Feed实时数仓宽表进一步加工之后的表（包括删除无用日志字段信息（比如实验sid信息等）、删除无用打点日志、 通过日志明细计算出维度/指标字段）。如果新的实时数仓宽表字段要和离线DWD数仓宽表建模保持一致，原实时数仓下游使用方无法直接迁移到新的Feed实时数仓。

解决方案：

1. 功能单一的大字段单独抽出，建立一个新的明细表。如sid字段，建立sid明细表，下游用户使用时通过cuid等字段进行关联。

2. 无用打点日志：对于Feed业务来说无用的打点日志，单独保留到非核心分区。

3. 新的实时数仓宽表，在离线数仓宽表字段基础上，增加字段用以表示旧实时数仓宽表中分区信息，兼容历史分区逻辑，以供下游切换时使用。

3.2.2 字段格式统一实时化解决方案

字段格式统一，主要是将清洗之后的数据，按照实时数仓的schema进行字段的格式进行统一，同时将最终数据文件(行存)转为ORC列式存储格式，以供hive、spark等查询引擎进行高效的查询。

在原来的数据架构中，字段格式统一只能由sc或者spark进行处理，所以只能使用流+批的方式进行实时数仓的生产，这造成了严重的资源浪费。将该部分处理工作集成到流式计算TM任务中，数据生产成本至少降低200万/年；同时缩短数据生产链路，提升数据产出时效。详细解决方案如下。

3.2.2.1 数据存储格式选定Parquet格式代替之前ORC格式作为最终数据的存储格式

Parquet是一种专为大数据处理系统优化的列式存储文件格式。目标是开发一种高效，高性能的列式存储格式，并且能够与各种数据处理系统兼容。Parquet 在2013年作为开源项目被创建，在2013年6月被 Apache 软件基金会采纳为顶级项目。它的开发受到 Apache Parquet 社区的积极推动。自推出以来，Parquet 在大数据社区中广受欢迎。如今，Parquet 已经被诸如 Apache Spark、Apache Hive、Apache Flink 和 Presto 等各种大数据处理框架广泛采用，甚至作为默认的文件格式，并在数据湖架构中被广泛使用。

Parquet具有以下优势

列式存储：

• Parquet 是一种列式存储格式，有多种文件压缩方式，并且有着很高的压缩比。

文件是可切分（Split）的：

• 在Spark中使用parquet作为表的文件存储格式，不仅节省AFS存储资源，查询任务的输入数据量减少，使用的MapTask也就减少了。

支持谓词下推和基于统计信息优化：

• Parquet 支持谓词下推和统计信息(例如最小值、最大值、空值等)，这使得在执行查询时可以更有效地过滤和优化数据访问。这对于加速查询是非常有帮助的。

支持多种数据类型和模式演进：

• Parquet 支持多种数据类型，包括复杂数据结构，这使得它适用于各种类型的数据。此外，Parquet 允许模式演进，即在不破坏现有数据的前提下修改表结构，提供了更大的灵活性。

3.2.2.2 在TM框架中引入Apache Arrow开源库实现输出parquet格式文件

Apache Arrow 定义了一个与语言无关的列式存储内存格式，可以理解为parquet文件加载到内存中的表现。

上图为Proto格式数据通过Arrow 转为Parquet格式数据的详细过程。

1. TMSinker算子（TM流式处理框架中输出算子）收到上游产出的proto数据后，首先将数据分成4份，每一份对应一个线程，

2. 每个线程将自己负责的数据转成一个RecordBatch; 具体操作是解析Protobuf数据，将数据进行格式映射，构建一个Arrow Schema，填充到RecordBatch中，然后将4个RecordBatch合成一张Table。

3. 使用Arrow提供的API，将Arrow Table写入到Parquet Writer，Parquet Writer负责把数据刷新到磁盘上。

部分组件概念如下：

RecordBatch，可以理解为一张子表，有schema信息和每一列数据，常作为并行计算的子数据单元。

Table可以理解为一张列式存储的表在内存中的表现形式，可以由多个RecordBatch合并而成。

3.2.2.3 实现过程中出现的其他问题及解决方案

小文件变多问题

原架构中，字段结构统一是批处理，会等15分钟的数据都产出之后，集中进行处理；而新的架构中，将字段结构统一的处理集成到流式计算中，导致小文件数过多。太多小文件会导致查询引擎增加对元数据读取开销等问题，影响查询稳定性，甚至会出现占满slot情况 影响其他任务。

小文件产出原因：正常TMsinker算子是通过攒task(数据大小+超时时间)减少小文件产生，但会存在跨时间窗口的数据，从而产出小文件问题。平均每15分钟会产生5234个文件，其中小文件951个，小文件占比18%(略早到的文件占比10%；略晚到的占比8%)，平均文件大小258MB -- 未压缩）。

解决方案：

1. TMsinker 算子每次请求tm server获取task数由1个变为多个（可配置），避免出现sinker获取1个task就处理的情况，同时降低tm server的压力。

2. 优化时间等待策略和攒数据策略

a. 默认配置

• 默认每次获取task数200个；(默认值200；用户可通过配置项覆盖)

• 最大等待时间20S；（默认20秒；时效和文件size的平衡；用户可通过配置项覆盖

• 最少积攒数据800MB； (默认800mb；用户可通过配置项覆盖)

b. 详细策略

• max_num: 一次性可获取并锁定的最多task数量

• last_num: 上一次获取并锁定的的task数量

• num: 当前获取并锁定的task数量

大文件转parquet失败问题

在使用arrow库把proto格式数据转为parquet格式数据过程中，当某一列 string 类型的数据超过 2G 时格式转换会失败。

首先我们从string在内存中的表现形式来进行分析

Length：表示这一列一共有多少条数据

Null Count：表示这一列一共有多少条数据是Null

Validity Bitmap：位图，1代表非Null，0代表null，用于快读判断某条数据是否是null

Value Buffer： 存储 string 数据 list;

**Offsets Buffer：**存储每条数据在ValueBuffer中的位置

如上图，string的offsets buffer是list，因此string类型最大只能支持2^31字节=2G的数，如果在这条数据之前所有的数据已经超过2G了，那么因为Offset是int32无法表示大于2G的整数，导致这条数据无法转换。

问题原因找到，解决方案就很简单了，将string替换成large_string类型即可，其offsets buffer是list。

压缩耗时高问题

通过查看arrow库的源码，我们发现Arrow库当前使用的ZSTD压缩方法的Simple API，而Zstd库提供了 Simpler/Advanced API。这两个API的区别是Simple API只能设置压缩级别，而Advanced API可以设置压缩级别和压缩线程等。

解决方案：修改源码中ZSTD压缩方法的API，改为Advanced API，并通过环境变量暴漏多线程相关的参数。

以配置6核CPU为例，单线程时最多整使用1个核，多线程时可以使用到5.5个核

字段结构统一实时化最终整体解决方案如下：

04 总结与规划

Feed实时数仓重构升级完成后，流批一体架构升级为纯流式架构，整体计算成本节省50%，实时数仓数据产出实效缩短30分钟，提速80%。离线复杂业务逻辑下沉，指标查询效率提升90%，DWD明细宽表产出时效提升3小时；Feed宽表统一指标出口，其他下游和Feed业务线完成口径对齐，从根本上解决了指标对不齐的问题；流式计算整体架构统一到流式TM框架，维护成本降低50%，端到端核心非核心数据完成拆分，服务&数据双隔离，互不影响，服务稳定性大幅提升。

针对Feed实时数仓的后续规划，我们计划从计算引擎上进行优化升级，对标业界主流实时计算引擎，改变现有的C++代码开发模式，提高流式计算服务的开发效率，降低开发成本，以应对快速发展手百和Feed业务，满足越来越多的数仓需求。同时未来我们将把Feed实时数仓建设成厂内实时数仓标杆，为更多的业务提供实时数据服务。

导读

BaikalDB作为服务百度商业产品的分布式存储系统，支撑了整个广告库海量物料的存储。在大语言模型LLM蓬勃发展的现在，想在大模型里使用BaikalDB里的数据进行分析，都需要复杂的定制开发。看BaikalDB如何借助模型上下文协议(MCP)，让数据库对话像聊天一样简单——无需编写代码，大语言模型即可完成复杂数据分析。

01 引言

在2025年以前，大语言模型（Large Language Model‌，LLM）想要使用数据库的数据，都需要开发人员设计接口、开发Agent插件、构建Prompt等费时费力的一系列定制开发；同时面对不同大模型的差异，还需要额外的重复性工作进行适配。

随着模型上下文协议（Model Context Protocol，MCP）的标准化普及，这一局面被彻底重构。MCP通过定义统一的上下文交互规范，为应用程序与AI模型建立了 “通用通信协议”。

基于此，BaikalDB团队创新推出‌BaikalDB MCP Server‌，将其打造为连接LLM与分布式存储系统的 “智能USB接口” ——该方案具备三大核心价值：

1. 零开发集成‌：支持主流LLM通过标准化协议直接访问BaikalDB，无需编写任何适配代码。

2. 全链路自动化‌：从自然语言意图理解、SQL智能生成到查询执行与数据分析，实现端到端闭环。

3. 多模型兼容性‌：屏蔽底层技术差异，一套接口适配GPT、Claude、文心一言等各类大模型。

02 MCP: AI USB接口

2024年11月由Anthropic公司提出的模型上下文协议MCP，是一种标准化的大模型与外部数据源、工具交互的开放协议。来源于USB接口范式的设计灵感，MCP的核心思想在于：通过创建一个通用的标准（如USB接口设计），解决大语言模型与外部系统间的“信息孤岛” 问题，该协议通过三大核心原则重构AI开发生态：

1. 即插即用标准化：定义统一的上下文交换格式，使大模型与数据源/工具的对接效率提升80%以上。

2. 组件解耦化：支持不同AI模块的热插拔组合，开发者可像搭积木般构建复杂AI系统。

3. 语义透明化：通过标准化上下文标记，实现跨组件意图传递的零损耗。

△MCP设计理念

2.1 MCP 组成

如上图所示，MCP 由三个核心组件构成：MCP Host、MCP Client 和 MCP Server：

官方文档链接：

modelcontextprotocol.io/clients

modelcontextprotocol.io/quickstart/…

modelcontextprotocol.io/quickstart/…

github.com/modelcontex…

MCP Server的三类能力：

• 工具类（Tools）——  模型的「智能外设」

     供模型调用的函数或服务，用于执行特定任务。如一个天气查询工具，获取指定城市的天气信息。

• 资源类（Resources）——模型的「知识库」

     供模型读取的数据源，如文件数据或 API 响应内容，为模型提供了丰富的上下文信息，增强了模型的理解能力。

• 提示词（Prompts）——模型的「操作指南」

     预先编写的模板，旨在帮助用户完成特定的任务，通常是为了优化工具或资源的使用，提供一种更高效、更准确的交互方式。

MCP Client和Server之间的三种通讯方式：

• STDIO 传输

     MCP Server运行在本地。

     通过标准输入（stdin）和标准输出（stdout）建立双向通信，1对1服务。

• SSE 传输

     MCP Server运行在本地或远程运行。

     通过服务器发送事件协议（SSE）进行通信，支持N对1服务。

     在 2024-11-05 版本废弃，被 Streamable HTTP 替代，后者将 SSE 作为可选的流式传输机制纳入其中。

• Streamable HTTP 传输

     MCP Server运行在本地或远程运行。

     通过可流式HTTP传输协议通信，支持N对1服务。

     支持流式传输，适合大数据量场景，提供更灵活的传输能力

2.2 MCP 流程

文心快码Comate是百度基于文心大模型开发的智能代码助手，旨在通过AI技术重构编程流程，提升开发效率与代码质量。目前Comate不仅支持‌‌智能代码生成‌、单元测试生成等功能，还支持接入外部MCP Server与大模型进行交互。

以在文心快码Comate里通过BaikalDB MCP Server对BaikalDB数据进行查询分析举例：

1. MCP Host：Comate Desktop 作为 Host，负责接收提问【分析42601969用户在 2023-3月每天的转化总数，按照时间升序排序，用折线图展示，并分析趋势走向 】并与大模型交互。大模型解析提问，并生成对应的SQL。

2. MCP Client：当大模型决定需要baikaldb_mcp/read_query Tool，Comate 中内置的 MCP Client 会被激活。这个Client负责与BaikalDB MCP Server建立链接并调用read_query工具。

3. MCP Server：BaikalDB MCP Server被调用，接收、执行查询语句，最终返回SQL执行结果。

完整执行流程：你的问题 → Comate Desktop → 大模型 → 需要查询BaikalDB表，并生成对应SQL → MCP Client 连接 → BaikalDB MCP Server → 执行SQL并返回结果 → Comate生成回答 → 生成折线图。

MCP架构设计使得如Comate等LLM应用，可以在不同场景下灵活调用各种工具和数据源，而开发者只需专注于开发对应的 MCP Server，无需关心 Host 和 Client 的实现细节。

03 BaikalDB MCP Server

3.1 BaikalDB MCP Server主要功能

BaikalDB MCP Server提供了以下功能，支持大模型直接和BaikalDB数据库进行交互：

1. 工具类（Tools）：大模型可以根据上下文按需调取的直接和BaikalDB交互的工具。

• 链接操作：链接到指定的BaikalDB库

     connect_baikaldb：给定链接信息（包括host，port，username，password，database），连接到对应的BaikalDB数据库，使用过程中支持动态切换不同的BaikalDB集群。

• 查询操作：包括获取库表信息，执行SELECT/DML SQL，分析SQL索引使用扫描量等。

     show_all_databases：获取所有的数据库列表信息。

     db_overview：获取指定数据库中所有表的概览信息。

     table_overview：获取指定表的概览信息，包括：表结构（show create table）、表示例数据（select * from table limit 3）。

     read_query：执行select sql并返回csv结果数据，大模型拿到结果可以进行智能分析、智能绘图等等。

     write_query：执行建删表、插入删除变更等dml sql并返回操作结果。

     analyze_select_query：分析查询SQL执行情况：使用的索引，索引扫描/过滤/反查行数等，支持大模型进行索引分析推荐。

• 模板操作（优化复杂场景使用）：支持预先导入模板SQL（如百度智能云推出的Sugar BI SQL模板），帮助大模型理解业务逻辑，后续大模型可在模板SQL基础上改写查询分析，并支持基于模板进行二次查询（如再次聚合），不同BaikalDB用户之间模板不共享。

     get_all_bi_sql_template_list：查询当前BaikalDB用户已导入的SQL模板列表。

     get_bi_sql_template_detail：获取SQL模板详细信息，包括SQL模板，相关表Schema等。

     add_bi_sql_template：指定模板说明，模板SQL等，添加新的SQL模板。

     delete_bi_sql_template：删除指定的SQL模板。

2. 资源类 (Resources) 和 提示词 (Prompts)：

• 目前BaikalDB MCP Server暂未定义资源和提示词，未来会根据使用场景灵活添加，以更好的引导大模型和BaikalDB进行交互。

通过以上工具，BaikalDB MCP Server使得大模型能自主的查询/操作数据库，进行多轮数据智能分析，并且可以结合大模型和其他MCP能力，并高效的通过多种形式呈现分析结果（如Excel文本，绘制图表等）。

3.2 BaikalDB MCP Server应用场景

BaikalDB MCP Server拥有以上能力后，就可以在以下场景中进行使用：

1. 实时数据分析和智能报表

• 大模型可以实时查询BaikalDB的业务数据，生成可视化报表，并可结合历史上下文生成分析报告或者建议。

2. 多数据源联邦查询分析

• 通过MCP支持大模型同时访问BaikalDB和其他数据源（如知识库、Mysql等），实现联邦分析。

3. 开发测试提效

• 在开发测试过程中，通过自然语言交互，建删改表、增删改查、构造测试数据、分析SQL执行情况等，不用额外切多个窗口执行SQL操作。

04 BaikalDB MCP Server使用

BaikalDB MCP Server使得BaikalDB不单是个高性能的分布式数据库，还是大模型的分析执行插件，使得用户不再需要任何开发，即可对BaikalDB存储的数据进行智能分析。

4.1 Comate 配置

以Comate举例：按照以下图示步骤，将BaikalDB MCP Server json配置添加到Comate MCP配置文件中，即可以在Comate中使用大模型操作BaikalDB数据库。当然后续我们会尝试将BaikalDB MCP Server发布到MCP仓库，使得配置更简单！

BaikalDB MCP Server Json配置如下：

{  
    "mcpServers":  {
        "baikaldb_mcp": {
            "transport": "sse/streamableHttp",
            "url": "BaikalDB MCP Server URL",
            "headers": {},
            "timeout": 50
          }
     }
}

4.2 Demo 演示

示例1：智能分析

下方视频展示了，在Comate中用自然语言对数据库数据进行智能分析和图表展示。 mpvideo.qpic.cn/0bc34mc4gaa…

示例2：开发测试提效

下方视频展示了，开发测试过程中的智能建表、导数、SQL执行分析、索引推荐等。 mpvideo.qpic.cn/0b2eiaadqaa…

示例3：基于模板智能分析

下方视频展示了，在复杂业务场景中，通过预先导入的BI SQL模板进行更高效准确的智能分析。 mpvideo.qpic.cn/0bc3omc24aa…

05 总结

BaikalDB MCP Server的核心价值在于打破了数据库数据的信息壁垒，构建了一条完整的智能数据处理链路，实现了从自然语言解析到业务建议输出的端到端能力：‌

• 自然语言理解：将非结构化查询转化为结构化意图。

• 数据库操作：自动生成并执行SQL语句。

• 数据分析：对查询结果进行多维解读并生成可执行建议。

但是也存在一些问题：‌

• SQL生成准确性高度依赖元数据质量（如表结构、字段注释）。

• 复杂业务逻辑描述困难。

• 大模型在长上下文中的注意力分配问题。

当然，随着大模型推理能力的持续提升和MCP协议生态的完善，这种数据智能范式将在金融风控、供应链优化、智能客服等复杂业务场景中展现出更大的价值潜力。

你有没有这样的体验？导航说30分钟能到，结果真的一分不差？

有时候导航告诉你要绕行5分钟的路，其实省下了20分钟的堵车。

这些神奇的“预知能力”，就是我们常听到的 ETA（Estimated Time of Arrival，预计到达时间），别看它们只是一个个数字，其实背后藏着一整套复杂又高效的技术体系。

百度地图 ETA

到底是怎么精准计算出来的呢？

【AI地图 Tech 说】第二期将为你揭开奥秘！

01 基础介绍

ETA 预测的本质，就是给定出发地、目的地和出发时间后，预测驾车所需的时间。例如，当你在某个时间 T 请求路线（如 Route = a→b→c→d→e）时，ETA 系统便开始计算驾车预计行驶的时长。

百度地图 ETA（未来出行）是地图导航的基础功能，其技术演进共经历了四个发展阶段。

▎ 1.0时代：静态 ETA（2010年前）

最初，百度地图 ETA 功能的计算方式极为简单，仅通过距离除以限速得出。然而，这种方式计算出的结果误差常常超过30%，一旦遭遇交通拥堵状况，更是完全无法应对，由此引发了用户的诸多吐槽。

▎ 2.0时代：动态 ETA（2010-2015年）

百度地图首次接入实时交通数据，能够识别实时拥堵路段并提供基本绕行建议。然而，这种方法仍无法预测拥堵的进一步变化趋势。

▎ 3.0时代：个性化 ETA（2015-2021年）

通过引入机器学习与用户画像，百度地图开始分析驾驶习惯（如激进型或保守型司机）、车辆类型（如货车或新能源车），实现了针对不同人群的个性化路线推荐。

▎ 4.0时代：预见性 ETA（2021年至今）

百度地图融入 AI 技术，如预训练大模型和时空预测技术，开始实现未来30-60分钟的精准路况预测，甚至能准确量化天气对行车速度的影响。

02 技术优势

百度地图 ETA 为何如此精准？背后的核心在于预训练交通大模型与端到端路线通行时间预测两大技术。

▎ 预训练交通大模型：海量 AI 知识集成体

预训练交通大模型通过地图脱敏轨迹数据，建模城市交通规律，为智能交通提供底座能力。预训练交通大模型基于千亿公里驾驶数据，能够精准捕捉不同城市在时段、天气、区域上的交通规律，如北京周一比周五早高峰堵12%、上海雨天车速下降22%、深圳科技园晚高峰比早高峰堵35%。同时，该模型还具备持续学习优化能力，每天都会结合最新观察到的真实拥堵情况自动更新模型参数。

预训练交通大模型整体框架

预训练交通大模型的框架主要分为3个部分：

交通大模型以及下游应用

■ Large-Scale Traffic Corpus（大型交通语料数据）

将原始的脱敏 GPS 轨迹点处理成路段粒度的交通时序信息和路线粒度的个性化导航行为。

■ Pre-Train Model（预训练模型）

基于历史交通大数据充分训练预训练模型，表征普适性的交通规律信息。

■ Downstream Task（下游任务）

基于预训练的交通图嵌入，通过 Zero-Shot 或者 Fine-tune 应用于通行时间预估、交通流量预估、路线排序、智能信控等场景。

▎ 端到端路线通行时间预测：基于交通大模型 FineTune 的 ETA-GNN AI 仿真推演路线模型

在预训练交通大模型基础上，百度地图进一步应用端到端路线通行时间预测，进行更细致的 AI 仿真推演，不再局限于逐路段的简单计算，而是精确模拟红绿灯等待时间、前方车辆汇入情况及施工路段的实际通行效率。同时通过动态概率模型实时评估，决策绕行还是等待，以达到最佳出行策略，预测准确率高达92%。

SFT-ETA 路线模型

ETA 路线模型预测 Pipeline

端到端路线预测体系涵盖以下核心能力：

■ 长时流量预测能力（Supervised FineTune）

全天候预测能力：通过对历史流量数据的监督微调，模型可实现对未来 24小时路段流量变化趋势的精准预测，适用于节假日、景区周边等高动态场景。

零样本迁移泛化：预训练模型内置“早晚高峰模式库”，可直接迁移至新城市路网，实现冷启动场景下的预测精度显著提升。

■ 动态交通关系图谱建模

时空图表示学习：捕捉交通流随时间与空间变化的普适规律。

路网级传播效应建模：通过图神经网络（GNN）结构，量化不同路段之间的流量传导影响，实现更高精度的区域级拥堵预测与调度模拟。

■ 地理语义位置编码（GeoEmbedding）

多维地理语义融合：将传统经纬度转换为包含道路等级、POI 密度、地形坡度等语义信息的向量表示。

跨模态建模能力：融合天气、热度等环境信息，实现对不同条件下相同路段的动态编码与差异化建模，例如“暴雨下立交桥”和“晴天立交桥”的通行效率差异。

■ 轨迹表示学习与个性化 ETA

行为建模：通过车辆历史脱敏的轨迹聚类，区分不同驾驶风格（如保守型 vs 效率型），提供分群精准 ETA 预测。

实时风格感知与动态修正：感知车辆当前驾驶状态（如频繁变道、急加速等），动态调整 ETA 和路径建议，实现个性化自适应路线仿真与推荐。

03 应用场景

百度地图 ETA 广泛应用于各类场景中：

日常通勤：准确预测早晚高峰路况，帮助通勤族合理安排出行。

机场接送：精准判断当前出发是否能赶上航班，解决旅途焦虑。

重大活动预警：如演唱会结束前提前提醒车主提前离场，避免拥堵。

节假日旅游：提前预测旅游景区附近的拥堵趋势，提供更舒适的出游体验。

通过持续的技术进化和 AI 驱动的全面赋能，百度地图的 ETA 精准度在短途、长途、拥堵、节假日等多个场景均已显著领先行业水平，在用户感知层面更显稳健和准确。更值得一提的是，在节假日（尤其“五一”这类与日常规律差异显著的场景下），其表现尤为突出。

出行从此告别盲目与焦虑

百度地图将每一次的未知变成清晰的规划

让用户安心出发，自信抵达！

你有没有过这样的体验？在高速上对着导航喊“小度小度”，它就神奇地回应道“来了”；在地下车库问“最近的充电桩”，屏幕立刻跳出相关的充电桩指引；甚至对车载语音助手说“有点冷”，空调的温度就会悄悄调高。这些看似“读心术”的交互背后，藏着一个能听懂人话、能感知环境、能精准应答的“数字领航员”。

当你说“查找故宫附近的粤菜馆”时，系统不仅要从3亿多条 POI 数据中精准定位，还要理解“附近”是500米还是3公里；当你追问“有包厢吗”，它甚至能调用餐厅实时预订系统。这些看似简单的对话，需要跨越语音识别、语义理解、内容获取、答案生成等多重技术关卡。

百度地图 AI 导航小度想想

如何将自然语言转化为精准指令？

那些“秒回”的答案又是怎样炼成的？

【AI 地图 Tech 说】第三期将带你拆解这座“数字领航员”的魔法工厂，看看从“听清”到“听懂”方面，究竟藏着多少黑科技。

上图说明了从用户请求到最终执行的整个过程，可以看到其中经过了语音识别、意图解析、技能承接等主要的环节！

01 语音指令的解码之旅：从声波到文本

当用户说出"导航到故宫博物院"时，系统首先启动声学模型将声波转化为文字。这个看似简单的步骤，其实也不容易，蕴含三层技术环节：

▎ 基础识别

其实就是我们大家常说的语音识别技术，它利用深度学习模型将声波信号转化为二进制序列，结合声学模型与发音词典生成初步文本。语音识别技术近年来经历了白盒化到黑盒化的演进，其性能、效果都有很大的提升，大家应该都已经比较熟悉。但相对于安静室内环境，用户在户外使用小度想想的时候，还有一类常见的问题是拒识。根据统计，至少有15%左右的语音请求是由于误唤醒/误收音引入的（非用户主观需求）。小度想想，需要考虑到行驶过程中的风噪、聊天、多媒体播放等复杂噪音场景，百度地图引入了双重拒识判断模型（声学拒识、语义拒识），提前对问题请求进行甄别和提前拦截，最大限度降低用户干扰，大幅提升用户体验。

▎ 纠错

通过语言模型（如BERT、N-Gram）对识别结果进行上下文纠错，例如将“北经”修正为“北京”。这是小度想想相对于通用的语音助手的优势所在，在纠错的过程中，会使用包括地图 POI 数据、路名数据等专业字典进行参考。百度地图建设了超亿条 POI 数据的本名、别名、关联名的地理知识图谱，将 POI 的各种表达方式建立标准化映射。在此过程中，还需要构建错误拼音-标准名称的双向索引表，支持"西单大悦成"→"西单大悦城"这样的智能纠错。

▎ 排序

在实际工程中，纠错手段不可能只有一个，因此就需要在上述流程完成后，基于多个逻辑，会输出多个可能的识别结果。这里就会基于用户之前的对话习惯，以及一些其他基于先验知识和统计学习的置信度评分算法，从多个候选文本中选取最优结果（比如“横屏模式”，在排序中会优于“红屏模式”）。

02 意图解析的"翻译官"：把自然语言转化为机器指令

当从语音的音频识别为自然语言之后，下一步就是将其转化为机器指令。这里包括几个关键技术：

技术亮点一：『意图模板匹配』

基于自然语言处理（NLP）技术，完成实体识别（如时间“明天”、地点“北京”）、意图分类（如“天气查询”）、情感分析（如用户是否急躁）。过去的语义理解，更多使用模板类技术，如下图所示，针对用户问询的内容抽取出关键要素后，再看匹配了哪种需求表达方式，这称之为一个“意图模板”，基于大量预置的模板就可以实现大部分指令的识别。

技术亮点二： 『生成式意图理解』

模板化语义理解能解决很多问题，但是存在的关键短板在于泛化理解能力不足，同时高度依赖领域知识积累，需要提前做大量的模板标注，还要解决相近表达方式的模板冲突问题，当模板数量达到一定程度后维护成本就会增加。LLM 的出现，另辟蹊径地解决了这个问题。其核心优点是端到端利用 LLM 的上下文理解能力，直接解析用户自然语言中的隐含需求，形成对“口语表达中蕴含的本质意图”的理解，这个过程中无需构造模板，而是提前将全量承接 API 的参数规范作为“知识”以Prompt的方式注入 LLM，使其自主选择 API 并填充参数。举例来说，我们可以给大模型这样的 Prompt：

角色：你是一个语音助手语义解析器，目标是将用户指令转换为API调用
参考资料：可用的API及参数如下：
{API参数规范库}
用户指令：{user_query}
任务：请按以下步骤执行：
1. 选择最匹配的API；
2. 从指令中提取参数值，若未明确提及则设为null；
3. 输出JSON格式，包含api_name和parameters。
预期输出：{"api_name":
"search_flight", "parameters": {"departure_city":
"北京", ...}} 

大模型就能输出针对 user_query 最合适的工具调用参数，跳过了映射的环节，减少了折损，同时因为 LLM 对世界的强刻画能力，使泛化能力也大幅增强，这种模式已经在业内广泛使用，成为提升语义理解能力的主流方法。当然，大模型的应用中，少不了有成本、响应时间上的难题，所以实际工程中还是会大小模型混用，或者用小模型做定向的精调，来实现成本、性能和效果的兼顾。

技术亮点三：『工具调用』

工具调用是小度想想的下半身，是能够准确承接用户需求的关键支撑。其本质上可以理解为一系列 API 接口的调用。当调用序列复杂了之后，调用状态的维护就会成为问题，小度想想针对多轮复杂工具调用，提出了基于技能的状态机架构，任意复杂的操作，都可以基于这套架构来统一表达。

技术亮点四：『生成式 AI 时代的工具调用进阶』

在大模型的时代，为了提升工程化的效果，在 API 接口的基础上又诞生了两个公认的技术范式：

• MCP：聚焦模型与外部工具的连接，提供统一接口（如数据库、API调用），类似“AI 的 USB 接口”，降低跨模型开发成本。只要所有工具都以 MCP 的协议接入，那么大模型就可以知道这个工具能力的存在，从而能做到在合适的时候调用它。

欢迎使用百度地图 MCP 服务

• RAG：RAG 本质上是对问答能力的数据增强，如果小度想想仅仅基于老旧的 LLM 底座来回答问题，会有很严重的幻觉发生。为了解决这个问题，往往使用检索增强生成（Retrieval Augmented Generation，简称 RAG），百度地图将所有的地图领域数据以结构化来存储，然后在用户提问后，以向量相似性找到对应参考数据，并取出再用 LLM 做汇总，就相当于从“闭卷考试”变成了“开卷考试”，从而保证了答案的精准性。

03 持续提升生产力：从语音助手到智能体

随着 LLM 的能力越来强，我们发现，它的强大理解能力，对于一个一般化的常识问题，能给出相当接近人类的回答。那么是否它能模拟很多团队协作的真人，甚至以硅基生命来承接现实世界的生产力？这就是智能体（Agent）要考虑的问题了。智能体是这两年 AI 领域最火的词之一，它是基于人工智能技术在某个领域体现高度智能，显著提升人类工作效率的信息系统，相对于“语音助手”，更偏重于“通过观察、思考、权衡利弊，动态自主调用基础能力、高准确地解决复杂业务问题”的特性。

以自动驾驶场景为例，智能体可以实时感知车辆周围的路况、其他车辆的行驶状态、交通信号灯的变化等关键信息，为后续决策提供坚实的数据基础。自主决策能力堪称智能体的 “大脑”，它依据感知到的环境信息，结合内部预设的规则和先进算法，迅速、准确地做出决策。在面对复杂路况时，自动驾驶智能体能够综合分析各种因素，精准判断是加速、减速还是转弯，以确保车辆行驶的安全与高效。又如在智能物流配送中，智能体的核心目标是按时将货物准确送达目的地，为此它会综合考量实时路况、车辆载重等信息，动态规划最优配送路线，克服重重困难以达成目标。

回到语音助手这个场景，结合地图智能体的任务，首先要针对地图场景深入精调大模型，百度地图通过文心一言基座大模型进行二次预训练、SFT、强化学习等手段，使地图大模型能够精确理解用户在地图中的各种常见表达，理解准确率高达95%以上。

此外，针对复杂任务的执行，还要引入的两个特性是记忆和反思：

• 记忆能力：当用户表达不完整的需求时，能够基于之前的问答和用户行为，自动补全对话内容（如用户问“今天限行吗？”默认补充用户所在城市），因此需要构建记忆能力，用于存储历史交互数据、用户偏好与领域知识（如常用地址、路线选择习惯、节假日出行规律），为意图理解与决策提供背景支持，减少重复询问并提升个性化水平。这里面的短期记忆一般是指从启动会话至今的内容，往往持续数分钟，而长期记忆则是用户相对稳定固化的特征，就地图智能体来说，用户的搜索、导航记录等都是长期记忆的范畴。

• 反思能力：一个初始状态的智能体，在应对用户复杂需求以及实时环境快速变化时，往往会出现理解偏差、输出内容不完备与知识更新滞后等问题。引入反思（Reflection）能力，能显著提升服务的精准性与智能化水平。基于上述记忆-反思流程图，可以看到反思能力能不断地自我判断当前的答案是否满意。当然，客观来说，在大部分领域很难实现完美的反思能力，因为反思的本质是要在将答案呈现给人之前就能判断其质量，这里面存在大量主观因素和模棱两可的问题，在这个过程中，LLM 是第一大功臣，可以说针对语音对话类场景，没有 LLM 纯靠规则就不可能实现普遍有效的反思。除此之外，长短期记忆也起到了重要的作用，它能够结合用户之前的习惯，猜测当前的结果是否符合用户预期，如果不符合，会主动打回进行重新理解和执行。

04 案例解析：天气查询的完整技术链路

以一个简单的“明天北京会下雨吗”为例，系统执行以下操作：

• 语音识别：ASR 引擎输出“明天北京会下雨吗”文本；

• 语义理解：通过注册到小度想想的工具，结合这段文本，输出应当调用天气 API，获取相关数据；

• 服务调用：调用天气 API 获取预测天气数据；

• 答案生成：输出“明天北京阴有雨，15-25℃”；

• 反思与重新生成: LLM 审视这个答案，认为还不够详细，反思后认为应该按时间段细化降水概率，因此重新请求天气 API，获取更详细的降雨预测数据，并呈现给用户。

随着多模态大模型以及自动驾驶技术的发展，未来的小度想想会有更多的可能性。从大的趋势来说，语音语义一体化大模型正在逐渐成熟，2025年3月31日，百度在 AI DAY 上发布了业界首个基于全新互相关注意力（Cross - Attention）的端到端语音语言大模型，该模型实现了超低时延与超低成本。另外，多模态的对话（比如视频 AI 对话）和自动驾驶的结合也值得重视，比如通过车载摄像头识别"前方学校区域"并自动减速；通过声纹、视频和车辆传感器识别人、车的异常，主动采取应对措施；而在导航行中播报的时候，所有内容都是基于实时动态数据进行人格化生成，再也不像机器人那样的生硬，而是像真人一样地交流，让我们的出行更舒适高效。