有什麼方案可以代替 Impala？

01-15

Presto | Distributed SQL Query Engine for Big Data

Shark - Lightning Fast Hive SQL on Spark

Druid(秒+十億行級)

Kylin(eBay,TPB+百億數據+ANSI SQL+秒級+ODBC)

Cubert(Linkedin)

Druid (大數據實時統計分析數據存儲)

Apache Kylin首頁、文檔和下載

2015年7月新增

via:SQL on Hadoop開源項目總結_hadoop_大數據-ITnose

著作權歸作者所有。

商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。

作者：教練_我要踢球

鏈接：Impala優化基本方案 - CSDN博客

來源：CSDN博客

1、選擇合適的文件存儲格式，既然使用impala，無非就是為了一個目的：性能好/資源消耗少，Impala為了做到通用性，也就是為了更好的hive無縫連接，支持了大部分Hive支持的文件格式，例如Text、Avro、RCFile、Parquet等（不支持ORC），但是為了實現更快的ad-hoc查詢（基本上都是OLAP查詢，查詢部分列，聚合，分析），我們基本上都會選擇使用Parquet格式作為數據文件存儲格式，即使你的數據導入到hive中存儲的使用的是其它格式（甚至通過自定義serde解析，例如Json），仍然建議你新建一個Parquet格式的表，然後進行一次數據的轉換。因此這個條目可以看做是：請選用Parquet作為文件存儲格式！

2、選擇合適的Partition粒度，分區的個數通常是根據業務數據來的，通常時間分區（例如日期/月份）是少不了的，例如對於一個支持多終端的應用，可能在時間分區下面再加一層終端類型的分區，設置對於每一個終端的不同操作在進行一層分區，根據唯物辯證法，凡事都需要保持一個度，那麼就從兩個極端的情況下來分析分區的粒度如何確定：1：分區過少:，整個表不使用分區，或者只有一個日期的分區，這樣會導致頻繁的查詢某一個終端的數據不得不掃描整天的數據甚至整個表的數據，這是一種浪費；2、分區過多，對於每一個要統計的維度都創建一個分區，這樣對於任何一個維度=』xxx』的查詢都只需要掃描精確需要的數據，但是這樣會導致大量的數據目錄，進而導致大量的文件需要掃描，這對於查詢優化器是一個災難。因此最終的建議是：根據查詢需求確定分區的粒度，根據每一個分區的成員個數預估總的分區數，保證一個表的分區數不超過30000（經驗之談？），避免過小的分區。
3、盡量分區的成員的長度，目前分區欄位可以支持數值類型和字元串，但是這裡推薦儘可能的使用合適的整數（一般用0-256就可以保存一個分區成員的映射了，否則分區會很多）而非原始的字元串，可以在外面建立字元串到整數的映射以保存原始信息，這個約束的主要原因是每一個分區會佔用一個目錄，每一個目錄名又會在NameNode中佔用一定的內存，所以不光光是對於Impala而言，對於使用Hadoop的用戶而言，盡量減小文件目錄的長度。

4、選擇合適的Parquet Block大小，在條目1中已經明確，要使用Impala獲得較快的查詢性能，那麼就老老實實的使用Parquet作為存儲格式，而每一個Parquet的Block大小又有什麼影響呢，這裡暫且把Block的大小理解成一個Parquet分區的大小，在存儲上表現為文件大小，如果文件過大，那麼會導致這個文件只會一個Impalad進程處理，這樣大大降低了Impala的並行處理能力；而如果文件過小則會導致大量的小文件，在帶來並發執行的同時也會帶來大量的隨機I/O的影響，因此需要對於特定的數據進行不同的parquet Block大小測試以尋求最適合該數據集的Block大小。
5、收集表和分區的統計信息，在執行完數據導入之後，建議使用 COMPUTE STATS語句收集表的統計信息，當然也可以只收集某一個分區的統計信息。
6、減少返回結果大小，如果需要統計聚合，直接在SQL中完成，儘可能的在where中執行過濾而不要查出來之後在應用端做過濾，對於查詢結果儘可能使用LIMIT限制返回結果集大小；避免大量的結果展示在終端，可以考慮通過INSERT xxx的方式把結果輸出到文件，或者通過impala-shell參數將結果重定向。
7、對於執行性能較差的查詢使用EXPLAIN分析原因。
8、最後，查詢操作系統配置、查看系統使用負載，可以使用Query Profile工具來探測。
上面的這些條目是最基本的應對性能調優的方案，主要包括：使用Parquet格式存儲數據、分區粒度要確定好，保證整個表的分區數不要太多（目錄不要太多），每一個分區下不要存在過多的小文件（選擇合適的Parquet文件大小），收集統計信息使得查詢優化器能夠選擇更好的查詢方案，最後要學會使用EXPLAIN和Profile功能分析性能問題所在。

也就是dremel的思想，可以看下drill

Impala本質上是一個MPP資料庫，只是利用了HDFS來作為存儲底層，其實和Hive，Spark-SQL這種SQL底下套上另外一套計算框架都不一樣。

如果問哪種方案替代Impala，我覺得像GreenPlum這種MPP資料庫更合適一點