导读

通过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，可以按需使用自动合计，减少查询的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 维度归因：横向看维度，“问题在哪个群体”

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

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

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

| 算法 | 算法描述

|

适用指标

| |

波动贡献

|

概述：因子波动量占整体波动量的占比

波动量 = 维度项本期 - 维度项基期

维度项绝对差值 = abs(维度项本期 - 维度项基期)

波动影响贡献度 = 维度项差值 / 整体基期

可加型指标，如分发量

|

可加型指标，如分发量

| |

超均贡献

|

概述：超均贡献度是为解决原子指标单看变化的绝对量级（偏移量、偏移量占比）和变化的相对快慢（波动率）导致的不准确问题：

• 用变化的绝对量级进行根因定位：会导致量级较大的维度因子长期排在前列，可能无法识别非头部因子带来的影响。

• 用变化的相对快慢进行根因定位：会导致量级较小但波动剧烈的因子排在前列，忽略了量级影响。

因子波动与指标值（均值）波动差异的相对大小，超均贡献度越大，说明因子的变化偏离均值变化越大，越有可能是根因

超均贡献值 = (维度项波动率-总波动率）*本期值

超均贡献度 = 超均贡献值/总的超均贡献值

差值 = 指标本期值 - 指标基期值

波动率 = 指标差值 / 上期值

|

可加型指标，如分发量

| |

综合贡献

|

概述：由于比例型指标（分子/分母）不可加和性（各商品类目的客单价加和不等于总的客单价），所以波动贡献和超均贡献无法准确评估因子的影响，故使用综合贡献

可以发现，均值指标本身的变化可以拆解为三部分：

组间贡献值：衡量结构变化（因子分母占比变化）对指标变化的影响。

组内贡献值：衡量因子量级变化对指标变化的影响。

交叉贡献值：衡量组间和组内交叉效应对指标带来的变化影响，属于高阶项，一般可忽略

|

比例型指标，如人均分发量

|

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

比如，原始数据：日期、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平台从工具集合升级为智能决策伙伴，让每个用户都能拥有自主进化的数据大脑，持续释放数据价值。