导读

在这个高速发展的信息时代，数据洪流已经成为了企业在数字化转型过程中遇到的核心挑战，而流式计算正是应对无界数据流的利器。然而，随着流式技术的普及与发展，其固有的复杂性也日益凸显：

• 开发门槛高：需要开发者深入掌握事件时间处理、窗口机制、状态管理等复杂概念；

• 运维成本高：实时系统的容错保障、监控告警与性能调优，往往比离线系统耗费更多人力；

• 扩展性差：传统流式架构僵化，难以灵活、高效地响应业务的快速迭代与规模增长。

面对这些挑战，业界共识逐渐清晰：流式计算的未来，不应只属于少数专家，而应成为每个团队都能高效使用的通用能力。为此，一种新的破局思路正在兴起——将流式计算与云原生理念深度融合，构建以 Kubernetes 为底座、以开发者体验为中心的 PaaS 化流式开发平台。

这样的平台，不仅将底层基础设施的复杂性封装于服务之中，更通过配置化、模板化、自动化的手段，把专家经验转化为平台默认能力，真正实现“让实时计算像搭积木一样简单”。这正是本文所要探讨的核心命题：如何基于云原生技术，打造一个高效、可靠、易用的新一代流式计算 PaaS 平台。

01 背景

1.1 流式计算简介

流式计算（Stream Compute）是一种对无界数据流进行实时处理的计算模式。相比于传统的批处理先存储后计算的模型，流式计算会在数据生成时便持续不段的导入、处理和分析，并近乎实时地产出连续的结果。

如果将数据源看做一条奔流不息的“数据河流”：

批处理：修筑水坝，先将河水拦截并蓄水至一定水位线（存储），然后再开闸放水进行计算。这种方式延迟高，但是吞吐量大，适合对时效性不高的海量数据进行离线分析；

• 流式计算：在河床上安装一套实时监测和过滤系统，对流淌过的每一滴水进行即时分析处理。这种方式延迟极低，使业务能够对瞬息万变的业务场景做出及时反应。

因此，流式计算的核心价值就是时效性，将数据分析这个原本应该出现在“事后复盘”的环节提前到“事中干预”甚至“事前预测”。这在例如实时监控、实时风控、实时推荐等关键业务场景中起到了重要的作用。

1.2 传统流式计算核心挑战

尽管流式计算凭借其时效性高的优点，在企业的业务发展中越来越占据了核心地位，但是由于其复杂性，成了制约企业发展的一个障碍，主要分为开发门槛高、运维成本高、扩展性差三个方面。

1.2.1 开发门槛高

当前市面上主流的流式计算框架（如Flink、Spark Streaming等）以及百度自研的流式计算框架TM，虽然功能强大，但是学习路径异常陡峭。开发者不仅需要了解分布式系统的基本原理，还需要了解：

事件时间与处理时间的处理：如何正确处理乱序事件、延迟数据到达时应该怎么处理等等，这些问题是实现精确业务逻辑的前提，同时也是最容易出错的部分；

• 复杂的窗口机制：窗口一般分为滚动窗口、滑动窗口和会话窗口，不同窗口的适用场景与配置差异有很大区别，如果选择不当也将影响业务效果；

• 状态管理机制：有状态计算是流处理的核心问题，而状态的容错、恢复与一致性保障（如Exactly-Once）机制复杂，对开发者的要求也更高。

1.2.2 运维成本高

与离线的批处理不同，流式系统的运维是持续且动态的，这也导致了高昂的运维成本，主要体现在：

容错：在节点故障、网络抖动的情况下，如何保证不重不丢，这就需要复杂的检查点（Checkpoint）机制和保存点（Savepoint）机制；

• 实时监控与告警：流式系统本身的秒级时效也要求运维团队能够秒级发现并响应问题 ，为了达到这个目标，需要针对于任务延迟、反压（Backpressure）、资源使用率等关键指标配置复杂的监控和告警体系；

• 持续的性能调优：流式系统的特点是在运行起来之前，没人知道应该怎么样配置资源参数，因为一点点数据量的波动或者业务逻辑变更都可能引发性能瓶颈，造成延迟或者反压等问题。这就需要运维人员持续地针对于系统进行调参，包括并行度、内存资源参数等等。

1.2.3 扩展性差

早期的各类流式计算框架设计上相对僵化，而难以灵活应对当前快速发展的业务需求，其扩展性主要是受制于以下三个方面：

• 架构耦合度高：计算逻辑与底层资源、存储强耦合，这就导致了升级或迁移时成本较高；

• 弹性伸缩能力弱：部分流式场景可能会面临突如其来的热点问题，如双十一电商大促，面对可能到来的流量高峰，只能提前估算并扩容，同样地当流量低谷到来时，也将造成资源浪费。在高速迭代的场景下，这样不够灵活的模式越来越捉襟见肘；

• 业务迭代不敏捷：实际企业业务场景中实时指标或者计算口径的迭代是家常便饭，而现有框架下一个迭代的上线需要复杂的开发、测试、上线流程，无法满足业务快速发展的要求。

1.3 破局之道——构建云原生流式计算PaaS平台

面对开发复杂、运维繁重、扩展受限等痛点，单纯依赖底层框架已难以为继，我们需要一场开发与运维范式的根本性变革。而云原生与PaaS（平台即服务）理念的深度融合，正式引领这场变革的破局点：将流式计算能力封装起来作为云原生PaaS服务，通过平台化手段实现能力下沉、体验上移。

具体而言，平台以Kubernetes为底座，融合配置化开发模型与智能化运行引擎，达成三大转变：

从“写代码”到“配任务”：通过标准化的表单化配置，抽象事件时间、窗口、状态等复杂概念，用户只需声明数据源、处理逻辑与输出目标，即可生成可运行的流式作业，大幅降低开发门槛；

• 从“人肉运维”到“自动治理”：依托 Kubernetes 的弹性调度、健康探针与 Operator 模式，平台自动完成任务部署、扩缩容、故障恢复与指标采集，将运维复杂度内化于平台；

• 从“烟囱式架构”到“服务化复用”：通过统一的元数据管理、连接器库与模板市场，实现计算逻辑、数据源、监控策略的跨团队复用，支撑业务敏捷迭代与规模化扩展。

这一 PaaS 化转型，不仅继承了云原生技术在资源效率、可观测性与自动化方面的优势，更将流式计算从“专家专属工具”转变为“全员可用服务”，为企业实时数据能力建设提供了可持续、可复制的基础设施。

02 平台架构总览：云原生PaaS的设计内核

云原生技术（容器化、编排调度、微服务、可观测性）流式计算与PaaS结合提供了 “物理基础”，让平台化能力有了落地的土壤。其核心价值在于实现了流式系统的 “标准化、弹性化、可感知”：

标准化部署：通过 Docker 容器化封装流式任务及其依赖环境，消除 “开发环境与生产环境不一致” 的痛点，同时让任务的部署、迁移、复制变得高效统一 —— 这是智能化调度和弹性扩缩容的前提，确保系统能对任务进行精准操作；

• 弹性编排调度：基于 Kubernetes（K8s）的编排能力，实现流式任务的自动化部署、调度与生命周期管理。K8s 的 Pod 调度、StatefulSet 状态管理等特性，为流式任务的水平扩缩、故障转移提供了底层支撑，让资源调整变得灵活可控；

• 全链路可观测：云原生可观测性技术（Prometheus、Grafana、Jaeger 等）构建了 Metrics（指标）、Logs（日志）、Traces（链路追踪）三维监控体系，让流式系统的运行状态 “可视化、可量化、可追溯”。

依托云原生的技术，我们构建了四层架构的流式计算基础设施架构，是PaaS落地的技术底座：

• 硬件资源层：以多地域、多机房的服务器集群为物理支撑，通过分布式部署实现资源规模化与容灾能力，为上层提供算力基础；

• Kubernetes 编排层：由 K8s Master（集成 API Server、调度器等核心组件）和多节点 K8s Node 组成，承担资源调度、任务编排、弹性扩缩的核心能力，实现流式任务的自动化部署、生命周期管理与资源动态分配；

• 容器化流式引擎层：以容器化 Pod 形式运行基于厂内自研流式框架TM的算子，通过容器标准化封装消除环境差异，支持水平扩缩容，让计算能力可根据业务流量弹性适配；

• 可观测性层：通过 Grafana Dashboard 等工具构建全链路监控体系，覆盖指标、日志、链路追踪，为用户实时感知系统状态，及时决策提供了数据支撑。

四层架构的协同，最终实现了**“标准化部署、弹性资源调度、全链路可观测”**的云原生能力，为流式计算的 PaaS 化封装提供了坚实技术底座 —— 将底层复杂的资源管理、引擎调度、监控采集能力下沉，向上层用户暴露 “简单、易用、高效” 的配置化开发接口，完美承接 “降低门槛、简化运维、提升弹性” 的核心目标，让流式计算能力真正以 “服务” 形式交付。

2.1 基石：Kubernetes编排层——资源的智能大脑

Kubernetes 不仅是容器编排引擎，更是整个流式平台的“智能调度中枢”，它是整个平台弹性与自动化的基石。

我们基于K8s实现了流式任务的声明式管理与智能调度。用户提交的任务需求（如所需CPU、内存）被抽象为K8s的定制化资源，而平台的流式任务算子则作为集群内的“自动化运维机器人”，持续监听这些资源状态，并驱动底层执行。其核心价值体现在：

声明式部署与自愈：平台将用户配置的流式任务，自动转换为由Deployment（无状态任务）或StatefulSet（有状态任务，保障Pod名称与存储的稳定）管理的Pod组。当某个Pod因节点故障意外退出时，K8s的控制器会立即在健康节点上重建，通常在秒级内完成故障恢复，实现了从“人工响应”到“自动愈合”的质变。

• 高效运维与弹性基础：Kubernetes的声明式API与资源模型，为流式任务的高效运维与可控弹性提供了完美基础。平台基于此定义了清晰的资源规格与副本数配置。当业务需要扩缩容时，运维人员只需通过平台更新一个配置值，K8s调度器便会自动、可靠地完成整个实例的扩容或优雅终止流程。这种模式将传统的、易出错的手工部署，转变为一种可审计、可回滚、分钟级内完成的标准化操作，为应对计划内的流量洪峰（如大促）提供了敏捷且可靠的弹性能力。

• 资源隔离与高效利用：通过K8s的Namespace和Resource Quota，平台可以为不同部门或业务线创建逻辑上隔离的资源池，避免相互干扰。同时，K8s调度器能基于节点的实际资源利用率，进行智能装箱（Bin Packing），显著提升集群整体的资源使用效率，降低成本。

综上所述，Kubernetes 在此不仅是“运行环境”，更是实现了 资源调度、弹性控制、高可用保障 三位一体的智能大脑。

2.2 载体：容器化流式引擎层——应用的标准化封装

流式计算的复杂性则很大程度上源于环境依赖于运行时差异，而容器化技术是连接用户逻辑与底层资源的“载体”，是彻底解决这一问题的有效方法：

• 统一镜像规范：所有流式作业基于标准化基础镜像构建，预装基础环境配置、监控 Agent 和日志采集器，确保“开发、测试、生产”三环境完全一致；

• 轻量级 Sidecar 模式：每个 Pod 包含主容器（运行流式算子）与 Sidecar 容器（负责日志上报、指标暴露、配置热更新），解耦业务逻辑与平台能力；

• 资源隔离与限制：通过 K8s 的resources.requests/limits精确控制 CPU、内存分配，避免单个任务资源争抢影响集群稳定性。

容器在此不仅是“打包工具”，更是 标准化交付、安全隔离、敏捷迭代 的核心载体

2.3 视野：可观测性层——系统的透明驾驶舱

对于一个持续运行的实时系统，可观测性如同飞机的驾驶舱仪表盘，是保障其稳定、高效运行的“眼睛”和“直觉”。我们构建了三位一体的可观测性体系：

Metrics（指标）- 系统的脉搏：平台深度集成Prometheus，自动采集每个流式任务Pod的核心性能指标，如**数据吞吐率（records/s）、处理延迟（process_latency）、背压状态（is_backpressured）**以及CPU/内存使用率。通过预置的Grafana仪表盘，运维人员可以一眼掌握全局健康状态，将监控从“黑盒”变为“白盒”。

• Logs（日志）- 诊断的溯源：所有容器的标准输出与错误日志，通过DaemonSet方式被统一收集、索引（如存入Elasticsearch）。当指标出现异常时，运维人员可以快速关联到对应时间点的详细应用日志，精准定位错误根源，将排障时间从小时级缩短至分钟级。

• Traces（分布式链路追踪）- 性能的脉络：对于复杂的数据处理流水线，我们通过集成链路追踪，还原一条数据在流式任务DAG中流经各个算子的完整路径和耗时。这使得定位性能瓶颈（例如，是哪部分操作拖慢了整体速度）变得直观而高效。

可观测性在此不仅是“监控工具”，更是 智能决策的数据源泉，为弹性扩缩、用户及时调优提供实时反馈。

△ Grafana监控仪表盘

2.4 协同：架构驱动的核心价值闭环

上述三层并非孤立存在，而是通过 “声明 → 执行 → 感知 → 优化” 的闭环紧密协同：

用户通过配置声明业务意图（如“每分钟统计活跃用户”）；

• Kubernetes 编排层将其转化为可调度的 Pod 拓扑，并由容器化引擎执行；

• 可观测性层持续采集运行数据，形成系统“数字孪生”；

• 平台基于反馈自动触发弹性扩缩、参数调优或故障恢复，最终兑现 SLA 承诺。

这一闭环，使得平台既能 向下充分利用云原生基础设施的能力，又能 向上为用户提供简单、可靠、高效的流式服务体验。开发门槛、运维成本、扩展性三大痛点，由此在架构层面被系统性化解。

03 配置化开发——从“编码”到“装配”

传统开发模式下，工程师们需要用代码手动地去处理流式计算任务的每一个细节，这是需要复杂和强依赖经验的。而配置化的出现，恰如第一次工业革命的珍妮纺纱机，使工程师们从冗杂的重复工作中释放出来，将“手工作坊”升级生成“现代化生产线”，使流式计算开发变得普惠和平民化。

3.1 从代码到配置：开发模式的范式转移

这场革命最初的表现是开发模式的根本性转变：从命令式（Imperative）转变为声明式（Declarative）的范式转移。

• 命令式（写代码）：开发者需要告诉流式系统**“怎么做”（How），这带来了极大的灵活性，但是同时也伴随着极高的复杂度和学习成本；

• 声明式（写配置）：开发者需要声明**“做什么”（What），而“怎么做”则交由底层引擎去完成。

3.2 隐藏的复杂性：从“专家调优”到“配置默认”

常见的流式系统主要由数据源层、核心计算层、时间容错层、结果输出层这四部分：

数据源层和结果输出层，即数据采集和输出的过程，不在我们此次重点讨论的范围内；

3.2.1 核心计算层

对于核心计算层来说，这里负责了流式作业的主要业务逻辑计算，其中

Import算子——数据接入的“第一入口”

• 算子特点：作为流式数据进入核心计算层的“门户”，核心职责是实现多种类型数据源的接入和初步格式解析，为后续计算环节提供标准化的数据输入，是保障数据接入稳定性和兼容性的关键。

• 传统开发模式：需要工程师根据不同的输入数据类型，手动配置响应的链接参数，以进行不同的适配；同时还需要自定义数据解析逻辑，处理不同格式数据的字段映射和类型转换；此外，还需要手动处理连接异常、数据读取重试等问题，避免数据丢失或重复处理。

• 配置化调优：无需手动编写接入与解析代码，支持多种主流数据格式，如CSV、Parquet、PB等；对于PB格式来说，在预置的标准数据格式模板的基础上，支持上传自定义proto后，通过反射将proto内各个字段映射成便于用户处理的Schema；同时系统内部集成连接容错、自动重试、断点续读机制，保证数据接入的稳定性。

Map/Filter算子——数据预处理的第一个环节

• 算子特点：最基础、高频的算子，Map 负责对单条数据做结构化转换（如字段格式清洗、维度扩充、单位换算），Filter 则按业务规则筛选数据（如过滤空值、无效订单、非目标场景数据），是所有业务逻辑落地的前置环节；

• 传统开发模式：开发流式作业时需要工程师手动编写定义转换/筛选逻辑， Map需要逐字段处理数据类型转化，而Filter要精确写明判断条件。除了要保证逻辑精准外，还需要兼顾性能，如复杂字段多层嵌套可能会导致单条数据处理耗时过长，进而引发整条流数据延迟；

• 配置化调优：无需编写一行代码，通过可视化界面配置流式作业，系统会现针对于用户的数据源进行预处理，将多种多样的格式处理成便于用户直接用Sql语句直接处理的格式，Map 操作支持拖拽算子、上传自定义proto等实现，Filter 可通过配置Sql设置过滤规则。

Aggregate算子——业务指标计算

• 算子特点：针对于实例内拿到的这一批数据，对数据做聚合计算（如求和、计数、平均值、TopN等），是实现实时业务指标统计的核心算子；

• 传统开发模式：需要工程师自行定义聚合逻辑，如使用hash map做累加器等，在复杂聚合（如多维度嵌套聚合）的情况下，开发难度大，调试成本高，同时还需要兼顾计算时效和聚合粒度等；

• 配置化优化：直接写Sql的模式极大降低了开发成本，同时底层采用向量化引擎对列进行操作，相较于传统的行处理模式极大提高了计算效率，提高了时效性。

Sink算子——计算结果的最终出口

• 算子特点：作为核心计算层的收尾环节，将最终流式作业产出数据输出至下游目标系统，是实时数据价值落地的关键。

