Flink 使用介绍相关文档目录

Flink 使用介绍相关文档目录

Flink常用参数配置

端口地址

jobmanger.rpc.address jm的地址。

jobmanager.rpc.port jm的端口号。

web.port Flink web ui的端口号。

jobmanager.archive.fs.dir 将已完成的任务归档存储的目录。

history.web.port 基于web的history server的端口号。

historyserver.archive.fs.dir history server的归档目录。该配置必须包含jobmanager.archive.fs.dir配置的目录，以便history server能够读取到已完成的任务信息。

historyserver.archive.fs.refresh-interval 刷新存档作业目录时间间隔。

fs.hdfs.hadoopconf hadoop配置文件路径（已被废弃，建议使用HADOOP_CONF_DIR环境变量）

yarn.application-attempts job失败尝试次数，主要是指job manager的重启尝试次数。该值不应该超过yarn-site.xml中的yarn.resourcemanager.am.max-attemps的值。

资源配置

jobmanager.heap.mb jm的堆内存大小。不建议配的太大，1-2G足够。

taskmanager.heap.mb tm的堆内存大小。大小视任务量而定。需要存储任务的中间值，网络缓存，用户数据等。

taskmanager.network.memory.max 网络缓冲区最大内存大小。

taskmanager.network.memory.min 网络缓冲区最小内存大小。

taskmanager.network.memory.fraction 网络缓冲区使用的内存占据总JVM内存的比例。如果配置了taskmanager.network.memory.max和taskmanager.network.memory.min，本配置项会被覆盖。

taskmanager.memory.task.off-heap.size：任务使用的堆外内存。

taskmanager.memory.flink.size：总flink内存。适用于standalone模式。

taskmanager.memory.process.size：总进程内存。适用于container模式（yarn，k8s等）。

taskmanager.memory.managed.size：managed内存。流任务可用于rockdb转台后端。批任务可以用于排序，hash表和中间结果缓存。

taskmanager.numberOfTaskSlots slot数量。在yarn模式使用的时候会受到yarn.scheduler.maximum-allocation-vcores值的影响。此处指定的slot数量如果超过yarn的maximum-allocation-vcores，flink启动会报错。在yarn模式，flink启动的task manager个数可以参照如下计算公式：

num_of_tm = ceil(parallelism / slot)

即并行度除以slot个数，结果向上取整。

parallelsm.default 任务默认并行度，如果任务未指定并行度，将采用此设置。

Flink内存关系图

参见：
https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/memory/mem_detail.html#framework-memory

Flink 运行batch job尽量配置更大的managed memory

状态后端

state.backend 存储和检查点的后台存储。可选值为rocksdb filesystem hdfs。

state.backend.fs.checkpointdir 检查点数据文件和元数据的默认目录。

state.checkpoints.dir 保存检查点目录。

state.savepoints.dir save point的目录。

state.checkpoints.num-retained 保留最近检查点的数量。

state.backend.incremental 增量存储。

Akka

akka.ask.timeout Job Manager和Task Manager通信连接的超时时间。如果网络拥挤经常出现超时错误，可以增大该配置值。

akka.watch.heartbeat.interval 心跳发送间隔，用来检测task manager的状态。

akka.watch.heartbeat.pause 如果超过该时间仍未收到task manager的心跳，该task manager 会被认为已挂掉。

Netty

taskmanager.network.netty.server.numThreads和taskmanager.network.netty.client.numThreads：netty的客户端和服务端的线程数目，默认为taskmanager.numberOfTaskSlots

taskmanager.network.netty.client.connectTimeoutSec：taskmanager的客户端连接超时的时间，默认为120s

taskmanager.network.netty.sendReceiveBufferSize：netty的发送和接收的缓冲区大小

taskmanager.network.netty.transport：netty的传输方式，默认为nio。可选nio和epoll

Flink HA(Job Manager)的配置

high-availability: zookeeper 使用zookeeper负责HA实现
high-availability.zookeeper.path.root: /flink flink信息在zookeeper存储节点的名称
high-availability.zookeeper.quorum: zk1,zk2,zk3 zookeeper集群节点的地址和端口
high-availability.storageDir: hdfs://nameservice/flink/ha/ job manager元数据在文件系统储存的位置，zookeeper仅保存了指向该目录的指针。

Flink metrics 监控相关配置

下面例子中为Prometheus监控的相关配置

metrics.reporters: prom
metrics.reporter.prom.class: org.apache.flink.metrics.prometheus.PrometheusReporter
metrics.reporter.prom.port: 9250-9260

