HIVE外部表为什么比内部表要慢

这篇文章主要为大家展示了“Hive外部表为什么比内部表要慢”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“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: 74555

以下是程序访问，通过匹配ROWKEY的前缀，看看requests增长：

      val scan = new Scan()
      scan.setCaching(100)
      scan.setRowPrefixFilter(Bytes.toBytes("i517T5100"))

访问之后的requests为：74559 ，  增长了4， 返回结果也为4， 那么我可以这么理解，通过i517T5100这个ROWKEY前缀访问，获取4条记录，requests也增长了4

以上程序我可以改写为SQL： select count(*) from t_device_fault_statistics where id like 'i517T5100%' 

访问之后，返回结果为4， 我们来看看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外部表除了使用等于ROWKEY方式不慢，其他的查询应该是从HBASE加载全部数据，然后通过HIVE本身来过滤。奇怪的是等于ROWKEY方式为什么HIVE就可以通过HBASE过滤，而不是依靠HIVE自己本身呢?  说明等于ROWKEY的方式，HIVE可以直接转义成HBASE执行语句，定位一条数据，而其他方式HIVE无能为力，只能全表。

以上是“HIVE外部表为什么比内部表要慢”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注编程网精选频道！