“阿里正式向 Apache Flink 贡献 Blink 源码”

apache flink是德国柏林工业大学的博士生和研究生从学校开始的项目，初期称为stratosphere。 年，stratosphere项目的中心成员离开学校开发了flink，将flink计算的主流方向定位为流量计算，同年将flink捐赠给apache，随后迅速孵化成为apache的顶级项目。 目前，flink是业界最受好评的大型数据流计算引擎。

阿里巴巴去年尝试了采用flink。 但是，蚂蚁的业务体积非常大，挑战也很多。 那时的flink无论是规模还是稳定性都还没有得到实践，成熟度还需要研究。 为了支持这么大的业务卷，我们必须在flink之上进行一系列的改进，所以阿里巴巴维持着blink这个内部版本的flink。

基于blink的计算平台于年正式上线。 截至目前，阿里大部分技术部门都采用了blink。 blink在阿里内部纷繁的业务场景中得到锻炼和成长。 在公司客户提出的性能、资源利用率、易用性等各种问题上，blink进行了比较改善。 虽然目前blink在阿里内部使用最多的场景是流量计算，但在批处理计算的场景中也有很多业务被在线采用。 例如，搜索和推荐算法业务平台采用blink进行流计算和批处理解析。 blink用于实现流批量一体化的样本生成和特征提取流程，可解决的特征数达数千亿，且每秒解决数亿条消息。 在此场景的批处理解析中，一个作业可以解析的数据量超过400t。 此外，为了节省资源，批处理解析作业与流计算作业和搜索的在线引擎在同一台计算机上运行。 因此，我们可以看到，流批整合已经在阿里巴巴取得了巨大的成功。 希望这次成功和阿里巴巴内部的经验能回归社区。

其实我们从选择flink的第一天开始就一直和社区紧密合作。 这些年来，我们也将蚂蚁对flink的改善推回了社区。 我们从2010年开始将流式计算sql的大部分功能推回到了社区中，将运行时的稳定性与性能优化进行了比较。 但是，blink本身快速迭代的速度非常快，社区有自己的节奏，很多情况下可能无法立刻推回我们的改变。 对社区来说，稍微大一点的功能和重构必须在达成共识才能更好地保证开源项目的质量，但推送速度相对较慢。 经过这几年的开发迭代，我们和社区之间的差距已经很大了。

blink有一点优秀的新功能。 例如，社区版本中没有性能良好的批处理解析功能。 在这期间，我们被问到了blink的各种新功能。 人们越来越期待blink尽快成为开源。 我们一直在考虑开源问题。 一个方案是和以前一样，继续分解各种功能和优化，一个个和社区讨论，慢慢推回flink。 但这显然不是大家所期待的。 另一个方案是先将完美的尽可能多的代码开源，让社区开发者尽快试用。 第二个方案将很快得到社区许多客户的支持。 因此，我们每年都开始开源相关的准备。 经过半年的努力，我们终于整理了大部分blink的功能，开源了。

我们之所以贡献代码，是为了能稍微尝试一下他们感兴趣的功能。 blink决不会单独成为独立的开源项目进行运营，他一定是flink的一部分。 开源后，我们期待着找到最快的方法把blink merge放入flink中。 blink开源的目的只是希望flink变得更好。 apache flink是一个社区项目，必须和社区一起讨论blink以什么形式进入flink最合适，如何做出贡献是社区最希望的方法。

在过去的一段时间里，我们在flink社区征求了广泛的意见，但是我们认为将这次开源的blink代码作为flink的分支直接推回到apacheflink项目中是最合适的方法。 他们还与社区讨论了计划迅速从merge blink迁移到flink master的方案。 有关详细信息，请参见flink社区中讨论的flip32。 我期待着这个merge能在短时间内完成。 这样，我们之后的机器学习等其他新功能就可以直接推回到flink master了。 我相信很快flink和blink就会完全合二为一。 之后，阿里巴巴将直接采用flink进行生产，帮助社区一起维护flink。

此次开源的blink代码在blink1.5. 1版的基础上增加了许多新功能，以及性能和稳定性方面的各种优化。 第一个贡献是，阿里巴巴在流媒体计算中积累的新功能和性能的优化，完整的(可以通过所有tpc-h/tpc-ds，读取hive meta和data )，高性能的batch sql， 以提高易用性为中心的功能)，包括对更高效的交互式编程的支持)，今后也将继续为flink在ai、iot和其他新兴行业的功能和优化做出贡献。 有关此版本的blink发行版的详细信息，请参见blink代码根目录中的readme.md文档。 下面，我们将按模块介绍blink的主要新功能和优化点。

/ S2// S2 /

sql/tableapi体系结构的重构和性能优化是开放源代码版blink的一大贡献。 首先，我们对sql engine的体系结构进行了很大的调整。 提出了一种新的查询处理器( qp )。 查询优化器)和查询执行程序)。 这样，流计算和批处理计算这两层的大部分设计工作可以尽量复用。

