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:

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