解决准实时案例的选择是相当开放的。流式处理能够提供低延迟，并有较为基本的SQL支持能力，但是需要预先定义查询来达到较好的效果。专有的数据仓库有许多特性（例如，事务、索引），并且能支持随机和预定义的查询，但是这种专有数据仓库在规模上有限制而且价格昂贵。批处理可以解决大规模数据的场景，并通过Spark SQL/Hive提供成熟的SQL支持。但是这种处理的方式通常会有比较高的延迟。由于各有利弊，最后用户通常基于可用的硬件和他们组织内部的运维支持的方式来做出选择。我们将在本文的结论处在回头来看这些挑战。
下面我会介绍通过使用Spark/MapReduce而不是运行流式处理任务，以每X分钟执行迷你批任务的方式来解决准实时场景的一些技术优点。类似于Spark流处理中的微批次（以秒粒度执行操作），迷你批次以分钟粒度来运行。在本文中，我将通篇使用“增量处理”这一术语来指代这种处理方式。
增加效率
增量的处理迷你批次中的新数据能更加有效地使用组织中的资源。让我们来举个具体的例子，我们有一个Kafka事件流以每秒一万条的速度涌入，我们想要计算过去15分钟在一些维度上的消息的数量。大部分流式处理管道使用一个外部结果存储系统（例如Cassandra, ElasticSearch）来保存聚合的计数，并让在YARN/Mesos等资源管理里的容器持续运行。这在小于五分钟的延迟窗口的场景下是说得通的。实际上，典型的YARN容器的启动开销大约是一分钟。此外，为了提升写操作到结果存储系统上的性能，我们通常进行缓存并进行批量更新，这种协议都需要容器持续地运行。