impala筆記
Impala是hadoop上交互式MPP SQL引擎， 也是目前性能最好的開源SQL-on-hadoop方案。 如下圖所示， impala性能超過SparkSQL、 Presto、 Hive。
impala與hadoop生態結合緊密
（1） HDFS是impala最主要的數據源。 除此之外， impala也支持HBase，甚至支持S3存儲。
（2） impala表定義存儲在hive metastore中， 支持讀取hive表定義。
（3） 支持Parquet， RCFile， sequence file， txt等常見文件格式， 其中Parquet是列存格式，性能最佳。
（4） 集成YARN。
SQL支持度：支持SQL92中的大部分select語句， 以及SQL2003標準中的分析函數。 不支持DELETE和UPDATE， 但是支持批量裝載數據（insert into select, LOAD DATA) 和批量刪除數據（drop partition）。除此之外， 用戶也可直接操作HDFS文件實現數據裝載和清理。
架構如上圖所示。
查詢執行
impalad分為frontend和backend兩個層次， frondend用java實現（通過JNI嵌入impalad）， 負責查詢計劃生成， 而backend用C++實現， 負責查詢執行。
frontend生成查詢計劃分為兩個階段：（1）生成單機查詢計劃，單機執行計劃與關系數據庫執行計劃相同，所用查詢優化方法也類似。（2）生成分布式查詢計劃。 根據單機執行計劃， 生成真正可執行的分布式執行計劃，降低數據移動， 盡量把數據和計算放在一起。
上圖是SQL查詢例子， 該SQL的目標是在三表join的基礎上算聚集， 并按照聚集列排序取topN。 impala的查詢優化器支持代價模型： 利用表和分區的cardinality，每列的distinct值個數等統計數據， impala可估算執行計劃代價， 并生成較優的執行計劃。 上圖左邊是frontend查詢優化器生成的單機查詢計劃， 與傳統關系數據庫不同， 單機查詢計劃不能直接執行， 必須轉換成如圖右半部分所示的分布式查詢計劃。 該分布式查詢計劃共分成6個segment（圖中彩色無邊框圓角矩形）， 每個segment是可以被單臺服務器獨立執行的計劃子樹。
impala支持兩種分布式join方式， 表廣播和哈希重分布：表廣播方式保持一個表的數據不動， 將另一個表廣播到所有相關節點（圖中t3）； 哈希重分布的原理是根據join字段哈希值重新分布兩張表數據(譬如圖中t1和t2）。分布式計劃中的聚集函數分拆為兩個階段執行。第一步針對本地數據進 行分組聚合（Pre-AGG）以降低數據量， 并進行數據重分步， 第二步， 進一步匯總之前的聚集結果（mergeAgg）計算出最終結果。 與聚集函數類似， topN也是分為兩個階段執行， （1）本地排序取topN，以降低數據量； （2） merge sort得到最終topN結果。
Backend從frontend接收plan segment并執行， 執行性能非常關鍵，impala采取的查詢性能優化措施有
資源管理
impala通常與MR等離線任務運行在一個集群上， 通過YARN統一管理資源， 如何同時滿足交互式查詢和離線查詢兩種需求具有較大挑戰性。 YARN通過全局唯一的Resource Mananger調度資源， 好處是RM擁有整個集群全局信息，能做出更好調度決策， 缺點是資源分配的性能不足。 Impala每個查詢都需要分配資源， 當每秒查詢數上千時， YARN資源分配的響應時間變的很長， 影響到查詢性能。 目前通過兩個措施解決這個問題：（1）引入快速、非集中式的查詢準入機制， 控制查詢并發度。（2）LLAM（low latency application master）通過緩存資源， 批量分配，增量分配等方式實現降低資源分配延時。
相關系統對比
| HIVE | Spark | Impala | |
| 概要 | Hive是老牌的SQL-on-hadoop解決方案 | spark之上的交互式SQL解決方案 提供DataFrame API作為SQL補充， 方便實現ETL、分析、機器學習等復雜邏輯。 SparkSQL使用scala定義UDF， 非常方便。 |
hadoop上交互式MPP SQL引擎 |
| 容錯 | 強。 中間結果落盤，容錯能力強，最細粒度容錯。 | 較強。基于數據血緣關系的數據恢復。 | 弱。 遇到問題時，需要重做查詢 |
| 性能 | 慢。 |
較快。 |
快。 |