导读

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

名词解释

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

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

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

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

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

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

01 背景与问题

1.1 背景

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

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

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

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

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

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

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

• 容易出现服务不稳定。

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

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

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

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

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

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

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

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

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

2.1 建模模型

2.1.1 思路

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

2.1.1.1 举例

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

2.1.1.2 思路分析过程

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

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

消除：

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

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

2.1.2 建模核心思想

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

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

2.1.3 整体模型架构

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

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

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

2.2 计算引擎

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

2.2.1 从架构&处理流程上

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

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

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

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

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

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

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

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

2.2.2 ETLServer到数仓融合引擎转变

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

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

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

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

2.3.1 挑战1解决方案

1. 列式存储&读取：

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

2. 复杂嵌套字段打平：

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

2.3.2 挑战2解决方案

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

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

Merge Into基本语法

回溯原理流程如下图

1. 关联匹配：

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

2. 条件判断：

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

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

3. 原子性操作：

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

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

2.3.3 挑战3解决方案

2.3.3.1 重排序、高效压缩

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

（1）压缩编码

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

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

（2） 压缩格式

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

（3） Page Size

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 阶段一到阶段二

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

3.2 阶段二到阶段三

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

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

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

3.2.1 数据集建模合理度挑战

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

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

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

3.2.2 解决方案

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

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

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

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

3.3 新模式带来的改变

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

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

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

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

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

04 总结与展望

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

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

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

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

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

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

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

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