Flink

1 Flink跟Spark Streaming的区别?

  1）Flink 是标准的实时处理引擎，基于事件驱动。而 Spark Streaming 是微批（Micro-Batch）的模型;

  2）架构模型

  Spark Streaming 在运行时的主要角色包括：Master、Worker、Driver、Executor，Flink 在运行时主要包含：Jobmanager、Taskmanager和Slot。

  3）任务调度

  Spark Streaming 连续不断的生成微小的数据批次，构建有向无环图DAG，Spark Streaming 会依次创建 DStreamGraph、JobGenerator、JobScheduler。Flink 根据用户提交的代码生成 StreamGraph，经过优化生成 JobGraph，然后提交给 JobManager进行处理，JobManager 会根据 JobGraph 生成 ExecutionGraph，ExecutionGraph 是 Flink 调度最核心的数据结构，JobManager 根据 ExecutionGraph 对 Job 进行调度。

  4）时间机制

  Spark Streaming 支持的时间机制有限，只支持处理时间。 Flink 支持了流处理程序在时间上的三个定义：处理时间、事件时间、注入时间。同时也支持 watermark 机制来处理滞后数据。

  5）容错机制

  对于 Spark Streaming 任务，我们可以设置 checkpoint，然后假如发生故障并重启，我们可以从上次 checkpoint 之处恢复，但是这个行为只能使得数据不丢失，可能会重复处理，不能做到恰好一次处理语义。Flink 则使用两阶段提交协议来解决这个问题。

2 Flink 集群运行时角色

  Flink程序在运行时主要有TaskManager，JobManager，Client三种角色;

  Client 不是运行时和程序执行的一部分， 而是用于准备数据流并将其发送给JobManager。 之后， 客户端可以断开连接（ 分离模式） ， 或保持连接来接收进程报告（ 附加模式） 。 客户端可以作为触发执行 Java/Scala 程序的一部分运行，也可以在命令行进程 ./bin/flink run … 中运行。

  可以通过多种方式启动 JobManager 和 TaskManager： 直接在机器上作为standalone 集群启动、 在容器中启动、 或者通过 YARN 等资源框架管理并启动。TaskManager 连接到 JobManagers， 宣布自己可用， 并被分配工作。

2.1 J o b M a n a g e r

  JobManager 具有许多与协调 Flink 应用程序的分布式执行有关的职责： 它决定何时调度下一个 task（ 或一组 task） 、 对完成的 task 或执行失败做出反应、协调 checkpoint、 并且协调从失败中恢复等等。 这个进程由三个不同的组件组成：

ResourceManager

  ResourceManager 负责 Flink 集群中的资源提供、 回收、 分配， 管理 task slots。

Dispatcher

  Dispatcher 提供了一个 REST 接口， 用来提交 Flink 应用程序执行， 并为每个提交的作业启动一个新的 JobMaster。 它还运行 Flink WebUI 用来提供作业执行信息。

JobMaster

  JobMaster 负责管理单个 JobGraph 的执行。 Flink 集群中可以同时运行多个作业， 每个作业都有自己的 JobMaster。

2.2 T a s k M a n a g e r

  TaskManager（ 也称为 worker） 执行作业流的 task， 并且缓存和交换数据流。

  必须始终至少有一个 TaskManager。 在 TaskManager 中资源调度的最小单位是task slot。 TaskManager 中 task slot 的数量表示并发处理 task 的数量。 请注意一个 task slot 中可以执行多个算子。

3 并行度

  Flink中的任务被分为多个并行任务来执行，其中每个并行的实例处理一部分数据。这些并行实例的数量被称为并行度。我们在实际生产环境中可以从四个不同层面设置并行度：

    ① 操作算子层面(Operator Level)

    ② 执行环境层面(Execution Environment Level)

    ③ 客户端层面(Client Level)

    ④ 系统层面(System Level)

  优先级：算子层面>环境层面>客户端层面>系统层面

  并行度的设置：一般设为kafka的分区数，达到1：1
         遵循2的n次方：比如2、4、8、16……

