作者：李钰
本文由 Apache Flink PMC , 阿里巴巴高级技术专家李钰分享，主要介绍Apache Flink的前世今生，内容大纲如下：
- 什么是 Apache Flink
- 为什么要学习 Apache Flink
- Apache Flink典型应用场景
- Apache Flink基本概念
一、什么是 Apache Flink
Apache Flink是一个开源的基于流的有状态计算框架。它是分布式地执行的，具备低延迟、高吞吐的优秀性能，并且非常擅长处理有状态的复杂计算逻辑场景。
1.Flink 的起源
Apache Flink是Apache开源软件基金会的一个*项目，和许多Apache*项目一样，如Spark起源于UC伯克利的实验室， Flink也是起源于非常有名的大学的实验室——柏林工业大学实验室。
项目最初的名称为Stratosphere，目标是要让大数据的处理看起来更加地简洁。项目初始的代码贡献者中，有很多今天仍活跃在Apache的项目管理委员会里，在社区里持续做出贡献。
Stratosphere项目于2010年发起，从它的Git commit日志里面可以看到，它的第一行代码是在2010年的12月15日编写的。
2014年5月，Stratosphere项目被贡献到Apache软件基金会，作为孵化器项目进行孵化，并更名为Flink。
2.Flink的发展
Flink项目非常活跃，2014年的8月27号发布了孵化器里的第一个版本v0.6-incubating。
由于Flink项目吸引了非常多贡献者参与，活跃度等方面也都非常优秀，它在2014年12月成为了Apache的*项目。
成为*项目之后，它在一个月之后发布了第一个Release版本Flink 0.8.0。在此之后，Flink基本保持4个月1个版本的节奏，发展到今天。
3.Flink 的现状–Apache社区最活跃的项目
发展至今，Flink已成为Apache社区最活跃的大数据项目。它的用户与开发者邮件列表在2020年的Apache年度报告中排名第一。
如上方右图所示，与非常活跃的Spark项目相比，可以看到用户邮件列表的活跃度，Flink比Spark更高一筹。此外，在开发者代码提交次数与Github的用户访问量中， Flink在Apache所有项目中排名第二，在大数据项目中Flink都是排名第一。
从2019年4月至今，Flink社区发布了5个版本，每一个版本都有更多的 Commit与贡献者。
二、为什么要学习 Apache Flink
1.大数据处理的实时化趋势
随着网络迅速发展，大数据的处理呈现非常明显的实时化趋势。
如上图所示，我们列举了一些现实生活中常见的场景。如春晚的直播有一个实时大屏，双11购物节也有实时成交额的统计和媒体汇报。
城市大脑可以实时监测交通，银行可以实时进行风控监测。当我们打开淘宝、天猫等应用软件时，它都会根据用户不同的习惯进行实时个性化推荐。从以上例子我们可以看到，大数据处理呈现明显的实时化趋势。
2.Flink已成为国内外实时计算事实标准
在实时化的大趋势底下，Flink已成为国内外实时计算事实标准。
如上图所示，目前国内外许多公司都在使用Flink，国际公司有Netflix、eBay，LinkedIn等，国内有阿里巴巴、腾讯、美团、小米、快手等大型互联网公司。
3.流计算引擎的演进
流计算引擎进行了很多代的演进，第一代流计算引擎Apache Storm是一个纯流的设计，延迟非常的低，但是它的问题也比较明显，即没有办法避免消息的重复处理，从而导致数据正确性有一定的问题。
Spark Streaming是第二代流计算引擎，解决了流计算语义正确性的问题，但是它的设计理念是以批为核心，最大的问题是延迟比较高，只能做到10秒级别的延迟，端到端无法实现秒以内的延迟。
Flink是第三代流计算引擎，也是最新一代的流计算引擎。它既可以保证低延迟，同时又可以保证消息的一致性语义，对于内置状态的管理，也极大降低了应用程序的复杂度。
三、Apache Flink 典型应用场景
1.事件驱动型应用
第一类应用场景是事件驱动型应用。
事件驱动表示一个事件会触发另一个或者是很多个后续的事件，然后这一系列事件会形成一些信息，基于这些信息需要做一定的处理。
在社交场景下，以微博为例，当我们点击了一个关注之后，被关注人的粉丝数就会发生变化。之后如果被关注的人发了一条微博，关注他的粉丝也会收到消息通知，这是一个典型的事件驱动。
另外，在网购的场景底下，如用户给商品做评价，这些评价一方面会影响店铺的星级，另外一方面有恶意差评的检测。此外，用户通过点击信息流，也可以看到商品派送或其他状态，这些都可能触发后续的一系列事件。
还有金融反欺诈的场景，诈骗者通过短信诈骗，然后在取款机窃取别人的钱财。在这种场景底下，我们通过摄像头拍摄后，迅速反应识别出来，然后对犯罪的行为进行相应的处理。这也是一个典型的事件驱动型应用。
总结一下，事件驱动型应用是一类具有状态的应用，会根据事件流中的事件触发计算、更新状态或进行外部系统操作。事件驱动型应用常见于实时计算业务中，比如：实时推荐，金融反欺诈，实时规则预警等。
2.数据分析型应用
第二类典型应用场景是数据分析型应用，如双11成交额实时汇总，包括PV、UV的统计。
包括上方图中所示，是Apache开源软件在全世界不同地区的一个下载量，其实也是一个信息的汇总。
还包括一些营销大屏，销量的升降，营销策略的结果进行环比、同比的比较，这些背后都涉及到大量信息实时的分析和聚合，这些都是Flink非常典型的使用场景。
如上图所示，以双11为例，在2020年天猫双11购物节，阿里基于Flink的实时计算平台每秒处理的消息数达到了40亿条，数据体量达到7TB，订单创建数达到58万/秒，计算规模也超过了150万核。
可以看到，这些应用的场景体量很大且对于实时性要求非常高，这也是Apache Flink非常擅长的场景。
3.数据管道型应用 (ETL)
Apache Flink擅长的第三类场景为数据管道型应用，即ETL。
ETL（Extract-Transform-Load）是从数据源抽取/转换/加载/数据至目的端的过程。
传统的ETL使用离线处理，经常做的是小时级别或者天级别的ETL。
但是，随着大数据处理呈现实时化趋势，我们也会有实时数仓的需求，要求在分钟级或者秒级就能够对数据进行更新，从而进行及时的查询，能够看到实时的指标，然后做更实时的判断和分析。
在以上场景底下，Flink能够最大限度地满足实时化的需求。
背后的原因主要有以下几个，一方面Flink有非常丰富的Connector，支持多种数据源和数据Sink，囊括了所有主流的存储系统。另外它也有一些非常通用的内置聚合函数来完成ETL程序的编写，因此ETL类型的应用也是它非常适合的应用场景。
四、Apache Flink基本概念
1.Flink的核心概念
Flink的核心概念主要有四个：Event Streams、State、（Event）Time和Snapshots。
1.1 Event Streams
即事件流，事件流可以是实时的也可以是历史的。Flink是基于流的，但它不止能处理流，也能处理批，而流和批的输入都是事件流，差别在于实时与批量。
1.2 State
Flink擅长处理有状态的计算。通常的复杂业务逻辑都是有状态的，它不仅要处理单一的事件，而且需要记录一系列历史的信息，然后进行计算或者判断。
1.3（Event）Time
最主要处理的问题是数据乱序的时候，一致性如何保证。
1.4 Snapshots
实现了数据的快照、故障的恢复，保证数据一致性和作业的升级迁移等。
2.Flink作业描述和逻辑拓扑
接下来我们来具体的去看一下Flink的作业描述和逻辑拓扑。
如上方所示，代码是一个简单的Flink作业描述。它首先定义了一个Kafka Source，说明数据源是来自于Kafka消息队列，然后解析Kafka里每一条数据。解析完成后，下发的数据我们会按照事件的ID进行KeyBy，每个分组每10秒钟进行一次窗口的聚合。聚合处理完之后，消息会写到自定义的Sink。以上是一个简单的作业描述，这个作业描述会映射到一个直观的逻辑拓扑。
可以看到逻辑拓扑里面有4个称为算子或者是运算的单元，分别是Source、Map、KeyBy/Window/Apply、Sink，我们把逻辑拓扑称为Streaming Dataflow。
3.Flink物理拓扑
逻辑拓扑对应物理拓扑，它的每一个算子都可以并发进行处理，进行负载均衡与处理加速等。
大数据的处理基本上都是分布式的，每一个算子都可以有不同的并发度。有KeyBy关键字的时候，会按照key来对数据进行分组，所以在KeyBy前面的算子处理完之后，数据会进行一个Shuffle并发送到下一个算子里面。上图代表了示例对应的物理拓扑。
4.Flink状态管理和快照
接下来我们看一下Flink里面的状态管理和快照。
在进行Window的聚合逻辑时，每隔10秒会对数据进行聚合函数的处理。这10秒内的数据需要先存储起来，待时间窗口触发时进行处理。这些状态数据会以嵌入式存储的形式存储在本地。这里的嵌入式存储既可以是进程的内存里，也可以是类似RocksDB的持久化KV存储，两者最主要的差别是处理速度与容量。
此外，这些有状态算子的每一个并发都会有一个本地的存储，因此它的状态数据本身可以跟随算子的并发度进行动态的扩缩容，从而可以通过增加并发处理很大的数据量。
另一方面，作业在很多情况下有可能会失败。失败之后重新去运行时，我们如何保证数据的一致性？
Flink基于Chandy-Lamport算法，会把分布式的每一个节点的状态保存到分布式文件系统里面作为Checkpoint（检查点），过程大致如下。首先，从数据源端开始注入Checkpoint Barrier，它是一种比较特殊的消息。
然后它会跟普通的事件一样随着数据流去流动，当Barrier到达算子之后，这个算子会把它当前的本地状态进行快照保存，当Barrier流动到Sink，所有的状态都保存完整了之后，它就形成一个全局的快照。
这样当作业失败之后，就可以通过远程文件系统里面保存的Checkpoint来进行回滚：先把Source回滚到Checkpoint记录的offset，然后把有状态节点当时的状态回滚到对应的时间点，进行重新计算。这样既可以不用从头开始计算，又能保证数据语义的一致性。
5.Flink中的时间定义
Flink里另一个很重要的定义是Event Time。
在Flink里有三种不同的时间，Event Time指事件发生的时间，Ingestion Time指事件到达Flink数据源的时间，或者说进入到Flink处理框架的时间，Processing Time指处理时间，即到达算子当前的时间，这三个之间有什么区别呢？
在现实世界中，这个事件从发生到写入到系统里面，期间的间隔可能比较久。例如在地铁里面信号较弱时，如果我们在微博进行转发、评论、点赞等操作，由于网络的原因，这些操作可能要等我们出了地铁后才能完成，因此可能有些先发生的事件会后到达系统。而Event Time能够更真实地反映事件发生的时间点，因此在很多场景下，我们用Event Time作为事件发生的时间。
但是在这种情况底下，由于存在的延迟，所以在窗口需要花费较长的时间等待它的到来，端到端的延迟可能较大。
我们还需要处理乱序的问题，如果用 Processing Time当做事件时间的话，处理较快，延迟较低，但是无法反映真实事件发生的情况。因此在真实的开发应用时，需要根据应用的特点做相应的取舍。
6.Flink API
Flink可分成4个层次的API，最底层的API是可以自定义的Process Function，对一些最基本的元素，如时间、状态等，进行细节的处理，实现自己的逻辑。
再往上一层是DataStream API，它可以做流和批的处理，另外一方面它是逻辑的表达，有很多Flink内置的函数，方便用户编写程序。
最上层的API是Table API和Stream SQL，这是一个非常上层的表达形式，非常简洁，我们接下来分别举例说明。
6.1 Process Function
可以看到，在processElement里边，能够对这个事件、状态进行自定义逻辑的处理。另外，我们可以注册一个timer，并且自定义当timer被触发或时间到达的时候，到底要进行哪些处理，是一个非常精细的底层控制。
6.2 DataStream API
DataStream API是作业的描述，可以看到它有很多内置的函数，如Map、keyBy、timeWindow、sum等。这里也有一些我们刚才自定义的ProcessFunction，如MyAggregationFunction。
6.3 Table API & Stream SQL
同样的逻辑，如果用Table API和Stream SQL描述的话，它就更加地直观。数据分析人员不需要了解底层的细节，可以用一种描述式的语言去写逻辑。有关Table API和Stream SQL方面的内容，会在第5课进行详细的介绍。
7.Flink运行时架构
Flink运行时的架构主要有三个角色。
第一个是客户端，客户端会提交它的应用程序，如果它是一个SQL程序，还会进行SQL优化器的优化，然后生成对应的JobGraph。客户端会把obGraph提交到JobManager，可以认为这是整个作业的主控节点。
JobManager会拉起一系列的TaskManager作为工作节点，工作节点之间会按照作业拓扑进行串联，还有相应计算逻辑的处理，JobManager主要是进行一些控制流的处理。
8.Flink物理部署
最后我们来看一下Flink能部署哪些环境。
首先，它可以通过手动的方式作业提交到YARN, Mesos以及Standalone集群上。另外，它也可以通过镜像的方式提交到 K8s云原生的环境中。
目前，Flink在许多物理环境中均能进行部署。
最新活动推荐
仅需99元即可体验阿里云基于 Apache Flink 构建的企业级产品-实时计算 Flink 版！点击下方链接了解活动详情：https://www.aliyun.com/product/bigdata/sc?utm_content=g_1000250506