Flink基本介绍

Flink简介:

Flink通过实现Google Dataflow流式计算模型实现了高吞吐、低延迟、高性能兼具实时流式计算框架。同时Flink支持高度容错的状态管理,防止状态在计算过程中因为系统异常而出现丢失,Flink周期性地通过分布式快照技术Checkpoints实现状态的持久化维护,使得即使在系统停机或者异常的情况下都能计算出正确的结果。

Flink系统组成:

Flink系统由两个部分组成,分别是JobManager和TaskManager
JobManagers: jobmanager 负责整个Flink集群任务的调度以及资源的管理,从客户端获取提交的任务,然后根据集群中Taskmanager上TaskSlot的使用情况,为提交的应用分配相应的TaskSlot资源并命令Taskmanager启动从客户端中获取的应用。Jobmanager是集群中的Master节点,整个集群有且仅有一个active的jobmanager,负责整个集群的任务管理和资源管理。Jobmanager和TaskManager之间通过Actor System 进行通信,获取任务的执行情况并通过Actor System将应用的任务的执行情况发送到客户端。同时在任务的执行过程中,Flink Jobmanager会触发Checkpoints 操作,每个taskmanager节点接受的到checkpoints触发命令后,完成checkpoints操作,所有的checkpoint协调过程都是在Flink Jobmanager中完成。当任务完成后,jobmanager会将任务执行信息返回到客户端,并释放掉taskmanager中的资源以供下一次任务使用。

TaskManagers: Taskmanager相当于整个集群的slave 节点,负责具体的任务执行和对应任务在每个节点上的资源申请与管理。客户端通过将编写好的flink应用编译打包,提交到jobmanager,然后jobmanager会根据已经注册在jobmanger中taskmanager的资源情况,将任务分配到有资源的taskmanager节点,然后启动并运行任务。Taskmanager从jobmanager那接受需要部署的任务,然后使用slot资源启动task,建立数据接入网络连接,接受数据并处理。同时Taskmanager之间的数据交互都是通过数据流的方式进行的。
每一个TaskManager 就是一个JVM进程,TaskManager也叫TaskSlots.

flink的任务运行其实是采用多线程的方式,能够极大的提高cpu使用效率,在多个任务之间通过taskslot方式共享系统资源,每个taskmanager对多个taskslot资源池进行管理。
Client: 客户端负责将任务提交到集群,与JobManager构建Akka连接,然后将任务提交到JobManager,通过和JobManager之间进行交互获取任务执行状态。客户端提交任务可以采用CLI方式或者通过使用Flink WebUI提交,也可以在应用程序中指定JobManager的RPC网络端口构建ExecutionEnvironment提交Flink应用。

Flink Application

  • Streams: 流,分为有限数据流与无限数据流,unbounded stream 是有始无终的数据流,即无限数据流;而 bounded stream 是限定大小的有始有终的数据集合,即有限数据流,二者的区别在于无限数据流的数据会随时间的推演而持续增加,计算持续进行且不存在结束的状态,相对的有限数据流数据大小固定,计算最终会完成并处于结束的状态。

  • State: 状态是计算过程中的数据信息,在容错恢复和 Checkpoint 中有重要的作用,流计算在本质上是 Incremental Processing,因此需要不断查询保持状态;另外,为了确保 Exactly- once 语义,需要数据能够写入到状态中;而持久化存储,能够保证在整个分布式系统运行失败或者挂掉的情况下做到 Exactly- once,这是状态的另外一个价值。

  • Time: event time(事件时间:事件发生时的时间),ingestion time(摄取时间:事件进入流处理系统的时间),processing time(处理时间:消息被计算处理的时间),Flink 的无限数据流是一个持续的过程,时间是我们判断业务状态是否滞后,数据处理是否及时的重要依据。

  • API: API 通常分为三/四层,由上而下可分为 SQL / Table API、DataStream API、ProcessFunction 三层,API 的表达能力及业务抽象能力都非常强大,但越接近 SQL 层,表达能力会逐步减弱,抽象能力会增强,反之,ProcessFunction 层 API 的表达能力非常强,可以进行多种灵活方便的操作,但抽象能力也相对越小。
    在这里插入图片描述

Flink基本架构栈:

Flink的架构体系同样也遵行分层架构设计的理念,基本上分为三层,API&Libraries层、Runtine核心层以及物理部署层。
API&Libraries层: 提供了支撑流计算和批计算的接口,同时在此基础之上抽象出不同的应用类型的组件库。
Runtime 核心层: 负责对上层不同接口提供基础服务,支持分布式Stream作业的执行、JobGraph到ExecutionGraph 的映射转换、任务调度等,将DataStream和DataSet转成统一的可执行的Task Operator.
物理部署层: Flink 支持多种部署模式,本机,集群(Standalone/YARN)、云(GCE/EC2)、Kubenetes。

