已經有一個月沒有更新了，真的是比較懶惰。小編以後會盡量保持兩天一更新的

最近因工作需要需要使用impala，在這裡對impala進行一個個人的總結

為什麼產生impala?

熟悉大數據生態圈的朋友應該對這個並不陌生，hadoop現在主要使用的有三個版本，畢竟hadoop是作為頂級開源項目存在的，有很多優秀的公司去進行二次優化本身也是很正常的事情，主要使用的一般是apache原生的，還有CDH版本，二者的區別可以從很多方面進行進行分析

小編之前實習的公司都是使用apache的原生版本，最近也是剛剛開始接觸CDH版本，直觀的感受CDH相對於apache來說還是優點較多的，不管是管理系統的統籌調度還是web ui的設計等等。而impala同時也是Cloudera公司為了實現並行的批量sql的查詢的產物，因為相對於impala，hive在查詢方面的效率太低了（畢竟hive只是一個hadoop的數據倉庫，大部分的操作都要依賴MR去執行具體的任務）。

什麼是impala？(此處引用w3cschool關於impala的介紹)

Impala是用於處理存儲在Hadoop集群中的大量數據的MPP（大規模並行處理）SQL查詢引擎。 與其他Hadoop的SQL引擎相比，它提供了高性能和低延遲。

換句話說，Impala是性能最高的SQL引擎（提供類似RDBMS的體驗），它提供了訪問存儲在Hadoop分佈式文件系統中的數據的最快方法。

hive的查詢速度相對於impala為什麼這麼慢？

這裡我們以一個查詢為例簡單介紹一下

select u.name, o.orderid from order o join user u on o.uid = u.uid;

啟動hive，首先進行map任務，在map任務的時候對任務進行一個簡單的劃分，並且針對不同的表數據進行一個簡單的打標籤操作，用戶區分在reduce階段的結合處理，在shuffle階段通過將數據進行一個初次的處理，發送到Reduce階段。這裡沒有進行展開對抽象語法樹和具體的執行過程介紹直觀來看hive是MR的簡易化處理程序，MR是一個大數據批處理的過程，在MR的數據執行過程會包含大量的數據寫入到磁盤和從磁盤中再次讀取數據，這部分也是hadoop和spark的一個區別

這個過程如果說是用戶進行一些需要交互式的操作的話，速度自然是很慢的

Impala的優勢

先來看一下impala和hive架構圖比較一下

既然impala是在hive之後產生的，針對hive的不足impala肯定進行了相應的優化，

沒有使用MapReduce進行並行計算，雖然MapReduce是非常好的並行計算框架，但它更多的面向批處理模式，而不是面向交互式的SQL執行。與MapReduce相比：Impala把整個查詢分成一執行計劃樹，而不是一連串的MapReduce任務，在分發執行計劃後，Impala使用拉式獲取數據的方式獲取結果，把結果數據組成按執行樹流式傳遞彙集，減少了把中間結果寫入磁盤的步驟，再從磁盤讀取數據的開銷。Impala使用服務的方式避免每次執行查詢都需要啟動的開銷，即相比Hive沒了MapReduce啟動時間。

更好的IO調度，Impala知道數據塊所在的磁盤位置能夠更好的利用多磁盤的優勢，同時Impala支持直接數據塊讀取和本地代碼計算checksum。

通過選擇合適的數據存儲格式可以得到最好的性能（Impala支持多種存儲格式）。

最大使用內存，中間結果不寫磁盤，及時通過網絡以stream的方式傳遞

impala的劣勢

不支持用戶定義函數UDF。這也就意味著impala的靈活性較差，對於很多場景下不如hive靈活

不支持Transforms。

不支持查詢期的容錯。同樣這也就意味著如果impala在查詢期間出錯了，impala會進行一個

二次的查詢，如果數據量較大，擇需要消耗更多的時間和資源。而hive是依賴hadoop的各種

容錯機制的，所以可用性更高一些

對內存要求高。當然在內存越來越廉價的今天可能相對沒有那麼重要