图二: 流式处理引擎和增量迷你批次任务处理的对比。由Vinoth Chandar提供
然而在准实时处理的场景里，这些选择可能不是最佳的。为了达到同样的效果，你可以使用短生命周期的容器并且优化整体的资源利用。在图二中，流式处理器在15分钟内执行了六百万次更新到结果存储系统上。但是在增量更新模型里，我们执行一次内存中的合并同时仅进行一次更新到结果存储系统中，这时只会使用资源容器五分钟。相比实时模式，增量处理模型有三倍的CPU效率提升，在更新到结果存储的方面有几个数量级的效率提升。基本上，这种处理方式按需获取资源，唤醒的间隔足以完成等待的任务，而不用长时间运行，一边等待任务，一边吞食CPU和内存。
建立在已有的SQL引擎之上
随着时间的推移，大量SQL引擎在Hadoop/big data领域演进并发展（例如，Hive, Presto, SparkSQL）。它们提供了更好的针对大数据的复杂问题的表达能力。这些系统已经被大规模地部署，并在查询计划、执行等方面得到逐步增强。另一方面，流式处理的SQL仍然处于早期阶段。通过使用在Hadoop生态圈内已有的、更加成熟的SQL引擎来执行增量处理，我们可以利用他们自身发展过程中形成的坚实基础。
例如，连接操作在流式处理中是非常棘手的，因为要在窗口间对齐流。在增量处理模型中，这一问题变得更简单，因为有着相对更长的窗口，这使得有更多的空间让流在处理窗口中对齐。另一方面，如果正确性更为重要，SQL提供了一个更加简单的方式来选择性地扩展连接的窗口并且重新处理。