Flink:再爱我一次（再爱我我一次）

大数据生态圈已经发展到拥有明确的技术领导者的地步。在Hadoop上运行的SQL引擎类别中，Hive和Spark显然是开源开发人员中的主导产品。在这些领导者的阴影下，有许多新兴技术，尽管它们在某些用例中可能比领导者有优势，但尚未建立非常大的用户群。

其中包括Impala，Presto，Drill，Flink，Kylin，Tajo和Quasar等产品。你可能没有听说过这些新手，更不用说了解他们打算解决的用例或他们的工作状况如何。这些第二层产品之一Flink当然值得一看（尽管它的名字听起来像间谍电影中的反派）。

Flink最初是在柏林和波茨坦的大学中进行的一项德国研究项目（“ Flink”在德语中的意思是“灵活”），并在2014年成为Apache Incubator项目。像Spark一样，它可以分析批处理和流数据，取代了Hadoop的MapReduce有向图方法的范例，该方法利用内存中的存储来获得巨大的性能提升。

那么，Flink与Spark有何不同？为了解释，让我们看一个常见的用例。假设你正在开发一个物联网（IoT）系统，该系统每两秒钟一次从一组车队中的多个传感器收集数据（例如，温度，压力，行进距离）。你的系统应使用户能够查看统计数据，例如过去一年或过去一周的行进距离和每日平均温度之和。假设你有数百个同时用户，他们期望在几秒钟内获得结果。

一种方法是根据用户要求执行所有计算。这样可以提供到当前秒为止准确的结果，但是要动态执行这些计算将花费许多分钟，并且你的用户将在几秒钟后失去耐心。另一种方法是为所有可能的请求预先计算结果，以便在用户请求时立即提供结果。但是，这些结果将不可避免地是不准确的，因为它们将无法反映自上次对罐装结果进行预先计算以来收到的数据。

Flink架构

为了处理此用例，Nathan Marz定义了一个称为Lambda体系结构的框架，该框架建议与实时数据（例如，今天接收的所有数据）分开分析批处理数据（例如，直到昨天及之前收到的所有数据）。。批处理数据脱机分析，而实时流数据则在到达时不断进行分析。当用户发出查询时，系统会将预先计算的批处理分析和实时分析合并为一个即时结果。这提供了两全其美的优势-快速的响应时间和高达秒的准确性。

Lambda体系结构的严格要求是，批处理分析和流数据分析必须以相同的方式进行计算–否则，将它们组合会产生垃圾。保证等效性的最佳方法是使用完全相同的分析引擎在批处理数据和实时数据上运行完全相同的代码。但是，这需要一个可以同时分析批处理数据和实时数据的分析引擎。

幸运的是，Spark非常合适。Spark最初被设计为分析批处理数据，然后扩展到Spark Streaming，该处理程序通过将实时数据分解为由Spark引擎定期（例如，每分钟一次）的微批处理来处理实时数据。而且，与Storm等其他流分析系统不同，Spark保证每个消息仅被处理一次，这正是我们需要的行为。

如果我们使用Spark解决我们的用例，则必须做出妥协：我们提供的答案直到第二秒之前都是不准确的–直到Spark Streaming处理完最后一个微批处理后，答案才是准确的。最多过一分钟。这被称为高等待时间，即可能要等待很长时间才能处理一条消息。假设我们的用户愿意接受这种微小的时滞误差。现在让我们为用例添加一个新条件。假设我们的车队收到了一些需要立即关注的消息，例如，一辆汽车着火了。你的用户可能不会同意等到处理下一个微批处理（即最多一分钟）后才能收到此警报。因此，由于其高延迟，Spark不再是正确的解决方案。

对于此用例，Flink将是你的最佳选择。像Spark一样，Flink使用相同的计算引擎来处理批处理和流式实时数据，并且它保证每个消息仅被处理一次，因此，这是实现Lambda架构的一个不错的选择。但是，与Spark不同，Flink实时处理流数据，而不是通过微量批处理实时处理流式传输的消息。因此，与Spark不同，Flink支持低延迟，可以提供最新的分析精度。而且，与Spark不同，Flink可以立即发现紧急消息（例如，汽车着火了）并实时触发警报。

Flink还有其他一些使其与Spark区别的功能：

• 积极的优化引擎可以分析提交给集群的代码，并为在该特定设置上运行提供最佳的管道。

• 一个内部内存管理系统，与Java的垃圾收集器分开。通过显式管理内存，Flink群集比Spark群集遭受更少的内存高峰。

• 迭代算法的处理速度更快，其中必须多次分析同一数据，例如，增量迭代仅在自上次迭代以来已更改的那些数据元素上运行

尽管Flink具有所有优势，Spark仍然是重达800磅的大猩猩，具有越来越高的知名度和采用率，并且训练有素的开发人员也更多。但是，正如我们已经看到的那样，对于需要批处理和实时处理且具有低延迟的用例，Flink是一个很好的选择，值得再次考虑。