阿里巴巴对Flink究竟做了哪些优化呢？（上）

　　阿里巴巴对Flink究竟做了哪些优化呢？（上）

　　导读：随着人工智能时代的到来和数据的爆炸式增长，阿里巴巴的产品数据处理往往​​需要面对增量和全量两种不同的业务流程问题，所以阿里巴巴在想：可以吗？采用统一的大数据引擎技术，用户只需根据自己的业务逻辑开发一套代码即可。这样，在各种场景下，无论是全量数据还是增量数据，还是实时处理，都可以全面支持一套解决方案。这就是阿里巴巴选择 Flink 的背景和初衷。

　　当时Flink在规模和稳定性方面还没有经过实践，成熟度有待商榷。阿里巴巴实时计算团队决定在阿里巴巴内部建立一个 Flink 分支 Blink，并对 Flink 进行了大量的修改和改进，以适应阿里巴巴的超*敏*感*词*业务场景。那么，阿里巴巴对 Flink 做了哪些优化？

　　Apache Flink 概述

　　Apache Flink（以下简称Flink）是一个诞生于欧洲的大数据研究项目，原名StratoSphere。该项目是柏林工业大学的一个研究项目，早期专注于批量计算。 2014 年，StratoSphere 项目的核心成员孵化了 Flink，并于同年将 Flink 捐赠给了 Apache。后来，Flink 成功成为了 Apache 的顶级大数据项目。同时，Flink 计算的主流方向定位为流计算，即使用流计算来做所有的大数据计算。这就是Flink技术诞生的背景。

　　

　　

　　2014年，Flink作为专注于流计算的大数据引擎，开始在开源大数据行业崭露头角。它与Storm、Spark Streaming等流计算引擎的区别在于，它不仅是一个高吞吐量、低延迟的计算引擎，还提供了许多高级特性。比如提供有状态计算，支持状态管理，支持数据语义强一致性，支持Event Time，WaterMark对乱序消息的处理等。

　　Flink 的流行离不开它上面的诸多标签，包括性能卓越（尤其是在流计算领域）、高扩展性和容错性。它是一个纯内存计算引擎。在内存管理方面做了大量优化，此外还支持eventtime处理，支持大状态作业（阿里巴巴的作业状态大小超过TB是很常见的），并且支持exactly-once处理。

　　阿里巴巴和 Flink

　　随着人工智能时代的到来和数据量的爆炸式增长，在典型的大数据业务场景中，数据服务最常见的方式是使用批处理技术对全量数据进行处理，通过流式计算得到处理实时增量。数据。在大多数业务场景中，用户的业务逻辑在批处理和流处理中往往是相同的。但是，用户用于批处理和流处理的两种计算引擎是不同的。

　　因此，用户通常需要编写两套代码。毫无疑问，这会带来一些额外的负担和成本。阿里巴巴的产品数据处理往往​​需要面对增量和全量两种不同的业务流程问题，所以阿里巴巴在思考：能不能有统一的大数据引擎技术，用户只需要按照自己的业务逻辑开发一套代码即可。这样，在各种场景下，无论是全量数据还是增量数据，还是实时处理，都可以全面支持一套解决方案。这就是阿里巴巴选择 Flink 的背景和初衷。

　　

　　

　　基于Flink搭建在阿里巴巴上的平台于2016年正式上线，从阿里巴巴的搜索和推荐两个场景入手。目前，阿里巴巴的所有业务，包括阿里巴巴的所有子公司，都采用了基于 Flink 的实时计算平台。同时，Flink 计算平台运行在开源的 Hadoop 集群上。 Hadoop的YARN作为资源管理和调度，HDFS作为数据存储。因此，Flink 可以与开源大数据软件 Hadoop 无缝对接。

　　

　　

　　目前，这个基于 Flink 的实时计算平台不仅服务于阿里巴巴集团，还通过阿里云的云产品 API 为整个开发者生态提供基于 Flink 的云产品支持。

　　当时Flink在规模和稳定性方面还没有经过实践，成熟度有待商榷。阿里巴巴实时计算团队决定在阿里巴巴内部建立一个 Flink 分支 Blink，并对 Flink 进行了大量的修改和改进，以适应阿里巴巴的超*敏*感*词*业务场景。在这个过程中，团队不仅在性能和稳定性方面对 Flink 做了很多改进和优化，还在核心架构和功能上做了很多创新和改进，并将逐步推回社区，例如: Flink 新的分布式架构、增量Checkpoint机制、基于Credit的网络流控机制和Streaming SQL等。接下来我们主要从两个层面深入分析阿里巴巴对Flink做了什么？

　　走开源，用开源

　　一、SQL 层

