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

从2023年成立到如今日均服务2万+直播间，百度慧播星已演进为覆盖脚本生成、实时问答、智能决策、音视频克隆的全链路AI直播平台。本文深入解读其技术架构：如何通过检索增强和强化学习生成高转化脚本；如何利

基于AI的质量风险管控旨在通过AI解决质量领域诸多难题，本文分别从风险前的风险管理、风险中的风险感知和风险后的风险控制等多个阶段介绍质量管控的整体思路，实现质量结果的持续可控。

本文介绍了一种融合“AI项目管理、端到端Feature交付、全视角数字化度量”的研发新范式，旨在利用AI技术解决协作痛点，实现研发交付的高效与可控。

面对复杂的业务场景，百度数据分析平台（TDA） 通过分析能力增强与性能优化双轮驱动，来持续保障用户的分析体验

本文概述了在业务高速发展和降本增效的背景下百度MEG（移动生态事业群组）大数据成本治理实践方案，主要包含当前业务面临的主要问题、计算数据成本治理优化方案、存储数据成本治理优化方案、数据成本治理成果以及

百度电商风控研发团队在审核场景，通过流程ai化改造和建设机审AI Agent，阶段性实现了替代人审和完成审核提效目标的最佳实践。

本文深入剖析大规模微服务系统中雪崩故障的形成机理与微观演化路径，并结合百度系统性治理框架，分享可落地的预防与应对实践。

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

导读

面对百度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在数据开发治理实践上的核心理念与技术落地，包括“流程标准化、质量可控化、运维智能化”三大方向。

本文介绍了百度网盘如何通过Flink构建实时计算引擎，以解决Spark Streaming存在的问题，提供高性能、低延迟、稳定的实时计算能力，并介绍了实时计算引擎的演进历程、选择Flink的原因及展望

本期内容4年开发经验的 Java 大佬执墨为我们带来了包括规则配置在内的5个文心使用技巧分享。助你增加 AI Coding 技能点！一起来看看！

执墨，4年开发经验程序员一枚，一个懂点 AI 的软件研发工程师，持续学习有意思的技术、做有意思的事，目前在探索如何培养出一个 AI 开发搭子。

相信大家在实际使用 AI 生成代码的过程中，会发现**有些代码让人抓心挠肝，不是放错了位置，就是不符合项目规范，最后还要返工手动修改，觉得不如自己手搓。**但别担心，自己学写代码怎么说也学了三四年，玩游戏角色释放技能也有前摇，AI 写好代码当然也需要慢慢培养。从 Zulu 开始公测我就在使用文心快码，也算是小有经验。那么结合个人在 IntelliJ IDEA 中的使用体验，我总结了 Zulu 和 Chat 各自比较实用的技巧，希望能对大家有所帮助。

▎Zulu 调教指南：生成代码更可用

1.用 # 提供上下文

大语言模型本质上是基于前文内容来预测下一个最可能的词或代码片段。没有上下文，模型就无法准确判断下一步生成内容，因此对上下文的理解和利用是生成高质量代码的基础。在开发场景中，上下文不仅包含当前文件或代码片段，还涵盖项目结构、依赖关系、函数和变量作用域等。通过理解这些上下文，AI 能够更准确补全代码或生成符合项目风格的内容。

在文心快码中为 Zulu 添加上下文：Zulu 目前支持文件、文件夹和项目级别的上下文。开发者可以通过 # 操作符来唤起当前被索引的所有的文件，并添加为当前会话的上下文。

Step1：# 操作符唤起上下文菜单

Step 2：选择对应的文件或者目录。可以添加多个，如果没有选择上下文，则会默认使用当前项目为上下文环境。

Step 3：上下文配置好以后，可以通过自然语言的方式来描述你需要让 AI 干的事情。

在这个例子中，我选择了 Cache.java 这个文件，然后让 Zulu“实现一个查询缓存时，根据类型做反序列化的函数，目标为 Redis 序列化”。这时 Zulu 就开始阅读上下文，立刻理解了我的需求，在 Cache 接口中进行修改，添加了目标功能。

2.善用命令自动执行

**Zulu 能够自动感知当前工程的框架、技术栈、文件结构和运行环境，根据需求自动生成终端命令，并将这些命令发送到开发环境中的终端进行执行。**这种能力在脚本语言的开发过程中，非常具有优势，比如 Python、JS 等。你无需关注需要使用什么框架，AI 自行去进行使用和安装，开发者能够更专注于业务逻辑的实现。

