關於Impala優化的幾點思考

Impala做爲一種查詢系統，提供SQL語義，能夠查詢存儲在Hadoop的HDFS和HBase中的PB級大數據。相比於其它查詢工具，Impala的最大特色是查詢速度較快。因此對Impala的優化也是對其查詢速度的一種保障。
一、選擇合適的文件存儲格式，既然使用impala，無非就是爲了一個目的：性能好/資源消耗少，Impala爲了作到通用性，也就是爲了更好的hive無縫鏈接，支持了大部分Hive支持的文件格式，例如Text、Avro、RCFile、Parquet等（不支持ORC），可是爲了實現更快的ad-hoc查詢（基本上都是OLAP查詢，查詢部分列，聚合，分析），咱們基本上都會選擇使用Parquet格式做爲數據文件存儲格式，即便你的數據導入到hive中存儲的使用的是其它格式（甚至經過自定義serde解析，例如Json），仍然建議你新建一個Parquet格式的表，而後進行一次數據的轉換。所以這個條目能夠看作是：請選用Parquet做爲文件存儲格式！

二、選擇合適的Partition粒度，分區的個數一般是根據業務數據來的，一般時間分區（例如日期/月份）是少不了的，例如對於一個支持多終端的應用，可能在時間分區下面再加一層終端類型的分區，設置對於每個終端的不一樣操做在進行一層分區，根據惟物辯證法，凡事都須要保持一個度，那麼就從兩個極端的狀況下來分析分區的粒度如何肯定：1：分區過少:，整個表不使用分區，或者只有一個日期的分區，這樣會致使頻繁的查詢某一個終端的數據不得不掃描成天的數據甚至整個表的數據，這是一種浪費；二、分區過多，對於每個要統計的維度都建立一個分區，這樣對於任何一個維度=’xxx’的查詢都只須要掃描精確須要的數據，可是這樣會致使大量的數據目錄，進而致使大量的文件須要掃描，這對於查詢優化器是一個災難。所以最終的建議是：根據查詢需求肯定分區的粒度，根據每個分區的成員個數預估總的分區數，保證一個表的分區數不超過30000（經驗之談？），避免太小的分區。

三、儘可能分區的成員的長度，目前分區字段能夠支持數值類型和字符串，可是這裏推薦儘量的使用合適的整數（通常用0-256就能夠保存一個分區成員的映射了，不然分區會不少）而非原始的字符串，能夠在外面創建字符串到整數的映射以保存原始信息，這個約束的主要緣由是每個分區會佔用一個目錄，每個目錄名又會在NameNode中佔用必定的內存，因此不光光是對於Impala而言，對於使用Hadoop的用戶而言，儘可能減少文件目錄的長度。

四、選擇合適的Parquet Block大小，在條目1中已經明確，要使用Impala得到較快的查詢性能，那麼就老老實實的使用Parquet做爲存儲格式，而每個Parquet的Block大小又有什麼影響呢，這裏暫且把Block的大小理解成一個Parquet分區的大小，在存儲上表現爲文件大小，若是文件過大，那麼會致使這個文件只會一個Impalad進程處理，這樣大大下降了Impala的並行處理能力；而若是文件太小則會致使大量的小文件，在帶來併發執行的同時也會帶來大量的隨機I/O的影響，所以須要對於特定的數據進行不一樣的parquet Block大小測試以尋求最適合該數據集的Block大小。

五、收集表和分區的統計信息，在執行完數據導入以後，建議使用 COMPUTE STATS語句收集表的統計信息，固然也能夠只收集某一個分區的統計信息。

六、減小返回結果大小，若是須要統計聚合，直接在SQL中完成，儘量的在where中執行過濾而不要查出來以後在應用端作過濾，對於查詢結果儘量使用LIMIT限制返回結果集大小；避免大量的結果展現在終端，能夠考慮經過INSERT xxx的方式把結果輸出到文件，或者經過impala-shell參數將結果重定向。

七、對於執行性能較差的查詢使用EXPLAIN分析緣由。

八、最後，查詢操做系統配置、查看系統使用負載，可使用Query Profile工具來探測。

上面的這些條目是最基本的應對性能調優的方案，主要包括：使用Parquet格式存儲數據、分區粒度要肯定好，保證整個表的分區數不要太多（目錄不要太多），每個分區下不要存在過多的小文件（選擇合適的Parquet文件大小），收集統計信息使得查詢優化器可以選擇更好的查詢方案，最後要學會使用EXPLAIN和Profile功能分析性能問題所在。