HIVE外部表到底损失多少性能
2017-06-30 10:14
246 查看
我们经常说HIVE外部表比内部表要慢,到底是为什么? 以HBASE为例,如果把HIVE作为一个HBASE客户端的查询工具,语句转义之后发到HBASE,HBASE返回数据,按理不至于慢很多,毕竟只多做了一层SQL到HBASE的语句的转义。 既然事实却是慢,那么我们就可以认为HIVE外部表不能这么理解,应该还有其他的东西在阻碍HIVE外部表的性能,毕竟HIVE是走MAPREDUCE。
hbase(main):003:0> count 't_device_fault_statistics'
557 row(s) in 0.2890 seconds
=> 557
这里用一个只有557条数据的HBASE表来测试,看看HIVE外部表到底和HBASE本身的客户端有哪些区别。 准别工作如下:
1. 打开HBASE UI, http://hostname:60010/table.jsp?name=t_device_fault_statistics 这里有一个指标是requests(起初,我觉得这个是请求次数,测试之后我认为这是查询请求最后获得的行数, 因为你随便查询一个不存在的数字,你会发现这个数字是不会增长的,但是如果你查询输出10条数据,这个数字就会增长10)
2. 写一个JAVA程序,或者通过HBASE客户端也行
3. 建立HBASE的HIVE外部表
完成以上工作就开始测试,整个猜想是, 比较通过HIVE外部表访问之后requests增长和通过Hbase本身的API或者客户端访问的requests增长的区别。
当前requests: <span font-size:medium;white-space:normal;background-color:#ffffff;"="" style="word-wrap: break-word; font-family: 宋体, Arial; color: rgb(51, 51, 51);">74555
以下是程序访问,通过匹配ROWKEY的前缀,看看requests增长:
val scan = new Scan()
scan.setCaching(100)
scan.setRowPrefixFilter(Bytes.toBytes("i517T5100"))
访问之后的requests为:75216, 75216-74559=657 (
我测试很多次,表的实际行是557,但是每次这里增长657,我不确定为什么不是557,而是657)
这里暂时不管为什么不是557,而是实际的657, 总之可以看到,通过访问ROWKEY前缀,HBASE客户端只有4个requests增长,但是HIVE外部表有657。 能否这么理解,HIVE通过SQL查询是把
数据全部查询出来,然后通过HIVE本身来过滤,而HBASE查询是在服务器上过滤的,所以HIVE查询之后requests增长为表的行数.
经过测试,除了SQL条件采用 等于 rowkey的方式,requests增长会和Hbase客户端一样,其他的一定是全表扫描。 有人说HIVE是走mapreduce,mapreduce本身也是通过scan ,也可以增加过滤来达到效果,但是实际上没有。
从上面的测试,HIVE外部表除了使用等于ROWKEY方式不慢,其他的查询应该是从HBASE加载全部数据,然后通过HIVE本身来过滤。奇怪的是等于ROWKEY方式为什么HIVE就可以通过HBASE过滤,而不是依靠HIVE自己本身呢? 说明等于ROWKEY的方式,HIVE可以直接转义成HBASE执行语句,定位一条数据,而其他方式HIVE无能为力,只能全表。
hbase(main):003:0> count 't_device_fault_statistics'
557 row(s) in 0.2890 seconds
=> 557
这里用一个只有557条数据的HBASE表来测试,看看HIVE外部表到底和HBASE本身的客户端有哪些区别。 准别工作如下:
1. 打开HBASE UI, http://hostname:60010/table.jsp?name=t_device_fault_statistics 这里有一个指标是requests(起初,我觉得这个是请求次数,测试之后我认为这是查询请求最后获得的行数, 因为你随便查询一个不存在的数字,你会发现这个数字是不会增长的,但是如果你查询输出10条数据,这个数字就会增长10)
2. 写一个JAVA程序,或者通过HBASE客户端也行
3. 建立HBASE的HIVE外部表
完成以上工作就开始测试,整个猜想是, 比较通过HIVE外部表访问之后requests增长和通过Hbase本身的API或者客户端访问的requests增长的区别。
当前requests: <span font-size:medium;white-space:normal;background-color:#ffffff;"="" style="word-wrap: break-word; font-family: 宋体, Arial; color: rgb(51, 51, 51);">74555
以下是程序访问,通过匹配ROWKEY的前缀,看看requests增长:
val scan = new Scan()
scan.setCaching(100)
scan.setRowPrefixFilter(Bytes.toBytes("i517T5100"))
访问之后的requests为:75216, 75216-74559=657 (
我测试很多次,表的实际行是557,但是每次这里增长657,我不确定为什么不是557,而是657)
这里暂时不管为什么不是557,而是实际的657, 总之可以看到,通过访问ROWKEY前缀,HBASE客户端只有4个requests增长,但是HIVE外部表有657。 能否这么理解,HIVE通过SQL查询是把
数据全部查询出来,然后通过HIVE本身来过滤,而HBASE查询是在服务器上过滤的,所以HIVE查询之后requests增长为表的行数.
经过测试,除了SQL条件采用 等于 rowkey的方式,requests增长会和Hbase客户端一样,其他的一定是全表扫描。 有人说HIVE是走mapreduce,mapreduce本身也是通过scan ,也可以增加过滤来达到效果,但是实际上没有。
从上面的测试,HIVE外部表除了使用等于ROWKEY方式不慢,其他的查询应该是从HBASE加载全部数据,然后通过HIVE本身来过滤。奇怪的是等于ROWKEY方式为什么HIVE就可以通过HBASE过滤,而不是依靠HIVE自己本身呢? 说明等于ROWKEY的方式,HIVE可以直接转义成HBASE执行语句,定位一条数据,而其他方式HIVE无能为力,只能全表。
相关文章推荐
- CPU 硬盘性能到底相差多少
- 赋值一次到底消耗多少性能?
- 深度剖析浏览器渲染性能原理,你到底知道多少?
- 小米步童鞋店在这次交易中到底损失了多少钱 ?
- 『性能VS稳定』.Net 的 try-catch 到底浪费多少效率
- CPU 硬盘性能到底相差多少
- oracle索引重建到底会提高多少性能?
- 数据中心到底要用多少光模块?
- 【虫师--系列20】性能测试知多少---性能分析与调优的原理
- 性能测试知多少---并发用户
- 我们到底能认识多少?
- 用cloudera manager安装impala全过程以impala、hive、Spark性能比较--------(二)手动安装CDH4,hive,impala。
- Java Jdbc减少交互提升批量处理性能,到底该如何优化才好?
- Hive的管理表和外部表
- String,到底创建了多少个对象?
- 音频直播,这里面到底有多少坑
- Hadoop 之 Hive创建内外部表
- Android中常用的布局以及性能你了解多少?
- 性能测试知多少---性能需求分析
- 在hive中query外部表的简单测试