缓冲区超时配置

该配置项可以平衡吞吐量和延迟。设置值的解释如下：

• -1：直到缓冲区填满才发送，最大化吞吐量
• 0：一有数据就立刻发送，最小化延迟
• 其他值：在配置时间后发送，如果在配置时间内缓冲区填满，则立刻发送

设置方法：

env.setBufferTimeout(xxx)

提交应用时参数配置

注意：per-job模式或者application模式可以为某个作业单独指定JM和TM的资源消耗。资源的消耗情况应该以能扛住高峰时段的数据处理压力为准。可提前对集群进行压测，记录极限情况的资源使用量。

JobManager内存

yarn-session：-jm 2048
yarn-cluster：-yjm 2048

TaskManager内存

yarn-session：-tm 2048
yarn-cluster：-ytm 2048

每个TaskManager 的slot个数

yarn-session：-s 8
yarn-cluster：-ys 8

通过系统变量方式配置

还可以在提交作业的时候使用-D参数配置。支持的参数如下：

-Dyarn.application.queue=test \ 指定yarn队列
-Djobmanager.memory.process.size=2048mb \ 指定JM的总进程大小
-Dtaskmanager.memory.process.size=2048mb \ 指定每个TM的总进程大小
-Dtaskmanager.numberOfTaskSlots=2 \ 指定每个TM的slot数

Kafka相关调优配置

linger.ms/batch.size 这两个配置项配合使用，可以在吞吐量和延迟中得到最佳的平衡点。batch.size是kafka producer发送数据的批量大小，当数据量达到batch size的时候，会将这批数据发送出去，避免了数据一条一条的发送，频繁建立和断开网络连接。但是如果数据量比较小，导致迟迟不能达到batch.size，为了保证延迟不会过大，kafka不能无限等待数据量达到batch.size的时候才发送。为了解决这个问题，引入了linger.ms配置项。当数据在缓存中的时间超过linger.ms时，无论缓存中数据是否达到批量大小，都会被强制发送出去。
ack 数据源是否需要kafka得到确认。all表示需要收到所有ISR节点的确认信息，1表示只需要收到kafka leader的确认信息，0表示不需要任何确认信息。该配置项需要对数据精准性和延迟吞吐量做出权衡。

Kafka topic分区数和Flink并行度的关系

Flink Kafka source的并行度需要和kafka topic的分区数一致。最大化利用kafka多分区topic的并行读取能力。由于一个Kafka分区只能被一个消费者消费，因此一定要确保Flink Kafka source的并行度不要大于Kafka分区数，否则有些计算资源会空闲。如果并行度和分区数相同配置后，消费数据的速度仍然跟不上生产数据的速度，需要加大Kafka的分区数。

同理，如果Sink端也是Kafka，sink的平行度尽量和Kafka分区数一致。

Yarn相关调优配置

yarn.scheduler.maximum-allocation-vcores
yarn.scheduler.minimum-allocation-vcores

Flink单个task manager的slot数量必须介于这两个值之间

yarn.scheduler.maximum-allocation-mb
yarn.scheduler.minimum-allocation-mb

Flink的job manager 和task manager内存不得超过container最大分配内存大小。

yarn.nodemanager.resource.cpu-vcores yarn的虚拟CPU内核数，建议设置为物理CPU核心数的2-3倍，如果设置过少，会导致CPU资源无法被充分利用，跑任务的时候CPU占用率不高。

数据倾斜问题

几个解决套路：

• 尽量使用大的并行度
• 避免使用Map作为分区字段数据类型，同样避免使用String
• 避免使用windowAll等无法并发操作的算子
• 使用合适的分区方法

分区方法有如下几种：

• shuffle：随机分区
• rebalance：轮询
• rescale：每个源的数据分散给下游，类似于一对多，这点和rebalance不同
• broadcast：广播
• 自定义分区，一个例子如下所示：

stream.partitionCustom(new Partitioner[String] {
  override def partition(key: String, numPartitions: Int): Int = {
    key.hashCode % numPartitions
  }
}, s => s.charAt(0).toString)

这个例子取首字母作为key，使用key的hashCode和分区数取余后的值作为分区编号。

并行度配置

并行度一般配置为CPU核心数的2-3倍。

并行度配置的几个层次如下所示。从上到下作用范围依次增大，但是上面的配置可以覆盖下面的配置。

• 算子层次。算子的setParallelism方法
• 执行环境层次。env的setParallelism方法
• 客户端层次。提交任务时候的-p参数
• 系统层次。flink-conf.yaml配置文件，parallelism.default配置项。