例如在下面的 Python 虚拟环境创建和配置中，Zulu 首先生成并执行了终端命令 python3 -V，查看当前环境中已安装的 Python 版本，然后通过命令 python3 -m venv venv 创建了一个虚拟环境，最后通过 source venv/bin/activate && pip install -r requirements.txt 激活虚拟环境并安装项目依赖。整个过程完全没有跳出 IDE，极好地维护了开发过程中的心流体验。

3.规则约束

当没有提供规则文件去约束 Zulu 的生成行为时，在进行一个新的项目开发过程中，很容易会生成一些不达预期的代码，也会魔改代码。了解到文心快码支持自定义 Rules，因此我为 Zulu 编写了执行的上下文约束，控制其代码的生成。下面将具体展开我撰写规则的思路。

3.1编码环境

**介绍当前的编码环境，说明当前项目的所使用的技术栈。这一步至关重要，就好比给 Zulu 描绘了一幅项目的蓝图，让它清楚自己所处的 “战场” 环境。**例如在这个基于 Java 的 Spring Boot 项目中，明确告知了 Zulu 项目使用的是 Java 语言，以及 Spring、Spring Boot、Spring Security 等相关技术框架。这样，Zulu 在生成代码时，就能遵循这些技术栈的规范和特点，生成与之适配的代码。

## 编码环境
用户询问以下编程语言相关的问题：
- Java
- Spring&SpringBoot&SpringSecurity
- MyBatis&MybatisPlus
- RocketMq
- Nacos
- Maven
- SpringSecurity

3.2代码实现指南

**这个部分说明当前项目具体的代码如何实现，比如数据库表的创建规范、用户上下文怎么获取、项目结构的含义等。这相当于给 Zulu 制定了一套详细的工作 SOP，让它生成的代码符合项目的特定要求。**在采用 DDD（领域驱动设计）方式实现代码的项目中，我为 Zulu 提供了如下的 SOP。

1. 项目使用 DDD 的方式来实现代码，你需要注意如下几点：
  1. 领域层和仓库层的入参都要使用 DO、仓库层的实体对象需要添加 PO 的后缀
  2. Application或者Service层的输出必须的DTO，接口层的返回可以是DTO 也可以自己定义 VO
  3. 每一层对应的对象都需要添加对应的后缀，并且后缀要全大写。如仓库层的实体 UserPO，领域层领域UserDO，应用层的DTOUserDTO
  4. 项目的类之间的转换需要使用 MapStruct 来完成
2. 在使用三方依赖的时候，需要将对应的依赖内容先添加到 Maven 依赖中
3. 所有的接口都按照 RestFul 的风格定义，并且你需要区分接口的使用场景，如：前端使用、OpenApi、小程序端使用。
  1. 如果你无法通过用户的上下文知道需要你生成的接口的使用场景，你可以再次询问用户
  2. 前端统一前缀使用 /api/fe/v1/xxxxx，OpenApi 使用 /api/open/v1/xxxx，小程序使用 /mini-program/v1/xxxx并且三个入口的文件需要区分不同的文件夹
  3. 对于批量查询接口，你需要涉及分页的能力，不能使用内存分页，只能在 DB 层面做分页，并且要考虑深分页的问题
  4.  所有的接口返回需要返回 BaseResp 对象，BaseResp 的定义如下：
  @Data
  publicclassBaseResp<T> {
      privateString code;
      privateString message;
      privateT data;
  }
  4. 对于应用层，需要注意如下几点：
      1. 函数的输入和输出都是 DTO

3.3总结历史记录

每次使用 Zulu 生成代码后，可以让 Zulu 帮我们将每一次 Query 后的结论进行总结并记录到文件中，这对于项目的跟踪和回溯非常有帮助。提示词如下：

## 历史记录
1. 针对你回答用户问题的答案，你需要将本次回答的内容记录到项目的根路径下的 .cursor-history 文件里，格式如下：
2025-11-11 10:10:10
变更内容如下：
1. 增加用户模块
2. 修改用户管理内容
3. 增加用户内容
涉及文件为：
xxxx.java
xxxx.java
2. 你需要按照倒序的方式记录这个历史纪录

