Apache-Flink深度解析-概述

摘要：

Apache Flink 的命脉 "命脉" 即生命与血脉，常喻极为重要的事物。系列的首篇，首篇的首段不聊Apache Flink的历史，不聊Apache Flink的架构，不聊Apache Flink的功能特性，咱们用一句话聊聊什么是 Apache Flink 的命脉？个人答案是：Apache Flink 是以"批是流的特例"的认知进行系统设计的。

 

Apache Flink 的命脉

"命脉" 即生命与血脉，常喻极为重要的事物。系列的首篇，首篇的首段不聊Apache Flink的历史，不聊Apache Flink的架构，不聊Apache Flink的功能特性，咱们用一句话聊聊什么是 Apache Flink 的命脉？个人答案是：Apache Flink 是以"批是流的特例"的认知进行系统设计的。

 

咱们常常据说 "天下武功，惟快不破"，大概意思是说 "任何一种武功的招数都是有拆招的，惟有速度快，快到对手根原本不及反应，你就将对手KO了，对手没有机会拆招，因此惟快不破"。 那么这与Apache Flink有什么关系呢？Apache Flink是Native Streaming(纯流式)计算引擎，在实时计算场景最关心的就是"快",也就是 "低延时"。

就目前最热的两种流计算引擎Apache Spark和Apache Flink而言，谁最终会成为No1呢？单从 "低延时" 的角度看，Spark是Micro Batching(微批式)模式，最低延迟Spark能达到0.5~2秒左右，Flink是Native Streaming(纯流式)模式，最低延时能达到微秒。很显然是相对较晚出道的 Apache Flink 后来者居上。 那么为何Apache Flink能作到如此之 "快"呢？根本缘由是Apache Flink 设计之初就认为 "批是流的特例"，整个系统是Native Streaming设计，每来一条数据都可以触发计算。相对于须要靠时间来积攒数据Micro Batching模式来讲，在架构上就已经占据了绝对优点。

 

那么为何关于流计算会有两种计算模式呢？归其根本是由于对流计算的认知不一样，是"流是批的特例" 和 "批是流的特例" 两种不一样认知产物。

 

Micro Batching 模式

Micro-Batching 计算模式认为 "流是批的特例"， 流计算就是将接二连三的批进行持续计算，若是批足够小那么就有足够小的延时，在必定程度上知足了99%的实时计算场景。那么那1%为啥作不到呢？这就是架构的魅力，在Micro-Batching模式的架构实现上就有一个天然流数据流入系统进行攒批的过程，这在必定程度上就增长了延时。具体以下示意图：

 

很显然Micro-Batching模式有其天生的低延时瓶颈，但任何事物的存在都有两面性，在大数据计算的发展历史上，最初Hadoop上的MapReduce就是优秀的批模式计算框架，Micro-Batching在设计和实现上能够借鉴不少成熟实践。

 

Native Streaming 模式

Native Streaming 计算模式认为 "批是流的特", 这个认知更贴切流的概念，好比一些监控类的消息流，数据库操做的binlog，实时的支付交易信息等等天然流数据都是一条，一条的流入。Native Streaming 计算模式每条数据的到来都进行计算，这种计算模式显得更天然，而且延时性能达到更低。具体以下示意图：

 

 

很明显Native Streaming模式占据了流计算领域 "低延时" 的核心竞争力，固然Native Streaming模式的实现框架是一个历史先河，第一个实现
Native Streaming模式的流计算框架是第一个吃螃蟹的人，须要面临更多的挑战，后续章节咱们会慢慢介绍。固然Native Streaming模式的框架实现上面很容易实现Micro-Batching和Batching模式的计算，Apache Flink就是Native Streaming计算模式的流批统一的计算引擎。

