机器环境:
4个slave节点
10.200.187.86 cslave1 4核 3G
10.200.187.87 cslave2 2核 4G
10.200.187.88 cslave3 2核 4G
10.200.187.89 cslave4 2核 6G
测试效果:
[img]
[/img]
总结:
1.在内存够用并且是简单sql条件下,impala相比hive执行效率高很多,简单的sql在百万级别数据中运行,耗时几秒甚至不用一秒。
2.impala性能如何,与数据的存储格式关系很大,百万级别text格式与hbase格式相差十几倍,千万级别parquet格式与text格式相差百倍。
3.在当前集群配置下,百万级别impala join略比hive性能高(3~4倍),但在千万级别时impala大表的join执行失败(内存不足)。
4.impala采用parquet存储(列式),select部分字段+where条件查询效率很高。
问题:
官方表示impala新版本可以在生产环境中使用,但根据业界人反馈,会有很多问题,重点问题是出现内存溢出情况。官方推荐impala节点的内存是128G。
建议使用场景:
部署于生产环境,可应用于运维,做简单查数据工作,效率高。但有一定的内存占用,不建议使用复杂sql例如大表join等。
imapla实时查询,如上可以看到,相对hive性能是有很大提高的,但它也不能达到关系型数据库的效果,所以根据实际业务场景需求而定。
部分资料:
适用面:
Hive: 复杂的批处理查询任务,数据转换任务。
Impala:实时数据分析,因为不支持UDF,能处理的问题域有一定的限制,与Hive配合使用,对Hive的结果数据集进行实时分析。
优点:
支持SQL查询,快速查询大数据。
可以对已有数据进行查询,减少数据的加载,转换。
多种存储格式可以选择(Parquet, Text, Avro, RCFile, SequeenceFile)。
可以与Hive配合使用。
缺点:
不支持用户定义函数UDF。
不支持text域的全文搜索。
不支持Transforms。
不支持查询期的容错。
对内存要求高。
补充:
ERRORS报错情况
create table testjoinparquet as
> select a.tid,a.buyer_nick,b.status,b.adjust_fee,b.buyer_email
> from (select tid,buyer_nick from s_trade_big_parquet) a
> join
> (select tid,status,adjust_fee,buyer_email from s_trade_big_parquet) b
> on (a.tid=b.tid);
Query: create table testjoinparquet as select a.tid,a.buyer_nick,b.status,b.adjust_fee,b.buyer_email from (select tid,buyer_nick from s_trade_big_parquet) a join (select tid,status,adjust_fee,buyer_email from s_trade_big_parquet) b on (a.tid=b.tid)
Query aborted.
ERRORS ENCOUNTERED DURING EXECUTION:
Backend 3:Memory Limit Exceeded
Query Limit: Consumption=1.35 GB
Fragment dd496e82ab98ee40:19f71d48047534a2: Consumption=16.00 KB
UDFs: Consumption=0.00
EXCHANGE_NODE (id=4): Consumption=0.00
DataStreamMgr: Consumption=0.00
HdfsTableSink: Consumption=0.00
Fragment dd496e82ab98ee40:19f71d48047534a6: Consumption=1.27 GB
UDFs: Consumption=0.00
HASH_JOIN_NODE (id=2): Consumption=1.07 GB
HDFS_SCAN_NODE (id=0): Consumption=207.88 MB
EXCHANGE_NODE (id=3): Consumption=1.70 MB
DataStreamMgr: Consumption=1.70 MB
DataStreamSender: Consumption=2.45 KB
Fragment dd496e82ab98ee40:19f71d48047534aa: Consumption=82.39 MB
UDFs: Consumption=0.00
HDFS_SCAN_NODE (id=1): Consumption=82.19 MB
DataStreamSender: Consumption=8.00 KB
说明:内存已经用完,导致部分节点读取异常,parquet格式表写入很耗内存,因为parquet以1G为单位,1G得全部加载到内存中再写入。
相关文档:
开源中国:http://my.oschina.net/weiqingbin/blog/196143#OSC_h2_31,里边也有很多Impala框架优化应用方面的翻译文档。
hive与impala对比,sql差异参看http://www.cloudera.com/content/cloudera-content/cloudera-docs/Impala/latest/Installing-and-Using-Impala/ciiu_langref_unsupported.html#langref_unsupported,
中文:http://my.oschina.net/weiqingbin/blog/189414
4个slave节点
10.200.187.86 cslave1 4核 3G
10.200.187.87 cslave2 2核 4G
10.200.187.88 cslave3 2核 4G
10.200.187.89 cslave4 2核 6G
测试效果:
[img]
![](https://i-blog.csdnimg.cn/blog_migrate/b4b09e3eba90ba103ed2744bd6b88ad2.jpeg)
[/img]
总结:
1.在内存够用并且是简单sql条件下,impala相比hive执行效率高很多,简单的sql在百万级别数据中运行,耗时几秒甚至不用一秒。
2.impala性能如何,与数据的存储格式关系很大,百万级别text格式与hbase格式相差十几倍,千万级别parquet格式与text格式相差百倍。
3.在当前集群配置下,百万级别impala join略比hive性能高(3~4倍),但在千万级别时impala大表的join执行失败(内存不足)。
4.impala采用parquet存储(列式),select部分字段+where条件查询效率很高。
问题:
官方表示impala新版本可以在生产环境中使用,但根据业界人反馈,会有很多问题,重点问题是出现内存溢出情况。官方推荐impala节点的内存是128G。
建议使用场景:
部署于生产环境,可应用于运维,做简单查数据工作,效率高。但有一定的内存占用,不建议使用复杂sql例如大表join等。
imapla实时查询,如上可以看到,相对hive性能是有很大提高的,但它也不能达到关系型数据库的效果,所以根据实际业务场景需求而定。
部分资料:
适用面:
Hive: 复杂的批处理查询任务,数据转换任务。
Impala:实时数据分析,因为不支持UDF,能处理的问题域有一定的限制,与Hive配合使用,对Hive的结果数据集进行实时分析。
优点:
支持SQL查询,快速查询大数据。
可以对已有数据进行查询,减少数据的加载,转换。
多种存储格式可以选择(Parquet, Text, Avro, RCFile, SequeenceFile)。
可以与Hive配合使用。
缺点:
不支持用户定义函数UDF。
不支持text域的全文搜索。
不支持Transforms。
不支持查询期的容错。
对内存要求高。
补充:
ERRORS报错情况
create table testjoinparquet as
> select a.tid,a.buyer_nick,b.status,b.adjust_fee,b.buyer_email
> from (select tid,buyer_nick from s_trade_big_parquet) a
> join
> (select tid,status,adjust_fee,buyer_email from s_trade_big_parquet) b
> on (a.tid=b.tid);
Query: create table testjoinparquet as select a.tid,a.buyer_nick,b.status,b.adjust_fee,b.buyer_email from (select tid,buyer_nick from s_trade_big_parquet) a join (select tid,status,adjust_fee,buyer_email from s_trade_big_parquet) b on (a.tid=b.tid)
Query aborted.
ERRORS ENCOUNTERED DURING EXECUTION:
Backend 3:Memory Limit Exceeded
Query Limit: Consumption=1.35 GB
Fragment dd496e82ab98ee40:19f71d48047534a2: Consumption=16.00 KB
UDFs: Consumption=0.00
EXCHANGE_NODE (id=4): Consumption=0.00
DataStreamMgr: Consumption=0.00
HdfsTableSink: Consumption=0.00
Fragment dd496e82ab98ee40:19f71d48047534a6: Consumption=1.27 GB
UDFs: Consumption=0.00
HASH_JOIN_NODE (id=2): Consumption=1.07 GB
HDFS_SCAN_NODE (id=0): Consumption=207.88 MB
EXCHANGE_NODE (id=3): Consumption=1.70 MB
DataStreamMgr: Consumption=1.70 MB
DataStreamSender: Consumption=2.45 KB
Fragment dd496e82ab98ee40:19f71d48047534aa: Consumption=82.39 MB
UDFs: Consumption=0.00
HDFS_SCAN_NODE (id=1): Consumption=82.19 MB
DataStreamSender: Consumption=8.00 KB
说明:内存已经用完,导致部分节点读取异常,parquet格式表写入很耗内存,因为parquet以1G为单位,1G得全部加载到内存中再写入。
相关文档:
开源中国:http://my.oschina.net/weiqingbin/blog/196143#OSC_h2_31,里边也有很多Impala框架优化应用方面的翻译文档。
hive与impala对比,sql差异参看http://www.cloudera.com/content/cloudera-content/cloudera-docs/Impala/latest/Installing-and-Using-Impala/ciiu_langref_unsupported.html#langref_unsupported,
中文:http://my.oschina.net/weiqingbin/blog/189414