共计 5811 个字符，预计需要花费 15 分钟才能阅读完成。
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 弱小的自研索引的性能，须要进行全量数据的扫描。因而，咱们须要依据业务和数据的个性，尽可能多的增加过滤条件。
原文链接
本文为阿里云原创内容，未经容许不得转载。