Apache Flink 按不一样的需求支持Local，Cluster，Cloud三种部署模式，同时Apache Flink在部署上可以与其余成熟的生态产品进行完美集成，如 Cluster模式下能够利用YARN(Yet Another Resource Negotiator）/Mesos集成进行资源管理，在Cloud部署模式下能够与GCE(Google Compute Engine), EC2(Elastic Compute Cloud)进行集成。

 

Local 模式

该模式下Apache Flink 总体运行在Single JVM中，在开发学习中使用，同时也能够安装到不少端类设备上。参考

 

Cluster模式

该模式是典型的投产的集群模式，Apache Flink 既能够Standalone的方式进行部署，也能够与其余资源管理系统进行集成部署，好比与YARN进行集成。Standalone Cluster 参考 YARN Cluster 参考

这种部署模式是典型的Master/Slave模式，咱们以Standalone Cluster模式为例示意以下：

 

 

其中JM(JobManager)是Master，TM(TaskManager)是Slave，这种Master/Slave模式有一个典型的问题就是SPOF(single point of failure), SPOF如何解决呢？Apache Flink 又提供了HA(High Availability)方案，也就是提供多个Master，在任什么时候候总有一个JM服役，N(N>=1)个JM候选,进而解决SPOF问题，示意以下：

 

在实际的生产环境咱们都会配置HA方案，目前Alibaba内部使用的也是基于YARN Cluster的HA方案。

 

Cloud 模式

该模式主要是与成熟的云产品进行集成，Apache Flink官网介绍了Google的GCE 参考，Amazon的EC2 参考，在Alibaba咱们也能够将Apache Flink部署到Alibaba的ECS(Elastic Compute Service)。

完善的容错机制

什么是容错

容错(Fault Tolerance) 是指容忍故障，在故障发生时可以自动检测出来并使系统可以自动回复正常运行。当出现某些指定的网络故障、硬件故障、软件错误时，系统仍能执行规定的一组程序，或者说程序不会因系统中的故障而停止，而且执行结果也不会因系统故障而引发计算差错。

 

容错的处理模式

在一个分布式系统中因为单个进程或者节点宕机都有可能致使整个Job失败，那么容错机制除了要保证在遇到非预期状况系统可以"运行"外，还要求能"正确运行",也就是数据能按预期的处理方式进行处理，保证计算结果的正确性。计算结果的正确性取决于系统对每一条计算数据处理机制，通常有以下三种处理机制：

 

• At Most Once：最多消费一次，这种处理机制会存在数据丢失的可能。

• At Least Once：最少消费一次，这种处理机制数据不会丢失，可是有可能重复消费。

• Exactly Once：精确一次，不管何种状况下，数据都只会消费一次，这种机制是对数据准确性的最高要求，在金融支付，银行帐务等领域必须采用这种模式。

 

Apache Flink的容错机制

 

Apache Flink的Job会涉及到3个部分，外部数据源(External Input), Flink内部数据处理(Flink Data Flow)和外部输出(External Output)。以下示意图:

 

目前Apache Flink 支持两种数据容错机制：

 

• At Least Once

• Exactly Once

 

其中 Exactly Once 是最严格的容错机制，该模式要求每条数据必须处理且仅处理一次。那么对于这种严格容错机制，一个完整的Flink Job容错要作到 End-to-End 的 容错必须结合三个部分进行联合处理，根据上图咱们考虑三个场景：

 

系统内部容错

Apache Flink利用Checkpointing机制来处理容错，Checkpointing的理论基础 Stephan 在 Lightweight Asynchronous Snapshots for Distributed Dataflows 进行了细节描述，该机制源于有K. MANI CHANDY和LESLIE LAMPORT 发表的 Determining-Global-States-of-a-Distributed-System Paper。Apache Flink 基于Checkpointing机制对Flink Data Flow实现了At Least Once 和 Exactly Once 两种容错处理模式。

 

Apache Flink Checkpointing的内部实现会利用 Barriers，StateBackend等后续章节会详细介绍的技术来将数据的处理进行Marker。Apache Flink会利用Barrier将整个流进行标记切分，以下示意图：

 

这样Apache Flink的每一个Operator都会记录当前成功处理的Checkpoint，若是发生错误，就会从上一个成功的Checkpoint开始继续处理后续数据。好比 Soruce Operator会将读取外部数据源的Position实时的记录到Checkpoint中，失败时候会从Checkpoint中读取成功的position继续精准的消费数据。每一个算子会在Checkpoint中记录本身恢复时候必须的数据，好比流的原始数据和中间计算结果等信息，在恢复的时候从Checkpoint中读取并持续处理流数据。

 

外部Source容错

 

Apache Flink 要作到 End-to-End 的 Exactly Once 须要外部Source的支持，好比上面咱们说过 Apache Flink的Checkpointing机制会在Source节点记录读取的Position，那就须要外部数据提供读取的Position和支持根据Position进行数据读取。

 

外部Sink容错

 

Apache Flink 要作到 End-to-End 的 Exactly Once 相对比较困难，如上场景三所述，当Sink Operator节点宕机，从新恢复时候根据Apache Flink 内部系统容错 exactly once的保证,系统会回滚到上次成功的Checkpoin继续写入，可是上次成功Checkpoint以后当前Checkpoint未完成以前已经把一部分新数据写入到kafka了. Apache Flink自上次成功的Checkpoint继续写入kafka，就形成了kafka再次接收到一份一样的来自Sink Operator的数据,进而破坏了End-to-End 的 Exactly Once 语义(重复写入就变成了At Least Once了)，若是要解决这一问题，Apache Flink 利用Two phase commit(两阶段提交)的方式来进行处理。本质上是Sink Operator 须要感知总体Checkpoint的完成，并在总体Checkpoint完成时候将计算结果写入Kafka。

流批统一的计算引擎

批与流是两种不一样的数据处理模式，如Apache Storm只支持流模式的数据处理，Apache Spark只支持批(Micro Batching)模式的数据处理。那么Apache Flink 是如何作到既支持流处理模式也支持批处理模式呢？

 

统一的数据传输层

 

开篇咱们就介绍Apache Flink 的 "命脉"是以"批是流的特例"为导向来进行引擎的设计的，系统设计成为 "Native Streaming"的模式进行数据处理。那么Apache FLink将批模式执行的任务看作是流式处理任务的特殊状况，只是在数据上批是有界的(有限数量的元素)。

 

Apache Flink 在网络传输层面有两种数据传输模式：

 

• PIPELINED模式 - 即一条数据被处理完成之后，马上传输到下一个节点进行处理。

• BATCH 模式 - 即一条数据被处理完成后，并不会马上传输到下一个节点进行处理，而是写入到缓存区，若是缓存写满就持久化到本地硬盘上，最后当全部数据都被处理完成后，才将数据传输到下一个节点进行处理。

 

对于批任务而言一样能够利用PIPELINED模式，好比我要作count统计，利用PIPELINED模式能拿到更好的执行性能。只有在特殊状况，好比SortMergeJoin，这时候咱们须要全局数据排序，才须要BATCH模式。大部分状况流与批可用统一的传输策略，只有特殊状况，才将批看作是流的一个特例继续特殊处理。

 

统一任务调度层

 

Apache Flink 在任务调度上流与批共享统一的资源和任务调度机制（后续章节会详细介绍）。

 

统一的用户API层

 

Apache Flink 在DataStremAPI和DataSetAPI基础上，为用户提供了流批统一的上层TableAPI和SQL，在语法和语义上流批进行高度统一。(其中DataStremAPI和DataSetAPI对流和批进行了分别抽象，这一点并不优雅，在Alibaba内部对其进行了统一抽象）。

 

求同存异

 

Apache Flink 是流批统一的计算引擎，并不意味着流与批的任务都走统一的code path，在对底层的具体算子的实现也是有各自的处理的，在具体功能上面会根据不一样的特性区别处理。好比 批没有Checkpoint机制，流上不能作SortMergeJoin。

 

组件栈

 

咱们上面内容已经介绍了不少Apache Flink的各类组件，下面咱们总体概览一下全貌，以下：

 

TableAPI和SQL都创建在DataSetAPI和DataStreamAPI的基础之上，那么TableAPI和SQL是如何转换为DataStream和DataSet的呢？

 

TableAPI&SQL到DataStrem&DataSet的架构

 

TableAPI&SQL最终会通过Calcite优化以后转换为DataStream和DataSet，具体转换示意以下：

 

 

对于流任务最终会转换成DataStream，对于批任务最终会转换成DataSet。

 

ANSI-SQL的支持

 

Apache Flink 之因此利用ANSI-SQL做为用户统一的开发语言，是由于SQL有着很是明显的优势，以下：

 

 

• Declarative - 用户只须要表达我想要什么，不用关心如何计算。

• Optimized - 查询优化器能够为用户的 SQL 生成最优的执行计划，获取最好的查询性能。

• Understandable - SQL语言被不一样领域的人所熟知，用SQL 做为跨团队的开发语言能够很大地提升效率。

• Stable - SQL 是一个拥有几十年历史的语言，是一个很是稳定的语言，不多有变更。

• Unify - Apache Flink在引擎上对流与批进行统一，同时又利用ANSI-SQL在语法和语义层面进行统一。

 

无限扩展的优化机制

 

Apache Flink 利用Apache Calcite对SQL进行解析和优化，Apache Calcite采用Calcite是开源的一套查询引擎，实现了两套Planner：

 

• HepPlanner - 是RBO(Rule Base Optimize)模式，基于规则的优化。

• VolcanoPlanner - 是CBO(Cost Base Optimize)模式，基于成本的优化。

 

Flink SQL会利用Calcite解析优化以后，最终转换为底层的DataStrem和Dataset。上图中 Batch rules和Stream rules能够根据优化须要无限添加优化规则。

 

Apache Flink 优秀的架构就像一座摩天大厦的地基同样为Apache Flink 持久的生命力打下了良好的基础，为打造Apache Flink丰富的功能生态留下无限的空间。

丰富的类库和算子

类库

 

• CEP - 复琐事件处理类库，核心是一个状态机，普遍应用于事件驱动的监控预警类业务场景。

• ML - 机器学习类库，机器学习主要是识别数据中的关系、趋势和模式，通常应用在预测类业务场景。

• GELLY - 图计算类库，图计算更多的是考虑边和点的概念，通常被用来解决网状关系的业务场景。

 

算子

 

Apache Flink 提供了丰富的功能算子，对于数据流的处理来说，能够分为单流处理(一个数据源)和多流处理(多个数据源)。

 

多流操做

 

如上经过UION和JOIN咱们能够将多流最终变成单流，Apache Flink 在单流上提供了更多的操做算子。

 

单流操做

 

将多流变成单流以后，咱们按数据输入输出的不一样归类以下：

 

类型	输入	输出	Table/SQL算子	DataStream/DataSet算子
Scalar Function	1	1	Built-in & UDF,	Map
Table Function	1	N(N>=0)	Built-in & UDTF	FlatMap
Aggregate Function	N(N>=0)	1	Built-in & UDAF	Reduce

 

如上表格对单流上面操做作简单归类，除此以外还能够作 过滤，排序，窗口等操做，咱们后续章节会逐一介绍。

 

存在的问题

 

Apache Flink 目前的架构还存在很大的优化空间，好比前面提到的DataStreamAPI和DataSetAPI实际上是流与批在API层面不统一的体现，同时看具体实现会发现DataStreamAPI会生成Transformation tree而后生成StreamGraph，最后生成JobGraph，底层对应StreamTask，但DataSetAPI会造成Operator tree，flink-optimize模块会对Batch Plan进行优化，造成Optimized Plan 后造成JobGraph,最后造成BatchTask。具体示意以下：

 

这种状况其实 DataStreamAPI到Runtime 和 DataSetAPI到Runtime的实现上并无获得最大程度的统一和复用。在这一点上面Aalibab 企业版的Flink在架构和实现上都进行了进一步优化。

Apache Flink组件架构优化

组件栈

 

Alibaba 对Apache Flink进行了大量的架构优化，以下架构是一直努力的方向，大部分功能还在持续开发中，具体以下：

 

如上架构咱们发现较大的变化是：

 

• QP/QE/QO - 咱们增长了QP/QE/QO层，在这一层进行统一的流和批的查询优化和底层算子的转换。

• DAG API - 咱们在Runtime层面统一抽象API接口，在API层对流与批进行统一。

 

TableAPI&SQL到Runtime的架构

 

Apache Flink执行层是流批统一的设计，在API和算子设计上面咱们尽可能达到流批的共享，在TableAPI和SQL层不管是流任务仍是批任务最终都转换为统一的底层实现。这个层面最核心的变化是批最终也会生成StreamGraph，执行层运行Stream Task，以下：

小结

本篇概要的介绍了"批是流的特例"这一设计观点是Apache Flink的"命脉"，它决定了Apache Flink的运行模式是纯流式的，这在实时计算场景的"低延迟"需求上，相对于Micro Batching模式占据了架构的绝对优点，同时概要的向你们介绍了Apache Flink的部署模式，容错处理，引擎的统一性和Apache Flink的架构，最后和你们分享了Apache Flink的优化架构。

 

本篇没有对具体技术进行详细展开，你们只要对Apache Flink有初步感知，头脑中知道Alibaba对Apache Flink进行了架构优化，增长了众多功能就能够了，至于Apache Flink的具体技术细节和实现原理，以及Alibaba对Apache Flink作了哪些架构优化和增长了哪些功能后续章节会展开介绍！

 

 

• 海量【java和大数据的面试题+视频资料】整理在公众号，关注后能够下载~
• 更多大数据技术欢迎和做者一块儿探讨~