阿里巴巴资深技术专家莫问在2017年12月20日云栖大会北京峰会上做了题为“Apache Flink技术进阶”的主题演讲。Apache Flink作为流式计算引擎，支持了“双十一对的”实时计算，已经被国内外的公司使用。其中关于“Flink的技术特点”、“阿里巴巴的Flink版本——Blink”以及“Blink在实际场景中的应用” 等经验首次对外详细剖析，很有价值。

以下为视频内容整理：

Apache Flink介绍

Flink是Storm之后出现的第二个纯流式计算引擎，其特点是支持毫秒级的延迟，同时支持 “至少一次”语义的保证。目前在阿里巴巴的“双十一”上面支持了每秒四亿次的计算。

Flink提供了不同的抽象级别来开发流/批处理应用程序:

1. 最下面一层是有状态的分布式流式执行引擎。

2. 第二层是core APIs，包括DataStream/DataSet API。DataStream API是针对流式的输入，比如队列、日志等；DataSet API是针对有长度的数据源，比如一个文件。

3. 第三层提供了基于DSL的table API。这层把所有的数据源都抽象成table，支持类SQL的开发语言，可以用Java来编写。

4. 第四层是高级SQL语言。

   Flink相对于Storm来说有许多特性。Flink第一个特性是支持有状态的计算。 Flink内置了状态管理，可以保证高性能计算和数据的一致性。有了状态之后，Flink就可以提供“恰好一次”语义。如果业务场景接受，也可以支持“至少一次”语义。state也支持checkpoint，recovery，Upgrade，version等。

Flink的第二个特性就是在流里面加window。因为流是一条一条来处理记录，但是在很多场景上是远远不够的。因为业务可能需要把最近一段时间的数据攒起来做一次聚合，并做全局性的判断才能得到结论。window功能很好的解决了这个问题。Flink支持两种类型的window。一种是时间驱动，比如最近30秒或者每隔30秒取一次数据。一种是数据驱动，比如最近1000条或者是每隔1000条取一次。常见的Window有三种类型：Sliding window（没有重叠），Tumbling window(有重叠)，Session window（基于session）

使用window之后，在分布式系统中就很难保证所有的数据在源头产生数据的顺序和接收数据的顺序保持一致，会出现乱序的问题。Flink采用了标准的乱序处理方案——watermark技术。这个技术是在源头定期发送watermark，保证之前的数据顺利到达。watermark到达之后就触发window，进行window的计算。有了watermark和window，可以在流计算里面根据时序关系，实施更为复杂的计算。

Flink中保证状态一致性是使用的chandy-lamport算法，这个算法核心的思想就是：定期对流进行检查，并将计算状态持久化到存储里面。当系统奔溃的时候，会从最近一次检查点中根据状态来恢复，达到最终的结果。这个过程是在流里面插入一个barrier（特殊消息），并在源数据处开始广播，每个节点收到上游的barrier，会对barrier对齐并对做状态持久化，然后将barrier继续往下广播。当流把barrier从源头广播到最后节点的时候，就完成了checkpoint和状态持久化。

同步执行checkpoint会阻碍流的计算，所以采用异步checkpoint，这样也加快了checkpoint的对齐。对checkpoint的增量做持久化，就会减少对I/O的使用。由于 Storm 会对每条消息进行ACK，Flink 是基于一批消息做的检查点，这样可以保证对数据有一个更好的吞吐和更好的时延。这也是Flink和Storm最大的区别。

Flink的典型作业场景是处理实时数据。源头是一个kafka队列，包含所有的实时的数据流。Flink有三种算子角色，数据流分别在这三种算子中进行运算。第一种是Source（负责输入数据，记录kafka里面的offset并做持久化）；第二个就是中间的算子就是operator，一是就做map，二是根据同key做聚合，并产生counter。Offset和counter会存储到状态里面。第三个是sink，是负责输出并做快照。

阿里巴巴对Flink的贡献

Blink（alibaba Flink version）是依托阿里巴巴大规模生产环境和实际需求对Flink架构进行多项改进以及更多的扩展功能的版本。Blink全面兼容Flink的API与开源社区无缝对接。Blink团队目前向Flink社区共享了超过300个issue，对多项关键架构和SQL改进。团队培养出了5名在社区具备良好影响力的Flink committer。Blink团队连续两年赞助Flink forward大会，并且每次都会在现场分享。

Blink基于Flink进行了5个重大改造：

1. 对Flink部署和进程模型的改造

以前Flink是一个Standalone部署的架构，它的进程模型和分布式模型比较小。Blink团队按照分布式进程模型的调度，也使其能继续在Yarn和Mesos上面运行，对其计算和资源的调度进行了解耦，改进了Flink单master规模受限的架构。

2. 采用异步的I/O模型设计

在流式计算过程中，如果一个流被卡住，那么整个流式计算就会被卡住，这是分布式、高并发场景中的障碍。引入异步I/O的模型，使得所有Flink的算子，都可以异步访问外部的MySQL。短暂的抖动，也不会影响整个流的运行，可以大幅提升CPU的利用率。

3. 改善checkpoint机制

因为checkpoint是Flink的最大的一个特点，所以checkpoint的性能尤为关键。如果它的做的不好，就会影响主流程的处理。虽然数据规模非常大，但是每分钟更新的数据只有百分之一，做增量checkpoint，会大大减少开销。

4. failover的优化

在大规模场景下，实时计算的一个作业会有上千个并发，所以一旦failover，恢复需要很大成本。Blink对其做了改善。

5. 在网络层的优化

在流式计算中，网络层的性能非常关键。上下流的计算，都需要网络层去shuffle。Blink优化了shuffle的性能，使网络性能大大提升。

阿里巴巴对Flink的SQL也做了很多的贡献，使用的是流式SQL，不是传统的bash SQL。

Flink在阿里巴巴的应用

Flink流式计算架构几乎支持了阿里巴巴的所有场景，包括天猫，淘宝，飞猪，菜鸟，搜索广告，安全等等。

Flink在淘宝中的应用案例：

天猫双11成交额实时统计

大家对“双十一”的成交量印象深刻，这个成交量就是通过实时计算出来的。这个流程包括用户下单、将日志传到后台、读取日志、聚合计算、统计并输出结果等。为保证其正确性，在全天不能有任何的抖动。这个过程中每秒钟进行峰值为四亿次的运算，也是Flink目前最大的应用场景。

作为一家数据驱动的公司，需要实时监测所有的数据。实时计算平台会处理这些数据，并呈现给运营人员和管理层，方便他们基于这些数据去做决策。

淘宝搜索商品实时更新

淘宝会根据用户的搜索进行推荐。搜索引擎和推荐引擎的数据需要实时的更新。任何一次商品的变化和商家的变化，都会同步到数据的仓库里面。根据商家信息，类目信息，促销信息等，做联合并产生索引，生成到推荐引擎或者搜索引擎里面，进而生成推荐和搜索结果，并在用户的搜索页面上显示。任何一次商品、卖家、促销信息，用户行为的变化，都会影响到搜索的结果和展示，整个信息流的实时变化量非常大。