卡死？你的BI速度慢吗？试试这个工具

大数据一直被定义为3W（数量大，速度快，多样性） ，为了支撑数据分析服务的正常运行，BI工具的报表快速处理能力也需要与时俱进。

比如亿信ABI中，同样一个查询需求，为什么别人的计算结果获取时间从1分钟变成3秒钟？可能是你不知道ABI具有性能调优的精髓所在。

今天，为了解决广大BI工程师的调优难题，小亿准备“买一送一”，从SQL个数和过滤条件两个方面来跟大家分享一下，亿信ABI的性能调优小诀窍。

小诀窍之一：并行计算

在数据表格统计分析中，当一张报表中有多个分析报表时，系统需要生成多条SQL语句来完成数据查询结果。SQL数量的增多，势必会影响数据分析的查询效率。为了解决这个问题，亿信ABI优化了“并行计算”的功能。

并行计算就是将多个查询SQL并行执行，可提升多表格的计算效率；这里举几个例子，让大家直观感受一下。

测试场景一：

数据库与产品共用同一台PC机资源，耗时由10次重复计算得到的平均耗时：

PC机配置：双核四线程，8G内存

数据库：mysql5.0

产品：亿信ABI

物理表数据量：48814条记录

测试数据如下所示：

测试场景二：

数据库与产品共用同一台PC机资源，耗时由10次重复计算得到的平均耗时；

PC机配置：双核四线程，8G内存

数据库：mysql5.0

产品：亿信ABI

物理表数据量：100W大数据量

测试数据如下所示：

通过几个测试场景的对比，可以看出，在多表格多分析区的场景下，开启并行计算。最大化的利用系统资源，可以让你的报表计算速度产生质的飞越。那么设置方式是什么呢？

无！需！任何设置，亿信ABI就会自动进行多表格的并行计算。

BUT，如果由于某种原因，需要关闭并行计算，可以这么设置：

在“资源管理器”下的目录：

/root/products/eanalysemgr/conf/setup.conf 下配置属性值

@set_calc_threadmode值为none即可，如果不存在对应目录，可手动自行创建哦。

截图如下所示：

小诀窍之二：优化过滤条件，善用索引

亿信ABI分析表中的过滤条件在报表计算时都会转换成SQL语句中的where条件，在大数据量的情况下，where条件不够优化，会直接导致SQL语句运行效率低下，最直接的表现就是SQL语句执行时没用到索引或者用到的索引不够好。

那什么样的过滤能构成一个质量上乘的where子句？什么样的过滤一定会造成where子句效率的损失？我们在编写BI报表过滤条件时又该注意哪些问题呢？本例以数据库Oracle为例来给大家深入解读一二。

杜绝在指标列上使用函数Oracle使用索引的原则之一是：如果在where条件中的列上使用了函数，就不会使用该列上建立的索引。

举例如下：

优化前：

主题表ESEN_BI的列pid上有索引，原过滤条件写法为：

left(ESEN_BI.pid,1)>='1' and left(ESEN_BI.pid,1)

由于在列上用了left函数并且使用的是不等运算符，因此BI无法直接优化为like操作，只能将left转换为sql中的substr函数，结果就破坏了走索引的可能性；

优化后：

(ESEN_BI.pid like '1%' or ESEN_BI.pid like '2%'or ESEN_BI.pid like '3%')

该sql查询会走索引，在测试环境经过验证，这个过滤所在的分析表计算速度由原来的7分钟直接提速到了14秒。

优化过滤表达式

养成良好的过滤条件编写习惯。在理解业务过滤需求的基础上，尽可能的用简洁实用的表达式来编写。编写过滤条件时，可以使用以下3个小技巧：

能用like不用substr（取子串）

能用and尽量不要用or

尽量不要用 not in、in，有条件的情况下可以用范围过滤来代替（>，

最后再给大家几个与索引相关的小建议，赶紧拿出你的小本本记下来吧：

在索引列上使用函数时不会使用索引，如果一定要使用索引，建议建立函数索引；

索引列中有NULL值时，数据库查询不会走索引；

如果需要排序时，尽量根据已建立索引的列排序；

如果发现过滤条件和排序所需要的列没有索引时，可以申请让数据库工程师整体评估具体优化方法；

切忌自行随意增加索引，过多的索引反而会影响性能。

如果还想要获取更多亿信ABI使用小窍门，收获大惊喜，记得持续关注亿信华辰。当然也可以留言给小亿，说出你想要了解的其他应用小知识呢。