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外部表為什么比內部表要慢”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！