• 传统开发模式：需要工程师手动编写输出代码和配置项，适配下游系统的通信协议与数据格式；同时在Exactly-Once语义要求下，工程师需要协调检查点与Sink算子的事务或幂等写入逻辑，实现难度大；与此同时，批量写入的大小、间隔等参数调优将直接影响吞吐量和端到端延迟。

• 配置化优化：流式开发平台提供了一套标准化的Sink框架，用户只需要指定落盘的目标系统并配置基础参数，即可实现流式计算结果输出。目前已支持落盘Afs，厂内自研消息队列Bigpipe，以及向量化数据库Doris，未来还将进一步支持Redis、Clickhouse等。

• 检查点：在配置化场景下，用户仅需要配置检查点存储路径，而触发时机、容错策略、状态分片与恢复等底层复杂逻辑全部交由系统自动托管，提升了流式作业的可用性和易用性。

3.2.2 时间与容错层

时间与容错层是流式计算中“扛风险，保稳定”的核心支撑，水位控制和状态管理两大模块的底层逻辑复杂且易出错，传统开发模式下调优成本高，而配置化将其完全对用户透明，仅在页面上向用户体现为各个计算环节处理进度。

在流式系统中，水位体现了数据的完整性（水位时间之前的所有数据都已就绪）和可见性（当某条数据处理出现故障，水位便不会再退进，问题由此变得可见），作为这么重要的一个概念，水位控制就显得格外重要，往往需要丰富的经验和多次调优才能达到预期的效果。而在配置化的流式平台中，水位的控制对用户基本透明，仅在运维界面体现为各个算子的当前处理进度，在降低了门槛的前提下又保证了水位的数据完整性和可见性两个特点。

而状态管理是Exactly-Once的重要保证，保障了故障恢复时的数据一致性。传统开发模式下，用户需手动设计状态的存储结构（如选择本地内存还是分布式存储）、编写状态序列化 / 反序列化代码、规划状态分片策略以避免单点瓶颈，还要手动处理状态版本冲突、清理过期状态以防止存储膨胀，每一步都依赖对底层存储和分布式系统的深度理解。而在配置化的帮助下，这些技术被完全封装，用户仅需要配置状态存储的路径，其他则完全交由系统实现。

3.3 实践——Push业务在流式计算开发平台的落地

目前，Push业务实时方向优先在流式计算开发平台落地实践，这一决策不仅契合流式计算场景“低延迟、高吞吐、实时处理”的核心特性，更通过创新的开发方式实现了业务价值的高效释放——相较于传统开发模式中“开发-测试-部署-迭代”的冗长链路，新方案大幅简化了流式任务的编排、调试与上线流程，减少了环境适配、依赖冲突等冗余环节，让开发人员能够聚焦核心业务逻辑的迭代优化，无需投入过多精力在底层环境搭建与运维工作上。最终，这一落地策略显著缩短了业务需求从提出到上线的周期，极大提升了业务更新迭代的效率，助力业务快速响应市场变化、迭代产品功能，同时降低了开发与运维成本，为后续在更多云原生、实时计算相关业务场景的规模化推广奠定了坚实基础。

3.4 降本增效与敏捷迭代

配置化带来的价值是多维且立竿见影的，与我们在背景中讨论过的核心挑战相呼应：

• 大幅降低开发门槛和人力成本：在有了配置化之后，业务部门想要开发流式任务便不再需要向流式部门提需，只需要经过简单培训即可上手，同时也降低了沟通成本，团队的人力成本得以有效优化；

• 显著提升运维效率与系统稳定性：标准化的核心优势就是避免了很多人为错误，同时作为模板一定是经过多次试验后的最佳实践，能够保障作业运行的基线性能。同时，统一的交互界面将各个操作接口收口到一个平台上，极大降低了操作成本，版本管理、作业启停变得轻而易举，极大提升了运维效率；

• 极致优化资源利用：声明式的资源配置让流式系统可以更加灵活地进行资源扩速容调度和优化，避免了资源浪费或瓶颈；

• 赋能业务敏捷迭代：从前每个简单的迭代（例如将落盘窗口从5分钟修改成15分钟）都需要走开发-测试-上线的繁琐流程，往往会耗时半天至一天，而有了配置化后，仅仅需要在配置界面修改一个参数并重新发布部署即可实现修改，实现了真正的“敏捷开发”，让业务创新快人一步。

04 总结与展望

通过构建基于 Kubernetes 的云原生流式计算 PaaS 平台，我们不仅解决了传统流式系统“开发难、运维重、扩展弱”的三大痛点，更完成了一次开发范式的跃迁——从“手写代码、手动调优”走向“配置驱动、平台兜底”。开发者不再需要深陷于资源调度、状态管理、容错机制等底层复杂性，而是聚焦于业务逻辑本身，真正实现“所想即所得”的流式应用构建体验。这一转变的背后，是平台将多年积累的流式计算最佳实践，以标准化、自动化的方式内嵌于架构之中。无论是时间语义的精准处理，还是 Checkpoint 与 Exactly-Once 的默认保障，平台都在默默承担起“专家角色”，让普通开发者也能轻松驾驭高可靠、高性能的实时计算任务。

展望未来，立足于当前稳固的云原生底座，平台的演进路径清晰可见：

弹性智能化：当前基于可观测层丰富的监控指标，为引入更精细的自动化弹性策略奠定了坚实基础。后续，我们将探索基于自定义监控指标（如水位延迟、CPU使用率、吞吐量波动）的HPA，让资源扩缩容能紧贴真实业务负载，在保障SLA的同时进一步优化成本。

• 运维自治化：在大模型能力快速发展的当下，基于多年积淀的流式工程经验方案，在RAG技术的加持下构造流式服务运维智能体，实现运维自治化。

• 体验服务化（Serverless）：在配置化开发之上，最终极的体验是让用户完全感知不到底层引擎与基础设施。未来，平台将向流式计算FaaS（Function-as-a-Service）深化，用户只需提交一段业务处理函数或SQL，平台即可自动完成资源调度、引擎选择与任务生命周期管理，实现真正的“按需计算”。

导读

本文深入介绍了百度一站式全业务智能结算中台，其作为公司财务体系核心，支撑多业务线精准分润与资金流转。中台采用通用化、标准化设计，支持广告、补贴、订单等多种结算模式，实现周结与月结灵活管理。通过业务流程标准化、分润模型通用化及账单测算自动化，大幅提升结算效率与准确性，确保数据合规与业务稳健发展。未来，中台将推进全业务线结算立项线上化、数据智能分析，进一步提升数据分析智能化水平，为公司业务发展提供坚实保障。

01 概述

结算中台作为公司财务体系的核心组成部分，承担着多业务线分润计算、结算及资金流转的关键职能。采用通用化、标准化的设计理念，结算中台能够高效支撑公司内数十个业务线的分润需求，确保广告收入、订单收入、内容分发的精准结算，为公司的财务健康与业务稳健发展提供坚实保障。结算中台建设的核心目标是: 构建高效、标准化、智能化的结算中台体系，支撑多业务线分润计算与资金流转，确保结算数据准确性、高时效披露及业务快速迭代能力，同时降低运维复杂度，推动全业务线结算线上化管理。

结算中台已对接了百家号业务、搜索业务、智能体业务、小说等多个业务线的结算需求， 支持广告分润、补贴分润、订单分润三种结算模式。不同业务线根据各自的业务场景使用不同的结算模式，确保每个业务的收益分配准确无误。结算中台功能分层如图：

02 基本功能

1. 结算模式

结算中台支持三种结算模式，以适应不同业务场景的结算需求：

• 订单结算：基于直接订单数据，按照订单实际金额与分成策略进行分润计算。

• 补贴结算：针对特定业务或用户群体，提供额外的收益补贴，以增强业务的市场竞争力。

• 广告结算：根据分发内容的广告变现与渠道分成比例，精确计算媒体与内容的实际收益。

2. 结算能力

结算中台支持周结与月结两种结算能力：

• 周结：适用于需要快速资金回笼的业务场景,比如短剧快速回款以后能够再次用于投流, 确保资金流转的高效性。

• 月结：作为默认的结算周期，便于公司进行统一的财务管理与账务处理。

3. 账单测算自动化

结算中台支持重点业务账单自动测算，通过预设的分润模型，自动计算每个渠道、每位作者的应得收益，生成测算报告。这一自动化过程显著提升工作效率，减少人为错误，确保结算数据的绝对准确。

03 需求分析

在推进公司结算业务时，我们致力于实现统一化、标准化，规范业务流程，并确保数据合规化治理，我们面临着诸多问题与挑战，具体表现如下：

1. 流程与规范缺失

• 结算流程管理混乱：存在结算需求未备案即已上线的情况，或者备案内容与实际实现不一致，甚至缺乏备案流程。

• 日志规范陈旧：广告分润场景中，内容日志打点冗余，同时缺少扩展性，导致对新的业务场景无法很好兼容。

2. 烟囱式开发成本高

• 标准化与统一化需求迫切：之前，各个结算业务维护各自的结算系统，涉及不同的技术栈和结算模型，线下、线上结算方式并存，导致人工处理环节多，易出错，case多，管理难度大。为提高效率，需实现结算业务的标准化与统一化，并拓展支持多种业务结算模式。

• 分润模型通用化设计：多数业务结算方式相同，同时账单计算逻辑也相似或者相同，没有必要每个业务设计一套逻辑，需要做通用化设计。

3. 业务迭代中的新诉求

• 测算系统需求凸显：在业务快速迭代的过程中，许多业务希望尽快看到结算效果，以推进项目落地。因此，构建高效的测算系统成为迫切需求，以加速业务迭代和决策过程。

• 提升作者体验：为提升作者等合作伙伴的满意度和忠诚度，结算数据需实现高时效披露，确保他们能及时、准确地获取收益信息。结算账单数据的产出依赖百余条数据源，要保证数据在每天12点前产出,困难重重

• 数据校验与监控机制：结算数据的准确性和质量直接关系到公司的财务健康和业务发展。因此，需建立完善的数据校验和监控机制，确保结算数据的准确无误和高质量。

04 技术实现

根据结算中台建设的核心目标，结合业务痛点，在结算系统建设中，基于通用化、标准化的理念，从以下五个方面来搭建统一的、规范化的结算中台。

• 业务流程标准化：建设一套标准来定义三类结算模式下每个数据处理环节的实现方式，包括业务处理流程、数据处理过程。

• 分润模型通用化：实现不同的账单计算算法，支持各个业务的各类作者收入分配诉求，并且实现参数配置线上化。

• 技术架构统一：统一整个结算业务的技术栈、部署环境、功能入口和数据出口。

• 建设账单测算能力：模拟线上结算流程的账单测算能力，支持业务快速验证分润模型参数调整带来的作者收入影响效果。

• 建设质量保证体系：建设全流程预警机制，通过日志质检、自动对账、数据异常检测来保障账单产出数据时效性、准确性。

1. 业务流程标准化

不同业务场景，采用了通用化、标准化的设计来满足业务的特异性需求，下面是三大结算模式业务流程简图：

在广告模式、补贴模式、订单模式结算流程设计中, 从日志打点、线上化、计算逻辑等方向考虑了通用化、标准化设计, 具体如下:

(1) 日志打点统一化

统一日志标准, 针对业务日志规范陈旧问题，要求所有接入的业务方严格按照统一格式打点日志，删除冗余字段, 确保数据的规范性与一致性,同时保证设计能够覆盖所有业务场景，为后续处理奠定坚实基础。

针对某些业务定制化的需求, 在广告模式、补贴模式、订单模式三种结算方式中，在设计日志打点规范时, 会预留一些扩展字段, 使用时以 JSON 形式表示, 不使用时打默认值。

(2) 账单计算线上化

在补贴结算模式中，之前不同业务都有各自的账单格式设计，同时存在离线人工计算账单的非规范化场景，账单无法统一在线计算、存储、监管。新的结算中台的补贴结算模式，将所有离线结算模式，使用统一的账单格式，全部实现线上化结算，实现了业务结算流程规范化。

(3) 账单计算逻辑优化

比如在广告模式中，百家号业务的公域视频、图文、动态场景中，由于收入口径调整，迭代效率要求，不再需要进行广告拼接，所以专门对账单计算流程做了优化调整。不仅满足业务诉求，同时做了通用化设计考虑，保证后续其他业务也可以使用这套流程的同时， 也能兼容旧的业务流程。

广告模式结算流程优化前：

广告模式结算流程优化后：

2. 分润模型通用化

不同业务场景，不同结算对象，有不同的结算诉求，不仅要满足业务形态多样化要求，还要具有灵活性。因此抽取业务共性做通用性设计，同时通过可插拔式设计灵活满足个性化需求。

(1) 基于流量变化模型

以合作站点的优质用户投流方为代表的用户，他们在为百度提供海量数据获得收益的同时，也有自己的诉求，那就是自己内容的收益不能受到其他用户内容的影响。自己优质内容不能被其他用户冲淡，当然自己的低质内容也不会去拉低别人的收益水平。

对于此部分用户我们提供“基于流量变现的分润”策略，简单来说就是，某一篇内容的收益仅仅由它自己内容页面挂载的广告消费折算而来，这样就保证了优质用户投流方收益的相对独立，也促使优质用户产出更加多的内容。

(2) 基于内容分发模型

• 部分作者只关注收益回报: 对百家号的某些作者来说，他们的目的很单纯，他们只关注产出的内容是否获得具有竞争力的收益回报，至于收益怎么来他们并不关心。

• “基于流量变现”策略不妥此时，我们再使用“基于流量变现”的策略的话，就有些不妥，举个极端里的例子，有一个作者比较倒霉，每次分发都没有广告的渲染，那他是不是颗粒无收？这对作者是很不友好的。

• “基于内容分发的分润”模型: 基于收益平衡性考虑，我们推出了更加适合百家号用户的“基于内容分发的分润”模型。在这种模型下，只要内容有分发，就一定有收益，而不管本身是否有广告消费。

• 策略平衡考虑: 当然，为了防止海量产出低质内容来刷取利润，在分润模型上，我们同时将内容质量分和运营因子作为分润计算的权重，也就是说作者最终的收益由内容的质量和内容的分发量共同决定，以达到通过调整分润来指导内容产出的目的。

(3) 基于作者标签模型

为了实现对百家号头部优质作者进行激励，促进内容生态良性发展, 会对不同的作者进行打标, 并且使用不同的分润模型, 比如对公域的百家号作者进行打标, 优质作者, 通过动态单价及内容质量权重策略来给到他们更加的分成, 其他的普通作者, 通过内容分发模型来分润。这样不仅保证了优质作者取得高收益，也保证了其他作者也有一定的收益

另外，出于对预算的精确控制，发挥每一笔预算的钱效，优质的作者会占用较大的预算资金池，而普通作者使用占用较少的预算资金池。同时也会对每类资金池进行上下限控制，保证预算不会花超。

(4) 基于运营场景模型

为了实现对百家号作者的精细化运营，比如对一些参与各类短期活动的作者给予一定的阶段性的奖励，可以通过补贴模型来实现。在一些运营活动中，需要控制部分作者的分成上限，分润模型会进行多轮分成计算，如果作者的收益未触顶并且资金池还有余额的情况下，会对余额进行二次分配，给作者再分配一些收益。此类模型主要是为了实现灵活多变的作者分润策略。

3. 技术架构统一

根据业务流程标准化、分润模型通用化的设计原则，建设统一的结算中台。以下是结算中台统一结算业务前后的对比：

4. 建设账单测算能力

为各个需要测算能力的业务，设计了一套通用的测算流程，如下图：

针对每个测算业务，设计了独立的测算参数管理后台，用于管理业务相关的分润模型参数，如下图：

测算流程设计

(1) 功能简述: 每个测算业务, 产品需要登录模型参数管理后台,此后台支持对分润模型参数进行创建、查看、编辑、测算、复制、上线、删除，以及查看测算结果等操作, 出于业务流程合规化的要求, 每次模型参数上线前, 需要对变更的参数完成线上备案流程才可以上线，实现分润流程合规线上化。

(2) 流程简述

• 流程简述概览: 每次测算时， 产品需要先创建一个版本的账单模型测算参数，并发起参数测算，参数状态变成待测算 。

• 离线任务与收益计算: 此后，离线任务会轮询所有的待测算参数，提交Spark任务，调用账单计算模型来计算作者收益，最后生成TDA报告。

• 查看与评估测算报告: 产品在管理平台看到任务状态变成测算完成时, 可以点击 TDA 链接来查看测算报告, 评估是否符合预期。

• 根据预期结果的操作:如果不符合预期，可以编辑参数再次发起测算；如果符合预期，则可以发起备案流程，流程走完后可以提交上线。

(3) 收益明显: 通过账单测算建设, 不仅解决结算需求未备案即已上线或者备案内容与实际实现不一致，甚至缺乏备案流程的业务痛点问题,  而且把业务线下账单计算的流程做到了线上, 做到留痕可追踪。同时也满足了业务高效迭代的诉求, 一次账单测算耗时从半天下降到分钟级, 大大降低了账单测算的人力成本与时间成本。

5. 建设质量保障体系

为了保证业务质量，从以下几方面来建设：

(1) 建设数据预警机制：为保证作者账单数据及时披露, 分润业务涉及的 百余条数据源都签订了 SLA, 每份数据都关联到具体的接口人, 通过如流机器人来监控每个环节的数据到位时间, 并及时发出报警信息, 并推送给具体的接口负责人。对于产出延迟频次高的数据流，会定期拉相关负责人相关复盘，不断优化数据产出时效，保证账单数据在每天如期产出

(2) 数据异常检测机制：对账单数据进行异常波动性检测, 确保数据准确性 ,及时发现并处理潜在异常问题

(3) 自动对账机制：每天自动进行上下游系统间账单明细核对,保证出账数据流转的准确无误。

