让数据中台“飞“起来— Quick BI性能优化解决方案及实践

关注

原创 2025-07-12 11:20:31 1.2k 阅读 AI 写同款· GEO 优化 ›

构建应用内智能：衡石嵌入式BI如何打造“指标中台”驱动的场景化分析摘要：衡石科技通过创新的指标中台架构(MetricPlatform)解决了嵌入式BI分析面临的技术挑战。该架构包含三大核心技术：统一语义层建模实现业务友好的逻辑模型；高性能计算引擎支持预计算与动态查询；指标目录与治理确保数据一致性和安全性。通过分层解耦设计，提供了JSSDK、API网关等嵌入式集成方案，实现亚秒级响应、无缝主题适配和上下文感知。典型应用场景显示，该方案能根治指标口径碎片化问题，降低80%开发成本，同时保障企业级数据安全治理。指标中台成为嵌入式智能分析的"核心引擎"，为企业阅读详情

转载：羚羊

目前国内头部婴幼配粉企业就是基于dataphine+ADB+quickBI构建的数据中台和数据服务。

但是由于长期中台人员没有建立运维意识、优化意识，专业度也较低，导致业务及商业分析部门产品体验很差，经常影响到业务使用。

所以后来受中台邀请针对该企业开展了性能定位及优化。

1 引言

Quick BI“数据门户”在企业数据中台建设中的重要性

企业在数据中台初步建设完成以后，怎样让客户直观感受到数据中台的价值？企业决策者、各部门管理人员、业务运营人员如何通过统一的窗口，快速看到数据中台提供的数据，并利用这些数据全方位的支持企业发展？

基于Quick BI构建的企业数据门户，有效的解决了上述问题。Quick BI“数据门户”是数据中台提供给业务人员使用的门户和窗口，以场景化分析的方式，为企业各类人员和角色，提供统一的可视化服务。作为真正触达用户的可视化工具，Quick BI“数据门户”在企业数据中台建设中的重要性尤为突出。

为什么要对Quick BI进行优化？

企业数据中台建设完成后，数据中台作为企业统一数据的“供给方”，越来越多的部门和业务人员会成为“需求方”，希望通过数据中台的数据支持业务。随着“需求方”越来越多，并发要求越来越高，作为统一入口的Quick BI数据门户的压力随之越来越大。因此，随着数据中台在企业内推广和使用的逐步深入，需要对Quick BI进行全面优化，以满足不断增长的业务需要。

本文旨在说明的问题

本篇文章基于实际客户案例中Quick BI性能优化的实践探索，总结提出数据中台建设中的测试方法和性能优化解决方案，抛砖引玉，供其他类似项目参考。

2 典型的数据中台技术架构

基于阿里云数据中台整体解决方案，对数据中台技术实现进行选型及设计，典型的数据中台技术架构如下图所示，整个技术架构选型包含五个层次：业务数据源存储技术、数据源接入技术、数据中台数据存储与计算技术、数据服务及数据应用技术。

数据存储计算，数据中台中离线数据存储和计算采用MaxCompute离线计算引擎；实时计算部分采用阿里云StreamCompute流式计算技术实现；数据研发与管理采用Dataphin智能数据构建与管理大数据研发平台。

数据服务层，主要分API接口和数据库服务两种方式，一般普通查询使用RDS，多维分析使用ADB，搜索服务使用ElasticSearch，在线接口使用OneService服务。

数据应用层，使用阿里云智能报表工具Quick BI实现各种定制数据报表分析需求；以及基于阿里云产品技术体系实现客户个性化数据应用需求。其中基于Quick BI产品的数据中台门户如图中橙色部分所示。

3 Quick BI压测方法

3.1 压测目标

Quick BI数据中台门户压测目标主要围绕着两类发布变更和用户体验反馈，提前做好：性能卡点、性能调优工作，满足日常客户报表的极致体验、以及性能特殊诉求。

两个卡点：

1. 是项目建设初期场景批量上线，对上线场景进行压测，保障上线内容无性能问题以及隐患

2. 新的报表上线时，需要对新上线报表进行简单压测，避免单一报表导致整个系统性能出现瓶颈。

一个检查点：

1. 当客户直观使用感受数据中台门户报表显示过慢时，对系统整体压测，检查性能瓶颈点进行优化。

从而保障数据中台门户满足客户日常报表可视化性能需求。

3.2 压测策略

3.2.1 压测环境

Quick BI数据中台门户通常在客户现场只有正式环境，Quick BI门户页面压测接口全为查询类请求，压测执行不会对线上数据造成污染。当然为了避免影响线上用户，会在用户低峰期如凌晨节点执行压测。大部分项目数据门户环境如下：

3.2.2 压测实施

具体实施压测时，主要流程如下：