4 Flink的keyby怎么实现的分区？分区、分组的区别？

  Keyby实现原理：

    对指定的key调用自身的hashCode方法=》hash1
    调用murmruhash算法，进行第二次hash =》键组ID
    通过一个公式，计算出当前数据应该去往哪个下游分区：
      键组id * 下游算子并行度 / 最大并行度（默认128）

  分区：算子的一个并行实例可以理解成一个分区，是物理上的资源

  分组：数据根据key进行区分，是一个逻辑上的划分

  一个分区可以有多个分组，同一个分组的数据肯定在同一个分区

5 状态编程、状态机制(Flink 状态(State)管理与恢复)

  算子状态：作用范围是算子，算子的多个并行实例各自维护一个状态

  键控状态：每个分组维护一个状态

  状态后端：两件事=》 本地状态存哪里、checkpoint存哪里

6 Flink Time、Watermark、Window

6.1 Flink的三种时间语义

  Event Time：是事件创建的时间。它通常由事件中的时间戳描述，例如采集的日志数据中，每一条日志都会记录自己的生成时间，Flink通过时间戳分配器访问事件时间戳。

  Ingestion Time：是数据进入Flink的时间。

  Processing Time：是每一个执行基于时间操作的算子的本地系统时间，与机器相关，默认的时间属性就是Processing Time。

6.2 Flink 中的Watermark机制

  1）Watermark 是一种衡量 Event Time 进展的机制，可以设定延迟触发；

  2）Watermark 是用于处理乱序事件的，而正确的处理乱序事件，通常用Watermark 机制结合 window 来实现；

  3）基于事件时间，用来触发窗口、定时器等；

  4）watermark主要属性就是时间戳，可以理解一个特殊的数据，插入到流里面；

  5）watermark是单调不减的；

  6）数据流中的 Watermark 用于表示 timestamp 小于 Watermark 的数据，都已经到达了，如果后续还有timestamp 小于 Watermark 的数据到达，称为迟到数据。

6.3 Watermark是数据吗？怎么生成的？怎么传递的？

  Watermark是一条携带时间戳的特殊数据，从代码指定生成的位置，插入到流里面。

  一对多：广播

  多对一：取最小

  多对多：拆分来看，其实就是上面两种的结合

6.4 Watermark的生成方式？

  间歇性：来一条数据，更新一次watermark

  周期性：固定周期更新watermark

  官方提供的api是基于周期的，默认200ms，因为间歇性会给系统带来压力。

  Watermark=当前最大事件时间-乱序时间-1ms

6.5 窗口（分类、生命周期、触发、划分）

6.5.1 窗口分类： Keyed Window和Non-keyed Window

  基于时间：滚动、滑动、会话

  基于数量：滚动、滑动

6.5.2 Window口的4个相关重要组件：

  assigner（分配器）：如何将元素分配给窗口

  function（计算函数）：为窗口定义的计算。其实是一个计算函数，完成窗口内容的计算

  triger（触发器）：在什么条件下触发窗口的计算

  evictor（退出器）：定义从窗口中移除数据

6.5.3 窗口的划分

  start=按照数据的事件时间向下取窗口长度的整数倍

  end=start+size

    比如开了一个10s的滚动窗口，第一条数据是857s，那么它属于[850s,860s)

6.5.4 窗口的创建

  当属于某个窗口的第一个元素到达，Flink就会创建一个窗口

6.5.5 窗口的销毁

  当时间超过其结束时间+用户指定的允许延迟时间（Flink保证只删除基于时间的窗口，而不能删除其他类型的窗口，例如全局窗口）。

6.5.6 窗口为什么左闭右开

  属于窗口的最大时间戳=end-1ms

6.5.7 窗口什么时候触发

  如基于事件时间的窗口 watermark>=end-1ms

