1.背景
Runtime Filter又稱為Dynamic Filter，其目的在于通過在join的probe端提前過濾掉那些不會命中join的輸入資料來大幅減少join中的資料傳輸和計算，進而減少整體的執行時間。簡單來說就是利用小表的Join keys基于大表Join keys構造過濾器，來減少大表的資料讀取。
圖中左邊是正常掃描查詢計劃，右邊是加上Runtime Filter(Dynamic Filter)之後的掃描計劃，可以看到probe端在Join之前(Scan時)提前過濾掉資料。
SELECT * from fact_table A JOIN dimension_table B WHERE A.join_key = B.join_key; 
但是實作層面的困難在于如何将Runtime Filter(Dynamic Filter) Builder端的資料轉發給probe端，因為這些算子可能在不同的節點上運作。
一般有如下幾種設計方案：
- 協調器(Remote模式)
- Local模式
2.Impala VS Presto
2.1 Impala
Impala采用了這兩種方式、Presto采用了Local模式。
Impala Remote模式
Impala local表示生成的RF不需要通過網絡傳輸就可以直接應用，典型的情況時BROADCAST HASH JOIN的時候，JOIN和左表的HDFSTableScan是在一個Fragment中實作的（在一個線程中），由于每一個節點上運作的JOIN都會擷取到所有的右表資料，是以都能夠build出完整的基于右表資料的RF資訊，然後直接将這個資訊交給左表的Scan算子，不需要經過任何的網絡傳輸。
RuntimeFilter實作層面是采用Bloom Filter，上圖中會每個結點從HDFS讀取資料，然後傳到JoinNode，最後都到了協調者，統一merge後進行分發處理。
2.2 Presto
presto local模式
Presto 的Dynamic Filter包含 Partition Pruning（分區表） 以及 Row filtering（非分區表），依賴于broadcast join，builder端比probe端的表小得多。在這種情況下，probe端掃描和join算子在同一個程序中運作——是以它們之間的消息傳遞變得更加簡單。
presto将生成的Dynamic Filter作為 TupleDomain 公開給Probe端的 PageSourceProvider。
TPC-DS運作結果顯示DF在部分query上有顯著受益，cost-based optimizer (CBO) 。
Presto的實作原理：
- DynamicFilter
- DynamicFilterSource
DynamicFilter 代表計劃的一部分，一旦過濾器資料準備好，它将在運作時進行實際過濾。
DynamicFilterSource 負責建構運作時謂詞資料（例如布隆過濾器）并在準備好時将其傳遞給 DynamicFilter。除了建構 Bloom 過濾器 DynamicFilterSource 節點外，它還作為傳遞節點将接收到的資料轉發到 Join 節點。
代碼實作角度：DynamicFilterSource算子作為一個簡單的“pass-through”管道，同時儲存輸入的頁資訊。收集的頁面值用于建立RunTime Filter限制（用于内部連接配接中的probe端表掃描）。注意該算子僅支援小表builder端頁面（使用“廣播”連接配接時應該是這種情況）。
下圖中紅色箭頭表示發送謂詞（例如布隆過濾器）時的通信。這裡可以使用标準的 Presto 資料通信方式（Pages over Exchanges）将資料從 DFS 傳遞到 DF。實作另一個“中繼資料”協定似乎過于複雜。
如果将此連接配接公開為直接的父子關系，因為這将導緻計劃不再是樹而是 DAG。這将破壞（或至少使）通過通路者的目前周遊方法。無論如何，當在優化期間圍繞計劃樹移動一個或另一個時，需要保持 DFS 到 DF 的關系。
是以，最終實作手段是提供一個DynamicFilterSource算子作為通信管道。