(4) 日志质检机制：每日例行对日志进行全面质检分析, 及时发现日志打点日志。

05 中台收益

结算中台作为公司财务体系的核心，承担多业务线分润计算与资金流转重任。

(1) 通过通用化、标准化设计，高效支撑数十个业务线的精准结算，确保广告、订单、内容分发的业务结算稳定、健康。近一年，结算业务零事故、零损失。

(2) 中台支持多种结算模式与灵活周期管理，实现账单测算自动化，账单测算时间从天级降到小时级。提升效率并减少错误，提升业务需求迭代效率。

(3) 通过业务流程标准化、分润模型通用化、账单测算能力建设及质量保证体系，解决了结算业务规范缺失、业务形态多样等问题。累计解决历史结算case数十个，涉及结算金额达千万级。

未来，结算中台将推进全业务线结算立项线上化、周结与测算能力落地、项目全生命周期管理，并依托大模型能力实现数据智能分析，进一步提升数据分析智能化水平，为公司业务稳健发展提供坚实保障。

06 未来规划

1、推进全业务线结算实现立项线上化；

2、推进周结 、测算能力在各业务线上落地；

3、推进项目全生命周期管理，实现项目从上线到下线整体生命周期变化线上化存档，可随时回顾复盘。

4、数据智能分析，依托公司大模型能力，实现通过多轮对话问答来进行数据分析，针对业务问题进行答疑解惑，提升数据分析的智能化水平。

01 前言

在日常视频播放中，我们经常会遇到这样的问题：视频的长宽比例与设备屏幕不一致，导致画面上下或左右出现黑边。虽然这并不影响视频的正常播放，但从用户体验的角度来看，这些黑边往往打断了视觉的沉浸感，显得格外突兀。

为了解决这一问题，业界主流播放器（如 YouTube、Netflix）引入了一种被称为氛围模式（Ambient Mode）的视觉增强效果。它的核心思路是：

通过实时识别视频画面的主色调，并动态将其填充到黑边区域，使边缘色彩与视频内容保持一致，提升整体视觉统一性，从而营造出与视频内容相协调的氛围效果，让观众的观看体验更加自然和沉浸。

下面是YouTube的氛围模式效果：

youtube竖屏效果

youtube横屏效果

百度播放内核团队也将氛围模式效果应用到了视频播放场景，用于提升用户观看视频沉浸感，同时在百度App、好看App两款产品完成上线。本文将详细说明视频场景氛围模式技术方案。

02 整体技术方案

氛围模式通过在播放内核视频后处理通道（FilterChain）添加一个AmbientFilter滤镜实现，其核心思路：通过AmbientFilter滤镜先将视频帧数据从GPU下载到CPU，然后将视频帧数据按块进行区域划分，划分完成后再通过颜色量化算法提取每个区域主色调，最后将各个区域主色调传给平台层，平台层拿到主色调进行绘制视频四周氛围效果。整体方案流程大致如下图所示：

氛围模式整体方案

2.1 视频帧采样

为了提取视频的主色调，需要获取视频帧数据。但提取主色调并不要求每帧都下载，太频繁下载会拖垮应用性能，在视觉上也不会带来特别好的体验。因此我们对视频帧进行采样下载：在 25 FPS 的视频下，每隔约 50 帧（约 2 秒）采集一次帧数据。

同时，为了避免将视频帧数据从 GPU 下载到 CPU 时阻塞渲染线程，我们采取了以下优化：

1. FBO 压缩：先将视频帧渲染到较低分辨率的 FBO（例如将 1080p 压缩到 108p），大幅减少待传输的数据量。

2. PBO 异步传输：利用 PBO 异步将帧数据从 GPU 下载到 CPU，从而避免阻塞主渲染线程。

通过这种方式，我们既能保证主色调提取的效率，又不会影响视频的流畅播放。渲染线程和氛围模式工作线程两个线程工作流程如下图：

线程核心职责

2.2 主色调提取

2.2.1 视频帧区域划分

拿到视频帧数据后，我们先将视频帧划分出几个区域。项目中我们是将视频帧画面划分为：TopLeft, TopCenter, TopRight, BottomLeft, BottomCenter, BottomRight 六个区域，如下图所示：

视频区域块划分

接下来我们提取出每块区域的主色调。

2.2.2 提取主色调

要提取画面主色调，我们是通过颜色量化技术实现的。颜色量化（Color Quantization） 是一种图像处理技术，目的是减少图像中使用的颜色数量，同时尽量保持原图的视觉效果。代表性的颜色量化算法有：

1. 中值切割法（Median Cut）：将颜色空间递归分割成小立方体，取每个立方体的颜色中位数作为调色板颜色。

2. K-means聚类：将颜色按相似性分组，取每组的中心作为调色板颜色。

3. 八叉树算法：通过构建八叉树分层合并颜色，逐层减少叶子节点数量，最终保留高频颜色。

4. 流行色算法（Popularity）：统计原图颜色出现的频率，选取高频颜色作为调色板。

这几种算法从各维度对比情况如下：

从算法的速度、精度以及实现复杂度等多维度考虑，氛围模式场景我们选用中值切割法完成视频画面主色调的提取。

2.2.3 中值切割法

中值切割法（Median Cut）是一种用于图像颜色量化的算法，算法核心思想是将颜色空间递归地分割成更小的区域，以减少图像中颜色数量。该算法的目标是在颜色空间中选择一组代表性的颜色，这些颜色可以用于生成调色板，从而减少图像的颜色数量，同时尽量保留图像的视觉效果。算法核心步骤如下：

1. 初始化颜色盒

a. 首先，将所有颜色视为一个大的颜色盒（即整个颜色空间的一个区域）。

b. 颜色盒包含图像中所有像素的颜色。

2. 选择分割轴

a. 在每次迭代中，选择颜色分量（红、绿、蓝）中范围最大的分量作为分割轴。这是为了最大限度地减少颜色空间的不均匀性。

3. 按中值分割

a. 沿着选定的分割轴，根据颜色值的中值，将颜色盒分成两个较小的盒。

b. 这种方法确保每个新盒子中包含的颜色数量尽可能相等。

4. 递归分割

a. 对每个新的颜色盒重复步骤2和3，直到达到所需的颜色盒数量（通常是所需调色板的大小）。

5. 生成调色板

a. 一旦颜色盒的数量达到预期的数量，对每个盒子计算平均颜色或中值颜色，将其作为代表颜色添加到调色板中。

6. 颜色映射

a. 使用生成的调色板，重新映射原始图像中的每个像素到最接近的调色板颜色。

中值切割算法核心流程如下图：

中值切割算法

03 平台渲染氛围效果

当native层提取完视频帧各区域主色调后，将色值传给平台层（Android/iOS）。平台层收到色值后，将色值渲染到视频四周以产生氛围效果。为保证各个区域色值过渡自然，以及前后两帧的色值平滑过渡，需要借助平台层渐变、动画、rgb插值等技术实现。 下面结合Android和iOS两个平台分别介绍具体思路。

3.1 Android平台

Android 使用自定义view技术，完成氛围色值的渲染。我们提供一个自定义view名为AmbientView 来完成这个功能。有了AmbientView之后，布局结构大致如下：

<FrameLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:layout_gravity="center">
        <com.baidu.cyberplayer.sdk.AmbientView
            android:id="@+id/left_ambient"
            android:layout_width="xxxdp"
            android:layout_height="match_parent"/>
        <FrameLayout
            android:id="@+id/video_container"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"/>
        <com.baidu.cyberplayer.sdk.AmbientView
            android:id="@+id/right_ambient"
            android:layout_width="xxxdp"
            android:layout_height="match_parent"/>
</FrameLayout>

上面为视频横屏下布局大致情况，id为video_container的FrameLayout是播放器容器，在播放器容器左右各摆放一个AmbientView渲染氛围模式，AmbientView的宽度会根据播放器的尺寸的变化在代码中动态调整。

AmbientView核心功能：

1. 相邻区域的主色调，使用LinearGradient拉出线形渐变。对于横屏视频，我们渐变方向就是从上至下。所以更新氛围色值的代码如下：

private void updateGradient() {
    mLinearGradient = new LinearGradient(0, 0, 0, getHeight(),
                        mColors, null, Shader.TileMode.CLAMP);
    mPaint.setShader(mLinearGradient);
    invalidate();
}

2. 前后两帧氛围色值的切换，为了颜色切换不显得生硬，我们借助Android属性动画以及RGB插值实现色值缓慢渐变效果，核心代码如下：

private void startColorAnimator() {
    int[] lastColors = new int[mLastColors.length];
    for (int i = 0; i < lastColors.length; i++) {
        lastColors[i] = mLastColors[i];
    }

    mColorAnimator = ValueAnimator.ofFloat(0, 1f);
    mColorAnimator.setDuration(1500);
    mColorAnimator.addUpdateListener(new ValueAnimator.AnimatorUpdateListener() {
        @Override
        public void onAnimationUpdate(@NonNull ValueAnimator valueAnimator) {
            float progress = (float) valueAnimator.getAnimatedValue();
            interpolateColors(progress, lastColors);
            updateGradient();
        }
    });
    mColorAnimator.start();
}

/**
 * 插值计算color
 */
private void interpolateColors(float progress, int[] lastColors) {
    if (mCurColors == null || mCurColors.length <= 0) {
        return;
    }

    ArgbEvaluator evaluator = new ArgbEvaluator();
    for (int i = 0; i < mCurColors.length; i++) {
        mColors[i] = (int) evaluator.evaluate(progress, lastColors[i], mCurColors[i]);
    }
}

mColorAnimator是一个ValueAnimator对象，通过ValueAnimator我们创建一个1500ms的动画，在动画的更新函数里面，我们调用了interpolateColors，这个方法内部就是用ArgbEvaluator完成RGB颜色插值，更新到mColors数组中。最后调用updateGradient方法触发AmbientView重绘。

3. 渐变遮罩：最后我们还要在上面添加一层黑色渐变遮罩，保证氛围区域不要太突兀，以免过度吸引用户眼球，导致用户注意力不在视频内容本身上面。黑色遮罩实现也非常简单，代码如下所示：

float[] mPositions = {0.0f, 1.0f};
int[] mMaskColors = {0x88000000, 0xff000000};
// 从左到右渐变
mMaskLinearGradient = new LinearGradient(0, 0, getWidth(), 0,
                            mMaskColors, mPositions, Shader.TileMode.CLAMP);
mMaskPaint.setShader(mMaskLinearGradient);
// 绘制黑色渐变蒙层
canvas.drawRect(0, 0, getWidth(), getHeight(), mMaskPaint);

3.2  iOS平台

iOS端同样提供了一个自定义的 AmbientView（氛围视图），为视频播放场景提供动态渐变背景和遮罩效果，增强视觉沉浸感。

1. 双图层架构设计：采用主渐变层与遮罩层分离的架构方案，确保色彩渲染与边缘遮罩效果互不干扰，提升整体渲染效率。

- (void)setupSubLayers {
    _gradientLayer = [CAGradientLayer layer];
    _gradientLayer.frame = self.bounds;
    [self.layer addSublayer:_gradientLayer];

    _maskLayer = [CAGradientLayer layer];
    _maskLayer.frame = self.bounds;
    [self.layer addSublayer:_maskLayer];
}

2. 流畅动画引擎：基于CADisplayLink构建动画循环，通过实时颜色插值计算，实现细腻流畅的色彩过渡效果。

- (void)startAnimation {
    // 核心功能代码
    self.displayLink = [CADisplayLink displayLinkWithTarget:self selector:@selector(updateColors)];
    [self.displayLink addToRunLoop:[NSRunLoop mainRunLoop] forMode:NSRunLoopCommonModes];
}

- (void)updateColors {
    CGFloat progress = MIN(1.0, (CACurrentMediaTime() - self.startTime) / self.animationDuration);
    NSMutableArray *interpolated = [NSMutableArray array];
    for (NSUInteger i = 0; i < self.endColors.count; i++) {
        UIColor *from = i < self.startColors.count ? self.startColors[i] : [UIColor clearColor];
        UIColor *to = self.endColors[i];
        [interpolated addObject:(__bridge id)[self interpolateFrom:from to:to progress:progress].CGColor];
    }
    _gradientLayer.colors = interpolated;
}

- (UIColor *)interpolateFrom:(UIColor *)from to:(UIColor *)to progress:(CGFloat)progress {
    CGFloat fr, fg, fb, fa, tr, tg, tb, ta;
    [from getRed:&fr green:&fg blue:&fb alpha:&fa];
    [to getRed:&tr green:&tg blue:&tb alpha:&ta];
    return [UIColor colorWithRed:fr + (tr - fr) * progress
                           green:fg + (tg - fg) * progress
                            blue:fb + (tb - fb) * progress
                           alpha:fa + (ta - fa) * progress];
}

3. 渐变遮罩：采用多段式渐变遮罩配合加速曲线算法，打造自然的边缘过渡，有效增强视觉层次感。

- (void)makeMaskColorsAndLocations {
    const NSInteger steps = 6;
    for (NSInteger i = 0; i < steps; i++) {
        CGFloat t = (CGFloat)i / (steps - 1);
        CGFloat acceleratedT = t * t;
        CGFloat currentAlpha = a + (1.0 - a) * acceleratedT;

        UIColor *color = [UIColor colorWithRed:r green:g blue:b alpha:currentAlpha];
        [_maskColors addObject:(__bridge id)color.CGColor];
        [_maskColorsLocations addObject:@(t)];
    }
    _maskLayer.colors = _maskColors;
    _maskLayer.locations = _maskColorsLocations;
    _maskLayer.startPoint = CGPointMake(0, 0);
    _maskLayer.endPoint = CGPointMake(1, 0);
}

该实现确保了氛围渲染的高性能和优美视觉效果，为用户提供了沉浸式的观看体验。

04 效果展示

氛围模式已在百度内包括百度App和好看App两款App完成上线，其中百度App主要集中在搜索三方影视场景，好看App所有视频横屏场景（排除广告视频）。同时在视频观看时长、分发、完播率等UBS指标取得了正向收益，说明氛围模式给用户带来了不错的沉浸式观影体验。

下面是百度App和好看App效果展示：

百度App氛围模式

好看App氛围模式

5. 总结

氛围模式是一种视觉增强功能，通过技术手段有效解决了视频比例不匹配导致的黑边问题，显著提升了用户视觉体验，主要表现在如下几个方面：

1. 视觉沉浸：氛围模式通过在视频周围添加柔和的背景颜色，使屏幕的边缘与视频内容更好地融合。这种设计使得用户在观看视频时感觉更加沉浸，减少了视频与周围环境之间的视觉割裂

2. 舒适观看：这种模式可以减少长时间观看视频时的眼睛疲劳。通过在视频周围使用柔和的色彩过渡，可以缓解亮度差异带来的视觉刺激，从而提高观看舒适度。

3. 提升观感：氛围模式通过智能地调整背景色彩，使其与视频中的主要色调相匹配，提升整体观感。这使得视频内容更加突出，同时为观看者提供一种更为和谐的视觉体验。

通过本文介绍的技术方案，开发者可以实现类似主流视频平台的高质量氛围模式效果，为用户带来更加沉浸的观看体验。

导读

从2023年成立到如今日均服务2万+直播间，百度慧播星已演进为覆盖脚本生成、实时问答、智能决策、音视频克隆的全链路AI直播平台。本文深入解读其技术架构：如何通过检索增强和强化学习生成高转化脚本；如何利用强化学习智能中控动态优化直播策略；以及如何将语音与形象克隆效率提升至“小时级”；如何构建“先验-后验”数据飞轮，让模型自主进化；。罗永浩数字人直播GMV突破5500万的案例，验证了其“超越真人”的带货能力。未来，慧播星正朝着更智能、更拟真、更高效的方向持续迭代。

01 慧播星介绍

电商数字人直播（慧播星）正式成立于2023年，是一款汇集了百度在视觉，语音和语言方面AI能力的原生AI应用产品，致力于打造代际领先的超越真人的直播体验。25年底日均开播直播间已达2万多个，覆盖电商、教育、健康、金融、泛知识内容等多个行业。经过两年多的产品打磨和技术突破，慧播星数字人直播已具备超越真人的能力。例如，这些能力支撑了罗永浩2025年6月15 日的数字人直播首秀，吸引了超 1300 万人次观看，GMV（商品交易总额）突破 5500 万元，这一成绩超过了其同年 5 月的真人直播首秀（GMV 5000 万）。

1.1 商家业务视角——开播流程

商家在慧播星获得带货权限后，即可自助开启数字人直播，主要包括如下流程。

1. 商品选择，可从百度直营店铺（度小店），三方电商平台（京东淘宝拼多多）和百度本地生活的海量商品中选择带货商品

△ 海量内外部商品一键挂接

2. 形象选择或者定制，从7800+公共库形象中选择主播形象，或通过自助录制5分钟视频定制私有形象

△ 形象选择或定制

3. 直播间装修，从3600+套直播间模板中选择装修风格和元素，或通过AI自动生成直播间背景图和营销挂件

△ 直播间装修，丰富的模板&组件

4. 脚本生成，从多种公共风格中选择脚本带货风格，或自定义目标带货风格，补充少量营销信息，一键生成专业的直播脚本

△ 一键脚本生成

5. 音色选择，从3200+个公共库音色中选择主播音色，或通过手百自助录制，3天内得到私有定制音色

△ 音色选择或制作

6. 直播间互动配置，一键开启一言问答接管，也支持手动配置预置问答对，补充商家知识

△ 直播间互动配置

02 整体技术架构

慧播星整体架构主要由商家端、视觉语音和文本各模态模型、实时渲染引擎、站内外分发系统组成。

为实现更好的直播体验，数字人采用云端生成方案，云端生成系统主要包括如下几个子系统。