7 Exactly-Once的保证

  一般说的是端到端一致性，要考虑source和sink：

    Source：可重发

    Flink内部：Checkpoint机制（介绍Chandy-Lamport算法、barrier对齐）

    Sink：幂等性 或 事务性 写入

  我们使用的Source和Sink主要是Kafka：

    作为source可以重发，由Flink维护offset，作为状态存储

    作为sink,Flink官方的实现方法是基于两阶段提交，能保证写入的Exactly-Once，分为以下几个步骤：

  ① 开始事务（beginTransaction） 创建一个临时文件夹， 来写把数据写入到这个文件夹里面

  ② 预提交（preCommit） 将内存中缓存的数据写入文件并关闭

  ③ 正式提交（ commit） 将之前写完的临时文件放入目标目录下。 这代表着最终的数据会有一些延迟

  ④ 丢弃（abort） 丢弃临时文件

  ⑤ 若失败发生在预提交成功后， 正式提交前。 可以根据状态来提交预提交的数据， 也可删除预提交的数据。

  如果下级存储不支持事务,具体实现是幂等写入，需要下级存储具有幂等性写入特性。

    比如结合HBase的rowkey的唯一性、数据的多版本，实现幂等

8 Flink分布式快照的原理?

  Flink的容错机制的核心部分是制作分布式数据流和操作算子状态的一致性快照。

  这些快照充当一致性checkpoint，系统可以在发生故障时回滚。 Flink用于制作这些快照的机制在“分布式数据流的轻量级异步快照”中进行了描述。 它受到分布式快照的标准Chandy-Lamport算法的启发，专门针对Flink的执行模型而定制。简单来说就是持续创建分布式数据流及其状态的一致快照。

  barriers在数据流源处被注入并行数据流中。快照n的barriers被插入的位置（我们称之为Sn）是快照所包含的数据在数据源中最大位置。

  例如，在Apache Kafka中，此位置将是分区中最后一条记录的偏移量。 将该位置Sn报告给checkpoint协调器（Flink的JobManager）。

  然后barriers向下游流动。当一个中间操作算子从其所有输入流中收到快照n的barriers时，它会为快照n发出barriers进入其所有输出流中。

  一旦sink操作算子（流式DAG的末端）从其所有输入流接收到barriers n，它就向checkpoint协调器确认快照n完成。

  在所有sink确认快照后，意味快照着已完成。一旦完成快照n，job将永远不再向数据源请求Sn之前的记录，因为此时这些记录（及其后续记录）将已经通过整个数据流拓扑，也即是已经被处理结束。

  核心思想是在 input source 端插入 barrier， 控制 barrier 的同步来实现 snapshot 的备份和 exactly-once 语义。

9 CheckPoint

9.1 Flink 的容错机制（checkpoint）

  Checkpoint 机制是 Flink 可靠性的基石，可以保证 Flink 集群在某个算子因为某些原因(如 异常退出)出现故障时，能够将整个应用流图的状态恢复到故障之前的某一状态，保证应用流图状态的一致性。Flink 的 Checkpoint 机制原理来自“Chandy-Lamport algorithm”算法。

  每个需要 Checkpoint 的应用在启动时，Flink 的 JobManager 为其创建一个
CheckpointCoordinator(检查点协调器)，CheckpointCoordinator 全权负责本应用的快照制作。

  1. CheckpointCoordinator(检查点协调器) 周期性的向该流应用的所有source 算子发送 barrier(屏障)。

  2. 当某个 source 算子收到一个 barrier 时，便暂停数据处理过程，然后将自己的当前状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator 报告自己快照制作情况，同时向自身所有下游算子广播该 barrier，恢复数据处理

  3. 下游算子收到 barrier 之后，会暂停自己的数据处理过程，然后将自身的相关状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator 报告自身快照情况，同时向自身所有下游算子广播该 barrier，恢复数据处理。

  4. 每个算子按照步骤 3 不断制作快照并向下游广播，直到最后 barrier 传递到 sink 算子，快照制作完成。

  5. 当 CheckpointCoordinator 收到所有算子的报告之后，认为该周期的快照制作成功; 否则，如果在规定的时间内没有收到所有算子的报告，则认为本周期快照制作失败。

