连续流处理中，通过完善和改进算法来检测查询进度，特殊标记的记录被写入到每个任务的输入数据流中。当任务遇到标记时，任务会异步报告处理的最后一个Offset，一旦驱动程序收到写入接收器的所有任务的Offset，它就会将它们写入预写Log中。由于Checkpoint完全异步，因此任务可以不间断的继续，并提供一致的毫秒级延时。
3.2 Streaming对于Spark Streaming来说，当不同的数据来源输入进来时，基于固定的时间间隔，会形成一系列固定不变的数据集或者事件集（例如Kafka、Flume等）。这正好和Spark RDD基于固定的数据集吻合，从每一个批处理来看，空间维度的RDD依赖关系一致，不同的是这4个批处理输入的数据规模和数据内容不同，所以生成的RDD依赖关系实例不一样。
3.3 优势列举了Spark常见优势，如下所示：
支持Lambda，且在Spark中免费使用
高吞吐量，适用于不需要子延时的用例
容错性，默认使用微批处理
高度抽象的API
社区活跃度高
支持Exactly Once
3.4 限制另外，Spark也有它不足的地方，如下所示：
不是真正意义上的实时计算，不能够满足低延时需求
需要调整的参数太多，很难做到全面
在许多高级功能中落后于Flink
4.FlinkFlink也是来自Spark类似的学术背景，Spark来自加州大学伯克利分校，Flink来自柏林大学。像Spark一样，它也支持Lambda，但实现与Spark完全相反。Flink本质上是一个真正的实时计算引擎，将批处理作为有限数据流的特殊情况。虽然两个计算框架中的API相似，但它们在实现中没有任何相似之处，在Flink中，Map、Filter、Reduce等各个函数实现为长时间运行的运算符（类似于Storm中的Bolt）。
4.1 什么是Apache Flink？Flink是一个开源的实时计算引擎，是实时计算领域的领导者。它拥有出色的图计算和机器学习功能，其底层支持On YARN模式，且提供了本地&分布式模式，以及Docker&Kubernetes等容器部署。
4.2 如何使用Flink解决问题？在低延时场景，需要实时数据，以便能够更快的检测和解决关键事件。例如，在使用Flink之前，计算的基本业务指标，实现的延时时间约为3到4小时，这意味着，如果工程师在早上10点左右检测到业务指标变化异常，只能在下午14点左右开始排查。如果能够立马解决，则只能在下午18左右时来验证解决方案，这样实现起来效率不是很高。
假如你的业务数据是基于时间序列的，那么我们需要使用事件时间来处理在时间窗口内对业务指标进行分组。同时，Flink也可以很轻松的与存储在Kafka和HDFS中的业务数据进行集成。另外，Flink具有良好的非功能特性，便于在生产中运行，易于与不同的监控后端集成（例如Graphite、Prometheus等），以及提供良好的UI界面。此外，Flink工作的快速开发周期以及简单的执行模型使得学习曲线平稳，开发效率高。
4.3 什么是窗口和事件时间？Flink相比较Spark Streaming不仅提供了更低的延时，而且Flink还对窗口和事件时间提供了更好的支持。
4.3.1 窗口现实场景中，大部分的数据来源都是无界的，很多情况下，我们会对固定时间间隔的数据进行统计，比如每隔10秒统计一下集群服务的QPS，此时，窗口机制能够很好的帮助我们实现这类需求。
情况一：假设数据源分别在时间14秒，第14秒和第16秒产生消息类型K的消息（窗口大小为10秒）。这些消息将落入窗口中，如上图所示，在第14秒产生的前两个消息将落入窗口1（5秒~15秒）和窗口2（10秒~20秒），第16秒产生的第三个消息将落入窗口2（10秒~10秒）和窗口3（15秒~25秒）。每个窗口发出的最终计数分别为（F,2）、(F,3)、(F,1)，这是一种理想的状态。
情况二：假设其中一条消息（第14秒生产的）由于网络原因到达时延时了5秒（第19秒到达），那么此时消息在窗口的分布如何呢？延时的消息落入到窗口2和窗口3，因为第19秒在10秒~20秒和15秒~25秒这两个窗口。对于窗口2来说，计算没有什么问题（因为消息应该落入该窗口），但是它影响了窗口1和窗口3的结果。