阿里腾讯华为都在追捧的新一代大数据引擎Flink到底有多牛？

时间就是金钱。流式实时计算能为用户争取到更多的时间，未来需求会越来越大。Apache Flink是一个集流式批量于一体的大数据处理引擎，它具有高吞吐量和低延迟的性能，有很强容错性，非常适合各类对时间敏感的应用，如金融交易、风险控制、故障检测、电商促销等场景。传统的大数据处理引擎无法胜任类似实时计算的工作。

提起大数据处理引擎，很多人会想到Hadoop或Spark，而在2019年，如果你身处大数据行业却没听说过Flink，那你很可能OUT了！Flink是大数据界冉冉升起的新星，是继Hadoop和Spark之后的新一代大数据处理引擎。2019年初，阿里巴巴以1.033亿美元的价格收购了总部位于德国柏林的初创公司Data Artisans，Data Artisans的核心产品正是Flink。

Flink初是由德国几所大学发起的的学术项目，后来不断发展壮大，并于2014年末成为Apache项目。如果你对MapReduce比较熟悉的话，那么Flink就是流式计算界的MapReduce。

Flink技术不仅受到阿里巴巴的重视，更是被各大互联网公司所采用。Flink技术正在被快速应用到全世界的各大巨头公司：阿里、腾讯、华为、网易、滴滴等等。一个手握栗子的小松鼠突然风靡全球，成为各大公司追捧的下一代大数据处理引擎。也许，此时此刻正是这个小松鼠的计算工作，帮你从网络的海量信息中筛选出这篇文章，呈现到你的屏幕上。那么Flink到底是什么，它为何突然被如此多的大公司青睐，成为新一代大数据处理引擎？

本文将简单介绍什么是批量和流式计算，为何需要选择一个可靠的流式计算平台，以及Flink为何能在各大开源项目中脱颖而出。

为什么需要流式计算? 批量 v.s. 流式

在详细介绍Flink前，需要给未接触这个领域的朋友简单普及一下批量计算与流式计算的概念。

批量

批量（batch），顾名思义，就是对一批数据进行计算。我们身边批量计算比比皆是，简单的批量计算例子有：微信运动每天晚上有一个批量任务，把用户好友一天所走的步数统计一遍，给出一个排序结果，推送给用户；银行信用卡中心每月账单日有一个批量任务，把一个月的消费总额统计一次，出一份月度账单，发送给用户；国家统计局每季度对经济数据做一次统计，公布季度GDP增速。可见，批量任务一般是对一段时间的数据聚合后进行处理。对于数据量庞大的应用，如微信运动、银行信用卡等情景，一段时间的数据总量非常大，计算非常耗时。

批量计算的历史可以追溯的计算机刚刚起步的上世纪60年代，当前应用为广泛的当属数据仓库的ETL（Extract Transform Load）数据转化工作，如以Oracle为代表的商业数据仓库和以Hadoop/Spark为代表的开源数据仓库。

流式

然而，数据其实是以流（Stream）的方式源源不断地产生的。我们每时每刻的运动数据都会不断累积到手机传感器上，金融交易随时随地发生，用户无时无刻不在使用手机APP并产生用户行为，微观和宏观的经济行为一直在发生。个人用户每晚看一次微信运动排名觉得是一个比较舒适的节奏，但是对于商界来说，时间就是金钱，而且是以百万、千万甚至上亿为单位的金钱！获取实时的信息非常有必要，比如：双十一电商大促销，管理者要以秒级的响应时间查看其实时销售业绩、库存信息以及与竞品的对比结果，以争取更多的决策时间和空间；股票交易要以毫秒级的速度来根据新信息做出响应；风险控制要对每一份欺诈交易迅速做出处理，以减少不必要的损失；网络运营商要以极快速度发现网络和数据中心的故障等等。以上这些场景，一旦出现故障，造成了服务的延迟，损失都难以估量，因此，响应速度越快，越能减少损失，增加收入。而IoT物联网和5G通信的兴起将为数据生成提供更完美的底层技术基础，海量的数据在IoT设备上采集生成，并通过更高速的5G通道传输到服务器，更庞大的实时数据流将汹涌而至，实时处理的需求肯定会爆炸式增长。

为什么需要一个可靠的流式计算引擎？

处理实时流的平台通常被称为流式计算平台或实时计算平台。我们使用使用下面这个例子来解释为何要使用一个可靠的流式计算引擎。

业务场景：股票交易

我们都知道股票交易是非常依赖各类信息的。Flink官方网站在2015年提供了一个将各股票价格与Twitter上实时微博做相关分析的案例。在特朗普当政的今天看来，构建这样一个系统非常有必要，他在Twitter的上发表关于贸易战的一段话，有可能让全世界股市发生激烈的震荡。作为人类的我们不可能24小时一直盯着特朗普的Twitter，如果有一个自动化的系统来做一些分析和预警，将为决策者争取到更多时间。

假设我们有数支股票交易数据流，我们可以通过这个数据流来计算以10秒为一个时间窗口的股票价格波动，选出那些超过5%变化幅度的股票，并将这些股票与Twitter的实时文本数据做相关分析，以判断Twitter哪些上的讨论会影响股票价格。当相关分析的结果足够有说服力时，可以将这个系统部署到生产环境，实时处理股票与Twitter数据，产生分析报表，发送给股票交易人员。那么，如何构建一个可靠的程序来解决上述业务场景问题呢？

生产者消费者模型

处理流式数据的一般使用“生产者-消费者（Producer-Consumer）”模型来解决问题。一个或多个生产者生成数据，将数据发送到一个缓存区域，一个或多个消费者从缓存区域中消费数据。这里我们暂且不关心生产者如何生产数据，以及数据缓存，我们只关心如何实现消费者。

问题

