《Cloudera Impala进阶测试》由会员分享，可在线阅读，更多相关《Cloudera Impala进阶测试（12页珍藏版）》请在金锄头文库上搜索。
1、Cloudera Impala进阶测试 v9Cloudera Impala进阶测试1查询性能31.1单表2亿行数据规模的Impala vs Oracle性能对比31.2单表12亿行数据规模Impala性能测试51.312亿行数据规模表连接Impala性能测试82修正测试方案中的错误92.1单表2亿行数据规模的Impala vs vertica性能对比93数据装载124Impala花絮13 查询性能o 单表2亿行数据规模的Impala vs Oracle性能对比 o 单表12亿行数据规模Impala性能测试o 12亿行数据规模表连接Impala性能测试 修正测试方案中的错误o 单表2亿行数据规模
2、的Impala vs vertica性能对比 数据装载 Impala花絮1 查询性能1.1 单表2亿行数据规模的Impala vs Oracle性能对比新搭建的CDH仍然采用了3nodes集群部署，一个namenode，两个datanode，oracle还是在物理服务器上，采用oracle11gR2。以下是本次进阶测试的报告。OracleImpala平台配置Intel(R) Xeon(R) CPU L5420 2.50GHz * 8cores / 9g mem3nodes，for each node：Intel(R) Xeon(R) CPU L5420 2.50GHz * 8cores /24
3、g mem测试素材XXXX明细表F_UNIBA_DXSF_TEST，表记录行：201,148,266，文件大小27.7g表结构主要字段说明：ID（流水号，pk），patID（id），sfmonth（年月），outdept（科室），zje（费用金额），indate（日期）oracle 扫描方式 / impala 表存储文件格式索引扫描PARQUETFILE测试用例1：select * from F_UNIBA_DXSF_TEST t WHERE ID=664024100.1s15s测试用例2：select * from F_UNIBA_DXSF_TEST t WHERE patID=000931
4、0220.3s16.1s测试用例3：select outdept,sum(zje) from F_UNIBA_DXSF_TEST where sfmonth=201307 GROUP BY outdept139.8s3.6s测试用例4：select outdept,sum(zje) from F_UNIBA_DXSF_TEST where sfmonth=201306 and sfdm=a GROUP BY outdept236.7s3.9s测试用例5：select outdept,sum(zje) from F_UNIBA_DXSF_TEST where sfmonth=201308 and
5、 (sfdm=a or sfdm like z%) GROUP BY outdept448.6s4s测试用例6：select outdept,count(distinct patid) from F_UNIBA_DXSF_TEST where brsf=A002 and indate=to_date(20130903,yyyymmdd) GROUP BY outdept90s4.1s测试用例7：select count(*) from f_uniba_dxsf_TEST20.3s1.1s测试说明：1. 2亿行数据在oracle上做表扫描可视为“不可能完成的任务”，查询时间太长太长，没有测试的意
6、义，故进阶测试仅针对索引扫描方式测试小结： 测试结果毫无悬念，对于统计汇总类的查询，Impala采用PARQUETFILE格式存储无疑是目前最高效的。与oracle相比，性能有着几十倍到上百倍的增幅。对于单行查询，oracle借助B-Tree索引能保持较好的性能（主键、唯一索引最适合单行查询了），而Impala也差强人意，毕竟列式存储的数据压缩技术更适合重复值较多的场景（相同的值更有利于数据压缩），对于ID这种流水码，压缩率并不高（压缩率越低，IO越多），这无疑增加了查询开销。（借此吐槽：2亿行记录通过pk 或者 unique index 进行单行查询只要0.x 秒，SuccezBI的元数据应
7、属于OLTP操作型数据，不使用ObjectID这种唯一值进行查询，而用olap思想的通过属性字段来定位元数据的方式真是。还好目前项目的元数据数据量和DML并发都很小，未来如何？BI是否会遇到高并发场景笔者不确定，CI恐怕迟早要遇到的。）1.2 单表12亿行数据规模Impala性能测试测试环境与之前2亿行的测试环境相同Impala on 200 millionImpala on 1billion 200 million平台配置3nodes，for each node：Intel(R) Xeon(R) CPU L5420 2.50GHz * 8cores /24g mem3nodes，for ea
8、ch node：Intel(R) Xeon(R) CPU L5420 2.50GHz * 8cores /24g mem测试素材XXXX明细表F_UNIBA_DXSF_TEST，表结构主要字段说明：ID（流水号，pk），patID（id），sfmonth（年月），outdept（科室），zje（费用金额），indate（日期）impala 表存储文件格式：PARQUETFILE表记录行：201,148,266，文件大小27.7g表记录行：1,206,889,596，文件大小：约165g测试用例1：select * from F_UNIBA_DXSF_TEST t WHERE ID=664024
9、1015s60.4s测试用例2：select * from F_UNIBA_DXSF_TEST t WHERE patID=00093102216.1s69s测试用例3：select outdept,sum(zje) from F_UNIBA_DXSF_TEST where sfmonth=201307 GROUP BY outdept3.6s9.4s测试用例4：select outdept,sum(zje) from F_UNIBA_DXSF_TEST where sfmonth=201306 and sfdm=a GROUP BY outdept3.9s11.2s测试用例5：select
10、outdept,sum(zje) from F_UNIBA_DXSF_TEST where sfmonth=201308 and (sfdm=a or sfdm like z%) GROUP BY outdept4s12.2s测试用例6：select outdept,count(distinct patid) from F_UNIBA_DXSF_TEST where brsf=A002 and indate=to_date(20130903,yyyymmdd) GROUP BY outdept4.1s13.9s测试用例7：select count(*) from f_uniba_dxsf_TE
11、ST1.1s6.4s测试说明：1. 没有使用oracle测试12亿记录行的性能，看看2亿规模的测试就知道没必要再测试12亿规模了，再测下去Larry Ellison的脸都要青了测试小结：数据量虽然与之前相比增加了5X，但是性能并没有随数据量线性成倍增长，时间开销的增幅大概在2X5X之间，查询性能符合笔者的预期。从测试效果看，Impala能轻松应付百亿以内规模的数据量，不太会出现数据量增加后性能直线下降的情况。毕竟Impala有上万亿级记录行规模的成功案例。如果投产的项目的数据量达到“亿”级别，应该考虑表分区了，按时间，按地区，按业务类别等等，根据业务需求和数据特点合理规划分区方法。如果有客户需
12、要上CDH的项目，建议起步配备45节点，且至少有一到两个节点的配置较之其他节点更高，用作master node 或者 secondery master node1.3 12亿行数据规模表连接Impala性能测试测试环境与之前2亿行的测试环境相同，此处不再复述测试用例测试场景耗时select d.ksmc,sum(zje) from F_UNIBA_DXSF_TEST t,d_zyks_test dwhere d.ksbh=t.outdept and t.sfmonth=201308 and (t.sfdm=a or t.sfdm like z%) GROUP BY d.ksmc事实表与维表关联
13、维表数据不超过100行11.7sselect t.outdept,count(distinct patid) from F_UNIBA_DXSF_TEST t,d_zyks_test dwhere d.ksbh=t.outdept and brsf=A002 and indate=cast(20130903 as timestamp) GROUP BY t.outdept事实表与维表关联维表数据不超过100行11.6sSELECT a.outdept,b.bzje FROM (select outdept,sum(zje) from F_UNIBA_DXSF_TESTwhere sfmonth
14、=201306 and sfdm=a GROUP BY outdept) aLEFT JOIN (select outdept,sum(zje) bzje from F_UNIBA_DXSF_TESTwhere sfmonth=201309 and (sfdm=a or sfdm like z%) GROUP BY outdept) bON a.outdept=b.outdept事实表与事实表关联12亿数据 join 12亿数据先分组后连接17sselect COUNT(*) from F_UNIBA_DXSF_TEST t,F_UNIBA_DXSF_TEST t2 WHERE t.ID=t2
15、.id AND t.ID=66402410事实表与事实表关联12亿数据 join 12亿数据先连接后分组99s测试小结：事实表连接维表的效率与事实表单表的查询效率基本一样，小表连接对效率几乎没什么影响，Impala从1.2.2开始专门优化过连接查询，主要是优化了它的查询优化器。即使是事实表与事实表连接，如果先分组再做关联其效率也还不错，接近于单表查询的效率。但是若是大事实表与大事实表先做连接再做汇总，查询效率就明细不行了。不过通常情况下，BI项目很少有事实表之间连接的，这都可以通过建模、调整报表等方式解决，而且一般也不太会有人傻到用大事实表进行互连的吧，这种极端情况换哪种数据库都没法正常计算的。2 修正测试方案中的错误为什么测试单行查询的效率低？因为测试用例1,2本身就有问题！为什么？先看看Parquet的介绍：P
