大数据术语之Flink

Flink使用Standalone模式作业提交的流程：
    1.Flink提交作业给Job Client,然后Job Client将作业提交个Job Manager;
    2.Job Manager负责协调资源分配和作业执行。 它首先要做的是分配所需的资源。资源分配完成后任务将提交给相应的Task Manager;
    3.在接收任务时，Task Manager启动一个线程开始执行。
    4.Task Manager会继续向Job Manager报告状态更改。
    5.每个任务管理器TaskManager都需要管理一个或多个任务槽Slot，Slot是TaskManager资源粒度的划分，每个Slot都有自己独立的内存。所有Slot平均分配TaskManger的内存。比如TaskManager分配给Solt的内存为8G，两个Slot，每个Slot的内存为4G，四个Slot，每个Slot的内存为2G，值得注意的是，Slot仅划分内存，不涉及cpu的划分。同时Slot是Flink中的任务执行器（类似Storm中Executor），每个Slot可以运行多个task，而且一个task会以单独的线程来运行。Slot主要的好处有以下几点：
        1.可以起到隔离内存的作用，防止多个不同job的task竞争内存；
        2.Slot的个数就代表了一个Flink程序的最高并行度，简化了性能调优的过程；
        3.允许多个Task共享Slot，提升了资源利用率。
    6.共享Slot，虽然在flink中允许task共享Slot提升资源利用率，但是如果一个Slot中容纳过多task反而会造成资源低下（比如极端情况下所有Task都分布在一个Slot内），在Flink中task需要按照一定规则共享Slot。共享Slot的方式有两种，SlotShardingGroup和CoLocationGroup，这里主要介绍一下SlotShardingGroup的用法，
    这种共享的基本思路就是给operator分组，同一组的不同operator的task，可以共享一个Slot。默认所有的operator属于同一个组“default”，
    及所有operator的task可以共享一个Slot，可以给operator设置不同的group，防止不合理的共享。Flink在调度task分配Slot的时候有两个重要原则：
        1.同一个job中，同一个group中不同operator的task可以共享一个Slot
        2.Flink是按照拓扑顺序从Source依次调度到Sink的

Flink作业提交到YARN的流程：
    1.使用yarn-per-job提交作业；
    2.Flink任务提交后，Client向HDFS上传Flink的jar包和配置，之后向ResourceMananager提交任务；
    3.ResourceMananager向NodeManager收集资源信息，找一个资源比较足的NodeManager,启动一个ApplicationMaster;
    4.ApplicationMaster启动后向ResourceMananager注册自己，告诉ResourceMananager它可以工作了;
    5.ApplicationMaster加载Flink的jar包和配置文件，然后启动JobManger;
    6.ApplicationMaster向ResourceMananager申请资源启动TaskManager;
    7.ResourceMananager分配资源后,由ApplicationMaster通知对应的NodeManager启动TaskManager;
    8.NodeManager加载Flink的jar包和配置文件并启动TaskManager;
    9.TaskManager启动后向JobMannager发送心跳包，并等待JobMannager向其分配任务。

Flink检查点：
    checkpoint是Flink容错的主要机制。它不断为分布式数据流和executor状态拍摄快照。
1.当checkpoint启动时，JobManager会将检查点分界线（barrier）注入数据流；barrier会在算子间传递下去。每个算子会对当前的状态做个快照，保存到状态后端。
2.对于source任务而言，就会把当前的offset作为状态保存起来。下次从checkpoint恢复时，source任务可以重新提交偏移量，从上次保存的位置开始重新消费数据。
3.每个内部的transform任务遇到barrier时，都会把状态存到checkpoint里。
4.sink任务首先把数据写入外部kafka，这些数据都属于预提交的事务（还不能被消费）；当遇到barrier时，把状态保存到状态后端，并开启新的预提交事务。

Flink+Kafka如何实现端到端的Exactly-Once语义：
我们知道，端到端的状态一致性的实现，需要每一个组件都实现，对于Flink + Kafka的数据管道系统（Kafka进、Kafka出）而言，各组件怎样保证exactly-once语义呢？
从内部而言：  利用checkpoint机制，把状态存盘，发生故障的时候可以恢复，保证内部的状态一致性。
从source而言：kafka consumer作为source，可以将偏移量保存下来，如果后续任务出现了故障，恢复的时候可以由连接器重置偏移量，重新消费数据，保证一致性。
从sink而言：  kafka producer作为sink，采用两阶段提交 sink，需要实现一个 TwoPhaseCommitSinkFunction。

反压
反压（BackPressure）通常产生于这样的场景：短时间的负载高峰导致系统接收数据的速率远高于它处理数据的速率。
常见场景：
    1.垃圾回收停顿可能会导致流入的数据快速堆积；
    2.大促、秒杀活动导致流量陡增；
反压机制是指系统能够自己检测到被阻塞的 Operator，然后自适应地降低源头或上游数据的发送速率，从而维持整个系统的稳定。Flink 任务一般运行在多个节点上，数据从上游算子发送到下游算子需要网络传输，若系统在反压时想要降低数据源头或上游算子数据的发送速率，那么肯定也需要网络传输。