-
由Apache软件基金会开发的开源流处理框架
-
其核心是用Java和Scala编写的框架和分布式处理引擎
-
用于对无界和有界数据流进行有状态计算。
-
无界数据流: 即为实时流数据
- 有界数据流:即为离线数据,也称为批处理数据
-
-
官方说明
-
事件驱动型应用
-
数据分析型应用
-
数据管道 ETL
-
-
实际情况
-
要求严格的实时流处理场景
-
-
实现方式
-
Java API
-
Scala API
-
-
统一数据处理过程抽象
-
将实时和批处理的数据过程,均抽象成三个过程,即Source->Transform->Sink。
-
Source为源数据读入,即Source算子。
-
Transform是数据转换处理过程,即Transform算子。
-
Sink即数据接收器,即数据落地到存储层,即Sink算子。
-
-
代码实现复杂度
-
丰富的API和算子 *** 作,抽象封装统一性较高,支持类SQL编程,编程复杂度并不高。
-
-
物理部署层-deploy层
-
负责解决Flink的部署模式问题,
-
支持多种部署模式:本地部署、集群部署(Standalone/Yarn/Mesos)、云(GCE/EC2)以及kubernetes。
-
通过该层支持不同平台的部署,用户可以根据自身场景和需求选择使用对应的部署模式。
-
-
Runtime核心层
-
是Flink分布式计算框架的核心实现层,负责对上层不同接口提供基础服务。
-
支持分布式Stream作业的执行、JobGraph到ExecutionGraph的映射转换以及任务调度等。
-
将DataStream和DataSet转成统一的可执行的Task Operator,达到在流式计算引擎下同时处理批量计算和流式计算的目的。
-
-
API & Libraries层
-
负责更好的开发用户体验,包括易用性、开发效率、执行效率、状态管理等方面。
-
Flink同时提供了支撑流计算和批处理的接口,同时在这基础上抽象出不同的应用类型的组件库,如:
-
基于流处理的CEP(Complex Event Process,复杂事件处理库)
-
Table & Sql库
-
基于批处理的FlinkML(机器学习库)
-
图处理库(Gelly,凝胶-凝冻,取其意是指图是各个事务的统一整合体抽象)
-
-
-
API层包括两部分
-
流计算应用的DataStream API
-
批处理应用的DataSet API
-
统一的API,方便用于直接 *** 作状态和时间等底层数据
-
提供了丰富的数据处理高级API,例如Map、FllatMap *** 作等,
-
并提供了比较低级的Process Function API
-
-
-
集群生命周期和资源隔离保证
-
应用程序的main()方法是在客户端还是在集群上执行
-
本地运行模式-local
-
standalone模式-独立Flink集群
-
集群运行模式
-
经常是指flink on yarn集群模式,yarn也可以换成mesos,Kubernetes(k8s)等资源管理平台替换。
-
共3种
-
session模式
-
per-job模式
-
application模式
-
-
-
本地运行模式
-
运行过程:一个机器启动一个进程的多线程来模拟分布式计算。
-
主要用于代码测试
-
-
standalone模式
-
运行过程:完全独立的Flink集群的模式,各个环节均Flink自己搞定。并没有yarn、mesos的统一资源调度平台。
-
主要是只有纯Flink纯计算的场景,商用场景极少。
-
-
Flink Session 集群(会话模式)
- 集群生命周期:
-
在 Flink Session 集群中,客户端连接到一个预先存在的、长期运行的集群,该集群可以接受多个作业提交。即使所有作业完成后,集群(和 JobManager)仍将继续运行直到手动停止 session 为止。因此,Flink Session 集群的寿命不受任何 Flink 作业寿命的约束。
-
资源隔离:
-
TaskManager slot 由 ResourceManager 在提交作业时分配,并在作业完成时释放。由于所有作业都共享同一集群,因此在集群资源方面存在一些竞争 — 例如提交工作阶段的网络带宽。此共享设置的局限性在于,如果 TaskManager 崩溃,则在此 TaskManager 上运行 task 的所有作业都将失败;再比如,如果 JobManager 上发生一些致命错误,它将影响集群中正在运行的所有作业。
-
-
-
工作流程特征说明
-
多个不同的FlinkJob向同一个Flink Session会话上提交作业,由这一个统一个的FlinkSession管理所有的Flink作业。
-
工作流程示意图
-
- 集群生命周期:
-
Flink Job 集群(per-job模式)
-
集群生命周期:
-
在 Flink Job 集群中,可用的集群管理器(例如 YARN)用于为每个提交的作业启动一个集群,并且该集群仅可用于该作业。在这里客户端首先从集群管理器请求资源启动 JobManager,然后将作业提交给在这个进程中运行的 Dispatcher。然后根据作业的资源请求惰性的分配 TaskManager。一旦作业完成,Flink Job 集群将被拆除。
-
-
资源隔离:
-
JobManager 中的致命错误仅影响在 Flink Job 集群中运行的一个作业。
-
-
其他注意事项:
-
由于 ResourceManager 必须应用并等待外部资源管理组件来启动 TaskManager 进程和分配资源,所以其实时计算性并没有session模式强,因此 Flink Job 集群更适合长期运行、具有高稳定性要求且对较长的启动时间不敏感的大型作业。
-
-
工作流程特征说明
-
多个不同的FlinkJob向各自由统一资源管理器(Yarn)生成的专用Flink Session会话上提交作业,由作业所属的FlinkSession管理自己的Flink作业。
-
工作流程示意图
-
-
-
Flink Application 集群(应用模式)
-
集群生命周期:
-
Flink Application 集群是与Flink作业执行直接相关的运行模式,并且 main()方法在集群上而不是客户端上运行。
-
提交作业是一个单步骤过程:
-
无需先启动 Flink 集群,然后将作业提交到现有的 session 集群。
-
而是,将应用程序逻辑和依赖打包成一个可执行的作业 JAR 中,由入口机客户端提交jar包和相关资源到hdfs当中。
-
然后由调度启动的集群当中JobManager来拉取已由上一步上传完成的运行代码所需要的所有资源。如果有JobManager HA设置的话,将会同时启动多个JobManager作HA保障,此时将面临JobManager的选择,最终由一个胜出的JobManager作为Active进程推进下边的执行。
-
并由运行JobManager进程的集群入口点节点机器(ApplicationClusterEntryPoint)负责调用 main()方法来提取 JobGraph,即作为用户程序的解析和提交的客户端程序与集群进行交互,直到作业运行完成。
-
另外,如果一个main()方法中有多个env.execute()/executeAsync()调用,在Application模式下,这些作业会被视为属于同一个应用,在同一个集群中执行(如果在Per-Job模式下,就会启动多个集群)
-
该模式也允许我们像在 Kubernetes 上部署任何其他应用程序一样部署 Flink 应用程序。
-
因此,Flink Application 集群的寿命与 Flink 应用程序的寿命有关。
-
-
-
资源隔离:
-
在 Flink Application 集群中,ResourceManager 和 Dispatcher 作用于单个的 Flink 应用程序,相比于 Flink Session 集群,它提供了更好的隔离。
-
-
-
由两种类型的进程组成,一个 JobManager 和一个或者多个 TaskManager。
-
工作流程图
-
JobManager
-
JobManager 具有许多与协调 Flink 应用程序的分布式执行有关的职责:它决定何时调度下一个 task(或一组 task)、对完成的 task 或执行失败做出反应、协调 checkpoint、并且协调从失败中恢复等等。这个进程由三个不同的组件组成:
-
ResourceManager
-
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。
-
始终至少有一个 JobManager。高可用(HA)设置中可能有多个 JobManager,其中一个始终是 leader,其他的则是 standby。
-
-
-
TaskManager
-
TaskManager(也称为 worker)执行作业流的 task,并且缓存和交换数据流。
-
必须始终至少有一个 TaskManager。在 TaskManager 中资源调度的最小单位是 task slot。TaskManager 中 task slot 的数量表示并发处理 task 的数量。请注意一个 task slot 中可以执行多个算子。
-
-
工作流程图
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)