9.2 Flink checkpoint 与 Spark Streaming 的有什么区别或优势吗

  spark streaming 的 checkpoint 仅仅是针对 driver 的故障恢复做了数据和元数据的 checkpoint。而 flink 的 checkpoint 机制 要复杂了很多，它采用的是轻量级的分布式快照，实现了每个算子的快照，及流动中的数据的快照。

9.3 Checkpoint的参数设置

  1）间隔、语义： 1min~10min，3min，语义默认精准一次

  因为一些异常原因可能导致某些barrier无法向下游传递，造成job失败，对于一些时效性要求高、精准性要求不是特别严格的指标，可以设置为至少一次。

  2）超时 ： 参考间隔， 0.5~2倍之间， 建议0.5倍

  3）最小等待间隔：上一次ck结束 到 下一次ck开始 之间的时间间隔，设置间隔的0.5倍

  4）设置保存ck：Retain

  5）失败次数：5

  6）Task重启策略（Failover）：

    固定延迟重启策略： 重试几次、每次间隔多久

    失败率重启策略： 重试次数、重试区间、重试间隔

10 CEP

  CEP全称为Complex Event Processing，复杂事件处理

  Flink CEP是在 Flink 中实现的复杂事件处理（CEP）库

  CEP 允许在无休止的事件流中检测事件模式，让我们有机会掌握数据中重要的部分

  一个或多个由简单事件构成的事件流通过一定的规则匹配，然后输出用户想得到的数据 —— 满足规则的复杂事件

11 Flink CEP 编程中当状态没有到达的时候会将数据保存在哪里？

  在流式处理中，CEP 当然是要支持 EventTime 的，那么相对应的也要支持数据的迟到现象，也就是watermark的处理逻辑。CEP对未匹配成功的事件序列的处理，和迟到数据是类似的。在 Flink CEP的处理逻辑中，状态没有满足的和迟到的数据，都会存储在一个Map数据结构中，也就是说，如果我们限定判断事件序列的时长为5分钟，那么内存中就会存储5分钟的数据，这在我看来，也是对内存的极大损伤之一。

12 Flink SQL的工作机制？

  通过Calcite对编写的 Sql 进行解析、验证、优化等操作。

  1）在Table/SQL 编写完成后，通过Calcite 中的parse、validate、rel阶段，以及Blink额外添加的convert阶段,将其先转为Operation；

  2）通过Blink Planner 的translateToRel、optimize、translateToExecNodeGraph和translateToPlan四个阶段，将Operation转换成DataStream API的 Transformation；

  3）再经过StreamJraph -> JobGraph -> ExecutionGraph等一系列流程，SQL最终被提交到集群。

13 FlinkSQL怎么对SQL语句进行优化的？

  会使用两个优化器:RBO(基于规则的优化器) 和 CBO(基于代价的优化器)

  1）RBO(基于规则的优化器)会将原有表达式裁剪掉，遍历一系列规则（Rule），只要满足条件就转换，生成最终的执行计划。一些常见的规则包括分区裁剪（Partition Prune）、列裁剪、谓词下推（Predicate Pushdown）、投影下推（Projection Pushdown）、聚合下推、limit下推、sort下推、常量折叠（Constant Folding）、子查询内联转join等。

  2）CBO(基于代价的优化器)会将原有表达式保留，基于统计信息和代价模型，尝试探索生成等价关系表达式，最终取代价最小的执行计划。CBO的实现有两种模型，Volcano模型，Cascades模型。这两种模型思想很是相似，不同点在于Cascades模型一边遍历SQL逻辑树，一边优化，从而进一步裁剪掉一些执行计划。

14 Flink提交流程、组件通讯、任务执行、内存模型