这种详细的记录格式，能够清晰地展示每次代码生成的时间、变更内容以及涉及的文件，方便开发者随时查看和追溯项目的开发记录。而倒序记录使得最新的变更记录排在前面，开发者能够快速获取到最新的项目动态，提高了信息查找的效率。

▎Chat 隐藏技巧：编码交互更灵活

在研究 Zulu 的同时，我也发现了 Chat 功能比较好用的地方，下面想继续分享一些让编码过程更方便快捷的能力。

1.Inline Chat 行间会话

通过圈选代码片段，使用 Ctrl + I 快捷键可以唤起文心快码的行间对话能力，帮助我们快速对局部代码进行优化和调整，**此时上下文即当前的代码片段。

在对话框中输入需要 AI 完成的任务，Comate 会自动扫描代码并编辑，编辑完成后可以自行决定是否采纳或者忽略。

2.Git Commit 快捷键提交代码

在完成一个功能模块的开发后，需要提交代码到版本库。一般来说需要手动梳理本次代码的修改内容，编写提交信息。而在文心快码中，只需点击 Git Commit 快捷按钮，Comate 就能自动分析代码的变更情况，生成详细准确的提交信息，大大节省了时间，同时也提高了提交信息的质量，方便团队成员更好地了解代码的变更历史。

在 Git Commit 的时候点击快捷按钮，可以快速总结本次代码的变更内容。

▎案例实操

接下来就把这些小技巧应用在实际案例中，检验一下是否对开发流程有提效。

1. 实现一个社区自动签到脚本

文心快码在编写脚本方面具有显著优势，准确率极高。在实际工作中，我现在用到的脚本几乎都由文心快码完成，并且几乎都能一次性运行通过。**以实现一个社区自动签到脚本为例，具体操作步骤如下：

Step 1: 书写提示词，直接用自然语言描述即可，需要给出其接口定义信息和执行规则。

“给我写一个 python 脚本，实现接口签到和抽奖能力。

以下是签到接口的定义：

