Quick BI“数据门户”在企业数据中台建设中的重要性
企业在数据中台初步建设实现当前，怎么让客户直观感触到数据中台的价值？企业决策者、各部门管理人员、业务经营人员如何通过对立的窗口，疾速看到数据中台提供的数据，并利用这些数据全方位的反对企业倒退？
基于Quick BI构建的企业数据门户，无效的解决了上述问题。
Quick BI“数据门户”是数据中台提供给业务人员应用的门户和窗口，以场景化剖析的形式，为企业各类人员和角色，提供对立的可视化服务。作为真正触达用户的可视化工具，Quick BI“数据门户”在企业数据中台建设中的重要性尤为突出。

为什么要对Quick BI进行优化？
企业数据中台建设实现后，数据中台作为企业对立数据的“供给方”，越来越多的部门和业务人员会成为“需求方”，心愿通过数据中台的数据反对业务。随着“需求方”越来越多，并发要求越来越高，作为对立入口的Quick BI数据门户的压力随之越来越大。因而，随着数据中台在企业内推广和应用的逐渐深刻，须要对Quick BI进行全面优化，以满足一直增长的业务须要。

本文旨在阐明的问题本篇文章基于理论客户案例中Quick BI性能优化的实际摸索，总结提出数据中台建设中的测试方法和性能优化解决方案，抛砖引玉，供其余相似我的项目参考。

典型的数据中台技术架构

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

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

数据服务层，次要分API接口和数据库服务两种形式，个别一般查问应用RDS，多维分析应用ADB，搜寻服务应用ElasticSearch，在线接口应用OneService服务。

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

Quick BI压测办法

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

两个卡点：
1）压测，保障上线内容无性能问题以及隐患
2）新的报表上线时，须要对新上线报表进行简略压测，防止繁多报表导致整个零碎性能呈现瓶颈。

一个检查点：
当客户直观应用感触数据中台门户报表显示过慢时，对系统整体压测，查看性能瓶颈点进行优化。
从而保障数据中台门户满足客户日常报表可视化性能需求。

2、压测策略

1）压测环境
Quick BI数据中台门户通常在客户现场只有正式环境，Quick BI门户页面压测接口全为查问类申请，压测执行不会对线上数据造成净化。当然为了防止影响线上用户，会在用户低峰期如凌晨节点执行压测。大部分我的项目数据门户环境如下：

2）压测施行

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


（1）获取客户需要，如客户需要的可能是要反对100个并发，返回工夫不超过3s、日常峰值用户多少PV等。
（2）依据客户需要联合线上PV访问量预估，计算出教训qps和极限qps。
（3）后期筹备，须要跟客户沟通压测工夫点以及压测计划，同时压测期间协调产品方跟进，察看产品在压测时是否触发异样。
（4）压测工具筹备
（5）压测数据筹备
QuickBI门户波及多个页面，一个页面包含多个接口申请，如果通过手工抓接口录API入参的形式工作量极大，而且接口入参数据时效不高、容易出错。因而须要一种实时页面录制申请的形式实现压测数据疾速筹备。

3、压测形式
通常数据中台Quick BI门户的性能瓶颈是在提供数据服务的数据库，因而在进行压测时，咱们次要通过辨别不同数据源类型的报表页面，进行压测，如下表所示:
下表所示:

（1）摸高测试
以最初始的qps开始施加压力，察看零碎共性指标和业务指标，稳固没问题后就往上调高qps并发数，顺次循环，最初达到目标qps甚至超过指标qps，稳固一段时间，记录指标qps下的零碎各项要害指标及业务指标；
（2）恒定压力测试
个别在小于指标qps稳固压力，继续试压至多2min，察看零碎体现，没问题后，调整到指标qps，继续施压2min或者更长，察看零碎体现，记录零碎各项要害指标及业务成功率。
（3）混合压测
指的是多场景同时压测，这种状况往往须要充沛评估好多个场景总的流量对模块甚至产品的影响。
各模块混合压测时，须要评估好各自qps对模块及对上游模块可能造成的影响。

某客户Quick BI性能优化实际

1、Quick BI数据门户压测与调优
在理论客户案例中，为了从根本上解决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即可满足以后客户的应用需要，在理论进行压测是，针对数据门户场景别离进行压测，压测形式如下：

2、预先监控
在扩容和调优实现后，咱们还须要对系统的应用状况进行监控，监控指标如下：

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

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

（2）工作工夫CPU应用均匀40%左右
业务人员在日间应用期间，零碎以后配置在实践上能够反对100用户并发（20qps）的应用，而且客户侧在短期内会进行数据中台门户零碎推广，因而保留以后系统配置，应答后续推广的用户涌入。

Quick BI性能优化倡议

