导读

本文主要介绍基于流批一体建设的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 对话）和自动驾驶的结合也值得重视，比如通过车载摄像头识别"前方学校区域"并自动减速；通过声纹、视频和车辆传感器识别人、车的异常，主动采取应对措施；而在导航行中播报的时候，所有内容都是基于实时动态数据进行人格化生成，再也不像机器人那样的生硬，而是像真人一样地交流，让我们的出行更舒适高效。