转载：阿里巴巴选择ApacheFlink的原因是什么？本文主要根据阿里巴巴计算平台事业部高级技术专家莫问在云起大会上的演讲进行整理。一棵小树苗逐渐长成参天大树；一颗小小的橡实可能长成参天大树。随着人工智能时代的到来和数据量的爆炸式增长，典型的大数据业务场景中，常见的数据处理方式是使用批处理技术处理全量数据和流计算处理实时增量数据。在大多数业务场景中，用户的业务逻辑在批处理和流处理中往往是相同的。然而，用户用于批处理和流处理的两套计算引擎是不同的。因此，用户通常需要编写两套代码。这无疑带来了一些额外的负担和成本。阿里巴巴的商品数据处理往往需要面对增量和全量两种不同的业务流程，因此，阿里在思考，是否可以有一个统一的大数据引擎技术，用户只需要根据自己的业务逻辑开发一套代码就可以广泛应用了。在这样不同的场景下，无论是全数据还是增量数据，还是实时处理，都可以有一套完整的解决方案支持，这也是阿里选择Flink的背景和初衷。目前开源的大数据计算引擎有很多选择，如Storm、Samza、Flink、KafkaStream等。以及Spark、Hive、Pig、Flink等批量处理。但是同时支持流处理和批处理的计算引擎只有两个选择：一个是ApacheSpark，一个是ApacheFlink。从技术、生态等多方面综合考虑，阿里最终决定将Flink作为统一通用的大数据引擎作为未来的选择。Flink是一个统一的大数据计算引擎，具有低延迟、高吞吐量。在阿里巴巴的生产环境中，Flink的计算平台每秒可以处理数亿条消息或事件，延迟为毫秒级。同时，Flink提供了一次性的一致性语义。保证了数据的正确性。这样，Flink大数据引擎就可以提供金融数据处理能力。弗林克在阿里的现状基于ApacheFlink在阿里巴巴搭建的平台于2024年正式上线，从阿里巴巴的搜索和推荐两个场景实现。目前，包括阿里巴巴所有子公司在内的所有阿里巴巴业务都采用了基于Flink的实时计算平台。同时，Flink计算平台运行在开源的Hadoop集群上。Hadoop的YARN作为资源管理调度，HDFS作为数据存储。所以Flink可以和开源大数据软件Hadoop无缝对接。目前，这个基于Flink的实时计算平台不仅服务于阿里巴巴集团，还通过阿里云的云产品API向整个开发者生态系统提供基于Flink的云产品支持。Flink在阿里巴巴的大规模应用表现如何？规模:一个系统是否成熟，规模是一个重要的指标。Flink最初推出阿里巴巴只有几百台服务器，现在已经达到上万台服务器，在全球屈指可数；状态数据:基于Flink，内部积累的状态数据已经是PB规模；事件:如今，每天在Flink的计算平台上处理的数据超过万亿条；PS:高峰期每秒可承担超过4.72亿次访问，最典型的应用场景是阿里巴巴双11的大屏；弗蚂巧如林克的发展之路接下来，从开源技术的角度，我们来谈谈ApacheFlink是如何诞生，如何成长的。而阿里又是如何在这个成长的关键时刻进来的？你对它做过哪些贡献和支持？Flink诞生于欧洲大数据研究项目Streaming。这个项目是柏林工业大学的一个研究项目。早期，Flink做的是批量计算，但2024年，Streaming的核心成员孵化了Flink，同年将Flink捐赠给Apache，后来成为Apache最顶尖的大数据项目。同时，Flink计算的主流方向被定位为流式，即使用流式计算来计算所有的大数据。这就是Flink技术诞生的背景。2024年，Flink作为专注于流计算的大数据引擎，开始在开源大数据行业崭露头角。不同于Storm、SparkStreaming等流计算引擎，它不仅是一个高吞吐量、低延迟的计算引擎，还提供了许多高级功能。比如提供有状态计算，支持状态管理，支持数据语义的强一致性，支持事件时间，水印处理消息无序。Flink核心概念和基本概念Flink区别于其他流计算引擎的地方其实是状态管理。什么是状态？比如开发一套流量计算系统或者任务做数据处理，可能经常需要对数据做统计，比如Sum，Count，Min，Max，这些值都需要存储。因为它们是不断更新的，所以这些值或变量可以理解为一种状态。如果数据源正在读取Kafka，RocketMQ，可能需要记录读取的位置并记录偏移量。这些偏移变量是要计算的状态。Flink提供了内置的状态管理，可以将这些状态存储在Flink内部，而不需要存储在外部系统中。这样做有以下优点:第一，减少了计算引擎对外部系统的依赖和部署，运维更简单；其次，在性能上有了很大的提升:如果是通过外部访问，比如Redis，HBase必须通过网络和RPC访问。如果Flink在内部访问这些变量，它只通过自己的进程访问这些变量。同时，Flink会定期让这些状态的检查点持久化，并将检查点存储在分布式持久化系统中，比如HDFS。这样，当Flink的任务出错时，它会从最新的检查点恢复整个流的状态，然后继续运行它的流处理。对用户没有数据影响。Flink如何保证在检查点恢复的过程中没有数据丢失或重复？要保证计算准确，原因是Flink使用了一套经典的Chandy-Lamport算法，其核心思想是将这种流计算视为一种流拓扑，在这种拓扑的头部有规律地插入来自源点的特殊屏障，并将屏障从上游广播到下游。当每个节点接收到所有栅栏时，它将拍摄状态快照。每个节点完成快照后，整个拓扑将被视为一个完整的检查点。接下来，无论发生什么故障，都会从最近的检查点恢复。Flink使用这种经典算法来确保语义的强一致性。这也是Flink与其他无状态流计算引擎的核心区别。以下是Flink解决无序问题的方法。比如星球大战的序列，如果按照上映时间来看，可能会发现故事在跳跃。在流量计算上，和这个例子很像。所有消息的到达时间与源在线系统日志中实际发生的时间不一致。在流处理的过程中，希望消息按照它们在源端实际发生的顺序进行处理，而不是按照它们实际到达程序的时间。Flink提供了一些先进的事件时间和水印技术来解决乱序问题。以便用户可以有序地处理该消息。这是Flink的一个非常重要的特点。接下来介绍一下Flink起步时的核心概念和理念，这是Flink发展的第一阶段；第二阶段是2024年和2024年。这个阶段也是Flink发展和阿里巴巴介入的时候。故事源于2024年年中我们在搜索事业部做的一项调查。当时阿里有自己的批处理技术和流计算技术，既有自研的，也有开源的。但是，为了思考下一代大数据引擎的方向和未来趋势，我们对新技术做了大量的研究。结合大量的研究成果，我们最终得出结论，解决一般大数据计算需求，整合批量流的计算引擎是大数据技术的发展方向，最终我们选择了Flink。但2024年的Flink还不够成熟，规模和稳定性都没有达到实践的程度。最后我们决定在阿里成立Flink分公司，对Flink进行大量的修改和改进，以适应阿里巴巴的超大型业务场景。在这个过程中，我们团队不仅改进和优化了Flink的性能和稳定性，还在核心架构和功能上做了大量的创新和改进，并贡献给了社区，比如:Flink全新的分布式架构、增量式检查点机制、基于信用的网络流量控制机制和流式SQL。阿里巴巴对Flink社区的贡献我们来看两个设计案例。第一个是阿里巴巴重构了Flink的分布式架构，对Flink的作业调度和资源管理做了明确的分层和解耦。这样做的第一个好处是Flink可以在各种开源资源管理器上本地运行。这种分布式架构改进后，Flink可以原生运行在HadoopYarn和Kubernetes这两种最常见的资源管理系统上。同时将Flink的任务调度由集中式调度改为分布式调度，使Flink可以支持更大的集群，获得更好的资源隔离。另一个是实现增量检查点机制，因为Flink提供了有状态计算和规则检查点机制。如果内部数据越来越多，检查点就会越来越大，最终可能导致做不下去。提供增量检查点后，Flink会自动找出哪些数据是增量更改的，哪些数据是修改的。同时，只有这些修改过的数据被持久化。这样检查点就不会随着时间的运行越来越难，整个系统的性能也会非常稳定，这也是我们贡献给社区的一个非常重要的特性。经过2024-2024年对Flink流媒体能力的提升，Flink社区逐渐走向成熟。Flink也成为了流媒体领域最主流的计算引擎。因为Flink最开始是想做一个统一流式、批量处理的大数据引擎，这个工作在2024年就已经开始了。为了实现这一目标，阿里巴巴提出了新的统一API架构和统一SQL解决方案。同时，在流式计算的各种功能得到改进后，我们认为批量计算也需要各种改进。无论在任务调度层还是数据洗牌层，在容错性和易用性方面都有很多工作需要改进。究其原因，这里有两个要点与大家分享:●统一的API堆栈●统一的SQL方案我们来看看FlinkAPI栈的现状。研究过Flink或者用过Flink的开发者应该知道。Flink有两个基本的API，一个是数据流，一个是数据集。数据流API提供给流用户，数据集API提供给批量用户，但是这两个API的执行路径完全不同，甚至需要生成不同的任务来执行。所以这和统一API是冲突的，这也是不完善的，