导读

主要概述百度搜索业务数据建设的创新实践，重点围绕宽表模型设计、计算引擎优化和新一代业务服务交付模式（图灵3.0开发模式）三大方向，解决了传统数仓在搜索场景下面临的诸多挑战，实现了搜索数据建设的高效、稳定、低成本；为百度搜索业务敏捷迭代奠定夯实基础。

名词解释

TDS（Turing Data Studio）： 是基于图灵（百度内部数据分析平台）的数据建设解决方案，提供 数据开发、数仓管理、监控运维、资源管理等一站式服务的数据开发平台。详情参见：百度MEG数据开发治理平台-TDS

TDA（Turing Data Analysis）：是一款可视化BI产品，旨在帮助用户轻松上手及使用，进行拖拽式可视化数据分析及仪表盘建设。产品模块包括仪表盘、数据集、可视化分析及智能分析模块。详情参见：百度一站式数据自助分析平台（TDA）建设

TDE（Turing Data Engine ）：是基于图灵生态的计算引擎，包含Spark计算引擎和ClickHouse。详情参见：揭秘百度数仓融合计算引擎ClickHouse在百度MEG数据中台的落地和优化

UPI（Udw-API）：百度内部编程访问接口；以Map/Reduce计算框架为主，适用于计算逻辑复杂，以及多种数据源混合计算的例行离线数据挖掘业务

数仓融合计算引擎：是百度自主研发，基于spark自研的adhoc服务。提供数据查询分析，具有简单易用、超大规模支持、成本极低等特点，能实现T级数据秒级查询，也适用于例行生产的 ETL 场景。

函谷：图灵核心模块，作为图灵查询的gateway，完成图灵查询的接收、分发、提交执行、查询进展轮询、结果获取等一系列功能。

01 背景与问题

1.1 背景

在当今互联网产品发展日新月异、业务迭代迅猛的时代；跨业务分析的需求日益增长，这种变化既为企业创造了敏捷决策、精准运营的新机遇，也带来数据割裂、价值释放滞后等严峻挑战。特别是大型互联网企业，往往构建有复杂的多业务、多模块、多线条体系，每日持续产出海量的数据信息。这些数据的服务对象正逐步从数据研发人员扩展至更为广泛的产品相关人员，如何高效开展数据获取工作，打破数据孤岛现象，充分挖掘并释放数据驱动业务的潜力，已成为业界广泛关注和讨论的焦点议题。针对该问题，业界传统数仓常采用的是经典分层模型的数仓架构，从ODS（Operational Data Store）>DWD（Data Warehouse Detail）>DWS（Data Warehouse Summary）>ADS（Application Data Store）逐层建模，但我们会发现，从传统固化开发的角度来看，传统经典数仓模型是比较有优势的。然而，面对当下数据需求灵活多变的时代，其局限性也日益凸显。如下图

1.2 搜索场景下的困境与挑战

搜索作为百度的核心支柱业务，涵盖通用搜索、智能搜索、阿拉丁与垂类等多元化、多模态的搜索产品，具有快速迭代、模块多元化且复杂的特性，搜索数据更是复杂多样，整体数仓规模达到数百PB以上。

随着搜索业务各个模块之间的联系日益紧密，交叉分析的需求也在不断增长。使用人员对数据获取的便捷性提出了更高的要求，其中涵盖了数据分析师、策略、业务产品经理、运营、评估等多类角色。他们的诉求期望能够跨越复杂的数据架构壁垒，以更加高效、直观、快速的方式获取到所需数据。

而传统的搜索数仓建设体系 无论从建模角度还是技术框架上，都与现阶段用户诉求背道而驰。

1. 建模角度：多层的传统分层建模。往往会出现（大表数据量大、查询慢、存储冗余、口径不统一）等问题，影响业务分析效率，从而达不到数据驱动业务的效果。数据开发侧作为需求的被动承接方，根据业务侧提出的数据需求进行数据开发与交付，存在需求交付周期长、人力成本高等问题。

2. 技术框架角度：搜索数仓过去大多是采用UPI框架（以C++ MR计算框架为主）进行ETL处理。由于该框架技术陈旧，往往会出现以下问题影响数仓整体时效、稳定。从而使业务部门感知需求支持迟缓、数据产出延迟及数据质量低等一系列问题。

• 容易出现服务不稳定。

• 处理能力薄弱：处理不了特殊字符，从而导致数据丢失或任务失败等。

• 只能通过物理机远程执行的方式提交，有单节点风险。

• 无法Writer将数据写到Parquet文件，需要进行特定脚本ETLServer框架进行转换。

思考：如何更好的满足用户角色需求，进一步降低数据获取的使用门槛？

破局：拥抱变化，以用户诉求为核心出发点。 探索更适合用户的 体系化建模 来进行实质、有效的数据管理。

**体系化建模：**以业务产品需求驱动模型设计，以模型设计驱动和约束开发实施，防止因模型设计与业务产品割裂、开发实施缺少约束带来的无序、“烟囱式”开发。在机制上形成模型设计与开发实施的有效协同。

切入点：以规范“基础数据建设”，消除因“烟囱式”开发给业务带来的困扰和技术上的浪费。

由此我们探索出一套新的建模体系：大宽表+数据集：其核心点就是基于宽表 将之前的"需求-交付"解耦为以数据集为中心的建设，从而提升搜索内业务数据分析效率与分析深度，更好助力业务决策。以下将从宽表建模、计算引擎架构优化、新型业务交付模式等方向为大家介绍搜索数据团队业务实践。

02 搜索建模思路与技术方案

2.1 建模模型

2.1.1 思路

基于搜索产品功能特性与差异化业务场景，我们对日志数据进行主题化的分类。在每个主题域内，结合业务运营的具体环节特征，构建具备高整合度的宽表模型。在模型构建过程中，保持 ODS（操作数据存储）层与 DWD（明细数据层）的表结构粒度一致，确保数据的一致性与连贯性。所构建的宽表不仅完整涵盖下游业务所需的全部字段，包括业务明细表中的基础数据，还整合了各层级的维度属性与计算指标。通过这种方式，形成一个全面、统一的数据底座，为上层业务的多维分析、指标监控及决策支持提供坚实的数据支撑，有效满足多样化的业务分析需求。

2.1.1.1 举例

以展点主题为例，从历史的模型表粒度和模型层级来分析：ODS与DWD、DWS表行为、检索、点击各个主题在同层模型或者跨模型之间都存在字段、口径的冗余，如下图

2.1.1.2 思路分析过程

核心思想过程：展点主题下明确粒度，丰富维度&指标 建设宽表模型。

将展点主题下各层之间的事实表复杂嵌套字段打平后与各个维度表、指标等进行join生成宽表，宽表的列最终分为公共属性、展点行为属性、业务属性和指标属性。

消除：

• 数仓层间：字段存储冗余问题

• 数仓层内：口径不一致问题

2.1.2 建模核心思想

基于思路分析过程，总结出一套核心建模理论，核心思想如下图

构建搜索系统性数据建模：根据产品功能和业务不同，按照不同主题构建宽表。从而达到节约存储、精简表数量、口径更清晰的目标。

2.1.3 整体模型架构

基于核心建模思想理论得到整体的模型架构，如下图

• 采用Parquet列式存储，可支持宽表数百、千列，超多字段，再经过按列的高效压缩（bucket sort后，压缩率更高），降低了数仓整体存储空间，提高了IO效率，起到了降低上层应用延迟的效果。

• 将各层之间的表复杂嵌套字段打平后与各个维度表、指标等进行join生成百列宽表，宽表的列最终分为公共属性、业务维度属性和指标属性，便于业务分析，实现快速迭代。

2.2 计算引擎

为了保证数据生产稳定、准确性。我们对计算引擎的选择做了升级，采用传统Spark结合数仓融合计算引擎对搜索数仓ETL进行重构。

2.2.1 从架构&处理流程上

• C++ MR ：多进程，每个任务独立运行，必须经过Map-Shuffle-Reduce，然后中间结果写磁盘。

• Spark ：多线程，任务在Executor内以线程执行。基于DAG，可以在内存中缓存数据，减少IO。

Spark 框架 相较于 MR框架优势在于

• 基于内存计算，处理速度快。

• 支持多种计算模式，功能丰富，适合迭代处理数据。

• 提供了高级的 API，开发效率高。

• 基于平台提交，有效避免单节点计算风险。

且在有shuffle情况下计算表现更好（MR在Shuffle时默认进行排序，spark对shuffle有优化，只有在部分场景才需要排序），在具体业务实践中：同耗时的情况下，Spark计算资源相较于MR节省20%左右。

2.2.2 ETLServer到数仓融合引擎转变

各主题宽表模型的计算通过数仓融合计算引擎（通过Spark Application Context常驻方式做到资源有效复用；省去了启动Driver的时间实现任务的快速启动，来提升任务执行时间）可直接Writer将数据写到Parquet文件，文件无需进行多次脚本server转换。

在具体业务实践中 各主题计算耗时由之前40min 缩短至 10min（减少了30min），实现数仓快速产出。

2.3 新数据模型及架构下的挑战与解决方案

任何数仓模型架构不会存在一个绝对完美的、涵盖所有方面的解决方案。宽表设计仅是当前环境数仓模型的最优解，它依然面临着诸多不容忽视的挑战。

2.3.1 挑战1解决方案

1. 列式存储&读取：

宽表采用了Parquet列式存储，以及ZSTD高效压缩算法。结合数仓融合引擎，达到Data Skipping（即读的越少、计算越快）的效果，仅需读取查询涉及的分区及列，减少了磁盘 I/O 和内存传输的数据量来提升查询效率，通过Sql分析服务发现热点复杂字段，主动引导业务建设物化列，命中后查询性能提升80%。

2. 复杂嵌套字段打平：

业务常用核心指标以及高频字段口径下沉宽表。虽然行数变多了，但是避免了explode，get_json_object、array、map等复杂字段获取的耗时操作，查询性能相较于之前提升了2.1倍。

2.3.2 挑战2解决方案

搜索数据升级到了湖仓一体架构，借助Iceberg Merge Into功能，实现高效回溯方式：对表数据进行行级别的更新或删除。相比insert overwrite 操作更加高效，减少了不必要的数据移动和存储浪费。

通过单一原子操作实现了复杂的数据整合需求。相比传统的先删除再插入的方式，Merge Into提供了更好的性能和一致性保证，其原理是通过重写包含需要删除和更新行数据所在的date files。Merge Into可以使用一个查询结果数据来更新目标表的数据，其语法类似join关联方式，根据指定的匹配条件对匹配的行数据进行相应的操作

Merge Into基本语法

回溯原理流程如下图

1. 关联匹配：

• 目标表和源表根据指定key进行join操作。

2. 条件判断：

• 若Key匹配：根据源表操作类型，对目标表中的记录执行相应的操作（更新或删除）。

• 若Key不匹配：执行Insert操作，将源表数据插入目标表。

3. 原子性操作：

• 整个流程是事务性的，确保数据一致性。

以下是特定回溯场景下 hive与iceberg不同方式的回溯耗时对比，可以看的出来用merge into代替insert overwrite进行回溯，回溯更新效率整体可提高54%左右。

2.3.3 挑战3解决方案

2.3.3.1 重排序、高效压缩

开发ATO优化器(通过任务依次执行重排序、压缩等一系列Rules，实现分区优化和数据重分布)，高效率压缩，解决存储成本，存储节约20%。

（1）压缩编码

数仓表字段元信息采集：通过任务对图灵宽表表进行字段元信息采集，分析数据分布情况，获取重排序字段。

具体做法：通过RLE、Delta等缩码方式来提升数据压缩效率；数据重复度越高、连续性越好（有序）的场景，压缩效率会越高，RLE、Delta编码原理如下。

（2） 压缩格式

使用ZSTD压缩格式和更大的压缩level，在不影响查询性能的情况下，更大的压缩level能进一步提高压缩率，level=9时在压缩效率和耗时上最为平衡，读写耗时和压缩率对比效果如下。

（3） Page Size

针对Parquet文件格式特性进行深入挖掘 ，对Parquet page size进行分页扩容，将Page Size从1MB增大至5MB，让更多相似的数据集中到同一个数据页中，充分利用编码的压缩特性，进一步减少各个数据页之间存在的相似数据。在ZSTD的基础上，能进一步提升压缩效果，效果如下

2.3.3.2 历史裁剪，管理有效字段

开发了一套半自动化的通用裁剪模式，通过采集日常任务代码，sql parser模块解析出无用字段信息（尤其是大json 大map类型扩展字段的无用字段）自动化实现了裁剪。减少了 50% 的回溯任务计算资源消耗，将人力投入从5人/天降低到0.5人/天。

• 字段频率统计模块：通过对函谷 SQL 数据库和 TDS 平台 No SQL 任务的物理执行计划进行解析，实现对宽表 SQL 任务和非 SQL 任务的字段访问频率的自动化统计。

• 裁剪字段抽取模块：基于字段访问频率，每月抽取冷温字段，形成可视化的字段访问频率报表，生成裁剪 SQL。

• **冷温字段告警模块：**通过对比前一个月和本月冷温字段列表，生成当月新增冷温字段列表，然后向产品研发团队和数据RD团队发出告警，确认需要动态调整的裁剪字段；引入冷温字段告警模块，成功实现了裁剪字段的动态调整。最后，通过滚动裁剪模块自动裁剪395天前的数据，进一步降低人力/资源的消耗。

• 滚动裁剪模块：自动化滚动裁剪，裁剪宽表中395天前的数据。

基于业务实践证明：宽表数仓模型与数仓融合计算引擎的结合 比传统数仓模型 更适合 面向服务于快速迭代的驱动型业务，主要体现在

1. 查询性能巨大提升带来快速响应支持业务需求：

简单查询场景 ：Adhoc查询场景，耗时在数十秒级别，相比于普通Spark性能提升5倍。

复杂场景：业务常用复杂字段拆分打平，避免数组、map等复杂字段耗时操作、查询性能提升2.1倍。

2.口径封装下沉：封装业务核心口径，解决业务长期数据源多、口径不一致带来的数据准确性问题，省去不必要的沟通，使用更加简便。

3.减少冗余存储：相较于经典传统数仓同主题模型下存储降低30%左右。

03 基于建模与技术框架初步整合 探讨图灵3.0生态新一代业务服务交付模式

随着搜索数仓模型&计算引擎架构的重构和技术栈统一，搜索数仓定义逐步清晰化、数仓个数大幅度降低，整体趋向更加紧凑、高效以及收敛的态势。在此基础上，为了助力数据迭代效率和分析效率进一步提升，在业务线基础数仓及应用层数据建设上，百度MEG内部开发了图灵3.0生态系统（即 数仓合理建设，数据分析需求尽可能收敛到TDA平台，配套数据集建设完善），包括Turing Data Engine(TDE)计算引擎、Turing Data Studio(TDS)数据开发治理平台和Turing Data Analysis(TDA)可视化BI产品。依托图灵3.0生态，我们进而形成了一套新的开发范式—— 图灵3.0新开发模式，用来提升搜索内业务数据分析效率与分析深度，如下图（阶段三）所示

3.1 阶段一到阶段二

如之前所述：由于搜索数仓早期查询性能不理想，为了提升业务分析效率建设了大量的业务表。从而导致数据冗余、数据链路稳定性差、效率低、指标口径不一致等一系列问题。搜索数据团队通过数仓模型（将多层数据模型控制在1-2层）以及计算引擎架构升级重构、湖仓一体、高效压缩、裁剪等一系列措施解决了这些问题。数据建设更加完善规范化，搜索数仓表的数量由过去的数百张减少至20张左右，时效性大幅提升，全数据链路全流程提速4H+，数据稳定性及运维成本降低30%。

3.2 阶段二到阶段三

随着图灵3.0生态系统（包括TDA、TDS、TDE）及搜索数仓模型的日益完善，内部提出了 以数据集为核心来构建数据应用层，将数据开发侧与业务侧的依赖关系从之前的"需求-交付"解耦为以数据集为中心的建设，实现数据集<->可视化分析<->仪表盘的数据分析闭环，解决业务常用维度、指标长周期的查询分析需求 ——> 图灵3.0新开发模式。

图灵3.0新开发模式核心思想在于数据集的建设，我们将不再仅仅只是根据业务需求来定制开发数据报表，而是构建一个灵活、可扩展的数据集。使业务侧能够自主地根据需求从中提取、分析和可视化数据，以满足不断变化的业务需求。

那么，在数据集建模实践中，如何才能合理构建一个灵活、可扩展且高质量的数据集？是数据研发对数据集建模关键核心，也是最大的挑战。

3.2.1 数据集建模合理度挑战

1. 为了满足业务需求的多样性与广泛性，并支持更多的维度和指标。我们往往会倾向于在单个数据集中不断叠加新的维度和指标，这种做法虽然表面上看起来方便快捷，但实际上却导致了数据集行数的急剧增加，进而对聚合查询的性能造成了不利影响

2. 为了确保查询的高效性，同时兼顾更多维度与指标的业务需求。我们往往的做法 就是建立更多的数据集，以空间换时间去满足查询性能。

显然，这些做法之间存在着明显的矛盾，具体如下图。

3.2.2 解决方案

为了更好地找到平衡点，搜索数据团队采取了以下解决措施：

1. 明确边界：分主题建设对应数据集，单主题内 数据集尽量做到合并统一，以达到更高的集成度与一致性。

2. 明确粒度：从业务场景需求出发，单主题内数据集建设前明确数据集最小粒度 ，确保数据最小粒度既能满足主题分析的精度要求，又避免因过度细化或粗放导致的分析效能损耗，为后续数据集的结构化构建与高效奠定基础。

3. 深度性能优化：充分利用了TDE-ClickHouse强大基础引擎，例如在处理高基数去重计数字段时 创新性地采用NoMerge技术来替代传统的COUNT(DISTINCT)方法，降低了聚合层的计算负担，实现了查询性能5至10倍的提升，极大地优化了数据处理速度。

3.3 新模式带来的改变

△ 图灵3.0的数据开发新模式

1. 强化主动能力，业务自助效率显著提升：相较于以往被动式的一对一需求定制化开发模式，数据研发工作已从单纯响应被动需求转变为主动规划构建数据集。图灵3.0新开发模式下，实现数据集<->可视化分析<->仪表盘的数据分析闭环（满足 90%查询；其余10%长尾交给Adhoc查询），业务人员对日常通用需求的分析工作转移到数据集自助查询与分析上（根据数据集自助创建可视化数据报表）。可视化分析占比、业务自助率提高至90%，数据研发日常需求量减少80%。

2. 非核心常用维度指标查询性能显著提升：非核心常用维度指标由以往业务提需 查表或单独建设报表来获取数据的方式 转变为通过数据集自助下钻、拖拉拽自由组合常用维度指标，实现可视化分析的方式。借助TDE-ClickHouse 强大基础引擎能力：可视化分析效率大幅提升，从小时、分钟级的数据分析效率 提升至秒级分析。单次查询数据周期由1周内 提升至1年内（秒级完成查询），真正做到即需即查即用。

3. 血缘管理规范化，运维效率显著提升：数据血缘更加完整流程化，数仓-数据集 血缘在TDS完成闭环，数据集内字段血缘在TDA完成闭环，以数据集为纽带串联整个数据流全过程，数据链路运维效率提升2-3倍。

目前，该模式已经广泛应用于搜索各业务数据运营人员早报、周报等多种业务汇报场景。得益于该模式，搜索产品线下仪表盘周均查询（PV）高达1.7W次左右，可视化分析周均0.93W次左右 ，每周超过400多名用户参与TDA搜索数据分析工作。更重要的是，需求的交付周期实现了显著缩短，由以往的单/双周缩短至按天交付；甚至在某些情况下，业务人员能够直接自助获取所需数据。在处理重点项目时，该模式也能确保业务团队在第一时间获取到P0级别的关键数据。这种方式的转变不仅能够减轻数据开发团队的工作负担——人力成本由原先的3人锐减至1人，还能提高业务侧的数据使用效率和自主性，使得团队得以从繁琐的“取数”与“跑数”任务中解放出来，将更多的精力投入到数仓模型的优化、技术框架的探索与治理等更具战略价值的工作中去。

04 总结与展望

数据建模领域正经历从“技术驱动”向“价值驱动”的深刻转型，更加强调的是敏捷性、可解释性和业务对齐。尽管当前的技术工具愈发强大，但成功的关键依旧在于跟业务的紧密协作与一个清晰明确的治理框架。

搜索业务，作为百度内部最核心且最为复杂的板块，涵盖了多个至关重要的产品线。近年来，搜索数据团队始终致力于运用前沿技术来不断优化和完善数仓体系的建设，以坚实的基础数仓架构支撑起数据质量飞跃提升，从而高效赋能业务，带来可量化、可感知的业务成效与用户体验升级。

展望未来，随着AI代理和边缘计算等技术的蓬勃发展，数据建模有望朝着自适应与嵌入式方向进一步进化。搜索数据侧还将在以下关键方向与大家进行深入探讨、交流和学习：

• 通用数据流解决方案：构建事件规则引擎等通用数据流处理工具，简化数据处理流程，提高数据处理效率与灵活性。

• 日志埋点技术（含无埋点）：探索高效的自动化埋点机制，提升数据采集的全面性与准确性，为业务洞察提供坚实的数据基础。

• 宽表模型框架抽象层：探索更为高效、灵活的模型统一抽象方法层。

• AI大模型时代下的高效开发模式：探索如何通过利用大模型技术 来优化代码质量、数据链路等，打造更加高效、可靠的数据开发与运维体系。

我们期待之后再次与大家见面探讨这些议题，共同推动数据领域的创新与发展。

导读

百度MEG上一代大数据产品存在平台分散、易用性差等问题，导致开发效率低下、学习成本高，业务需求响应迟缓。为了解决这些问题，百度MEG内部开发了图灵3.0生态系统，包括Turing Data Engine(TDE)计算&存储引擎、Turing Data Studio(TDS)数据开发治理平台和Turing Data Analysis(TDA)可视化BI产品。依托图灵3.0生态，我们引入了数据湖表格式：Apache Iceberg，利用其特性并在多种业务场景下进行优化实践，解决图灵数仓业务实时数据入湖，数据表历史记录更新效率低等多个痛点问题。

01 背景

1.1 图灵3.0生态概述

由于百度MEG上一代大数据产品存在平台多、易用性差及数据流转繁琐等问题。这些问题导致开发人员研发效率低及多平台间高昂的学习成本；业务部门的感知则是需求交付迟缓、数据产出延迟及数据质量低等问题。为了解决上述问题，我们构建了新一代大数据解决方案——"图灵3.0"，旨在覆盖数据全生命周期，支持全链路数据操作，提供高效敏捷且统一的强大数据生态系统，其中包括数据计算引擎、数据开发和数据分析三个核心部分：

1. TDE（Turing Data Engine）：图灵生态的计算引擎，包含基于Hive、Iceberg进行数据处理的Spark和ClickHouse高性能计算引擎。

2. TDS（Turing Data Studio）：一站式数据开发治理平台。

3. TDA（Turing Data Analysis）：新一代可视化BI产品。

本文主要介绍数据湖表格式Iceberg在图灵3.0生态下的应用与实践。

△图灵3.0生态产品

1.2 问题

MEG数据中台基于Hive构建了离线数据仓库，已支持手百，搜索，商业，贴吧，小说，用增架构，销售等多个业务需求，但随着业务的发展，业务对数据的实时性以及查询性能等有更高要求，当前主要存在以下几个问题：

1. 商业、电商、销售等业务，周期性地更新行业等信息，单次更新数据量占比小、字段少，但是基于Hive的数据更新（以下简称：数据回溯）只能通过全量覆盖写的方式实现，数据回溯周期长、效率低、成本高。

2. 由于Hive在实时数据更新以及事务支持上存在一定局限性，无法有效满足业务构建实时数仓的需求。

3. 在处理大规模数据集上，Hive的查询性能受到如元数据的加载解析以及每次访问数据都需通过分布式文件系统listFile遍历文件列表等问题的影响，导致性能降低。

基于上述问题，我们通过技术调研，最终引入了开源的数据湖表格式Iceberg，构建数据湖存储服务，并借助大数据生态的Spark、Flink等计算引擎来实现数据湖的分析，将其无缝集成到图灵生态中，帮助业务提效降本，构建更快速、更高效、更低成本的数据中台产品。

1.3 Hive和Iceberg对比

Hive作为一个基于Hadoop生态系统的开源数据仓库工具，主要用于对大规模结构化数据进行存储、查询和分析。而Iceberg作为新一代数据湖表格式，提供了类似传统数据库的事务性，保证和数据一致性，并支持复杂的数据操作，如行级更新和删除等，更加适合实时更新，流批一体数据场景，下表列出Hive和Iceberg一些主要特性对比：

特性	Hive	Iceberg
行级更新	不支持	支持merge into、upsert等语法进行行级别更新能力
时效性	小时级别/天级	分钟级
事务	非完整的ACID事务	支持完整的ACID事务，同时使用多快照提供了读写分离的特性
元数据管理方式	基于Mysql进行元数据存储	通过文件组织管理，直接存储数据文件元数据
数据版本控制	无	支持时间旅⾏(Time travel)特性，可基于快照进行历史数据版本管理和访问

1.4 Iceberg的组织结构

Iceberg文件组织分为元数据层和数据层，主要包含version-hint，metadata file、snapshot file、manifest file和data file文件类型，具体如下：

• metadata元数据层

a. version-hint：该文件作为元数据索引初始文件，记录了Iceberg表的版本号，通过版本号找到对应的metadata file。

b. metadata file：记录了Iceberg表的schemas、properties以及快照等信息。

c. snapshot file（manifest-list）：每次数据 commit 会生成一个新的快照，保存了该快照下每个manifest file路径及对应的分区范围。

d. manifest file：记录数据文件元信息，包含每个数据文件的路径、文件的大小等一系列统计信息（如文件每列的最大最小值、空值数等），实现元数据和数据文件的关联。

• data数据层

data file：实际的数据文件，以 parquet 等列存格式存储数据。

△Iceberg表结构

△Iceberg文件组织结构

通过上述Iceberg元数据文件组织结构，Iceberg实现了文件级的元信息统计及版本化管理。

02 Iceberg能力建设与应用

2.1 图灵生态能力适配

2.1.1 统一元数据服务

由于原生iceberg缺少元数据的可视化管理能力，我们通过构建统一的元数据微服务，将Iceberg表和Hive表元数据进行管理，对应用层提供相关表和分区的增删改查等接口，统一数据存储的元数据操作入口。

该微服务主要包含常驻SparkSession模块，EngineMetaService模块和元数据模块，通过将SparkSession常驻，为用户提供Iceberg表和Hive表元数据和分区数据的增删改查功能，以及可视化的元数据管理界面。

△统一元数据服务架构

2.1.2 打通Iceberg和Hive联邦查询

为了兼容历史业务存量Hive表，同时降低用户使用Iceberg的成本。我们在计算引擎层面打通Iceberg和Hive联邦查询能力，并保证了Iceberg表与原有方式语法一致。

通常在一条SQL执行过程中，主要可简化以下Parse、Analyzer、Optimizer、CBO四个流程。通过在Analyzer和Plan阶段进行改进优化，来打通Iceberg和Hive表联邦查询。

• Analyzer阶段：该阶段主要是将spark未解析的逻辑计划进行解析，我们通过对SparkSessionCatalog加载方式改造，优先加载iceberg表使用的catalog类型，如果用户SQL使用的是Iceberg表，则对应会使用IcebergCatalog和iceberg数据源访问，否则使用SessionCatalog与Hive数据源访问。

• Optimizer阶段：为加强数据安全管理，我们进一步打通Iceberg表鉴权能力，在基于逻辑计划生成物理计划阶段，解析注入表、字段信息以及表操作类型规则，并与公司内数管平台交互，实现对Iceberg表和字段的鉴权

△Iceberg和Hive联邦查询适配流程

2.2 存量Hive低成本迁移Iceberg

现有数仓业务数据主要存储于Hive表，为支持业务快速切换Iceberg应用新技术，我们建设了存量Hive表低成本迁移至Iceberg表的能力。

以下是在实践过程中的两种迁移方案对比：

方式1：使用Iceberg功能migrate进行原地迁移，通过社区提供的CALL migrate语法，直接执行如下示例的SQL语句，即可将Hive表升级为Iceberg表。

