Flink架构原理基础知识

介绍

Flink是一款基于状态的流式计算框架,它具有以下特点:
1、既可进行流式(Stream)计算,也可以进行批处理(Batch)计算
2、基于状态的计算,正是这种可管理的状态计算,让Flink实现了Exactly Once
3、窗口(Window)式计算,主要针对于Stream无界的数据流
4、完整的容错机制,包括CheckPoint和SavePoint
5、分布式计算,支持高可用
在这里插入图片描述
Flink内置了多种API,方便用户进行各种数据计算。
1、状态流式。最低级别抽象,使用最原始的Process Function
2、Core APIs。使用更加方便的DataStream/DataSet API进行数据处理
3、Table API。将数据流抽象成关系型数据库表,提供更加方便的操作和编程方式
4、SQL。与Table API结合,提供最高级别的抽象编程,使数据处理变得更加简洁和高效

架构

在这里插入图片描述
Flink运行架构如上图所示,从整体上看,主要由客户端(Client)、Master(JobManager)、Worker(TaskManager)组成,由客户端将应用程序提交到JobManager,然后由JobManager进行任务解析和划分,将任务分发给TaskManager去执行。在Job执行过程中,TaskManager始终和JobManager保持心跳连接,向JobManager汇报节点资源和Task执行进度。从更细节的角度看,JobManager和TaskManager内部也包含了很多功能模块。

其实除了Flink,类似Storm、Spark等,从架构上来看,很多大数据分布式计算技术都有一些共通之处。
1、分布式计算都有多个节点组成,这些节点以集群模式运行
2、集群中有一到多个Master,也称为管理节点,负责集群资源管理和任务执行管理
3、集群中有多个Worker,也称为计算节点,负责真正的执行计算任务,并向Master汇报自身信息

Flink架构三个组成部分:
Client。客户端负责将Job提交到Flink集群,提交完后就与集群没有关系了,可以关闭,它不属于Flink运行时的组件
**JobManager。**集群的管理节点,也可称为Master。在收到客户端提交的Job后,会将Job解析并优化生成执行计划图,然后将Job以Task形式调度分发到各个TaskManager节点。除此之外,JobManager也负责Checkpoint的管理工作,通知TaskManager节点进行Checkpoint动作,同时也负责Task的执行和取消等操作。在Job执行过程中,TaskManager向JobManager以心跳形式汇报自身状态,JobManager监控各个节点信息和任务执行情况。
TaskManager。集群的工作节点,也可称为Worker,它是实际运行计算的节点。在接收到JobManager分发的Task后,在TaskSlot中启动并运行Task,每个TaskSlot中可运行一个到多个Task。TaskManager除了以心跳形式向JobManager汇报信息,TaskManager之间是以数据流形式进行数据传输。

补充:在Job执行过程中也涉及到其他组件:
1、Operator Chain。多个operator算子组合生成一个operator chain,最终以一个Task形式执行。Task运行在一个线程内,避免了多线程交互的消耗
2、Task Slot。TaskManager运行在JVM中,在启动时分配一到多个Slot,每个Slot运行一个到多个Task。多个Slot共享JVM资源,官方建议Slot数量设置成CPU CORE数量
3、CheckPoint。Flink容错机制之一,由于Flink Stream是基于状态的计算,因此可以按照一定的频率将Stream的状态和位置信息保存,这些保存的信息就称为CheckPoint。在计算失败情况下就可以通过CheckPoint进行回复
4、SavePoint。不同于CheckPoint针对于Stream流的,SavePoint是针对于Job的,它是对整个Job执行状态的存储,并且是永久式存储,除非手动删除。CheckPoint会有一个自动失效时间(TTL),过期自动删除

Task Slot

Flink的Slot由TaskManager启动,Task运行在Slot中。多个Slot共享一个JVM,Slot也就成为了资源划分单位。通常Sloat数量由taskmanager.numberOfTaskSlots设定,随着TaskManager一起启动。Job并行度也就是Task数量,通常Slot数量决定了Job并行度。
1、每个TaskManager就是一个JVM,通过Slot数量来进行资源划分
2、多个Slot平均分配JVM资源,避免Slot之间资源竞争
3、Task是由一系列operator算子优化后组成,也就是一个Operator Chain,Task内部算子的执行可称为SubTask
4、一个Slot可运行一到多个线程,每个线程负责执行一个任务
5、在一个Job内部,不同SubTask可共享Slot,即使这些SubTask不是来自同一个Task。

Slot共享好处:
1、Slot数量和Job中设置的最高并行度一致,这样就不需要计算Job需要多少个Task
2、更好的进行资源利用。

假设有2个TaskManager,每个TaskManager有3个Slot。
Job并行度为2时:
在这里插入图片描述
Job并行度为6时:
在这里插入图片描述
可以看出当并行度设置成和Slot一样数量时,source/map并行度为6,window操作并行度为6,sink并行度为1。这样充分利用了每个Slot的资源,达到了资源最大化利用。也正是由于相同Job下不同SubTask可共享Slot资源,所以避免了多个算子在不同Slot中交互的资源消耗。

