測試所用的檔案格式有如下幾種：SequenceFile（Hadoop生态圈常用檔案格式）、RCFile（結合了行式和列式存儲格式的優點）、Parquet（列式存儲格式）
4不同檔案格式和壓縮方式條件下的CPU資源消耗對比
- CPU累積時間一方面反映的是查詢時間，即查詢時間越長，CPU的累積時間就會越多。另一方面反映的是查詢中重組資料的難度，重組資料的難度越大，CPU的累積時間就會越多。因為Spark SQL無法監測到具體的CPU使用情況，故沒有比較。- 這裡（Hive/Impala）各種檔案格式消耗CPU值，是指在整個查詢過程中CPU累積時間。
- RCFile采用Snappy與Parquet壓縮方式的對比：從Hive來看兩者消耗的CPU時間相當，而且兩者的資料量大小是差不多的（Hive的RCFile經過Snappy壓縮後為286G，Parquet資料量大小為265G），對于Hive來講資料量的多少直接影響了CPU累積時間。但是要注意的是，在查詢一，因為查詢一要求加載所有的列，對于以列式存儲為特征的Parquet而言，資料重組的難度會極具增大，消耗了很多的CPU資源，是以在Hive的查詢一中，Parquet消耗的CPU累計時間是最大的，同時查詢時間也是最大的。是以綜合來看，對于Hive而言采用RCFile檔案格式經過Snappy壓縮後的方式是最合适的。- Impala的說明：對于Impala而言，情況則有些不同。在查詢一中因為加載所有列，造成了記憶體不足，導緻無法查詢。
5不同檔案格式和壓縮方式條件下的記憶體消耗對比
- 因為無法檢測具體每種查詢所消耗的記憶體資源，是以本次執行Spark SQL和Hive基本可以假定是在充分使用了8G記憶體資源下測試的。- 對于三種類型的查詢方式在記憶體上的使用情況在縱向比較是存在困難的，一是沒有監測到具體查詢中Hive和SparkSQL的記憶體使用情況，二是三者并非都是以記憶體計算為特點，縱向比較意義不大。但是可以通過設定yarn.nodemanager.resource.memory-mb的大小橫向對Hive和SparkSQL在不同記憶體條件下進行比較。
- 在查詢一中，因為對于未壓縮的Sequence消耗記憶體很大，單節點峰值超過了7.8G。Parquet消耗記憶體更大，單節點峰值超過了12.6G，并且因為無法再申請記憶體而報錯。是以在加載全部列的時候，仍然是不推薦使用Parquet格式。- 比較除查詢一之外的其餘查詢所消耗的平均記憶體，可以比較所有檔案的平均消耗記憶體排名為：Sequence未壓縮（1650MB）> Sequence 壓縮（798MB）> Parquet（652MB）> RCFile未壓縮（560MB）> RCFile壓縮（500MB）> 文本（478MB）。Parquet格式所消耗的記憶體與RCFile、文本相比，記憶體消耗相差不大。是以選擇Parquet格式對于Impala而言，仍然是不錯的選擇。- 由于快速檢索這種互動式查詢需要支援多使用者并發操作，是以每一個查詢使用的資源越少越好。從上述記憶體使用狀況來看，使用文本格式占用的資源是最穩定的，保持在較低水準，使用Parquet格式占用的記憶體有時高于1GB（查詢1、2、3、7），不太穩定，當有20個并發查詢時目前叢集的節點的實體記憶體是不夠的（16GB，實際可用12.6GB）。是以，除非實體記憶體充足，不然使用Parquet格式可能無法支援15個以上的并發查詢。
6不同查詢工具生成Parquet格式對Impala查詢的影響
- 從前面三個部分可以看出Impala與Parquet适配性最好，而且Impala在使用Parquet格式進行查詢時的查詢速度最快。但是我們從上面的測試也可以看出三種查詢工具生成的Parquet格式檔案是不一樣的。這會影響到Impala查詢的各個方面。下面測試的就是不同查詢工具生成的Parquet格式對Impala查詢的影響。
從上圖可以看出以下幾點：1. 對于查詢三至查詢六，所有Parquet格式的查詢時間相當；對于查詢一與查詢二，Spark-Parquet的查詢時間接近Hive-Parquet的1/2；對于查詢七，Hive-Parquet和Spark-Parquet查詢時間相當，均少于Impala-parquet。2. 結論：單從查詢速度上考慮，Spark-parquet是适配于Impala的最佳Parquet格式。
其中，對于Impala生成的Parquet檔案來說查詢一因記憶體占用過大而無法執行，圖中的CPU時間标記為-1。從上圖可以看出以下幾點：1. 對于查詢二至六，所有Parquet格式CPU時間相當；對于查詢一與七，Spark-Parquet的CPU時間最少。2. 結論：單從CPU時間上考慮，Spark-parquet占用的CPU資源最少。
其中，對于Impala生成的Parquet檔案來說查詢一因記憶體占用過大而無法執行，圖中的記憶體占用标記為-1。從上圖可以看出以下幾點：1. 對于所有查詢，Impala-Parquet格式占用的記憶體最多；對于查詢二至查詢七，Hive-Parquet和Spark-Parquet占用的記憶體相當；對于查詢一，Spark-Parquet占用記憶體約為Hive-Parquet的1.5倍。2. 結論：單從記憶體占用上考慮，Hive-Parquet占用的記憶體資源最少，其次是Spark-Parquet。
其中，對于Impala生成的Parquet檔案來說查詢一因記憶體占用過大而無法執行，圖中的讀取資料量标記為-1。從上圖可以看出以下幾點：1. 對于查詢二至查詢七，讀取資料量大小的排序大緻為 Impala-Parquet > Hive-Parquet > Spark-Parquet；對于查詢一至查詢三，Spark-Parquet讀取的資料量接近Hive-Parquet的一半。2. 結論：單從讀取資料量大小上考慮，Spark-Parquet讀取的資料量最少，在以IO時間為主要時間開銷的查詢（如查詢一）中，讀取資料量與查詢時間成正比，即Spark-Parquet的查詢時間最少。- 綜合上述幾點，可以得出的結論是：在執行除查詢一（掃描所有列）以外的查詢時，使用Spark-Parquet的查詢速度最快，占用CPU與記憶體資源最少。
7結論
• 縱向上來比較，在節點可用實體記憶體充足的情況下，Impala采用SparkSQL生成的Parquet格式的查詢速度是最快的，并且在CPU和記憶體上同時具有優勢。如果需要建構大資料情況下互動式查詢，本條結論具有重要的參考價值。• 輸入資料量的大小是影響查詢速度、CPU消耗與記憶體消耗的關鍵。• 盡管在文本格式下進行格式轉換會消耗時間，但是這種時間的消耗是值得的，因為可以極大提升查詢速度，尤其是适合一次寫入，多次查詢的情況。• Sequence File是Hadoop生态系統中普遍支援的檔案格式，是以适用性是很普遍的，相比之下，RCFile和Parquet檔案格式的适用性要比Sequence File低。但是其在查詢速度、資源消耗上是不占有任何優勢的。• 對指定格式進行Snappy壓縮也是合适的，因為可以減少近一半的資料量，可以減少IO壓力，将IO的壓力分擔給CPU。• 對于Hive而言，采用RCFile格式并對其進行Snappy壓縮是最合适的。• 對于SparkSQL而言，采用Parquet格式是最合适的。• 對于加載全部列的查詢方式，采用RCFile格式是最合适的。• 對于加載部分列，優先選擇Impala進行查詢。而且對于檔案格式來說，推薦使用Spark SQL進行壓縮生成的Parquet格式。