31｜新一代流处理框架：Batch mode和Continuous mode哪家强？

作者回复: 老弟思考的很到位~ 从实现上来说，先消费再记录的方式，肯定是可以实现的。不过这样一来，会有几方面的问题： 1）首先是老弟提到的，数据处理失败，就存在一个重试的问题，如果是先写WAL（数据+元数据），再消费，因为数据已经落盘（本地或是HDFS）缓存了，因此再消费一遍，很容易，也很方便。但如果反过来，先消费、再写日志，那就得从Source重新拉数据，网络开销是一方面，再者，为了确保拉取的是同一份数据，实际上也需要维护元数据，来管理offsets 2）再一个，即便是没有失败重试的问题，在batch mode下，一个批次的数据，还是以批次为粒度，来触发一个job，这中间的任务调度延迟，其实仅靠先处理数据，是去不掉的。这个跟Continuous mode很不一样，Continuous mode是常驻的job，因此不存在这个问题。 关于老弟说的“Exactly once”，严格来说，Spark自己不能保证“Exactly once”，但它可以做到“At least once”，再结合幂等的Sink，端到端可以做到“Exactly once”。但是就Structured Streaming来说，它自己只能做到“At least once”。

作者回复: 好问题，先说结论，虽然咱们的主题是Spark，不过就追求实时性的流处理来说，我还是会推荐Flink。 Flink的Kappa架构，天然对流处理友好，尤其是对于实时性的支持。因为出发点就是流计算，因此随着Flink的发展、迭代，开发API也越来越丰富，功能也越来越完善。 而Spark不同，Spark实际上是Lambda架构，天然以批处理为导向，最初的流处理，也是微批模式，也就是Micro-batch，咱们分析了，微批模式，没法保证实时性，不过对于高吞吐，倒是比较友好。尽管Spark官方推出了Continuous mode，但是目前功能、API各方面还没有那么完善，至少现在为止，Continuous mode还不支持聚合操作，仅这一点，限制就太大了，试问现在的数据处理，有多少逻辑是不需要聚合操作的呢？太少了。因此，Continuous mode，在我看来，更多的是一种尝试和探索，至于后续能否提供更多的功能与能力，还要看Spark社区对于这方面的发力。 不过，从课程内容的角度，我们还是得让大家知道，Spark社区推出了这么一种Continuous mode。一方面是让大家知道有这么回事，再者和Micro batch mode是个对比，有利于大家做对比学习，加深印象 但是就能力来说，从实时性和功能完善的角度出发， 我觉得，还是Flink更加实用

作者回复: 课程主要围绕Structure Streaming哈

作者回复: 感谢老弟提醒，上一个留言，一起回复了哈~

作者回复: 感谢老弟的提醒，原文的描述确实有问题~ 新版本的Kafka确实在Producer级别支持幂等和事务性，结合transactional id + PID + sequence number，能做到跨会话、跨Topic Partition做到幂等。再结合Structured Streaming对于Event time、Late Data和Watermark的支持，以及WAL和Checkpoint机制，理论上，Structured Streaming + Kafka确实可以做到Exactly once。 原文的表述有误，当时脑子里想的是老的Spark Streaming，由于不支持事件时间，仅支持Processing time，而一般的时间窗口，都会有group by这些带状态的计算。因此即便是结合Kafka的幂等性，也很难做到Exactly once的Delivery。 再次感谢老弟，我回头抽空调整下原文的描述，谢谢~