JVM参数配置

以增加GC日志为例，修改"conf/flink-conf.yaml配置文件的env.java.opts参数，增加：

-Xloggc:/path/to/gc_log.log
-XX:+PrintGCDetails 
-XX:-OmitStackTraceInFastThrow 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDateStamps 
-XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=10 
-XX:GCLogFileSize=50M

Checkpoint

Checkpoint周期性进行。如果checkpoint操作耗时比checkpoint间隔时间还长，在上一个checkpoint未完成的时候，即便到了下一个checkpoint触发时间，新的checkpoint操作不会立即开始。只有在前一个checkpoint完成之后下一个checkpoint才能开始。这种情况下checkpoint会一直进行下去，严重影响系统性能。

为了避免这种情况，可以指定checkpoint之间的最小时间间隔。方法如下：

StreamExecutionEnvironment.getCheckpointConfig().setMinPauseBetweenCheckpoints(milliseconds)

注意：可以在应用中通过配置CheckpointConfig，可以允许多个checkpoint过程同步执行。

除此之外，checkpoint还支持更多的配置：

// 开启Checkpoint，设置间隔时间
env.enableCheckpointing(TimeUnit.MINUTES.toMillis(10));
// 配置 Checkpoint
CheckpointConfig checkpointConf = env.getCheckpointConfig();
// 启用EXACTLY_ONCE模式，使用Unaligned Checkpoint，保证数据精准一次投送，但会略微增大延迟
// 启用AT_LEAST_ONCE模式，barrier不会对齐，投送数据可能会重复，但是延迟很低
checkpointConf.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE)
// 最小间隔时间，上面已介绍过
checkpointConf.setMinPauseBetweenCheckpoints(TimeUnit.MINUTES.toMillis(10))
// 超时时间。如果超过这个时间checkpoint操作仍未完成，checkpoint会被废弃
checkpointConf.setCheckpointTimeout(TimeUnit.MINUTES.toMillis(10));
// 作业取消后checkpoint仍然保留（需要人工清理）
checkpointConf.enableExternalizedCheckpoints(
CheckpointConfig.ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);

使用RocksDB backend

RocksDB支持增量checkpoint，相比全量checkpoint而言耗时更短。

启用增量checkpoint方法，在flink-conf.yaml中增加：

state.backend.incremental: true

也可以在代码中设置：

RocksDBStateBackend backend = new RocksDBStateBackend(checkpointDirURI, true);
env.setStateBackend(backend);

RocksDB调优参见: https://mp.weixin.qq.com/s/YpDi3BV8Me3Ay4hzc0nPQA

调整SSTable的block和block cache

state.backend.rocksdb.block.blocksize
state.backend.rocksdb.block.cache-size

经过实践这两个参数值对checkpoint性能影响较大。

使用全局参数

可以通过全局参数的方式，将参数从JobManager传递给各个TaskManager。

在JobManager中注册全局参数（ParameterTool是可序列化的）：

env.getConfig().setGlobalJobParameters(ParameterTool.fromArgs(args));

TaskManager中，通过Rich函数中使用如下方式获取全局参数：

ParameterTool parameterTool = (ParameterTool)getRuntimeContext().getExecutionConfig().getGlobalJobParameters();

使用分布式缓存

上一节介绍了如何为各个TaskManager传递参数。这里的分布式缓存则用于向各个TaskManager分发文件。

注意：AsyncFunction不支持分布式缓存，直接使用会抛出异常。

首先，需要在JobManager注册需要分发的文件。注册的文件由JobManager发送给各个TaskManager，保存在TM运行环境的临时目录中。

val env = ExecutionEnvironment.getExecutionEnvironment

env.registerCachedFile("d:\\data\\file\\a.txt","b.txt")

然后TaskManager使用的时候，通过Rich函数拉取文件：

getRuntimeContext.getDistributedCache.getFile("b.txt")

反压分析

性能瓶颈测试方法

测试反压可以快速的定位流处理系统的性能瓶颈所在。先在Kafka中积攒一批数据，然后在使用Flink消费，就好比水库泄洪，很容易找到下游性能薄弱的环节。

反压的可能原因

反压的原因可能会有：

• 短时间的负载高峰，超过流处理系统极限
• 下游sink负载变大，数据无法及时输出
• GC压力过大，停顿时间太长
• 某个算子作业过于复杂，执行耗时较长
• 集群网络波动，上游传递给下游的网络通道受阻

定位方式

定位之前禁用掉OperatorChain，这样原本chain到一起的多个算子会分开，方便我们更精细的定位性能瓶颈。