CALL catalog_name.system.migrate('db.sample', map('foo', 'bar'));

该方案操作简单且可回滚，但这种方式在图灵生态落地过程中也存在一些问题：

该方式会基于原Hive表的数据信息构建Iceberg元数据信息，并将原Hive表名重命名为sample_backup_，同时数据路径也进行重命名。

• 下游无法读：在执行迁移过程中，原Hive表对应的路径已经被重命名，进而导致下游业务无法正常读取正在迁移中的表。

• 多表挂载冲突：在业务的使用场景中，存在同一份物理数据被多个Hive表挂载可能，直接修改路径会导致其他表失效。

方式2：基于上述问题，我们进一步对现有方案进行优化，不改变Hive表原有的数据路径，来实现Hive低成本迁移Iceberg，具体流程如下：

• 构建Iceberg元数据：直接复用Hive的分区数据，新建同名的Iceberg表，并重建Iceberg元数据，最终新Iceberg表的元数据信息实际指向是Hive分区数据存储位置。

• 数据校验：当Iceberg元数据构建完成后，查询Iceberg表中字段数据，和迁移之前Hive表字段数据，进行一致性校验，验证迁移是否符合预期。

• 读写切换：数据校验完成后，我们只需要将对应表的属性更新为Iceberg。因为我们已经打通了Iceberg和Hive的查询，且迁移后表名未变，业务可正常使用原有表名及语法进行查询和写入，降低迁移成本。

△Hive迁移Iceberg整体实现流程

2.3 Iceberg在图灵的应用和性能优化

2.3.1 图灵实时数仓应用

在图灵数仓大部分场景中，用户主要依托天级或小时级运行的离线Spark任务来完成数据入仓。在这种模式下，难以满足部分对数据实时性要求较高的需求。

为解决该问题，我们基于Iceberg+Flink构建的图灵实时湖仓架构，整体重构流程如下图所示。该架构模式实现了数据分钟级别实时入仓，显著提升了数据入仓的时效性。进一步扩展了整个图灵的应用场景。

• 针对数据分析和case排查等场景，业务可基于图灵常驻计算引擎进行实时查询，快速获取所需要的数据支持业务分析决策；

• 针对策略迭代、特征生产以及机器学习等复杂计算场景，可基于spark例行任务进行加工生产；

• 针对策略数据调研分析、科学计算等复杂场景通过数据交互计算引擎Jupyter进行数据计算。通过构建图灵实时湖仓架构，既保证了数据分析的时效性又兼顾了复杂计算任务的处理能力，有效提升了业务的数据处理效率和分析决策能力。

△图灵实时湖仓架构演变

2.3.2 行级更新策略

在图灵数仓业务场景下，商业、搜索、电商、销售等业务，周期性地更新行业等信息。而Hive在该场景下支持相对较弱，需通过全量覆盖写方式刷新数据，这种方式在大数据量场景下，回溯数据周期长，消耗资源大，所需要的人力时间成本也高。我们通过利用Iceberg行级更新的特性，基于update、merge into等方式回溯进行字段变更，能够很大程度的提高回溯效率，降低资源和人力成本。

针对数据行级更新，Iceberg提供了两种策略，分别为COW(Copy on Write： 写时复制) 或 MOR (Merge on Read：读时合并)，其中MOR根据其标记删除文件的区别又细分了两种方式（Equality Delete File和Position Delete File）。

更新策略	更新后的读取效率	更新时写入效率	适用场景	备注
COW	最快	最慢	读多写少场景
MOR 标记条件删除（Equality Delete File）	较快	最快	写入多、读取少场景	读开销：每次读取数据需要额外读取标记删除列数据进行比较。 写开销：只需要存储标记过滤数据的条件，写入成本极低。
MOR 标记位置删除（Position Delete File）	快（依赖更新数据量）	较快	少量数据更新、读取少场景	读开销：加载每个文件需过滤的数据行号。（删除行过多，影响性能） 写开销：需要扫描一遍原数据，找出待删除数据的行号。

关于COW和MOR更新策略的文件表现形式如下图所示，我们针对不同场景采用不同更新策略：

• 对于日常数据查询分析场景，小时级&天级离线例行生成加工场景，由于查询次数会远多于数据更新次数，可默认采用COW策略；

• 针对一些业务更新少量字段进行长周期回溯场景，以及实时场景，写入频繁，通过使用MOR策略，来支持用户进行数据回溯变更字段信息，以提升数据更新效率并节省资源。

△COW和MOR两种更新策略对比

△MOR两种删除文件类型&更新字段示例

在业务进行数据回溯应用过程中，我们采用MOR(Position Delete File)进行行级数据更新，通过原Hive回溯和新Iceberg回溯两种方式对比，在一天24小时不同分区上，验证了Hive和Iceberg新旧的回溯效率，如下图所示，业务回溯效率整体可平均提升50%+；进一步地对比单次回溯一年数据消耗的计算资源量对比，平均整体降低70%+的计算资源消耗，整体上极大提升回溯效率，并降低资源成本。

△ Hive 和 Iceberg 回溯效率对比

2.3.3 Iceberg表生命周期管理和性能优化

在Iceberg应用实践的过程中，针对不同业务场景遇到的问题，我们汇总如下：

• 小文件过多：在实时湖仓业务场景，为了要保证数据的时效性，通常是分钟级别的commit操作，在这种场景下，单个作业执行一天，则需要1440 个 commit，如果执行时间更长，则会产生更多的commit，随着时间的累积，元数据以及数据文件等都会产生大量的小文件，对于整体查询的性能会产生一定的影响。

• 存储资源增加：如果iceberg表的快照不及时进行清理，可能会造成数据存储增加，导致存储账号资源紧张。

• 缺乏分区数据统一管理：在一些业务场景，只需要保存一定天数的分区数据，针对无用数据需要进行删除处理。

• 数据文件组织不均衡且无序：由于表数据写入是随机无序，且针对表数据文件大小会存在不均衡的情况。

针对上述问题，我们通过对Iceberg表进行全生命周期管理，并结合Iceberg特性优化表查询性能，保障整个数据链路的稳定性，整体框架如下图所示：

△Iceberg表生命周期管理和性能优化流程

以上流程主要包含表数据生命周期管理和表性能优化两部分。

一方面，对于表数据生命周期管理，我们通过在线服务执行定时任务，来实现对表数据和元数据进行全生命周期监控，具体如下：

• 数据分区过期：基于用户配置的表生命周期，进行分区数据删除，保证数据文件按期清理。

• 元数据快照清理：为用户提供按照时间维度天级别和按照个数维度小时级别两种快照过期策略，精细化元数据快照过期处理，实现存储资源的高效利用。

• 元数据孤儿文件清理：通过天级例行任务来触发清理由于计算引擎执行任务失败等情况产生的一些没有被引用的孤儿文件，避免元数据累积影响性能。

另一方面，在表性能优化方面，我们结合图灵数仓表使用情况，并基于Iceberg原生特性，为用户在平台侧提供Iceberg表优化算子（如下图示例），主要包含以下两种能力：

• 小文件合并：通过制定合并文件大小，对表数据文件进行重写合并，避免产生大量小文件。

• z-order排序优化：实现对表相关字段进行重排序，提升查询性能。

△Iceberg表优化算子任务创建示例

我们通过对Iceberg表整体的生命周期管理，实现了数据和元数据的统一治理，表元数据小文件数万个降低到数百级别，合理控制了元数据产生的数量，并解决了数据频繁回溯场景下存储快速增加的问题。而在表查询优化方面，通过在一些表的数据重分布和字段重排序应用，在部分业务表查询性能提速50%。

03 未来规划

Iceberg作为图灵3.0生态中的重要组成部分，基于其高时效性、行级更新能力、小文件合并以及Z-order等成体系的数据优化的技术解决方案，为MEG数据中台业务提供构建湖仓一体，解决数据回溯等痛点问题的能力。目前Iceberg的应用已覆盖搜索，商业，销售，用增架构等多个业务线，通过低成本助力业务将存量Hive迁移Iceberg表，为业务提供高性能数据查询，同时实现对业务的降本增效。此外，我们也在不断完善Iceberg数据存储引擎的各项能力，包含表数据智能治理、查询优化、智能索引以及特定场景的性能问题等，并不断扩大Iceberg的业务覆盖范围。

6月23日，百度 AI 开放日举行，百度智能代码助手文心快码迎来重大突破。百度副总裁陈洋现场发布了文心快码独立 AI 原生开发环境工具——Comate AI IDE，是行业首个多模态、多智能体协同的 AI IDE，首创设计稿一键转代码，开箱即用，为国内企业和开发者打造高效、智能、安全可靠的 AI IDE。目前，百度每天新增的代码中，文心快码生成的代码占比已超过43%。

百度副总裁陈洋表示：“六十年前，程序员用穿孔卡片写下第一个‘Hello World’，文心快码 AI IDE 让这句问候有了新的回响：Hello World，Hello Life。提升编程效率的同时，降低了使用门槛，不论是视障开发者还是小学生群体，文心快码在帮助每个有梦想的人构建他们的世界。”

IDC 报告显示，AI Coding 市场在2025年迎来应用爆发期，不少用户认为自研独立 IDE 代表着下一代、更先进的智能代码助手。自研 AI 原生开发环境，而非仅作为插件附着于 VS Code、JetBrains 等既有平台，能够在编辑器的界面与底层逻辑、重构整个开发工作流，乃至开发者生态层面具备更大主动性。

文心快码推出的 Comate AI IDE，在“智能”、“拓展”、“协同”、“灵感”四大方面实现全方位链接，具备多项核心能力：AI 辅助编码全流程、多智能体协同、多模态能力增强、支持 MCP 等，已成为 AI 时代工程师的“工作台”。百度文心快码高级经理彭云鹏进行了详细介绍。

在 Comate AI IDE 中使用编程智能体 Zulu，可体验多智能体功能完成复杂任务，具备自主思考和决策能力，支持自动拆解任务计划、自主决策下一步执行内容、实时展示思考过程。开发者只需要动动嘴，就可以搞定需求。目前 Zulu 也宣布升级，在专精场景、行为能力、组合模式维度更专业。

多模态能力也是这次 Comate AI IDE 的亮点之一，尤其在前端场景做了场景化增强。如设计稿转代码（F2C）、图片转代码、自然语言转代码，生成高还原度的代码，同时生成代码可预览，预览后选定元素用自然语言进行页面调整，像真正的“前端工程师”一样开发代码。其中，F2C 即 Figma To Code，Figma 设计稿一键转换为高可用代码，高还原、好维护、超便捷，让设计师的每个图层都精准转化为可运行代码，节省了80%重复劳动。

Comate AI IDE 还内置了十余种开发工具，如文件检索、代码分析、代码编辑等，同时支持 MCP 对接外部工具和数据，适配各种开发场景。此外，Comate AI IDE 迁移使用方便，支持快速迁移原 IDE 配置，AI 辅助编程覆盖从分析需求、编写代码、运行与测试到提交代码的全流程。

对比 Cursor，Comate AI IDE 在 F2C、代码效果实时预览、主动追问完善需求、智能化页面调试等方面优势显著，尤其针对中文开发者优化了自然语言理解能力，更贴合国内研发场景。

现场，算法工程师张欣欣分享了文心快码的使用心得。在中文理解能力的加持下，张欣欣放弃了国际编程工具 Cursor 转向文心快码。借助文心快码智能体 Zulu，她仅用两周时间，就开发了一款医疗辅助诊疗系统，实现了从一个算法工程师向全栈工程师的进阶。在北京市海淀区，三位热爱编程的小学生，利用文心快码完成了自己的编程命题，并搭建了少儿编程开源社区，让身边的小朋友们提交代码、分享经验、讨论问题，解决问题。

会上，文心快码同时宣布“Comate Next 计划”正式启动，向全球开发者与企业开放深度共建通道，加速 AI 驱动的人机协同研发范式落地。该计划提供了全新进化的云端工作台，帮助开发者告别本地配置与协作的困境，首创“多智能体协同系统”，支持开发者自定义智能体或直接下达任务。同时面向企业提供专家1v1交流等深度共建权益。

从技术突破到生态构建，从职业场景到全民普惠，文心快码正以中国自主创新的姿态，重新定义智能编程的未来。让每一个有梦想的人，都能构建属于自己的世界。

日志中台是百度内部针对打点数据的全生命周期管理平台，作为公司日志数据的唯一入口，承担以下核心职能：1.功能覆盖：提供从数据采集、传输、存储到查询分析的一站式服务，支持产品运营分析、研发性能监控、运维管理等多元场景。2.业务赋能：通过标准化流程实现用户行为日志的埋点申请、审批及退场管理，助力APP端、服务端等业务线挖掘数据价值。3.生态协同：与大数据平台、推荐中台、性能平台深度联动，避免重复建设，提升资源利用率，强化业务中台能力。

01 项目背景

2020年初启动的日志中台前端项目，随着业务发展逐渐暴露出严重问题。整个前端项目技术负债多，有500多个文件，共11万多行源码。项目已经变得老旧而臃肿。面临线上bug频发、排查问题效率低下等各种问题，陈旧的技术栈与低效的流程也制约了团队的生产力。因此需进行全面全面重构，通过基于业务导向的架构优化、开发测试流程规范化，从而提升前端开发效率，使项目具备长期稳健发展的技术基础。本文将重点介绍我在重构项目过程中的一些实践经验。

02 前端项目面临的问题

先介绍下日志中台前端项目的基本情况

• 核心框架：Vue 2.6 + Vuex 3.1.1 + VueRouter 3.0.6

• UI组件库：ElementUI 2.15.13

• 构建工具：@vue/cli-service 3.11.0（基于Webpack 4）

• 部署平台：测试环境（FIS3）、生产环境（Tower）

下面我将从4个维度来分析下前端项目所面临的各种问题。

2.1 代码质量

由于项目没有接入代码格式化 prettier 和 代码规范检查 eslint，导致项目的代码质量堪忧，各种各样的代码风格并存。在开发需求过程中，各自的编码风格不一致，维护时需额外适应时间，甚至由此引发线上问题。

2.2 基础建设

1. 代码臃肿，维护困难

• 全项目500+源文件中，30+文件超1000行，5+文件超2000行，最大文件达5000行。

• 巨型文件导致：

  IDE卡顿（Mac开发时频繁卡住）。

  热更新失效（>2s延迟，大文件需手动刷新浏览器）。

2. 技术栈陈旧

• 仍使用已停止维护的vue-cli（Webpack 4时代工具链），与现代构建工具（Vite、Webpack 5）存在代差。

2.3 构建和部署

测试环境

测试环境的部署采用的是 fis3，这是百度FE团队早期自研的集构建、部署于一身前端构建工具，日志中台项目使用其部署测试环境的功能。具体流程就是在开发者本地执行打包操作，然后将打包产物通过fix3推送到后端的服务器上去，替换掉之前的打包产物，从而实现部署新版本。

• 这种方式存在诸多问题：

• 本地构建依赖不一致，易引发环境差异问题。

• 无CDN缓存，静态资源直推后端服务器。

• 无版本管理，存在代码覆盖风险。

• FIS3已停止维护，社区无支持。

• 本质问题：前后端未完全分离，违背当前主流协作模式。

生产环境

生产环境的部署则采用的是Tower平台，这是百度内部的线上部署平台，通过平台的形式将master分支的代码在服务器上编译构建，将打包后的产物推送到线上环境对应的服务器上，从而实现完整的上线流程。这种上线方式同样存在诸多不足：

• 上线耗时长达30分钟，无增量构建能力。

• 多服务器部署时存在“漂移现象”（请求路由不一致）。

• 操作流程复杂，平台限制多（如回滚困难）。

• 仍缺失CDN加速，影响页面加载性能。

2.4 优质组件

在Vue技术栈中，模块和组件的模糊概念，导致很多开发者无法区分其区别。

1. 组件与模块概念混淆

• src/components目录下堆积40+文件夹，但90%为一次性业务模块（如5个重复封装的Table组件），缺乏真正的复用价值。

2. 基础建设缺失

• 无通用业务组件库，开发依赖Element UI原始组件。

• 高频逻辑（如表单校验、数据请求）需重复实现，通过“复制粘贴”开发，导致代码冗余和一致性风险。

03 全面重构拆分

下面是针对以上项目中的各个痛点的重构具体手段。

3.1 接入工程化

前端项目若缺乏统一的代码规范和质量控制，随着业务增长，代码可维护性会急剧下降，最终导致开发效率低下、线上问题频发。因此，引入业界成熟的工程化方案是提升代码质量的关键。

工程化改造步骤

1. 清理冗余配置

• 移除项目中无用的、过时的配置（如废弃的.babelrc、冗余的webpack配置等），减少干扰项。

2. 统一基础配置文件

• 在项目根目录下添加必要的配置文件，确保团队开发环境一致：

• .vscode/settings.json（统一VSCode编辑器配置）

• .editorconfig（统一缩进、换行等基础格式）

• .npmrc（设置为百度npm镜像）

• .browserslistrc（明确目标浏览器兼容范围）

3. 接入代码规范工具

• Prettier：自动格式化代码，统一风格（如缩进、引号、分号等）。

• ESLint：检查JavaScript/Vue代码质量，避免常见错误。

• Stylelint（可选）：规范CSS/Less代码风格。

4. 优化开发体验

• 推荐安装必要的VSCode插件（如ESLint、Prettier、Volar等），提升开发效率。

5. 提交时增量强制校验（Git Hooks）

• 接入husky+lint-staged，在git commit时自动执行代码检查，阻止不合规代码提交。

配置参考：

• VSCode统一配置

  www.yuque.com/shuoshubao/…

• 工程化配置方案www.yuque.com/shuoshubao/…

历史代码修复策略

原则：“自动修复优先，手动修复补充”，避免无限制添加eslint-disable或ignore规则，导致规范形同虚设。

具体执行步骤：

1. 自动格式化（Prettier）

2. ESLint自动修复

3. 分析剩余问题

• 使用eslint-formatter-html生成报告，评估剩余问题。

• 调整ESLint规则（如放宽部分历史代码限制），拆解为多个小任务手动修复。

4. 回归测试

• 联合熟悉业务的同学进行全量测试，确保修复过程不影响系统功能。

效果验证

• 代码风格统一：所有新提交的代码均符合规范，减少风格争议。

• 错误率下降：低级语法错误、边界条件导致的JS报错大幅减少。

• 开发体验提升：IDE卡顿减少（格式化后代码更简洁），热更新效率提高。

3.2 升级基建

3.2.1 源码优化与依赖治理

问题现状：

项目存在大量技术债务，包括：

• 冗余资源（未压缩图片约2M）

• 无效依赖（22个未使用的npm包）

• 混合模块规范（require/import混用）

• 废弃技术栈（如已停止维护的iView）

优化措施：

1. 资源优化

• 使用基于Tinypng封装的工具批量压缩图片，体积减少65%

• 清理已下架页面的遗留代码（约15个路由）

2. 依赖治理

• 移除22个无用依赖

• 统一使用ES Module规范（手动替换require为import）

3. 技术栈升级

• 替换老旧组件库：vue-json-diff、vue-code-diff、vue-codemirror 替换为 monaco-editor

3.2.2 构建相关

相对于以往的 Webpack 或者 Vue CLI，存在开发服务器启动慢（平均45秒）、热更新延迟高（2.5秒）、构建流程复杂（需Babel转译ES5）。

Vite 配置详见：www.yuque.com/shuoshubao/…

接入Vite后，低配置电脑同学开发时的平均热更新时间由2.5秒缩短到100毫秒。在单个需求完成耗时方面，由之前的4.2人天缩减到3.4人天，综合人效提高19%。

另一方面，由于 Vue CLI 是基于babel将esnext代码转成es5，而Vite基于esbuild不需要进行降级编译。在将 Vite 的配置 build.target 设置为 ['chrome100'] 后，甚至连非常新的esnext语法糖都不需要转换，浏览器直接可以使用前端的源码，极大的利用了esnext带来的开发便利，而不需要关注Babel的版本以及各种依赖包和复杂的配置。

3.2.3 部署相关

百度内部主流的部署平台是 Fcnap。这是一个类似Vercel的前端一站式部署平台，基于git分支，只要检测到分支变动，就会触发自动构建和部署。

只需配置好各个测试环境以及生产环境的基本信息，后续在需要开发中，只需要将分支和测试环境关联起来，就可以达到随时提交代码随时部署的效果；上线过程更是丝滑，只需要将代码合到master分支，就会自动上线。

将 fis3 以及 Tower 迁移到 Fcnap 后有如下优势：

• 测试和生成环境使用一套部署逻辑

• 上线部署耗时由30分钟缩减至2分钟

• 提供cdn功能，每次上线后增量更新的静态资源只有500kb

• 上线期间访问系统不会出现白屏现象

• 上线过程对用户无任何影响

3.2.4 接口调试

传统开发模式的痛点

在传统前后端协作中，存在典型的"接口依赖症"：

1. 开发阻塞：前端必须等待后端接口Ready才能开始调试

2. 效率低下：联调阶段频繁出现接口变更，导致重复返工

3. 数据不可控：依赖真实测试环境数据，难以覆盖边界场景

数据表明：在接口未就绪阶段，前端开发效率会下降60%以上

真正的"前后端分离"实践

核心原则：开发阶段解耦，联调阶段对接

1. 规范先行：

• 后端通过YAPI等平台提供完整的接口文档

• 包含：请求方法、参数结构、响应体示例、状态码定义

2. Mock数据要求：

• 真实业务数据（非简单根据接口文档生成各种随机数据）

• 可自定义异常场景（404， 502等真实场景还原）

• 支持动态响应（根据参数返回不同数据）

针对这个开发环节，我们也基于Vite实现了一个非常好用的插件：vite-plugin-mock，用于提升开发效率。整体的设计如下：

相比于传统的 mock 方案，vite-plugin-mock在开发体验、数据维护上有更好的开发体验。

特性	传统Mock方案	vite-plugin-mock
数据真实性	随机生成，不可用	可在真实接口数据上任意修改
开发体验	需要启动Mock服务	配置简单，可随时修改数据
联调切换	手动修改请求地址	自动代理无缝切换
数据维护	独立维护Mock数据	数据存放在本地，每个人都可维护单独的数据

3.3 构建体积优化

这一部分主要从以下三个技术方案着手优化，再配合其他人工优化手段，打包体积由开始的 14M 优化到 1.8M，接入cdn功能后，则仅有500kb。

3.3.1 element-ui

fork element-ui 源码, 采用rollup进行打包，优化部分源码，修复部分 bug，重新发包为 @baidu-log/element-ui

这一步骤，js 体积从 1.2M 优化到 500kb。并结合下面 externals 功能，进一步使用cdn功能缓存这部分文件体积。

3.3.2 引入externals功能

将基础包通过cdn的形式在 index.html 模板中引入其umd格式的文件，从而避免打包这部分内容。这部分会用到cdn的缓存功能，会节约掉大约 2M 的体积。

vite-plugin-externals

这个是开源的vite插件，配置也比较简单，详见配置：www.yuque.com/shuoshubao/…

vite-plugin-assets

这个是为了配合上面vite-plugin-externals插件，将对应的externals的npm包对应的umd文件插入到模板中，代码详见：www.yuque.com/shuoshubao/…

为什么不直接写在 index.html 里呢？因为像 vue 和 react 这样的框架，在开发时都提供了对应的开发调试工具：dev-tools。而使用 dev-tools 则需要提供对应的 dist/vue.js，而react对应的则是 react.development.js。

3.3.3 大包的特殊处理

1. monaco-editor

项目中用到了 monaco-editor 这个编辑器组件，直接打包将会非常大，有10M以上的体积。根据官方提供的方案即可进行如下封装，其中 cdn 地址由百度的 npm 镜像服务提供支持。

代码详见：www.yuque.com/shuoshubao/…

2. xlsx, fabric 等

在项目中用到了 xlsx, fabric, markdown-it, echarts, draw.io 这几个体积很大的包，但又不属于很基础的包，只有少部分页面的某个功能点才会用到。针对这些包采用从cdn异步加载其umd包的形式来引入，而不是通过 import npm包的形式。

代码详见：www.yuque.com/shuoshubao/…

以上两种优化方案，与常见的动态引入方案（dynamic import）是有很大区别的，dynamic import 是通过编译工具将对应的npm包打包成一个独立的chunk，然后在使用的时候再通过loadScript方式引入。这种问题在于文件的缓存，一是chunk可能会变，二是像Vercel这种平台，每次发布都是一个全新的 s3 bucket，上线后缓存功能也就失效了。而上述这种方案，则利用npm镜像服务，每次都访问固定的cdn地址，也就达到了cdn的缓存目的了。

3.4 建设组件库

鉴于项目没有优质组件的背景，从零到一搭建了组件库，组件库主要包含以下内容：

1. 基于 Vuepress 建设高质量组件库文档

2. 迁移 element-ui 文档，并修复其中大量劣质示例代码

3. 采用 Vitest 编写工具方法的测试用例

4. 提供9个高频优质通用组件，10个业务组件

组件库文档：logsfe.vercel.app/

文档分为以下几大模块

• 优质组件：logsfe.vercel.app/components/…

• 组件库里的方法：logsfe.vercel.app/utils.html

• @nbfe/tools工具库方法： logsfe.vercel.app/tools/date.…

• ElementUI 文档：logsfe.vercel.app/element/ico…

• 前端定制的开发规范：logsfe.vercel.app/contribute/

实际效果：组件库中的组件在项目中目前已被使用240次，用户使用体验良好。

3.4.1 通用组件

基于大量的B端系统开发经验，提炼出配置化表格和配置化表单组件，满足项目中90%的开发场景，通过重构部分页面后比较分析，在写对应模块时，能减少40%的代码。

通用组件均与业务解耦，设计优雅的api，并提供大量示例。组件库里只提供少量的优质组件，严格把控每一行提交的代码，并为组件中的工具函数提供符合 JSDoc-style 规范的注释，且通过 Vitest 来编写单元测试。

3.4.2 element-ui 文档集成

在实际工作中，发现 element-ui 文档存在很多问题且早已不维护。

• 主题与日志中台不符，不利于查看

• 组件默认size过大，一页都看不了多少示例

• 右侧没有 toc 功能，不方便快速定位

• 示例很多写法不优雅，以及很多冗余代码被人机的复制到了项目中

• 在线调试示例采用的是 codepen 平台，这个平台很慢而且经常挂了

基于以上各种问题，将 element-ui 官方的示例 fork 到组件库中，使用和日志中台一样的主题，并修复上述各种问题。

并使用纯前端来实现了一个完全可用的 codepen 组件使用示例功能。

3.4.3 通用工具库

基于B端系统抽象的实用工具方法集合。在组件库中提供优质的说明文档和使用示例。这个已经发布到npm上，并在多个公司和团队使用。

包括日期处理、数据处理、接口数据格式化、针对element-ui的一些实用封装。目前已在项目中被93个文件使用150次。

项目地址：www.npmjs.com/package/@nb…

04 总结与展望

在频繁的需求迭代过程中，项目迟早会变成臃肿老旧的样子。当开发体验、开发速度、代码质量、项目可维护性、联调测试体验、线上质量等全方位令人举步维艰的时候，就该发起大规模的全面重构了。对每一项重构技术需要深刻掌握，才能掌握重构的深度和保证重构后的项目质量。另外，还定制了很多开发规范和最佳实践指导，但项目中仍存在大量不符合规范的地方，将在未来继续进行全量修复，直到将一个老旧的项目重构到更接近现代化前端项目的程度。

本文全面探讨了营销活动反作弊与电商反作弊的图算法应用。首先介绍了黑产薅取活动奖励、刷单等作弊行为的背景，随后深入讲解了同人挖掘技术，包括同人建模、挖掘步骤及稳定性处理。接着，依次介绍了标签传播算法、Fraudar算法、GCN网络的原理、优缺点及应用。最后，文章展望了未来图算法在风控反作弊应用的发展方向，如多模态数据融合与动态图实时计算，旨在应对黑产的快速演化，确保营销活动的公平性与数据真实性。

01 业务背景

在营销活动场景中，黑产团伙通过自动化手段大规模获取活动奖励，挤占真实用户权益造成营销资金浪费，并污染数据指标导致活动效果失真，从而影响运营决策准确性。