目标指标：QPS（每秒查询率，Queries Per Second）和PQS（每秒请求数，probably refers to "Queries Per Second" or "Requests Per Second"）都是衡量系统处理能力的重要指标。QPS 指的是服务器每秒能够处理的查询次数，而PQS 通常也指每秒处理的请求数量，可以理解为QPS 的另一种说法

1. 获取客户需求，如客户需求的可能是要支持100个并发，返回时间不超过3s、日常峰值用户多少PV等。

2. 根据客户需求结合线上PV访问量预估，计算出经验qps和极限qps。

3. 前期准备，需要跟客户沟通压测时间点以及压测方案，同时压测期间协调产品方跟进，观察产品在压测时是否触发异常。

4、压测工具准备

5、压测数据准备

QuickBI门户涉及多个页面，一个页面包括多个接口请求，如果通过手工抓接口录API入参的方式工作量极大，而且接口入参数据时效不高、容易出错。因此需要一种实时页面录制请求的方式实现压测数据快速准备。

3.2.3 压测方式

通常数据中台Quick BI门户的性能瓶颈是在提供数据服务的数据库，因此在进行压测时，我们主要通过区分不同数据源类型的报表页面，进行压测。

1、摸高测试

以最初始的qps开始施加压力，观察系统个性指标和业务指标，稳定没问题后就往上调高qps并发数，依次循环，最后达到目标qps甚至超过目标qps，稳定一段时间，记录目标qps下的系统各项关键指标及业务指标；

2、恒定压力测试

一般在小于目标qps稳定压力，持续试压至少2min，观察系统表现，没问题后，调整到目标qps，持续施压2min或者更长，观察系统表现，记录系统各项关键指标及业务成功率。

3、混合压测

指的是多场景同时压测，这种情况往往需要充分评估好多个场景总的流量对模块甚至产品的影响。

各模块混合压测时，需要评估好各自qps对模块及对下游模块可能造成的影响。

4 某客户Quick BI性能优化实践

4.1 数据门户压测与调优

在实际客户案例中，为了从根本上解决Quick BI数据门户性能问题，采用如下方案进行整体的优化与压测验证：

验证：

首先优化分为任务优化和产品优化：

一．任务优化

1. 第一轮压测：首先对Quick BI进行一轮压测，记录当前系统性能数据。

2. 查找优化对象：ADB产品根据top10耗时SQL，针对性的探查性能瓶颈，Quick BI产品侧通过查找元仓，找到自定义SQL数据集，并筛选非传参且耗时高的数据集。

3. 优化：

ADB以优化表DDL为主和规格评估为主，通过在ADB库中查询INFORMATION_SCHEMA.PARTITIONS，获得各表组分区如下：

为了使数据分布均匀，避免长尾问题，根据产品建议，通过重命名原表->创建新表->数据回写的方式，将ADB中非128分区的表进行DDL改造，分区调整为128分区。

Quick BI通过将自定义SQL数据集固化成结果表的方式，降低使用此类数据集时每次查询复杂SQL的性能消耗。通过元仓查询到的此类数据集如下，其中有两个数据集不是传参类型自定义SQL数据集，并且SQL非常复杂，对ADB系统性能影响非常大，针对这两个数据集进行优化调整，将处理逻辑下沉在Dataphin的ads层，并将结果表同步至ADB，供Quick BI的报表直接访问。

4. 第二轮压测：对Quick BI各场景页面进行第二轮压测，验证优化效果。

二．产品优化：

1. Quick BI产品：后续升级为3.6.1版本后，支持数据缓存功能，可以将各场景默认展示页的数据进行缓存，降低对后端数据库的性能消耗。

2. ADB：优化完成后，可视情况进行限流，从而在资源紧张情况下保障绝大部分用户的正常使用。后续从2.0版本升级为3.0版本，写入效率预计提升50%，读取效率预计提升40%，并且ADB 3.0版本支持存储计算分离。

另外在Quick BI独立部署正式上线期间，GTS侧进行现场重保，各相关产品侧在远程进行重保，进而保障客户数据门户环境平稳运行。

与此同时，因ADB资源不足，对ADB规格进行评估，联合商务侧临时使用代金券，将ADB资源由进行临时扩容，优先保障客户上线，根据上线后实际客户使用情况决定是否保持扩容规格。

系统调优的目的在于满足客户对数据中台数据门户性能的需求，那么对数据门户的压测必不可少，经过分析，20个qps即可满足当前客户的使用需求，在实际进行压测是，针对数据门户场景分别进行压测，压测方式如下：

4.2 事后监控

在扩容和调优完成后，我们还需要对系统的使用情况进行监控，监控指标如下：

通过监控指标项发现，扩容和优化后：