1. 商品理解，为脚本，问答，互动等各种内容生成模型提供商品知识增强

2. 脚本生成，围绕商品自动生成风格化口语化的带货脚本

3. 智能问答，用户提问时实时检索商品知识，生成精准的回复，支持弹幕和口播回复

4. 智能互动，以直播效果（评论率、用户退场率、观看时长等）为目标主动向用户发起互动

5. 直播间装修，智能生成直播间背景，合成带营销内容的挂件

03 内容生成

3.1 风格化脚本生成

直播脚本水平与带货效果息息相关，优秀主播的脚本能够打动用户，循循善进引导用户成交。由于普通商家的带货营销水平有限，商家希望仅表达学习某某主播，系统自动为其生成风格相似的脚本。在此需求背景下，慧播星利用多模态商品理解富集构建商品知识库，借助EB4/turbo在电商直播语料上进行大规模预训练，结合人工专家精标数据SFT，通用和电商知识增强等手段实现一键风格化仿写。

• 商家仅需选定商品和补充少量营销信息，即可按预设风格或者自定风格（提供最少400字的带货文案）一键生成风格相似的带货脚本。客户采纳率92%，开播渗透率67%，相比客户脚本转化率+14%。
• 考虑到风格化脚本创作需求的独立性，慧播星已将脚本生成独立为工具，商家可脱离直播业务流使用工具。

△ 风格化脚本生成工具UI

技术架构

整体技术主要包括商品理解、检索增强、强化学习风格化生成和后处理阶段。

• 商品理解。系统通过多模态商品解析技术对商品详情页、海报图、参数图等视觉素材进行 OCR、版面结构识别与多模态模型融合，自动抽取核心卖点、适用人群、功能亮点、使用场景等结构化商品知识。可在单张图里同时捕获“文本内容 + 图示含义 + 排版语义”等特征，并利用 LLM 对解析结果进行归一化和字段对齐，形成高覆盖、高一致性的商品知识库。
• 检索增强（RAG）链路。用户输入的风格范文（不少于 400 字）会先经过标签分析模块，由大模型识别出其关键风格维度，如：表达节奏（快/慢）、情绪浓度（热情/克制）、营造气氛策略（故事、对比、疑问句）、用户痛点定位、直播常用带货技巧（强调稀缺、促单压力、利益点递进）等。基于这些风格标签，系统自动生成 Query，用于从通用知识库与电商知识库中检索对应表达方式、句式模板与知识上下文（卖点顺序推荐、商品类别常用话术、场景化句法等）。
• 风格化生成模型。模型基于电商专精的电商直播语料预训练能力，并结合海量运营专家的精细化标注数据（SFT），能够在保持范文风格一致性的同时，将内容自动替换为目标商品的卖点和营销逻辑。为确保生成内容既符合直播场景使用习惯，又具备高情绪感染力，系统引入轻量级 RLHF/强化学习优化，通过人类偏好数据持续调优，使模型能够稳定输出“自然、顺畅、带货效果强”的脚本。为持续提升模型能力，通过数据飞轮对该生成模型进行对齐。
• 标签化与后处理。脚本被进一步结构化，包括：分镜逻辑、开场引导、利益点铺垫、情绪高点、促单推进、收尾金句等，方便商家在实际直播中灵活调用或进行定制化编辑。

脚本数据飞轮

数字人直播的内容绝大部分来自大模型生成，前期领域专家知识为生成标准，脚本、问答、互动场景的生成质量已达到普通真人主播的水平。然而人工先验知识存在主观偏差，且缺乏全面性和快速适应新变化的能力，完全依赖人工只能达到次优水平。为持续攀升超越域内外头部真人主播，需建立业务和大模型的数据飞轮，通过飞轮效应持续提升模型在数字人直播场景的后验效果。

先验对齐

在真实直播场景中，数字人模型最终追求的是“后验效果最优”——即用户停留、评论增长、转化提升等真实业务指标。然而后验目标往往天然伴随风险：例如激进促单、夸大效果、模糊描述等内容可能在短期内获得更高的用户反馈，却越过事实边界与平台规范，形成安全问题。因此，在模型全面对齐后验之前，必须构建一套稳健、可解释、与平台规范一致的先验对齐体系作为基础。先验奖励模型作为“守门人”，以推理专家模型为判断核心，通过结构化的偏好评分与规则奖励引导模型学习合规、高质、可控的内容风格，实现“先验对齐 → 强化学习 → 专精模型 → 回流验证”的闭环。

自动偏好合成。传统先验奖励完全依赖人工标注，成本高且存在主观性。为解决这一问题，我们集成了多个先进推理类基模型（如 EB4-4T、Deepseek-R1/V3、GPT-o 系列等），通过多模型投票、结果对比分级等方式自动合成偏好。这一自动化偏好生成机制能够模拟“专家标注”，但具备：

• 一致性更高，减少人工主观波动
• 覆盖范围更广，数百万级先验数据
• 适应变化更快，模型可随平台规范或内容趋势变化即时更新

最终形成先验 RM（Reward Model）的核心训练数据。先验 RM 的核心职责是确保模型在任何情况下都不会突破内容安全边界，为后续后验对齐提供稳固底座。

后验数据飞轮

为了让模型吸收用户的真实后验反馈，慧播星构建了一套以“内容探索 + 奖励建模”为两条主线的数据飞轮，实现模型的自主进化与持续增强。

基于后验统计的内容探索：可控、高解释的偏好数据生成链路。后验统计路径主要面向高精度、强可控、可解释性强的偏好数据生产需求，结合在线实验框架，通过真实用户反馈驱动的方式生成偏好样本。通过高频在线实验，系统不断沉淀千级规模的偏好数据，支撑后续的模型偏好对齐训练（如 DPO/IPO 等策略优化方法）。

可泛化的奖励 uplift 建模：大规模偏好数据的高效补充路径。相比基于后验统计的实验方式，uplift 建模路径旨在解决用户行为稀疏、实验成本高的问题，通过泛化模型直接对用户偏好进行预测，生成百万级的偏好数据，实现更高效的数据扩容。采用 S-Learner / T-Learner 等 uplift 方法，构建用户行为因果效应模型，直接预测“某段内容是否会提升用户的互动/评论/停留等关键指标？”

3.2 智能问答

慧播星建设了一套完备的直播场景RAG系统，包括电商领域知识检索模型，通过千亿模型蒸馏的低时延生成模型（12s->2s)，数据飞轮。目前已实现多模素材调度，高拟真明星问答，客户个性化表达，垂类适配，商家/商品知识库等产品能力。客户可一键开启智能问答，问答端到端可用率95%，优质率90%，客户开启率94%，运营和客户反馈较好。

△ 智能问答架构

技术架构

慧播星的直播实时问答系统在工程上形成了知识整合 → 领域检索 → 低延迟生成 → 后处理 → 数据飞轮的完整闭环，为超拟真数字人提供了媲美真人的实时互动能力。

• 在知识整合层，系统将商家侧的商品图文、卖点、FAQ、视频脚本、类目属性以及运营沉淀的数据统一入库，并通过向量化处理构建高可用的电商知识底座。
• 领域知识检索模块结合了千帧蒸馏后的 EB-lite/行业模型与高维向量语义搜索，通过「意图识别 → 精准匹配 → 语义聚类 → 知识召回」的流水线，确保系统能够从复杂直播语境中准确捕捉用户提问意图。直播场景中存在大量口语化、短句化、甚至噪声语料（如： “这个能用多久啊”。“有别的颜色吗？”），系统通过深度语义 embedding（如 ernie embedding）实现高鲁棒性的实时检索，使检索召回的准确率在实时环境下依然保持稳定。
• 低延时生成模块。基于千亿模型蒸馏结果构建，针对直播高并发、低时延、强一致性的要求，模型经过结构裁剪、张量并行优化与 Prompt 规约，使单轮响应时延从 12s 压缩到 2s，在保证语义丰富度和口播自然度的同时提升端到端体验。
• 数据飞轮实现持续自我优化：运营反馈、用户互动日志、误匹配案例以及高质问答样本会自动回流到数据处理模块，驱动知识库更新与模型重训练。

3.3 智能中控

---

真人主播会根据直播间实时状态决策当前应发起何种动作（action），比如直播间互动氛围差的时候是应该邀评，换卖点讲解还是促单？确定动作后主播知道如何最好的的执行动作，例如怎么把邀评讲出来？说什么话，用什么语气，邀请特定观众还是所有观众。行为决策和行为内容生成两者相结合实现直播间下单，关注，留联等最大化目标。超拟真数字人需要具备上述两种核心能力，即给定一个长期目标（如每场次的订单总数，评论总数，观看时长等），要求数字人1）判断在不同直播间状态下应该做出什么行为，是切换卖点讲解，促单逼单，邀评还是多轮互动？2）确定某种行为后生成适合的的行为内容，如塑品讲解，优惠讲解，促单逼单等的具体口播内容。

技术架构

智能中控架构核心由基于强化学习的决策Agent，和基于一言大模型的多任务融合两个部分组成。

基于强化学习的行为决策Agent

行为决策的目标是在不同直播状态下选择最优动作，最大化长期目标（订单、评论、观看时长等）

上图展示了直播环境与RL决策Agent的交互流程：

• 状态 St：观看人数、评论频率、当前商品、用户行为序列、是否有提问等
• 动作 At：邀评 / 多轮互动 / 促单 / 动态讲解 / 切换卖点 / 回答问题……
• 奖励 Rt：订单数变化、评论数增加、停留时长、转化率提升等
• Agent 通过不断试错 & 策略迭代，获得最优策略。

这使数字人能够像真人主播一样：氛围低时发起互动，用户观望时进行促单，新观众进入时进行商品介绍。RL 的优势在于目标导向：不是优化单句话，而是优化整场直播的 KPI。

基于大模型的行为内容生成与融合

当 RL Agent 选择了一个动作后，例如“促单”，还需要生成对应的动作参数：如促单的口播内容，使用什么语气？内容是偏温和还是强节奏？是否引用当前观众的评论？实践中我们通过强化学习训练了一系列action内容生成专精模型，能够生成特定参数指定的直播内容。

未来我们将以语言模型为基座对决策和内容生成任务进行端到端训练，减少分阶段建模带来的累计误差。

04 语音克隆与合成

普通商家原声演绎状态不佳，缺乏带货感。慧播星利用风格迁移TTS技术自动合成感染力强，拟真度高的直播音频。经过两年多的迭代TTS开播使用率从30.3%提升至92.8% ，制作时效性从1月降低到1分钟。

电商TTS发展主要经历两个阶段：

第一阶段（2023.3~2024.Q2) **：语音定制工牌麦收音，依赖大量人工传导，整个周期长达一个月

第二阶段（2024.Q3至今) **：小程序自助收音提高收音效率，自动训练架构升级，抑扬顿挫带货效果持续优化

第一阶段：工牌麦收音效率低下

第二阶段：小程序自助录制

现状：当前慧播星支持原生和激情带货两种音色克隆，客户仅需在手百小程序上录制15分钟语音，系统在1天内自动为客户生成克隆音（对比如下）。目前慧播星已制作12w多个音色，2.7w多个客户定制音色。

两种音效可选

1. 原声效果：还原本人说话特点，如语速和语调

http://blob:https://unitools.fun/fb87134d-97ec-42a5-a0a0-b74980b1cfc3

2. 激情带货效果：让整体情绪更激昂，抑扬顿挫

http://blob:https://unitools.fun/85e53903-5672-4988-85ae-19a4c867a607

未来计划利用海量直播场景的语料数据，进一步降低克隆门槛（对齐竞品的30s）、提升克隆效率（分钟级可完成克隆进行合成）、优化朗读效果（对标直播/视频/讲述/咨询等不同语境的真人） ，同时从单声音的克隆和合成成本达到业内头部领先水平。

克隆+合成技术架构

整体架构主要包括离线声纹注册和模型训练，在线合成三个部分。

△ 形象克隆及合成架构

05 形象克隆与合成

主播形象是直播的核心要素，高拟真形象能够提升用户观看时长，进而提升成单效果。慧播星与视觉技术部深度合作，基于2D数字人技术针对直播场景定制形象克隆和合成能力，建设了接近7800+个公共库形象，有效地支撑商家在慧播星的前期探索，为自建形象做好准备。

△ 慧播星形象制作

形象克隆技术发展主要经历了四个阶段：

第一阶段（2023.3~2023Q4) ：V1版本唇形驱动方案适配电商直播场景，跑通录制约束较多的**闭嘴且无遮挡录制+**形象克隆流程，建立起第一批公共库形象

第二阶段（2024.Q4~2024.Q2) ：V3V4版本唇形驱动通过数据建设和模型算法优化实现张嘴录制和更自然的唇动效果

第三阶段（2024.Q3~2025.Q2) ：进一步降低录制门槛，支持录制中遮挡、大幅度侧脸和人脸出镜。

当前阶段客户仅需上传5分钟左右的自然演绎视频，系统在3小时内即可自动为客户生成克隆形象。时至25年底慧播星已累计制作32万多多个形象，8万多个客户定制形象，线上可用率95% 。

第三阶段（2025.Q3~至今）：突破唇形驱动，建设多人出镜，动作驱动，表情驱动，持物驱动等下一代形象生成能力（多模协同的超级主播）。

视觉技术

实时场景下早期的唇动方案采用单阶段建模（如wav2lip），输入音频直接输出像素空间的唇形图片。实践中单阶段方案无法达到逼真的唇动效果，后来的商用方案几乎都采用两阶段方案：第一阶段将音频转化为2D关键点或3D人脸模型作为中间表达，第二阶段将中间表达利用GAN网络解码到像素空间。

视觉生成模型

核心由三个模型组成，3D人脸重建模型，音频到3D人脸生成模型，3D空间到像素空间人脸生模型。

• 3D人脸重建利用3DMM将人脸图片（像素）转换为3D mesh（三维空间点）
• 基于Faceformer改进的音频到3D mesh预估模型，mesh作为中间表达携带了丰富的面部动态，使得生成模型能够生成逼真的唇形图片。
• 基于StyleGan2改进的人脸生成模型，训练目标包括像素空间的重建损失，特征空间的感知损失，以及对抗生成损失。实现个性化增量微调方案，复用预训练底座只学习每个主播的个性化唇动风格，新形象仅需微调，3小时内完成制作。

模型pipeline

在线合成架构

形象合成以tts音频、底板视频帧和直播间背景为输入，通过生成模型实时合成主播嘴部区域，最后组装成视频流推送给用户。其中任务队列建立缓冲区，保障了视频流的连续性。目前已实现单卡多路流式渲染，支撑2万多直播间同时开播

在线流式合成架构

06 总结

历经两年多的持续打磨与技术突破，慧播星已经从一款数字人直播工具，成长为覆盖脚本生成、实时问答、智能中控、语音克隆、形象合成等多模态全链路的原生 AI 直播平台。它不仅复刻了真人主播的内容表达与带货节奏，更通过商品理解增强、强化学习决策、先验—后验数据飞轮、大规模音视频生成模型等关键技术，实现了“超越真人”的直播能力。随着业务规模的快速扩张与技术体系的持续演进，慧播星已在日均2万+直播间、万级定制形象与音色、覆盖电商与泛行业场景的真实生产环境中验证了 AI 直播的成熟度和商业价值。未来慧播星将继续沿着“更智能、更具说服力、更高效”的方向迭代：让脚本更精准、互动更自然、视觉更逼真、声音更生动、决策更智慧，并通过持续运转的数据飞轮不断突破直播体验的天花板。

导读

线上问题复盘发现质量保障存在测试召回、有效性及排查止损时效性不足等痛点，根源在于保障对象多样演进、线上问题处置复杂。为此我们构建质量风险管控系统，本文分别从风险管理系统的构建思想&实践、风险感知系统的AI效果提升、风险控制系统的智能化建设等维度展开介绍，整体风险管控系统在构建过程效果、使用效果和质量结果等层面均取得较好效果。未来，AI将更深度参与质量风险管控过程，与人工协同构建更智能化的风险管控体系。

01 背景

在线上问题的复盘中，我们总结出质量保障的三大痛点：

（1）问题测试召回/感知能力的完备性不足：测试能力缺失导致问题漏检、监控报警缺失导致问题发现滞后；

（2）问题测试召回/感知能力的有效性不足：测试工具不稳定导致测试结果失真、报警配置不合理导致误报/漏报；

（3）问题排查与止损的时效性不足：线上问题定位能力缺失、定位止损慢、止损链路长，导致影响范围扩大。

究其根本，源于以下挑战：

（1）质量保障对象多样、海量且持续演进：我们面对数以万计至百万级的质量保障对象（如服务模块、词表、业务对象等），每类对象对应不同的质量风险与保障策略。同时，这些对象本身还在不断变化，要求质量保障方案具备动态适应能力——即实现对质量保障对象的完整、动态、高效识别与控制，确保在合适的阶段选用最优的质量保障策略组合，以召回潜在风险。

（2）线上问题处置复杂、动态且高度关联：线上系统面临大量动态风险（如变更、数据波动、流量与资源变动等），这些因素持续冲击系统稳定性。因此，我们亟需构建不依赖人、完备且高效的问题感知机制，并打造体系化、智能化的定位与止损能力，从而快速分析线索、实施干预，降低线上问题带来的损失。

为应对上述挑战，我们构建了质量风险管控系统（RMCS），该系统由三部分组成：风险管理系统（RMS-Risk Manage System）-前置消除风险、风险感知系统（ROS-Risk Observe System）-中期发现问题、风险控制系统（RCS-Risk Control System）-后置控制损失。

02 AI的质量风险管控方案

经过多年发展，伴随着AI的发展强大，质量风险管控经过起步阶段、发展阶段的建设积累，已经发展到关键的转型阶段：基于AI的质量风险管控阶段，我们普遍并深入的使用AI能力来解决质量风险管理全流程的问题，提升质量管控的效果和ROI。