以当前主流作弊模式为例，黑产实施路径如下：

1. 资源准备阶段：通过虚拟机登录批量购买的百度账号。

2. 任务执行阶段：部署自动化脚本模拟用户行为，如视频播放、广告点击等。

3. 资金变现阶段：使用分散的真实微信账号进行提现操作。

在与反作弊的对抗中，黑产工具持续升级（如改机工具、IP池轮换等），传统特征采集数据趋于分散。我们的反作弊体系从两个方向不断提升防御能力：

1. 多维特征挖掘，包括设备指纹、行为特征以及环境特征。

2. 关联团伙分析，包括用户操作模式量化、昵称相似度分析以及基于账号-设备-提现账户等信息建立关联图谱。

上图为云手机工具示例。

在电商场景中，存在着类似于营销活动的批量团伙作弊，典型的即刷单。刷单作弊即非真实有购买需求的用户（机器或众包真人）为了提升店铺的销量、评分，替店铺虚假的下单、评价，然后收取店铺报酬的一种作弊方式。

02 同人挖掘

2.1 同人建模

黑产为了节省成本往往存在账号、设备共用的情况，因此我们定义“同人”概念：

若参与活动的账号、设备背后的主体相同，则为一个同人团伙。

在账号之外，增加一个同人粒度进行数据监控和风险控制。例如，某人使用5个手机号分别注册5个uid，并使用2个身份证进行实名认证，每天在3个设备上参与活动，并将收益提取到2个微信账号中，我们希望通过构图将其归类为一个同人团伙。

2.1.1 同人挖掘

挖掘步骤可分为以下3步：

1. 以用户百度账号为节点，共设备ID/手机号/提现ID/身份证号（加密）为边构图

2. 挖掘极大连通子图，即有边的强连通判为同人关系

3. 在多天参与活动的用户上挖掘同人关系，并与历史挖掘结果进行拼接，做同人ID稳定性处理

2.1.2 稳定性处理

在与历史同人结果拼接时，可将情况分为以下几类：

经过稳定性处理后，整体同人ID稳定性达96.8%，排除已知合并等不稳定因素稳定性达99.3%。

2.2 挖掘结果

由于线上已有一对多业务规则，同人团伙会采用多对多打散以绕过规则。

以下展示部分典型团伙构图：

2.3 同人应用

作弊识别：按照团大小逐渐收敛，从同人作弊株连、团内作弊风险浓度高、同人且有作弊风险几个思路进行策略迭代。

发放打压：对于作弊风险较低的羊毛党用户，业务侧可根据情况进行奖励发放打压。

03 标签传播算法及其应用

3.1 标签传播算法

标签传播算法（Label Propagation Algorithm，LPA）是一种基于图的半监督学习算法，常用于社区检测和节点分类任务。它通过迭代传播标签信息，利用数据结构的相似性来推断未知节点的标签。

3.1.1 算法流程

输入：图$(G=(V,E))$(G=(V,E))，已知标签节点集合$V_L$VL，未知标签节点集合$V_U$VU。

输出：所有节点预测标签$({y_i}_{i\in V})$(yii∈V)。

初始化阶段：为每个已标记节点$v\in V_L$v∈VL分配固定标签$y_v$yv，为每个未标记节点$v\in V_U$v∈VU随机分配标签（或按先验分布分配）。

迭代传播阶段：对于每个未标记节点，将出现频率最高的邻居标签作为自己的新标签。

定义$N(v)$N(v)为节点$v$v的邻居集合，$y_v^{(t)}$yv(t)为节点$v$v在迭代$t$t时的标签，Ⅱ为指示函数（当$y_u=l$yu=l时为1，否则为0）。

无权图标签更新规则 $y_v^{(t+1)} = \argmax_l \displaystyle\sum_{u\in N(v)} \Pi(y_u^{t}=l)$yv(t+1)=argmaxlu∈N(v)∑Π(yut=l)

加权图标签更新规则 $y_v^{(t+1)} = \argmax_l \displaystyle\sum_{u\in N(v)} w_{uv} \cdot\Pi(y_u^{t}=l)$yv(t+1)=argmaxlu∈N(v)∑wuv⋅Π(yut=l)，其中$w_{uv}$wuv为边权重。

终止条件：当迭代不再改变任何节点的标签时；或达到最大迭代次数。

上图为标签传播示例。

3.1.2 实践细节

最高频率标签不唯一时：随机选择（结果可能不稳定），或结合其他信息（如节点度数等）。

传播顺序：同步更新（所有节点同时更新，可能振荡），或异步更新（按随机或度排序等顺序逐个更新）。

3.1.3 无监督改进

在完全无监督的情况下，仍然可以通过改进方法实现社区检测或聚类任务。面对局部最优问题，使用模块度作为目标函数多次运行。

算法流程：

1. 随机初始化所有节点的标签（如1到K，K为社区数）

2. 执行标准LPA迭代，直到收敛，计算模块度Q

3. 重复多次，选择模块度最高的划分结果

模块度指标的核心思想：社区内部的连接应显著高于随机情况

其中$A_{ij}$Aij为邻接矩阵元素（节点$i$i和$j$j相连时为1，否则为0），$k_i$ki为节点$i$i的度数，$m$m为图中总边数$m=\frac{1}{2}\sum_iki$m=21∑iki，$c_i$ci节点$i$i所属的社区，$\delta(c_i,c_j)$δ(ci,cj)若$c_i=c_j$ci=cj则为1，否则为0。

3.1.4 算法优缺点

优点：

1. 计算高效：每轮迭代复杂度$O(|E|)$O(∣E∣)

2. 无需参数调优：完全基于图结构

3. 自然并行化：节点更新可并行执行

局限性：

1. 结果可能不稳定：受初始化顺序影响

2. 仅利用拓扑结构：忽略节点特征信息

3. 对稀疏图效果差：邻居信息不足时传播受限

3.2 在营销活动场景的应用

在营销活动场景中，黑产在资源准备和任务执行阶段存在批量化的账号生成和活动行为，在挖掘结果中也经常发现存在昵称、行为序列等相似的聚集特征。

3.2.1 构图

以用户账号为节点，以昵称与活动点位行为序列为例，分别采用针对字符串、序列相似度的建边算法。

昵称相似度：两两计算用户昵称的编辑距离，编辑距离越小说明两个昵称越相似。

序列相似度：拼接用户活动点位（活动行为类型标记）-时间作为行为序列，将序列中的打点转换为词频矩阵，使用MinHash估计Jaccard相似度。

实践细节

1. 预处理，如做昵称长度分桶、异常用户筛选等，减少相似度计算量。

2. 使用局部敏感哈希（LSH）进行优化，减少搜索空间。

3. 可结合业务场景做相似度阈值过滤，缩减构图输入。

3.2.2 团伙挖掘

使用无监督的LPA算法进行团伙挖掘，设定团伙阈值、或结合业务场景添加其他特征进行作弊识别。

下表为实际应用中，通过用户行为序列相似挖掘出的一个团伙部分数据，其设备和地域并不聚集，但昵称可看出为批量操作。

04 Fraudar算法及其应用

在电商场景中，用户-店铺之间天然形成一种二部图的结构，二部图是指图中的节点有两类、边有一类，两类节点互相连接，每类节点本身之间没有连接。Fraudar算法是一种适用于二部图结构的算法，下文详细介绍我们在电商场景的应用。

4.1 Fraudar算法原理

4.1.1 全局可疑度度量

Fraudar定义了一个全局度量 $g(S) = \frac{f(S)}{|S|}$g(S)=∣S∣f(S)，其中：
● $f(S) = f_v(S) + f_{\epsilon}(S)$f(S)=fv(S)+fϵ(S)：子网络 $S$S 中节点的可疑度之和$（f_v）$（fv）与边的可疑度之和$（f_{\epsilon}）$（fϵ）；
● 假设在一个用户-商品二部图中，那么$f_v(S)$fv(S)可以理解为用户或商品的独立可疑度，$f_{\epsilon}(S)$fϵ(S)可以理解为用户在商品下的订单/评论的可疑度。
● $|S|$∣S∣：子网络的规模（节点数）。
$g(S)$g(S)表示一个网络的平均可疑度，满足以下四个属性：

1. （节点可疑度）当节点总数、边可疑度保持一致时，由较高可疑度的节点组成的网络比由较低可疑度节点组成的网络更可疑。

$|S| = |S'| \land f_{\epsilon}(S) = f_{\epsilon}(S') \land f_v(S) > f_v(S') \Rightarrow g(S) > g(S')$∣S∣=∣S′∣∧fϵ(S)=fϵ(S′)∧fv(S)>fv(S′)⇒g(S)>g(S′)

2. （边可疑度）其他条件不变，在网络中添加边会增加该网络的可疑度。

$e \notin \epsilon \Rightarrow g(S(v, \epsilon \cup \\{e\\})) > g(S(v, \epsilon))$e∈/ϵ⇒g(S(v,ϵ∪e))>g(S(v,ϵ))

3. （大小）假设节点和边的权重都相等，边的密度也相等，那么更大的网络比小的网络更可疑。其中边的密度$\\rho(S)$rho(S)定义为网络中的边数除以它可能的最大边数。

$|S| > |S'| \land S \supset S' \land \rho(S) = \rho(S') \Rightarrow g(S) > g(S')$∣S∣>∣S′∣∧S⊃S′∧ρ(S)=ρ(S′)⇒g(S)>g(S′)

4. (集中度) 较小的网络比相同总可疑度但规模更大的网络更可疑。