　　为了真正让用户能够根据自己的业务逻辑开发出一套可以同时运行在多种不同场景的代码，Flink首先需要为用户提供统一的API。经过一番研究，阿里巴巴实时计算认为SQL是一个非常合适的选择。在批处理领域，SQL 历经数十年的考验，是公认的经典。在流计算领域，近年来不断涌现流表对偶性、流作为表的ChangeLog等理论。在这些理论的基础上，阿里巴巴提出了动态表的概念，这样流计算也可以像批处理一样用SQL来描述，在逻辑上是等价的。这样，用户就可以使用 SQL 来描述他们的业务逻辑。同样的查询语句在执行时可以是批处理任务，也可以是高吞吐量低延迟的流计算任务，甚至可以是批处理技术先行。计算历史数据，然后自动转化为流计算任务处理最新的实时数据。在这个声明式的 API 下，引擎有更多的选择和优化空间。接下来，我们将介绍一些比较重要的优化。

　　首先是升级替换SQL层的技术架构。研究或使用过 Flink 的开发者应该都知道，Flink 有两个基本的 API，一个是 DataStream，一个是 DataSet。 DataStream API是为流式用户提供的，DataSet API是为批处理用户提供的，但是两组API的执行路径完全不同，甚至需要生成不同的任务来执行。经过一系列的优化，Flink 的原生 SQL 层会根据用户选择的批处理或流处理来调用 DataSet 或 DataStream API。这会导致用户在日常的开发和优化中，经常会面临两套几乎完全独立的技术栈，很多事情可能需要重复两次。这也将导致在技术堆栈的一侧完成优化，但不会在另一侧完成。因此，阿里巴巴在SQL层提出了一个新的Quyer Processor，主要包括一个可以尽可能复用流和批处理的优化层（Query Optimizer），以及一个基于相同接口的算子层（Query Executor）。这样一来，80%以上的工作就可以在双方复用，比如一些常用的优化规则、基础数据结构等等。同时，streams 和batches 都会保留自己独特的优化和算子，以满足不同的作业行为。

　　

　　

　　在SQL层的技术架构统一之后，阿里巴巴开始寻求更加高效的基础数据结构，以便让Blink在SQL层的执行更加高效。在原生的 Flink SQL 中，统一使用了一种叫做 Row 的数据结构，完全由 JAVA 的一些对象组成，在关系型数据库中形成一行。如果当前行数据由一个整数、一个浮点数和一个字符串组成，那么 Row 将收录一个 JAVA Integer、Double 和 String。众所周知，这些JAVA对象在堆上有很多额外的开销，在访问这些数据的过程中会引入不必要的装箱和拆箱操作。基于这些问题，阿里巴巴提出了一种新的数据结构BinaryRow，它和原来的Row一样，也代表一行关系数据，但不同的是它完全使用二进制数据来存储这些数据。在上面的例子中，三种不同类型的字段统一用JAVA的byte[]表示。这将带来许多好处：

　　通过引入如此高效的基础数据结构，整个SQL层的执行效率提高了一倍多。

　　在算子的实现层面，阿里巴巴引入了更广泛的代码生成技术。由于技术架构和基础数据结构的统一，许多代码生成技术可以实现更广泛的重用。同时，由于SQL的强类型保证，用户可以提前知道算子需要处理的数据类型，从而可以生成更有针对性、更高效的执行代码。在原生 Flink SQL 中，只有像 a>2 或 c + d 这样的简单表达式才会应用代码生成技术。经过阿里巴巴的优化，一些算子会进行整体的代码生成，比如排序和聚合。这让用户可以更灵活地控制算子的逻辑，将最终运行的代码直接嵌入到类中，省去了昂贵的函数调用开销。一些应用代码生成技术的基础数据结构和算法，如排序算法、基于二进制数据的HashMap等，也可以在流算子和批处理算子之间共享复用，让用户真正享受到技术和架构的统一。好处。针对批处理的某些场景优化数据结构或算法后，流计算的性能也可以得到提升。接下来说说阿里巴巴在 Runtime 层对 Flink 做了哪些巨变。

　　二、运行层

　　为了让 Flink 在阿里巴巴的*敏*感*词*生产环境中落地生根，实时计算团队如期遇到了各种挑战。首先要做的是将 Flink 与其他集群管理系统集成。 Flink 的原生集群管理模型尚未完善，其他相对成熟的集群管理系统无法原生使用。基于此，一系列难题接踵而至：多租户之间的资源如何协调？如何动态申请和释放资源？如何指定不同的资源类型？