△ 基于AI的质量风险管控整体架构

领域知识：把丰富的知识从各类入口、平台、配置以及人脑转移到标准的软件知识图谱中，以结构化知识和非结构化规范知识进行组织，按需转化为实体和关系，从而构建RMCS的丰富、标准、开放的知识图谱生态，实现海量信息的标准化、共享化存储。

RMCS核心能力

• RMS Agent （AI风险管理）：以 AI 为核心，打造具备 “感知 - 决策 - 执行 - 反思” 能力的智能质量风险管理系统，实现 “应拦尽拦”。RMS以开放策略生态思路，灵活管理 “对象质量能力、质量能力风险处置策略”，实现对不同刻画对象能力现状的刻画，驱动质量能力提升，最终通过风险管理应用平台，实现数据、策略、刻画、闭环等环节的统一产品管理。

• ROS  Agent（AI报警管理）：依托领域知识，打造风险实时观测与降噪能力，实现 “应报尽报”。ROS涵盖知识建设、监控创建、维护、评估、降噪及报警跟进等多个环节，覆盖风险管理（如前置监控完备性建设）与控制（如报警有效性、感知后跟进处置）两个阶段，是问题发现后的主要感知手段。

• RCS  Agent（AI值班人）：融合领域模型与领域知识，打造端到端 AI 值班人，具备自主 / 协同式的智能定位与处置能力，实现 “应快尽快”。RCS围绕问题发生到止损全环节，构建报警分类导诊、排查定位、止损等多个环节的智能化控制能力，实现对问题整体损失预期控制，托管全流程风险控制过程。

03 基于AI的质量风险管控核心能力介绍

3.1 RMS Agent （AI做风险管理）

传统质量建设过程的核心痛点包括质量能力缺失、质量能力退化等反复出现的问题，面对庞大且持续变化的质量主题和持续发展的质量保障能力，需要构建不依赖于人刻画和前置风险识别，风险管理系统RMS就是为了解决这种前置风险而产生的， RMS以知识图谱为基础，对质量保障『主体』上全生命周期『质量保障能力』进行持续的合理性风险评估、分发和处理流程管理，牵引『主体』的『质量保障能力』持续发挥预期价值，达到将风险约束在适宜位置/阶段的目的，最终实现3个根本性转变：

• 从“人治”到“数治”： 将风险管控从依赖专家个人经验和重复劳动的模式，转变为基于全域数据和AI模型进行系统性、自动化治理的模式。

• 从“孤立”到“协同”： 打破各业务线、各质量阶段之间的信息壁垒，通过统一的风险语言和协作流程，实现跨域风险的联动防控。

• 从“被动响应”到“主动预防”： 从事后补救的“救火队”模式，转向事中干预、事前预测的“预警机”模式，将风险尽可能约束在萌芽或早期阶段。

RMS核心关注的四大核心痛点和解决思路：

（1）“经验壁垒”与“人力瓶颈”问题： 风险识别、评估、决策高度依赖少数专家的个人经验，难以规模化、标准化和传承，RMS 将专家经验沉淀为可计算、可复用的知识图谱和AI策略模型，让系统具备“专家级”的风险认知和判断能力。

（2）“信息孤岛”与“认知局限”问题：业务系统、质量数据、保障能力等信息分散在不同部门，缺乏全局视角，RMS 通过构建覆盖“主体-对象-能力”的完备知识图谱，打通数据孤岛，形成统一的、相互关联的风险全景视图。。

（3）“响应滞后”与“漏反复”问题： 传统人工巡检和评审方式，风险发现不及时，处理周期长且可能陷入“发现问题-修复-再次发生”的恶性循环，RMS实现7x24小时的自动化风险扫描与监测，并通过策略闭环确保风险被有效分发和处理，防止复发。

（4）“成本高昂”与“灵活性不足”问题： 为每个业务线定制化搭建风控体系成本高、周期长，业务变化时，风控策略难以快速调整，无法适应敏捷开发和快速迭代的需求，RMS 通过中台化、组件化（拼装、插拔式）的架构，提供通用能力的同时，允许业务方低成本、高效率地自定义风控流程和策略，实现“开箱即用”与“灵活定制”的平衡。

RMS旨在从模式上、成本上、效果上重塑质量风险管理过程，****打破业务间壁垒，最大化降低业务质量经营成本。****整体方案依托软件知识图谱，以一站式质量经营为导向，构建包括实体对象管理、质量能力管理、风险策略管理、风险观测、风险分发处置等通用能力。标准能力支持业务自主拼装、插拔式使用，实现风险从认知到闭环的全流程管理。支持各种质量角色的参与，协同以达到持续提升质量经营水平的目的。

下面是RMS提供的部分核心能力展示，目前RMS接入实体106万，覆盖实体类型115类，建设能力项394个，累计发现风险16万+，并完成了91.46%的风险闭环，直接支撑业务风险前置挖掘召回和闭环。

基于多实体关系的大事件运营

风险智能闭环工作台

3.2 ROS  Agent（AI做报警管理）

监控报警建设核心要解决报警完备性、有效性两个问题，即一旦异常发生时，需覆盖全位置、全指标异常并有效感知，同时对异常引发的多维、重复、关联报警进行降噪，减少报警信号的流转干扰。

为此，ROS重点构建了报警自主生成&运维与报警智能降噪能力来解决报警完备性和有效性问题。本文从通用逻辑阐述 AI 监控管理方案。

为达到完备和有效的目标，需重点解决以下四大问题：

（1）如何做到完备的覆盖：构建完备的系统与业务知识，抽象所有监控对象并构建不同监控对象关系，结合监控基础知识与大模型，生成完善的监控覆盖方案，其中需要重点关注业务监控基础知识差异，同时使用影响范围、对象分层等作为输入进行方案构建。

（2）如何做到监控项智能生成：依据监控对象、关系、基础知识、数据 / 业务特征及经验，生成含监控对象、策略、关联参数、通知方式等的多维度复杂监控项参数，这里结合时序模型、大模型来综合判断，最终结合监控平台能力完成监控项的生成；监控生成分为完全自主生成（适用于场景明确、准确度高的场景）与协同式生成（需人工确认，用于初始阶段或准确度不足时），两种方式适合于不同成熟度的场景使用。

（3）如何做到异常智能识别：通过规则、时序模型、大模型、动态阈值等机制，判断数据或用例结果是否为问题，不同的监控平台、监控对象、数据特征、业务特征适合不同类型的异常检测策略。

（4）如何进行智能降噪：分析单个报警 、关联报警、多个报警的异常特征、关系及盯盘情况来综合判断是否需要进行报警通知，并结合风险程度、影响范围、时效性等解决无效打扰、报警淹没等问题，平衡质效。

下面是典型的业务&监控平台提供的能力示例如下，通过上述关键问题的解决，结合底层完备/准确的知识构建和场景化的应用产品，监控召回率保持90%+，报警生成比例78%，部分业务监控降噪比例已达到60%。

报警生成示例

切流导致的报警降噪（绿色点不通知）示例

3.3 RCS  Agent（AI值班人）

风险控制系统主要解决报警后跟进及时性、排查准确性与效率问题，通过快速找到有效止损线索并止损缩小影响，将问题损失控制在最小范围，会面临以下几个关键问题：

（1）匹配最优跟进人 / 方案：如何结合问题影响面、跟进代价与时效性，明确 AI 或真人跟进的成本与效果。

（2）提供排查线索与止损预案：如何依据业务经验、变更信息、系统知识、历史故障等，匹配最契合排查链路/工具找到正确的线索并从预案库筛选最优止损方案，实现快速止损。

（3）解决跟进过程信息与人员混乱：针对多角色、多团队参与的线上处置场景，尤其长链路业务信息差问题，需要构建端到端事件管理机制，确保及时找对负责人、同步信息，减少干扰与维护成本。

为了解决上述问题，构建了一套统一的RCS建设方案，可实现基于AI的全方位风险控制能力。

方案中有几个关键部分，展开介绍如下：

（1）问题导诊：报警后快速明确风险影响面、跟进方（AI or 真人），提供智能排查结论，按业务特点构建导诊策略（如影响面、风险对象、业务类别等），实现差异化问题处置通路。

（2）端到端事件管理：搭建事件管理产品，覆盖事件感知、建群、排查、止损、总结、跟踪全生命周期，提供流程管理、信息互通等核心能力，同时完成事件信息的统一中心化存储，实现 MEG 线上事件标准化管理。

（3）AI值班人自主处置（常见于慢损问题）：对影响小、暂无需真人介入的问题，AI 通过定位工具调度、对话分析、人员地图等能力，完成初步分析、变更确认、标注等工作，确认是线上问题后再转真人跟进。自主处置AI值班人的目标是自主完成问题处置，所以需要建设完善的定位工具调度、单对单对话、自然语言分析、人员地图能力，并能够实现拟人化的信息确认和自主分析。

（4）AI值班人引导处置（常见于快损问题）：快损问题需真人与 AI 协同，AI 以助手身份提供线索推荐、工具推荐、止损操作推荐、事件盯盘等支持，且可动态调整策略（如根据损失预估切换止损方式），触达正确人员快速判断，快损事件的关键目标是快速止损，所以无论是触达效率、有损止损动作选择权衡等均需要以综合损失最小快速止损为目标。

（5）高危事件管控中心：针对业务与系统关联复杂的情况，构建全局管控中心与 MEG 高危事件 AI 值班人，与各业务 AI 值班人协同，实现事件信息、工具、线索互通，避免因信息差延误止损。

通过持续的能力建设和数字化构建，线上问题的智能定位覆盖率和准确率稳步增长，同时为了解决问题损失（等级）和MTTR的耦合关系，构建了基于损失速度分桶的损失控制达标率指标，该达标率同样持续提升至93%。AI值班人开始持续在风险控制过程中发挥作用，AI值班人协助率达到96%，端到端协率完成协助率达到40%。

04 总结&展望

随着RMCS能力的建设，质量结果得到了非常有效的控制（如下图）。

（1）从线上问题数量上看，线上问题总数逐年降低，25年对比22年降低比例超过53%，说明我们具备了将问题前置拦截通过风险呼唤前置解决的能力。

（2）从线上问题等级上看，严重问题数量也在持续降低，说明我们具备了快速问题感知和控制的能力，将高损问题转化为低损问题。

展望

目前质量风险管控已经发展了AI转型的重要时期，已经从使用AI解决工具问题变化为使用面向AI构建知识、产品，AI从辅助人慢慢的开始在更多场景可以替代人，因人的投入限制质量保障工作的限制会逐步被突破，质量风险管控后续也可能会变成人和AI更深度协同分析的局面，AI发挥自我学习、24h oncall、智能化的特长完成绝大部份的风险管控，正式员工发挥知识构建、训练AI并构建符合AI的管控产品，最终协同构建更智能化的风险管控目标。

导读

面对研发交付中Feature级项目复杂度攀升、信息分散及跨端协作低效等痛点，传统的Story级管理模式已显乏力。本文详细阐述了一套“项目级效能提升一站式交付最佳实践”，通过构建三大核心体系重塑研发流程：一是通过AI侧边栏与风险管控打造“AI项目管理”，实现信息聚合与决策提效；二是推动“一站式Feature交付”，利用AI自动生成测试方案与搭建环境，实现端到端闭环；三是建立涵盖“重点战役-Feature-Story”的三级数字化度量体系。这套新范式旨在以智能替代人工低效环节，助力团队从“被流程束缚”向“借智能破局”转变，实现研发效能的质的飞跃。

01 背景

在研发交付场景中，Story级别效率持续向好，但端到端 Feature 级项目持续增多，复杂度呈上升趋势。在传统工作模式下，研发团队正遭遇一系列制约效能的痛点：

• 信息分散、Feature视角管控缺失：研发过程中，需求卡片、Bug列表、测试用例等信息分散于不同空间；以及历史交付流程侧重 story 侧，缺少完整需求视角交付的风险洞察，导致项目无预警延期，管理成本趋增。

• 多方协作效率低下：联调测试依赖手动触发脚本，环境配置依赖人工协调；多模块联动存在用例交叉冗余、测试评审缓慢；跨产品线借调沟通成本高，各端测试人力重复投入且耦合重，拖慢研发节奏，项目进度风险激增 。

• Feature 级数字化能力缺失：既缺乏能够精准衡量 Feature 价值与进展的指标度量体系，也缺乏用于支撑分析、优化的标准化数据积累流程，导致 Feature 相关的评估无据可依，数据资产难以沉淀，进一步制约效能提升与问题根因定位。

为有效破解以上痛点，提升产研团队整体效能，我们构建项目级交付新范式：通过 “ AI 项目管理” 打造一站式项目信息与工具服务获取新入口，实现过程风险AI精准管控；通过 “一站式 Feature 交付” 推动单端联调模式向端到端交付模式转变，同时借助 AI 测试提效驱动交付效能跃升；通过 “项目级效能数字化度量” 构建完善的效能评估体系。

• AI项目管理：借助群聊侧边栏打造一站式项目信息看板，提升风险感知与决策效率；支持产研团队一键获取所需工具、服务，提升工具使用与协同效率；依托AIQA构建全流程管控能力并提效。

• 一站式Feature交付：通过建设端到端交付能力，释放冗余人力，并将测试方案生成、基础环境搭建等场景与AIQA深度融合，为 Feature 全生命周期提供高效、智能的一站式支撑。

• 项目级效能数字化度量：构建涵盖重点战役、Feature、Story 三个层级的更全面、立体的洞察体系，借助数据驱动的力量，全方位、深层次评估分析产品开发过程的效能表现与最终成果，为业务决策提供坚实有力数据支撑。

以智能替代人工低效环节，推动团队从 “被流程束缚” 向 “借智能破局” 转变，为效能提升注入新动能，引领团队协作进入智能化新范式，让每一次交付都更高效、更可控！

02 AI项目管理

2.1 项目管理痛点

在研发交付体系中，Feature级项目持续增多，复杂度呈上升趋势，团队项目管理普遍面临四大核心痛点：

• 信息碎片化带来高昂的把控成本

• 跨角色协作过程产生的高额隐性成本

• 分散工具链造成执行效率损耗

• 项目交付进展、风险纯依赖人工通知确认，交付周期长尾

为破解上述痛点，我们构建融合 “侧边栏 + AIQA过程管控” 的 AI 项目管理体系，实现信息整合、协作提效、工具聚合与交付管控闭环。

2.2 侧边栏应用

侧边栏统一解决方案，通过配置侧边栏框架，灵活定制卡片，以满足业务线各类场景应用，通常涵盖项目概览、项目详情、工具集合三大核心模块。

• 项目概览模块：以 PMO 视角为核心，深度整合项目进度、资源占用、风险预警等维度数据，支撑 PMO 实现精准的项目群管控与决策穿透 。

• 项目详情模块：聚焦产研团队执行视角，整合项目关联卡片、各类文档、bug 记录、上线记录、实验记录及测试环境等信息，保障研发高效协同与质量可控。

• 工具集合模块：提供了项目管理、联调提效等工具，可根据角色、产品线、项目，提供不同的工具入口，推动研发端到端衔接与操作链路简化。

通过具象化的配置实践，可在实际业务场景中落地，助力各角色高效协作，破解产研团队项目管理痛点 。以下实践案例，包括：项目概览、项目详情、工具集三大类内容，且支持PC和手机端样式，以及群吊顶和侧边栏位置。

2.3 过程管控

在项目各环节，AIQA以PMO数字助手的角色，建设基于AIQA的项目进度/风险提醒能力，通过输入框形式进行交互，全流程管控并提效。具体能力包括：AB实验长时间停留、AB实验放量实时、技术方案&打点方案等未评审风险等

• 项目评审风险提醒：支持技术方案、UI、实验方案、打点方案等提醒

• AB实验：待启动实验、实验中、评估中等9个阶段的停留时长；单台、放量、灰度等7个阶段的放量提醒

• 项目进度风险提醒

03 一站式Feature交付

3.1 端到端交付

产研需求常常是包括客户端、前端、服务端，两端以上联动的需求占比较高（>40%），各端分别投入人力测试，测试耦合严重，人力重复投入严重，通过建设交付能力，支撑实现需求测试从「单端测试+多端联调」交付模式，转为「端到端」交付模式，释放冗余人力。

例如客户端&服务端联动的需求，通过从功能角度评估客户端case对服务端case覆盖，覆盖的部分由客户端QA端到端测试，未覆盖部分通过夯实自动化能力补充测试或调起服务端QA补充测试，并通过准入/准出能力评估影响面和测试完备度，保证项目质量，释放冗余人力，提升整体测试吞吐。

各阶段支撑能力建设有：

• 测试前：通过端到端模式识别判断需求是否可以进行端到端的交付，动态自动分配测试人力，基于需求生成端到端测试用例，前端&服务端的环境自动搭建/更新，创建相应的mock环境等

• 测试中：基于代码提交进行风险洞察，以及提供问题定位、mock 能力供前端/客户端的同学更顺畅的完成测试过程，并且在过程中对测试流量进行录制，实时采集覆盖率，供后续测试评估；并在测试过程中阶段性评估测试进度风险，及时发现&通报过程中风险；

• 测试准出：测试完成后，自动触发服务端的异常测试、自动生成后续用于回归的自动化case，以保障服务端的迭代质量，整体完成后根据手工case完成率、bug闭环率、手工测试覆盖率、异常测试结果等多个维度综合进行测试准出评估

3.2 AI测试提效

3.2.1 测试方案自动生成

我们探索测试方案自动生成，目前可以通过分析MRD/PRD/CR，结合历史业务&工具知识经验，自动生成完整的测试方案，包括：

