阿里巴巴资深技术专家莫问在2017年12月20日云起会议北京峰会上做了题为《先进的阿帕奇Flink技术》的主题演讲。Apache Flink作为流计算引擎，支持“双十一对”实时计算，已被国内外公司使用。其中“Flink的技术特点”、“阿里巴巴的Flink版本——Blink”和“Blink在实际场景中的应用”等体验都是首次详细分析，非常有价值。

视频内容组织如下:

Apache Flink介绍

Flink是继Storm之后的第二个纯流量计算引擎，其特点是支持毫秒级延迟和“至少一次”语义保证。目前阿里巴巴的“双十一”支持每秒4亿次计算。

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

底层是有状态分布式流执行引擎。

第二层是核心API，包括数据流/数据集API。数据流API是流的输入，如队列、日志等。数据集API适用于有长度的数据源，比如文件。

第三层提供基于DSL的表格API。该层将所有数据源抽象成表，支持类似SQL的开发语言，可以用Java编写。

第四层是高级SQL语言。

Flink和Storm相比有很多特点。Flink的第一个特点是支持有状态计算。Flink内置状态管理，确保高性能计算和数据的一致性。有了状态，Flink可以提供“恰好一次”的语义。如果业务场景可以接受，也可以支持“至少一次”的语义。状态还支持检查点、恢复、升级、版本等等。

Flink的第二个特性是在流中添加一个窗口。因为流是逐个处理记录的，所以在很多场景下远远不够。因为企业可能需要收集最近的数据进行汇总，并做出全局判断以得出结论。窗口函数很好的解决了这个问题。Flink支持两种类型的窗口。一种是时间驱动的，比如最近30秒或者每30秒取一次数据。一种是数据驱动，比如最后1000个或者每1000个。常见的窗口有三种类型:滑动窗口(无重叠)、翻滚窗口(有重叠)和会话窗口(基于会话)。

使用window后，很难保证所有数据在源端生成的顺序与分布式系统中接收数据的顺序一致，会导致乱序的问题。Flink采用了标准的乱序处理方案——水印技术。这种技术是在源头定期发送水印，保证之前的数据顺利到达。水印到达时，触发窗口计算窗口。有了水印和窗口，就可以根据时间关系在流量计算中进行更复杂的计算。

在Flink中，chandy-lamport算法用于确保状态一致性。该算法的核心思想是定期检查流量，并将计算出的状态保存到存储器中。当系统崩溃时，它会根据状态从最新的检查点恢复，并达到最终的结果。这个过程是在流中插入一个屏障(特殊消息)并在源数据开始广播。当每个节点接收到上游屏障时，它将对齐并保持屏障的状态，然后继续广播屏障。当流将屏障从源节点广播到最后一个节点时，检查点和状态持久性就完成了。

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

Flink典型的工作场景是处理实时数据。源是kafka队列，其中包含所有实时数据流。Flink有三个操作员角色，其中数据流是单独操作的。第一个是Source(负责输入数据，在kafka中记录偏移量并持久化)；第二个是中间的运算符是operator，一个是做map，一个是根据同一个键聚合，生成counter。和offsetcounter将存储在状态中。第三个是sink，负责输出和快照。

阿里巴巴对Flink的贡献

Blink(阿里巴巴Flink版本)是依托阿里巴巴的量产环境和实际需求，对Flink架构进行改进，扩展更多功能的版本。Blink完全兼容Flink的API，并与开源社区无缝对接。目前，Blink团队已经与Flink社区分享了300多个问题，并对一些关键架构和SQL进行了改进。团队培养了5名在社区有良好影响力的弗林克委员。Blink团队连续两年赞助Flink forward大会，每次都是现场分享。

Blink在Flink的基础上进行了五大改造:

1.转换Flink部署和流程模型

Flink以前是独立的部署架构，流程模型和分布式模型都比较小。Blink team按照分布式进程模型的调度也使其能够继续在Yarn和Mesos上运行，解耦其计算和资源调度，改善了规模有限的Flink单主的架构。

2.使用异步I/O模型进行设计

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

3.完善检查点机制

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

4.故障转移的优化

在大规模场景下，实时计算会有成千上万个并发作业，所以一旦发生故障转移，恢复的代价会很大。Blink改进了它。

5.网络层的优化

在流式计算中，网络层的性能非常关键。上行和下行计算都需要网络层洗牌。Blink优化了shuffle的性能，大大提高了网络性能。

阿里巴巴在Flink的SQL上也做出了不少贡献，用流SQL代替了传统的bash SQL。

Flink在阿里巴巴的应用

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

Flink在淘宝的应用案例:

天猫双11成交额实时统计

大家对“双十一”的成交量印象深刻，是实时计算出来的。这个过程包括用户下单、后台发送日志、读取日志、汇总计算、统计和输出结果等。要保证它的正确性，一整天都不能有抖动。在这个过程中，峰值运算次数为每秒4亿次，这也是Flink目前最大的应用场景。

作为一家数据驱动的公司，需要实时监控所有数据。实时计算平台会对这些数据进行处理，呈现给运营商和管理层，让他们根据这些数据做出决策。

淘宝搜索商品实时更新

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