Flink的具体优势:

  • 同时支持高吞吐、低延迟、高性能
    Flink是目前开源社区中唯一一套集高吞吐、低延迟、高性能三者于一身的分布式流式数据处理框架。像Apache Spark也只能兼顾高吞吐和高性能特性,主要因为在Spark Streaming流式计算中无法做到低延迟保障;而流式计算框架Apache Storm只能支持低延迟和高性能特性,但是无法满足高吞吐的要求。而满足高吞吐、低延迟、高性能这三个目标对分布式流式计算框架来说是非常重要的。

  • 支持事件时间(Event Time)概念
    在流式计算领域中,窗口计算的地位举足轻重,但目前大多数框架窗口计算采用的都是系统时间(Process Time),也是事件传输到计算框架处理时,系统主机的当前时间。Flink能够支持基于事件时间(Event Time)语义进行窗口计算,也就是使用事件产生的时间,这种基于事件驱动的机制使得事件即使乱序到达,流系统也能够计算出精确的结果,保持了事件原本产生时的时序性,尽可能避免网络传输或硬件系统的影响。

    扫描二维码关注公众号,回复: 8975649 查看本文章
  • 支持有状态计算
    Flink在1.4版本中实现了状态管理,所谓状态就是在流式计算过程中将算子的中间结果数据保存在内存或者文件系统中,等下一个事件进入算子后可以从之前的状态中获取中间结果中计算当前的结果,从而无须每次都基于全部的原始数据来统计结果,这种方式极大地提升了系统的性能,并降低了数据计算过程的资源消耗。对于数据量大且运算逻辑非常复杂的流式计算场景,有状态计算发挥了非常重要的作用。

  • 支持高度灵活的窗口(windows)操作
    在流处理应用中,数据是连续不断的,需要通过窗口的方式对流数据进行一定范围的聚合计算,例如统计在过去的1分钟内有多少用户点击某一网页,在这种情况下,我们必须定义一个窗口,用来收集最近一分钟内的数据,并对这个窗口内的数据进行再计算。窗口可以用灵活的触发条件定制化来达到对复杂的流传输模式的支持,用户可以定义不同的窗口触发机制来满足不同的需求。
    Flink内置了3种时间窗口:Tumbling Windows、Sliding Windows和Session Windows;

    • Tumbling Windows(滚动窗口): 窗口大小固定,没有重叠;
    • Sliding Windows(滑动窗口):窗口大小固定,有重叠;
    • Session Windows(会话窗口):窗口大小不固定,没有重叠,同一个session中所有事件分配在一个窗口;
  • 基于轻量级分布式快照(Snapshot)实现的容错
    Flink能够分布式运行在上千个节点上,将一个大型计算任务的流程拆解成小的计算过程,然后将tesk分布到并行节点上进行处理。在任务执行过程中,能够自动发现事件处理过程中的错误而导致数据不一致的问题,比如:节点宕机、网路传输问题,或是由于用户因为升级或修复问题而导致计算服务重启等。在这些情况下,通过基于分布式快照技术的Checkpoints,将执行过程中的状态信息进行持久化存储,一旦任务出现异常停止,Flink就能够从Checkpoints中进行任务的自动恢复,以确保数据在处理过程中的一致性。

  • 基于JVM实现独立的内存管理
    内存管理是所有计算框架需要重点考虑的部分,尤其对于计算量比较大的计算场景,数据在内存中该如何进行管理显得至关重要。针对内存管理,Flink实现了自身管理内存的机制,尽可能减少JVM GC对系统的影响。另外,Flink通过序列化/反序列化方法将所有的数据对象转换成二进制在内存中存储,降低数据存储的大小的同时,能够更加有效地对内存空间进行利用,降低GC带来的性能下降或任务异常的风险,因此Flink较其他分布式处理的框架会显得更加稳定,不会因为JVM GC等问题而影响整个应用的运行。

  • Save Points(保存点)
    对于7*24小时运行的流式应用,数据源源不断地接入,在一段时间内应用的终止有可能导致数据的丢失或者计算结果的不准确,例如进行集群版本的升级、停机运维操作等操作。值得一提的是,Flink通过Save Points技术将任务执行的快照保存在存储介质上,当任务重启的时候可以直接从事先保存的Save Points恢复原有的计算状态,使得任务继续按照停机之前的状态运行,Save Points技术可以让用户更好地管理和运维实时流式应用。

发布了67 篇原创文章 · 获赞 113 · 访问量 3万+

猜你喜欢

转载自blog.csdn.net/TNTZS666/article/details/102499921