导读

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

名词解释

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

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

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

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

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

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

01 背景与问题

1.1 背景

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

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

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

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

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

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

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

• 容易出现服务不稳定。

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

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

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

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

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

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

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

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

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

2.1 建模模型

2.1.1 思路

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

2.1.1.1 举例

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

2.1.1.2 思路分析过程

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

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

消除：

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

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

2.1.2 建模核心思想

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

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

2.1.3 整体模型架构

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

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

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

2.2 计算引擎

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

2.2.1 从架构&处理流程上

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

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

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

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

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

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

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

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

2.2.2 ETLServer到数仓融合引擎转变

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

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

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

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

2.3.1 挑战1解决方案

1. 列式存储&读取：

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

2. 复杂嵌套字段打平：

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

2.3.2 挑战2解决方案

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

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

Merge Into基本语法

回溯原理流程如下图

1. 关联匹配：

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

2. 条件判断：

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

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

3. 原子性操作：

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

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

2.3.3 挑战3解决方案

2.3.3.1 重排序、高效压缩

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

（1）压缩编码

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

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

（2） 压缩格式

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

（3） Page Size

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 阶段一到阶段二

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

3.2 阶段二到阶段三

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

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

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

3.2.1 数据集建模合理度挑战

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

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

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

3.2.2 解决方案

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

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

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

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

3.3 新模式带来的改变

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

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

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

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

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

04 总结与展望

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

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

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

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

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

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

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

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

导读

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

01 背景

1.1 图灵3.0生态概述

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

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

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

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

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

△图灵3.0生态产品

1.2 问题

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

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

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

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

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

1.3 Hive和Iceberg对比

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

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

1.4 Iceberg的组织结构

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

• metadata元数据层

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

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

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

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

• data数据层

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

△Iceberg表结构

△Iceberg文件组织结构

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

02 Iceberg能力建设与应用

2.1 图灵生态能力适配

2.1.1 统一元数据服务

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

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

△统一元数据服务架构

2.1.2 打通Iceberg和Hive联邦查询

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

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

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

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

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

2.2 存量Hive低成本迁移Iceberg

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

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

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

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

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

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

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

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

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

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

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

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

△Hive迁移Iceberg整体实现流程

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

2.3.1 图灵实时数仓应用

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

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

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

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

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

△图灵实时湖仓架构演变

2.3.2 行级更新策略

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

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

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

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

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

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

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

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

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

△ Hive 和 Iceberg 回溯效率对比

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

03 未来规划

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

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

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

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

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

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

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

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

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

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

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

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

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

01 项目背景

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

02 前端项目面临的问题

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

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

• UI组件库：ElementUI 2.15.13

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

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

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

2.1 代码质量

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

2.2 基础建设

1. 代码臃肿，维护困难

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

• 巨型文件导致：

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

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

2. 技术栈陈旧

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

2.3 构建和部署

测试环境

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

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

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

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

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

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

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

生产环境

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

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

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

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

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

2.4 优质组件

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

1. 组件与模块概念混淆

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

2. 基础建设缺失

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

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

03 全面重构拆分

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

3.1 接入工程化

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

工程化改造步骤

1. 清理冗余配置

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

2. 统一基础配置文件

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

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

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

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

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

3. 接入代码规范工具

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

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

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

4. 优化开发体验

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

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

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

配置参考：

• VSCode统一配置

  www.yuque.com/shuoshubao/…

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

历史代码修复策略

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

具体执行步骤：

1. 自动格式化（Prettier）

2. ESLint自动修复

3. 分析剩余问题

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

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

4. 回归测试

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

效果验证

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

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

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

3.2 升级基建

3.2.1 源码优化与依赖治理

问题现状：

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

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

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

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

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

优化措施：

1. 资源优化

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

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

2. 依赖治理

• 移除22个无用依赖

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

3. 技术栈升级

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

3.2.2 构建相关

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

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

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

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

3.2.3 部署相关

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

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

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

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

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

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

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

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

3.2.4 接口调试

传统开发模式的痛点

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

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

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

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

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

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

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

1. 规范先行：

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

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

2. Mock数据要求：

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

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

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

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

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

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

3.3 构建体积优化

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

3.3.1 element-ui

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

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

3.3.2 引入externals功能

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

vite-plugin-externals

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

vite-plugin-assets

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

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

3.3.3 大包的特殊处理

1. monaco-editor

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

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

2. xlsx, fabric 等

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

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

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

3.4 建设组件库

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

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

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

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

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

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

文档分为以下几大模块

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

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

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

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

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

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

3.4.1 通用组件

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

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

3.4.2 element-ui 文档集成

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

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

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

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

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

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

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

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

3.4.3 通用工具库

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

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

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

04 总结与展望

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