另外，由于sql和tableapi的程序最终运行时，不会翻译成datastream和dataset这两个api，而是构建在直接可执行的dag上，所以物理执行操作员的设计不完全依赖基础api，更灵活。 唯一的影响是，这个版本的sql和tableapi不能与名为dataset的api进行相互转换，但是它拥有与datastream api进行相互转换的能力(在表中注册datastream或者将table注册为dataate 将来，计划逐渐在datastream和tableapi上实现dataset的功能。 当时，datastream和sql和tableapi一样，都是可以描述bounded和unbounded processing的api。

不仅是体系结构上的重构，blink在具体的实现中也进行了很多比较大的重构。 首先，blink引入了二进制数据结构binaryrow，大大减少了数据存储的开销以及序列化和反序列化计算的数据开销。 其次，在运算符的实现水平上，blink在更广的范围内引入了codegen技术。 由于运营商事先知道要解决的数据的类型，所以可以直接在qp层内部生成更对比度更高的有效执行代码。

blink的运算符可以动态申请和采用资源，更好地利用资源提高效率。 更重要的是，这些运算符对资源有比较好的控制，不会出现outofmemory问题。 另外，与流计算场景相比，blink加入了minibatch的执行模式，在aggregate、join等需要与state频繁交换，并且经常先进行reduce的一部分的场景中，可以使用minibatch 除了这些重要的重构和功能之外，blink还实施了高级sql ddl、基于emit策略的流式计算dml、一些重要的sql功能和大量的性能优化策略。

有上述许多架构和实施上的重构。 blink的sql/tableapi在功能和性能方面发生了一些变化。 在批处理计算中，首先，blink batch sql完全贯通tpc-h和tpc-ds，性能得到了大幅提高。 如上图所示，以此次开源的blink版本和spark 2.3.1的tpc-ds的benchmark性能为对象。 柱状图的高度表示运行的总时间，高度越低证明性能越好。 可以看出，与spark相比，blink在tpc-ds中具有非常明显的性能特性。 而且，这种性能特性随着数据量的增加而越来越大。 在实际场景中，这个特征超过了spark的三倍。 流媒体计算的性能也同样得到了提高。 我们在线的典型工作大多性能提高三到五倍。 在数据倾斜的场景和相对较难的tpc-h query中，流媒体计算性能提高了几十倍。

标准的关系SQL API除外。 tableapi在功能上是sql的超集。 由于这个sql中新增的功能，我们还在tableapi中添加了对应的api。 除此之外，我们还在tableapi中引入了一些新功能。 其中重要的是cache功能。 在批处理计算方案中，客户可以根据需要缓存计算的中间结果，从而避免不必要的计算重复。 大大加强了交互编程的体验。 我们稍后会在tableapi中添加越来越有用的功能。 其实，很多新功能已经在社区展开讨论，被社区接受。 例如，我们在tableapi中添加了针对一行整体操作的运算符map/flat map/aggregate/flat aggregate [ flink flip 29 ]等。

在这次的开源版本中，我们实现了在元数据和数据层上对接flink和hive进行连接。 国内外很多企业还在用hive进行自己的批量解决。 对于这些客户，通过采用这次的开源blink版本，可以直接用flink sql查询hive的数据，真的可以在hive引擎和flink引擎之间自由切换。

为了通过元数据，我们重新构建了flink catalog的实现，同时添加了两种catalog。 一个是基于内存的flinkinmemorycatalog，另一个是可以桥接hive metastore的Hive目录。 有了这个hivecatalog，您就可以在flink工作中读取hive的元数据。 为了通过数据，实现了hivetablesource。 这样，flink job就可以直接读取hive常规表和分区表中的数据。 因此，在这个版本中，客户可以使用flink sql读取现有的hive meta和data，然后进行数据解析。 今后将继续加强对flink上的hive兼容性的支持，包括对hive特定的查询、数据类型和hive udf的支持。

为了提供更好的可视化和交互体验，zeppelin为了更好地支持flink做了很多工作。 这些变更有在flink上进行的，也有在zeppelin上进行的。 使用此zeppelin图像(有关详细信息，请参见blink代码中的docs/quick start/zeppelin _ quick start.MD )测试和采用这些功能，然后再使用flink 这个测试用的zeppelin版本首先很好地融合和整合了flink的多个运行模式和运维接口。 使用副本sql和表API，可以自由地查询flink的静态表和动态表。

此外，与flink的流式计算优势相比，此版本的zeppelin支持savepoint。 客户可以通过界面暂停作业，然后从savepoint重新启动作业以继续。 在数据展示方面，在以前流传下来的数据观察界面的基础上，增加了流计算的读卡器和时间序列展示等功能。 为了便于客户试用，此版本的zeppelin提供了三个内置链接教程的示例。 一个是流ETL示例，另一个是flink batch和flink stream的基础示例。

●[/s2/ ]链接网络[/s2/ ]

我们在flink web的易用性和性能等许多方面进行了大幅改善，从资源采用、作业调整、日志查询等维度增加了许多功能，使客户可以更轻松地运输flink作业。 关于资源的采用，增加了cluster、taskmanager、job三级的资源新闻，资源的申请和采用情况一目了然。 工作的拓扑关系和数据流可以追溯到操作者层面，vertex可以添加inqueue、outqueue等多项指标，方便地跟踪数据的逆压、滤波、倾斜情况。 taskmanager和jobmanager的日志功能大幅增强，与来自job、vertex、subtask等多个维的对应日志相关联，提供多日志文件访问入口，并分页显示查询和日志的突出显示功能

我们还使用新的angular 7.0全面重建了flink web，使页面性能提高了两倍以上。 即使在大数据量的情况下，也不会出现页面堵塞或纸箱的情况。 此外，整体优化了页面的交互逻辑，大多数相关新闻在一个页面上完成了查询和比对工作，大大减少了不必要的跳转。