　　为了解决这个问题，实时计算团队进行了大量的研究和分析。最终选择的方案是改造Flink资源调度系统，让Flink可以原生运行在Yarn集群上；并重构Master结构，让一个Job对应一个Master，Master不再是集群瓶颈。以此为契机，阿里巴巴与社区共同推出了全新的Flip-6架构，使Flink的资源管理成为可插拔的架构，为Flink的可持续发展奠定了坚实的基础。现在 Flink 可以在 YARN、Mesos 和 K8s 上无缝运行，这有力地说明了这种架构的重要性。

　　解决了Flink集群*敏*感*词*部署的问题后，接下来就是可靠性和稳定性了。为了保证Flink在生产环境的高可用，阿里巴巴重点改进了Flink的FailOver机制。首先是Master的FailOver。 Flink 的原生 Master FailOver 将重启所有作业。改进后，Master的任何FailOver都不会影响Job的正常运行；其次，引入了Region-based Task FailOver，以尽量减少任何任务的FailOver对用户的影响。在这些改进的护航下，大量阿里巴巴业务方开始将实时计算迁移到 Flink。

　　Stateful Streaming 是 Fl​​ink 最大的亮点。基于 Chandy-Lamport 算法的 Checkpoint 机制，让 Flink 拥有恰好一次一致的计算能力。但是在早期的 Flink 版本中，Checkpoint 在*敏*感*词*数据量下的性能存在一定的瓶颈。 Baba还对Checkpoint做了很多改进，比如：

　　虽然所有的数据都可以放在State中，但是由于一些历史原因，用户还是有一些数据需要存储在一些外部的KV存储比如HBase中，而用户需要在Flink Job中访问这些外部数据，但是由于 Flink 一直是单线程处理模型，访问外部数据的延迟成为整个系统的瓶颈。显然，异步访问是解决这个问题的直接方法。然而，让用户在 UDF 中编写多线程同时保证 ExactlyOnce 语义，却并不容易。阿里巴巴在 Flink 中提出了 AsyncOperator，它允许用户在 Flink JOB 中编写异步调用，就像编写“Hello Word”一样简单。这使得 Flink Job 的吞吐量有了很大的飞跃。

　　Flink 旨在成为一个统一的批处理流计算引擎。在使用了闪电般的流计算之后，批处理用户也有兴趣留在 Flink 社区。但批量计算也带来了新的挑战。首先，在任务调度方面，阿里巴巴引入了更灵活的调度机制，可以根据任务之间的依赖关系进行更高效的调度；其次是data Shuffle，Flink原生的Shuffle Service和TM是绑定的。任务执行后，TM无法释放资源。此外，原创的 Batch shuffle 不会合并文件，因此无法在生产中使用。阿里巴巴开发了Yarn Shuffle Service功能来同时解决以上两个问题。阿里巴巴在开发 Yarn Shuffle Service 时发现，开发一套新的 Shuffle Service 非常不方便，需要侵入 Flink 代码中的很多地方。为了让其他开发者可以方便地扩展不同的Shuffle，阿里巴巴还修改了Flink Shuffle架构，让Flink的Shuffle成为可插拔架构。目前阿里巴巴的搜索业务已经在使用Flink Batch Job，并开始服务生产。

　　经过3年多的打磨，Blink在阿里巴巴已经开始蓬勃发展，但是Runtime的优化和改进却是层出不穷，一大波改进和优化正在酝酿中。

　　Flink 的未来发展方向

　　目前Flink已经成为主流的流计算引擎。社区接下来的重要任务是让 Flink 在批量计算方面取得突破，成为更多场景下的主流批量计算引擎。然后进一步在stream和batch之间无缝切换，使得stream和batch之间的界限越来越模糊。使用Flink，在一次计算中，可以同时进行流计算和批量计算。

　　接下来，阿里巴巴还将致力于推动 Flink 对更多语言的生态支持，不仅仅是 Java 和 Scala 语言，甚至是机器学习下使用的 Python 和 Go 语言。

　　

　　

　　还有一点必须是AI，因为现在很多大数据计算需求和数据量都支持非常流行的AI场景，所以Flink会在完善的流批生态的基础上，不断完善上层的机器学习算法。同时，Flink 还将与更成熟的机器学习和深度学习相结合。例如，Tensorflow On Flink 可用于集成大数据的 ETL 数据处理、机器学习的特征计算和特征计算、训练计算等，让开发者可以同时享受多个生态系统的好处。

　　

　　

　　最后，在生态和社区活动方面，阿里巴巴目前正在推进的一件事是筹备将于2018年12月20日至21日在国家会议中心举行的首届Flink Forward China Summit（千人）。 , 参与者将有机会了解为什么阿里巴巴、腾讯、华为、滴滴、美团和字节跳动等公司将 Flink 作为首选的流处理引擎。

　　云服务器团购99元！拉新红包即可赢取*敏*感*词*红包！ 300万等你瓜分！

　　一键开团赢红包：/m/1000019899/。