flink(六):框架和原理

说明

  • 本博客每周五更新一次,上周五有事,推迟到今天更新。
  • 本博文主要分享flink的系统架构和执行原理,介绍flink的角色分工和任务执行的具体步骤和过程。

角色分工

  • 主要分为:client、管理节点、工作节点
    在这里插入图片描述

flink on yarn执行流程

  • flink提交任务到yarn
    在这里插入图片描述

DataFlow执行过程

独立Operator

  1. DataFlow:flink程序在执行的时候回被映射成一个数据流模型
  2. Operator:数据流模型中的每一个操作被称为Operator,Operator分为:Source/Transform/Sink
  3. Partition:数据流模型是分布式和并行的,执行中会形成1~n个分区
  4. Subtask:多个分区任务可以并行,每个都是独立运行在一个线程中,也就是一个Subtask子任务。
  5. Parallelism:并行度,就是可以同时真正执行的子任务数/分区数
    在这里插入图片描述

Operator合并OperatorChain

  • 客户端在提交任务的时候,会对Operator进行优化操作,能进行合并的Operator会被合并为一个Operator,合并后的Operator称为OperatorChain,即一个执行链。
  • 每个执行链会在TaskManager上独立的线程上运行
    在这里插入图片描述

Operator算子间传递模式

One TO One模式

  • 两个Operator用此模式传递的时候,会保持数据的分区数和数据的排序,如上图中Source1到Map1,它就是保留Source的分区特性,以及分区元素处理的有序性。

Redistributing模式

  • 这种模式会改变数据的分区数,每一个Subtask会根据Transformation把数据发送到不同的目标Subtasks,比如keyBy()会通过hashcode重新分区,broadcast()和rebalance()方法会随机重新分区

执行原理

  • flink执行分为四步:StreamGraph、GobGraph、ExecutionGraph、物理执行图
    在这里插入图片描述

StreamGraph

  • 最初程序执行逻辑图,即算子间执行顺序,client上生成。
  • 流程化

JobGraph

  • 将OneToOne的Operator合并为OperatorChain,Client上生成
  • 流程优化合并

ExecutionGrap

  • 将jobGraph根据代码中设置的并行度和请求的资源进行并行化规划,JobManager上生成。
  • 并行化

物理执行图

  • 经ExecutionGraph的并行执行,落实到具体的TaskManager上,将具体的SubTask落实到具体的TaskSlot内进行运行。
  • 落实执行线程化
  • TaskManager相当于进程,TaskSlot相当于线程。

总结

  • 个人认为大型程序的设计理念坚持模块化为中心,分许需求确认功能,再将功能定义为不同模块,独立设计并实现各个模块的功能,最终连接各个模块形成整体,所谓大道至简。
  • 这种方式设计的软件,结构清晰且易于调整优化,单个模块功能异常,不会引发整个系统雪崩,利于调试和维护,值得借鉴和学习,设计软件时,功能拆分模块化,功能尽量只有连接,没有交集。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 6
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 6
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值