• 对需求的基本洞察理解（背景概述、分系统/模块升级点）

• 联调测试范围（涉及系统/模块等）作为环境推荐能力的输入

• 联调测试用例及可驱动AI测试执行的相关场景参数

• 测试经验&风险、历史相似项目参考

3.2.2 测试环境LUI搭建

建设LUI交互端到端环境部署能力，支持产研团队各业务线及图搜联调场景调用，端到端环境部署时长保持在小时级

功能点：

• 聚合用户的部署意图，支持多种prompt，完成LUI环境部署诉求：支持Feature卡片、QA单模块产物、单story卡片、联调CR、Fcnap域名等多种部署意图，聚合部署变更的信息

• 提供丰富的prompt向量库维护，实现精准的意图识别：prompt维护

• 基于qs-bot openmanus和mcp框架，实现丰富的工具集，通过动态规划调度工具交付各场景下的端到端测试环境：需求变更信息处理，数据聚合；触发多路复用环境部署；kirin异步轮询部署状态；qsbot回调重新触发动态规划；环境前后端链接与配置管理

• 聚合部署任务中的工具使用历史，异步回调完成环境部署完成后的智卡推送：聚合单次LUI中动态规划的工具返回信息；完成智卡数据构造并发卡推送给用户

04 项目级效能数字化度量

针对 Story 维度的度量工作，主要聚焦于对研发测试阶段展开持续且深入的洞察，旨在为从事研发测试工作的人员提供切实可行的优化方向与手段。但story维度的度量也存在如下问题：

• Story 粒度本身存在一定局限性，呈现研发-测试阶段的效率洞察，向左延伸的需求设计阶段，向右延伸的上线实验转全阶段，都不涵括在内，无法代表整体情况；

• 随着产品复杂程度日益提高，传统以 Story 维度为主的度量方式，无法站在产品需求视角观测交付效率，已难以满足需求；

• 站在每个组织的重点战役角度，story度量的方式，无法看到战役视角的资源投入和效率瓶颈，无法提供深层次的分析和决策。

为此我们开始建设贯穿重点战役-》feature-》Story的统一三级视角的数字化方案：

4.1 Feature级数字化

围绕从最初的发布规划、设计构思、开发实施、测试验证、正式上线，直至后续的小流量到逐步推全的整个生命周期，实施全方位、系统性的评估与监测，确保 Feature 的每个阶段都能得到有效把控与持续优化。最终实现更加高效地管理和优化产品开发流程，以及进一步提升团队协作效率。

4.2 战役级数字化

重点战役是企业为实现特定战略目标而发起的关键行动，往往需要通过一系列具体的Feature来实现其目标。

协同机制：重点战役的范围在季度初由PMO圈定，在业务拆解功能时在Feature上打上标记，数字化定期采集和处理分析，支持业务进行重点战役的进度监控和项目复盘。

05 总结与展望

立足项目级一站式交付实践，AI 原生思维在研发领域的价值将向更深、更广维度延伸：

• 从能力深化看，AI 将实现从 “被动响应需求” 到 “主动预测需求” 的升级，通过持续学习团队协作数据、项目交付规律，可提前预判研发各阶段的核心需求，预警潜在风险，让智能服务更具前瞻性

• 从场景拓展看，AI 与高频协作场景的融合将突破群聊边界，向需求评审、代码联调、线上问题排查等全研发链路渗透，构建 “全场景覆盖、全流程智能” 的研发协同体系，让智能能力随研发动作自然触发

• 从生态构建看，基于侧边栏的 AI 驱动协作模式，可进一步打通跨团队、跨业务线的数据与工具壁垒，形成可复用、可迭代的研发效能提升方案，推动 AI 原生思维从单一团队实践，升级为业务级研发协同标准

最终，AI 将不再仅是 “提效工具”，更将成为研发团队创新的 “核心引擎”，通过持续解放人工低效环节，让团队聚焦于技术攻坚、产品创新等核心工作，推动研发领域从 “效能提升” 向 “价值创造” 跨越，开启智能化研发的全新阶段。

导读

