Impala
基於hive，使用內存計算，提供對HDFS、Hbase數據的高性能、低延遲的交互式SQL查詢功能。Impala適合用來處理輸出數據適中或比較小的查詢。
組件簡紹
Impala Statestore :檢查集羣各個節點上Impala daemon的健康狀態,同時不間斷地將結果反饋給各個Impala daemon
Impala Catalog :分發hive 的元數據信息到 Impala Daemon,接收來自Statestore的所有請求,一個集羣中只需要 一個節點上有這個守護進程,
Impala Daemon :Impalad接收client請求,負責讀寫數據文件,基於內存運行Sql
部署注意事項：
如果Impalad與 Catalog安裝到一塊，當內存消耗很大時會影響元數據的同步，因此要部署到不同的機器上，Catalog與StateStore 需要進行通信，所以最好部署到同一機器
常遇問題：
1.內存消耗過大導致分析任務異常的BUG
2.impala通常與MR等離線任務運行在一個集羣上， 通過YARN統一管理資源， 如何同時滿足交互式查詢和離線查詢兩種需求具有較大挑戰性。 YARN通過全局唯一的Resource Mananger調度資源， 好處是RM擁有整個集羣全局信息，能做出更好調度決策， 缺點是資源分配的性能不足。 Impala每個查詢都需要分配資源， 當每秒查詢數上千時， YARN資源分配的響應時間變的很長， 影響到查詢性能。
3.一個用戶執行大量的insert操作，其實這些任務本身是能正常執行的，但是當這種任務大量地執行時，很有可能會對整個集羣的io造成一定的影響，這時候正好又有一定數量複雜查詢的反覆提交，綜合起來會使集羣在某個時間段內出現io或者某些表被鎖住。
4.大量的insert操作或者select操作，會導致對impala的元數據庫進行大量的讀寫，這種頻繁的讀寫操作會造成mysql的鎖表。
5.如果在同一個shell腳本中，先執行了ddl操作，然後又對相應的庫執行查詢，會出現元數據同步延遲導致無法讀取信息的操作。
內存溢出問題
Impala從Impala 1.4 for CDH4、CDH5.1版本開始新增了“SQL Operations that Spill to Disk”功能，即當Impala內存運算溢出時轉移到磁盤進行運算，雖然在計算時需要佔用臨時的磁盤空間，增加了磁盤I/O，導致運算時間遠高於純內存運算，但至少解決了內存溢出時分析任務直接失敗這一“0”容錯的致命問題。
在impalashell中執行“setDISABLE_UNSAFE_SPILLS=0”或者“setDISABLE_UNSAFE_SPILLS=FALSE”命令即可。當設置DISABLE_UNSAFE_SPILLS參數的值爲0（FALSE）時，內存運算瀕臨溢出時轉爲磁盤運算；設置爲1（TRUE）時，當內存溢出時直接報內存溢出“Memory limit exceeded”錯誤
建議用戶儘可能的規避觸發“Spill to Disk”功能。該功能目前存在的限制包括：
- 不是所有的SQL語句都能觸發，例如union關鍵字還是會觸發內存溢出錯誤；
- 各個節點的內存峯值限制不能過低，低於運算所需分配給各個節點的最小內存；
- 運算explain輸出的各個節點預估內存不能過分高於各個節點的實際物理內存；
- 當觸發“Spill to Disk”功能時有其他併發查詢，仍會觸發內存溢出錯誤；
- 對磁盤的空間有一定的要求，磁盤運算的數據會寫入到impala各個節點的臨時目錄下，增加了磁盤I/O，並且會引發不可控制的磁盤佔用。
優化：
1.分區不能超過1w多，否則嚴重影響查詢性能
2.join時，把小表寫前面，會把小表廣播到其他節點。
3.引入快速、非集中式的查詢准入機制， 控制查詢併發度。
4.LLAM（low latency application master）通過緩存資源， 批量分配，增量分配等方式實現降低資源分配延時
5.爲Impala中源數據、中間表、結果表選擇合適的存儲結構。Impala默認是建立TEXT格式的表存儲，而對於海量數據的存儲，優選Parquet格式的存儲方式。在建表時顯示的指定以Parquet格式建表，並且避免使用INSER…VALUES語句向Parquet表中插入數據。因爲這種方式每插入一行數據就會在HDFS上產生單獨的一個小數據文件，會降低數據查詢的並行度從而影響查詢速度。
6.在Impala的分析任務中，無論是數據庫中的原始表、中間表、結果表還是查詢用到的海量數據表或者影響性能的關鍵表，建議在生成表之後執行COMPUTE STATS table_name命令對錶的相關信息進行統計，集羣會根據統計信息自動選擇優化的查詢方案。越是規模大的表（GB、TB級以上）統計命令執行時間越長，統計完成後的查詢優化效果越是明顯
注:壓縮數據帶來cpu額外耗時，但是減少了io耗時。
元數據操作優化
1.只有通過hdfs增加或刪除分區中文件後，才需要人爲更新元數據，其餘情況依賴impala自帶更新機制即可。
2.通過hdfs增加或刪除分區中文件後一律使用refresh tablename操作，性能損耗最低。
3.日常查詢操作一律不加-r參數。如果出現提示元數據過期，可斷開重連或者使用refresh操作。