• 看页面：查看Flink Web UI中对应算子的Back Pressure页面，如果各个SubTask显示的结果为High，说明该算子存在反压情况。
• 看监控：查看算子的inPoolUsage监控项。如果数值过高，说明存在反压。

找到反压算子之后，我们可以使用Flame Graph火焰图，来分析每个方法调用的耗时，从而找到耗时较长的方法。

开启火焰图的方法：

在flink-conf.yaml中配置。

参数	默认值	含义
rest.flamegraph.enabled	false	是否开启火焰图
rest.flamegraph.cleanup-interval	10min	统计信息的缓存清除时间
rest.flamegraph.delay-between-samples	50 ms	构建 FlameGraph 的单个堆栈跟踪样本之间的延迟
rest.flamegraph.num-samples	100	构建flamegraph的采样数
rest.flamegraph.refresh-interval	1 min	火焰图刷新的时间间隔
rest.flamegraph.stack-depth	100	创建FlameGraphs 的堆栈跟踪的最大深度

一些通用的方法：

• 优化反压算子的业务逻辑代码
• 调用外部系统使用AsyncFunction
• 增大TM的内存资源
• 增大反压算子的并行度
• 减少反压上游算子的并行度

分区空闲检测

Barrier对齐环节（一个算子有多个input）需要收集齐各个input的watermark才放行数据，如果某一个input的数据量很少，导致该input迟迟收不到watermark，则整个数据链路会被阻塞。

为了解决这个问题，Flink提供了分区空闲检测功能，如果某个input在一段时间内没有收到数据，会被标记为空闲。在barrier对齐环节，这个input上面的watermark会被忽略。

配置分区空闲判定时间的方法如下：

SourceFunction.assignTimestampsAndWatermarks(
                WatermarkStrategy
                        .forBoundedOutOfOrderness(Duration.ofMinutes(2))
                        .withIdleness(Duration.ofMinutes(5))
);

作业提交方式

参考链接：YARN | Apache Flink

Flink作业提交的方式分为application模式，per-job模式和session模式。

per-job模式

在Yarn创建一个Flink集群，然后在提交任务客户端所在机器本地运行作业jar的main方法，提交生成的JobGraph到Flink集群的JobManager。如果附带--detached参数，提交的作业被accept的时候，客户端会停止运行（命令行不用一直开着，生产环境必须。开发测试时可不带--detached参数，通过命令行查看运行日志）。

实际生产中推荐使用此模式。每个作业都使用单独的Flink集群，它们消耗的资源是互相隔离的，一个作业的崩溃不会影响到其他作业。

flink run -t yarn-per-job --detached /path/to/job.jar

session模式

首先启动Flink Yarn Session，它是一个常驻与Yarn的Flink集群。启动成功后，无论是否有作业执行，或者作业是否执行完毕，该session始终保持运行。启动yarn session的方法如下：

export HADOOP_CLASSPATH=`hadoop classpath`
./bin/yarn-session.sh --detached

yarn-session支持的相关参数解释：

• -d/--detached: Detach模式，session启动成功后client停止运行。不用保持控制台一直开启。
• -nm: Application名称
• -jm: Job Manager 容器的内存
• -tm: Task Manager 容器的内存
• -t: 传送文件至集群，使用相对路径。程序中读取文件仍使用相对路径
• -qu: 指定使用的Yarn队列

提交作业到Yarn session：

flink run -t yarn-session \
  -Dyarn.application.id=application_XXXX_YY \
  /path/to/job.jar

停止Flink Yarn session可以通过Yarn UI的kill按钮。当然也可以通过如下方式：

echo "stop" | ./bin/yarn-session.sh -id application_XXXXX_XXX

注意：一个Flink Yarn Session可以同时跑多个Flink作业。

application模式

和per-job模式类似，提交一次任务会在Yarn运行一个Flink集群。不同之处为作业jar包的main方法在Yarn集群的JobManager上运行，而不是提交作业的client端运行。作业执行完毕后，Flink on yarn集群会被关闭。

flink run-application -t yarn-application /path/to/job.jar

application模式的好处是Flink yarn集群可以直接从HDFS上查找并下载作业jar以及所需依赖，避免了从client机器上传。

flink run-application -t yarn-application \
    -Dyarn.provided.lib.dirs="hdfs://myhdfs/my-remote-flink-dist-dir" \
    hdfs://myhdfs/jars/my-application.jar

其中yarn.provided.lib.dirs为Flink作业所需依赖包的地址。