Flink详解系列(一)–flink架构

近段时间,由于公司项目的相关需求,需要对Flink做详细的梳理,我把学习过程整理成Flink详解系列的10篇左右的总结,供大家参考。

大数据计算引擎的发展

近年来随着大数据的发展,涌现出了一大批开源的大数据处理引擎,比如hadoop, storm, spark等。国外的一些社区将这些大数据计算引擎分为4代:

第一代以hadoop承载的mapreduce为标志,开启了大数据处理的先河。mapreduce将处理过程分为map和reduce两个阶段,对于复杂应用,需要拆分为多个mapreduce的job, 并有应用层去管理各个job的依赖关系。

第二代以支持DAG框架为标志,也是以批处理为主,具体如Tez,以及更上层的Oozie。

第三代以spark为代表,开启了内存计算的时代,支持job内部DAG管理,同时支持流处理、批处理,并提供SQL高层API支持。

第四代就该系列要介绍的Flink,主要是由于Flink对流计算的支持。

Flink于2014年12月成为Apache软件基金会的顶级项目,2015年9月发布第一个稳定版本0.9,到目前为止已经发布到1.12版本,社区非常活跃。

全球有越来越多的公司在使用Flink, 国内主流互联网公司都在大规模使用Flink作为企业分布式大数据处理引擎。Flink之所以如此受到青睐,除了其提供高吞吐、低延迟和Exactly-once一致性语义支持外,更重要的是它能以流数据的处理方式来处理批数据,可以真正意义上实现批流处理的统一。正是由于这些特性,使Flink逐渐成为主流的大数据处理框架,并将在不久的将来成为下一代大数据处理的标准。

Flink架构

Flink是一个分布式系统,它的运行涉及到多个进程,这些进程会分布到集群的多台不同机器上。分布式系统就需要面对这样的几个问题:分配和管理集群计算资源,进程协调,持久且高可用的数据存储及故障恢复等。

Flink并不依靠自身去实现这些功能,而是在已有集群基础设施和服务之上专注于它的核心功能–分布式流数据处理。它和很多集群管理器(比如:YARN、Mesosd等)能很好的集成,也可以独立运行。它不提供分布式持久化存储,而是使用现有的分布式文件系统(HDFS)和对象存储(S3)。它使用ZooKeeper来完成可用性配置中的领导选举工作。

1、任务提交过程

以YARN作为资源管理器为例,Flink任务提交后,Client向HDFS上传Flink的Jar包和配置,之后向Yarn资源管理器提交任务,资源管理器分配容器资源并通知对应的NodeManager启动ApplicationMaster,ApplicationMaster启动后加载Flink的Jar包和配置构建环境,然后启动JobManager,之后ApplicationMaster向资源管理器申请资源启动TaskManager,资源管理器分配容器资源后,由ApplicationMaster通知资源所在节点的NodeManager启动TaskManager,NodeManager加载Flink的Jar包和配置构建环境并启动TaskManager,TaskManager启动后向JobManager发送心跳包,并等待JobManager向其分配任务。

2、运行架构

从上面的Flink任务执行图可以看到,运行时有两个主要的进程:JobManager和TaskManager。client不是Flink程序运行时和程序执行的一部分,它主要负责准备和提交dataFlow到JobManager, 并接收JobManager返回的程序执行结果。

JobManager负责协调Flink程序的执行,包括:任务的调度、任务运行完成与失败的处理,协调检查点与恢复等,主要包括以下项职能:

ResourceManager:负责资源分配,管理任务slot, 这个是flink集群资源管理的单位。Dispatcher:提供应用程序提交的REST接口,对每一个提交的作业启动JobMaster,并运行Flink WebUI提供作业执行的信息。JobMaster:负责单个作业图(JobGraph)的执行。一个集群可以同时运行多个作业,每个作业都有自己的JobMaster。

TaskManager负责执行dataflow中的任务,缓存和交换数据流。一个作业执行时,至少要有一个TaskManager,TaskManager中资源调度的最小单位是slot。一个TaskManager中的slot数表示的是该TaskManager中可以并行执行任务的数量

3、任务和算子链

为方便执行,Flink将不同算子的子任务(subtask)链接到一个任务里,每一个任务在一个线程中执行。这是一个非常有用的优化方式,它减小了进程间数据交换和缓存的开销,而且在减少延迟同时增加了吞吐量。这种链接关系是可配置的,下面是一个有5个子任务(subtask)的示例,有5个线程并行执行。

4、任务Slot和资源

每个worker(TaskManager)都是一个JVM进程,可以执行一个或多个子任务(subtask)。任务槽(task slot)就是为了控制一个worker能同时运行多少个任务的(至少一个)。

每个任务槽(task slot)代表TaskManager一个设定的资源子集。比如, 一个TaskManager有3个槽,会将其管理的1/3的内存分给每个槽位。将资源分成不同的槽位意味着一个子任务(subtask)不会跟其他作业的子任务竞争资源,而是会拥有一定量的保留资源。需要注意的是,这里不涉及CPU隔离,目前任务槽仅仅分割task管理的内存。

为了适配任务槽(task slot)的数量,用户可以定义子任务(subtask)是如何隔离的。如果每个TaskManager有一个槽,就意味着task组运行在不同的GJVM里。如果每个TaskManager有多个槽意味着多个字任务(subtask)共享同一个JVM。任务在同一个JVM运行可以共享TCP链接和心跳信息。它们可以共享数据集和数据结构,因此可以减少每个任务的开销。

    THE END
    喜欢就支持一下吧
    点赞8 分享
    评论 抢沙发
    头像
    欢迎您留下宝贵的见解!
    提交
    头像

    昵称

    取消
    昵称表情代码图片

      暂无评论内容