在实现消费者时，我们可以启动一个进程，以10秒为一个窗口，统计该窗口内数据流内的交易情况，找到波动大的那些股票。同时，程序也对新进入的Twitter文本进行分析。这个逻辑看起来很容易实现，但深挖之后会发现问题繁多。

可扩展性

编写在一个计算节点上的程序应该还算容易。但是我们知道Twitter数据量非常大，平均每秒有上千条，每天有几亿条，一般情况下单个计算机节点无法处理这样的数据规模。这时候需要多节点并行处理，如何将数据切分成多份，打到多个节点上？每个节点上只处理一部分数据，我们并不知道哪条交易和哪些微博被切分到哪个节点上，每个节点只是整个宏观交易的一个部分视角，无法获得宏观视角，但是老板只关心总数，是不是还要跨节点聚合，把每个节点的数据合并到一起？一旦数据量增大，事情就开始变得复杂。

容错性

假如特朗普发布一条加增关税的Twitter，引发某一时刻非常激烈的讨论，数据突增，程序跑挂了。重启程序后，之前的那些计算如何恢复？如果程序仅适用单节点做处理，除了可处理的数据吞吐量小，还存在单点风险，一旦单节点失败，将影响整个业务。如果程序使用多节点做处理，你需要一个机制来做失败恢复。

事件时序错乱

限于网络条件和其他各种潜在影响因素，数据流中的时间并非百分百按照本来发生的时间抵达消费者。比如，你想统计上午11:00:00到11:00:10的交易情况，然而发生在11:00:05的某项交易因网络延迟没能抵达，这时候是直接放弃掉这条交易？绝大多数情况我们会让程序等待，比如我们会假设数据晚不会延迟超过10分钟，因此程序会等待10分钟。实现等待也还能接受，但是如果有多个节点在并行处理呢？每个节点等待一段时间，后聚合的节点还要等待更长时间。

Apache Flink

Apache Flink专门为解决上述问题而生，如果用Flink去解决前面所提到的股票建模，只需要设置时间窗口，并在这个时间窗口下做一些数据处理的操作，并且可以根据数据量来设置由多少节点来并行处理。感兴趣的朋友可以在Flink的官方网站中阅读该案例的代码。

使用Flink计算股票波动问题：https://flink.apache.org/news/2015/02/09/streaming-example.html

Flink不仅提供了大量简单易用的API，更是以高数据吞吐量和低处理延迟的特性远胜其他大数据处理引擎，而且Flink可以适应多节点并行的场景，有很强的可扩展性和容错性。

在Flink之前，不乏流式处理引擎，比较的有Storm、Spark Streaming，但某些特性远不如Flink。

代被广泛采用的流式计算引擎是Strom。它是以数据流中的事件（Event）为小单位来进行计算的，在这点上它与Flink一致。以事件为单位的框架的优势是延迟非常低。由于一些其他地方的实现不同，在多项基准测试中，Storm的数据吞吐量和延迟都远逊于Flink。Storm只支持"at least once"和"at most once"，即数据流里的事件投递只能保证至少一次或至多一次，不能保证只有一次。对于很多对数据准确性要求较高的应用，Storm有一定劣势。此外，Storm不支持SQL，不支持中间状态State。

第二代非常流行的流式计算引擎是Spark Streaming。Spark是一统江湖的批量大数据处理引擎，为了适应流式计算的场景，Spark的子项目Spark Streaming使用mini-batch的思想，每次处理一小批数据，一小批数据包含多个事件，以接近实时处理的效果。因为它每次计算一小批数据，因此总有一些延迟。但Spark Streaming的优势是拥有Spark这个靠山，用户从Spark迁移到Spark Streaming的成本较低，因此能给用户提供一个流式和批量二位一体的计算引擎。

Flink是与上述两代框架都不太一样的新一代计算引擎。按照Flink新的官方解释，它是一个支持在有界和无界数据流上做有状态计算的大数据引擎。它也是以事件为单位，并且支持SQL、State、WaterMark等特性。它支持"exactly once"，即事件投递保证只有一次，不多也不少，这样数据的准确性能得到提升。比起Storm，它的吞吐量更高，延迟更低，准确性能得到保障；比起Spark Streaming，它以事件为单位，达到真正意义上的实时计算，且所需计算资源相对更少。

之前提到，数据都是以流的形式产生的。数据可以分为有界（bounded）和无界（unbounded），批量处理其实就是一个有界的数据流，是流处理的一个特例。Flink因此也是一个可支持流式和批量计算的大数据引擎。

Flink是一个分布式系统，可以利用上千个节点的上万个CPU核心，可以部署在Yarn、Mesos以及Kubernetes等资源调度平台上。Flink在计算过程中记录了状态，并将这些状态数据定时以checkpoint的形式做了备份，这样即使程序失败，重启后还能快速恢复到失败时间点上。

经过几年的发展，Flink的API已经非常完善，可以支持Java、Scala和Python，并且支持SQL。Flink的Scala版API与Spark很像，有Spark经验的程序员可以用一个小时的时间熟悉Flink API。Flink底层是有状态流式处理引擎，DataStream主要针对有界和无界流，DataSet主要针对有界数据集，Table API提供了类似关系型数据库的编程接口，用户也可以直接使用SQL来调用Flink。

此外，Flink也在入局机器学习和图计算，并试图把自己打造成一个一站式大数据与人工智能引擎。

小结

时间就是金钱。流式实时计算能为用户争取到更多的时间，未来需求会越来越大。Apache Flink是一个集流式批量于一体的大数据处理引擎，它具有高吞吐量和低延迟的性能，有很强容错性，非常适合各类对时间敏感的应用，如金融交易、风险控制、故障检测、电商促销等场景。传统的大数据处理引擎无法胜任类似实时计算的工作。