1. 每日1：30~8：30左右，数据中台数据写入ADB库，CPU等资源会占用较高，使用率可以达到90%+，但因是非业务使用时间，所以对业务使用无影响。

2. 工作时间CPU使用平均40%左右

业务人员在日间使用期间，系统当前配置在理论上可以支持100用户并发（20qps）的使用，而且客户侧在短期内会进行数据中台门户系统推广，因此保留当前系统配置，应对后续推广的用户涌入。

5 Quick BI性能优化建议

5.1 Quick BI开发规范

总结上述性能测试和性能优化的结果，开发人员在使用Quick BI进行可视化开发的过程中，应遵循一定的开发规范，以保证在前期就规避一些性能风险，提升整体平台的性能。

5.1.1 自定义SQL建模

使用Quick BI进行数据可视化开发，其中的大部分SQL都是Quick BI的SQL引擎自动生成的，此处不需要开发人员关注。而在Quick BI专业版中支持的“即席分析SQL”功能（如上图）中，允许开发人员通过自定义的SQL创建数据集，此处需要开发人员遵循以下原则进行SQL开发：

1）只有必须使用即席查询SQL中的“参数”传递功能，以满足特殊场景需要的时候，才使用“即席分析SQL”的方式创建数据集。其他场景下，都要求将此数据查询的过程前置到数据计算过程里面，即使用Dataphin等工具将所需加工的数据提前计算好，形成专门的数据表，Quick BI直接使用该数据结果，而不是在Quick BI中，创建数据集的时候进行比较复杂的SQL数据加工。

2）自定义SQL，不建议使用超过3个以上的union 类型的操作。不建议使用超过5个字段以上的group by 操作。不满足的情况，均建议采用上面1）中的方式，前置到数据计算环境，将数据处理好，再在Quick BI中使用数据。

3）SQL的编写规范，需要严格遵循《数据中台模型设计&数据开发规范》的要求编写。

4）可通过简单的性能测试衡量在即席分析SQL中编写SQL脚本是否可行，在该过程编写的SQL，页面执行后，返回结果的时间建议不要超过1s的时间，否则相应的页面查询很可能无法满足客户对相应时间的要求。

5.1.2 数据集表关联

Quick BI在数据集管理页面，支持通过数据表的关联建立数据集

此处也比较可能产生性能问题。开发过程中需循序以下规范：

1）应尽可能减少使用数据表关联的功能，如果能够在Dataphin等数据加工工具提前将关联加工好，则要求此关联过程前置到计算层。

2）如前面的1）条无法满足，则需要尽可能的使用相同数据源的数据进行关联。

3）如果前面1）2）都无法满足，应尽量使用RDS或ADB数据库中的数据集进行关联。尽量避免使用ODPS的数据源进行关联访问。

4）尽量避免两个表全关联，或者笛卡尔积的方式进行关联，这样可能造成数据集数据量极大膨胀，产生性能问题。

5）可通过简单的性能测试衡量在数据集中进行数据表关联操作是否可行，在数据集中进行关联，页面刷新预览数据时，返回结果的时间建议不要超过1s的时间，否则相应的页面查询很可能无法满足客户对相应时间的要求。

5.1.3 数据集缓存

Quick BI在数据集页面，支持对数据集进行缓存配置，如下图：

Quick BI的3.6.1版本以后支持对ODPS和ADB数据源的数据集进行缓存配置，技术上会将开启了缓存的数据集数据缓存到Quick BI安装部署时配置的Redis上面，以减轻对来源数据库的频繁访问，加速查询性能。使用该功能，需要注意：

1） Redis数据缓存按小时进行更新，因此开启了缓存的数据集数据不会实时与数据源进行同步，如源数据发生变化，查询结果不会实时响应，只会根据Redis的更新才会识别到最新的数据变化。

2） Redis的空间有限（具体示安装部署时的配置而定），因此也不建议所有的数据集都开放该缓存功能，而应选择并发查询度较高，性能较差的数据集，有重点的开放该功能。

5.2 AnalyticDB for MySQL表设计规范

5.2.1 ADB数据模型（原ADS)

ADB是MPP分布式架构，其数据模型如下：

MPP（Massively Parallel Processing，大规模并行处理）分布式架构是一种高性能计算架构，专为处理海量数据分析而设计。其核心思想是将大型任务拆分成多个小任务，同时在多个独立的计算节点上并行执行，最终汇总结果，从而极大提升数据处理速度。

以下是MPP架构的核心要点解析：

