新手学做网站 下载,网站建设模版文档,做外贸公司网站,做网站送推广Flink 和 SparkStreaming的区别
设计理念方面
SparkStreaming#xff1a;使用微批次来模拟流计算#xff0c;数据已时间为单位分为一个个批次#xff0c;通过RDD进行分布式计算
Flink#xff1a;基于事件驱动#xff0c;是面向流的处理框架#xff0c;是真正的流式计算…Flink 和 SparkStreaming的区别
设计理念方面
SparkStreaming使用微批次来模拟流计算数据已时间为单位分为一个个批次通过RDD进行分布式计算
Flink基于事件驱动是面向流的处理框架是真正的流式计算
架构方面
SparkStreaming角色包括 Master、Worker、Driver、Executor
Flink角色包括 Jonmanager、Taskmanager和slot
窗口计算方面
SparkStreaming只支持基于处理时间的窗口操作
Flink可以支持时间窗口也支持基于事件的窗口如滑动、滚动、会话窗口等
时间机制方面
SparkStreaming只支持处理时间产生数据堆积时候处理时间和事件时间误差明显
Flink支持事件时间、注入时间、处理时间同事支持watermark机制处理迟到的数据在处理大乱序的实时数据更有优势
容错机制方面
SparkStreaming基于RDD或对宽依赖添加CheckPoint利用 SparkStreaming的 direct方式与kafka保证 exactly once
Flink基于状态添加CheckPoint通过俩阶段提交协议来保证 exactly once
吞吐量与延迟方面
SparkStreaming基于微批次的处理使得吞吐量是最大的但付出了延迟的代价只能做到秒级处理
Flink数据是逐条处理容错机制很轻量级兼顾了吞吐量的同时又有很低的延迟支持毫秒级处理 Flink 运行时组件
作业管理器JobManager
控制一个应用程序执行的主进程也就是说每个应用程序都会被一个唯一的Jobmanager所控制执行Jobmanager会先接收到要执行的应用程序这个应用程序会包括作业图 Job Graph、逻辑数据流图 ogical dataflow graph和打包了所有的类、库和其它资源的JAR包。Jobmanager会把Jobgraph转换成一个物理层面的数据流图这个图被叫做“执行图”(Executiongraph)包含了所有可以并发执行的任务。Job Manager会向资源管理器(Resourcemanager)请求执行任务必要的资源也就是任务管理器(Taskmanager)上的插槽slot。一旦它获取到了足够的资源就会将执行图分发到真正运行它们的 Taskmanager上。而在运行过程中Jobmanagera会负责所有需要中央协调的操作比如说检查点(checkpoints)的协调。
任务管理器TaskManager Flink中的工作进程。通常在 Flink中会有多个Taskmanager运行每个Taskmanager都包含了一定数量的插槽(slots)。插槽的数量限制了Taskmanager能够执行的任务数量。启动之后Taskmanager会向资源管理器注册它的插槽收到资源管理器的指令后 Taskmanager就会将一个或者多个插槽提供给Jobmanager调用。Jobmanager就可以向插槽分配任务(tasks)来执行了。在执行过程中一个Taskmanager可以跟其它运行同一应用程序的Taskmanager交换数据。
资源管理器ResourceManager)
主要负责管理任务管理器(TaskManager)的插槽(slot)Taskmanger插槽是Flink中定义的处理资源单元。Flink为不同的环境和资源管理工具提供了不同资源管理器比如YARN、K8s以及 standalone部署。当Jobmanager申请插槽资源时Resourcemanager会将有空闲插槽的Taskmanager分配给Jobmanager。如果 Resourcemanager没有足够的插槽来满足 Jobmanager的请求它还可以向资源提供平台发起会话以提供启动 Taskmanager进程的容器。
分发器Dispatcher 可以跨作业运行它为应用提交提供了REST接口。当一个应用被提交执行时分发器就会启动并将应用移交给Jobmanage。Dispatcher他会启动一个WebUi用来方便地展示和监控作业执行的信息。
Flink作业提交流程 on Yarn Flink任务提交后Client向HDFS上传Flink的Jar包和配置向ResourceManager请求一个YARN容器启动ApplicationMasterApplicationMaster启动后加载Flink的Jar包和配置构建环境启动JobManagerJobManager和ApplicationMaster(AM)运行在同一个容器中ApplicationMaster向ResourceManager申请启动TaskManager所需资源ResourceManager分配Container资源后由ApplicationMaster通知资源所在节点的NodeManager启动TaskManagerNodeManager加载Flink的Jar包和配置构建环境并启动TaskManagerTaskManager启动后向JobManager发送心跳包并等待JobManager向其分配任务。
Flink的执行图
Flink 中任务调度执行的图按照生成顺序可以分成四层
逻辑流图StreamGraph→ 作业图JobGraph→ 执行图ExecutionGraph→ 物理图Physical Graph逻辑流图StreamGraph
这是根据用户通过 DataStream API 编写的代码生成的最初的 DAG 图用来表示程序的拓扑结构。这一步一般在客户端完成。
作业图JobGraph
StreamGraph 经过优化后生成的就是作业图JobGraph这是提交给 JobManager 的数据结构确定了当前作业中所有任务的划分。主要的优化为: 将多个符合条件的节点链接在一起合并成一个任务节点形成算子链这样可以减少数据交换的消耗。JobGraph 一般也是在客户端生成的在作业提交时传递给 JobMaster。
执行图ExecutionGraph
JobMaster 收到 JobGraph 后会根据它来生成执行图ExecutionGraph。ExecutionGraph是 JobGraph 的并行化版本是调度层最核心的数据结构。ExecutionGraph 更进一步细化了 JobGraph 中的任务并考虑了容错、调度等因素。
物理图Physical Graph
JobMaster 生成执行图后 会将它分发给 TaskManager各个 TaskManager 会根据执行图 部署任务最终的物理执行过程也会形成一张“图”一般就叫作物理图Physical Graph。 这只是具体执行层面的图并不是一个具体的数据结构。 Flink中的并行度Parallelism 在 Flink 程序执行过程中每一个算子operator可以包含一个或多个子任务operator subtask这些子任务在不同的线程、不同的物理机或不同的容器中完全独立地执行。每个算子的子任务subtask的个数被称之为其并行度parallelism。一般情况下程序的并行度可以认为就是其所有算子中最大的并行度。一个程序中不同的算子可能具有不同的并行度。 任务槽和并行度的关系
task slot 是静态的概念 是指TaskManager具有的并发执行能力可以通过参数taskmanager.numberOfTaskSlots进行配置并行度parallelism是动态概念也就是TaskManager运行程序时实际使用的并发能力可以通过参数parallelism.default进行配置。换句话说并行度如果小于等于集群中可用slot的总数程序是可以正常执行的因为slot不一定要全部占用有十分力气可以只用八分而如果并行度大于可用slot总数导致超出了并行能力上限那么心有余力不足程序就只好等待资源管理器分配更多的资源了。 算子链Operator Chain 一个数据流在算子之间传输数据的形式可以是一对一one-to-one的直通 (forwarding)模式也可以是打乱的重分区redistributing模式具体是哪一种形式取决于算子的种类。
一对一直通One-to-oneforwarding 数据流维护着分区以及元素的顺序。source算子读取数据之后可以直接发送给 map 算子做处理它们之间不需要重新分区也不需要调整数据的顺序。这就意味着 map 算子的子任务看到的元素个数和顺序跟 source 算子的子任务产生的完全一样保证着“一对一”的关系。
重分区Redistributing 数据流的分区会发生改变。每一个算子的子任务会根据数据传输的策略把数据发送到不同的下游目标任务。例如keyBy()是分组操作本质上基于键key的哈希值hashCode进行了重分区而当并行度改变时比如从并行度为 2 的 window 算子要传递到并行度为 1 的 Sink 算子这时的数据传输方式是再平衡rebalance会把数据均匀地向下游子任务分发出去。
合并算子链 在 Flink 中并行度相同的一对一one to one算子操作可以直接链接在一起形成一个“大”的任务task这样原来的算子就成为了真正任务里的一部分。这样的技术被称为合并算子链。 Flink中的状态
算子状态Operator State Operator State可以用在所有算子上每个算子子任务或者说每个算子实例共享一个状态流入这个算子子任务的数据可以访问和更新这个状态。 算子状态的实际应用场景不如 Keyed State 多一般用在 Source 或 Sink 等与外部系统连接 的算子上或者完全没有 key 定义的场景。比如 Flink 的 Kafka 连接器中就用到了算子状态。 在我们给 Source 算子设置并行度后Kafka 消费者的每一个并行实例都会为对应的主题( topic)维护一个偏移量 作为算子状态保存起来。 对于 Operator State 来说因为不存在 key所有数据发往哪个分区是不可预测的也就是说当发生故障重启之后我们不能保证某个数据跟之前一样进入到同一个并行子任务、访问同一个状态。所以 Flink 无法直接判断该怎样保存和恢复状态而是提供了 接口让我们根据业务需求自行设计状态的快照保存snapshot和恢复restore逻辑。
支持的结构类型
广播状态BroadcastState有时我们希望算子并行子任务都保持同一份“全局”状态用来做统一的配置和规则设定。这时所有分区的所有数据都会访问到同一个状态状态就像被“广播”到所有分区一样这种特殊的算子状态就叫作广播状态BroadcastState。
列表状态ListState
联合列表状态UnionListState
按键分区状态Keyed State 状态是根据输入流中定义的键key来维护和访问的相当于用key来进行物理隔离所以只能定义在按键分区流KeyedStream中也就 keyBy 之后才可以使用。 不同 key 对应的 Keyed State可以进一步组成所谓的键组key groups每一组都对应着一个并行子任务。键组是 Flink 重新分配 Keyed State 的单元键组的数量就等于定义的最大并行度。当算子并行度发生改变时Keyed State 就会按照当前的并行度重新平均分配保证运行时各个子任务的负载相同。
支持的结构类型
比较常用的ValueState、ListState、MapState不太常用的ReducingState 和 AggregationState
Flink的状态管理checkpoint和savepoint
