阿里巴巴资深技术专家莫问在 2017 年 12 月 20 日云栖大会北京峰会上做了题为 "Apache Flink 技术进阶" 的主题演讲。Apache Flink 作为流式计算引擎,支持了 "双十一对的" 实时计算,已经被国内外的公司使用。其中关于 "Flink 的技术特点"、"阿里巴巴的 Flink 版本——Blink" 以及 "Blink 在实际场景中的应用" 等经验首次对外详细剖析,很有价值。
以下为视频内容整理:
Apache Flink 介绍Flink 是 Storm 之后出现的第二个纯流式计算引擎,其特点是支持毫秒级的延迟,同时支持 "至少一次" 语义的保证。目前在阿里巴巴的 "双十一" 上面支持了每秒四亿次的计算。
Flink 提供了不同的抽象级别来开发流 / 批处理应用程序:
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 在淘宝中的应用案例:
天猫双 11 成交额实时统计大家对 "双十一" 的成交量印象深刻,这个成交量就是通过实时计算出来的。这个流程包括用户下单、将日志传到后台、读取日志、聚合计算、统计并输出结果等。为保证其正确性,在全天不能有任何的抖动。这个过程中每秒钟进行峰值为四亿次的运算,也是 Flink 目前最大的应用场景。
作为一家数据驱动的公司,需要实时监测所有的数据。实时计算平台会处理这些数据,并呈现给运营人员和管理层,方便他们基于这些数据去做决策。
淘宝搜索商品实时更新淘宝会根据用户的搜索进行推荐。搜索引擎和推荐引擎的数据需要实时的更新。任何一次商品的变化和商家的变化,都会同步到数据的仓库里面。根据商家信息,类目信息,促销信息等,做联合并产生索引,生成到推荐引擎或者搜索引擎里面,进而生成推荐和搜索结果,并在用户的搜索页面上显示。任何一次商品、卖家、促销信息,用户行为的变化,都会影响到搜索的结果和展示,整个信息流的实时变化量非常大。
来源: https://yq.aliyun.com/articles/326161