15 Flink常见的维表Join方案

  1）预加载： open（）方法，查询维表，存储下来 ==》 定时查询

   2）热存储： 存在外部系统redis、hbase等

    缓存

    异步查询： 异步io功能

   3）广播维表

   4）Temporal join：外部存储，connector创建

16 公司怎么提交的实时任务，有多少Job Manager？ 有多少TaskManager？

  1）我们使用yarn per-job模式提交任务

  2）集群默认只有一个 Job Manager。但为了防止单点故障，可以配置高可用。对于standlone模式，公司一般配置一个主 Job Manager，两个备用 Job Manager，然后结合 ZooKeeper 的使用，来达到高可用；对于yarn模式，yarn在Job Mananger故障会自动进行重启，所以只需要一个，配置的最大重启次数可以是10次。

  3）基于yarn，动态申请TaskManager的数量

17 Flink的interval join的实现原理？join不上的怎么办？

  底层调用的是keyby+connect ，处理逻辑：

  1）判断是否迟到（迟到就不处理了）

  2）每条流都存了一个Map类型的状态（key是时间戳，value是List存数据）

  3）任一条流，来了一条数据，遍历对方的map状态，能匹配上就发往join方法

  4）超过有效时间范围，会删除对应Map中的数据（不是clear，是remove）

  Interval join不会处理join不上的数据，如果需要没join上的数据，可以用 coGroup+connect算子实现，或者直接使用flinksql里的left join或right join语法。

18 Flink资源配置调优

  Flink性能调优的第一步，就是为任务分配合适的资源，在一定范围内，增加资源的分配与性能的提升是成正比的，实现了最优的资源配置后，在此基础上再考虑进行后面论述的性能调优策略。

  提交方式主要是yarn-per-job，资源的分配在使用脚本提交Flink任务时进行指定。

  标准的Flink任务提交脚本（Generic CLI 模式）：

  从1.11开始，增加了通用客户端模式，参数使用-D <property=value>指定

bin/flink run \
	-t yarn-per-job \
	-d \
	-p 5 \ 指定并行度
	-Dyarn.application.queue=test \ 指定yarn队列
	-Djobmanager.memory.process.size=1024mb \ 指定JM的总进程大小
	-Dtaskmanager.memory.process.size=1024mb \ 指定每个TM的总进程大小
	-Dtaskmanager.numberOfTaskSlots=2 \ 指定每个TM的slot数
	-c com.atguigu.app.dwd.LogBaseApp /opt/module/gmall-flink/gmall-realtime-1.0-SNAPSHOT-jar-with-dependencies.jar

  参数列表：https://ci.apache.org/projects/flink/flink-docs-release-1.12/deployment/config.html

18.1 内存设置

  生产资源配置：

bin/flink run \
	-t yarn-per-job \
	-d \
	-p 5 \ 指定并行度
	-Dyarn.application.queue=test \ 指定yarn队列
	-Djobmanager.memory.process.size=2048mb \ JM2~4G足够
	-Dtaskmanager.memory.process.size=6144mb \ 单个TM2~8G足够
	-Dtaskmanager.numberOfTaskSlots=2 \ 与容器核数1core：1slot或1core：2slot
	-c com.atguigu.app.dwd.LogBaseApp /opt/module/gmall-flink/gmall-realtime-1.0-SNAPSHOT-jar-with-dependencies.jar

  Flink是实时流处理，关键在于资源情况能不能抗住高峰时期每秒的数据量，通常用QPS/TPS来描述数据情况。

18.2 并行度设置

18.2.1 最优并行度计算

  开发完成后，先进行压测。任务并行度给10以下，测试单个并行度的处理上限。然后 总QPS/单并行度的处理能力 = 并行度

  不能只从QPS去得出并行度，因为有些字段少、逻辑简单的任务，单并行度一秒处理几万条数据。而有些数据字段多，处理逻辑复杂，单并行度一秒只能处理1000条数据。

  最好根据高峰期的QPS压测，并行度*1.2倍，富余一些资源。