GET 接口：……(为保护隐私，此处略去）

以下是抽奖接口的定义：……

再调用接口时，你需要按照先调用签到再调用抽奖的顺序来完成，并且这两个接口需要一个 cookie 信息来完成调用，因此你需要定义一个全局的 cookie 来实现这两个接口的定义。”

Step 2: Zulu 后自行生成对应的文件

Step 3: 按照 Zulu 的提示执行对应的命令，然后这个脚本就成功实现完成了。

2. 实现一个约束之下的意图识别服务

这个案例的重点在于，在新的项目中如何将自己业务项目中的一些编码规则告知 AI，使生成的代码更符合团队的开发规范。

Step 1: 书写提示词，在提示词部分添加了“实用技巧”中的第3点规则约束部分提到的规则。

“我需要你实现一个意图识别的工程能力，它的主要功能是对外提供一个 OpenApi 的接口来根据用户的输入返回一个固定的意图。这个 OpenApi 的实现思路是：

1.查询本地的规则列表；然后进行匹配；

2.如果本地的规则都无法匹配，则调用第三方的 LLM 接口进行意图识别；

3.返回结果。

你的代码实现需要按照这个规则来：#.zulurules”

完整规则见附录一

Step 2: Zulu 生成代码与总结

▎写在最后

文心快码是我个人使用的第一款 AI 编程工具，其核心功能围绕两大模块展开：编程智能体 Zulu 与 Chat ，二者协同能够满足不同编程需求。Zulu 与 Chat 功能相比，核心差异在于其具备更强的自动化编码能力：能够直接生成完整文件并编写代码，且生成内容会以 Diff 格式清晰展示修改痕迹，方便开发者直观对比并选择是否采纳。文心快码插件实现了与 JetBrains 系列 IDE 的深度集成——开发者无需离开熟悉的 IDE 环境，即可调用 AI 编程能力。对于我这样习惯使用 JetBrains 工具链的 Java 程序员而言，这种原生集成的体验尤为友好，能在日常开发流程中自然融入 AI 辅助，减少工具切换成本。

附录：Rules 示例

你是一名资深后端开发专家，精通 Java、Spring、SpringBoot、MyBatis、MyBatisplus、RocketMq以及各种中间件，如：Zookeeper、Nacos、SpringCloud等。你思维缜密，能够提供细致入微的答案，并擅长逻辑推理。你会仔细提供准确、事实性、深思熟虑的答案，并且在推理方面堪称天才
- 严格按照用户的需求执行。
- 首先逐步思考——用伪代码详细描述你的构建计划。
- 确认后，再编写代码！
- 始终编写正确、符合最佳实践、遵循 DRY 原则（不要重复自己）、无错误、功能完整且可运行的代码，同时确保代码符合以下列出的 代码实现指南。
- 优先考虑代码的易读性和简洁性，而不是性能。
- 完全实现所有请求的功能。
- 不要留下任何待办事项、占位符或缺失的部分。
- 确保代码完整！彻底验证最终结果。
- 简洁明了，尽量减少其他描述。
- 如果你认为可能没有正确答案，请明确说明。
- 如果你不知道答案，请直接说明，而不是猜测。
- **注意：尽量使用已经存在的目录，而不是自建目录**
- 你需要严格按照 cursorrules 中的内容来生成代码，不要遗漏任何内容
# 编码环境
用户询问以下编程语言相关的问题：
Java
Spring&SpringBoot&SpringSecurity
MyBatis&MybatisPlus
RocketMq
Nacos
Maven
SpringSecurity
# 代码实现指南
## 依赖处理
- 你所有使用到的依赖必须在根目录的 Pom 文件中做 Dependency Management 版本管理
- 对于通用的依赖可以直接放到根目录的 Pom 文件中，如 lombok
## 监控上报能力
- 你需要为项目中所有使用到的外部插件增加监控上报能力，如：线程池，Redis、MySQL 等。你可以使用 Spring actuator 提供的能力对外提供 Prometheus 格式的上报信息
## 数据库SQL
你需要根据用户的输入来推断可能使用到的表的结构，并按照如下的格式生成。
- 其中 create_time、update_time、create_user、update_user 是必须拥有的字段。
ext和is_deleted可以根据用户的需求来选择添加
- 对于唯一索引，其需要同一个前缀为 ux_，如：ux_business_key_type；对于非唯一索引，需要同一个前缀为 idx_，如：idx_business_key_type
```CREATE TABLE `audit_log` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '账户日志ID',
`business_key` varchar(100) NOT NULL DEFAULT '' COMMENT '业务实体ID或索引,如账号名',
`business_type` smallint(6) unsigned NOT NULL DEFAULT '0' COMMENT '10000-账号,20000-邮箱,30000-ADKeeper,40000-远程账号',
`operate_desc` varchar(500) NOT NULL DEFAULT '' COMMENT '操作描述',
`version` int(11) NOT NULL DEFAULT '0' COMMENT '版本号',
`ext` json DEFAULT NULL COMMENT '扩展属性',
`is_deleted` tinyint(3) unsigned NOT NULL DEFAULT '0' COMMENT '是否删除0为未删除，1为删除',
`create_time` int(11) NOT NULL DEFAULT '0' COMMENT '创建时间',
`update_time` int(11) NOT NULL DEFAULT '0' COMMENT '更新时间',
`create_user` varchar(32) NOT NULL DEFAULT '' COMMENT '创建人',
`update_user` varchar(32) NOT NULL DEFAULT '' COMMENT '更新人',
PRIMARY KEY (`id`),
KEY `idx_business_key_type` (`business_key`,`operate_type`)
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8 COMMENT='账户审计表'
```#编写代码时遵循以下规则：
- 你不能直接在根目录上创建 src 文件夹，而是要创建一个当前项目的子模块来完成代码生成，模块的名字默认为 当前项目名-api
- 项目使用 DDD 的方式来实现代码，你需要注意如下几点：
  - 使用充血模式和工厂模式的方式来完成项目代码的实现
  - 领域层和仓库层的入参都要使用 DO、仓库层的实体对象需要添加 PO 的后缀
  - Application或者Service层的输出必须的 DTO，接口层的返回可以是 DTO 也可以自己定义 VO
  - 每一层对应的对象都需要添加对应的后缀，并且后缀要全大写。如仓库层的实体 UserPO，领域层领域 UserDO，应用层的DTO UserDTO
  - 项目的类之间的转换需要使用 MapStruct 来完成
  - 所有的接口都按照 RestFul 的风格定义，并且你需要区分接口的使用场景，如：前端使用、OpenApi、小程序端使用。
  - 如果你无法通过用户的上下文知道需要你生成的接口的使用场景，你可以再次询问用户
  - 前端统一前缀使用 /api/fe/v1/xxxxx，OpenApi 使用 /api/open/v1/xxxx，小程序使用 /mini-program/v1/xxxx并且三个入口的文件需要区分不同的文件夹
  - 所有的接口返回需要返回 BaseResp 对象，BaseResp 的定义如下：
  @Data
  public class BaseResp<T> {
      private String code;
      private String message;
      private T data;
  }
  - 对于应用层，需要注意如下几点：
     - 函数的输入和输出都是 DTO
  - 对于远程调用层，需要注意如下几点：
     - 你需要使用 @HttpExchange 的能力来完成远程调用，并且让项目中的第三方配置收口到同一个配置节点下。示例如下：
@HttpExchange
public interface IntentRemoteClient {
    @PostExchange(value = "/api/open/agent/intent")
    BaseResprecognizeIntent(
        @RequestBody IntentRequest request
    );
}
@Data
@ConfigurationProperties(prefix = "api")
public class ApiProperties {
    /**
     * 应用依赖的外部服务的配置, 这些外部服务使用 MiPaaS 认证中心提供的认证
     */
    @Valid
    @NotEmpty
    private Map external;
    /**
     * 外部服务配置
     */
    @Data
    public static class ExternalService {
        /**
         * 服务 API 的基础 URL
         */
        @NotBlank
        @URL
        private String baseUrl;
        /**
         * 对一些配置的覆写
         */
        private ExternalServicePropertiesOverrides overrides;
    }
    /**
     * 认证使用不同的 URL 和 认证凭据的配置
     */
    @Getter
    @AllArgsConstructor
    public static class ExternalServicePropertiesOverrides {
        private String authServiceBaseUrl;
        private ClientCredential clientCredential;
    }
    @Getter
    @AllArgsConstructor
    public static class ClientCredential {
        private String appId;
        private String appSecret;
    }
} 
@Configuration
@EnableConfigurationProperties(ApiProperties.class)
public class RestApiConfig {
    private final Mapservices;
    public RestApiConfig(ApiProperties appProperties) {
        this.services = appProperties.getExternal();
    }
    @Bean
    public IntentRemoteClient intentRemoteClient() {
        // 1. 获取服务对应的配置
        var svc = findServiceConfiguration("intent");
        // 2. 构建 Client
        var httpClient = HttpClient.create()
          .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 5000)
          .wiretap(true)
          .responseTimeout(Duration.ofSeconds(10));
        var client = WebClient.builder()
          .baseUrl(svc.getBaseUrl())
          .codecs(clientCodecConfigurer -> clientCodecConfigurer.defaultCodecs().maxInMemorySize(50 * 1024 * 1024))
          .clientConnector(new ReactorClientHttpConnector(httpClient))
          .filter(new AuthorizationAuthFilter(svc.getOverrides().getClientCredential().getAppId(),
            svc.getOverrides().getClientCredential().getAppSecret(), svc.getBaseUrl()))
          .build();
        var factory = HttpServiceProxyFactory.builderFor(WebClientAdapter.create(client)).build();
        return factory.createClient(IntentRemoteClient.class);
    }
    /**
     * 生成服务配置
     *
     * @param name 服务名称
     * @return ExternalService
     */
    @NotNull
    private ApiProperties.ExternalService findServiceConfiguration(@NotNull String name) {
        var svc = services.get(name);
        if (svc == null) {
            throw new IllegalArgumentException("no such service");
        }
        return svc;
    }
} 
  - 对于数据库层，你需要注意如下几点：
     - 你需要为DB增加 自动映射枚举 的能力，即可以在数据库的 PO 中直接使用枚举
     - 你需要使用 自动填充字段 功能来填装 create_time、update_time、create_user、update_user。其中创建人和更新人可以通过 SpringSecurity 获取。
# 历史记录
针对你回答用户问题的答案，你需要将本次回答的内容记录到项目的根路径下的 .cursor-history 文件里，格式如下：
2025-11-11 10:10:10
变更内容如下：
1. 增加用户模块
2. 修改用户管理内容
3. 增加用户内容
涉及文件为：
xxxx.java
xxxx.java
你需要按照倒序的方式记录这个历史纪录