作者：王峰（莫问）、梅源
剩喜漫天飞玉蝶，不嫌幽谷阻黄莺。2020 年是不寻常的一年，Flink 也在这一年迎来了新纪元。
12 月 13 – 15 号，2020 Flink Forward Asia（FFA）在春雪的号召下顺利拉开帷幕。Flink Forward Asia 是由 Apache 官网受权，Apache Flink Community China 反对举办的会议。通过两年的一直降级和欠缺，Flink Forward Asia 已成为国内最大的 Apache 顶级我的项目会议，是 Flink 开发者和使用者的年度盛会！往年因为疫情的起因，Flink Forward Asia 首次采纳线上线下双线同步会议的模式，吸引了更多的参会者观看探讨，三天理论总参加人数（UV）超过 9.2 万，单日最高观看人数（UV）超过 4 万。
FFA 大会从社区倒退，业内影响力和 Flink 引擎生态这三方面总结了 Flink 过来一年内的问题。
社区方面，如上图所示，依据 Apache 基金会财年报告颁布的各项外围指标显示，Flink 在 2020 年蝉联 Apache 社区最沉闷的我的项目。不仅如此，Flink Github 的星数（代表我的项目受欢迎水平）和 Flink 的社区代码贡献者（contributor）数量在过来数年中始终放弃年均 30%+ 的增长。尤其值得一提的是 Flink 中文社区的凋敝倒退：Flink 是以后 Apache 顶级我的项目中惟一一个开明了中文邮件列表（user-zh@flink.apache.org）的我的项目，且中文邮件列表的活跃度已超过英文邮件列表；Flink 的官网公众号订阅数超过 3 万人，全年推送超过 200 篇和 Flink 技术，生态以及实际相干的最新资讯。此外，Flink 官网中文学习网站也曾经正式开明：https://flink-learning.org.cn/，收纳了和 Flink 相干的学习材料，场景案例以及流动信息，心愿能对 Flink 感兴趣的同学有所助益。
在业界影响力方面，通过几年的倒退，Flink 曾经成为事实上的国内外实时计算行业标准，大部分支流科技公司均已采纳 Flink 作为实时计算的技术计划。本届 Flink Forward Asia 邀请到 40 多家一线国内外公司参加分享 Flink 的技术摸索和实践经验，上图列出了其中局部公司的 Logo。从图中的 Logo 来看，Flink 技术曾经利用到各行各业，深刻到咱们的日常点滴生存中，从常识分享到在线教育；从金融服务到理财投资；从长短视频到在线直播；从实时举荐搜寻到电商服务等等。
从 Flink 引擎生态来看，2020 年，Flink 在流计算引擎内核，流批一体，拥抱 AI，云原生这四个主打方向上都获得了不错的问题。特地对于流批一体，往年公布的三个大版本（Flink-1.10 & 1.11 & 1.12）对流批一体进一步作了降级和欠缺，并首次在阿里巴巴双十一最外围的天猫营销流动剖析大屏场景中落地 [1]。经验过双十一洗礼的流批一体将成为在业界大规模推广的终点，创始流批一体新纪元！
本文将对 Keynote 议题作一些简略的演绎总结，抛砖引玉，感兴趣的小伙伴们能够在官网找到相干主题视频观看直播回放。
主会场议题
在主议题之前有两个环节值得提一提。一是阿里巴巴团体副总裁，阿里云智能计算平台负责人，人工智能计算框架 Caffe 之父贾扬清老师作为收场嘉宾，分享了他对开源与云的思考。他指出，开源让云更标准化，而大数据和人工智能一体化则是必然趋势。不言而喻地，作为顶级开源我的项目和实时计算规范的 Flink 在这个过程中承当极其重要的角色。同时他也对 Flink 如何在将来做到计算普惠化和数据智能化提出更多期待，让 Flink 的小松果在各行各业的数据和智能交融中生根发芽！二是由阿里云天池平台和 Intel 联结举办的第二届 Apache Flink 极客挑战赛颁奖典礼。此次挑战赛聚焦防疫主题，在 Apache Flink 平台上反对深度学习利用，吸引了来自 14 个国家和地区，705 所高校，1327 家企业的 3840 位选手，由扬清，李文和湘雯颁奖。
言归正传，上面聊聊几个主议题。
Flink as a Unified Engine –– Now and Next
主议题由 Apache Flink 中文社区发起人，阿里云智能实时计算和开放平台负责人莫问老师开启，次要介绍 Flink 社区在 2020 年获得的成绩以及将来的倒退方向，次要包含：流计算引擎内核，流批一体，Flink + AI 交融，云原生这四个方向。值得一题的是，他还特地分享了阿里巴巴作为 Flink 最大的使用者和推动者，在流批一体双十一外围业务场景落地的过程中的教训和心得，置信对很多有相似需要的小伙伴们会有启发。
技术创新是开源我的项目继续倒退的外围， 所以首先第一个局部是 Flink 社区在流计算引擎内核方面的翻新分享 ：
1）Unaligned Checkpoint
咱们晓得 Flink 的一个最外围的局部是通过分布式全局轻量快照算法 [2, vldb17] 做 checkpoint 来保障强一致性 exactly once 语义。这个算法通过 task 之间 barrier 的传递使得每一个 task 只须要对本人的状态进行快照；当 barrier 最终达到 sink 的时候，咱们就会失去一个残缺的全局快照（checkpoint）。但在数据反压的状况下，barrier 无奈流到 sink，会造成 checkpoint 始终无奈实现。Unaligned Checkpoint 解决了反压状态下，checkpoint 无奈实现的问题。在 unaligned checkpoint 的模式下，Flink 能够对每个 task 的 channel state 和 output buffer 也进行快照，这样 barrier 能够疾速传递到 sink，使得 checkpoint 不受反压影响。Unaligned checkpoint 和 aligned checkpoint（现有的 checkpoint 模式）能够通过 alignment timeout 主动智能的切换，下图给出了示意图。
2）Approximate Failover –– 更加灵便的容错模式
流计算内核引擎局部的另一个晋升是 Approximate 单点 Failover。在强一致性 exactly once 语义下，单个节点的失败会导致全副节点的重新启动和回滚。但对某些场景，特地是 AI 训练的场景，其实对语义一致性的要求并没有那么高，反而对于可用性要求更高，所以社区引入了 Approximate Failover 的模式：单个节点的失败只会引起该失败节点的重启和复原，而整个数据流程是没有中断的。Approximate Failover 在 AI 训练和举荐场景下是强需要，快手和字节跳动的分享中都有提到。
3）Nexmark –– Streaming Benchmark
目前的实时流计算并没有行业内公认的 benchmark，为了填补这项空白，基于 NEXMark[3]，Flink 推出了第一版蕴含 16 个 SQL Query 的 benchmark 工具 Nexmark。Nexmark 一大特点是不便易用，没有内部零碎依赖, 同时反对规范的 ANSI SQL。Nexmark 目前业已开源：https://github.com/nexmark/ne…，能够用来比对不同流计算引擎之间的差别。
第二个重要的局部是流批一体 ，结尾提到 2020 年是流批一体的新纪元，为什么这么说呢，莫问老师从流批一体架构演进，Flink 批处理性能，以及业界流批一体数据生态这三个方面给出了答案。
1）流批一体架构演进
Flink-1.10 & 1.11 两个大版本实现了 SQL & Table 层的流批一体化和解决生产可用性问题；刚刚发版的 Flink-1.12 解决了 DataStream 层的流批一体化；从 1.13 版本开始，Flink 将逐渐淘汰 DataSet 这套 API。在全新的流批一体架构中，Flink 实现了对立的流批表白，对立的流批执行，以及对立可插拔的 runtime 反对。分会场中的《基于 Flink DataStream API 的流批一体解决》有对这个局部更为具体的介绍。
2）Batch 性能
大家比较关心的批的性能：通过三个版本的迭代，以 TPC-DS 为基准，Flink-1.12 比 Flink-1.9（去年的版本）提速 3 倍！数据量 10TB，20 台 64Core 机器的配置下，TPC-DS 运行工夫收敛到万秒以内。这意味着 Flink Batch 的性能曾经不亚于任何一个业界支流的 Batch 引擎了。
3）流批一体数据生态
莫问老师指出，流批一体不仅仅只是一个技术问题，它也对业界数据生态的演变也起到了深远的作用，比拟典型的场景包含数据同步集成（数据库里的数据同步到数仓中）和基于 Flink 流批一体的数仓架构 / 数据湖架构。传统的数据同步集成采纳全量增量定时合并的模式，而 Flink 流批一体混合 connector 能够实现全量增量一体化数据集成（读取数据库全量数据后，能够主动切换到增量模式，通过 CDC 读取 binlog 进行增量同步），全量和增量之间无缝主动切换，如下图所示。
传统的数仓架构别离保护一套实时数仓和离线数仓链路，这样会造成开发流程冗余（实时离线两套开发流程），数据链路冗余（两遍对数据的荡涤补齐过滤），数据口径不统一（实时和离线计算结果不统一）等问题。而 Flink 的流批一体数仓架构将实时离线链路合二为一，能够齐全的解决上述这三个问题。不仅于此，Flink 的流批一体架构和数据湖所要解决的问题（流批一体存储问题）也完满符合。当初比拟支流的数据湖解决方案 Iceberg，Hudi 和 Flink 都有集成。其中，Flink + Iceberg 已有残缺的集成计划；而 Flink + Hudi 的整合也在踊跃对接中。
第三个大的方向是与 AI 的交融。莫问老师从语言层，算法层和大数据与 AI 一体化流程治理这三个方面总结了 2020 年 Flink 在 AI 交融方面的停顿。从语言层来讲，Flink 对 AI 的支流开发语言 Python 的反对 PyFlink 逐渐走向成熟：Flink 的 DataStream API 和 Table API 都已 Python 化，用户能够用纯 Python 语言开发 Flink 程序；Flink SQL 中反对 Python UDF/UDTF；PyFlink 集成了罕用的 Python 类库如 Pandas，在 PyFlink 中能够间接调用 Pandas UDF/UDAF。从算法层面来看，去年开源的：Alink https://github.com/alibaba/alink（基于 Flink 的流批一体的传统机器学习算法库）新增了数十个开源算法，提供基于参数服务器的大规模分布式训练，训练过程与预测服务的连接更加顺畅。
大数据与 AI 一体化流程治理也是一个很值得深入探讨的问题，其背地的实质问题是在离线学习实时化的大背景下，如何设计离线在线机器学习一体化的流程治理架构，以及该架构如何与大数据工作流程相结合，实现大数据与机器学习全链路一体化的问题。这套残缺的解决方案 Flink AI Extended 不仅反对深度学习引擎和 Flink 计算引擎的集成（TensorFlow / PyTorch on Flink），它的工作流（Flink AI Flow）也利用了上述的一体化设计思维。目前 Flink AI Extended 也曾经开源：https://github.com/alibaba/fl…。此外，在分会场议题中有对 Flink AI Extended 更具体的探讨和全流程 demo《基于 Flink 的在线机器学习零碎架构探讨》，感兴趣的同学能够找来看看并试用一下。
此外还有一个重要的方向是 Flink 与云原生生态 Kubernetes 的深度交融。Kubernetes 目前广泛应用在各种在线业务上，其生态自身倒退也很快，能够给 Flink 在生产中提供更好的运维能力。从 Flink-1.10 版本开始，Flink 通过三个版本的迭代，到 Flink-1.12，Flink 曾经能够原生地运行在 Kubernetes 之上，对接 K8S 的 HA 计划，并不再依赖 ZooKeeper，达到生产可用级别。同时，Flink 的 JobManager 能够和 K8S Master 间接通信，实现动静扩缩容，并反对对 GPU 的资源调度。
接下来，莫问老师分享了 Flink 在阿里巴巴（Flink 最大的使用者和推动者）的前世，今生和将来。2016 年，Flink 在双十一搜寻举荐场景中首次亮相，并用 Flink 实现搜寻举荐和在线学习全链路实时化。2017 年，Flink 成为阿里巴巴团体内实时计算的规范解决方案。2018 年，Flink 正式上云，应用 Flink 的实时数据解决方案更好的为中小企业服务。2019 年，阿里巴巴收买了 Flink 的初创公司 Ververica，并将 Blink 回馈给社区，向国际化迈进一步。到 2020 年，Flink 曾经成为事实上的寰球实时计算规范。目前各大云厂商（阿里云，AWS）和大数据厂商（Cloudera）等均已将 Flink 内置作为规范的云产品。到往年双十一，Flink 已包揽阿里外部所有团体（包含蚂蚁，钉钉，菜鸟等）的全链路实时化解决方案，规模达到百万级 CPU Core。并且在资源没有增长的状况下，进步了一倍业务能力。往年双十一的实时数据处理峰值更是达到 40 亿条记录 / 秒的新高。
莫问老师强调，“全数据链路实时化”并不是起点，阿里巴巴的指标是“实时离线一体化”。2020 年，Flink 迎来了实时离线流批一体的新纪元 –– 首次在双十一最外围场景天猫营销流动剖析大屏场景中落地，并带来了微小的收益：实时和离线逻辑业务的一体化使得数据后果人造保持一致；同时使得业务开发效率晋升了 4-10 倍；流批工作的错峰调度使得资源老本节俭了 1 倍，如上图所示。在行业实际分会场中的《流批一体技术在天猫双 11 的利用》对此有更详尽的介绍，感兴趣的同学能够参考一下。在行业内，字节跳动，美团，快手，知乎，小米，网易等都在摸索 Flink 流批一体的落地。
Flink 助力美团数仓增量生产
第二场议题由美团实时计算负责人鞠大升老师带来，次要分享了 Flink 在美团外部的利用。鞠大升老师首先分享了美团数仓的整体架构。如下图所示。美团数据架构包含数据集成系统、数据处理系统、数据生产和数据利用四局部。Flink 次要利用在 Kafka2Hive、实时数据处理、Datalink 等（图中红圈的局部），而他本次分享也次要集中在这几个局部。Flink 在美团的次要利用场景包含实时数仓，实时剖析；举荐搜寻；风控监控；平安审计。这几个利用场景其实也是 Flink 当初的几个最支流的利用场景。在美团的利用场景中，Flink 每天的峰值数据达到 1.8 亿条记录 /s。
美团的分享有两个比拟乏味的局部，一是提出了“增量生产”这个概念。这其实和莫问老师提到的全量增量一体化数据集成殊途同归。但在这个概念里，减少了数据时效性，数据品质和生产成本之间的衡量考量，也即如何在一个数仓业务中在满足时效性的状况下能更无效的管制老本和晋升数据品质。二是美团基于 Flink 架构解决了分布式异构数据源同步（Datalink）的问题。他们基于 Flink 的同步零碎能够将同步工作通过 Task Manager 扩散到集群中，使得整体架构有很好的扩展性；另一方面，离线和实时的同步工作能够都对立到 Flink 框架中，所以离线和实时所有同步的组件都能够共用。
目前，美团在数据处理这一层还没有实现齐全的流批对立，所以鞠大升老师示意，将来的指标心愿在数据处理以及数据存储自身都能达到流批对立。
Apache Flink 在快手的过来、当初和将来
第三场议题由快手大数据架构团队负责人赵健博老师带来，次要分享了快手实时计算选型 Flink 的起因和 Flink 在快手外部利用的场景，以及快手在这些利用场景内的相干技术改良。快手选型 Flink 的起因其实答复了为什么 Flink 能成为业界实时计算的规范：1）亚秒级的解决提早，这对快手外部的实时利用是个硬性强需要；2）丰盛的窗口计算模式，自带的标准化状态存储以及 Exactly Once 的强一致性保障可能极大的简化业务开发和调试的复杂度；3）流批一体架构的演进进一步简化数据和业务架构的复杂性。快手示意十分看好 Flink 流批一体在数据全场景落地。
快手应用 Flink 从 2017 年开始，从 0 到 1 往年已是第四个年头，倒退过程如上图所示。快手应用 Flink 次要场景包含实时 ETL 数据集成，实时报表，实时监控，实时特色解决（AI），目前每天的峰值能够达到 6 亿条记录 /s。针对上述每一个场景快手都分享了很具体的实例，特地是特色解决（Feature Processing/Engineering），在很多 AI 场景中还是很有代表性的。
快手还分享了自研的状态存储（SlimBase）在其外部的利用。SlimBase 次要分为三层，State Interface 层，KV Cache 层和 File System（Distributed）层；其中 KV Cache 是读操作能减速的要害。当 SlimBase KV Cache 层都被命中时，SlimBase 绝对于 RocksDB 有 3-9 倍的读写效率晋升；而 Cache 层不能都被命中的状况下（须要拜访文件系统），读性能有一些降落。除了 SlimBase，快手对 Flink 的稳定性（包含硬件故障，依赖服务异样，工作过载）和负载平衡方面都提出一些改良的解决方案。分会场议题《快手基于 Apache Flink 的继续优化实际》对此有更具体的介绍。
对于将来的布局，赵健博老师老师示意会推动 Flink 的流批一体在快手外部落地，并联合 Flink 的流批一体推动 AI 数据流实时化以晋升训练模型的迭代速度。随着越来越多业务应用 Flink，快手对 Flink 的稳定性也提出更多的要求（比方疾速 Failover 的能力），所以快手在这方面也会有更多的投入。
Stream is the New File
主议题的最初一场是由戴尔科技团体软件开发总监滕昱老师带来的流式存储议题：Pravega。这个议题比拟乏味的是探讨了流式存储的形象 Stream Abstraction。传统的文件系统对于流式存储来说并不是一个好的形象，起因 1）文件的大小有限度，然而流式数据是继续注入的；2）在继续的数据注入中对存储的并发度也须要动静调整，这就波及到多个文件的保护和操作；3）有序的流式数据的定位寻址问题在文件系统接口中也无奈很好的被反对；4）当初业界习用的联结应用音讯队列（Kafka）+ 文件系统的混合形象也依然没有加重利用程序开发和保护的难度。
根据上述需要，Dell 科技团体设计了基于 Stream Abstraction 的流式存储系统 Pravega。Pravega 将流存储动静 scaling，动静 scaling 当前如何保障流数据逻辑上有序，流数据定位和寻址以及 checkpointing 等等一系列问题都封装在 Stream abstraction 之下。在这种形象之下，流式存储能够和流式计算引擎无缝连接，也给流式计算屏蔽了很多流存储端的复杂性，从而使整个端到端仅一次性解决（exactly once）的 pipeline 被极大的简化（如上图所示）。目前 Pravega 曾经是一个 CNCF 开源我的项目，在 Pravega 最新一期官网 blog（https://blog.pravega.io/）中，Pravega 公布了基于 OpenMessaging Benchmark 比照 Kafka 和 Pulsar 的各项性能指标。此外，Pravega 在分会场中有一场对于 Pravega Flink connector 的分享，《Pravega Flink connector 的过来，当初和将来》，感兴趣的同学能够看一下。
除了主会场阿里巴巴，美团，快手，Dell 科技团体的分享，分会场由行业实际，核心技术，开源生态，金融行业，机器学习和实时数仓六个子议题超过 40 家企业机构参加分享，包含天猫，字节跳动，亚马逊，LinkedIn，爱奇艺，蚂蚁，好将来，小米，微博，腾讯，知乎，京东，PingCAP，网易，360 等，后续会有更多的对分会场议题的专场分享文章，敬请期待！
总结和感想
没有一个冬天不能超越，没有一个春天不会降临。2020 年是不寻常的一年，尽管疫情肆虐，然而 Flink 社区在 2020 年继续凋敝，蝉联最沉闷的 Apache 我的项目；Flink 也成为了事实上的国内外实时计算规范。过来一年，Flink 在流计算引擎内核，流批一体，AI 交融，云原生这四个方向上都获得了不错的问题，将来也会在这四个方向上持续耕进。2020 年是 Flink 的新纪元，流批一体首次在阿里巴巴双十一最外围的业务场景中落地，这将是流批一体在业界大规模推广的终点。将来可期，让咱们携手共进，一起致力，把握好时机独特迎接挑战，共创美妙的 Flink 2021！
[1] 40 亿条 / 秒！Flink 流批一体在阿里双 11 首次落地的背地
[2, vldb17] State Management in Apache Flink
[3] NEXMark – A Benchmark for Queries over Data