【kudu pk parquet】TPC-H Query2對比解析

這是【kudu pk parquet】的第二篇，query2在kudu和parquet上的對比解析，其中kudu包含有不能下發的謂詞。

3臺物理機，1T規模的數據集，impala和kudu版本是咱們修改後支持runtime filter的版本，結果對好比下圖：

 

縱座標表示耗時，矮表示性能好，耗時短，響應差近三倍。

首先，來咱們來看二者的執行計劃，顏色越鮮豔表示越耗時：

• parquet

 

• kudu

 

能夠看到kudu左右兩邊各有一個鮮豔的紅色框（節點），說明這兩個執行節點耗時比較長，放大來看：

左邊部分：

• parquet

 

• kudu

上面兩個圖的執行計劃紅色圈起來部分，parquet的掃描（「05：SCAN KUDU」）和關聯（「09：HASH JOIN」）分別只要1秒鐘左右，而kudu則要7秒和11秒。

你們注意到了沒有，「07：SCAN KUDU」這個節點在兩個引擎上返回的數據量是不同的，parquet只返回了5條記錄，kudu則返回了25條。同時這個返回結果是做爲runtime filter應用於「06：SCAN KUDU」的，因此能夠看到「06：SCAN KUDU」節點上返回的數據量，呈現幾何級的差別（條件寬泛，因此匹配的數據量就多了）。接着，過濾出來的結果再runtime filter應用於「05：SCAN KUDU」節點。爲何「05：SCAN KUDU」節點的掃描動做會差7倍（kudu 7秒鐘對比parquet 1秒鐘）？

分析kudu的profile能夠看到「05：SCAN KUDU」的runtime filter是在2秒鐘（另外1個是在18秒後到達，無效）之後纔到達的：

 

因此減去1秒鐘的filter等待時間，對partsupp表掃描花了6秒鐘時間，一樣是掃描partsupp表爲啥parquet只要掃描2秒鐘，怎麼解釋？這涉及到了runtime裁剪分片，由於它們的關聯鍵恰好是個主鍵

05:SCAN KUDU [kudu_1000g_2.partsupp]
   runtime filters: RF000 -> kudu_1000g_2.partsupp.ps_partkey, RF004 -> ps_suppkey
   mem-estimate=0B mem-reservation=0B
   tuple-ids=5 row-size=24B cardinality=800000000
----------------

因此動態裁剪分片很重要，這裏就再也不展開，之後有機會再解析。

掃描返回的數據多，直接致使後續的關聯節點「09：HASH JOIN」時間變成11秒。

前面埋伏了1個地雷，有心的讀者能夠想一下。

右邊部分：

• parquet

 

• kudu

 

上面兩個圖中，kudu的「00：SCAN KUDU」節點消耗了4秒鐘，而parquet只須要817毫秒！

查看kudu的profile：

|  |  |  F07:PLAN FRAGMENT [RANDOM] hosts=3 instances=3
|  |  |  00:SCAN KUDU [kudu_1000g_2.part]
|  |  |     predicates: p_type LIKE '%NICKEL'
|  |  |     kudu predicates: p_size = 22
|  |  |     mem-estimate=0B mem-reservation=0B
|  |  |     tuple-ids=0 row-size=75B cardinality=1264911
|  |  |

能夠看到有個「like」的謂詞，可是kudu官網說「!=」和「like」目前是不支持的：

由於kudu不支持「like」謂詞的下發，因此過濾的動做須要在impala側執行，這就須要impala把kudu上的數據所有掃描讀取過來，那麼這個耗時跟parquet本地過濾顯然是無法比的（網絡IO+序列化反序列化），近5倍的差別。

而後，左邊「02：SCAN KUDU」節點的runtime filter是在4秒鐘後到達：

 

因此partsupp全表掃了3秒鐘（減去1秒鐘的filter等待時間），而後應用filter，接着掃描剩下的7秒鐘（11秒-4秒），也即掃描花了10秒鐘時間。耗時比parquet長的緣由和最前面「左邊部分」的「05：SCAN KUDU」同樣，也涉及到了runtime裁剪分片，由於它們的關聯鍵也是主鍵：

|  |  02:SCAN KUDU [kudu_1000g_2.partsupp]
|  |     runtime filters: RF008 -> ps_partkey
|  |     mem-estimate=0B mem-reservation=0B
|  |     tuple-ids=2 row-size=24B cardinality=800000000
|  |

這裏埋伏第2個地雷。

-------------------------------------------------------------------------------------------

到此，TPC-H query2在kudu和parquet上執行耗時的對比已經解析完成，接下來挖出前面埋伏的2個地雷：

1. 爲何parquet上「07：SCAN KUDU」只返回5條，而kudu返回了25條？
2. 在kudu執行計劃中，一樣是掃描partsupp表，爲啥「左邊部分」「05：SCAN KUDU」節點只耗時7秒鐘，而「右邊部分」「02：SCAN KUDU」節點則耗時11秒鐘？

本文來自網易雲社區，經做者何李夫受權發佈。

原文地址：【kudu pk parquet】TPC-H Query2對比解析

更多網易研發、產品、運營經驗分享請訪問網易雲社區。