有状态的计算

Flink Stream流式处理是一种包含状态的处理,在计算过程中可以将数据流的状态和位置存储起来,既能在失败情况下进行容错回复,同时又能保证Exactly Once语义的实现。
在Flink中包含两种状态,Keyed State和Operator State(Non-keyed State)。
Keyed State只适用于KeyedStream,并且状态可进行管理,默认由Flink进行管理,存储在内存中。

例如:
ValueState
ListState
ReducingState
AggregatingState<IN, OUT>
MapState<UK, UV>

Operator State与key无关,每一个operator实例都有一个operator state,其状态信息存储在operator内部,不可进行管理。
Flink在运行时会将这些状态信息存入到CheckPoint中,所有状态都有一个失效时间(TTL),当过期后会自动清除。
以下为官方提供的一个例子:

public class CountWindowAverage extends RichFlatMapFunction<Tuple2<Long, Long>, Tuple2<Long, Long>> {

    /**
     * The ValueState handle. The first field is the count, the second field a running sum.
     */
    private transient ValueState<Tuple2<Long, Long>> sum;

    @Override
    public void flatMap(Tuple2<Long, Long> input, Collector<Tuple2<Long, Long>> out) throws Exception {

        // access the state value
        Tuple2<Long, Long> currentSum = sum.value();

        // update the count
        currentSum.f0 += 1;

        // add the second field of the input value
        currentSum.f1 += input.f1;

        // update the state
        sum.update(currentSum);

        // if the count reaches 2, emit the average and clear the state
        if (currentSum.f0 >= 2) {
            out.collect(new Tuple2<>(input.f0, currentSum.f1 / currentSum.f0));
            sum.clear();
        }
    }

    @Override
    public void open(Configuration config) {
        ValueStateDescriptor<Tuple2<Long, Long>> descriptor =
                new ValueStateDescriptor<>(
                        "average", // the state name
                        TypeInformation.of(new TypeHint<Tuple2<Long, Long>>() {}), // type information
                        Tuple2.of(0L, 0L)); // default value of the state, if nothing was set
        sum = getRuntimeContext().getState(descriptor);
    }
}

// this can be used in a streaming program like this (assuming we have a StreamExecutionEnvironment env)
env.fromElements(Tuple2.of(1L, 3L), Tuple2.of(1L, 5L), Tuple2.of(1L, 7L), Tuple2.of(1L, 4L), Tuple2.of(1L, 2L))
        .keyBy(0)
        .flatMap(new CountWindowAverage())
        .print();

// the printed output will be (1,4) and (1,5)

Flink容错机制

Flink提供了完整的容错机制,包括针对于计算的CheckPoint机制,以及针对于Job的SavePoint功能。

CheckPoint

Flink中Stream流式计算都是带有状态的,所以按照一定的频率将计算的状态信息保存起来,这些保存的数据流的中间计算结果就是CheckPoint,当Job失败时候,用户可以从CheckPoint进行恢复。
实现CheckPoint条件:
1、持久化的数据源,能够实现错误数据重新输入。例如kafka
2、持久化的状态信息,将计算状态CheckPoint持久化到外部系统,例如HDFS
使用CheckPoint:
CheckPoint默认是关闭的,以下为官方提供的一段样例代码:

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

// start a checkpoint every 1000 ms
env.enableCheckpointing(1000);

// advanced options:

// set mode to exactly-once (this is the default)
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);

// make sure 500 ms of progress happen between checkpoints
env.getCheckpointConfig().setMinPauseBetweenCheckpoints(500);

// checkpoints have to complete within one minute, or are discarded
env.getCheckpointConfig().setCheckpointTimeout(60000);

// allow only one checkpoint to be in progress at the same time
env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);

// enable externalized checkpoints which are retained after job cancellation
env.getCheckpointConfig().enableExternalizedCheckpoints(ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);

// allow job recovery fallback to checkpoint when there is a more recent savepoint
env.getCheckpointConfig().setPreferCheckpointForRecovery(true);

SavePoint

SavePoint看上去和CheckPoint有点相似,但是却大不相同:
1、存储结构不同。SavePoint除了存储状态信息外还保存Job的元信息
2、概念上不同。Checkpoint主要在意外失败的时候提供恢复机制,由Flink管理,与用户无关。而Savepoint主要由用户管理,其创建和恢复等操作都是由用户实现
3、作用域不同。Savepoint是针对于job级的控制,Checkpoint针对于job内部数据流和算子
使用SavePoint:
在这里插入图片描述

水平一般,能力有限,大数据小学生一枚。文章主要用于个人学习和总结,如果能给他人带来帮助,纯属意外。

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值