大数据技术之flink架构设计与运行流程

一.架构设计

• 架构设计图

  • 

• 各层及相关术语说明

  • 物理层
    • 解决flink的部署模式的问题
    • 支持多种部署模式:本地,集群,云及k8s
    • 用户可以根据不同的场景选择不同的部署模式
  • 核心层
    • 是flink的核心实现层,负责为上层的接口提供服务
    • Runtime
      • flink的核心计算
    • Optimizer
      • 负责任务的优化
    • Stream Buider
      • 负责对任务进行DAG优化
  • API层
    • 面向用户,负责更好的用户开发体验
    • 提供了流计算和批处理的接口,同时在这个基础上又开发了不同的组件库
      • 基于流处理的CEP(Complex event process,复杂事件处理)
      • Table和sql
      • 基于批处理的机器学习库flinkML
      • 图处理库Gelly
    • API层包括两部分
      • 流处理应用的DataStream API
      • 批处理应用的DataSet API
      • 统一的API,包括直接操作状态和时间等底层数据

二.运行模式

• 各个运行模式的区分点
  • 集群的生命周期
  • 资源的隔离保障
• 运行模式分类
  • 本地
  • standlone 独立flink集群,也就是集群中仅安装了flink
  • 集群运行
    • 经常是指flink on yarn
    • 三种
      • session
      • pre-job
      • application
• 本地
  • 一个机器的单进程多线程模拟集群
  • 一般用于测试
• standlone
  • 完全独立的flink集群,纯flink完成各种工作
• 集群

  • session

    • 生命周期
      • 集群首先创建了一个回话等待客户端连接,单个任务结束后并不会关闭会话,可以接受多个作业的提交.
      • 一句话 : 保持会话通道,接受多个任务
    • 资源隔离
      • 由于所有作业共享同一个集群,所以如果一个TaskManager失败,它上所有的任务都将失败,一个JobManager失败,它将影响集群中运行的所有作业
      • 一句话 : 管理者宕掉,任务全部GG
    • 总结
      • 速度快,但是有风险
    • 工作模式
      • 附加模式(默认)
        • 特点
          • 客户端与flink作业集群同步
        • 细节
          • 客户端将集群交给yarn,但是客户端保持运行,持续追踪集群状态
          • 但是如果集群发生错误,客户端将显示,如果客户端关闭,对应也会通知集群关闭
        • 一句话
          • session模式下的flink默认就是这个,客户端与集群一个关,都关
      • 分离模式
        • 特点
          • 客户端与flink集群相互异步,客户端提交完成后就可以退出
        • 细节
          • yarn-session.sh客户端将集群提交给yarn,然后客户端返回
          • 需要再次调用客户端或者yarn来停止集群
        • 一句话
          • 客户端提交了集群后就可以退出
    • 工作流程
      • 多个作业向同一个Session提交,由它统一管理
      • 示意图

        • 

        • 

  • pre-job

    • 生命周期
      • 集群管理器(yarn)为每个任务创建一个集群,该集群仅用于该作业.
      • 客户端首先向集群管理器请求资源启动JobManager,然后将这个作业提交给dispactcher.然后作业的资源请求惰性分配TaskManager.一旦作业完成,集群将被拆除
    • 资源隔离
      • JobManager中的错误仅会影响其中的一个作业
    • 总结
      • pre-job模式适合长期运行,具有高稳定性且对启动时长要求不高的大型作业
    • 工作流程
      • 多个不同的作业分别向自己的Session会话上提交作业
      • 流程图

        • 

        • 

  • application

    • 生命周期
      • main方法在集群上
      • 提交作业的是一个单步骤过程
        • jar包和资源上传hdfs
        • jobManager去拉去对应的jar包和资源,如果存在HA,就选举出一个Active
        • 由jobManager所在机器调用main方法提取JobGraph,作为客户端程序和集群进行交互,直到任务结束
        • 如果main方法中有多个env.execute()/executeAsync()调用,在Application中,这些作业会被视为同一个应用,在同一个集群上执行
        • application的寿命和对于作业的寿命有关
    • 资源隔离
      • 在 Flink Application 集群中，ResourceManager 和 dispatcher 作用于单个的 Flink 应用程序，相比于 Flink Session 集群，它提供了更好的隔离。
    • 总结
      • 该模式为yarn session和yarn per-job模式的折中选择。
    • 工作流程
      • 将各个环节更进一步进行专用化处理，相当于每个FlinkJob都有一套专用的服务角色进程。
      • 示意图

        • 

  • 总结

    • 各个模式应用场景
      • session模式
        • 集群资源充分、频繁任务提交、小作业居多、实时性要求高的场景。
      • per-job模式
        • 作业少、大作业、实时性要求低的场景。
      • application模式
        • 实时性要求不太高、安全性有一定要求均可以使用，普遍适用性最强。
    • 生产环境中
      • 一般建议用per-job或是application模式，提供了更好的资源隔离性和安全性。

三.运行流程

• 核心角色

  • 一个JobManager
  • 一到多个TaskManager

• 流程图
  -

  

  • 角色剖析
    • JobManager
      • 主要作用就是协调和监控Task,Task的执行顺序,task的任务状态决策等
      • 这个进程由三个不同的组件组成
        • ResourcesManager
          • ResourceManager 负责 Flink 集群中的资源提供、回收、分配 - 它管理 task slots，这是 Flink 集群中资源调度的最小单位。Flink 为不同的环境和资源提供者（例如 YARN、Mesos、Kubernetes 和 standalone 部署）实现了对应的 ResourceManager。在 standalone 设置中，ResourceManager 只能分配可用 TaskManager 的 slots，而不能自行启动新的 TaskManager。
        • dispatcher
          • dispatcher 提供了一个 REST 接口，用来提交 Flink 应用程序执行，并为每个提交的作业启动一个新的 JobMaster。它还运行 Flink WebUI 用来提供作业执行信息。
        • JobMaster
          • JobMaster 负责管理单个JobGraph的执行。Flink 集群中可以同时运行多个作业，每个作业都有自己的 JobMaster。
          • 始终至少有一个 JobMaster。高可用（HA）设置中可能有多个 JobMaster，其中一个始终是 leader，其他的则是 standby。
    • TaskManager
      • TaskManager（也称为 worker）执行作业流的 task，并且缓存和交换数据流。
      • 必须始终至少有一个 TaskManager。在 TaskManager 中资源调度的最小单位是 task slot。TaskManager 中 task slot 的数量表示并发处理 task 的数量。请注意一个 task slot 中可以执行多个算子。

• Yarn模式提交任务的工作流程

  • flink-application运行模式

    •