大数据一直被定义为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使用小窍门,收获大惊喜,记得持续关注亿信华辰。当然也可以留言给小亿,说出你想要了解的其他应用小知识呢。
领取专属 10元无门槛券
私享最新 技术干货