1、Quick BI开发标准
总结上述性能测试和性能优化的后果，开发人员在应用Quick BI进行可视化开发的过程中，应遵循肯定的开发标准，以保障在后期就躲避一些性能危险，晋升整体平台的性能。

自定义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的工夫，否则相应的页面查问很可能无奈满足客户对相应工夫的要求。

数据集表关联
Quick BI在数据集治理页面，反对通过数据表的关联建设数据集

此处也比拟可能产生性能问题。开发过程中需循序以下标准：
（1） 应尽可能减少应用数据表关联的性能，如果可能在Dataphin等数据加工工具提前将关联加工好，则要求此关联过程前置到计算层。
（2） 如后面的1）条无奈满足，则须要尽可能的应用雷同数据源的数据进行关联。
（3） 如果后面1）2）都无奈满足，应尽量应用RDS或ADB数据库中的数据集进行关联。尽量避免应用ODPS的数据源进行关联拜访。
（4） 尽量避免两个表全关联，或者笛卡尔积的形式进行关联，这样可能造成数据集数据量极大收缩，产生性能问题。
（5） 可通过简略的性能测试掂量在数据集中进行数据表关联操作是否可行，在数据集中进行关联，页面刷新预览数据时，返回后果的工夫倡议不要超过1s的工夫，否则相应的页面查问很可能无奈满足客户对相应工夫的要求。

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

Quick BI的3.6.1版本当前反对对ODPS和ADB数据源的数据集进行缓存配置，技术上会将开启了缓存的数据集数据缓存到Quick BI装置部署时配置的Redis下面，以加重对起源数据库的频繁拜访，减速查问性能。应用该性能，须要留神：
（1） Redis数据缓存按小时进行更新，因而开启了缓存的数据集数据不会实时与数据源进行同步，如源数据发生变化，查问后果不会实时响应，只会依据Redis的更新才会辨认到最新的数据变动。
（2） Redis的空间无限（具体示装置部署时的配置而定），因而也不倡议所有的数据集都凋谢该缓存性能，而应抉择并发查问度较高，性能较差的数据集，有重点的凋谢该性能。

2、 AnalyticDB for MySQL表设计规范

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

用户在设计表的时候，须要重点关注以下四点：
散布键（一级分区键）
散布键（也成为一级分区键）依据散布键的Hash值，将表数据打散到各个数据分片。
所以，在抉择散布键时，肯定要尽量确保数据分布平均，防止数据歪斜。这是重中之重！
同时，尽量抉择多表join时的关联键，防止数据shuffle。
针对一些数据量少且很少更新的码表，能够抉择创立为“维度表”，来防止数据shuffle，晋升性能。

分区键（二级分区键）
再每一个一级分区下，再依据 List Value，将数据调配多个分块。

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

主键（Primary Key）
通过主键进行记录的唯一性判断，且散布键和分区键必须蕴含在主键中。

为了确保主键的性能，通常要抉择“数值型”的列作为主键，并严格控制主键的个数，通常管制在4个列以内。

汇集列（Clustered Key）
通过将雷同的数据物理排序在一起，能够达到升高IO并晋升查问性能的成果。通常汇集列抉择那些有肯定反复数据量、且经常作为查问过滤条件的列，例如商品类型、人员部门等。

3、AnalyticDB for MySQL开发标准
AnalyticDB for MySQL领有弱小的自研存储、MPP计算引擎和先进的优化器，通常客户无需过于关注SQL是否标准。然而，以下的根本准则能够充分利用ADB的特点，已达到最佳的性能：

尽量避免列上嵌套函数
如下，如果在列上嵌套函数，会导致该列上的索引生效，从而须要扫描全表数据，减少系统资源耗费的同时还会影响查问的性能。

因而，咱们在编写SQL时要尽量避免在列上嵌套函数，下面的SQL能够做如下批改：

尽量确保join时基于散布键：
如果两表Join是不是基于散布键，则须要进行大量的数据shuffle，如下：
例如：
表 customer 的散布键是 UserId
表 order 的散布键是 OrderId
SQL:
Select * from customer c join order o on c.userId=o.userID

在SQL执行时就须要对order表shuffle数据，这样会减少零碎的资源耗费，包含内存、网络、CPU等，查问响应工夫也会减少

因而，咱们须要批改 Order 表的散布键为 UserID，这样下面的SQL在执行时会在单个ECU本地内实现计算，从而晋升性能，如下：

尽量多的增加过滤条件
默认状况下，客户无需关怀哪些列须要创立索引，ADB会在所有的列上创立索引。然而如果过滤条件的过滤性不佳，甚至是缺失，则无奈施展ADB弱小的自研索引的性能，须要进行全量数据的扫描。因而，咱们须要依据业务和数据的个性，尽可能多的增加过滤条件。

原文链接
本文为阿里云原创内容，未经容许不得转载。