$|S| < |S'| \land f(S) = f(S') \Rightarrow g(S) > g(S')$∣S∣<∣S′∣∧f(S)=f(S′)⇒g(S)>g(S′)

4.1.2 抗伪装设计

即使虚假账户添加大量正常连接（伪装），算法仍能通过识别局部密集子网络发现异常，因为伪装行为会导致整体网络稀疏化，而欺诈子网络仍保持高密度。

上图是虚假账户常用的伪装方法，假设为用户-商品网络，那么（a）刷单用户通过向正常商品随机下单伪装；（b）刷单用户通过向正常商品添加有偏的伪装；（c）刷单用户劫持一些正常账户。

算法使用了列权重作为边权的方式来抗伪装，即利用商品的边数来定义边权。在一个用户商品图中，算法先确定商品节点的数量，利用 1/log(商品节点边数+5)确定边权 （边可疑度），然后按照边权汇总求取商品节点、用户节点的权重（节点可疑度）。

4.1.3 算法实现流程

利用列权重定义边权能够抵抗虚假账户向正常商品增加边的伪装，因为是往正常商品增加边，不会影响欺诈商品的边数，也即三种伪装方式的欺诈块仍然是高权重的/密集的。而如果使用行权重，那么一个用户通过向正常商品增加边，就可以稀释自己的欺诈边的可疑度，达到伪装的目的。

上图是 Fraudar 算法的步骤。迭代移除当前优先级最高的节点（可疑度贡献最低的节点），逐步缩小网络规模，直至所有节点被移除。每一步记录剩余子网络的全局可疑度$g(S)$g(S)。在所有迭代步骤中，$g(S)$g(S)值会先增大后减小，算法保留每一步的迭代结果，选择$g(S)$g(S)达到最大值的子网络作为最可疑的欺诈团伙。

由于遍历删除图中可疑度最低的节点是个$O(|V|^2)$O(∣V∣2)的操作（迭代$|V|$∣V∣次，每次找到可疑度最低的节点$O(|V|)$O(∣V∣)，因此算法引入了优先树（小顶堆），叶子节点对应图中的节点，父节点记录子节点中的最高优先级，以此实现快速访问和更新优先级。优化后算法需要迭代边数次，每次查找和更新节点优先级的复杂度变为$O(log|V|)$O(log∣V∣)，算法的总时间复杂度为$O(|\epsilon| log|V|)$O(∣ϵ∣log∣V∣)。

另外，在实际应用中，只获得可疑度最大的子图可能并不够用，可以在获取一个可疑度最大子图后将其中原始图中删除，然后再在剩余的图中获取次可疑的子图，循环往复得到多个可疑子图。

4.1.4 优缺点及改进方向

优势：

1. 抗伪装能力通过全局度量而非局部密度，算法能抵抗虚假账户添加正常连接的行为，即使部分节点被“污染”，仍能准确识别核心欺诈簇。

2. 高效性与可扩展性利用优先树结构优化节点移除操作，时间复杂度为 O(|∈| log |V|)，适用于大规模网络。

3. 实际应用场景

• 电商刷单检测：识别虚假评论形成的密集用户-商品子网络。

• 社交网络反欺诈：检测伪卡交易或虚假关注关系。

• 金融反洗钱：发现异常交易团伙。

4.2 Fraudar算法应用

4.2.1 构图与关系降噪

实践中，我们利用用户-店铺的订单关系构建二部图，并且为了提升二部图中的风险浓度，对低风险店铺等做了剪枝实现关系的降噪，然后输入Fraudar算法挖掘异常子图。

原始的Fraudar算法只能挖掘出风险最高的一个子图，但实际业务中，一般不止一个作弊团伙，因此我们在每次运行Fraudar算法产生一个子图后，就将这个子图从原始图中裁剪掉，再次运行Fraudar算法得到次可疑的子图，即循环Fraudar。通过这种方法，我们可以获得期望数量的异常子图。

4.2.2 结合监督模型

挖掘出的风险子图由用户和店铺构成，而实际业务的识别目标是订单，且风险子图中会掺杂少量正常用户的订单。为了进一步提升算法识别结果的准确率，我们将挖掘出的风险子图输入到LR模型进行精细判别。LR模型使用用户、店铺的特征作为输入，异常订单为正样本、正常订单为负样本训练，最后在风险子图的用户、店铺的订单上区分出异常订单并落地到业务。

05 GCN模型及其应用

上文提到Fraudar模型为了提升图的风险浓度做了剪枝降噪，这样提升算法精准的同时会损失一部分召回。并且Fraudar本身是无监督模型，还需要结合监督模型做精细化判别。因此我们尝试了端到端的GCN模型，提升召回的同时简化了识别链路。

5.1 GCN模型原理

5.1.1 GCN的核心思想：消息传递与聚合

GCN的核心是通过邻域聚合更新节点特征，其本质是让每个节点从邻居节点中提取有效信息：

1. 基础聚合公式：

$H^{(l+1)} = \sigma\left(\hat{D}^{-1/2} \hat{A} \hat{D}^{-1/2} H^{(l)} W^{(l)}\right)$H(l+1)=σ(D^−1/2A^D^−1/2H(l)W(l))

其中：

• $\hat{A} = A + I$A^=A+I：邻接矩阵加入自连接，防止节点自身信息丢失。

• $\hat{D}$D^：度矩阵的对称归一化，解决节点度数差异导致的权重偏差。

• $W^{(l)}$W(l)：可学习的权重矩阵，用于特征变换，即卷积核。

• $H^{(l)}$H(l)：激活值，对于输入层可以理解成特征矩阵。

2. 关键设计：

• 归一化：通过$\hat{D}^{-1/2} \hat{A} \hat{D}^{-1/2}$D^−1/2A^D^−1/2避免度数高的节点主导信息传播，使模型更稳定。

• 非线性激活：如ReLU函数，增强模型的表达能力。

5.1.2 数学视角：从拉普拉斯矩阵到频谱域卷积

GCN的理论基础源自图谱理论，通过将图信号转换到频域进行卷积操作，核心概念：

1. 拉普拉斯矩阵：定义为$L = D - A$L=D−A，其特征分解$(L = U \Lambda U^T)$(L=UΛUT)将图结构映射到频域空间。

2. 图傅里叶变换：利用特征向量矩阵$U$U对节点特征进行频域投影，卷积操作简化为频域的乘积。

a. 卷积定理：函数卷积的傅里叶变换是函数傅里叶变换的乘积，即对于函数$f(t)$f(t)与$h(t)$h(t)两者的卷积是其函数傅里叶变换乘积的逆变换。
b. 图傅里叶变换把图上定义的任意向量，表示成了拉普拉斯矩阵特征向量的线性组合。

3. 切比雪夫近似：为降低计算复杂度，GCN采用一阶近似（仅考虑直接邻居），公式退化为经典聚合形式。
第一代 GCN：将输入特征通过图傅里叶变换从空域映射到谱域，做卷积运算后再映射回空域。

$Y = U \cdot g_\theta(\Lambda) \cdot U^T X$Y=U⋅gθ(Λ)⋅UTX

第二代GCN：利用切比雪夫多项式近似$gθ(Λ)$gθ(Λ)，避免$O(N^3)$O(N3)复杂度的拉普拉斯矩阵分解。
卷积核用 K阶段切比雪夫多项式展开：

$g_\theta(\Lambda) = \sum_{k=0}^K \theta_k T_k(\tilde{\Lambda})$gθ(Λ)=∑k=0KθkTk(Λ~)

最终 GCN 公式：

$Y = \sum_{k=0}^K \theta_k T_k(\tilde{L}) X$Y=∑k=0KθkTk(L~)X

第三代 GCN：只保留一阶切比雪夫多项式，并加入自环和归一化。

$H^{(l+1)} = \sigma \left( \hat{A} H^{(l)} W^{(l)} \right)$H(l+1)=σ(A^H(l)W(l))

5.1.3 模型结构：轻量化与高效性

GCN的典型结构通常仅需2-4层即可完成高效学习，原因在于：

1. 层数限制：过深的网络会导致过平滑（图中同一连通分量的节点特征趋同），因此实践中常用浅层架构。

2. 参数共享：每层共享权重矩阵，大幅减少参数量，适合处理大规模图数据。（相对于一个节点一个权重矩阵的全连接形式）

3. 应用场景：

• 节点分类（如电商刷单用户检测）

• 图分类（如分子属性判断）

• 链接预测（如推荐系统好友关系推断）

5.1.4 GCN的优缺点与改进方向

1. 优势：

• 天然融合图结构与节点特征，适合复杂关系建模。

• 计算高效，支持稀疏矩阵优化。

2. 局限：

• 过平滑问题：深层网络性能下降。

• 静态图假设：难以处理动态变化的图结构。

5.2 GCN模型应用

5.2.1 构图

利用订单作为节点、订单之间的属性关联关系构建同构图。特征上采用用户、 店铺等风险属性刻画订单，异常订单为正样本、正常订单为负样本。

5.2.2 风险订单挖掘

由于实际业务中有标签的风险订单、正常订单仅是全量订单的一小部分，因此我们采用了半监督的方式训练GCN模型，利用有标签的订单对无标签的订单进行推理。GCN模型设计上针对的是静态图，应用中我们采用了随着时间窗口滚动构图的方式来适应动态变化的数据，滚动过程中排除了GCN模型本身推理的标签，防止对模型自身结果过拟合。

这里解释下，为什么我们不采用一个训练好的模型在线上不断的推理，而是滚动的训练推理。这是因为GCN模型从原理上属于直推式模型，通常的训练好一个模型后不断的对新数据推理的模型是归纳式模型。GCN的直推式，本质上是因为卷积计算用到了图的拉普拉斯矩阵，图发生了变化，那么这个拉普拉斯矩阵也就发生变化，训练的模型也就失效了。

既然GCN是直推式的，这里又产生一个问题，为什么我们不使用归纳式模型呢？事实上，我们对比了GraphSage等模型在同样图结构、特征数据上的效果，在我们的场景中比GCN效果差，为了保证业务效果我们最终采用的是GCN。

06 总结和展望

在风控反作弊的业务中，我们落地了LPA、Fraudar、GCN等算法并取得了良好的效果，未来我们希望做的更多。

1. 多模态数据融合：从单一图谱到全域关联

未来风控需整合图数据、时序数据（如交易频率）、文本数据（如聊天记录）等多模态信息。例如，通过图嵌入技术将设备、IP、地理位置等实体统一表征，构建全域风险画像。

2. 动态图实时计算：应对黑产快速演化

当前黑产通过“少边构造”（刻意断开部分关联）绕过静态图检测，需引入动态图算法（如时序GNN）实时捕捉行为演变，并结合增量计算优化性能。

3. 可解释性与对抗防御：提升算法可信度

探索可视化工具（如子图归因分析）解释GCN决策逻辑，并研发对抗训练技术抵御黑产对模型的逆向攻击。

图算法正从“辅助工具”升级为风控系统的核心引擎，而未来的挑战在于如何平衡技术效能、业务合规与用户体验。

百度垂直搜索系统将搜索核心能力赋能阿拉丁（百度搜索特型结果）、垂直领域搜索、应用内搜索等场景，支撑了数百个检索场景、百亿级内容数据的检索。随着接入业务数量和数据量不断增长，系统在海量数据管理与调度上遭遇新的挑战，通过垂搜数据管理系统弹性调度优化实践来满足业务增长需求。

01 背景

1.1简介

百度垂搜架构的召回引擎经过历史架构演进确定了异构部署的架构模型，相较于同构部署在容量自动调整、数据按需存储等方面更具效率与成本的优势，同时在海量数据和海量检索方面也实现了高可用和高性能。目前系统已承接80+业务，全机房部署了数百个检索服务，数千个索引库，共计数百亿文档收录。随着接入新业务数量的增加，以及存量业务的深入迭代，我们遇到了更加复杂多样的场景，进而对系统提出更高的要求。本文主要介绍我们的系统在海量数据管理与调度上面临的问题， 以及各项优化工作落地后在系统扩展性、稳定性等方面取得的效果。

1.2 当前数据管理架构存在的问题

此前我们的系统设计了弹性伸缩机制应对流量和数据量的上涨，冷热分离机制实现了资源按需部署。随着接入业务的增加，系统逐渐暴露出一些新的问题，主要体现在以下几点:

• 元信息管理瓶颈。系统使用ETCD进行服务发现和心跳管理， 然而所有业务实例直连ETCD存在严重读写放大问题， 导致ETCD负载超发出现单点瓶颈, 限制集群规模进一步增长。

• 依靠人工评估资源。新业务的接入或者一些大事件运营保障依赖人工估算所需资源，不仅耗费人力，而且不够准确，估算过高，服务长期处于低负载会造成资源浪费，估算过低，服务容易过载，进而导致稳定性问题。

• 数据量增长瓶颈。 当前的架构可以在无需重新建库的情况下原地扩分片，但是分片数只能倍数扩展，并且分片数量有限制，大库场景容易触发上限，进而导致数据量无法继续增长。

02 检索系统与数据管理系统架构

2.1 检索系统架构概览

首先简单介绍下垂搜检索系统的各模块，如下图所示:

• RANK。检索精排模块，负责query理解、请求构造、多队列拆分、正排数据获取、策略因子计算、算分排序、返回结果组装等流程。

• BS。检索召回引擎，负责基础召回/粗排，根据基础相关性等权重因子进行数据的粗筛，支持基于term倒排拉链和ANN向量基础召回。

• BUILD。数据建库模块，负责数据处理、切词、生成正排/倒排/向量/摘要等功能。

每个垂类(业务)拥有一套独立的上述检索系统服务，数据管理系统为每个业务的检索系统提供实例调度、容量管理、服务发现、心跳管理、路由控制等能力，数据管理系统面向的核心管理对象是召回引擎(BS)。

2.1.1 垂搜召回引擎

如下图所示，百度垂搜的召回引擎是一个流式、多分片、异构、有状态的倒排+向量索引引擎:

• 流式。业务经过离线建库环节产出建库包并生效到Kafka中，召回引擎再从Kafka消费，数据从建库到检索可实现秒级生效。

• 多分片。业务数据量超过单机存储上限，会被拆分成多个分片(slice)，每个分片由PaaS层面实例承载，并对应Kafka的一段partition区间。

• 异构。单个业务的若干个资源号(resource)之间支持独占或者混部，一般根据服务负载设置不同副本数，根据数据量设置不同分片数。

• 有状态。每个实例承载一个或多个分片数据，周期性汇报心跳，消费分片由中控服务统一调度。

名词解释:

• resource(资源号): 一类或者一个场景的数据集合，即一个索引库，一个业务通常包含多个资源号(如图中mobile_game，pc_game， game_video等)。

• slice(分片):数据调度基本单位，一个resource根据数据量可能会拆分成多个slice(mobile_game有三个slice, pc_game和game_video1个)。

• slot:数据划分的基本单位，一个slice下有若干个slot， 与Kafka的partition一一对应，在业务接入时根据数据量级确定。

pod:PaaS层面实际的物理存储容器，一个pod会承载一个或多个slice，由中控服务统一调度。

2.2 动态化数据管理系统

动态化数据管理系统负责召回引擎的每个实例从建库到检索，从部署到下线的全生命周期管理。经过服务重构、架构升级、新功能建设等方面的优化工作，形成了包括中控服务，心跳服务(HeartbeatService), 名字服务(NamingService), 存储ETCD等模块的现有系统架构:

2.2.1 中控服务

整个动态化数据管理系统的核心模块，负责各类调度任务的发起、控制等:

• 资源号接入/下线。新增资源号(索引库)，为每个资源号根据副本数、资源号之间部署关系等调度实例；下线资源号， 对应资源号的数据发起清理以及实例回收。

• 副本保活。每个资源号实际副本数可能由于扩缩副本或PaaS层面迁移，导致与目标副本数不一致，中控服务负责定期轮训所有资源号(分片)，维持副本数与目标一致。

• 容量管理。自动扩缩容服务/人工基于负载调整资源号的副本数，并通过副本保活生效，基于数据量调整资源号分片数，通过任务控制器生效。

• 可用度控制。上线重启需要保证分片维度的可用度，变更由PaaS发起，每个实例重启前需要请求中控服务的探针，中控服务根据当前分片可用度决定实例是否可以重启。

2.2.2 名字服务NamingService

提供服务发现，实例屏蔽，建库路由控制等能力：

• 服务发现。周期性加载并更新全量业务的资源号检索路由拓扑信息，对每个分片过滤心跳丢失、未消费完成、重启中等暂不可用实例。

• 实例屏蔽。支持异常实例的分片维度/App维度屏蔽，线上快速止损，并保留现场便于后续问题追查。

• 建库路由控制。提供离线建库侧全量业务资源号与Kafka partition映射关系查询，资源号倒排索引双写控制。

2.2.3 心跳服务HeartbeatService

负责召回引擎(BS)实例、分片心跳信息收集并持久化，实例消费区间信息传递等:

• 心跳管理。收集召回引擎实例上报的心跳信息，包括实例自身心跳以及消费分片信息， 并将心跳信息聚合后写入ETCD。

• 实例调度信息传递。获取由中控调度下发的最新消费分片信息，写入心跳请求response，实例感知到消费分片发生变化后，清理旧分片数据，并重新消费新分片数据。

2.2.4 存储ETCD

动态化数据管理系统各类元信息持久化存储:

• 实例心跳信息。包括版本号，实例唯一标识，上报时间戳，消费分片等。

• 分片路由拓扑信息。分片下全量副本状态信息，包括endpoint，snapshot版本，上报时间戳，消费状态等。

• 业务资源号拓扑信息、建库路由信息。单业务视角下全量资源号信息，包括版本号，分片数，副本数，对应Kafka partition区间，rpc参数配置等。

03 弹性调度机制优化实践

3.1 服务发现、心跳管理模块重构

3.1.1 原有架构

可以看到在原有架构，业务RANK和BS实例都是直连ETCD，随着业务接入数量的增加逐渐暴露出一些问题:

• 读流量放大。同业务的不同RANK实例会各自访问ETCD获取相同的路由拓扑，导致读流量放大，对于RANK实例数多的业务放大现象愈发明显。

• 写流量放大。每个分片含有多个副本，在进行更新时，一轮周期内同一个分片会被写入多次，导致写流量放大，对于副本数多的分片写竞争愈发激烈。

• 升级改造困难。路由筛选策略、心跳上报策略均内嵌在sched-lib中, 进行升级需要给每个业务RANK/BS上线，人力成本巨大。

为了解决上述问题，我们对心跳管理和服务发现模块进行了微服务拆分，新增心跳服务(以下简称HS)和名字服务(以下简称NS)避免了业务实例直连ETCD，同时引入了Prometheus，对心跳上报状态和路由获取状态等信息进行监控和可视化展示。

3.1.2 NS(NamingService)设计

我们对NS的定位是作为ETCD的cache，采用Read-Through的模式，对全量业务的RANK提供拓扑信息查询，RANK不再直接访问ETCD:

• NS本身设计为一个无状态服务， RANK可以访问任意一台NS获取拓扑，NS实例之间拓扑路由保证最终一致性，NS在拓扑变更时返回拓扑信息+MD5(拓扑)+更新时间戳，未变更时仅返回MD5和时间戳， RANK基于MD5和时间戳自行判断是否需要更新。

• 拓扑更新策略下沉到NS中，RANK获取到的拓扑即为直接可用拓扑，针对不同业务提供不同的控制策略并且后续升级改造只需上线NS，成本大幅降低。

单机房3台NS实例即可支撑全部业务拓扑查询，重构前后ETCD读流量比例为M:3，M为平均每个业务RANK实例数，假设N取30，则读流量下降90%。

3.1.3 HS(HeartbeatService)设计

HS负责收集BS实例本身的心跳以及实例消费的分片的心跳，周期性聚合写入ETCD，并且向BS实例返回其最新的消费分片信息:

• HS采用无主节点设计，也支持任意水平扩展。同一个业务的不同BS实例通过一致性hash方式请求同一台HS实例, 便于HS进行分片维度的信息聚合，这样在大部分时间，每个分片无论有多少个副本一个周期内只会被写入一次，实例本身的心跳采用批量更新形式，写竞争大幅降低。

• BS在上报心跳的同时会从HS的response中获取自身消费的最新分片信息，如果分片信息变化，则清理老分片数据，消费新分片数据，后续只上报新分片状态信息。

单机房3台NS实例即可支撑全部业务心跳更新，重构前后ETCD写流量比例为N:1，N为平均每个分片副本数，假设N取5，则写流量下降80%。

3.2 自动扩缩容

3.2.1 当前现状

BS是一个多分片、异构服务，即每个App内通常部署了多个资源号，各业务App在PasS层面隔离部署，在资源利用率、扩缩容管理等方面我们遇到以下问题：

• 整体资源利用率低。全机房拥有上百个BS业务App、上千个资源号，PaaS层面的整体平均峰值CPU利用率低于平均水平，峰值CPU超过70%的资源号占比不足20%。

• 依赖人工进行资源号副本数调整。一般上线前通过人工压测评估放量后所需的资源然后进行申请，有时候通过压测难以估算真实的资源，并且后续业务迭代或者流量变化也会引起资源使用的变化，如果负载超发，服务稳定性难以保障，如果负载太过空闲，也会造成资源浪费。

• 无法直接接入PaaS层面自动扩缩容能力。一方面PaaS无法感知每个App内资源号维度负载信息，另一方面每个实例承载分片信息只能由中控服务调度，因此无法直接服用PaaS层面自动扩缩容能力。

3.2.2 自动扩缩容实现

为了实现容量自适应调整，我们开发了一个自动扩缩容服务，对全量资源号进行容量管理。自动扩缩容服务周期性计算资源号维度负载，根据负载情况，触发中控服务进行资源号副本数调整，或者PaaS层面实例数调整。对于扩容，优先调度存量资源池中实例，如果存量实例不足则触发PaaS扩容；对于缩容，先将空闲副本数回收至空闲资源池，再触发PaaS缩容。对于自动扩缩容服务的设计我们主要考虑了以下几点:

负载指标选取

垂搜系统大部分业务BS为纯内存版本，且几乎没有下游网络请求，属于典型的计算密集型业务， 因此我们选择CPU作为负载计算参考指标，另外资源号混部场景进一步结合QPS和Latency进行判断。此前我们已经实现了基于Prometheus采集实分片维度CPU、MEM、QPS、Latency、建库数据量等指标全量业务覆盖，因此可以低成本的获取到全量资源号维度的负载数据。

负载状态流转

每个资源号从扩容到缩容，共定义如下7种状态：

enum LoadStatus { LOAD_STATUS_LOAD_OK = 0; //正常负载 LOAD_STATUS_OVERLOAD = 1; //超负载 LOAD_STATUS_IDLELOAD = 2; //低负载 LOAD_STATUS_BS_ADD_REPLICA = 3; //bs 扩副本中 LOAD_STATUS_BS_REMOVE_REPLICA = 4; // bs 缩副本中 LOAD_STATUS_TRIGGER_PAAS_EXPENSION = 5; // PaaS 扩容中 LOAD_STATUS_TRIGGER_PAAS_SHRINK = 6; // PaaS 缩容中 }

每个资源号根据负载情况在上述状态之间流转:

扩缩容执行流程

• 扩副本

  • 优先调度App内空闲实例，不足则触发PaaS层面实例数扩容，循环执行直到负载恢复正常。

• 缩容

  • 先将资源号多余副本释放为空闲实例，再触发PaaS层面缩容，循环执行直到资源号负载以及空闲实例数回到正常水平。

3.3 资源号扩分片进阶

每个资源号随着数据量级不断增长，分片数也需要动态扩展，否则会出现分片内存超发的情况。

3.3.1 当前扩分片方案

每个资源号按resource->slice->slot的层级划分，slot 是数据划分最小单位与kafka partion一一对应，在业务接入时每个资源号slot(partion)的数量已经确定。扩层时，资源号的slot数量不变，分片数变成原来2倍， 每个分片的slot数则为原来的1/2。

原有的扩分片方案可以在无需重新建库的情况下实现业务无感的原地分片扩缩操作，然而依旧存在两个问题:

• 分片数按指数增长，当分片数超过一定数值，将带来不容忽视的资源成本。

• 如果初始分配slot数太少，当slice:slot=1:1时，无法再扩层，数据增长出现瓶颈。

3.3.2 进阶扩展方案

对于分片无法继续扩展但是依旧需要继续建库的情况，先前的方案只能是重建一个新的资源号，需要业务、架构共同介入，历史上我们使用原方案迁移一个资源号，前后投入近3周时间，耗费成本巨大，因此我们需要一个成本更低的方案。通过分析，当前分片的扩展瓶颈主要有以下三个限制条件：

• 每个资源号的slots是一段连续的区间。

• BS的slot与Kafka的partition一一对应。

• 初始分配slot数太少，且后续不支持调整。

只需要打破其中任意一个条件，则可以消除瓶颈。综合考虑改造成本、扩展灵活性、实现难度等因素，我们选择从条件三入手，在新的partition区间重建分片，分片数和slot数根据数据量设置，将旧分片的数据全量复制到新的分片上，再将新分片替换旧分片，如下图所示。

整体实现

对于一个流式建库系统，业务可能时刻都在进行数据建库，我们希望做到迁移过程中业务依旧可以持续建库，并且保证数据不丢失、时序不错乱。我们的方案是将数据分为存量数据(老分片中的全量数据)和增量数据(实时写入的新数据)，对于增量数据可以通过双写机制，同时写入新旧分片，存量数据则通过构建snapshot的方法迁移至新分片，新分片数据ready后，再由服务发现层将检索流量切换至新分片，整体流程如下:

• 离线侧开启双写，保证增量倒排索引数据同时写入新旧分片，正排和摘要部分数据无需变化。

• 基于旧分片构建新分片snapshot, 并记录构建时间点。将该时间点前旧分片所有数据进行resharding构建新分片snapshot。

• 新分片的BS实例加载构建好的snapshot，然后每个partition的消费offset回退到snapshot构建时间点开始重新消费。

• 服务发现层将资源号到slot区间映射切换到新分片上，检索流量从老分片迁移至新分片。

• 将旧分片BS实例回收，并关闭双写。

04 总结与展望

4.1 总结

本文介绍了百度垂搜检索数据管理架构在弹性机制建设上的一系列优化工作，并且在扩展性、稳定性、以及成本效率等方面均取得了预期成果:

• 扩展性

  • ETCD负载下降一个量级，单机房BS、RANK集群规模提升两个量级， 单分片副本数上限提升至5000+。

  • 分片扩展数量不再受限，解决了部分存量业务无法扩展分片导致的内存超发问题，并支持搜索创新业务数据量从百万级逐步增加至数十亿量级。

• 稳定性

  • 存量调度问题被修复，新增多种路由调度策略以应对不同场景，分片可用度不足干预时间从小时级缩短至分钟级。

  • ETCD负载不再超发，慢查询基本消失，稳定性风险基本消除，心跳上报、拓扑获取状态建立监控，异常情况及时感知。

• 成本效率

  • 全机房BS接入自动扩缩容，实现容量自适应调整，整体峰值CPU利用率提升了15%+，同时相比之前减少了80%人工介入容量调整的情况出现。

  • 部分业务通过分片合并，最终使用存储资源为下降至原来的20%，并且检索97分位耗时降低了20ms，业务侧效果与先前打平。

4.2 展望

目前索引库的自动扩缩容机制实现了副本数随负载(CPU)的自动调整，后续将实现分片数随数据量的自动调整。另外，在大库场景将持续建设流批一体机制，以追求用更低的存储成本实现更高的检索性能。

6月6日，由人民日报文化传媒、百度公司联合主办的2025智能经济论坛在人民日报社举行。会上，百度集团执行副总裁、百度智能云事业群总裁沈抖分享了百度智能云以全栈自主可控能力赋能企业创新和产业升级的实践与成果。

今天，越来越多的企业对大模型的需求，已经从最初的“提示词优化”进化到“更系统的智能体建设”。如何高效开发智能体应用，选哪个模型，用什么算力，成为企业的新挑战。

百度智能云深入产业实践，沉淀中国经验，打造从应用、模型到国产算力的“人工智能+”基础设施，已经服务65%的央企客户，同时也支撑着千行百业客户的AI创新。

沈抖表示，百度智能云会坚定投入，打造更先进、高效的人工智能基础设施，服务更多的中国企业，加快推动大模型产业化发展，释放更多场景价值。

百度集团执行副总裁、百度智能云事业群总裁沈抖

以下为演讲全文：

尊敬的各位领导，亲爱的朋友们，大家好！我给大家汇报一下我们最近经历的一些大模型和产业结合的进展。

近年来，基础模型持续迭代，AI产品体验不断优化，正在从“能用”走向“好用”。

越来越多的领先企业，坚定攻关大模型，在有些战略价值、经济效益和民生意义的高价值场景里面主动布局，持续突破。

这方面我们和很多客户做了很多有价值的探索，从最初大家最熟悉的提示词优化，走向更系统的智能体建设。

接下来，我跟大家分享一些工作进展和案例。

今天人民日报的头版右下角有一条消息，中国建成了全世界规模最大的互联网办电服务体系，这个意义重大。因为生活生产方方面面都离不开电。

电力公司每天都会接到大量的用电需求，尤其是企业级的需求，非常复杂。供电公司要编制非常完善的供电方案，工作量很大。

今天，我们发布：营销供电方案智能体。它可以帮助电力企业把这项工作变得更高效、更智能。

过去，在业务受理环节就要填报大量数据和资质证照，制定供电方案时常常要多个部门的工作人员上门现场勘察，很复杂。

今天看一下我们是怎么跟国网一块解决这个问题的。

用电企业通过国网APP发起对话以后，智能体首先通过意图识别确认办电需求，然后进行任务拆解和规划，将办电需求分配给用电类别、负荷性质等不同的专家模型，完成推理，并且填写工单不同字段。

通过多轮对话精准识别用户办电需求之后，智能体会自动生成多套供电方案，还能帮用户对比不同方案的优劣、做出最优选择。

图上就是实际办电过程中需要走过的流程，也是智能体背后处理的流程。从上面可以看到办电流程很复杂，远超一般的业务场景。

现在智能体能够全面掌握流程，准确调动行业知识和工具系统，实现企业办电流程的全面智能化，而且，这套流程、知识和工具，可以快速复制到更多的电网系统，企业更轻松，让用户更便利。

下面看一下出行。安全高效的出行肯定是所有人的愿望。然而路上各种突发情况，是我们不得不面对的现实。

今天我们发布：公路应急指挥智能体。

把处理突发情况交给智能体处理，可以实现事件预警准确率提升到95%以上；处置时间从1小时以上缩短至30分钟左右。

我们看下这个是怎么在河北京雄高速落地的。

屏幕上展示的，是一些典型的事件类型。

我们以异常停车来举例。

，时长00:55

进入京雄高速监控大厅，常规情况下，会由小模型做实时路侧监测。

如果小模型发现路上有车辆突然停下，会迅速把这个事件上报给大模型，然后交给大模型做进一步校验。

之所以需要大、小模型协作，是因为小模型可以快速从监控视频中抽好几百帧处理，做到实时的监测反馈，但它不能理解车辆复杂的连续运动，比如，堵车时，车辆走走停停，就会被小模型误判成“异常停车”。而大模型可以对完整的视频片段做语义理解，对事件的判断会更精准。

监控员确认执行后，智能体会自动发送情报板，联动养护、应急等部门推进处置流程。这个过程中，智能体会全程跟踪。

处理结束后，大模型还会自动生成事件处置报告，为后续同类工作提供有价值的参考。

出行的体验，除了安全高效，还希望多一些和家人共处的美好时光。

**今天，我们发布：**座舱大模型智能体。

它可以帮助车企打造更加智能、温暖的家庭出行体验。

在深蓝汽车S09这样的高端车型上，我们的座舱大模型智能体能为0到15岁的儿童和青少年提供一个专属学习娱乐空间。孩子可以在车里形成专属的绘本，进行情境化英语口语练习，还可以和虚拟卡通角色进行语音、视频互动。

我们也在和多家车企深化合作，研发面向不同用户群体的座舱智能解决方案，让每位家庭成员都能体会到出行的乐趣。

其实，科技的进步，归根结底都是为了让大家的生活更好一些。

而对于每个人来说，没有什么比健康更重要。

尤其是生病时，一定希望被快速接诊，尽快治疗。

过去，患者和医生见面前互相不了解，往往大专家都在看小病，真正有了疑难杂症又找不到大专家。好不容易挂了号，在门外排了半小时的队，进诊室之后，医生还要从头问一遍，“哪不舒适” “什么时候开始” “哪些病史”……

今天，我们发布：智慧就医智能体，它为这个场景提供新的解法。

通过自然语言对话，快速了解患者病情，生成结构化的电子病情卡。

在分导诊环节，医院可以为患者推荐合适的科室和医生；

在医院预约挂号环节，医生可以用它辅助审核加号申请；

在问诊阶段，医生也可以通过它快速了解患者病情，辅助生成病例，大幅提高接诊效率。

接下来，我们以“加号审核”场景为例，看看这个智能体在武汉协和医院的应用效果。

，时长00:51

打开武汉协和AI导诊的界面，点击“帮我预约”。

智能体会核对患者的身份，主动询问病情，确认就诊的目的。

患者可以上传自己的病历报告。智能体就能识别文本、图片这些多模态内容。

智能体会根据这些材料问一些问题。比如，它会追问肿块是不是增大，是不是呼吸困难，引导患者提供更多的病情信息。

最后，智能体汇总刚才全部的信息，自动生成病情卡。这时候点击“立即加号”以后，医生就可以收到病情卡、确认加号。

“绿水青山就是金山银山 ”。

环境保护是非常重要的工作，AI正在让生态环境的监测和治理变得可感、可行。

环境监测，要综合考虑大气、土壤、水温等方方面面，并不容易。单就水质监测来讲，国家级水质监测站将近2000多个，仅中国环境检测总站涉及水环境的业务系统，就有7个。要分析某一个地方的水污染情况，需要专人跨越好几个业务系统去翻查大量数据、统计分析，非常辛苦。

今天，我们发布：生态环境监测智能体。

它可以基于大小模型能力，实时监测水质**、大气****、土壤等多维数据，秒级生成环境质量分析报告，为****环保部门、相关企业提供参考。**

这个智能体，现在在中国环境检测总站落地。在多个场景下，现在回答准确率能超过95%。

我们来看一下。

，时长01:01

进入“生态环境监测智能助手”，

这个智能体打通了各级数据库，能够实时监测、分析全国环境质量。这时候我们可以下钻，问它具体月份的污染情况，或者让它做城市级别的环境分析。

如果监测到异常情况，端侧小模型会对冒泡点位标记预警，你可以追问点位的情况。

比如，你可以问它6月19日四个点位报警的原因，智能体就会结合小模型监测的PM值，推理出污染浓度变化趋势。如果继续追问污染的原因，它会结合附近站点的多维度数据，和周边地区的火点情况，推理出污染的原因。比如是前一天晚上当地的秸秆焚烧。

最后您可以让它生成一份报告，智能体内置了报告生成的标准工作流程，生成的报告质量还是很高的，过去一个团队甚至几个团队做的事，现在由一个智能体就能完成。

刚才一口气给大家介绍了好几个智能体，已经针对行业场景做了深度优化，内置了特定的大小模型、行业知识、行业标准流程和常用工具，对同行业的客户具有一定的通用性。

**今天，我把它们****作为百度智能云精选行业智能体家族推荐给大家。**感兴趣的伙伴只需要对它们做一些轻量定制，就可以把这些能力快速嵌入到自己的系统当中。

在我们和很多客户的实践中，“轻量定制”的行业智能体，正在成为大模型产业落地的捷径。

未来，我们还会沉淀更多的行业智能体，赋能更多的业务场景。

另外也有不少客户，在用过之后，希望进一步打造更贴合自身业务的智能体。这时候，就需要从轻量定制，走向系统化构建。这时候就要复杂一些。

我们面临三个问题，怎么开发、选什么模型、用什么算力。这也是百度智能云给大家提供的全栈能力，接下来我快速就开发平台、模型和算力三层给大家汇报一下最新的进展。

开发层有千帆平台，可以给大家提供一个智能体工厂，帮助大家快速开发智能体、构建智能体生态。

在千帆上，您可以：

• 直接使用百度提供的成熟的智能体， 比如刚才提到的行业智能体，以及像智能客服这样的通用智能体；

• 未来，您还可以通过A2A等协议，调用更多内外部的智能体，打通跨组织的业务流程；

• 您也可以开发自己的智能体，通过MCP等协议，连接企业内外部的服务，建设自己的超级智能体。

在智能体搭建过程中，为了提升智能体的效果，您可以在千帆上灵活的选择各种底层模型，还可以根据用户反馈来精调这些模型，不断提升智能体的用户体验，形成数据飞轮。

当然很多时候我们不仅需要在公有云上用智能体，还需要把智能体放在自己企业环境里面。我们也提供千帆私有化部署方式。大家第一反应，大模型快速发展，私有化部署怎么跟得上行业发展？其实这里的“私有化”更像是“私有化订阅制”：每当有新的模型、新的技术出来，我们会推送到您的企业系统上，让您的系统始终和行业保持同步、与前沿技术相连，变得可成长、可进化。

有出色的开发平台，还需要出色的模型。

今年4月我们发布了两个旗舰模型，一是文心4.5 Turbo，二是文心X1 Turbo推理模型。

文心4.5 Turbo的多模态理解效果比以往提高30%，在多个测试集上超越了OpenAI的最新模型GPT-4.1，价格只有GTP-4.1的6%、DeepSeek V3价格的40%。

接下来大家看一个演示，看一下多模态理解能力。

矿山里面作业人员驾驶掘进机的时候会出现视线盲区。误闯人员进来很危险，需要及时预警。

如图显示就是一个典型情况，上面有两位工人。第一个红框里，是一位正在驾驶掘进机的正常作业人员。第二个红框里，有一位工人出现在掘进机旁边，机器运行时没有及时避让，属于违规行为，算是“误闯”。

我们测一下文心。

，时长00:48

进入文心以后，选择4.5 Turbo。

然后提问：根据矿山作业安全要求，对图像进行分析，判断是否有作业人员误闯？

可以看到，文心首先识别出这是矿山作业场景。正确推理出左下角是误闯人员。而对于掘进机上面正常作业的人员，并没有预警。

这说明它理解了场景以及人和掘进机的关系，体现了强大的多模态理解能力。

另外就是文心****X1 Turbo，是推理模型里面的代表，价格只有DS R1的四分之一。

我们来看下它的效果。

这次我们选一个预算管控的场景。因为涉及到多个部门的大量数据，财务人员做一次分析往往需要花半天的时间。

大屏幕上展示的，是一家制造业公司5月份五个部门的成本预算数据。每张表中，都列出了各类费用的预算金额和实际支出。现在，我们要对比两组数据，找出偏差值超过正负3%的费用项。花超了，成本会失控；花少了，说明资源没用到位。都要及时改进。

我们看文心X1 Turbo，能不能快速完成这个任务。

，时长00:42

首先进入文心一言，选择X1 Turbo。

我们先把刚才的表格上传上去。

我们告诉文心，根据附件，帮助完成5月份公司成本预算管理分析。要找到差值超过3%的费用项，并结合同类企业的经营情况，给出总结报告。

可以看到X1 Turbo在理解任务后，开始做任务拆解；利用代码解释器，计算各部门差异率，汇总差额超过3%的费用项；接着还调用联网搜索工具，找同类企业经营情况。找完之后，再给出预算管理优化意见；最后会汇总结果，生成报告。

我们打开看一下这个报告。

它已经找出了所有差异率超过3%的所有费用项，比如，行政部的租赁费超了9.9%。

然后它会结合搜索的情况，推理出：要控制租赁费，需要关注市场的租金波动，提前谈续租条款。

最后，它建议行政部门建立租赁费预警机制，定期评估办公地点的利用率。可以说，大模型数据准确，条理清晰，很快完成我们的目标。

今天，大模型技术还在快速迭代，百度也会继续投入，不断去把模型的效果做得更强。

即使在这种情况下，我们在和客户一块合作时，发现通用模型到了真正具体的场景，还是达不到预期。

拿金融行业来说，金融对大模型的要求非常高：知识面广、时效性强，而且对大模型准确率和幻觉率都有非常严格的要求。通用模型因为缺乏专门金融语料的训练，很难精准回答，通常会出现幻觉。

更重要的是，真正有价值的金融数据，大多掌握在金融机构手里。金融机构这时候如果要来拿这些数据做精调，面临两个问题，一般大模型参数规模比较大，精调成本比较高；精调完了，而且部署成本也很高。

这时候行业大模型就很值得关注。

大模型厂商基于行业语料做“懂业务、更专业”的行业大模型。通常这种模型，在参数比较小的情况，可以达到更大参数规模通用模型的效果。

企业可以在参数相对小的模型上定制，提高效果、降低成本。

今天，我们以金融行业为试点，正式推出千帆金融行业大模型，叫千帆慧****金！

我们在通用模型的基础之上，收集了大量的研报、财报及专业的书籍，对这些海量的金融数据进行清洗、挖掘，整理出数百亿tokens高质量金融领域语料，同时做了指令对齐、知识增强、训练、推理等一系列优化，打造千帆慧金金融知识增强大模型

一般模型分知识模型和推理模型。提高了金融知识模型以后，我们还针对行业复杂计算任务进一步优化思维链路，研发了千帆慧金金融推理增强大模型。

不管是知识模型，还是推理模型，都提供了两个版本，8B版本响应快、易部署，适用于意图识别、指标抽取等对速度要求高、任务相对明确的场景。70B大参数版本更适合处理投研辅助、策略分这样的复杂推理、多轮任务规划的问题。

每个模型上都可以支持32K的窗口，满足绝大多数的场景。

可以看到，在金融领域几个常用的评测集上，增强后的两个模型都已经超过了参数比它大很多的行业模型、通用模型效果。

千帆慧金是针对金融行业的，感兴趣的客户可以上千帆试一下。

这只是一个起点，也是我们在行业探索的经验。我们还会根据行业的需求，不断推出更多垂直行业场景的模型。

现在，千帆提供超过****100个模型服务，**大家可以根据自己的需要灵活的选择。**

刚才讲了，为了做出好的智能体、好的应用，需要好的开发工具，好的模型。最后还有一个很关键的问题，就是算力。我们都知道，当下我们面临非常严峻的算力挑战。

好在过去几年中国半导体产业走的虽然很不容易，但是还是取得不少的进展。百度很荣幸参与其中，也做出了一些贡献。

我简单给大家汇报我们的芯片昆仑芯的进展。

昆仑芯P800是一款真正意义上为大模型而设计的芯片，它采用了完全由昆仑芯自研的XPU-P架构，显存远超同类芯片。CUDA上能跑的大模型，P800都可以跑，迁移成本非常低。

今年****2月，我们点亮了P800的万卡集群，4月点亮了3万卡。在这么大的规模上采用昆仑芯P800和海光CPU这样的全国产方案，属于国内首个。

现在，国家电网、中国钢研、招商银行，以及北大、同济等高校和互联网企业已经开始规模部署P800。

昆仑芯不仅性能强大，还有很强的扩展能力。

4月，我们在武汉发布了昆仑芯超节点，就是把64张AI加速卡塞进一个机柜。这一台机柜的算力，相当于过去上百台服务器。这样一个超节点最大的优势是各种机房环境下都可以部署。即便是传统的风冷机房也可以直接部署，不用做太多的基础改造，其它超机必须搞成液冷环境才能使用。

AI芯片非常敏感，随着集群规模扩展，故障率一定会快速增长，对于整个业务影响是指数级的。这就要求，在硬件之上，还必须有一层好的软件管理系统，保证集群的稳定运行。

百舸，是我们推出一款GPU算力管理平台，可以对所有的底层硬件进行统一的纳管、调度，在超大规模节点上有效训练时长也可以超过95%。

这些能力已经在一些客户、伙伴中真正跑起来了。

比如说南方电网。在实际部署测试中，国产昆仑芯P800性能表现不错，帮助客户在大模型训练上显著降低了成本。结合百舸的工程经验，训练性能达到行业领先水平。

当然，算力平台的价值不只是性能，更重要的是灵活。出于供应链的稳定性和弹性的考虑，大多数客户不会只绑定单一芯片，会考虑一云多芯。

百舸适配多款国内外主流芯片，满足中国企业在不同算力架构下的部署需求。

百舸不仅向下兼容各种芯片、屏蔽底层差异，向上也适配了各种主流的大模型框架，支持包括DeepSeek在内的国产开源模型的训练和推理。

使用百舸**+昆仑芯方案，单卡吞吐性能相比国内主流芯片方案可以高出90%；大规模、高并发模型推理速度可以提高****40%+。**

我们和长安共建的长安汽车智算中心，依靠百舸平台以及客户自研的“星环平台”。集群平均算力使用率可以到90%；综合资源利用率提升50%。

我们希望，百舸能为更多的中国企业提供稳定可靠的国产算力支撑，让大家放心使用国产芯片、跑国产模型！

这就是百度智能云人工智能全栈基础设施。

现在，这套覆盖算力、模型开发、应用开发、数据管理的一整套系统化服务，已经服务了****65%的央企客户和广大企业的AI创新。

有人说，“想象未来最好的方式就是去创造它。”

模型能力和工程能力的持续进化、算力成本的不断降低，会为企业打开想象空间，让很多原来做不了的事儿变得可行，从“不可能”变成“可能”。

大屏幕展示的，是我们正在和客户、伙伴共创、共建的重点场景。这不是一张规划图，是一张行动图。每一个场景背后，都是正在推进的AI实践，是大模型走进产业的中国经验。

这是一场长期的接力。我们会坚定投入，打造更先进、高效的人工智能基础设施，服务更多的中国企业，加快推动大模型产业化发展，释放更多场景价值。

导读

BaikalDB作为服务百度商业产品的分布式存储系统，支撑了整个广告库海量物料的存储和OLTP事务处理。随着数据不断增长，离线计算时效性和资源需求压力突显，基于同一份数据进行OLAP处理也更为经济便捷，BaikalDB如何在OLTP系统内实现适合大数据分析场景的查询引擎以应对挑战？

01 BaikalDB应对OLAP场景的挑战

BaikalDB是面向百度商业产品系统的需求而设计的分布式存储系统，过去多年把商业内部几十套存储系统全部统一到BaikalDB，解决了异构存储带来的各种问题，支撑了整个广告库的海量物料存储和复杂的业务查询。BaikalDB核心特点包括：

• 兼容mysql协议，支持分布式事务：基于Raft协议实现三副本强一致性，通过两阶段提交协议保障跨节点事务的原子性与持久性‌。

• 丰富检索能力：不仅支持传统的结构化索引、全文索引等，为解决LLM应用的向量需求，BaikalDB通过内置向量索引方式实现向量数据的存储和检索，一套系统支持结构化检索、全文检索、向量检索等丰富的检索能力，综合满足LLM应用的各种记忆存储和检索需求。

• 高可用，弹性扩展：支持自动扩缩容和数据均衡，支持自动故障恢复和迁移，无单点。当前管理数千业务表与数十万亿行数据，日均处理百亿级请求‌。

△BaikalDB架构

随着业务发展，离线分析难以满足诉求，实时多维分析需求对BaikalDB大数据处理能力的要求显著提高。BaikalDB的查询引擎主要面向OLTP（联机事务处理）场景设计的，以下双重关键瓶颈使其应对OLAP （联机分析处理）有很大的挑战：

1. 计算性能瓶颈：传统火山模型使用行存结构破坏缓存局部性、逐行虚函数调用风暴频繁中断指令流水线、单调用链阻塞多核并行扩展等等弊端，导致大数据分析性能呈超线性劣化。

2. 计算资源瓶颈：Baikaldb单节点计算资源有限，面对大规模数据计算，单节点CPU、内存使用容易超限。

BaikalDB从OLTP向HTAP（混合事务/分析处理）架构演进亟需解决当前OLTP查询架构在面向大规模数据的计算性能瓶颈、计算资源瓶颈，并通过如向量化查询引擎、MPP多机并行查询、列式存储等技术手段优化OLAP场景查询性能。

02 BaikalDB OLAP查询引擎的目标

2.1 向量化查询引擎：解决OLTP查询引擎性能瓶颈

2.1.1 火山模型性能瓶颈

设计之初，由于BaikalDB主要面向OLTP场景，故而BaikalDB查询引擎是基于传统的火山模型而实现。

如下图所示，在火山模型里，SQL的每个算子会抽象为一个Operator Node，整个SQL执行计划构建一个Operator Node树，执行方式就是从根节点到叶子节点自上而下不断递归调用next()函数获取一批数据进行计算处理。 由于火山模型简单易用，每个算子独立实现，不用关心其他算子逻辑等优点，使得火山模型非常适合OLTP场景。

△select id, name, age, (age - 30) * 50 as bonus from peope where age > 30 火山模型执行计划

但当火山模型处理大量数据时有着以下三大弊端，这些弊端是导致火山模型面对大数据量分析场景查询性能差的元凶。

1. 行式存储引发的缓存失效问题‌

   1. 数据局部性缺失‌：行式存储（Row-based Storage）将整行数据连续存放，当查询仅需部分列时，系统被迫加载整行冗余数据，容易造成Cache Miss。

   2. 硬件资源浪费‌：现代CPU三级缓存容量有限，行存结构导致有效数据密度降低。

2. 逐行处理机制的性能衰减‌

   1. ‌函数调用过载‌：火山模型要求每个算子逐行调用 next() 接口，处理百万级数据时产生百万次函数调用。

   2. ‌CPU流水线中断‌：频繁的上下文切换导致CPU分支预测失败率升高。

3. 执行模型的多核适配缺陷

   1. 流水线阻塞‌：Pull-based模型依赖自顶向下的单调用链，无法并行执行相邻算子。

   2. ‌资源闲置浪费‌：现代服务器普遍具备64核以上计算能力，单调用链无法充分利用多核能力。

当查询模式从OLTP轻量操作转向OLAP海量扫描复杂计算时，上述三个弊端导致的查询性能衰减呈现级联放大效应。虽然能做一些如batch计算，算子内多线程计算等优化，但并不能解决根本问题，获得的收益也有限。BaikalDB寻求从根本上解决瓶颈的方法，探寻新架构方案以突破性能瓶颈！

2.1.2 向量化查询引擎

多核时代下的现代数据库执行引擎，发展出了向量化查询引擎，解决上述火山模型的种种弊端，以支持OLAP大数据量查询性能。与火山模型弊端一一对应，向量化执行引擎特点是如下：

1. 列式存储与硬件加速协同优化‌

   1. 列存数据紧凑布局‌：采用列式存储结构（Colum-based Storage），将同类型数据连续存储于内存，有效提升CPU缓存行利用率，减少Memory Stall。

   2. ‌SIMD指令集加速‌：通过向量寄存器批量处理128/256/512位宽度的连续数据单元，允许CPU在单个指令周期内对多组数据进行相同的操作。

2. 批量处理提升缓存亲和性

   1. ‌数据访问模式优化‌：算子/计算函数内部采用批量处理机制，每次处理一批连续数据块。这种连续内存访问模式提升了 CPU DCache 和ICache 的友好性，减少 Cache Miss。

   2. 流水线气泡消除‌：批处理大量减少上下文切换，降低CPU资源空闲周期占比，显著提升流水线吞吐量‌。

3. 多核并行计算架构创新

   1. Morsel-Driven Parallelism范式‌：将Scan输入的数据划分为多个数据块（称为morsel），morsel作为计算调度的最小单位，能均匀分发给多个CPU core并行处理。

   2. Push-based流水线重构‌：颠覆传统Pull模型，通过工作线程主动推送数据块至下游算子（算子树中的父节点），消除线程间等待开销。数据驱动执行，将算子树切分成多个线性的Pipeline，多Pipeline之间能并行计算。

△向量化执行引擎pipeline并行计算

2.2 MPP多机并行计算的启发：进一步提升OLAP查询性能

向量化执行引擎在OLAP场景有大幅度的性能提升，却仍然无法解决单台计算节点的CPU和内存受限的问题，同时随着处理数据量增大，单节点执行时间呈指数级增长。

为了打破这一单点限制，进一步提升OLAP查询性能，MPP（Massively Parallel Processing）大规模并行计算应运而生，其核心特点有：

1. ****分布式计算架构：****基于哈希、范围等策略将数据分布到不同计算节点，实现并行计算加速，能显著缩短SQL响应时间。

2. ****线性扩展：****各计算节点采用无共享架构，通过高速网络实现跨节点数据交换，天然具备横向扩展能力，可通过增加节点线性提升整体吞吐量‌。

△MPP: 3台计算节点并行计算

03 BaikalDB HTAP查询架构落地

3.1 巧妙结合Arrow Acero实现向量化查询引擎

BaikalDB团队在向量化执行引擎设计过程中，秉持"避免重复造轮子"的技术理念，优先探索开源生态的优秀解决方案‌。基于BaikalDB已采用Apache Arrow列式存储格式实现全文索引的技术积淀‌，团队发现Arrow项目最新推出的Acero流式执行引擎子项目展现出三大核心功能：①支持Arrow列式存储格式向量化计算，支持SIMD加速；②Push-Based流式执行框架支持Pipeline并行计算，能充分利用多核能力；③执行框架可扩展——这些特性与BaikalDB对向量化执行引擎的需求高度契合‌。最终团队选择基于Arrow列存格式和Acero流式计算引擎实现BaikalDB向量化执行引擎，不仅大幅度缩短了研发周期，更充分发挥了开源技术生态的协同优势‌。

BaikalDB巧妙结合开源Apache Arrow列存格式和Arrow Acero向量化执行引擎，通过将火山模型计划翻译为Acero执行计划，全程使用Arrow列存格式，计算最终列存结果再列转行返回给用户，在BaikalDB内部实现了适合大量数据计算的向量化查询架构。

核心实现包括以下五点：

1. 数据格式：将源头RocksDB扫描出来的行存数据直接转为Arrow列存格式，SQL计算全程使用Arrow列存，最终将列存格式的计算结果再转换成行存输出给用户。

2. 计算函数：将所有BaikalDB计算函数翻译成Arrow Compute Expression，每个Arrow计算函数运行一次处理万行数据，同时能支持部分如AVX2、SSE42等SIMD指令集，支持SIMD加速。

3. 执行计划：将每个SQL生成的BaikalDB原生执行计划，转换成一个Acero执行计划Exec Plan（包含所有BaikalDB算子翻译成的Acero ExecNode Declaration树），使用Acero向量化执行引擎替换火山模型执行。

4. 调度器：将进行数据扫描SourceNode的IO Executor和计算的CPU Executor独立开。

   1. 每个Baikaldb和BaikalStore实例内置一个全局的Pthread CPU IO Executor池，支持计算阶段的Push-based Pipeline并行计算，同时支持算子内并行计算，如Agg并发聚合、Join并发Build/Probe等。

   2. 每个SourceNode都独自一个Bthread IO Executor，支持Hash Join或Union的各个子节点能并发查表。

5. RPC接口：Baikaldb和BaikalStore之间RPC使用Arrow列存格式替换行存pb格式进行数据传输，大幅度降低传输数据大小，同时去掉了pb序列化和反序列化的开销，加速了数据传输效率。

△BaikalDB火山模型（左） BaikalDB向量化引擎（中：Index Lookup HashJoin，右：HashJoin）

3.2 拆解执行计划实现MPP多机并行查询引擎

BaikalDB实现了向量化执行引擎后，大部分OLAP请求性能得到大幅度提升，但很快就遇到了受限于单计算节点资源和性能的case。团队首先对业务场景进行了分析，发现资源/性能卡点主要在集中在最后单点Agg/Join的计算上。

为了破除这一单点限制，因Agg/Join都依赖内部HashTable进行计算，很容易想到按照HashKey将源数据hash shuffle到不同的计算节点进行并行计算来加速计算性能，平摊计算需要的内存和CPU资源，每个计算节点依然可以使用向量化执行引擎加速单机计算性能。如下图所示，这一方案需要解决的核心问题有以下两点：

1. 实现Exchange算子对进行跨节点数据Shuffle。

2. 在执行计划合适的地方的插入Exchange算子对拆分为多个并行子计划Fragment。

△BaikalDB Agg Mpp执行示例

△BaikalDB Hash Join Mpp执行示例

3.2.1  Exchange算子跨节点数据shuffle

Exchange算子包括ExchangeSenderNode/ExchangeReceiverNode算子对，必须成对出现，进行跨节点数据分发和接收。ExchangeReceiverNode核心功能主要是接收对应的下游Fragment所有ExchangeSenderNode发来的数据，需保证不重不丢，进行超时处理等。ExchangeSenderNode核心功能是进行数据分发，其分发模式主要有以下三种，以支持不同的场景需求。

1. SinglePartition：一个或者多个ExchangeSenderNode将所有数据直接完整发送到单个上游Fragment ExchangeReciverNode实例，使用场景如Fragment 0单个计算节点收集最终结果输出给用户。

2. HashPartition：ExchangeSenderNode将所有数据都先根据指定HashKey计算每一行hash值，根据hash值将每行数据re-partition到不同的发送队列里，最终发送到上游Fragment多个ExchangeReceiverNode，使用场景如Store Fragment将rocksdb扫描出来的数据shuffle到上游多个实例进行Agg/HashJoin计算。

3. BroadcastPartition：ExchangeSenderNode将所有数据都直接完整发送到多个上游ExchangeReciverNode，使用场景如Join小表数据直接完整发送到上游多个实例进行BroadcastJoin。

△BaikalDB Exchange算子实现（HashPartition）

3.2.2  执行计划拆解多个并行子计划Fragment

在插入Exchange算子对之前，需要给物理执行计划里的每个算子明确其分区属性PartitionProperty，标志着该算子是否可以分发到多个计算节点进行并行加速。PartitionProperty主要有三种：

1. AnyParitition：该节点没有任何要求，如FilterNode，可以根据相邻节点分区属性情况单节点或多节点执行。

2. SinglePartition：该节点必须要在单个计算节点上执行，如用于将最终数据打包发送给用户的PacketNode。

3. HashPartition：该节点可以按照指定key将数据分发到多个计算节点上并行执行，当前只有AggNode和JoinNode会产生HashPartition。

如下图所示，明确了每个算子的分区属性后，需要加入Exchange算子对的位置就很清晰明了了：分区属性有冲突的相邻算子之间。

在物理计划中插入了Exchange算子对后，在一对ExchangeSenderNode/ExchangeReceiverNode之间进行拆解，即可以将单个物理执行计划拆分为多个子执行计划Fragment。单机执行的Fragment在本机执行，多机执行的Fragment发送给多个同集群其他计算节点进行异步执行，store fragment根据表数据分布情况分发给BaikalStore存储集群并行执行。

在MPP物理计划制定过程中，为了减少数据shuffle的开销，尽可能减少SQL shuffle数据量，BaikalDB也实现了多种查询计划优化手段，如limit下推、hash partition fragment合并等等。

△MPP物理计划制定过程

3.3  自适应策略支持一套系统应对TP/AP请求

BaikalDB设计HTAP架构的核心目标是一套系统能同时兼容OLTP和OLAP请求，无需业务进行任何改造，这需要系统拥有极强的兼容性。

目前BaikalDB内部有三种执行方式：火山模型、单机向量化执行引擎、MPP多机执行引擎，不同的执行引擎适用不同数据量级的SQL。随着数据量大小从小到大，适合的计算引擎是火山模型执行 → 单机向量化执行 → MPP多机并行执行，原因有以下两点：

1. 火山模型执行对比向量化执行更为轻量，导致在OLTP小请求（如SQL涉及数据行数<1024）方面，传统火山模型性能比单机向量化执行性能更好。

2. MPP执行会带来额外的网络开销（数据shuffle）、CPU开销（hash计算和re-partition），导致Baikaldb处理数据量需要超过一定阈值时，Baikaldb多机并行执行才能cover额外的网络/CPU开销，SQL性能才能提升，否则单机向量化执行是性能最优。

BaikalDB实现了智能执行引擎决策系统，支持SQL自适应选择合适的执行引擎，支持一套集群能同时满足业务OLTP和OLAP场景需求。技术实现包含两大核心机制：

1. 向量化引擎动态热切换：BaikalDB支持SQL在执行过程中，随着数据量增大，从火山模型动态切换到向量化执行引擎执行。

2. 统计信息驱动MPP加速：BaikalDB支持根据过去执行统计信息决策是否走MPP加速执行，当SQL统计的99分位处理数据行数/大小超过指定的阈值，则SQL直接通过MPP多机并行执行。

04  总结

4.1 项目收益

BaikalDB通过架构创新打造了HTAP架构，期望一套系统支持线上OLTP/OLAP请求，其技术演进路径呈现『混合执行引擎架构自适应选择』的特征：SQL自适应选择火山模型、向量化执行引擎、MPP多机并行执行引擎。

目前BaikalDB HTAP架构已经应用到线上多个业务，大数据量查询取得大幅度的性能提升，同时Baikaldb单点内存使用峰值也得以大幅度下降：

• 单机向量化执行相对于火山模型执行，大数据量查询请求耗时平均下降62%，最大能下降97%（如11s优化到300ms），内存使用峰值最大能降低56%（57G->25G）。

• MPP在单机向量化执行基础上，大数据量查询耗时还能进一步优化，查询耗时平均下降54%，最大能下降71%（如42s优化到12s），内存使用峰值最大能降低80%（5 hash partition）。

4.2 未来展望

BaikalDB HTAP架构目前还在不断发展，包括性能优化、丰富支持算子和计算函数等等，未来还预期结合列式存储、CBO等技术进一步提升OLAP场景性能：

• 结合列式存储提升数据扫描性能：目前BaikalDB向量化查询引擎和MPP查询引擎全程基于Arrow列存格式，但是底层数据存储仍然是行存，存在一次行转列的开销；并且OLAP场景，更适合使用列存格式作为底层数据存储格式。BaikalDB当前在发展列存引擎，未来单机向量化和MPP能直接基于底层列式存储，进一步提升OLAP场景查询性能。

• 结合CBO（Cost-Based Optimization）优化自适应MPP选择策略：当前BaikalDB是基于过去的执行统计信息判断SQL是否适合走MPP，当SQL过去执行统计信息波动巨大时，自适应判断方法可能会失效，未来可能结合代价模型来进一步优化MPP选择策略。

在数据库的运维工作中，DBA 应该选择哪一种方案，确保 Redis 数据库崩溃后可以对数据进行回档，恢复业务运行？

一般情况下，DBA 可以通过 Redis 原生的持久化机制，如 RDB 快照持久化或者 AOF 日志持久化的方案来进行数据存档。在业务发生问题后，利用 RDB 或者 AOF 存档文件进行数据恢复。这两种方案均可以满足大部分业务场景的需求。

然而，在游戏、电商等场景中，数据库发生故障后需要能够精准、快速的恢复业务，原生的 RDB 或 AOF 方案则难以满足要求，如：

• RDB 无法恢复至任意时间点。RDB 定期生成全量快照（如每小时一次）保存数据，但两次快照之间的数据变更会丢失。例如：如果在 10:00 和 11:00 各有一个 RDB 快照，但故障发生在 10:30，则只能恢复到 10:00 的状态，丢失 30 分钟的数据。
• AOF 文件大恢复速度慢。AOF 会记录所有指令的操作，可以实现指定时间点的恢复，但数据量大存储成本高，导致恢复时间远超基于 RDB 的恢复方式。例如：如果 AOF 记录了从 10:00 和 11:00 的所有指令操作，故障发生在 10:35:15，在数据恢复中 Redis 将执行从 10:00:00 到 10:35:15 的全部数据写操作。

01 百度智能云 Redis 数据恢复方案

百度智能云数据库 Redis 推出的「数据闪回」功能，相比基于 Redis 原生的 RDB 或者 AOF 的恢复方法，「数据闪回」可以使用更小的存储空间，快速地将业务数据恢复到任意指定时间点。

「数据闪回」基于 RDB 和 AOF 的混合持久化方式，使得较少存储空间就能保留完整的数据备份，并为 AOF 新增时间戳，方便快速找到指定时间点的文件。这使得「数据闪回」能满足从小时级到秒级不同场景的数据恢复需求。

1.1 基于 RDB 和 AOF 的混合持久化方式，保留完整的数据备份

百度智能云 Redis 通过采用 RDB + AOF 混合存储的方式，解决了传统 AOF 方案带来的由于日志数量多、导致数据恢复慢的问题。

• RDB 提供基础的数据快照，用于快速恢复到一个基准时间点（例如每天凌晨的备份）。
• AOF 提供增量的操作日志，记录 RDB 基准时间点之后的所有写命令，实现命令级别的数据恢复能力。

开启 AOF 后系统默认记录一周之内的全部命令，到期后系统将自动清除过期的 AOF 文件，自动开始进入新一轮的 RDB 快照 + AOF 记录的周期。

1.2 新增 AOF 内置时间戳

原生 Redis 的 AOF 文件会记录全部的写命令，但是并没有给这些命令配置时间信息，导致系统无法快速找到指定时间点的文件，使得数据恢复效率受限。

为了解决这一问题，百度智能云 Redis 内核团队按照 Redis 协议设计了百度版本的新的协议。该协议新增 op-header 字段，即为每个 Redis 指令增加了时间戳，使得 Redis 具备按照时间点来快速找到文件的能力。

1.3 数据恢复过程

当用户提出回档需求并指定时间点后，百度智能云的 Redis 将启动数据恢复流程。

首先，平台会克隆出一个与原集群配置完全相同的空 Redis 集群。

随后，系统依据原集群的分片规则和用户指定的时间点，精准定位对应的 RDB 文件与 AOF 文件，将这两类文件加载至 Redis 内存，完成整个数据恢复操作，使Redis 集群状态精准还原至用户指定的时间节点。

02 总结

在当今数字化时代，数据的价值不言而喻，而数据恢复能力更是企业业务连续性的关键保障。百度智能云数据库 Redis 的「数据闪回」功能，为 Redis 数据恢复提供了一种创新且高效的解决方案。它不仅解决了传统 RDB 和 AOF 方案的局限性，还通过混合持久化和时间戳技术，实现了秒级精度的任意时间点数据恢复。

随着互联业务的发展、业务逐渐的复杂，传统代码架构在日常开发中存在的多种弊端，如代码混乱、补丁式开发、迭代成本高等问题，大大影响了迭代的效率。本文作者借助 DDD 的战略设计和战术设计，介绍了如何通过限界上下文、领域模型、聚合、资源库等概念，实现业务逻辑与技术的解耦，提升代码的可维护性、扩展性和稳定性。同时，文章作者结合团队在落地DDD时，遇到的卡点、痛点，创新性的提出一种 DDD 的分层实践，并在实际开发中取得了较好的效果

01 背景

不知不觉从事To B业务已经3年，笔者在工作中看了很多、也写了很多的代码，由此也产生很多的思考和感悟：在日常的工作中，我们的主要矛盾在于日渐复杂、动态变化的业务诉求与有限的人力之间的矛盾。而为了解决这一矛盾，我们要尽可能的保证代码的优雅。

但是传统的代码设计，如：面条式代码架构、基于面向对象+MVC的代码架构，大部分无法保证在日趋复杂的业务中以优雅的代码架构持续发展。一旦迭代时间拉长，这类代码往往会或多或少地表现出以下特征：

1. 代码组织混乱（数据的获取随意、业务逻辑与数据逻辑纠缠、结构随意）;

2. 业务逻辑透传数据数据库（业务逻辑层层透传到数据库层）;

3. 隐式代码逻辑横行（业务代码到处散落、对象的初始化通过隐式init）。

笔者在这里画一下这套代码的逻辑组织结构：

具体来分析，笔者认为主要存在以下几种问题：

1. 稳定性&性能低下：由于代码组织结构的混乱，导致开发模式变成了打补丁，迭代方式变成了在原有的代码基础上继续填充if else、或者新开辟一个func用于实现本次新加的代码逻辑。这往往会导致重复数据的获取、重复的数据校验、重复的对象创建.....，从而导致性能的大幅下降。

2. 代码复杂程度高

a.补丁式的开发模式:

i. 由于补丁的开发，数据的获取随意从而导致代码的复用性降低，毕竟每同学在开发时，如果不全盘梳理代码已无法抽取合理的公共代码逻辑。而新添加的代码又会成为下一个同学的开发负担，从而导致_代码一直处于恶性循环，从而导致复杂度一直增长*。笔者就见过一些超过1500行的函数，这些函数除了重新推倒重来基本无迭代的可能性，因此我们应该尽可能避免这种情况发生。除了以上问题，补丁式的开发缺少统一的规划，*圈复杂度的急剧上升也是代码复杂度上升_的一个重要原因。

b. 代码组织混乱:

i. 数据获取随意:由于没有统一的代码格式层级,数据的获取散列在整个代码的各处、赋值修改亦如此,导致数据污染。

ii.据获取通过Map结构：笔者见过一些代码通过Map获取数据，后续的开发的同学必须不仅要关注这个map的成员、还要关注Map中每个成员的生命周期是否有过修改、更新，迭代过程中十分痛苦。

iii .....

c. 隐式的业务逻辑:

i.代码只体现对数据修改、更新,而没有显示注明业务逻辑。

d. 业务逻辑透传数据数据库:

i. 笔者见过一些代码,请求的参数直接从api透传到dao层,导致对这段代码进行扩展十分困难。

3. 迭代成本高:由于代码复杂度过高,导致迭代复杂度同比增加。

从实际工作中来看，一旦代码选择这种架构，便只能沿着混乱继续一路狂奔，从而无法挽回直到业务无法忍受技术的短板，选择进行重构！笔者在这里截取一些代码片段，作为示例：

△map获取

△超长代码

02 那什么才是好的代码架构？优雅的结构？

从笔者的工作经验来看，好的代码结构一般具有以下几种特点：

1. 代码的可扩展性：好的代码架构帮助代码开发人员将业务与技术解耦，增加代码的扩展性;

2. 代码的可维护性：好的代码架构能将业务和依赖进行解耦，增加代码的可维护性；同时好的代码架构可以降低代码和文档的腐化程度;

3. 代码复用性高、可测试性强：代码架构有助于提升代码的复用性、可测试性;

锦上添花:

4. 系统稳定性高:好的代码架构有助于提升系统的稳定性。

很高兴的事情是DDD是从一种更高纬度的设计思想去思考问题，他以业务驱动为核心，从稳定性的角度去构建代码结构。某种意义而言，DDD也许是一种更巧妙的解决方案，帮助我们去构建更优雅的结构，从一定维度上减缓项目代码的腐化。

03 什么是领域驱动设计

DDD是一种围绕领域建模来解决复杂业务交付的设计思想。

1. 什么是复杂？如何理解复杂？

• 复杂可能是现状业务就复杂，也可能是业务日渐演变成复杂。复杂来自规模在变，比如几个业务对象的逻辑不复杂，几十上百个业务对象就会变得错综复杂;

• 复杂来自结构化不足，例如结构化的中国结比非结构化的意大利面更有序、易于大脑理解。此外，如何协同不同团队完成软件交付也是一种复杂。

2. 什么是领域建模？

• 领域模型跟技术毫无关系，而是为了更有结构化的拆解和表达业务逻辑。业务逻辑来自现实世界里的具体场景，涉及可视画面、操作动作和流程。要准确表达业务逻辑需要先讲清楚每个概念是什么，再建立概念之间的联系，基于这些关系再组合出更多的流程;

• 概念、联系、流程就是领域模型。围绕领域模型去表达业务时也自然而然地把技术实现细节分离出去了。后续代码实现就是将业务架构映射到系统架构的过程，以后业务架构调整了能快速的调整技术架构。

3. DDD用哪些领域概念表达业务？

• 表示业务逻辑的是：实体、值对象、领域服务、领域事件。这意味着所有领域逻辑都应该在这四种对象里，统一称为领域模型对象，这将极大_减少业务逻辑的蔓延;_

• 引入聚合进一步封装实体和值对象，让领域逻辑更内聚，起到边界保护的作用。聚合的引入使得业务对象间的关联变少。如何设计聚合见下面实践部分;

• 围绕聚合的操作引入工厂和资源库。工厂负责复杂聚合的创建，资源库负责聚合的加载、添加、修改、删除。聚合内的实体状态变更通过领域事件来推动;

• 应用服务处于应用层，对领域逻辑编排、封装之后对上层接口层暴露。一次编排就是一个用户用例。

04 领域驱动设计如何解决问题

DDD 包括战略设计和战术设计两部分。

• 战略设计：主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。

• 战术设计：从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。

4.1 战略设计：分割你的设计，以免无法控制

4.1.1 Bounded Context（限界上下文）

限界上下文是围绕应用程序和/或项目部分的概念边界，涉及业务领域、团队和代码。它将相关组件和概念分组，避免歧义，因为其中一些可能在没有明确上下文的情况下具有相似的含义。

• 比如电商领域的商品，商品在不同的阶段有不同的术语，在销售阶段是商品，而在运输阶段则变成了货物。同样的一个东西，由于业务领域的不同，赋予了这些术语不同的涵义和职责边界，这个边界就可能会成为未来微服务设计的边界。领域边界就是通过限界上下文来定义的。

• 比如财务领域、审核领域。DDD里的限界上下文（Bouded Context）是对广告领域的软件实现，比如钱包体系、账户体系就是财务领域内的限界上下文。

• 限界上下文定义了解决方案的明显边界，边界里的每一个领域概念，包括领域概念内的属性和行为都有特殊含义。出了限界上下文这个边界这层含义就不复存在。

• 如何划分限界上下文？

1. 根据相关性做归类。一般是优先考虑功能相关性而不是语义相关性，比如创建订单和支付订单都是订单语义，但功能相差比较大，应该划分为两个限界上下文。

2. 根据团队粒度做裁剪、根据技术特点做裁剪。一些通用的技术功能应该尽可能归拢到一个限界上下文，比如每个业务限界上下文都有监控，但监控能力应该归拢到监控限界上下文。

4.1.2 Context Mapping（上下文映射）

识别并以图形方式记录项目中的每个限界上下文称为上下文映射。上下文映射有助于更好地理解有界上下文和团队如何相互关联和沟通。它们给出了实际边界的清晰概念，并帮助团队直观地描述系统设计的概念细分。

受限上下文之间的关系可能会有所不同，这取决于设计要求和其他特定于项目的约束，本文将省略某些关系，但以下四种关系除外：

4.1.3 Anti-corruption Layer（防腐层）:

下游限界上下文实现了一个转换来自上游上下文的数据或对象的层，确保它支持内部模型。

4.1.4 Conformist（跟随者关系）:

下游有界上下文符合并适应上游上下文，如果需要，必须进行更改。在这种情况下，上游环境对满足下游需求不关心。

4.1.5 Customer/Supplier（客户/供应商关系）:

上游向下游提供服务，下游上下文充当客户，确定需求并向上游请求更改以满足其需求。

4.1.6 Shared Kernel（共享内核）:

有时，两个（或更多）上下文不可避免地重叠，最终共享资源或组件。这种关系要求两个上下文在需要更改时保持连续同步，因此如果可能的话应该避免。

4.2 战术设计:DDD的螺母和螺栓

4.2.1 Entity（实体）

具有唯一标识并具有连续性的对象称为实体，它们不仅仅由属性定义，更多地由它们是谁定义。

它们的属性可能会发生变异，它们的生命周期可能会发生剧烈变化，但它们的身份依然存在。身份通过唯一密钥或保证唯一的属性组合来维护。

例如，在电子商务领域，订单有一个唯一的标识符，它经历几个不同的阶段：打开、确认、发货和其他，因此它被视为领域实体。

重点关注：Entity最重要的设计原则是保证实体的不变性（Invariants），也就是说要确保无论外部怎么操作，一个实体内部的属性都不能出现相互冲突，状态不一致的情况。

这里给出一些总结的规范：

1. 创建一致性 ，实体的创建尽量通过Factory或者规约进行创建;

2. 在代码实践中，尽量保证实体的创建唯一性（避免过多的创建实体的方法）。

3. 实体的属性尽量使用小写，避免外部直接对属性的操作，从而导致实体与业务出现不一致的情况;

4. 通过聚合根对子实体进行访问；子实体的一致性交由聚合根保证;

5. 任何实体的行为只能直接影响到本实体（和其子实体）。

应当遵守的原则：在一个系统里一个实体对象的所有变更操作应该都是预期内的，如果一个实体能随意被外部直接修改的话，会增加代码bug的风险**。**

4.2.2 Value Object（值对象）

描述特征的对象，不具有任何唯一性的对象称为价值对象，它们只关心自己是什么，而不关心自己是谁，值对象是多个实体的属性，可以由多个实体共享。

例如：两个客户可以具有相同的发货地址，尽管存在风险，但如果其中一个属性需要更改，则共享这些属性的所有实体都会受到影响。为了防止这种情况发生，值对象必须是不可变的，当需要更新时，强制系统用新实例替换它们。

此外，价值对象的创建应始终取决于用于创建它们的数据的有效性，以及它如何尊重业务不变量。

因此，如果数据无效，将不会创建对象实例。例如，在北美，带有非字母数字字符的邮政编码将违反业务不变量，并将触发地址创建异常。

4.2.3 Aggregate（聚合）

聚合是相关实体和值对象的集合，聚集在一起表示事务边界。每个聚合都有一个朝外的实体，控制对边界内对象的所有访问，该实体称为聚合根，是其他对象可以交互的唯一对象。

聚合中的任何对象都不能直接从外部世界调用，从而保持内部的一致性。业务不变量是保证聚合及其内容完整性的业务规则，换句话说，它是一种确保其状态始终与业务规则一致的机制。例如，当某个产品的库存量为零时，就永远不能下订单。

4.2.4 Repository（资源库）

为了能够从持久性中检索对象，无论是在内存、文件系统还是数据库中，我们需要提供一个对客户机隐藏实现细节的接口，以便它不依赖于基础架构细节，而仅仅依赖于抽象。

存储库提供了一个接口，域层可以使用该接口来检索存储的对象，避免了与存储逻辑的紧密耦合，并使客户端产生了直接从内存检索对象的错觉。

值得一提的是，所有存储库接口定义都应该位于domain层，但它们的具体实现属于基础架构层。

4.2.5 Domain Event（领域事件）

领域事件是过去时态的业务事实，当聚合根状态变更时触发，它的核心职责是跨聚合/微服务的业务协同，我们将它定义在领域层，发布/处理可在应用层。

例如订单创建后触发库存更新、通知等跨系统操作，它不需要强一致性保证，只需要保证最终一致性。

4.2.6 Domain Service（领域服务）

在许多情况下，领域模型需要某些与实体或值对象不直接相关的动作或操作，将这些动作或操作强制到它们的实现中会导致它们的定义失真。

如电商订单支付，需要协调订单、库存、支付三个实体完成事务。

服务****应该精心设计，始终确保它们不会剥夺实体和价值对象的直接责任和行为。

它们还应该是无状态的，这样客户机就可以使用服务的任何给定实例，而不考虑该实例在应用程序生命周期中的历史记录。

4.2.7 Application Service（应用服务）

和领域服务的区别在于，应用服务处理流程编排、捕获异常，领域服务处理核心业务规则。

应用服务是协调领域模型与外部系统交互的中间层，负责处理非业务逻辑的横切关注点，如事务管理、安全认证、参数校验、事件发布等。

通过一个应用服务，我们能够清晰地看出对哪些实体行为进行了调度，它依赖于领域服务和基础设施组件，进行日志记录、异常捕获、权限验证、数据转换等基础设施层交互，保持领域层与技术实现解耦。

此外，应用服务还需要对外暴露REST API或RPC接口，对内将DTO转换为领域对象，隔离外部请求与内部模型。

05 领域驱动设计分层架构

** 六边形架构**

从代码演进的角度来看/需求变更的速度来看，我们将各层按照变更速度排序：

1. Domain（领域）层属于核心业务逻辑，属于经常被修改的地方；这部分的需求经常随着产品的迭代进行变更。领域层不依赖其他层，通过资源库包下的接口定义做到依赖倒置，接口参数不能体现具体技术实现细节，领域模型里的实现逻辑只依赖接口。这样做到对领域逻辑的一层防腐。本层里以聚合为单位放置代码，便于以后系统拆分，以聚合为单位。

2. Application（应用）层属于Use Case（业务用例）。业务用例一般都是描述比较大方向的需求，接口相对稳定，特别是对外的接口一般不会频繁变更。_添加业务用例可以通过新增Application Service或者新增接口实现功能的扩展_**。**此外应用层还可以处理横切面事务比如启动数据库事务。

3. Interface（接口）层主要负责解决外部通信、协议等问题，将外部的定时任务、请求、rpc、事件消费都进行透明处理。

4. Infrastructure（基础设施）层属于最低频变更的。基础设施层完成资源库的实际实现，以及领域层定义的其他接口的实现如对外部服务的访问，领域事件发布到消息队列中间件等。一般这个层的模块只有在外部依赖变更了之后才会跟着升级，而外部依赖的变更频率一般远低于业务逻辑的变更频率。

5.1 DDD FrameWork（四层架构）

后文中，我们对于层的介绍将类比接口的概念进行介绍，重点关注3个概念：

• 入参

• 出参

• 内容

5.1.1 用户接口层

• 定义：用户接口层负责向用户显示和解释用户指令。这里的用户可能是:用户、程序、自动化测试和批处理脚本等等。

• 目的：我们希望通过分层,来提升application层的稳定性。

• 构成结构

1. 入参:  CQE对象;

2. 出参：DTO对象;

3. 内容 : 对玩不输入进行校验,输出内容的处理结果;

• 笔者在这里给出一些落地规范:

1. 统一的鉴权：比如在一些需要AppKey+Secret的场景，需要针对某个租户做鉴权的，包括一些加密串的校验;

2. 网络协议的转化：这个尽量交给框架处理，我们主要的工作是关注如何将参数反序列化或者序列化;

3. Session的管理：一般在面向用户的接口或者有登陆态的，通过Session或者RPC上下文可以拿到当前调用的用户，以便传递给下游服务;

4. 限流配置：对接口进行限流;

5. **异常处理：**通常在接口层要避免将异常直接暴露给调用端，所以需要在接口层做统一的异常捕获，转化为调用端可以理解的数据格式;

6. 日志打印：在该层进行日志的打印;

7. CQE的校验：在该层进行业务无关的校验，推荐依赖框架本身实现;

8. 可选：部分代码会在interface层引入缓存。

补充：浅谈CQE模型和CQRS

从笔者的经验来看，这两者概念上区别不大，他的思路就是将系统的Input，根据语义拆分成write和read。这里先只谈CQE模型：

Command指令：指调用方明确想让系统执行的指令，他的预期是对一个系统进行影响，即写操作。通常来说，需要一个明确的返回值（如：同步的操作结构、异步的指令被接受）

Query指令：指调用方明确想查询的东西，包括查询参数、过滤、分页等条件，其预期是对一个系统的数据完全不影响的，也就是只读操作

Event指令：指一件已经发生过的事情，需要系统根据这个事实进行相应，通常都会伴随一个写操作。事件处理器不会有返回值。补充一下，Application层的Event概念和Domain层的DomainEvent是类似的概念，但不一定是同一回事，这里的Event更多是外部一种通知机制而已。

Q：为什么使用CQE对象?

这是一个好的问题，从笔者的经验来看，DDD在于解决复杂的业务；

从某种意义上来说，笔者认为读不算真正的业务，读往往可以理解成数据的组装。

因此，对问题进行拆分，分而治之，从工程学上来说是一种简单可行的方案。从完美的角度上来说，如果能有一种可以全治理的方案一定是最好的！But we live in the real world!

5.1.2 应用层（落地重点）

• 定义：应用层是很薄的一层，理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作。

• 目的：应用层的核心是：Manage或者Orchestration，编排是应用层最关心的事情，他负责将业务编排到各个领域中。

• 构成结构

1. 入参:  CQE(Command、Query、Event)对象

2. 出参：DTO对象

3. 内容：

a.应用层位于领域层之上，可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作。

b.应用层也是微服务之间交互的通道，它可以调用其它微服务的应用服务，完成微服务之间的服务组合和编排。

c.应用服务是在应用层的，它负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，以粗粒度的服务通过 API 网关向前端发布。

d.应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。

• 落地规范

a.应用层应该只包含业务流程的封装，不处理业务逻辑;

b.避免进程内部的EDA驱动。

Q:什么是DTO？为什么要有DTO？带来的额外成本是什么？

DTO存在的意义在于我们可以将实体与数据传输解耦，使得领域层只和应用层有关联性、对外透明；额外成本：性能&冗余&额外引入的DTO Assembler层（用于实体到DTO的转换）。一个基本的DTO对象，如下（简单的pojo对象）：

type AdWalletDTO struct {
    AdAccountID          string          `json:"ad_account_id"         orm:"ad_account_id"         `   // 子账户ID
    WalletStatus         uint            `json:"wallet_status"         orm:"wallet_status"         `   // 钱包状态：1-正常 2-欠费状态 3-关闭
    DepositBalance       decimal.Decimal `json:"deposit_balance"        orm:"deposit_balance"        ` // 存款余额
    FrozenDepositBalance decimal.Decimal `json:"frozen_deposit_balance" orm:"frozen_deposit_balance" ` // 冻结存款余额
    CreditBalance        decimal.Decimal `json:"credit_balance"        orm:"credit_balance"        `   // 信用余额
    FrozenCreditBalance  decimal.Decimal `json:"frozen_credit_balance" orm:"frozen_credit_balance" `   // 冻结信用余额
    CouponBalance        decimal.Decimal `json:"coupon_balance"`                                       // 代金券余额
    Title                string          `json:"title"`                                                // 名字
    Currency             string          `json:"currency"`                                             // 货币
}

Q:CQE 和 DTO有什么区别？

ApplicationService的入参是CQE对象，但是出参却是一个DTO，从代码格式上来看都是简单的POJO对象，那么他们之间有什么区别呢？

可以简单做如下理解：

• 入水口的pojo是CQE，出水口的是DTO（因为入水口天然自带业务含义，因此需要严格的校验；出水口是安全的，只承担数据传输的载体）

• 复用性上而言：CQE对象复用性更低，DTO的复用性更强

CQE对象：CQE对象是ApplicationService层的输入，也可以是interface层的输入，有明确的意图，这个对象必须保证输入的正确性。

DTO对象：是负责承接数据的容器，不负责具体的业务，不包含任何逻辑，只是贫血对象

最重要的一点：因为CQE是”意图“，所以CQE对象在理论上可以有”无限“个，每个代表不同的意图；但是DTO作为模型数据容器，和模型一一对应，所以是有限的。

Q:为什么出参应该返回DTO而不是Entity?

这个是一个非常好的问题，笔者在DDD落地实践的时候，笔者是这么去想的：

1. 稳定性思考：Entity里面通常会包含业务规则，如果ApplicationService返回Entity，则会导致调用方直接依赖业务规则，如果内部规则变更可能直接影响到外部。

2. DTO的不稳定性大于实体：业务经常会增加、改变一些字段，而实体的字段相对更加稳定，这也让我们尽量在application层的出参去屏蔽实体

3. 领域边界稳定性：ApplicationService的入参是CQE对象，出参是DTO，这些基本上都属于简单的POJO，来确保Application层的内外互相不影响。

4. 通过DTO组合降低成本：Entity是有限的，DTO可以是多个Entity、VO的自由组合，一次性封装成复杂DTO，或者有选择的抽取部分参数封装成DTO可以降低对外的成本。

Q:在上述的过程中，我们似乎只解决了C、E对象，我们应该如何针对Query进行处理？

在实践过程中，我们发现Query往往是复杂的、随意的、且交付对象是异变的，因此如果强行将Query作为业务来嵌入我们的DDD中，简直是自讨苦吃——我们很难保证一个操作既是高效读、又是高效写、同时还要兼顾一致性。因此我们的解决思路是，针对Query采用传统的开发模型，虽然不够优雅、但是足够有效，毕竟因为改动代码，导致读错的成本实在是太小了。

在实践过程中，我们推荐使用调用链去尽量简化、复用读的场景，并且取得较好的实践效果。

应用层，因为我们操作的对象是Entity，但是输出的对象是DTO，这里就需要一个专属类型的对象叫DTO Assembler。DTO Assembler的唯一职责是将一个或多个Entity/VO，转化为DTO。

注意：DTO Assembler通常不建议有反操作，也就是不会从DTO到Entity**，因为通常一个DTO转化为Entity时是无法保证Entity的准确性的。**

5.1.3 领域层

• 定义：领域层的作用是实现企业核心业务逻辑,通过各种校验手段保证业务的正确性。

• 目的：领域层的目的是完成业务的核心逻辑,降低实体之间的依赖性。

• 构成结构

1. 入参: 实体、聚合根、基础的数据结构(int、string......)......

2. 出参：实体、聚合根、基础的数据结构

3. 内容：

a.应领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象，主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。

b.领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能。

c.当领域中的某些功能，单一实体（或者值对象）不能实现时，我们就会将这样的逻辑放在领域服务里，__通过领域服务组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。

• 落地规范

a.避免领域事件的使用。

Q:为什么我们要避免进程内部的领域事件的使用？

进程内的领域事件，会导致显示的调度变成隐式，这种隐式的场景在测试阶段很难发现问题，从而导致线上问题的产生。从迭代的发展来看，隐式的事件驱动对于我们设计一个好的代码架构不是一件好事情，反而会大大提高代码的复杂度！因此，我们要尽量去避免进程内部级别的事件驱动~

5.1.4 基础设施层

• 定义：基础层是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。

• 目的：对业务提供最基本的服务

• 落地规范

a.比较常见的功能还是提供数据库持久化

b.基础层包含基础服务，它采用依赖倒置设计，封装基础资源服务，实现应用层、领域层与基础层的解耦，降低外部资源变化对应用的影响。

5.1.5 Data flow direction（数据链路）

在数据链路维度，我们来看DDD的数据流转，可以更清晰地看出每一层之间的交互。

数据持久化对象 PO(Persistent Object)，与数据库结构一一映射，是数据持久化过程中的数据载体。

领域对象 DO（Domain Object），微服务运行时的实体，是核心业务的载体。

数据传输对象 DTO（Data Transfer Object），用于前端与应用层或者微服务之间的数据组装和传输，是应用之间数据传输的载体。

视图对象 VO（View Object），用于封装展示层指定页面或组件的数据。

5.1.6 附录：生产环境中项目结构

目录结构：

5.2 领域驱动VS数据驱动

5.2.1 对比

传统的接口-逻辑-数据访问三层架构里，往往是这么个逻辑。

前几行代码做validation，接下来做convert，然后是业务处理逻辑的代码，中间穿插着通过RPC或者DAO获取更多的数据，拿到数据后，又是convert代码，然后接着一段业务逻辑代码，最后可能还要落库，发消息等等。

MVC三层架构

• 用户界面层（View/Controller）**负责用户交互和界面展示，接收用户输入并传递至业务逻辑层，同时将处理结果返回给前端。

• 业务逻辑层（Service）**包含核心业务逻辑，但常因过度集中而臃肿，容易成为“大泥球”。业务逻辑可能分散在多个Service类中，甚至通过SQL实现部分逻辑，导致耦合度高。

• 数据访问层（DAO）**直接操作数据库，依赖ORM框架，与数据库表结构紧密绑定。

MVC VS DDD：

5.2.2 转化

三层架构向 DDD 分层架构演进，主要发生在业务逻辑层和数据访问层。

DDD 分层架构在用户接口层引入了 DTO，给前端提供了更多的可使用数据和更高的展示灵活性。

DDD 分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻辑混乱，代码改动相互影响大的情况。DDD 分层架构将业务逻辑层的服务拆分到了应用层和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。

另外一个重要的变化发生在数据访问层和基础层之间。三层架构数据访问采用 DAO 方式；DDD 分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。

仓储又分为两部分：仓储接口和仓储实现。仓储接口放在领域层中，仓储实现放在基础层。原来三层架构通用的第三方工具包、驱动、Common、Utility、Config 等通用的公共的资源类统一放到了基础层。

5.2.3 CQRS

不得不提的CQRS结构（参考文档：learn.microsoft.com/zh-cn/azure…

简介：CQRS 是“命令查询责任分离”（Command Query Responsibility Segregation）的缩写

定义：CQRS是一种设计模式，可将数据存储的读取和写入操作隔离到单独的数据模型中。 此方法允许每个模型独立优化，并可以提高应用程序的性能、可伸缩性和安全性

核心：将外部系统的输入区分为：Cmd(包含Event)和Qurey。

因为我们知道，在DDD的模式中，所有的操作都是以实体为基础的，一个实体很有可能很大，涵盖了多种数据来源组成。

那这里就出现了一个问题，业务中需要出一个接口，查询一个account list，以label value的形式返回，我们该怎么做？

是先通过一系列工厂校验，拿到一个大实体，然后通过这个实体操作数据，拿到account list，再处理成dto返回。

还是直接写一个简单的mvc，查询然后拿结果组装返回。

毫无疑问，我们选择后者。

这就是CQRS，用比较粗糙的说法：我们建议在业务逻辑的写入Cmd(包含Event)用DDD来进行，也建议在业务逻辑的查询Query用MVC来进行。

一切模型或者框架，都是为了简化我们的工作，如果我们因为使用了某一种设计模式，而导致开发严重受限，那说明这种设计模式，并不适合我们。

06 总结

正如那句话说的，DDD不是银弹，它不能解决所有问题，但是我们在尝试解决的路上，发现了这样一种模式。

07 彩蛋

看到了这里想必你的脑子里现在全是实体、领域等等这些理论概念，已经忘记了文章一开始我们要干什么，这其实也是在落地DDD时一大痛点。那就让我们不忘初心，再重新回顾和强调一下：我们的目的是要去写一个好的代码。

-----END-----

推荐阅读

读友好的缓存淘汰算法

如何定量分析 Llama 3，大模型系统工程师视角的 Transformer 架构

微服务架构革新：百度Jarvis2.0与云原生技术的力量

技术路线速通！用飞桨让京剧人物照片动起来

无需业务改造，一套数据库满足 OLTP 和 OLAP，GaiaDB 发布并行查询能力

为了适应 PD 分离式推理部署架构，百度智能云从物理网络层面的「4us 端到端低时延」HPN 集群建设，到网络流量层面的设备配置和管理，再到通信组件和算子层面的优化，显著提升了上层推理服务的整体性能。

百度智能云在大规模 PD 分离式推理基础设施优化的实践中，充分展现了网络基础设施、通信组件与上层业务特征深度融合的重要性。

---

01 PD分离式推理服务对网络的需求

传统的推理服务均是集中式，大多是单机部署。即使是多机部署，机器规模也非常小，对网络的带宽和时延需求都不大。当前大规模 PD 分离式推理系统来说，对网络通信的需求则发生了变化：

• 引入大规模的 EP 专家并行。EP 会从单机和双机的小规模，变成更大规模，因此 EP 之间的「 Alltoall 通信域」成倍增长。这对于网络基础设施、Alltoall 算子等的通信效率都提出了更高的要求，它们会直接影响 OTPS、TPOT 等指标，从而影响最终的用户体验。

• PD 分离式部署，Prefill 和 Decode 之间会有 KV Cache 流量的传输，KV Cache 通信的时延直接影响推理服务整体的性能。

为了提升大规模 PD 分离式推理系统的效率，百度智能云针对性地优化了网络基础设施和通信组件：

• 物理网络层面：为适配 Alltoall 流量专门建设了「4us 端到端低时延」 HPN 集群，支持自适应路由功能彻底解决网络哈希冲突，保证稳定的低时延。

• 流量管理层面：优化 Alltoall 多打一 incast 流量导致的降速问题。对 HPN 网络中训练、推理等不同类型流量进行队列管理，实现训推任务的互不干扰。通过自研高性能 KV Cache 传输库实现 DCN 弹性 RDMA 满带宽传输。

• 通信组件层面：Alltoall 算子优化，相比开源的方案，大幅提升 Prefill 和 Decode 的 Alltoall 通信性能。针对 batch size 级别的动态冗余专家编排，将专家均衡度控制在了 1.2 以下，确保集群中所有 GPU 通信时间大致相同。优化双流，实现最大程度的计算和通信 overlap，整体提升 20% 吞吐。

下面我们逐一介绍百度智能云在以上几个层面的优化实践。

02 解决方案和最佳实践

2.1 建设适配的 HPN 网络设施

百度智能云在训练场景下的 HPN 网络架构设计已经有着丰富的经验，AIPod 使用多导轨网络架构，GPU 服务器配有 8 张网卡，然后每张网卡分别连到一个汇聚组的不同 LEAF 上。在 LEAF 和 SPINE 层面，通过 Full Mesh 的方式进行互联。

以下图为例，考虑一个训练场景下的 3 层架构 HPN 网络：

2.1.1 训练和推理任务的流量特征

• 非 MoE 训练任务的流量特征

在传统非 MoE 的训练场景下，跨机通信产生的流量大多数都是同号卡流量。例如在梯度同步时候产生的 AllReduce 或者 ReduceScatter 或者 AllGather，PP 之间的 SendRecv 等。同号卡通信最佳情况可以只经过一跳，以上图为例，每个 LEAF 交换机有 64 个下联口，因此 64 台服务器规模同号卡通信理论上可以做到一跳可达。

规模再大，就只能经过 SPINE 或者最差经过 SUPER SPINE 来进行通信。为了减少流量上送 SPINE，百度百舸在任务调度的时候会自动进行服务器的亲和性调度。在创建任务的时候，尽量把同一通信组下的 Rank 排布在同一 LEAF 交换机下的服务器内，那么理论上大部分流量都可以收敛在 LEAF 下。

• MoE 推理流量特征

对于推理服务来说，MoE EP 之间的 Alltoall 通信流量模式与 AllReduce 等不同，会产生大量的跨导轨流量。虽然对于 Prefill 阶段来说，可以通过软件实现层面规避掉跨导轨的流量，但是 Decode 阶段仍然无法避免跨导轨，这会导致多机之间的通信不只是同号卡通信，跨机流量大部分并不能一跳可达，会有大量的流量上到 SPINE 或者 SUPER SPINE，从而导致时延增加。

• MoE 训练流量特征

对于 MoE 训练的流量会更加复杂，综合了训练和推理的流量特征，既存在传统的梯度同步产生的 AllReduce 或者 ReduceScatter 或者 AllGather，PP 之间的 SendRecv，也存在 EP 之间的 Alltoall 流量。这些流量不但会出现跨导轨传输的问题，他们之间可能会存在 overlap 导致互相干扰。

2.1.2 面向 EP 的 HPN 架构优化

鉴于 Alltoall 通信的特点，我们在设计 HPN 网络的时候，会考虑优先保证跨导轨流量至多 2 跳可达，让 Alltoall 流量收敛到 SPINE 层，以这种方式尽量减少跨导轨的通信时延。如下图所示：

LEAF 层所有设备全部有一根线接入同一台 SPINE 交换机，这样可以让集群内 Alltoall 跨导轨流量全部收敛到 SPINE 层，跨导轨通信时延可以进一步从 5us+ 缩小为 4us。

这种经过优化后的 HPN 网络架构，能接入的卡数主要取决于交换机芯片支持的最大的下联口有多少。虽然对于超大模型的训练任务来说，这个集群规模可能不够，但是对于推理来说，通常不需要那么大规模的机器，是可以满足需求的。

2.1.3 自适应路由彻底消除 hash 冲突

同时，由于 Alltoall 通信流量的特征，LEAF 到 SPINE 之间的通信流量会成为常态。当流量需要通过 SPINE 传输的时候，会由 hash 选择 SPINE 出口的过程，这时候有可能会产生 hash 冲突，导致网络抖动。因此为了避免 hash 冲突，百度智能云基于自研交换机实现自适应路由。如下图所示：

假设 A 和 C 进行 Alltoall 跨导轨通信，A 发出的流量必然要经过 SPINE，那么流量在到达 LEAF 的时候，会基于 packet 做 hash，并结合链路的负载情况动态选择最优的出口，将报文发送到多个 SPINE 上。

基于报文 hash 到不同的物理路径，百度智能云实现了链路负载均衡，消除因 hash 冲突时延增加导致的性能抖动，实现稳定的低时延网络。

详情可参考：彻底解决网络哈希冲突，百度百舸的高性能网络 HPN 落地实践

2.2 流量的管理和优化

2.2.1 避免 incast 造成降速，不同类型流量的分队列管理

• Alltoall 多打一，不合理的配置造成降速

在推理服务中，EP 间的 Alltoall 通信流量特性与传统训练中的 AllReduce 完全不同，网络上多打一造成的 incast 流量非常常见。这种 incast 的严重程度会随着规模的增大而增大。incast 流量的突发，可能会造成接收侧网卡上联的交换机端口向发送侧反压 PFC，导致网络降速。

传统 Alltoall 流量多打一的示意图如下，假设机器 A 和机器 C 的 GPU0、GPU2、GPU4、GPU6 都需要给机器 B 的 GPU0 发送数据，那么在网络上就会出现 8 打 1 的情况。

传统的 Alltoall 实现，例如 PyTorch 内部调用的 Alltoall，是使用 send recv 去实现的，如果使用 PXN 可以缩小网络上的发生多打一的规模，但是多打一依然存在，如下图所示：

因此无论 Alltoall 的算子实现方式如何，网络上的多打一都无法避免。此时如果网络侧的拥塞控制算法的配置不合理，对拥塞过于敏感，就会产生降速，进而对整体吞吐造成影响。

• 推理训练任务中非 Alltoall 流量的干扰

除此之外，如果集群内还存在其他流量，例如训练任务 DP（数据并行）之间的 AllReduce 或者 ReduceScatter 或者 AllGather，或者 PD（Prefill-Decode）之间的 KV Cache 传输，也会对 Alltoall 的流量造成影响，从而进一步降低推理引擎的整体吞吐。

因此无论是端侧网卡的配置，或者是交换机的配置，都需要针对 Alltoall 这种多打一 incast 流量做针对性优化，同时尽量避免集群内其他流量对 Alltoall 流量造成影响。

针对这种情况，我们给出的解决方案如下：

• 在队列管理层面，通过端侧网卡将 EP 的流量做专门的优先级配置，将 Alltoall 流量导入到高优先级队列。其他训练的流量，比如 AllReduce 等使用低优先级队列。

• 在资源层面，在端侧网卡和交换机的高优先级队列上，预留更多的 buffer，分配更高比例的带宽，优先的保证高优先级队列的流量。

• 在拥塞控制算法配置层面，高优先级队列关闭 ECN 标记功能，让 DCQCN 算法对 Alltoall 流量微突发造成的拥塞不做出反应，从而解决 incast 问题造成的降速。

在经过端侧网卡和网侧交换机配合调整后，可以保障 Alltoall 通信流量的通信带宽和传输时延，实现训推任务的互不干扰，并有效的缓解 incast 流量带来的非预期的降速而造成的性能抖动。

经过测试，在我们部署的推理服务中，Alltoall 过程的整体通信时延有 5% 的降低。

2.2.2 DCN 支持弹性 RDMA 实现 KV Cache 满带宽传输

在 PD 分离式推理系统中，还存在 PD 之间 KV Cache 传输的流量。相比 Alltoall 虽然他的带宽需求不算大，但为了避免二者的流量互相干扰，通常我们会让 KV Cache 的传输流量单独走 DCN 网络，使其与 Alltoall 的流量完全隔离开。

在 DCN 网络的设计上，为了保证 KV Cache 流量的传输带宽，其网络架构收敛比采用 1：1。端侧网卡支持弹性 RDMA，使用 RDMA 协议保证 KV Cache 的高性能传输。

在传输库层面，百度智能云使用自研的高性能 KV Cache RDMA 传输库，其接口设计与框架层深度定制，支持上层框架分层传输，也支持多层 KV Cache 的批量传输，便于在框架层做计算与传输的 overlap。

通过以上设计优化，KV Cache 传输在主网卡可以用满带宽，传输时间可以完全被计算 overlap 住，不成为推理系统的瓶颈。

2.3 提高推理服务组件的网络通信效率

在有了高带宽低时延的网络基础设施的基础上，如何用好网络基础设施，是推理服务软件层面需要重点考虑的事情。

在我们对 PD 分离推理服务的 profile 分析当中，发现了一些影响网络通信效率的关键因素。

2.3.1 Alltoall 算子的通信效率

目前社区开源的 DeepEP 已经给出了推理系统中 dispatch 和 combine 过程的 Alltoall 高性能的算子的实现，且性能表现优异。

对于 Prefill 来说，由于输入的 batch size 较大，Alltoall 通信算子的同号卡传输阶段为了平衡显存资源和性能，采用分 chunk 传输的方式，发送和接收会循环使用一小块显存，并对每次 RDMA 发送以及机内 NVLink 传输的 token 数做了限制。

通过实际观测网卡的传输带宽，发现其并没有被打满。在此基础上，我们对网络传输的显存的大小，以及每一轮发送接收的最大 token 数等配置，针对不同的 GPU 芯片，做了一些精细化的调整，使之在性能上有进一步的提升。通过优化，DeepEP 的传输性能有大概 20% 的性能提升，网络带宽已经基本被打满。

对于 Decode 来说，DeepEP 的实现是多机之间的 EP 通信，不区分机内和机间，一律采用网络发送。这样做的考虑是为了机内传输也不消耗 GPU 的 SM 资源，完成网络发送后算子即可退出。在网络传输的时间内做计算，完成后再调用 Alltoall 的接收算子，以此来实现计算和通信的 overlap。但这样做的缺点是机内的 NVLink 的带宽并没有被高效的利用起来，网络传输的数据量会变大。

因此，百度智能云通过在 GPU 算子内使用 CE 引擎做异步拷贝，在不占用 GPU SM 资源的情况下，也能实现机内 NVLink 带宽的高效利用，同时不影响计算和通信的 overlap。

2.3.2 动态冗余专家编码，保证 EP 负载均衡

EP 专家之间如果出现处理 token 不均衡的情况，将会导致 Alltoall 通信算子的不同 SM 之间，以及不同 GPU 的通信算子之间，出现负载不均的情况，导致的结果就是整体通信时间会被拉长。

由于 EP 专家之间的负载均衡是推理服务引擎提升吞吐的非常重要的一环，经过百度智能云的大规模的线上实践的经验来看，静态冗余专家并不能很好的保证专家均衡。因此我们专门适配了针对 batch size 级别的动态冗余专家，把专家均衡度（max token/avg token）基本控制在了 1.2 以下，不会出现明显的「快慢卡」的情况

2.3.3 极致优化双流效果，整体吞吐进一步提升

通信和计算 overlap，隐藏通信的开销，一直都是推理服务，或者大模型训练中，非常重要的课题。

在百度智能云的实践中，我们在线上大规模的推理服务中开启了双流。为了尽量隐藏掉通信的开销，达到最好的 overlap 的效果，除了做 EP 之间的专家均衡以外，对计算算子也做了针对性的优化，例如对计算算子和通信算子 kernel launch 的顺序做合理排布，对二者所需的 SM 资源做合理的分配，避免出现计算算子占满 SM 导致通信算子 launch 不进去的情况，尽可能的消灭掉 GPU 间隙的资源浪费。通过这些优化，整体的吞吐可以提升 20% 以上。

03 总结

百度智能云在大规模 PD 分离式推理基础设施优化的实践中，充分展现了网络基础设施、通信组件与上层业务特征深度融合的重要性。这种融合不仅是技术层面的创新，更是对实际业务需求的深刻理解和响应。

01 引言

大模型的训练和推理任务，本质就是海量数据处理的过程。强大的算力集群，不仅需要高性能的AI加速卡和高性能的RDMA网络，还离不开高性能存储系统的支持。

当前，在大模型训练任务的数据读取、Checkpoint加载，推理任务的快速分发和镜像加载等场景，数据的大小少则几十GiB，多则几百TiB甚至至多达到数PiB。存储速度越快，算力空闲时间越短。这需要一套能够支持大规模算力集群、海量数据场景的高性能存储加速系统。

02 RapidFS存储加速集群

在Create 2025大会，昆仑芯3万卡集群正式发布。为此，我们为RapidFS存储加速服务部署了数百台国产CPU服务器，集群设计总吞吐接近10 TiB/s，以满足3万卡昆仑芯集群大规模数据读写需求。

我们使用部分资源进行了RapidFS性能测试（更多测试细节见后文）。

测试结果显示，20个RapidFS存储节点稳定提供了302 GiB/s吞吐，70个RapidFS存储节点稳定提供了1.03 TiB/s吞吐。单台RapidFS存储节点可提供15 GiB/s吞吐，折合单TiB（裸容量）300 MiB/s。

这些数据表明RapidFS存储加速集群的吞吐性能，随着集群规模线性增长。单台RapidFS存储节点经过软硬一体的协同优化，充分发挥出国产CPU的性能和软件加速效果。

同时，这也意味着在70个RapidFS存储节点提供加速的情况下，100个计算节点并发加载10 GiB的文件仅需1秒，让数据随叫随到。

03 RapidFS产品简介

RapidFS是一款近计算存储加速工具。依托对象存储BOS作为数据湖存储底座，构建容量与性能解耦、冷热分层、透明流转的高性能存储方案。以POSIX挂载和HDFS协议，为上层计算应用提供统一文件访问入口，加速AI训练与推理、海量数据处理与分析、数据分发等业务场景下的存储访问。

04 性能测试详细说明

4.1 服务器配置

在本次测试的昆仑芯3万卡集群中，百度智能云RapidFS以全托管集群方式部署于国产CPU服务器，作为近计算存储加速服务使用。详细配置如下：

4.2 测试规模

我们分别对20个存储节点和70个存储节点规模的RapidFS集群进行了性能测试。

4.3 测试方法

按照DeepSeek V3模型文件构造160个4.3 GiB文件，总计688 GiB。将这些文件导入对象存储BOS并加载至RapidFS存储加速集群中。每个计算节点开启8进程从RapidFS存储加速集群中读取模型文件，持续压测600秒。

4.4 测试结果

测试集群A：20个RapidFS存储节点

测试集群B：70个RapidFS存储节点

百度智能云RapidFS存储加速集群用数据证明了国产算力基础设施的突破潜力。存储性能与算力需求实现「同频共振」，成为大模型训练与推理的效率助推器。

Qwen3 系列全家桶包含了 8 款不同尺寸的模型，覆盖了从 6 亿到 2350 亿的参数规模。其中 2 款混合专家（MoE）模型和 6 款稠密（Dense）模型，均支持「混合推理」机制。

目前，百度百舸平台已经同步支持 Qwen3 系列全家桶的一键部署，为企业提供一站式 AI 服务，实现大模型落地「快稳省」的要求。

一键部署流程

登录百度百舸·AI 异构计算平台，在「**快速开始」**找到 Qwen3 系列模型。

点击模型卡片的「一键部署」开始部署模型。目前 Qwen3 系列模型支持 SGLang、vLLM 推理加速方式。

百度百舸平台已推荐部署不同模型的最低配置资源，您可以按需修改。（注意：需要提前购买算力资源，并在百度百舸平台创建自运维或全托管资源池）

部署成功后，通过「在线服务」列表中查看服务调用信息，获取调用地址和 Token 调用服务。

百度百舸·AI 异构计算平台，是面向大模型训推一体化的基础设施，提供领先的 AI 工程加速能力，从资源准备、模型开发、模型训练到模型部署，为 AI 工程全周期提供丰富特性和极致易用体验。

针对大模型 PD 分离式推理部署方案，百度百舸平台支持自适应 PD 任意配比、细粒度 PD 负载均衡、自适应最优混合并行策略、动态冗余专家编排等，降低 40% TPOT 和 95% 推理成本，实现了极致的推理加速优化。

这套方案正在支撑百度智能云千帆平台，为 40 万客户提供服务。上线以来，推理吞吐提升了 20 倍，速度提升了 50% 以上。

4月28日，IDC《中国汽车云市场(2024下半年)跟踪》报告发布，2024下半年中国汽车云市场整体规模达到65.1亿元人民币，同比增长27.4%。IDC认为，自动驾驶技术深化与生成式AI的发展将为汽车云打开新的成长天花板，推动云计算在汽车行业的持续渗透。

IDC报告显示，2024年全年自动驾驶研发解决方案市场规模达16.34亿元人民币，同比增长18.42%，百度智能云以5.64亿元人民币的市场份额排名第一，份额占比达34.51%。

IDC中国企业级研究部分析师陈启今表示：“自动驾驶研发解决方案市场竞争激烈，百度智能云凭借自动驾驶领域的深厚行业积累和企业解决方案优势，重点关注头部车企和Tier1，市场份额重回至行业第一。”

智能驾驶进入AI时代，智算基础设施与算法、数据三者协同发展，端到端智驾正成为业内共识，车企和供应商不断加码算力集群采购、新算法架构搭建、仿真测试等资本支出，头部客户算力花销和算力规模正朝着亿级、10EFlops级别演进。

陈启今表示，智驾领域技术持续迭代、竞争白热化，客户对自动驾驶解决方案的需求不断增加，而新车网联化进程全面加速及车联网场景创新也驱动客户加大相关投入，这些因素共同为汽车云长期发展积累增长势能。

在这样的趋势下，百度智能云快速完成迭代，将汽车云解决方案已经升级到了3.0版，为车企提供了强大的算力支撑、精准的算法适配、高质量仿真场景及车路协同等核心技术，针对端到端智能驾驶进行了重点的适配，有力推动了自动驾驶的量产落地。

目前，百度智能云正加速对头部车企的覆盖，中国市场TOP15销量品牌、TOP10新能源车企中合作客户均已经实现全覆盖、在主流车企中渗透率达到95%。

百度沈抖：智能基础设施，为应用而生

导读

打点是指在网站或者APP中加入一些统计代码，通过日志记录用户在 APP 内触发的一系列行为，包括点击、滑动等。打点上报后汇聚成用户行为日志，用户行为日志可用于报表统计、AB Testing、个性化推荐等，是分析用户、调整策略、迭代产品的重要依据。

日志中台做为百度内一站式打点解决方案，覆盖了厂内以百度APP为代表的大多产品，每天产生千亿级的打点日志PV。这些日志经过格式化之后，满足用户的各种数据消费需求，光是占用的存储资源每天达上百P。为了满足业务长周期的数据统计、分析、回溯等需求，需要大量的计算和存储成本，部分核心数据甚至需要永久存储。

但是，随着业务快速迭代发展，线上打点只增不减，单条日志越来越长，上报量越来越大，规模日渐膨胀。打点日志的无序增长，既影响打点服务的稳定，也带来计算和存储资源的增长。为了在资源有限的前提下，最大化打点日志的价值，需要对打点日志进行持续的治理，提升打点收益。治理手段包括无用点位的定位和下线、异常打点的发现和修复、已有打点的字段裁剪和上报机制优化、新feature放量或运营活动期间打点服务的稳定性保障等。

△点位全生命周期治理

通过点位治理措施，对于正常需求导致pv上涨的点位，中台能够提前扩充资源，保障业务的高效发展；对于异常问题引起的pv上涨的点位，中台能够协助业务方排查潜在风险，减少业务隐患；对于无用打点，及时发现并完成点位下线，节省后续计算和存储资源；对于冗余打点引起pv上涨的点位，中台协助优化打点上报逻辑，实现高质量打点，推动业务方和日志中台的降本增效。因此，点位治理实践能够助力日志中台感知点位波动、预先为正常流量的增幅留足空间，保证打点符合用户预期、限制低质量有问题流量无序发展，为用户提高更优质量的打点体验，高效率高质量支持业务蓬勃发展。

△全生命周期打点管理

01 要治理的问题和方案

日志中台的成本治理实践主要分三个阶段：人工治理、半自动化治理、点位全生命周期标准化治理。在最开始的阶段，首要目标为与用户沟通，制止打点流量无序增长。因此采取人工治理的方式：由中台同学和点位相关业务同学沟通来推进点位治理，人工治理能够充分了解用户治理诉求，分析点位pv增长原因，在支持业务正常推进的基础上采取定制化的治理措施。通过人工治理的方式，在治理前期取得了一定的治理收益，但随着成本治理的不断推进，治理覆盖的点位、业务线和业务方不断增加，治理变得越来越复杂且难以持续跟进。参照人工治理阶段积累的经验，采用技术化的手段，升级到了半自动平台化治理，从治理实施的角度出发，实现流程化治理，推进了治理前发现异常点位、治理中介入点位治理和治理后成果展示与分析的状态流转，大大提高了治理效率。然而，点位治理不是一劳永逸的事情，为了更好的完成点位可持续治理，日志中台从点位全生命周期的角度出发，实现了点位全生命周期标准化治理，能够修复异常打点、优化冗余打点、下线无用点位，并总结点位相关特性，实现了依据点位特性的长期治理，在对打点的健壮性优化的同时提升了重复治理的效率。

1.1阶段一 人工治理

1.1.1 问题分析

打点用户作为日志中台的核心用户群体，是打点的发起者、使用者，因此是点位治理的主要执行者。打点用户只要有两个核心特点：打点目的多样，点位治理措施多样。打点目的多样是指用户会根据实际业务要求进行打点，例如节日/活动流量打点、实验分析打点、实际需求打点等等。同时打点用户在实现点位治理时，也会有不同的实际操作，例如会选择优化打点代码、对打点实验进行固化或者打点下线、对实际需求打点进行缴费以保证计算和存储资源充足。人工治理阶段依靠着中台同学和业务同学的沟通合作能够在充分满足用户打点目的多样性的同时尽可能提供灵活、丰富的打点治理策略。

△问题分析

点位波动的原因能够从三个维度进行解析说明，分别是业务线、内部因素和外界因素。从业务线角度而言，不同业务线之间因其承担着不同的业务定位，因此其点位波动会受到业务整体的决策而波动，因此点位治理策略应当面向业务线特色而展开。对于较大的业务线，例如手百，需要明确到点位的波动是否与某个细节打点相关。而对于较为独立的业务线，例如贴吧，网盘等，中台更关注业务线整体pv的波动。对于内部因素而言，影响点位pv波动的因素是各种各样的，主要分为三大类，即需求上线导致的打点pv增幅，这其中有因为直接需求、级联需求或需求同步导致的pv涨幅（例如极速版同步手百主版）。有异常打点导致的pv增幅，其中主要包括代码本身异常、流量异常和打点时机异常。在外界因素方面，导致打点pv增幅的原因主要分为三部分：节假日、双十一等商业活动或热点直播导致的pv涨幅，以及实验变更的微观涨幅和APP大盘增长导致的宏观涨幅。综上所述，点位pv波动的因素是较为复杂的，因此点位治理的核心目标是针对各种复杂诱因导致的点位pv波动采取面向用户个性化的点位治理措施，实现高效率灵活的点位治理。

1.1.2 解决方案

阶段一主要依靠人工治理，其步骤可以用以下DAG图说明，支持四大类点位治理模式**【需求普涨、异常修复、活动流量和打点优化】**，模版化的处理步骤能覆盖绝大部分点位治理场景。

1.2 阶段二 半自动治理平台化

1.2.1 问题分析

随着成本治理的不断推进，治理覆盖的点位、业务线和业务方不断增加，治理变得越来越复杂且难以仅靠人力沟通持续跟进，而点位治理方作为打点治理的主要发起方和跟进方，需要频繁的与业务方进行交流，以便于针对点位实际和业务现状发起点位治理。同时点位治理过程需要全过程记录，依靠人工治理架构的点位治理过程使用文档记录全过程，同时点位治理流程中产生的点位治理时间轴、点位治理总览、点位治理成果均以文档的形式记录会有展现效果差、依赖人力更新的问题。同时点位治理流程较为复杂，如果使用人力治理+文档记录的措施缺乏标准的状态流转，无法保证打点治理的高效和质量。

△半自动化平台治理

1.2.2 解决方案

打点治理的涉及的方方面面非常多，按照时间顺序而言，主要分为异常点位的发现和挖掘、面向异常点位的治理实施、以及治理后成果的总结和治理全局分析。对于涉及的主体而言，打点治理主要涉及的被动主体为点位用户以及点位信息，主动主体为点位治理方，对点位本身而言，打点治理流程需要感知点位异常波动、整理点位相关基础信息【业务线、负责人、历史相关需求】等、最终整理完成点位自身特色信息【点位属性是活动点位、基础框架点位等】。对于点位治理方而言，需要针对异常点位发起点位治理【通过如流群内部消息面向业务同学】、需要根据点位自身情况选取点位治理策略【打点优化、异常治理、成本追缴】等，同时在点位治理流程中，点位治理负责人需要及时跟进点位治理情况，推进点位治理信息，在治理完成后需要总结点位治理结果报表，并完成阶段性总结。对于业务方而言，用户需要感知点位pv波动信息、点位治理需求并给出点位治理及时反馈。因此在打点治理的重要场景上，主要的难题为：需要形成点位治理【前期、中期和后期】的规范化治理流程，有效推进点位治理状态的流转【发现异常、介入治理、推进治理、完成治理】；由于点位治理是面向用户导向的，其中涉及到大量的沟通成本，为了加速办公效率，针对IM沟通需要做专门的优化。针对上述问题，日志中台推进了打点半自动化治理平台的建设，实现了治理标准流程化、办公沟通智能化、点位治理高效化。

△一站式成本治理平台

成本治理平台将打点治理分为三个阶段**【治理前-异常波动点位挖掘阶段】，【治理中-目标点位介入治理阶段】，【治理后-治理成果展示&分析阶段】**。

在治理前期【异常波动点位挖掘阶段】，该阶段核心为实现一个定时例行任务，该任务定时获取所有点位的天级pv，并根据异常波动识别算法判别出异常点位，并组装该点位的其他相关信息（业务线、是否是实时流点位等），最终完成异常点位信息的下发和邮件通告。异常点位挖掘任务依托定时任务调度系统完成开发，实现算子高效配置，任务定时准确执行，能够有效挖掘出异常点位信息。

在治理实施中期【目标点位介入治理阶段】，按照点位治理状态的不同，分为三个核心页面进行综合治理，即待治理页面，正在治理页面和治理完成页面。其中待治理页面主要展示由【异常波动点位挖掘阶段】所得到的异常点位列表，在点位负责人甄别该点位确实符合点位治理要求后，即可一键建群触发点位治理流程。触发后，该点位即可展示在正在点位治理页面，针对目标点位治理，点位治理负责人即可按照【点位治理默认状态流转图】或【自定义算子点位治理状态图】完成点位治理，在治理过程中，平台使用企业办公IM企业机器人来实时推送点位治理模版信息【点位治理背景、点位治理缴费文档等】，进而加速点位治理过程。同时在点位治理过程中，数据库会记录点位状态变更时间轴，实时记录点位治理状态。当点位流程治理完成后，点位会移入已经治理完成的点位页面。已经治理完成点位页面会同步至指定MySQL数据库中，智能报表平台会针对该数据库做实时数据分析和可视化报表生成。

在治理后期【理成果展示&分析阶段】该阶段核心是展示指定时间范围内的治理效果【已经治理pv、已治理的点位个数】，以及分析相关指标【各个治理种类的点位数目、已经追缴的成本金额】。治理平台采取可视化智能报表平台完成对点位治理的趋势分析，按照时间顺序对已经治理的pv数和点位个数完成了对点位治理的分析。

△办公IM成本治理机器人

在点位治理过程中，点位治理负责同学需要和点位负责同学、点位相关RD有频繁且密集的沟通，为了提高业务沟通效率，点位治理平台接入 办公IM企业级开发机器人【成本治理机器人】，成本治理机器人实现了全流程的治理加速，在治理发起时，点位负责人能够针对异常目标点位一键发起群聊，该群聊名为【点位监控】（相关）点位流量上涨。在治理发起后第一时间，成本治理机器人会同步点位基本信息、点位涨幅pv等，通报使用自动化通报模版。在点位治理推进中，如流机器人支持发送自定义信息并@相关业务人员完成治理状态推进。

1.3 阶段三 点位全生命周期标准化治理

1.3.1 问题分析

△打点全生命周期

点位治理不是一劳永逸的事情，为了更好的完成点位可持续治理，日志中台从点位角度出发实现了点位全生命周期标准化治理架构。打点本身是点位治理的重要对象，同时打点本身自身也有着足够的信息量，例如，点位本身会因为业务下线或业务场景的迭代而成为无用点位；点位本身会因为打点开发代码 BUG而成为异常点位或是冗余点位；同时点位自身因为其长期存在，进而会在一定时间内长期波动，导致需要点位治理频繁介入。因此点位治理问题需要在点位生命周期维度完成对无用点位的下线；对有异常问题的点位完成修复、对于冗余点位的优化；在点位长期波动角度，完成基于点位特性的高效治理，而非是机械重复的全流程点位治理。

1.3.2 解决方案

1.3.2.1  基于点位特性持续治理

基于点位特性持续治理，图中是某运营活动相关点位pv波动图，图中可以清晰看到，该点位在所示周期内出现了三次点位波动，因为该点位属于活动运营性质点位，因此在春节期间、618活动期间以及暑假活动运营期间，出现了多次波动，如果按照常规治理手段，需要多次频繁介入，为了在持续性治理中提高治理效率，应当结合点位业务属性，构建出治理经验总结，在后续多次治理中不断完善治理属性，即可根据历史治理经验实现既定治理措施。我们将点位根据业务属性而形成的分类称之为“点位特性”，而根据点位特性的操作化治理称之为“基于点位特性的持续治理”，实践表明，基于点位特性的持续治理流程针对点位多次治理，大大加速效率。例子中的运营活动点位，在得知其活动属性的基础上，仅需关注涨幅与活动映射关系以及预估流量是否与预期相符合即可，无须重复治理流程。

△基于点位特性持续治理

打点治理是一个长期持续性的操作，单个点位存在多次介入治理的可能性，因此考虑到点位的持续性治理是非常重要的。在长期的点位治理中，点位因其个性化特色，具有自身属性。结合点位自身特色与规则介入，能够在持续性治理操作中实现基于点位特性的治理。从点位特色出发，常见的点位种类有如下六种，分别为单需求类型点位、复合需求类型点位、活动属性类型点位、级联需求类型点位、实验类型点位、框架性质类型点位。其中不同点位种类具有自身的相应的特征，因此应当采取相关的治理策略，进而大大降低了二次治理的难度和工作量。

下面是常见点位特性的说明及相应的再次治理策略：

• 单需求类型点位，该类点位上下游关系较为简单，点位定位明确，主要完成单一或固定类型的需求，因此其涨幅与需求之间关联，对于二次治理时，重点关注点位所对应的需求方即可，治理策略较为简单。

• 复合需求类型点位，该类点位往往是多业务方共用打点，执行不同类型的需求，因此再次治理时，需要补充记录点位使用拓扑关系，完善点位下游关系。

• 活动类型点位，该类打点往往与节假日/运营活动强关联，例如小说相关打点往往和寒暑假密不可分，手百皮肤活动往往与运营活动强相关，对于此类打点，需要核实对应的活动，并保证容量充足即可。

• 级联需求类型点位，该类打点往往提供一个基础性的功能，例如工具性质打点，这类打点并不直接作用于业务方，而是为业务方提供第三方能力，因此其上涨与自身无关，此类打点需要核实符合预期即可。

• 实验类型点位，该类打点往往与策略实验放量相关，具有一定的活动周期属性，但是与活动属性点位不同的是，实验复合预期后可能会固化，需要核实长期上涨带来的费用。

• **框架性质类型打点，**该类打点作为手百等APP的基础打点，承载着多项核心功能，往往打点量级较大（单点位可达百亿）正常涨幅波动也较大（天级波动可达10亿上下），其波动需要结合DAU大盘涨幅进行分析，往往无法与某些需求直接关联。

  

  △治理角度的常见点位分类

  1.3.2.2  推进无用点位下线

  随着业务的持续迭代与推进，点位的状态也在不断更新，一些点位会逐渐成为无用点位。无用点位因其自身属性分为两大类：无流量点位和有流量无使用点位，其中无流量点位往往因为实验的下线或业务线的变更导致点位无流量，而有流量无使用点位往往因为业务的优化升级或是日常迭代导致点位依然有上报，但是不再有下游使用，上报的数据内容也不再有访问记录。其中无流量点位会消耗一定的数据分析和维护成本，并对相关分析带来一定影响，而有流量无使用的点位则会占用一定的计算和存储资源。因此，推进无用点位下线是点位全生命周期治理的重要一环，日志中台及相关数据存储团队形成了完善的无用点位下线流程。

△无用点位下线流程图

在点位负责人完成上线后，中台及相关数据存储团队会进行例行的无用点位识别任务，当识别出无用点位后，会通知相关点位负责人，若点位负责人支持点位下线，则点位会进入预下线状态，当点位在一定时间段内仍无相关业务反馈，则该点位会完成下线。若点位负责人因业务特殊需求，则能够继续保留该点位，若该点位超过三次被识别为无用点位则会报备总监确认，结合业务实际则可以录入白名单。

△基于鉴权信息访问判别来源

无用点位识别任务的核心在于识别出有流量但是没有下游使用的点位，识别任务会根据相关业务的若干数据表的鉴权信息筛选出相关的下游访问来源，这些下游访问来源包括但不限于实验分析平台、数据分析平台、报表平台，相关业务使用和一些定时例行任务。当筛选出相关点位的具体下游访问来源之后，即可联合下游访问来源的具体业务信息识别出该点位是否确实无人使用，进而判断出无用点位。

1.3.2.3  异常点位修复&冗余点位优化

△异常点位修复&冗余点位优化

为了更好的完成点位治理，需要对打点潜在问题进行分析，进而能够根据潜在问题制定相应的解决方案。结合打点实际，业务实际和中台业务逻辑可以发现，打点存在有几类问题：冗余打点浪费了一定的资源，多条打点公共参数相同，仅仅业务参数有差异，但是依然分开若干条上报；对于比值类实验指标，不同的打点量级的实验效果是一致的，但依然打了较大量级的日志条数；异常打点不符合业务预期，异常上报了一定量级的日志，点位缺乏分级别处理无法做到重要点位高优先级处理。为了解决上述问题，我们进行了针对性的方案优化，针对冗余打点采取合并上报、打点采样等打点优化措施，针对异常打点采取【发现异常、确认异常，最终修复异常】的工作流程。

02 项目收益&业务反馈

日志中台点位治理实践项目对点位实现各种灵活治理措施，包括但不限于打点优化、异常修复、成本追缴和活动流量观察。在点位治理项目上线后，助力业务方发现10+潜在风险点，手百每人每天上报日志减少上百条。治理项目每年治理上千亿pv，节省数百万的用于计算、存储的年化成本费用。

在治理过程中，我们坚持用户导向，点位治理流程协助用户方发现很多问题，排查了潜在异常，节约了很多资源，也收到很多高质量的业务方真实反馈。

△业务高质量反馈

03 总结与展望

△总结与展望

日志中台打点治理实践方案已经取得了一定的项目收益，协助用户优化了了打点体验，提升了打点质量，升级了业务性能，同时也助力了手百等业务的稳健、高质量发展，在未来日志中台会持续打造业界领先的打点治理方案，进一步优化用户体验，帮助用户精细化排查点位波动的原因，更为精准化的定位问题原因，精密化提升打点收益与产出，切切实实使每一次打点都取得超出预期的收益。同时进一步助力业务发展，降低手百每人每天上报的日志数目，在有限的打点资源内尽可能创造更高规模的收益。同时随着日志中台对于事件的支持，打点治理方案会探索基于事件的pv治理策略，支持更细粒度的打点治理。

-----END------

推荐阅读

从数字化到智能化，百度 SRE 数智免疫系统的演进和实践

走！Ké武汉，看百度智能云生态大会

名列前茅！百度文心大模型4.5及X1在中国信通院“方升”大模型基准测试中表现优异

飞桨新一代框架3.0正式发布：加速大模型时代的技术创新与产业应用

中国人工智能产业发展联盟（以下简称“AIIA”）紧密跟踪大模型和智能体的技术发展与行业应用动态，构建并发布了“方升”（FactTesting）大模型基准测试体系，自2024年以来已对国内外开源与闭源大模型开展了6轮能力监测，累计测试了200余个大模型，持续跟踪其技术演进与表现，为行业技术选型与能力评估提供了重要依据。2025年，评测范围进一步扩展至多模态理解、文生图、文生视频等领域，并率先开展智能体测试的研究与实践，初步构建了智能体测试验证平台，为产业界提供全面的技术评估参考。

2025年4月9日，在南京召开的中国人工智能产业发展联盟第十四次全体会议上，中国人工智能产业发展联盟正式发布“方升”大模型基准测试结果（2025年1季度）。

“方升”大模型基准测试结果发布现场

在权威发布环节，AIIA 总体组组长、中国信通院人工智能研究所所长魏凯发布了“方升”人工智能基准测试结果及测试观察。在大语言模型测试结果中，文心大模型4.5在基础能力结果、文心大模型X1在推理能力结果中均名列前茅。

大语言模型-基础能力测试结果

大语言模型-推理能力测试结果

3月16日，百度正式发布文心大模型4.5和文心大模型X1。

文心大模型4.5是百度自主研发的新一代原生多模态基础大模型，通过多个模态联合建模实现协同优化，多模态理解能力优秀；具备更精进的语言能力，理解、生成、逻辑、记忆能力全面提升，去幻觉、逻辑推理、代码能力显著提升。

文心大模型X1具备更强的理解、规划、反思、进化能力，并支持多模态，**是首个自主运用工具的深度思考模型。**作为能力更全面的深度思考模型，文心大模型X1兼备准确、创意和文采，在中文知识问答、文学创作、文稿写作、日常对话、逻辑推理、复杂计算及工具调用等方面表现尤为出色。

文心一言官网

目前，两款模型已在文心一言官网上线，免费向用户开放。（yiyan.baidu.com）

2025是大模型技术全面迭代的一年，百度将在人工智能、数据中心、云基础设施上更大胆地投入，打造更好、更智能的下一代模型。

----------END----------

推荐阅读

飞桨新一代框架3.0正式发布：加速大模型时代的技术创新与产业应用

即刻体验！文心大模型X1现面向企业用户全面开放！

一篇论文，看见百度广告推荐系统在大模型时代的革新

前沿多模态模型开发与应用实战3：DeepSeek-VL2多模态理解大模型算法解析与功能抢先体验

秒哒首发即爆发！上线首日吸引2万用户，打造3万应用！

人工智能技术日新月异，深度学习框架作为技术底座深刻影响着算法创新的速度与产业落地的深度。飞桨框架以五大核心突破回应时代命题，正式发布3.0版本。飞桨框架3.0实现了从底层硬件适配到顶层开发体验的全面进化，在训练效率、性能、兼容性等关键指标上建立新标杆，作为支撑千行百业智能化转型的“AI 操作系统”，此次升级不仅是技术参数的迭代，更是面向大模型工业化生产范式的革命性突破。无论是前沿算法研究还是产业级大模型落地，飞桨框架3.0都将成为开发者的首选利器。

作为中国首个自主研发的产业级深度学习平台，飞桨一直坚持开源路线，支撑产业智能化升级。2025年4月1日，飞桨框架迎来重大更新，发布飞桨框架3.0正式版。飞桨框架3.0版本不仅延续了飞桨框架2.0系列动静统一、训推一体的特性，更在自动并行、神经网络编译器、高阶自动微分等方面取得突破，为大模型时代的技术创新与产业应用提供了强大支撑，为开发者打造了一站式、高性能的深度学习开发体验。

飞桨框架3.0具备以下五大新特性：

1）动静统一自动并行：通过少量的张量切分标记，即可自动完成分布式切分信息的推导，Llama 预训练场景减少80%的分布式相关代码开发。

2）大模型训推一体：依托高扩展性的中间表示（PIR）从模型压缩、推理计算、服务部署、多硬件推理全方位深度优化，支持文心4.5、文心X1等多款主流大模型，DeepSeek-R1满血版单机部署吞吐提升一倍。

3）科学计算高阶微分：通过高阶自动微分和神经网络编译器技术，微分方程求解速度比 PyTorch 快115%。

4）神经网络编译器：通过自动算子自动融合技术，无需手写 CUDA 等底层代码，部分算子执行速度提升4倍，模型端到端训练速度提升27.4%。

5）异构多芯适配：通过对硬件接入模块进行抽象，降低异构芯片与框架适配的复杂度，兼容硬件差异，初次跑通所需适配接口数比 PyTorch 减少56%，代码量减少80%。

01 背景概述

在大模型时代，深度学习框架的重要性愈发凸显，成为推动人工智能技术发展的核心引擎。算法、算力、数据作为人工智能技术的三大要素，其相互作用与协同发展不断催生着新的突破。越来越多的实例证明，算法创新能够发挥出更为显著的威力。DeepMind 的 AlphaFold3通过动态扩散算法突破蛋白质结构预测精度，已成功应用于抗疟疾等药物分子设计；DeepSeek 通过算法创新，成功提升了 DeepSeek V3模型的性价比，大幅降低了训练成本。这些突破性进展表明，算法创新正在重构技术发展的成本曲线。

然而，算法创新并非易事，当前算法工程师和科研人员在使用现有深度学习框架进行算法创新时，仍面临诸多挑战。

1）大模型分布式开发门槛高：大模型参数规模庞大，其分布式训练需使用复杂的并行策略，包括数据并行、张量并行、参数分片并行、流水线并行、序列并行、专家并行等。大模型开发中，如何实现多种并行策略的高效协同已成为关键瓶颈。

2）模型推理部署困难重重：由于算法训练和推理任务的计算、通信存在较大差别，算法工程师在完成模型算法创新后，往往难以直接应用于推理部署，需要大量的工程开发工作。

3）前沿模型架构灵活多变：科学智能（AI for Science）等新兴领域的快速发展，对深度学习框架提出了新的要求，包括求解复杂微分方程所需的高阶自动微分、傅里叶变换等科学计算操作、复数的高效运算等。

4）模型极致性能优化难度大：以大模型为代表的很多场景对训练推理速度有严苛要求，为突破计算瓶颈，工程实践中常需通过手写 CUDA 内核代码进行性能优化，这对算法工程师的底层编程能力提出了极高要求。

5）异构芯片适配成本高：AI 应用场景丰富多样、算力需求巨大，单一芯片难以满足业务需求。而不同芯片之间的硬件架构、软件栈成熟度、开发接口差异大，业务适配成本高、软硬协同优化难。

为此，飞桨新一代框架3.0应运而生：该版本提供了丰富的深度学习相关的各种开发接口；表示层专注于计算图的表达与转换，通过高可扩展中间表示 PIR，实现动转静、自动微分、自动并行、算子组合以及计算图优化等核心功能；调度层负责对代码或计算图进行智能编排与高效调度，支持动态图和静态图两种不同的执行模式；算子层由神经网络编译器 CINN 和算子库 PHI 共同构成，涵盖了张量定义、算子定义、算子自动融合和算子内核实现等关键功能；适配层则用于实现与底层芯片适配，包括设备管理、算子适配、通信适配以及编译接入等功能。

飞桨框架3.0架构图

飞桨框架3.0凭借强大的功能和优化的设计，帮助算法工程师和科研人员以更低的成本进行算法创新，并实现产业应用。以百度文心大模型为例，飞桨框架3.0在训练、推理等方面为文心大模型提供端到端优化，训练方面重点提升训练吞吐、训练有效率和收敛效率，集群训练有效率超过98%；推理部署方面通过注意力机制量化推理、通用投机解码等技术提升推理吞吐和效率；全面支持文心4.5、文心X1等大模型的技术创新和产业应用。

02 全面支持自动并行训练

降低大模型开发训练门槛

在大模型时代，随着模型规模和训练数据量的不断增长，传统的单机单卡训练已无法满足需求，分布式并行训练成为加速大模型迭代的关键。然而，无论是动态图还是静态图，当前市场上的并行训练框架普遍存在使用成本高的问题。开发者既要熟知模型结构，还要深入了解并行策略和框架调度逻辑，使得大模型的开发和性能优化门槛非常高，制约了大模型的开发和训练效率。

针对这一痛点，飞桨提出了动静统一自动并行方案。该技术通过原生动态图的编程界面与自动并行能力，同时保障了灵活性和易用性，大幅降低了大模型并行训练的开发成本；同时，利用框架动静统一的优势，一键转静使用静态优化能力，提供极致的大模型并行训练性能。开发者仅需少量的张量切分标记，框架便能自动推导出所有张量和算子的分布式切分状态，并添加合适的通信算子，保证结果正确性。具体工作流程如下图所示：

动静统一自动并行流程图

飞桨框架3.0动静统一自动并行技术的具体特点如下：

1）简单易用，大幅降低大模型并行训练开发成本。飞桨自动并行功能允许用户在不考虑复杂分布式通信的情况下完成算法实现。仅需借助少量 API 调用，即可将算法转换为并行训练程序，显著简化开发过程。以 Llama2的预训练为例，传统实现方式需要开发者精细调整通信策略，以确保正确高效执行，而自动并行实现方式相比传统方式减少80%的分布式核心代码，极大降低了开发复杂度。

2）全面可用，适用于众多大模型训练场景。**基于飞桨大模型开发套件（PaddleNLP、PaddleMIX），飞桨框架已全面验证 Llama、QwenVL 等从大语言模型到多模态模型的预训练、精调阶段的自动并行训练。

3）轻松加速，一键动转静提供极致性能优化。**得益于飞桨框架独特的动静统一设计，用户仅需简单添加一行代码，即可轻松实现从动态到静态的转换。这一转换使得我们能够充分利用多种静态优化技术，匹敌甚至超越经过极致优化的动态图训练效率。

4）协同文心，开源多项大模型独创优化策略。**飞桨协同文心创新实现精细化重计算、稀疏注意力计算优化、灵活批次的流水线均衡优化等，这些优化技术在飞桨框架3.0中开源，助力开发者进行极致的大模型训练性能优化。

未来，我们将进一步探索无需使用张量切分标记的全自动并行，让开发者可以像写单机代码一样写分布式代码，进一步提升大模型的开发体验。

动静统一自动并行训练速度对比

03 大模型训推一体

提升推理部署效率

在完成模型的开发和训练后，我们需要面对推理部署场景的挑战：如何低门槛、低开发成本、快速地将模型部署到业务场景，并提供低时延、高吞吐、低算力成本的推理服务。**自2.0版本起，飞桨便采用了“动静统一、训推一体”的设计理念，3.0版本也继续秉持这一理念，并在大模型场景下持续优化，发挥更大作用。

在推理部署方面，相较于动态图，静态图不仅可部署范围更为广泛，它能够通过整图导出的方式，摆脱对 Python 源代码和执行环境的依赖；而且更适合进行全局调优，可通过手写或者借助编译器自动实现算子融合等方式来加速推理过程。

得益于动静统一的架构和接口设计，飞桨能够完整支持动态图和静态图这两种不同的运行模式，并且具备出色的整图导出能力。飞桨的动转静整图导出成功率高达95%，高于 PyTorch 62%。“训推一体”意味着能够在同一套框架下，尽可能复用训练和推理的代码，特别是复用模型组网代码。**在完成模型的开发训练后，只需进行少量的开发工作，即可实现快速推理部署。**与业界当前先使用 PyTorch 和 DeepSpeed 进行训练，再采用 vLLM、SGLang、ONNXRuntime 等推理引擎进行推理部署的方案相比，飞桨采用训练和推理使用同一套框架的方式，能够有效避免不同框架之间可能出现的版本兼容性问题，以及因模型结构变化、中间表示差异、算子实现差异等带来的困扰。

飞桨训推一体架构设计

大模型的推理部署需要更好地平衡成本、性能和效果，飞桨框架3.0全面升级了大模型推理能力，依托高扩展性的中间表示（PIR）从模型压缩、推理计算、服务部署、多硬件推理全方位深度优化，能够支持众多开源大模型进行高性能推理，并在 DeepSeek V3/R1上取得了突出的性能表现。飞桨框架3.0支持了 DeepSeek V3/R1满血版及其系列蒸馏版模型的 FP8推理，并且提供 INT8量化功能，破除了 Hopper 架构的限制。此外，还引入了4比特量化推理，使得用户可以单机部署，降低成本的同时显著提升系统吞吐一倍，提供了更为高效、经济的部署方案。在性能优化方面，我们对 MLA 算子进行多级流水线编排、精细的寄存器及共享内存分配优化，性能相比 FlashMLA 最高可提升23%。综合 FP8矩阵计算调优及动态量化算子优化等基于飞桨框架3.0的 DeepSeek R1 FP8推理，单机每秒输出 token 数超1000；若采用**4比特单机部署方案，每秒输出 token 数可达2000以上，推理性能显著领先其他开源方案。**此外，还支持了 MTP 投机解码，突破大批次推理加速，在解码速度保持不变的情况下，吞吐提升144%；吞吐接近的情况下，解码速度提升42%。针对长序列 Prefill 阶段，通过注意力计算动态量化，首 token 推理速度提升37%。

DeepSeek 模型单机推理速度对比（H800上256并发不含 MTP 测试）

04 助力科学前沿探索

提升微分方程求解速度

人工智能正以前所未有的方式重塑科学研究范式，成为推动科学发现与技术创新的“超级加速器”。例如，布朗大学团队首次提出物理信息神经网络（PINNs），通过自动微分实现物理约束与数据驱动的结合；NVIDIA 实验室提出全球高分辨率气象预报模型 FourCastNet，预报时长从几个小时缩短到几秒钟；2025年1月，Baker 团队在《Nature》发表研究，利用 RFdiffusion 算法从头设计出能够高效中和眼镜蛇蛇毒中三指毒素的蛋白质。**科学智能（AI for Science）为解决科学问题带来新方法的同时，也对深度学习框架带来诸多新挑战。**对科学问题机理化的探索，需要深度学习框架能够具备更加丰富的各类计算表达能力，如高阶自动微分、傅里叶变换、复数运算、高阶优化器等等；此外，如何实现深度学习框架与传统科学计算工具链的协同，也是需要思考的问题。

为了解决这些挑战，飞桨框架3.0提出了基于组合算子的高阶自动微分技术，如下图所示，该技术的核心思想是将复杂算子（如 log_softmax）拆解为多个基础算子的组合，然后对这些基础算子进行一阶自动微分变换。重要的是，基础算子经过一阶自动微分变换后，其所得的计算图仍然由基础算子构成。通过反复应用一阶自动微分规则，我们可以轻松地获得高阶自动微分的结果。这一机制不仅完美兼容动态图模式和静态图模式，而且在动态图模式下支持 N+1阶微分的灵活拆分，同时在静态图模式下能够进行高效的编译器融合优化。

基于组合算子的高阶自动微分技术

基于飞桨框架的高阶自动微分和编译优化技术，实现了方程求解类模型性能的大幅提升，英伟达 Modulus 的41个不同方程实验显示，飞桨的微分方程求解速度比 PyTorch 开启编译器优化后的2.6版本平均快 115%。此外，飞桨还实现了傅里叶变换、复数运算、高阶优化器等功能，这些方法在航空航天、汽车船舶、气象海洋、生命科学等多个领域都具有广泛的应用潜力，为科学研究和工程实践提供了有力的支持。在模型层面，我们成功研发了赛桨（PaddleScience）、螺旋桨（PaddleHelix）等系列开发套件，为科学计算提供了更为便捷、高效的解决方案。飞桨对 DeepXDE、Modulus 等主流开源科学计算工具进行了广泛适配，并成为 DeepXDE 的默认推荐后端。

飞桨 AI for Science 全景图

05 神经网络编译器技术

实现框架通用性能提升

在众多深度学习的应用场景中，如大模型训练、自动驾驶等，对模型的训练与推理速度均提出了极高的要求。然而，**要实现训练与推理速度的提升并非易事，这需要我们紧密结合模型结构与硬件特性，开展大量的工程实现与优化工作。**在模型结构层面，模型结构正日益呈现出多样化的趋势，从基础的全连接网络，到复杂的卷积神经网络、循环神经网络、Attention 网络、状态空间模型、图神经网络等，每一种模型结构都拥有其独特的计算模式与优化需求。在硬件特性方面，算力的增长速度远远超过了访存性能的提升，访存性能的瓶颈限制了访存密集型算子（如归一化层、激活函数等）的执行效率。特别是，当前市场上硬件平台种类繁多，我们需要投入大量的人力物力，进行针对性的优化工作，这将严重拖慢算法创新和产业应用的速度。

让我们通过一个实例来阐释这一点。我们以 Llama 模型中经常使用的 RMS Normalization（Root Mean Square Layer Normalization）为例，其计算公式相对简单明了。

假设我们需要实现 RMS Normalization 的计算，最简单的办法是，我们可以使用飞桨框架提供的张量运算开发接口，调用平方、求和、除法、开根号等操作来完成，代码如下：

class RMSNorm(paddle.nn.Layer):
    def __init__(self):
        super().__init__()
        self.variance_epsilon = 1e-6
        self.weight = paddle.create_parameter(shape=[768], ...)
        
    def forward(self, x):
        variance = x.pow(2).mean(-1, keepdim=True)
        x = paddle.rsqrt(variance + self.variance_epsilon) * x
        return x * self.weight

上述代码开发简单，但是由于存在大量的访存操作导致性能很差，且显存占比较多；为了突破访存瓶颈，开发者可以选择通过手写 CUDA 代码的方式实现一个融合的 FusedRMSNorm 算子，但是对于开发者要求更高，开发成本也更高，更重要的是这种方式极大降低了可维护性和灵活性。

为此，飞桨框架3.0研制了神经网络编译器 CINN（Compiler Infrastructure for Neural Networks），相比于 PyTorch 2.0的 Inductor 加 Triton 的两阶段编译方案，CINN 支持直接从神经网络中间表述编译生成 CUDA C 代码，通过一阶段的编译方案，CINN 避免了两阶段编译由于中间表示信息传递和表达能力限制所造成的信息损失，具备更通用的融合能力和更好的性能表现。具体一些技术创新如下：

1）以 Reduce 为核心的算子融合技术。摒弃传统的粗粒度 pattern 匹配模式，支持维度轴自动变换对齐融合，在保证计算正确性的同时，具有更强的算子融合能力，带来更大的性能优化潜力。

2）动静态维度的高效后端 Kernel 调优技术。算子全面支持 reduce、broadcast、transpose 等多种算子的不同组合方式，针对各类算子组合和数据类型，自适应不同维度大小与不同硬件配置，进行全场景高效调优。通过自动向量化提高 BF16、FP16等小数据类型的访存效率。通过分析与分桶机制，实现动静态运行时配置生成，根据运行时的硬件配置，在无需 profiling 的情况下生成高效的 kernel。

3）动态维度的复杂表达式化简技术。建立了分层化简体系，Lower、Schedule、CodeGen 阶段执行不同等级化简方法，解决传统化简方法中多场景叠加后化简困难、化简不彻底问题。实现了复杂表达式结构化简，抽取融合算子经过编译、调优后的固定子结构进行专项化简，且灵活支持自定义化简方法。

神经网络编译器 CINN 流程图

借助神经网络编译器技术，我们能够在维持高度灵活性和易用性的基础上，实现性能的显著提升。以下为 A100平台上 RMSNorm 算子的性能测试结果：相较于采用 Python 开发接口组合实现的方式，经过编译优化后的算子运行速度提升了4倍；即便与手动算子融合的方式相比，也实现了14%的性能提升，在灵活性与高性能之间寻找到了较为理想平衡点。我们在 PaddleX 开发套件里选取了超过60模型进行实验，使用 CINN 编译器后超60%模型有显著性能提升，平均提升达27.4%。重点模型相比 PyTorch 开启编译优化后的版本平均快18.4%。

神经网络编译器 CINN 训练速度对比

06 标准化统一硬件适配

加速软硬协同优化

在深度学习的创新探索与产业落地进程中，单一芯片往往难以满足复杂多变的业务需求，因此通常需要融合运用多种芯片来构建解决方案。大模型应用对于算力的需求极为庞大，而单一芯片的供应数量有限，远不足以支撑大模型的高效运行。不仅如此，不同场景对芯片性能有着差异化的严苛要求，单一芯片更是难以全面满足。例如，在大模型训练场景中，需要芯片具备大显存、高带宽以及高可靠性的特性；自动驾驶场景则强调低时延与高可靠性，以保障行车安全；端侧场景则聚焦于低功耗，以延长设备的续航时间。

飞桨框架自发布之初就考虑了多硬件适配的需求，历经持续迭代与演进，3.0版本构建了一套成熟且完善的多硬件统一适配方案：

1）飞桨聚焦于硬件接口的抽象。飞桨将硬件接口细分为设备管理、计算执行、分布式通信等多个类别，通过标准化的硬件接口成功屏蔽了不同芯片软件栈开发接口之间的差异。通过合理的抽象，减少了适配所需的接口数量，以昇腾芯片适配为例，初步跑通所需适配接口数比 PyTorch 方案减少56%，适配代码量减少80%。

2）基于标准化适配接口的定义，飞桨实现了松耦合、可插拔的架构。在此架构下，每类芯片仅需提供标准化适配接口的具体实现，便能轻松融入飞桨后端，极大地简化了芯片接入的流程。

3）考虑到不同芯片软件栈成熟度的差异，飞桨提供了丰富多样的接入方式，涵盖算子开发、算子映射、图接入、编译器接入等。针对大模型训练与推理需求，飞桨还具备全栈优化能力，如支持动静统一编程范式、超大规模分布式训练技术，提高了模型开发与部署效率。

4）飞桨与芯片厂商携手合作，共同构建了官方代码合入机制、例行发版机制和持续集成测试等研发基础设施，还建立了日级别例行功能与精度监测，保障开发者使用体验。

这些举措提升了研发效率，确保飞桨与各类芯片的适配工作高效、稳定推进。

多硬件统一适配方案

基于前述技术，飞桨与芯片厂商紧密合作，**携手共建蓬勃发展的硬件生态，当前飞桨已与超过40家成员单位开展合作，适配超过60个芯片系列。**飞桨已与24家硬件厂商伙伴达成深度合作，共同推出了飞桨生态发行版。飞桨能够有效屏蔽底层硬件之间复杂多样的差异，为开发者提供简洁易用的开发接口。**开发者只需编写一份代码，就可以让程序在不同芯片上顺畅运行，轻松实现业务的跨芯片迁移。**飞桨的跨平台能力为业务在芯片选择方面带来了前所未有的灵活性，使开发者能够根据实际需求，更加自由、高效地规划业务部署。

07 总结

飞桨框架3.0面向大模型、异构多芯进行专属设计，向下适配异构多芯，充分释放硬件潜能；向上一体化支撑大模型的开发、训练、压缩、推理、部署全流程，并助力科学前沿探索。具备动静统一自动并行、大模型训推一体、科学计算高阶微分、神经网络编译器、异构多芯适配五大新特性。

1）动静统一自动并行：用户只需在单卡程序上进行少量的张量切分标记，飞桨就能将其自动转换为并行训练程序，大幅度降低了产业开发和训练的成本，使开发者能够更专注于模型和算法的创新。

2）大模型训推一体：同一套框架支持训练和推理，实现训练、推理代码复用和无缝衔接，为大模型的全流程提供了统一的开发体验和极致的训练效率，为产业提供了极致的开发体验。

3）科学计算高阶微分：科学计算提供了高阶自动微分、复数运算、傅里叶变换、编译优化、分布式训练等能力支撑，支持数学、力学、材料、气象、生物等领域科学探索，微分方程求解速度比 PyTorch 开启编译器优化后的2.6版本平均快115%。

4）神经网络编译器：采用与框架一体化的设计，能够支持生成式模型、科学计算模型等多种模型的高效训练与可变形状推理，在计算灵活性与高性能之间提供了良好的平衡点，显著降低了性能优化的成本。

5）异构多芯适配：构建了一套成熟且完善的多硬件统一适配方案，通过标准化接口屏蔽了不同芯片软件栈开发接口差异，实现可插拔架构，提供多种接入方式和基础设施，支撑硬件厂商合入4001个 PR，包括26584个 commits。

飞桨框架3.0将为开发者提供一个“动静统一、训推一体、自动并行、自动优化、广泛硬件适配”的深度学习框架，开发者可以像写单机代码一样写分布式代码，无需感知复杂的通信和调度逻辑，即可实现大模型的开发；可以像写数学公式一样用 Python 语言写神经网络，无需使用硬件开发语言编写复杂的算子内核代码，即可实现高效运行。目前3.0正式版本已面向开发者开放，并且兼容2.0版本的开发接口，非常欢迎广大开发者使用和反馈。

---------- END----------

推荐阅读

即刻体验！文心大模型X1现面向企业用户全面开放！

一篇论文，看见百度广告推荐系统在大模型时代的革新

前沿多模态模型开发与应用实战3：DeepSeek-VL2多模态理解大模型算法解析与功能抢先体验

秒哒首发即爆发！上线首日吸引2万用户，打造3万应用！

秒哒，全面开放！

4月2日，文心大模型X1正式上线百度智能云千帆大模型平台，企业用户和开发者登录即可调用API。

文心大模型X1具备更强的理解、规划、反思、进化能力，并支持多模态，是能力更全面的深度思考模型。模型兼备准确、创意和文采，在中文知识问答、文学创作、文稿写作、日常对话、逻辑推理、复杂计算及工具调用等方面表现尤为出色。

据权威测试，在多个公开数据集测评中，文心大模型X1在数学、代码、知识推理等能力上表现优异，超越升级后的DeepSeek-V3-0324。在数学场景中，GSM8K数据集测试后结果显示，文心X1得分95.6，DeepSeek-V3-0324得分93.6；代码生成层面，MBPP数据集测试后结果显示，文心X1得分83.3，DeepSeek-V3-0324得分81.2；在知识推理层面，C-Eval数据集测试后结果显示，文心X1得分88.6，DeepSeek-V3-0324得分85.1；在数学推理层面，Aime2024数据集测试后结果显示，文心X1得分78.6，DeepSeek-V3-0324得分57.1。

在模型服务方面，现可直接通过千帆ModelBuilder调用文心大模型X1 API服务，输入价格低至0.002元/千tokens，输出价格低至0.008元/千tokens，同时支持批量推理场景，满足更多元业务需求。

在模型开发方面，千帆ModelBuilder模型蒸馏支持文心大模型X1作为教师模型，一键实现从“思考模型”到“轻量模型”的知识蒸馏。

在应用开发方面，千帆AppBuilder支持用户基于文心大模型X1，快速搭建具有深思考能力的RAG、Agent、AI搜索、工作流，实现更充分的思考规划、更准确的工具调用、更全面的生成效果，助力企业级大模型应用在千行百业落地。

百度智能云千帆大模型平台始终致力于为用户提供全流程、一站式的AI服务，以开放性、易用性、低成本的平台理念，企业用户和开发者能够更高效地探索大模型应用，提升创新效率，加速各类AI应用从概念到落地的转化，为AI技术在更多领域的拓展与应用注入强大动力。

------END------

推荐阅读

一篇论文，看见百度广告推荐系统在大模型时代的革新

前沿多模态模型开发与应用实战3：DeepSeek-VL2多模态理解大模型算法解析与功能抢先体验

秒哒首发即爆发！上线首日吸引2万用户，打造3万应用！

秒哒，全面开放！

图灵数据洞察平台-TDF（Turing Data Finder）

我们见证了 DeepSeek R1，用强大的推理能力再次点燃 AI 智力增长的火箭。 在上个星期，OpenAI 给 GPT-4o 的一波图像生成更新又让全网陷入了梗图、甚至玩梗视频制造的火热氛围中。