核心特征	说明	优势	典型代表
无共享架构 (Shared Nothing)	每个节点拥有独立的CPU、内存和存储资源，节点间不共享磁盘或内存，仅通过网络通信协作	消除资源争用，扩展性强，故障隔离性好	Greenplum, Teradata, Amazon Redshift
任务并行化	查询被分解成多个子任务，分配到不同节点并行执行	线性提升处理速度（理想情况下增加节点即可成倍缩短查询时间）	Vertica, Snowflake (存储层)
数据分片 (Data Partitioning/Sharding)	海量数据被水平分割成小块（分片），分布存储在不同节点上	数据本地化处理，减少网络传输，最大化并行效率	Apache HAWQ, Yellowbrick
分布式查询优化器	智能规划查询执行路径，决定数据移动和计算任务分配	最小化数据移动，优化资源利用	IBM Netezza, Google BigQuery
专用高速互联网络	节点间通过高速网络（如InfiniBand）连接	保障节点间高效通信，减少数据传输瓶颈	多数MPP数据库专用硬件集群

核心工作原理

数据分布：数据按特定策略（如哈希、范围）分散存储在集群的各个节点上。
查询分解：用户提交查询后，协调节点（Leader Node）将其拆分为多个子任务。
并行执行：子任务被发送到存储相关数据分片的节点上同时执行。
结果汇总：各节点将中间结果返回给协调节点进行聚合，最终返回给用户。

与Hadoop的区别

特性	MPP	Hadoop(MapReduce)
数据处理类型	结构化数据、SQL查询	非结构化/半结构化数据、批处理
延迟	低延迟（秒级）	高延迟（分钟级+）
数据存储	通常需预定义Schema	Schema-on-Read（读时解析）
容错	节点故障可能导致查询失败	通过数据冗余实现高容错

典型应用场景

大型数据仓库：TB/PB级结构化数据分析
商业智能(BI)：复杂报表、即席查询(Ad-hoc Query)
实时分析：需要秒级响应的交互式分析
ETL处理：高效的数据清洗和转换

用户在设计表的时候，需要重点关注以下四点：

ADS设计了一级分区列的概念，一级分区列的首要选择是避免数据倾斜。

其次要尽量选择会参与谓词运算的列。

同时为了减少DBA的负担，ADS又设计了二级分区的概念，二级分区列尽量按照时间去选择，二级分区列尽量也参与到谓词运算同样可以提高查询效率。

5.2.2 分布键（一级分区键）

分布键（也成为一级分区键）根据分布键的Hash值，将表数据打散到各个数据分片。

所以，在选择分布键时，一定要尽量确保数据分布均匀，避免数据倾斜。这是重中之重！

同时，尽量选择多表join时的关联键，避免数据shuffle。

针对一些数据量少且很少更新的码表，可以选择创建为“维度表”，来避免数据shuffle，提升性能。

5.2.3 分区键（二级分区键）

再每一个一级分区下，再根据 List Value，将数据分配多个分块。

分区键通常基于“日期”，并根据二级分区数的定义，按照分区键值的大小进行排序，保留最大的N个二级分区。这样就赋予数据“生命周期”的特性。

推荐尽量选择和时间有关的列来作为二级分区列，因为二级分区列有一个最大的特点是会按照数量滚动删除。和上面的例子相同，我们修改为增加二级分区列,增加ds这个列，按照每天的交易数据把数据归并到某个二级分区里。

create table orders(
 order_id long,
 store_id long,
 order_total float,
 order_time timestamp,
 order_comment varchar,
 ...
 )
 partition by hash key(store_id)
 partition number(256)
 SUBPARTITION BY LIST KEY (ds bigint)
 SUBPARTITION OPTIONS (available_partition_num = 90);

这里的二级分区列我们使用交易日期ds，按照上图所示available_partition_num = 90，也就是说我们会保存90天的历史数据，当第91天的记录进入到ADS后，ADS会自动把91天前的记录删除，这样的设计可以极大的简化DBA的日常运维工作

常见的分区设计错误

分区数目过少，小于LocalNode的数目，如上图所示，如果分区数目过少，可能会出现有的LocalNode没有分区需要处理。假设分区数目为8个，而LocalNode的个数为16个，那必然会出现有8个LocalNode没有任何数据需要处理，这时候资源会出现浪费现象。
分区数目不是LocalNode的倍数，如上图所示，如果某个表的分区数目是100个，而LocalNode的个数是64个，那么必然会出现有36个LocalNode处理2个分区，而另外28个分区需要处理1个分区。这时候的查询有很可能会出现处理36个分区的LocalNode成为慢节点。
二级分区数目过多，例如有的表每天只有30w的数据，但是需要存储1年的数据，这时候如果每天的记录都作为二级分区会导致查询效率降低。最佳选择是每个月做一个二级分区，这样每个二级分区大概有900w数据，一共有12个二级分区。
避免数据倾斜是分区的最主要目的，在数据均匀分布的情况下尽可能将查询中最常使用的谓词列或者多表Join的时候JOIN的列作为分区列可以极大提高查询效率。