18.2.2 Source 端并行度的配置

  数据源端是 Kafka，Source的并行度设置为Kafka对应Topic的分区数。

  如果已经等于 Kafka 的分区数，消费速度仍跟不上数据生产速度，考虑下Kafka 要扩大分区，同时调大并行度等于分区数。

  Flink 的一个并行度可以处理一至多个分区的数据，如果并行度多于 Kafka 的分区数，那么就会造成有的并行度空闲，浪费资源。

18.2.3 Transform端并行度的配置

Keyby之前的算子

  一般不会做太重的操作，都是比如map、filter、flatmap等处理较快的算子，并行度可以和source保持一致。

Keyby之后的算子

  如果并发较大，建议设置并行度为 2 的整数次幂，例如：128、256、512；

  小并发任务的并行度不一定需要设置成 2 的整数次幂；

  大并发任务如果没有 KeyBy，并行度也无需设置为 2 的整数次幂；

18.2.4 Sink 端并行度的配置

  Sink 端是数据流向下游的地方，可以根据 Sink 端的数据量及下游的服务抗压能力进行评估。如果Sink端是Kafka，可以设为Kafka对应Topic的分区数。

  Sink 端的数据量小，比较常见的就是监控告警的场景，并行度可以设置的小一些。

  Source 端的数据量是最小的，拿到 Source 端流过来的数据后做了细粒度的拆分，数据量不断的增加，到 Sink 端的数据量就非常大。那么在 Sink 到下游的存储中间件的时候就需要提高并行度。

  另外 Sink 端要与下游的服务进行交互，并行度还得根据下游的服务抗压能力来设置，如果在 Flink Sink 这端的数据量过大的话，且 Sink 处并行度也设置的很大，但下游的服务完全撑不住这么大的并发写入，可能会造成下游服务直接被写挂，所以最终还是要在 Sink 处的并行度做一定的权衡。

18.3 RocksDB大状态调优

   RocksDB 是基于 LSM Tree 实现的（类似HBase），写数据都是先缓存到内存中，所以RocksDB 的写请求效率比较高。RocksDB 使用内存结合磁盘的方式来存储数据，每次获取数据时，先从内存中 blockcache 中查找，如果内存中没有再去磁盘中查询。 优化后差不多单并行度 TPS 5000 record/s，性能瓶颈主要在于 RocksDB 对磁盘的读请求，所以当处理性能不够时，仅需要横向扩展并行度即可提高整个Job 的吞吐量。以下几个调优参数：

  设置本地 RocksDB 多目录

  在flink-conf.yaml 中配置：