通过Turing Data Analysis(TDA）一站式自助分析平台建设，实现了业务看数、分析一体化闭环。然而，随着业务深度使用，分析需求也更加的复杂、多样，对TDA的分析能力提出了更高的要求，同时用户的极限查询与性能形成对抗，也影响了用户的分析体验。本文将聚焦分析能力增强与性能优化两方面，阐述具体的优化策略，以持续保证用户分析体验。

01 背景与问题

1.1 TDA概述

通过百度一站式数据自助分析平台（TDA）建设，实现了业务看数、分析一体化闭环：

1. 业务看板迭代提效（自助化）：数据报表迭代模式发生变化，从PM提需RD排期模式逐步转换为PM/运营自助化操作(做看板/分析数据）

2. 数据洞察分析提效（极速）：单次数据查询从分钟级降低到秒级，指标波动分析效率提升20倍，单次指标波动归因分析端到端从2小时->5分钟内

3. 业务一站式自助分析（一站式）：实现数据趋势观测、维度下钻分析、明细导出等功能，实现了数据监控、数据分析一体化体验。

1.2 问题与挑战

随着业务深度使用，分析需求也更加的复杂、多样，对TDA的分析能力提出了更高的要求，同时用户的极限查询与性能形成对抗，也影响了用户的分析体验：

1. 更高的分析能力要求：

a. 更复杂的统计指标计算：业务上需要计算周/月/季/年日均值及与前一周期（上一周/月/季/年）的对比差异值，以及对多行数据汇总合计等，这些更复杂的统计指标计算还无法高效满足；

b. 分析报告能力：在业务日常的数据使用中，周报/月报等固定周期数据的汇报是一个各业务通用且固定的使用场景。目前各业务多采用数据建设—>仪表盘配置—>人工下载整理—>添加数据结论—>生成周报的流程进行建设，在此过程中，数据整理、结论添加、跨平台整合等工作耗时耗力。

2. 性能“对抗”：随着数据量级增长、用户极限的分析（当用户发现查询变快后，会扩大查询周期进行更复杂的分析等）与性能形成对抗。

针对上面的问题，我们的解决方案是：

1. 分析能力增强：

a. 复杂统计指标自动计算：结合业务诉求，将业界通用分析计算方法（时间对比、占比分析、同环比、合计、日均值、排序、TopN、表计算等）落地到平台，计算方法可以交叉使用，来满足业务复杂的指标计算诉求。

b. 周报/月报等分析报告能力建设：通过对试点业务周报的分析，总结周报组成（周期图表数据 + 动态结论包括交叉分析结果及归因结论），因此通过图表 + 复杂统计指标计算 + 归因方法 + 动态富文本，最终生成例行周报，来提高工作效率。

2. 性能优化：完整的分析过程是，数据建模->引擎查询->平台二次计算呈现，故需要数仓、引擎和平台三方共建，确定长期监控目标图表查询P90及成功率，来长期监控优化。

接下来将从分析能力增强及性能优化展开讲述。

02 分析能力增强

2.1 复杂统计指标自动计算

整体思路：复杂统计指标计算能力是以TDA图表查询能力为核心，扩展SQL构建算子+数据处理算子，实现不同统计指标计算，灵活可插拔

△ TDA分析计算架构

分析case：分析近一年百亿级数据，按月聚合的环同比、日均、合计值

首先，传统的查询后处理方式，先查出明细数据，在内存中分组、合并计算。存在以下问题：

1. 当查询量级百亿时，内存中计算不太可能

2. 针对于复合指标如d = (a + b) / c，需要分别查出a、b、c的值，在处理；以及更复杂的如 sum( case when city = 'xx' then 1 case when city in ('xx', 'xx') then 2 end)，需要解析出SQL语法树，才能知道计算逻辑，无法保证数据计算准确。

所以，只能设计实现同环比、日均值、合计等SQL构建算子，将计算逻辑拼接到查询层，整体流程如下：

△ 分析近一年百亿级数据，按月聚合的环同比、日均、合计值

其中，环同比核心逻辑是：日期偏移+Join连接，查询本期数据与上一周期数据（偏移一周期），这样同维度的数据可以通过Join连接拼接到同一行，基于表列计算实现环同比计算

△ 同环比构建SQL

接着，日均值核心逻辑：

可加型指标（如分发量），日均分发量 = 分发量 / count(distinct 日期)；

非可加型指标（如dau、人均分发量等），通过子查询，先查出按天的明细，再计算按月的日均

为了优化性能，可先识别待计算的指标列表是否包含非可加型指标，若包含再通过子查询计算实现。

最后，合计核心逻辑：

为了优化性能，通过多协程非阻塞方式并发查询多个SQL，可以按需使用自动合计，减少查询的SQL数量。

2.2 周报/月报等分析报告建设

过去周报/月报书写通过PPT/PDF，采用数据建设—>仪表盘配置—>人工下载整理—>添加数据结论—>生成周报的流程进行建设，在此过程中，数据整理、结论添加、跨平台整合等工作耗时耗力，故我们将周报/月报场景固化为平台分析工具，帮助业务快速构建周报/月报，提高工作效率。

通过对试点业务周报的分析，可以发现业务周报的主要结构为：

1. 周期数据（文本）：按周/月汇总的数据，一般来自于TDA图表中的某些指标。

2. 图表（图表）：TDA中已生成的图表截图，或使用TDA中的数据画一些自定义的图表

3. 结论（归因 + 外部因素，文本）：结论包括两种，一种是基于数据集的交叉分析可以得出的结论；另一种是基于一些客观事实分析得出的结论，如天气变化、APP版本更新等。

因此，周报/月报的建设思路：

△ 周报case

1. 动态富文本：文本组件，可以嵌入TDA图表指标数据、交叉分析数据、归因数据等动态数据，以及截图等

△ 动态富文本

相较于传统PPT/PDF书写方式，智能周报最大的区别就是动态绑定数据，我们基于Lexical自研了动态富文本，通过宏定义变量绑定图表、归因结论等动态数据，通过跨模块消息通信，解决了动态数据渲染的性能问题，包括静态和动态分开渲染，减少等待，监听数据更新，避免重复数据请求，监听组件更新，避免频繁保存，提升编辑流畅度等

2. 复杂统计指标计算能力：复杂统计指标自动计算（同环比、日均值、合计等），上一章节已讲述

3. 归因决策能力：归因思路固化、归因算法、多级归因、例行归因等，下一章节讲述

2.3 归因决策能力建设

每个业务都有自己的一套分析思路，以百家号分析为例：

百家号核心指标波动排查路径：基于核心指标进行维度波动拆解，一般会进行2-3级拆解分析

如：对分发量（历史可分发内容）的归因分析

第一步：维度筛选（内容类型=图文；账号类型：禁言）

第二步：定位异常内容垂类（分内容垂类监测数据波动情况，找出波动top2垂类：财经、美食）

第三步：第一层维度归因（计算各维度各枚举值自身环比变化率、对垂类整体变化的贡献度，取top）（①作者粉段（10万粉段作者）、②发文来源（YY））

第四步：第二层维度归因（取除自身外的其他12个维度分别计算变化率、贡献度取top维度）

△ 业务分析树case

我们期望能提供工具化能力，让业务可以把自己的分析思路沉淀到平台，形成资产。

所以，归因决策的整体建设思路是：

以“分析树”作为分析思路落地的载体，抽象“异常发现”、“维度拆解”、“指标拆解”等通用分析算子，允许用户将业务分析思路固化在平台内形成“分析树”DAG图，实现自动的异常发现和分析，并结合数据就绪通知，将分析结论例行输出展示到分析报告里。

△ 分析树示例，数据为测试数据，仅供参考

2.3.1 异动检测：快速锁定，“哪里出了问题”

基于规则：根据业务经验，基于和之前日期数据的差异百分比来划定正常波动区间，如日环比、周同比等

基于时序预测算法：计算一个时序数据的置信区间，超出区间外的，则是异常值，算法如Holt-Winters、Prophet

整体检测的流程如下：

2.3.2 维度归因：横向看维度，“问题在哪个群体”

维度归因的整体流程如下：

分析类：入口，解析用户归因配置，确定维度拆解的视角（下钻、组合、自动选择），调用查询类查询所需的数据，调用归因算法对数据处理，最终调用输出类，按照呈现样式输出对应的数据格式

算法类：区分指标类型（可加型指标、比例型指标），适用算法不同

查询计算类：区分维度归因视角（下钻、组合、自动发现），查询计算方式不同

比如，原始数据：日期、A、B、M（指标）

△ 查询计算：下钻、组合、自动发现

2.3.3 指标归因：纵向看指标，“这个群体的问题是什么”

指标归因的整体流程如下：

1. 乘法指标拆解归因： 乘法因子贡献同时也适用于除法指标，只需要为分母建立一个倒数字段即可。

如A = B * C

2. 非乘法指标拆解归因： 在实际业务中核心指标会由由多个指标复杂的四则运算得到，或者没有公式关系但存在相关性，此时也需要量化评估子指标对核心指标变化的贡献

线性：如A = B + C - D，使用波动贡献计算即可

B贡献率 = ΔB / ΔA

C贡献率 = ΔC / ΔA

D贡献率 = -ΔD / ΔA

非线性：如房价和位置，楼层，面积的关系，并无严格的数学公式，但是又存在一些相关性。

我们假设一个指标可以表示为若干个相关指标的函数模型f，如：

A = f(B, C)

通过XGBoost进行建模，保证模型可以得到很好的预测效果（尽量贴合真实数据）

再通过SHAP，给出一个可加性的解释方法

yi=ybase+f(xi,1)+f(xi,2)+⋯+f(xi,k)

03 性能优化

3.1 性能挑战

1. 平台自身：以主题宽表建设数据集，单天数据量级千万级；分析复杂度高，按季度查询同环比、日均值等涉及Join、子查询、长周期的复杂查询场景；

2. 用户：数据量级不断增长，用户会照着性能极限去使用（比如优化过性能后，用户发现查询变快，会扩大查询周期），与性能优化形成对抗。

3.2 性能优化方案

完整的分析链路：数据建模->引擎查询->平台二次计算呈现，所以性能的优化也是需要数仓、引擎和平台三方共同推进建设。

整体的优化方案：

△ 数仓、引擎、平台三方共建

1. 平台从缓存、查询并发控制等角度优化性能，通过性能诊断工具，监控图表耗时情况，将诊断结果推送至数仓；

△ 性能诊断工具

1. 2. 数仓建模优化生产高性能数据集接入平台，定期治理一些长尾自定义字段。

2. 3. 引擎给数仓、平台提供能力支持，持续优化查询性能。80%+的数据集都是用Clickhouse，所以针对Clickhouse重点优化：ClickHouse在百度MEG数据中台的落地和优化

下面重点讲一下平台性能优化

3.2.1 分级缓存：CDN缓存、配置缓存、数据缓存

CDN缓存：静态资源统一接入一站式云平台fcnap，开启Http2.0和CDN加速；

配置缓存：仪表盘、图表等配置接口接入缓存，通过监听更新事件，异步更新缓存，保证缓存永久最新。

数据缓存：

• 首次查询：用户首次访问（缓存穿透），查询数据库，然后写入缓存

• 主动预热：对于一些固化的看数场景，例如仪表盘，提前把仪表盘图数据或图表查询放到缓存中，用户查看时直接读取缓存。

△ 缓存预热

预热主要分为三部分：预热生产、预热消费、预热监控

预热生产：确定哪些仪表盘需要预热，预热的触发条件，缓存更新机制等

预热消费：根据图表查询pv，确定消费优先级；高峰时段，预热任务主动避让，暂停生产；数据变更，根据血缘查找需更新的图表。

预热监控：监控消费队列的情况，记录失败的状态和原因；监控缓存命中率，调整预热生产策略。

最终，命中平台缓存的查询P90耗时优化至几百ms

3.2.2 与引擎、数仓联合，实现数据多级聚合

数仓在数据建模层面进行数据聚合，基于大宽表（事实表 + 维度表），并结合业务主题抽取出相应的维度聚合表作为CH数据集，为满足业务侧的拖拽式分析

△ CH数据集建设流程

部分公共仪表盘的首屏请求通过平台预热缓存兜住，而变更仪表盘条件以及下钻分析的查询，会穿透到引擎侧，所以在引擎侧实现了两层数据聚合：

1. 引入聚合表：基于Projection实现对查询中间状态的预聚合，避免对原始明细数据的大量磁盘扫描；

2. SQL级缓存：按SQL级粒度，将最终查询结果缓存在外部内存，缩短查询链路，并避免重复查询带来的多余磁盘IO。

△ 与引擎、数仓联合，实现多级聚合

平台将高频历史查询，同步到引擎侧，协助自动创建Projection，引擎侧实现对Projection进行全生命周期自动化管理。

3.2.3 查询并发：多域名转发请求，多进程 + 多协程响应请求

△ 并发查询

浏览器并发6限制：通过多域名方式，将图表请求与其他请求分流，保证平台交互流畅，图表请求并发度提升，从而提升总体耗时

多进程 + 多协程响应请求：单个请求处理时是串行的，但有些逻辑可以并行处理，如计算合计时，原数据SQL + 合计SQL通过协程并行执行，提高查询性能。

流控限制：多并发可能会带来引擎高负载问题，除了扩充引擎资源外，平台和引擎联合对查询进行流控限制，针对重复请求，引擎侧快速快速返回相应状态，平台根据状态码做对应的处理，来避免用户请求太多，导致负载过高，查询卡死

△ 流控限制

04 总结与展望

通过复杂统计指标自动计算能力、周报/月报等分析报告能力以及归因决策能力的建设，满足了业务更高分析能力诉求。通过性能优化，解决了用户分析与性能优化之间的长期“对抗”，来持续保证用户的分析体验。

目前TDA平台PV日均5w+，其中可视化分析PV占比70%+，用户已深度使用这套分析能力来解决日常分析诉求

随着AI的快速发展，我们也在不断探索BI与AI的融合落地，打造一个Data Agent（数据领域专家智能体），深度运用业务数据资产，实现主动思考、洞察、分析与行动（如自动识别 DAU 异常波动，并自动从维度和指标分别进行归因分析最终出优化产品功能或调整运营策略的报告建议），推动TDA平台从工具集合升级为智能决策伙伴，让每个用户都能拥有自主进化的数据大脑，持续释放数据价值。

导读

本文概述了在业务高速发展和降本增效的背景下百度MEG（移动生态事业群组）大数据成本治理实践方案，主要包含当前业务面临的主要问题、计算数据成本治理优化方案、存储数据成本治理优化方案、数据成本治理成果以及未来治理方向的一个思路探讨，为业界提供可参考的治理经验。

01 背景

随着百度各业务及产品的快速发展，海量的离线数据成本在持续地增长。在此背景下，通过大数据治理技术来帮助业务降本增效，实现业务的可持续增长变得至关重要。我们通过对当前资源现状、管理现状以及成本现状三个角度进行分析：

• 资源现状：各个产品线下业务类型繁多，涉及的离线AFS（百度公司分布式文件存储：Appendonly File Storage）存储账号和EMR（百度公司全托管计算集群：E-MapReduce EMR+）队列数量非常多，成百上千，什么时候启动治理，采用什么手段治理，并没有明确规划，且各业务间缺少统一的治理标准。

• 管理现状：针对离线资源的使用参差不齐，存储账号和计算队列资源的管理和使用较为混乱，有的使用率高，有的使用率低；此外，业务间的离线作业管理并不统一且不完全规范，没有完善的流程机制以及规范来对离线资源以及作业进行管理管控，并且计算任务的执行效率较低，整体运维难度较大。

• 成本现状：MEG各个产品线离线计算资源达数千万核，存储资源达数千PB，各产品线的离线计算和存储资源成本每年可达数亿元，随着业务的增长，如果不进行成本治理和优化，离线资源成本还会持续增加。

整体来说，目前主要面临数据散乱、资源浪费、成本增加等问题。基于以上存在的问题，我们通过构建统一的治理标准，并利用大数据资源管理平台搭建各产品线下的的离线存储资源视图、计算资源视图、任务视图以及成本视图，基于引擎能力对存储和计算进一步优化，帮助MEG下各产品线下的业务持续进行数据成本治理，接下来将具体阐述我们在大数据成本治理过程的实践方案。

△ 数据成本治理现状

02 数据成本治理实践方案

2.1 数据成本治理总体框架

---

针对目前存在的问题，我们主要围绕数据资产度量、平台化能力以及引擎赋能三个方面构建数据成本治理总体框架，实现对计算和存储两大方向的治理，来达到降本增效的目的，具体如下图所示，接下来将进行具体地介绍。

△ 数据成本治理总体框架

2.1.1 数据资产健康度量

为了对当前各个业务的计算和存储资源进行合理的评估和治理，我们采用统一的标准：健康分来进行衡量，而健康分计算的数据指标来源依赖于离线数据采集服务，该服务通过对当前计算队列，计算任务，存储账号，数据表等元数据信息进行例行采集，然后再进一步对于采集的数据进行分析和挖掘，形成一个个计算治理项和存储治理项，比如计算治理项可包含：使用率不均衡的计算队列个数、长耗时高资源消耗的计算任务、数据倾斜的任务以及无效任务等；存储治理项可包含1年/2年/N年未访问的冷数据目录、存储目录生命周期异常、inode占比过低以及未认领目录等。通过产生的数据治理项信息汇聚形成计算健康分和存储健康分两大类，如下：

• 计算健康分：基于队列使用平均水位+队列使用均衡程度+计算治理项进行加权计算获取。

• 存储健康分：基于存储账号使用平均水位+存储账号使用峰值+冷数据占比+治理项进行加权计算获取。

最终，通过统一规范的健康分来对当前各产品线下业务所属的数据资产进行度量，指导业务进行规范化治理。

2.1.2 平台化能力

此外，为了完成对当前产品线下离线计算和存储资源的全生命周期管理，我们通过搭建大数据资源管理平台，完成对各个产品线的离线计算资源和存储资源的接入，并基于平台能力为业务构建统一的计算视图、存储视图以及离线成本视图，整合离线计算任务需要的存储和计算资源，并将各类工具平台化，帮助业务快速发现和解决各类数据成本治理问题，具体如下：

• 计算视图：包含各个计算队列资源使用概览和计算治理项详情信息，并提供计算任务注册、管控、调度执行以及算力优化全生命周期管理的能力。

• 存储视图：汇聚了当前所有存储账号资源使用详情以及各类存储治理项信息，并提供给用户关于存储目录清理、迁移以及冷数据挖掘相关的存储管理以及治理能力。

• 成本视图：构建各个产品线下关于离线存储和计算资源总成本使用视图，通过总成本使用情况，更直观地展示治理成果。

2.1.3 引擎赋能

在实际离线大数据业务场景中，很多业务接口人对于大数据计算或者存储引擎的原理和特性不是非常熟悉，缺乏或者没有调优意识，通常在任务提交时没有根据任务的实际数据规模、计算复杂度以及集群资源状况进行针对性的参数调整，这种情况就会使得任务执行效率无法达到最优，且计算和存储资源不能得到充分的应用，进而影响业务迭代效率。针对上述计算和存储资源浪费的问题，我们结合大数据引擎能力，来实现对于计算和存储进一步地优化，助力业务提效，为业务的持续发展提供有力的支持。主要包含以下两个场景：

• 计算场景：结合任务运行历史信息以及机器学习算法模型能力，建立一套完善的智能调参机制，对于提交的任务参数进行动态调整，最大程度保障任务在较优的参数下执行，进一步提升任务执行效率，并高效利用当前计算资源。

• 存储场景：针对海量的存储数据，我们通过不同类型数据进行深入的分析和特征挖掘，实现了对存储数据智能压缩的能力，从而在不影响业务数据写入和查询的前提下，完成对现有数据存储文件的压缩，帮助业务节约存储资源和成本。

03 计算&存储数据成本治理优化

3.1 计算成本治理

在计算成本治理方向，我们主要基于平台和引擎能力，通过管理管控，混合调度以及智能调参三大方面对现有的计算资源和计算任务进行治理和优化。

3.1.1 管理管控

在MEG离线大数据场景下，主要涉及对上千EMR计算队列、以及上万Hadoop和Spark两大类型的计算任务管理。

• 一方面，我们针对各个业务的计算队列和计算任务的管理，通过平台能力实现了从计算资源的注册接入，到计算队列和任务数据的采集，再到离线数据分析和挖掘，最终形成如使用率不均衡的计算队列、长耗时高资源消耗的计算任务、数据倾斜的任务、无效任务以及相似任务等多个计算治理项，并基于统一规范的健康分机制来对业务计算资产进行度量，指导业务对计算进行治理。

• 另一方面，在离线混部场景，可能会存在部分用户对于任务使用不规范，影响离线例行任务或者造成资源浪费，我们针对Hadoop和Spark不同任务类型，分别建立了任务提交时和运行时管控机制，并结合业务实际场景，实现了并发限制、基本参数调优，队列资源限制以及僵尸任务等30+管控策略，对于天级上万的任务进行合理的管理管控，并及时挖掘和治理相关异常任务。目前运行的管控策略已经覆盖多个产品线下离线EMR计算队列上千万核，每天任务触发各种管控次数20万+。

通过对计算资源全生命周期的管理和管控，我们可以及时有效地发现可治理的队列或者任务，并推进业务进行治理。

△ 任务管理管控流程

3.1.2 混合调度

通过对于平台接入的队列资源使用情况以及任务执行情况的深度分析，我们发现当前各个业务使用的计算资源存在以下几个问题：

1. 不同产品线业务特点不同，存在Hadoop和Spark两种类型计算任务，并且Hadoop任务CPU使用较多、内存使用较低，而Spark任务CPU使用较低，内存使用较高。

2. 有些队列整体资源使用率不高，但是存在部分时间段资源使用很满，不同队列资源使用波峰不完全一致，有的高峰在夜间，有的高峰在白天。

3. 存在队列碎片化问题，一些小队列不适合提交大作业且部分使用率不高。

为解决上述问题，我们建设Hadoop和Spark混合调度机制。针对公司不同业务来源的任务，基于Hadoop调度引擎以及Spark调度引擎完成各自任务的智能化调度，并通过调度策略链在多个候选队列中选择最优队列，最终实现任务提交到EMR计算集群上进行执行。具体流程如下：

• 任务提交：针对不同产品线下的业务提交的Hadoop或者Spark任务，服务端会通过不同任务类型基于优先级、提交时间以及轮数进行全局加权排序，排序后的每个任务会分发到各自的任务调度池中，等待任务调度引擎拉取提交。

• 任务调度：该阶段，调度引擎中不同任务类型的消费线程，会定时拉取对应任务调度池中的任务，按照FIFO的策略，多线程进行消费调度。在调度过程中，每个任务会依次通过通用调度策略链和专有调度策略链来获取该任务最优提交队列，其中，通用和专有调度策略主要是计算队列资源获取、候选队列过滤、队列排序（数据输入输出地域，计算地域）、队列资源空闲程度以及高优任务保障等20+策略。比如某任务调度过程中，请求提交的队列是A，调度过程中存在三个候选队列A、B、C，其中候选队列A使用率很高，B使用率中等且存储和计算地域相差较远，C使用率低且距离近，最终通过智能调度可分配最优队列C进行提交。

• 任务执行：通过调度引擎获取到最优队列的任务，最终会提交到对应的EMR计算集群队列上进行执行，进而实现各个队列的使用率更加均衡，并提高低频使用队列的资源使用率。

△ 任务混合调度流程

3.1.3 智能调参

在数据中心业务场景，多以Spark任务为主，天级提交的Spark任务5万+，但这些任务执行过程中，会存在计算资源浪费的情况，具有一定的优化空间，我们通过前期数据分析，发现主要存在以下两类问题：

1. 用户没有调优意识，或者是缺乏调优经验，会造成大量任务资源配置不合理，资源浪费严重，比如并发和内存资源配置偏大，但实际可以继续调低，如case示例1所示；

2. 在Spark计算引擎优化器中， 只有RBO(Rule-Based Optimizer)和CBO(Cost-Based Optimizer)优化器， 前者基于硬规则，后者基于执行成本来优化查询计划，但对于例行任务， 只有RBO和CBO会忽略一些能优化的输入信息，任务性能存在一定的瓶颈，如case示例2所示。

△ 任务参数配置case示例

针对第一类问题，我们实现了对Spark任务基本参数智能调优的能力，在保证任务SLA的情况下，结合模型训练的方式，来支持对例行任务长期调优并降低任务资源消耗。每轮任务例行会推荐一组参数并获取其对应性能，通过推荐参数、运行并获取性能、推荐参数的周期性迭代，在多轮训练迭代后，提供一组满足任务调优目标并且核时最少的近似最优参数，其中涉及的参数主要有spark.executor.instances, spark.executor.cores, spark.executor.memory这三类基本参数。具体实现流程如下：

1. 任务提交流：任务提交过程中，会从调优服务的Web Controller模块获取当前生成的调优参数并进行下发；

2. 结果上报流：通过任务状态监控，在任务执行完成后，调优服务的Backend模块会定时同步更新任务实际运行配置和执行耗时等执行历史数据信息到数据库中；

3. 模型训练流：调优服务的Backend模块定时拉取待训练任务进行数据训练，通过与模型交互，加载历史调优模型checkpoint，基于最新样本数据进行迭代训练，生成新的训练模型checkpoint以及下一轮调优参数，并保存到数据库中。

4. 任务SLA保障：通过设置运行时间上限、超时兜底、限制模型调优范围，以及任务失败兜底等策略来保障任务运行时间以及任务执行的稳定性。

最终，通过任务提交流程、结果上报流程、训练流程实现任务运行时需要的并发和内存基本参数的自动化调优，并基于运行时间保障和任务稳定性保障策略，确保任务的稳定性，整体流程框架如下图。

△ 基本参数智能调优流程

针对第二类问题，我们构建HBO(History Based Optimization)智能调优模块实现对复杂参数场景的任务自动调优能力。首先，通过性能数据收集器完成对运行完成的Spark任务History的详情数据采集和AMP任务画像，然后在任务执行计划阶段和提交阶段，基于任务历史执行的真实运行统计数据来优化未来即将执行的任务性能，从而弥补执行之前预估不精确的问题，具体如下：

• 执行计划调优阶段：主要进行Join算法动态调整、Join数据倾斜调整、聚合算法动态调整以及Join顺序重排等调优；

• 任务提交阶段：基于任务运行特点智能添加或者改写当前提交的Spark任务运行参数，比如Input输入、合并小文件读、Output输出、拆分大文件写、Shuffle分区数动态调整以及大shuffle开启Kryo Serialization等参数，从而实现对运行参数的调优；

通过数据采集反馈和动态调参，不断循环，进而完成对于复杂参数场景的智能调优能力，让任务在执行资源有限的条件下，跑得更稳健，更快。整体实现流程图如下：

△ HBO智能调优流程

3.2 存储成本治理

---

在百度MEG大数据离线场景下，底层存储主要是使用AFS，通过梳理我们发现目前针对离线使用的各个存储账号，缺乏统一管理和规范，主要存在以下几个核心问题：

• AFS存储账号多且无归属：离散账号繁多，涉及目录数量多且大部分无Quota限制甚至找不到相关负责人，缺乏统一管理和规范；

• AFS存储不断增加：不少业务对于数据存储缺少优化治理措施，且存在很多历史的无用数据，长期存放，导致数据只增不减；

• 安全风险：各个账号使用过程中，数据随意读写甚至跨多个账户读写，安全无保障，并且缺少监控报警。

3.2.1 存储生命周期管理

针对上述问题，我们基于平台能力构建存储一站式治理能力，将存储资源的全生命周期管理分为五层：接入层、服务层、存储层、执行层以及用户层，通过建立存储资源使用规范，并基于采集的相关存储元数据，深度分析业务的离线AFS存储账号使用现状，将用户存储相关的问题充分挖掘和暴露出来，针对各种问题提供简单易用的通用化工具来帮助用户快速进行治理和解决，整体实现了各个集群存储账号的存储数据接入，采集，挖掘和分析，自动清理，监控预警全生命周期的管理。整体流程架构图如下：

△ 存储生命周期管理流程

• 接入层：通过建立规范的存储资源管理机制，比如存储的接入和申请规范、目录的创建规范、使用规范、利用率考核规范（Quota回收规范）以及冷数据的处理规范等通用化的规范，进而来完成用户从存储资源的接入-申请（扩容）、审核、交付、资源的例行审计的整体流程。

• 服务层：基于离线服务完成对各集群存储目录&存储冷数据Quota采集，然后进一步对数据进行深入分析和挖掘，包含但不限于冷数据、异常目录使用、存储变化趋势以及成本数据等分析。

• 存储层：建立账号、产品线、目录、任务、负责人以及账号的基本使用信息的元数据存储，通过Mysql进行存储，确保每个集群存储账号有对应归属；对于各个集群目录数据使用详情信息，选择Table（百度公司大规模分布式表格系统）进行存储。

• 执行层：基于存储管理规范，对于各个集群存储账号进行每天例行的存储自动清理，数据转储和压缩，并提供完善的存储使用监控报警机制。

• 用户层：通过平台，为用户构建不同维度的AFS存储现状概览视图，以及整合现有数据，对于各个集群的存储账号或目录进行分析，提供优化建议、存储工具以及API接口，帮助业务快速进行存储相关治理和存储相关问题的解决。

3.2.2 存储基础治理

在AFS存储资源的生命周期管理过程中，我们主要基于服务层和执行层为用户提供一套基础的存储AFS账号数据基础治理能力。通过离线解析Quota数据和冷数据目录相关的基础数据，完成对其计算、分析、聚合等处理，实现存储趋势变化、成本计算、异常目录分析、冷数据分析、数据治理项和治理建议等多方面能力支持。之后，用户便可结合存储数据全景视图分析和相关建议，进行存储路径配置、转储集群目录配置、压缩目录配置以及监控账号配置等多维度配置。基于用户的配置，通过后台离线服务定时执行，完成对用户存储的数据清理、空间释放和监控预警，保障各个业务存储账号的合理使用以及治理优化。

△ AFS存储数据基础治理流程

3.2.3 智能压缩

平台侧管理的MEG相关AFS存储数据上千PB，存在一部分数据，是没有进行相应的压缩或者压缩格式设置的并不是非常合理，我们通过结合业务实际使用情况，针对业务存储数据进行智能压缩，同时不影响数据读写效率，进一步优化降低业务存储成本，主要实现方案流程如下图。由于业务场景不同，我们采用不同的压缩方案。

• 针对数仓表存储数据场景：首先是通过对采集的数仓表元数据信息进行数据画像，完成表字段存储占比和数据分布情况分析，之后基于自动存储优化器，实现对数仓表分区数据读取、压缩规则应用以及分区数据重写，最终完成对数仓表数据的自动压缩，在保证数仓表读写效率的前提下，进一步提升数据压缩效率，降低存储数据成本。其中压缩规则应用主要包含：可排序字段获取、重排序优化、ZSTD压缩格式、PageSize大小以及压缩Leve调整等规则。

• 针对非数据仓表存储数据场景：在该场景下的存储数据，一般是通过任务直接写入AFS，写入方式各种各样，因此，需要直接对AFS存储数据进行分析和挖掘。我们首先对这部分数据进行冷热分层，将其分为冷数据、温数据以及热数据，并挖掘其中可进行压缩和压缩格式可进一步优化的数据，以及压缩配置可进一步调整的任务；之后，通过自动存储优化器，针对增量热数据，基于例行写入任务历史画像选择合适的压缩参数进行调优，并记录压缩效果；针对存量温冷数据，定期执行离线压缩任务进行自动压缩；最终我们对热数据进行压缩提醒，温冷数据进行自动压缩，从而实现该类型存储数据的压缩智能优化。

△ 智能压缩流程

04 治理成果

通过数据成本治理，我们取得了一些不错的优化和实践效果，主要包含数据开发和成本优化方面以及治理资产两大方面：

1. 数据开发和成本优化

• 数据开发提效：基于离线资源的全生命周期管理，计算和存储资源交付效率从月级或者周级缩短至天级，效率大幅提升，进而降低数据开发周期，此外基于混合调度和智能调参等能力，任务排队情况大幅降低，数据产出时效性平均提升至少一倍，大幅提高数据开发效率。

• 计算成本优化：实现了MEG下上千个队列使用更加均衡，并完成了千万核EMR计算队列资源平均使用率提升30%+，增量供给日常业务需求数百万核资源的同时，优化退订数百万核计算资源，年化成本可降低数千万元。

• 存储运维提效：通过利用存储数据基础治理等能力，完成了对上千个AFS存储账号管理、无用数据挖掘和清理，以及监控预警等，使得存储账号的运维更加可控，效率大幅提升。

• 存储成本优化：实现了对MEG下上千PB存储资源整体使用率平均提升20%+，增量供给日常业务需求数百PB资源的同时，优化退订数百PB存储资源，年化成本同样降低数千万元。

2. 治理资产

• 数据开发规范：逐步完善了资源交付规范、计算任务开发规范、存储和计算资源使用规范、以及数据质量和安全规范等多种规范流程。

• 计算&存储资源成本：形成各个产品线下关于计算资源、存储资源以及成本使用详情的概览视图，对于资源使用和成本变化趋势清晰可见。

• 数据任务资产：基于任务历史画像，构建任务从提交到运行再到完成的全生命周期的执行详情数据概览视图，帮助业务高效进行任务管理。

• 数据治理项：通过数据挖掘和分析形成的计算任务，计算队列和存储账号相关的治理项详情数据看板，助力业务快速发现可治理的数据问题。

05 未来规划

目前，通过标准化、平台化以及引擎化的技术能力，进一步完成了对MEG下离线存储和计算资源管理和数据成本治理，并取得一定治理成果，但数据成本治理作为一个长期且持续的一项工作，我们将持续完善和挖掘数据成本治理技术方案，并结合治理过程中的经验、流程和标准，实现更规范、更智能化的治理能力。

导读

本文聚焦百度电商风控场景，针对传统机审多模态识别弱、语义模糊难区分、审核体验差等痛点，推进原有机审流程向AI化流程改造，基于业界MultiAgent范式在审核场景落地应用，提出 “多模态大模型 + 规则 + 知识库” 协同的机审 Agent 方案。通过：1. 审核标准体系化、大模型化；2. 多模态大模型在领域典型问题上的抽象技术方案；3. 针对场景化问题精准优化。产出标杆式业务落地效果，为电商风控大模型落地提供可迁移能力强的技术方案。

01 背景与问题

1.1 背景

“百度优选”是百度旗下电商品牌，伴随着近年百度电商的快速成长，在 “人、货、场” 高速运转的背后，风控体系始终面临 “安全 - 效率 - 体验” 的三角挑战：

• 对平台：风控是 “生命线”若未能准确及时的管控风险，可能引发监管处罚、用户信任流失，甚至影响百度的商誉。

• 对商家：“快过审 + 明理由” 是核心诉求，在传统人工审核流程中，商家提交信息后需等待2-4 小时（峰值期甚至 1 天），若被拒审仅收到 “内容违规” 的模糊反馈（在历史的商家访谈中，部分不满意指向了 “审核慢、理由不清”）。

• 对用户：“看到靠谱内容” 是关键，若平台出现了不可靠或者低质的信息，用户可能会因 “被骗” 损失利益，从而进一步导致用户的流失 。

作为百度电商风控技术团队，我们的目标很明确：用大模型重构机审体系，实现 “全机审覆盖 + 即时反馈 + 高可解释性”，让平台 “安全”、商家 “高效”、用户 “放心”。

1.2 面临的问题

在大模型落地前，我们的传统风控流程是 “商家提交→机审（规则+小模型过滤）→人审（人工判定）”，这种模式在业务快速增长下：

• 问题 1：人审瓶颈刚性，无法支撑业务增长

• 问题 2：机审能力薄弱，为保证风险不露出人审覆盖面大，审核时效长（小时级，极端情况下甚至长达1天）

• 传统机审依赖规则引擎（如关键词匹配 “最佳”“第一” 判定虚假宣传），但无法处理复杂场景：

• 多模态违规：主图显示 “Nike”品牌，详情页显示为”山寨品牌“—— 规则无法识别图文不一致；

• 模糊语义：“本品有助于睡眠”（合规）vs “本品治愈失眠”（违规）—— 规则无法区分 “程度差异”；

• 问题 3：审核体验差，商家申诉率高

• 传统机审拒审理由模糊，商家需反复猜测修改方向。

为了解决上述提到的问题，本文将详细介绍本次最佳实践

02 技术方案

针对传统流程的痛点，我们提出 “大模型 + 规则 + 知识库” 协同的机审 Agent 方案，核心逻辑是：让模型做 “语义理解”（擅长的事），规则做 “确定性判断”（稳定的事），知识库补 “外部信息”（精准的事）。

2.1 整体技术方案

流程上，我们重构了整个审核流程，实现了 “全机审覆盖 + 即时反馈 + 动态校准”：

原流程 vs 新流程对比

2.2 亮点

2.2.1 审核标准对齐

要实现全机审，“人审标准可量化” 是前提。我们通过 “风险梳理→标准优化→动态更新” 三步，将 700 余个零散风险点整合成 24 组核心风险，覆盖了95%+的线上违规问题。

步骤 1：风险点梳理 —— 做 “减法”

我们采集2025年Q1的全部人审记录，

• 相似风险合并：采用层次聚类将相似违规进行归类。

• 风险分层：对”风险严重程度“较低，且不直接影响商品价值和用户购买决策的风险暂时不纳入机审（人工巡查覆盖）。

• 长尾剪枝：对”发生频率“较低的风险暂时不纳入机审（人工巡查覆盖）。

步骤 2：审核标准优化 —— “规范化”

我们把人审识别的风险划分为三部分，明确违规/明确不违规/边界样本

步骤 3：动态更新 —— 做 “迭代”

我们每月例行巡查、回收商家申诉和人审处理数据，若发现新违规类型，则补充到风险组，及时更新线上机审agent。

2.2.2 基于多模态大模型的机审agent设计

大模型是机审 Agent 的 “大脑”，我们选择大语言模型+多模态大模型为基础，辅助知识库（品牌授权库、类目树、资质库），实现 “多模态理解 + 精准判定”。

输入层：多模态数据整合

接收商家提交的全量商品数据，包括：

• 文本数据：商品标题、详情页描述、规格参数、商家资质名称；

• 图像数据：主图、详情图、资质图片（如《授权许可证》）；

• 结构化数据：商家资质库（如品牌授权记录、进口报关单）、平台类目树、风险规则库。

特征抽取层：多模态特征融合

特征抽取是机审的 “感知层”，我们采用 “规则抽取 + LLM 文本理解 + 多模态模型图像理解” 的组合方式，覆盖所有维度的商品信息：

• 规则抽取：用正则表达式提取标题中的品牌（如 “Nike”）、类目（如 “运动鞋”）、关键词（如 “进口”）；

• LLM 文本理解：用文心大模型提取详情页中的模糊语义（如 “治愈失眠” 的违规表述）、逻辑矛盾（如 “进口商品” 但未提报关单）；

• 多模态大模型图像理解：使用多模态大模型模型识别主图中的品牌 logo（如 Nike 的 Swoosh 标志）、资质图片中的 OCR 信息（如《授权许可证》编号）。

风险判定层：大模型 + 规则 + 知识库协同

风险判定是机审的 “决策层”，核心逻辑是 “让专业的模块做专业的事”：

• 规则引擎处理确定性逻辑：针对 “绝对化用语”“资质必填项” 等确定性规则，直接用代码判断（如 “含‘进口’关键词必须提交《进口报关单》”）；

• 知识库查询外部信息：关联商家资质库、平台类目树等领域知识（如查询商家是否有 Nike 的授权记录）；

• LLM 综合判定：融合多模态特征、规则结果、知识库信息，输出最终结论（如 “主图含 Nike logo + 无授权记录 → 品牌侵权违规”）。

输出层：精准反馈 + 可解释性

输出层是机审的 “交互层”，需满足商家的 “明理由、能整改” 需求：

• 审核结果：通过 / 拒绝；

• 拒审理由：自然语言描述（如 “您发布的商品主图含 Nike 品牌 logo，但未提交 Nike 品牌的《授权销售许可证》”）；

• 整改建议：输出给发品端前端，提供自动整改能力（如删掉对应违规位置违规信息）。

任务拆分：让模型 “专注擅长的事”

我们将机审任务拆分为三类，以同时保证审核结果的高召回，高准确，清晰可解释：

• 特征抽取：提取商品的关键信息（如从主图提取品牌 logo、从详情页提取材质等）；

• 风险判定：规则引擎结合知识库，判断特征是否违规（如 “logo 是 Nike，但无授权→侵权”）；

• 理由生成：模型生成自然语言拒审理由（如 “未提交xx品牌的授权许可证，请补充”）。

03 实践案例

在典型问题的文本问题判定，图片问题判定，图文融合问题判定上，经过我们的技术方案演进，均可达到几乎对标人审能力的效果。

3.1 资质缺失风险判定

场景描述

针对高危商品行业如三品一械行业，售卖相关商品时要求商家提供清晰可辨、且信息完整的对应资质（如《保健食品批准证书》、《国产特殊用途化妆品行政许可批件》、《医疗器械备案证明》、《委托进口协议》等）。

传统流程痛点

• 规则策略：仅能检查 “是否含‘进口’关键词”，无法关联商家资质库，漏检率高；

• 人审需人工查询和核对资质，耗时长，易因 “漏看” 导致误判。

机审方案：领域微调 + Prompt Engineering

对于此类复杂判定类问题，领域知识深度深，我们基于基座模型进行了模型微调，通过高质量样本收集 -> Prompt Engineering -> 数据增强 -> 模型微调 得到了专注于电商风控场景的领域AI模型

• 高质量样本收集 ：我们将真实场景下经人工核验的高质量样本沉淀为模型训练语料。这一环节是模型训练的核心，保障了训练数据的真实性、多样性，以及对各类场景的覆盖丰富度。

• Prompt Engineering：基于不同样本类别，设计场景化提示词，引导模型关注风控领域知识：

• 数据增强：我们采用SOTA思考模型，动态生成Cot并对生成内容进行精细化纠偏，提升模型的推理能力：

• 模型微调：对比百度自研文心基座模型和开源Qwen系列模型，我们分别对比和采用了全参数微调和指令微调方式，加速训练过程，进一步提升模型效果，获得风控领域专家模型。

3.2 品牌授权风险判别

场景描述

商家发布的商品信息，涉及限售品牌，但实际未获得品牌授权（易引发假货投诉等体验问题）

传统流程痛点

• “山寨 logo”较难以识别（如 “Nlke” 冒充 “Nike”）；

• 授权书需人工手动核验，耗时久，漏检率较高；

• 管控品牌库变动升级较多

机审方案：多模态特征匹配 + 知识库关联

采用 “多模态模型图像识别 + LLM 字符相似度对比 + 知识库查询” 的方案：

1. 多模态模型图像识别：采用多模态模型提取主图中的 logo 特征；

2. 知识库查询：关联限售品牌库，确认品牌是否限售，是否有授权记录；

3. LLM 图文信息融合判断：确认提取品牌信息是否限售且无授权；

3.3 类目错放风险判定

场景描述

1）因电商商业流量推荐等场景中列类目特征权重极高，类目准确性严重影响流量变现效率；2）平台佣金政策和资质/定向准入等管控要求与类目强关联；因此要求商家发布商品必须选择到平台类目体系内最准确的类目；

传统流程痛点

• 图文特征融合困难：传统方案一般仅使用标题识别类目，商家对抗后容易绕过机审

• 平台类目庞杂：审核员需非常了解平台近5000个类目结构，极容易误审

方案演进

方案一：基础方案

• 图文特征融合推荐平台top相似度类目

方案二：解决类目推荐不准确问题

• 改为召回+rank 两阶段方案，提升精准选择类目可能性

• 升级相似度计算模型为bge-large-emb，解决部分情况下相似度召回精准不足问题

方案三：解决部分高风险商品在第一轮候选集召回不足问题

• 增加定向召回通路，提升高风险商品召回能力

• 升级风险判定方案，结合大模型判定和识别规则，进一步提升精准判别能力

04 总结与展望

4.1 落地效果

超预期的 “三升三降”

三升

• 机审覆盖率提升

• 审核时效提升

• 商家满意度提升

三降：

• 人审量减少

• 申诉率减少

• 用户投诉率减少

4.2 经验总结

大模型不是 “取代人”，而是 “解放人”—— 让审核人员从 “重复劳动” 转向 “标准制定、风险预判”。

本次落地实践较为成功的要点

• 多模态融合：电商数据 80% 是多模态的，单模态模型无法覆盖所有场景；

• 可解释性优先：大模型的自然语言生成能力是提升商家体验的关键 —— 传统规则的 “内容违规” 无法让商家整改，而 LLM 生成的 “未提交 Nike 授权许可证” 能直接指向问题，进一步的我们业务团队为商家提供了一键整改功能，大大提升商家使用平台工具的满意度；

• 闭环迭代：用巡查、申诉数据持续优化模型，形成 “数据→模型→效果提升” 的飞轮；

4.3 展望

agent的自我优化：利用大模型生成能力生成难样本，解决风控场景的大难题——小样本问题，辅助少量人工干预使得agent自我演进和优化。

05 结语

过去的1年里，大模型技术突飞猛进的发展，为电商风控带来了 “质的飞跃”—— 从 “被动堵风险” 转向 “主动防风险”。在百度电商风控技术的实践中，我们乘着时代的技术红利，落地 “多模态大模型 + 规则 + 知识库” 解决了传统机审的痛点，实现了 “平台安全、商家高效、用户放心” 的平衡。未来，我们将继续探索 “AI + 风控” 的边界，提供可快速迁移的大模型落地方案。

导读

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

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

01 摘要

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

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

02 背景

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

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

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

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

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

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

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

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

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

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

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

03 直观感受雪崩的威力

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

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

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

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

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

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

04 雪崩的特点

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

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

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

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

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

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

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

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

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

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

05 理论模型

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

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

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

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

06 微观灾变过程

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

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

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

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

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

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

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

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

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

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

07 真实案例验证

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

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

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

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

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

08 系统性思辨

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

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

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

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

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

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

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

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

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

09 我们的实践

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

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

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

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

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

• 端到端失败数量

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

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

• 分片服务：分片丢失率

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

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

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

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

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

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

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

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

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

10 治理结果

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

本文系统阐述了以大语言模型为核心驱动力的“数据平台智能化入库”方案，构建了从模式识别到自动部署的智能代码闭环，实现数据接入效率与质量的双重飞跃。

导读

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

背景

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

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

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

1. 2023年之前架构

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

2. 问题分析

2.1 旧架构分析

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

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

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

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

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

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

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

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

2.2 重构思路分析

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

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

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

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

建模思路：

（1）降低迁移成本

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

（2）双轨输出机制

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

（3）兼顾历史和未来

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

3. 解决方案

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

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

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

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

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

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

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

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

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

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

4. 新的问题&解决策略

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

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

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

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

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

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

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

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

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

02 第二阶段：全面提速

1. 2023→2024年架构

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

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

2. 问题分析

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

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

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

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

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

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

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

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

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

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

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

3. 解决方案

3.1 ETL框架升级

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

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

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

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

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

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

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

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

Spark对比MR的核心优势：

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

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

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

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

3.2 日志分类分级

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

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

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

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

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

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

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

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

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

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

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

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

3.3 AB实验数据扇出处理

3.3.1 现状与问题

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

3.3.2 解决方案

（1）分析过程

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

（2）设计思路

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

（3）成果与收益

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

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

4. 分级存储治理

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

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

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

具体实施策略：

03 总结与展望

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

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

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

随着人工智能技术的迅猛发展，如何在视频内容创作领域通过大模型自动化合成视频，来满足用户日益增长的内容需求？

随着百度Feed流业务高速发展，如何建设时效更高、数据更准确、架构更稳定的Feed实时数仓？详细阅读查看

看BaikalDB如何借助模型上下文协议(MCP)，让数据库对话像聊天一样简单——无需编写代码，大语言模型即可完成复杂数据分析。

你有没有这样的体验？导航说30分钟能到，结果真的一分不差？ 有时候导航告诉你要绕行5分钟的路，其实省下了20分钟的堵车。 这些神奇的“预知能力”，就是我们常听到的 ETA（Estimated Time

你有没有过这样的体验？在高速上对着导航喊“小度小度”，它就神奇地回应道“来了”；在地下车库问“最近的充电桩”，屏幕立刻跳出相关的充电桩指引；甚至对车载语音助手说“有点冷”，空调的温度就会悄悄调高。这些

面向业务场景的大模型评估中会面临着什么样的问题，如何解决这些问题，在实际评估中又需要注意哪些问题呢？

本文重点介绍TDS在数据开发治理实践上的核心理念与技术落地，包括“流程标准化、质量可控化、运维智能化”三大方向。