1.5.3 Spark还是Flink

通过前面的分析可以看出，Spark和Flink目前各有所长，在批处理领域，Spark具有优势；而在流处理方面，Flink当仁不让。具体到项目应用中，不仅要看是流处理还是批处理，还需要在延迟、吞吐量、可靠性，以及开发容易度等多个方面进行权衡。

如果在工作中需要从Spark和Flink这两个主流框架中选择一个进行实时流处理，我们更加推荐使用Flink，主要原因如下。

• Flink的延迟是毫秒级别的，而Spark Streaming的延迟是秒级的。

• Flink提供了严格的精确一次（exactly-once）性语义保证。

• Flink的窗口API更加灵活、语义更丰富。

• Flink提供事件时间语义，可以正确处理延迟数据。

• Flink提供了更加灵活的对状态编程的API。

基于以上特点，使用Flink可以解放程序员，提高编程效率，把本来需要程序员费时费力手动完成的工作交给框架去完成。

当然，在海量数据的批处理方面，Spark还是具有明显的优势的，而且Spark的生态更加成熟，也会使其在应用中更为方便。相信随着Flink的快速发展和完善，这方面的差距会越来越小。

另外，Spark 2.0之后新增的Structured Streaming流处理引擎借鉴DataFlow进行了大量优化，同样做到了低延迟、时间正确性及精确一次性语义保证；Spark 2.3以后引入的连续处理（Continuous Processing）模式更是可以在至少一次语义保证下做到1ms的延迟。Flink自1.9版本合并Blink以来，在SQL的表达和批处理的能力上同样有了长足的进步。

那如果现在要学习一门框架的话，优先选择Spark还是Flink呢？其实可以看到，不同的框架各有利弊，它们也在互相借鉴、取长补短、不断发展，至于未来是Spark还是Flink，甚至是其他新崛起的处理引擎“一统江湖”，都是有可能的。作为技术人员，我们应该对不同的架构和思想都有所了解，只有跳出某个框架的限制，才能看到更广阔的世界。