state.backend.rocksdb.localdir: /data1/flink/rocksdb,/data2/flink/rocksdb,/data3/flink/rocksdb

  注意：不要配置单块磁盘的多个目录，务必将目录配置到多块不同的磁盘上，让多块磁盘来分担压力。当设置多个 RocksDB 本地磁盘目录时，Flink 会随机选择要使用的目录，所以就可能存在三个并行度共用同一目录的情况。如果服务器磁盘数较多，一般不会出现该情况，但是如果任务重启后吞吐量较低，可以检查是否发生了多个并行度共用同一块磁盘的情况。

  当一个 TaskManager 包含 3 个 slot 时，那么单个服务器上的三个并行度都对磁盘造成频繁读写，从而导致三个并行度的之间相互争抢同一个磁盘 io，这样务必导致三个并行度的吞吐量都会下降。设置多目录实现多个并行度使用不同的硬盘从而减少资源竞争。

  如下所示是测试过程中磁盘的 IO 使用率，可以看出三个大状态算子的并行度分别对应了三块磁盘，这三块磁盘的 IO 平均使用率都保持在 45% 左右，IO 最高使用率几乎都是 100%，而其他磁盘的 IO 平均使用率相对低很多。由此可见使用 RocksDB 做为状态后端且有大状态的频繁读取时， 对磁盘IO性能消耗确实比较大。

  如下图所示，其中两个并行度共用了 sdb 磁盘，一个并行度使用 sdj磁盘。可以看到 sdb 磁盘的 IO 使用率已经达到了 91.6%，就会导致 sdb 磁盘对应的两个并行度吞吐量大大降低，从而使得整个 Flink 任务吞吐量降低。如果每个服务器上有一两块 SSD，强烈建议将 RocksDB 的本地磁盘目录配置到 SSD 的目录下，从 HDD 改为 SSD 对于性能的提升可能比配置 10 个优化参数更有效。

  state.backend.incremental：开启增量检查点，默认false，改为true。

  state.backend.rocksdb.predefined-options: SPINNING_DISK_OPTIMIZED_HIGH_MEM设置为机械硬盘+内存模式，有条件上SSD，指定为FLASH_SSD_OPTIMIZED

  从Flink1.10开始，Flink默认将RocksDB的内存大小配置为每个task slot的托管内存。调试内存性能的问题主要是通过调整配置项taskmanager.memory.managed.size 或者 taskmanager.memory.managed.fraction以增加Flink的托管内存(即堆外内存)。对于更细粒度的控制，应该首先通过设置 state.backend.rocksdb.memory.managed为false，禁用自动内存管理，然后调整如下配置项：

  ① state.backend.rocksdb.block.cache-size: 整个 RocksDB 共享一个 block cache，读数据时内存的 cache 大小，该参数越大读数据时缓存命中率越高，默认大小为 8 MB，建议设置到 64 ~ 256 MB。

  ② state.backend.rocksdb.thread.num: 用于后台 flush 和合并 sst 文件的线程数，默认为 1，建议调大，机械硬盘用户可以改为 4 等更大的值。

  ③ state.backend.rocksdb.writebuffer.size: RocksDB 中，每个 State 使用一个 Column Family，每个 Column Family 使用独占的 write buffer，默认64MB。建议调大，调整这个参数通常要适当增加 L1 层的大小阈值max-size-level-base

  ④ state.backend.rocksdb.compaction.level.max-size-level-base：增大write buffer，一定需要增大level1层的阈值，该值太小会造成能存放的SST文件过少，层级变多造成查找困难，太大会造成文件过多，合并困难。建议设为 target_file_size_base（默认64MB） 的倍数，且不能太小，例如5_{10倍，即320}640MB。

  ⑤ state.backend.rocksdb.writebuffer.count: 每个 Column Family 对应的 writebuffer 数目，默认值是 2，对于机械磁盘来说，如果内存⾜够大，可以调大到 5 左右

  ⑥ state.backend.rocksdb.writebuffer.number-to-merge: 将数据从 writebuffer 中 flush 到磁盘时，需要合并的 writebuffer 数量，默认值为 1，可以调成3。

  ⑦ state.backend.local-recovery: 设置本地恢复，当 Flink 任务失败时，可以基于本地的状态信息进行恢复任务，可能不需要从 hdfs 拉取数据

18.4 Checkpoint设置

  一般Checkpoint 时间间隔可以设置为分钟级别，例如 1 分钟、3 分钟，对于状态很大的任务每次 Checkpoint 访问 HDFS 比较耗时，可以设置为 5~10 分钟一次Checkpoint，并且调大两次 Checkpoint 之间的暂停间隔，例如设置两次Checkpoint 之间至少暂停 4或8 分钟。

  如果 Checkpoint 语义配置为 EXACTLY_ONCE，那么在 Checkpoint 过程中还会存在 barrier 对齐的过程，可以通过 Flink Web UI 的 Checkpoint 选项卡来查看 Checkpoint 过程中各阶段的耗时情况，从而确定到底是哪个阶段导致 Checkpoint 时间过长然后针对性的解决问题。

  RocksDB相关参数在1.3中已说明，可以在flink-conf.yaml指定，也可以在Job的代码中调用API单独指定，这