選擇正確的文件格式
對於大量數據（每個表或分區多個千兆字節），Parquet文件格式的性能最佳，因為它結合了列式存儲佈局，較大的I / O請求大小以及壓縮和編碼。
對於較小的數據量（每個表或分區只有幾GB或更少），您可能看不到文件格式之間的顯著性能差異。 在小數據量下，可以通過減少並行執行的機會來抵消來自有效壓縮文件格式的I / O減少。
在計劃生產部署或進行基準測試時，請始終使用實際數據量來獲得性能和可伸縮性的真實畫面。
最小化將結果傳輸回客戶端的開銷
使用以下技術：
· 聚合。 如果您需要知道有多少行與某個條件匹配，某列中的匹配值的總和，最低或最高匹配值等，請調用聚合函數，例如COUNT（），SUM（）和MAX（） 而不是將結果集發送到應用程序並在那裡進行那些計算。 請記住，未聚合結果集的規模可能很大，需要大量時間才能在網絡上傳輸。
· 過濾。 在查詢的WHERE子句中使用所有適用的測試，以消除不相關的行，而不是生成較大的結果集並使用應用程序邏輯對其進行過濾。
· LIMIT子句。 如果您只需要查看結果集中的一些樣本值，或使用ORDER BY進行查詢的頂部或底部值，請使用LIMIT子句來減小結果集的大小，而不是要求完整的結果集，然後 扔掉大部分的行。
選擇合適的Parquet塊尺寸
默認情況下，Impala INSERT…SELECT語句創建塊大小為256 MB的Parquet文件。 （此默認值在Impala 2.0中已更改。以前，限制為1 GB，但是Impala對壓縮進行了保守的估計，導致文件小於1 GB。）
Impala編寫的每個Parquet文件都是單個塊，從而允許單個主機將整個文件作為一個單元進行處理。 當您將Parquet文件複製到HDFS或HDFS文件系統之間時，請使用hdfs dfs -pb保留原始塊大小。
如果您的Parquet表中或者只有一個查詢訪問的分區中只有一個或幾個數據塊，那麼您可能會由於不同的原因而變慢：沒有足夠的數據來利用Impala的並行分佈式 查詢。 每個數據塊由一個DataNode上的單個內核處理。 在16核計算機的100個節點的群集中，您可能同時處理數千個數據文件。 您想在"許多小文件"和"單個大文件"之間找到一個平衡點，以平衡大容量I / O和並行處理。 您可以在執行INSERT…SELECT語句之前設置PARQUET_FILE_SIZE查詢選項，以減小每個生成的Parquet文件的大小。
對分區鍵列使用最小的適當整數類型
儘管試圖將字符串用作分區鍵列是很吸引人的，但是由於這些值始終會變成HDFS目錄名，因此您可以通過將數字值用於常見分區鍵字段（例如YEAR，MONTH和DAY）來最大程度地減少內存使用。 使用最小的整數類型來保存適當的值範圍，通常MONTH和DAY為TINYINT，而YEAR為SMALLINT。 使用EXTRACT（）函數可從TIMESTAMP值中提取各個日期和時間字段，並將CAST（）返回值轉換為適當的整數類型。
避免小文件
在Impala之外生成數據文件時，最好使用文本格式或Avro，您可以在其中逐行構建文件。
數據放入Impala後，您可以將其轉換為更有效的Parquet格式，並使用單個INSERT…SELECT語句將其拆分為多個數據文件。 或者，如果您具有在數據準備過程中生成數兆字節的Parquet文件的基礎結構，請執行此操作，並跳過Impala中的轉換步驟。
始終使用INSERT…SELECT在Impala中將大量數據從表複製到表。 對於大量數據或對性能至關重要的表，請避免使用INSERT…VALUES，因為每個此類語句都會產生一個單獨的微小數據文件。
例如，如果一個Parquet表中有成千上萬個分區，每個分區的數據少於256 MB，則考慮以更細粒度的方式進行分區，例如按年/月而不是年/月/日。 如果效率低下的數據提取過程在同一表或分區中生成了數千個數據文件，請考慮通過執行INSERT…SELECT壓縮所有數據到另一個表來壓縮數據。 數據將通過此過程重組為少量的較大文件。
(本文翻譯自Z² Little的文章《Best Practices of Impala》，參考：https://medium.com/@xzz201920/best-practices-of-impala-3480069ae767)
