圖二: 流式處理引擎和增量迷你批次任務處理的對比。由Vinoth Chandar提供
然而在準實時處理的場景里，這些選擇可能不是最佳的。為了達到同樣的效果，你可以使用短生命周期的容器并且優(yōu)化整體的資源利用。在圖二中，流式處理器在15分鐘內執(zhí)行了六百萬次更新到結果存儲系統(tǒng)上。但是在增量更新模型里，我們執(zhí)行一次內存中的合并同時僅進行一次更新到結果存儲系統(tǒng)中，這時只會使用資源容器五分鐘。相比實時模式，增量處理模型有三倍的CPU效率提升，在更新到結果存儲的方面有幾個數量級的效率提升?；旧?，這種處理方式按需獲取資源，喚醒的間隔足以完成等待的任務，而不用長時間運行，一邊等待任務，一邊吞食CPU和內存。
建立在已有的SQL引擎之上
隨著時間的推移，大量SQL引擎在Hadoop/big data領域演進并發(fā)展（例如，Hive, Presto, SparkSQL）。它們提供了更好的針對大數據的復雜問題的表達能力。這些系統(tǒng)已經被大規(guī)模地部署，并在查詢計劃、執(zhí)行等方面得到逐步增強。另一方面，流式處理的SQL仍然處于早期階段。通過使用在Hadoop生態(tài)圈內已有的、更加成熟的SQL引擎來執(zhí)行增量處理，我們可以利用他們自身發(fā)展過程中形成的堅實基礎。
例如，連接操作在流式處理中是非常棘手的，因為要在窗口間對齊流。在增量處理模型中，這一問題變得更簡單，因為有著相對更長的窗口，這使得有更多的空間讓流在處理窗口中對齊。另一方面，如果正確性更為重要，SQL提供了一個更加簡單的方式來選擇性地擴展連接的窗口并且重新處理。