測試環境
- 節點:
2 台主節點，6台計算節點
- 機器配置:
16個物理核
128G內存
12*3T磁盤
- 操作系統:
redhat 7.2
- 版本:
CDH 5.7.1-1.cdh5.7.1.p0.11
impala_kudu 2.7.0-1.cdh5.9.0.p0.23
kudu 0.9.1-1.kudu0.9.1.p0.32
spark 2.0.0
- 對照組：
Spark on Parquet
Impala on Parquet
Impala on Kudu
測試數據、語句、場景
TPC-DS，是用於評測決策支持系統（或數據倉庫）的標准SQL測試集。這個測試集包含對大數據集的統計／報表生成／聯機查詢／數據挖掘等復雜應用，測試用的數據和值是有傾斜的，與真實數據一致。可以說TPC-DS是與真實場景非常接近的一個測試集，也是難度較大的一個測試集。
TPC-DS支持指定不同的數據大小。本次測試選擇的數據大小分別為10GB、100GB、1TB、10TB。數據大小與表rows的關系如下圖所示：
TPC-DS一共99個測試案例，遵循SQL'99和SQL 2003的語法標准，SQL案例比較復雜．分析的數據量大，並且測試案例是在回答真實的商業問題．測試案例中包含各種業務模型（如分析報告型，迭代式的聯機分析型，數據挖掘型等）．本次測試使用了大部分的query，某些query由於語法錯誤、語法不兼容，或者在Hive、Spark、Impala下面都無法跑過，因此這些query不納入性能測試的范圍。
參數配置
本次測驗基本上使用了CDH的默認配置。一些重要配置有：
- Hadoop: 使用非安全模式，不帶kerberos認證。
- Impala: 使用自帶的Resource Management，而非YARN；Catalog Server設置內存為32gb；impalad內存設置為64gb。
- Kudu： 使用data disks的第一塊磁盤作為WAL磁盤（也就是使用SATA盤）；Kudu Tablet Server內存設置為32gb。
- Spark： 配置如下
spark.serializer org.apache.spark.serializer.KryoSerializer spark.driver.memory 10g spark.executor.memory 10g spark.executor.instances 36 spark.executor.cores 5 spark.yarn.executor.memoryOverhead 2g spark.sql.autoBroadcastJoinThreshold 209715200
測試步驟
- 通過tpcds-gen在hdfs上生成parquet數據
- 利用impala將tpcds數據從hdfs上導入到kudu
- 測試impala on kudu的性能
- 測試impala on parquet性能
- 測試spark on parquet的性能
測試結果
Kudu數據導入速度
如圖所示，kudu在導入小表時速度非常快，當導入大表時，速度反而變慢，性能嚴重下降。為了避免表字段類型、字段數目、大小造成的速度差異。我們根據同一張表store_sales進行比較，其結果為
(單位rows/秒, 越大越好)
由於kudu一開始先將數據插入到memRowSet，因此在數據集較小時插入速度非常快。當插入的數據達到10億條級別以上時，性能開始出現嚴重的downgrade。根據Todd在slack上的解釋是，impala插入數據時采用了隨機的順序，如果先將數據排序，再用impala導入可改善插入性能。目前社區正在改善此問題。
Kudu 查詢性能
首先我們比較一下100GB下impala on kudu 和impala on parquet的性能
(單位second, 越小越好)
如圖所示，在小數據集的查詢性能上，kudu普遍比parquet慢了2倍~10倍。
如果我們再比較一下1TB下的性能，可以發現
Kudu比parquet慢了10倍~100倍。這其中很可能是由於impala對kudu缺少優化導致的。因此我們再來比較基本查詢kudu的性能
如圖所示，單從簡單查詢來看，kudu的性能和imapla差距不是特別大，其中出現的波動是由於緩存導致的。和impala的差異主要來自於impala的優化。
Spark 2.0 / Impala查詢性能
查詢速度
(單位second, 越小越好)
從數據大小分析， 1TB和10TB下的差異不大。
從語句進行分析，Impala對於query75、query94下的性能較差，很可能是語句優化，join順序導致的異常。Spark對於query17、query50性能較差。
綜合分析，可以發現impala的速度普遍比Spark快一倍以上。Impala經過compute stats之后，消除了query75、query94這兩個語句的異常，在其它語句上的速度提升達到了一倍以上，在某些語句上compute stats后速度反而下降，如query58，然而這種情況很少見。
資源使用情況
Impala的資源使用整體少於Spark，磁盤的數據讀取少於Spark，這對於速度的提高至關重要，這與其語句的優化有關。Impala的CPU一直維持在較低的水平，說明其C++的實現比JAVA高效。
Spark的CPU占用較高，但是維持在50%的水平，可見CPU並沒有成為其瓶頸。Spark的磁盤寫入（綠色）非常多，這也許是其速度的主要瓶頸。從網絡IO上來看Spark也多余Impala，這一點可能與語句的優化、join、shuffle的實現方式有關。
--------
By 浴雨青山
商業轉載請聯系作者獲得授權,非商業轉載請注明出處