Flink性能调优

已于 2022-11-02 21:53:20 修改
阅读量5.7k 收藏 40
点赞数 5
分类专栏： BigData 文章标签： flink java 大数据
于 2022-02-14 17:04:34 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xiaoyixiao_/article/details/122928240
版权

目录

资源配置调优

资源配置概述

Flink性能调优的第一步，就是为任务分配合适的资源，在一定范围内，增加资源的分配与性能的提升是成正比的，实现了最优的资源配置后，在此基础上再考虑进行后面论述的性能调优策略。提交方式主要是yarn-per-job，资源的分配在使用脚本提交Flink任务时进行指定

官网可配置参数列表

Task Manager内存模型

image-20220213172238860

image-20220213172214791

JVM 元空间：taskmanager.memory.jvm-metaspace.size，默认256mb

JVM overhead执行开销：JVM执行时自身所需要的内容，包括线程堆栈、IO、编译缓存等所使用的内存

  • taskmanager.memory.jvm-overhead.fraction，默认0.1
  • taskmanager.memory.jvm-overhead.min，默认192mb
  • taskmanager.memory.jvm-overhead.max，默认1gb
  • 总进程内存*fraction，如果小于配置的min(或大于配置的max)大小，则使用min/max大小

框架内存：Flink框架，即TaskManager本身所占用的内存，不计入Slot的资源中。

  • 堆内：taskmanager.memory.framework.heap.size，默认128MB
  • 堆外：taskmanager.memory.framework.off-heap.size，默认128MB

Task内存：Task执行用户代码时所使用的内存

  • 堆内：taskmanager.memory.task.heap.size，默认none，由Flink内存扣除掉其他部分的内存得到
  • 堆外：taskmanager.memory.task.off-heap.size，默认0，表示不使用堆外内存

网络内存：网络数据交换所使用的堆外内存大小，如网络数据交换缓冲区

  • taskmanager.memory.network.fraction，默认0.1
  • taskmanager.memory.network.min，默认64mb
  • taskmanager.memory.network.max，默认1gb
  • Flink内存*fraction，如果小于配置的min(或大于配置的 max)大小，则使用min/max大小

托管内存：用于RocksDB State Backend的本地内存和批的排序、哈希表、缓存中间结果

  • taskmanager.memory.managed.fraction，默认0.4
  • taskmanager.memory.managed.size，默认none
  • 如果size没指定，则等于Flink内存*fraction

基于yarn模式，一般参数指定的是总进程内存，taskmanager.memory.process.size,指定为4G内存模型计算如下

JVM元空间：256M

JVM执行开销：4g*0.1=409.6m,在[192m,1g]之间，最终结果409.6m

fink内存=进程内存=4g-256m-409.6m=3430.4m

网络内存=3430.4m*0.1=343.04m，在[64m,1g]之间，最终结果343.04m

托管内存=3430.4m*0.4=1372.16m

框架内存，堆内和堆外都是 128m

Task堆内内存=3430.4m-128m-128m-343.04m-1372.16m=1459.2m

进程内存给多大，每一部分内存需不需要调整，可以看内存的使用率来调整

# export hadoop环境
export HADOOP_HOME='/opt/module/hadoop-3.1.3'
export HADOOP_CONF_DIR='/opt/module/hadoop-3.1.3/etc/hadoop/'
export HADOOP_CONFIG_DIR='/opt/module/hadoop-3.1.3/etc/hadoop/'
export HADOOP_CLASSPATH=`hadoop classpath`

# 指定并行度5,指定yarn队列为test，指定Job Manager大小为2G，指定Task Manager为4G，指定容器核数1core：1slot或2core：1slot，关闭classloader检查
bin/flink run \
-t yarn-per-job \
-d \
-p 5 \
-Dyarn.application.queue=test \
-Djobmanager.memory.process.size=2048mb \
-Dtaskmanager.memory.process.size=4096mb \
-Dtaskmanager.numberOfTaskSlots=1 \
-c czs.study.flink.WordCount \
./flinkyarncluster-1.0-SNAPSHOT-jar-with-dependencies.jar

分配CPU资源

Yarn的容量调度器默认情况下使用的是DefaultResourceCalculator分配策略，只根据内存调度资源，所以在yarn的资源管理页面上看到每个容器的vcore个数是1，可以修改策略为DominantResourceCalculator，该资源计算器在计算资源的时候会综合考虑cpu和内存的情况。在capacity-scheduler.xml中修改属性

<property>
    <name>yarn.scheduler.capacity.resource-calculator</name>
    <!-- <value>org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator</value> -->
    <value>org.apache.hadoop.yarn.util.resource.DominantResourceCalculator</value>
</property>

image-20220214142953649

image-20220214143501372

DominantResourceCalculator策略指定容器vcore数及每个容器核数


bin/flink run \
-t yarn-per-job \
-d \
-p 1 \
-Djobmanager.memory.process.size=2048mb \
-Dtaskmanager.memory.process.size=4096mb \
-Dyarn.containers.vcores=3 \
-Dtaskmanager.numberOfTaskSlots=4 \
-c czs.study.flink.WordCount \
./flinkyarncluster-1.0-SNAPSHOT-jar-with-dependencies.jar

image-20220214144040197

image-20220214144532859

并行度设置

任务并行度一般给到10以下，测试单个并行度的处理上限，然后总QPS/单并行度的处理能力 = 并行度，一般根据高峰期的QPS进行压测，并行度*1.2倍，富于一些资源

source端并行度配置

如果数据源端是kafka，source的并行度设置为kafka对应topic的分区数，如果已经等于kafka的分区数，消费数据仍跟不上数据生产的速度，要扩大分区，同时调大并行度等于分区数。Flink的一个并行度可以处理一至多个分区的数据，如果并行度多于kafka的分区数，那么就会造成有的并行度空闲，浪费资源。

transform端并行度配置

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

keyby之后的算子，如果并发度较大，建议设置并行度为2的整数次幂，例如：128、256、512。小并发任务的并行度不一定需要设置成2的整数次幂。大并发任务如果没有keyby，并行度也无需设置为2 的整数次幂。

sink端并行度的配置

sink端是数据向下游的地方，可以根据sink端的数据量及下游的服务抗压能力进行评估。如果sink端是kafka，可以设为kafka对应topic的分区数。sink端的数据量小，如监控告警的场景，并行度可以设置的小一些。source端的数据量是最小的，拿到source端流过来的数据后做了细粒度的拆分，数据量不断的增加，到sink端的数据量就非常大。那么在sink到下游的存储中间件的时候就需要提高并行度。另外sink端要与下游的服务进行交互，并行度还得根据下游的服务抗压能力来设置， 如果在flink sink这端的数据量过大的话，且sink处并行度也设置的很大，但下游的服务完全撑不住这么大的并发写入，可能会造成下游服务直接被写挂，所以最终还是要在sink处的并行度做一定的权衡。

状态及CheckPoint调优

RocksDB大状态调优

RocksDB是基于LSM Tree实现的(类似 Hbase)，写数据都是先缓存到内存中，所以Rocks的写请求效率比较高。Rocks DB使用内存结合磁盘的方式来存储数据，每次获取数据时，先从内存中blockcache中查找，如果内存中没有再去磁盘中查询。使用RocksDB时，状态大小仅受可用磁盘空间里的限制，性能瓶颈主要在于RocksDB对磁盘的读请求，每次读写操作都必须对数据进行反序列化或者序列化。当处理性能不够时，仅需要横向扩展并行度即可提高整个Job的吞吐量。

image-20220214150434521

从Flink1.10开始，Flink默认将RocksDB的内存大小配置为每个task slot的托管内存。调试内存性能的问题主要是通过调整配置项taskmanager.memory.managed.size或者taskmanager.memory.managed.fraction以增加Flink的托管内存(即堆外的托管内存)。进一步可以调整一些参数进行高级性能调优，这些参数也可以在应用程序中通过RocksDBStateBackend.setRocksDBOptions(RocksDBOptionsFactory)指定

开启State访问性能监控

image-20220214151302541

Flink1.13中引入了State访问的性能监控，即latency trackig state。此功能不局限于State Backend的类型，自定义实现的State Backend也可以复用此功能

State访问的性能监控会产生一定的性能影响，所以，默认每100次做一次取样，对不同的State Backend性能损失影响不同，对于RocksDB类型的性能损失大概在1%，对于Heap类型的性能损失最多可达10%

state.backend.latency-track.keyed-state-enabled：true #启用访问状态的性能监控
state.backend.latency-track.sample-interval: 100 #采样间隔
state.backend.latency-track.history-size: 128 #保留的采样数据个数，越大越精确
state.backend.latency-track.state-name-as-variable: true #将状态名作为变量

正常开启第一个参数即可-Dstate.backend.latency-track.keyed-state-enabled=true

bin/flink run \
-t yarn-per-job \
-d \
-p 1 \
-Djobmanager.memory.process.size=2048mb \
-Dtaskmanager.memory.process.size=4096mb \
-Dtaskmanager.numberOfTaskSlots=2 \
-Dstate.backend.latency-track.keyed-state-enabled=true \
-c czs.study.flink.WordCount \
./flinkyarncluster-1.0-SNAPSHOT-jar-with-dependencies.jar

开启增量检查点和本地恢复

开启增量检查点：Rocks DB是目前唯一可用于支持有状态流处理应用程序增量检查点的状态后端，可以修改参数开启增量检查点

state.backend.incremental: true # 默认 false，改为 true。
或代码中指定
new EmbeddedRocksDBStateBackend(true)

开启本地恢复：当Flink任务失败时，可以基于本地的状态信息进行恢复任务，可能不需要从hdfs拉取数据。本地恢复目前仅涵盖键控类型的状态后端(RocksDB)，MemoryStateBackend不支持本地恢复并忽略此选项

state.backend.local-recovery: true

设置多目录：如果有多块磁盘，也可以考虑指定本地多目录。不要配置单块磁盘的多个目录，务必将目录配置到多块不同的磁盘上，让多块磁盘来分担压力

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

bin/flink run \
-t yarn-per-job \
-d \
-p 1 \
-Djobmanager.memory.process.size=2048mb \
-Dtaskmanager.memory.process.size=4096mb \
-Dtaskmanager.numberOfTaskSlots=2 \
-Dstate.backend.incremental=true \
-Dstate.backend.local-recovery=true \
-Dstate.backend.latency-track.keyed-state-enabled=true \
-c czs.study.flink.WordCount \
./flinkyarncluster-1.0-SNAPSHOT-jar-with-dependencies.jar

调整预定义选项

Flink针对不同的设置为Rocks DB提供了一些预定义的选项集合，如果调整预定义选项后还达不到预期，再去调整block、writebuffer等参数

当前支持的预定义选项有DEFAULT、SPINNING_DISK_OPTIMIZED、SPINNING_DISK_OPTIMIZED_HIGH_MEM或FLASH_SSD_OPTIMIZED。有条件上SSD 的，可以指定为FLASH_SSD_OPTIMIZED

#设置为机械硬盘+内存模式
state.backend.rocksdb.predefined-options： SPINNING_DISK_OPTIMIZED_HIGH_MEM

增大block缓存

整个Rocks DB共享一个block cache，读数据时内存的cache大小，该参数越大读数据时缓存命中率越高，默认大小为8MB，建议设置到64-256MB

# 默认 8m
state.backend.rocksdb.block.cache-size: 64m

增大write buffer和level阈值大小

RocksDB中，每个State使用一个Column Family，每个Column Family使用独占的write buffer，默认64MB，建议调大。调整这个参数通常要适当增加level的大小阈值max-size-level-base，默认256m。该值太小会造成能存放的SST文件过少，层级变多造成查找困难，太大会造成文件过多，合并困难。建议设为target_file_size_base（默认64MB）的倍数，且不能太小，例如510倍，即320640MB

state.backend.rocksdb.writebuffer.size: 128m
state.backend.rocksdb.compaction.level.max-size-level-base: 320m

增大 write buffer数量

每个Column Family对应的writebuffer最大数量，这实际上是内存中“只读内存表“的最大数量，默认值是 2。对于机械磁盘来说，如果内存足够大，可以调大到5左右

state.backend.rocksdb.writebuffer.count: 5

增大后台线程数和write buffer合并数

增大线程数：用于后台flush和合并sst文件的线程数，默认为1，建议调大，机械硬盘用户可以改为4等更大的值

state.backend.rocksdb.thread.num: 4

增大write buffer最小合并数：将数据从write buffer中flush到磁盘时，需要合并的writebuffer最小数量，默认值为 1，可以调成3。

state.backend.rocksdb.writebuffer.number-to-merge: 3

开启分区索引功能

Flink1.13中对Rocks DB增加了分区索引功能，复用了RocksDB的partitioned Index & filter功能，简单来说就是对RocksDB的partitioned Index做了多级索引。也就是将内存中的最上层常驻，下层根据需要再load回来，这样就大大降低了数据Swap竞争。线上测试中，相对于内存比较小的场景中，性能提升10倍左右。如果在内存管控下Rocks DB性能不如预期的话，这也能成为一个性能优化点。

# 默认 false
state.backend.rocksdb.memory.partitioned-index-filters:true

调优参数设置

bin/flink run \
-t yarn-per-job \
-d \
-p 1 \
-Djobmanager.memory.process.size=2048mb \
-Dtaskmanager.memory.process.size=4096mb \
-Dtaskmanager.numberOfTaskSlots=2 \
-Dstate.backend.incremental=true \
-Dstate.backend.local-recovery=true \
-Dstate.backend.rocksdb.predefined-options=SPINNING_DISK_OPTIMIZED_HIGH_MEM \
-Dstate.backend.rocksdb.block.cache-size=64m \
-Dstate.backend.rocksdb.writebuffer.size=128m \
-Dstate.backend.rocksdb.compaction.level.max-size-level-base=320m \
-Dstate.backend.rocksdb.writebuffer.count=5 \
-Dstate.backend.rocksdb.thread.num=4 \
-Dstate.backend.rocksdb.writebuffer.number-to-merge=3 \
-Dstate.backend.rocksdb.memory.partitioned-index-filters=true \
-Dstate.backend.latency-track.keyed-state-enabled=true \
-c czs.study.flink.WordCount \
./flinkyarncluster-1.0-SNAPSHOT-jar-with-dependencies.jar

CheckPoint设置

一般需求，Checkpoint时间间隔可以设置为分钟级别(15分钟)。对于状态很大的任务每次Checkpoint访问HDFS比较耗时，可以设置为510分钟一次，并且调大两次Checkpoint之间的暂停间隔，例如设置两次Checkpoint之间至少暂停4或8分钟。同时也需要考虑时效性的要求,需要在时效性和性能之间做一个平衡，如果时效性要求高，结合end- to-end时长，设置秒级或毫秒级。如果Checkpoint语义配置为EXACTLY_ONCE，那么在Checkpoint过程中还会存在barrier对齐的过程， 可以通过Flink Web UI的Checkpoint选项卡来查看Checkpoint过程中各阶段的耗 时情况，从而确定到底是哪个阶段导致Checkpoint时间过长然后针对性的解决问题。

// 使⽤ RocksDBStateBackend 做为状态后端，并开启增量 Checkpoint
env.setStateBackend(new RocksDBStateBackend("hdfs://hadoop1:8020/flink/checkpoints", true););
// 开启 Checkpoint，间隔为 3 分钟
env.enableCheckpointing(TimeUnit.MINUTES.toMillis(3));
// 配置 Checkpoint
CheckpointConfig checkpointConf = env.getCheckpointConfig();
checkpointConf.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
// 最小间隔 4 分钟
checkpointConf.setMinPauseBetweenCheckpoints(TimeUnit.MINUTES.toMillis(4));
// 超时时间 10 分钟
checkpointConf.setCheckpointTimeout(TimeUnit.MINUTES.toMillis(10));
// 保存 checkpoint
checkpointConf.enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);

反压处理

Flink中文社区反应介绍

解决反压首先要做的是定位到造成反压的节点，排查的时候，先把operator chain禁用，方便定位到具体算子

利用Flink Web UI定位反压节点

Flink Web UI的反压监控提供了SubTask级别的反压监控，1.13版本以前是通过周期性对Task线程的栈信息采样，得到线程被阻塞在请求Buffer(意味着被下游队列阻塞)的频率来判断该节点是否处于反压状态。默认配置下，这个频率在0.1以下则为OK，0.1至0.5为 LOW，而超过0.5则为 HIGH。Flink1.13优化了反压检测的逻辑(使用基于任务Mailbox计时，而不在再于堆栈采样)，并且重新实现了作业图的UI展示:Flink现在在UI上通过颜色和数值来展示繁忙和反压的程度

image-20220214163237900

image-20220214163304377

分析瓶颈算子

该节点的发送速率跟不上它的产生数据速率。这一般会发生在一条输入多条输出的Operator(比如 flatmap)。这种情况，该节点是反压的根源节点，它是从Source Task到Sink Task的第一个出现反压的节点。

下游的节点接受速率较慢，通过反压机制限制了该节点的发送速率。这种情况， 需要继续排查下游节点，一直找到第一个为OK的一般就是根源节点。

总体来看，如果我们找到第一个出现反压的节点，反压根源要么是就这个节点，要么是它紧接着的下游节点。通常来讲，第二种情况更常见。如果无法确定，还需要结合Metrics进一步判断。

利用Metrics定位

监控反压时会用到的Metrics主要和Channel接受端的Buffer使用率有关，最为有用的是以下几个Metrics

Metrics描述
outPoolUsage发送端Buffer的使用率
inPoolUsage接收端Buffer的使用率
floatingBufferUsage接收端Floating Buffer的使用率
exclusiveBufferUsage接收端Exclusive Buffer的使用率

其中inPoolUsage=floatingBuffersUsage+exclusiveBuffersUsage

分析反压的大致思路是：如果一个Subtask的发送端Buffer占用率很高，则表明它被下游反压限速了，如果一个Subtask的接受端Buffer占用很高，则表明它将反压传导至上游。反压情况可以根据以下表格进行对号入座(1.9 以上)

image-20220214163929276

Flink1.9及以上版本，还可以根据floatingBuffersUsage/exclusiveBuffersUsage以及其上游Task的outPoolUsage来进行进一步的分析一个Subtask和其上游Subtask 的数据传输。在流量较大时，Channel的Exclusive Buffer可能会被写满，此时Flink会向Buffer Pool申请剩余的Floating Buffer。这些Floating Buffer属于备用Buffer。

image-20220214164111786

floatingBuffersUsage为高，则表明反压正在传导至上游

同时exclusiveBuffersUsage为低，则表明可能有倾斜比如，floatingBuffersUsage高、exclusiveBuffersUsage低为有倾斜，因为少数channel占用了大部分的 Floating Buffer

查看是否数据倾斜

在实践中，很多情况下的反压是由于数据倾斜造成的，这点我们可以通过 Web UI 各个SubTask的Records Sent和Record Received来确认，另外Checkpoint detail 里不同SubTask的 State size也是一个分析数据倾斜的有用指标

image-20220214164322025

使用火焰图分析

如果不是数据倾斜，最常见的问题可能是用户代码的执行效率问题(频繁被阻塞或者性能问题)需要找到瓶颈算子中的哪部分计算逻辑消耗巨大。最有用的办法就是对TaskManager进行CPU profile，从中我们可以分析到Task Thread是否跑满一个CPU核：如果是的话要分析CPU主要花费在哪些函数里面；如果不是的话要看 Task Thread阻塞在哪里，可能是用户函数本身有些同步的调用，可能是checkpoint或者GC等系统活动导致的暂时系统暂停

开启火焰图功能：Flink 1.13直接在WebUI提供JVM的CPU火焰图，这将大大简化性能瓶颈的分析，默认是不开启的，需要修改参数

// 参数配置方式
rest.flamegraph.enabled: true #默认 false

// 或者启动时提交
-Drest.flamegraph.enabled=true \

image-20220214164605325

火焰图是通过对堆栈跟踪进行多次采样来构建的。每个方法调用都由一个条形表示，其中条形的长度与其在样本中出现的次数成正比

  • On-CPU: 处于 [RUNNABLE, NEW]状态的线程

  • Off-CPU: 处于 [TIMED_WAITING, WAITING, BLOCKED]的线程，用于查看在样本中发现的阻塞调用。

火焰图的颜色没有特殊含义，看顶层的哪个函数占据的宽度最大。只要有"平顶"（plateaus），就表示该函数可能存在性能问题

  • 纵向是调用链，从下往上，顶部就是正在执行的函数

  • 横向是样本出现次数，可以理解为执行时长

  • 如果是Flink 1.13以前的版本，可以手动做火焰图：制作火焰图

分析GC情况

TaskManager的内存以及GC问题也可能会导致反压，包括TaskManager JVM各区内存不合理导致的频繁Full GC甚至失联。通常建议使用默认的G1垃圾回收器。可以通过打印GC日志(-XX:+PrintGCDetails)使用GC分析器(GCViewer工具)来验证是否处于这种情况

-Denv.java.opts="-XX:+PrintGCDetails -XX:+PrintGCDateStamps"

因为是on yarn模式，运行的节点一个一个找比较麻烦。可以打开WebUI，选择JobManager或者TaskManager，点击Stdout，即可看到GC日志，点击下载按钮即可将GC日志通过HTTP的方式下载下来

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-m8X1iUPr-1644829454634)(https://gitee.com/czshh0628/blog-images/raw/master/image-20220214165141691.png)]

通过GC日志分析出单个Flink Taskmanager堆总大小、年轻代、老年代分配的内 存空间、Full GC 后老年代剩余大小等，相关指标定义可以去Github具体查看。

GCViewer 地址

Linux下分析：java -jar gcviewer_1.3.4.jar gc.log

Windows下分析：直接双击gcviewer_1.3.4.jar，打开GUI界面，选择gc的log打开

如果是Source端数据读取性能比较低或者Sink端写入性能较差，需要检查第三方组件是否遇到瓶颈，还有就是做维表join时的性能问题。异步io+热缓存来优化读写性能，先攒批再读写

数据倾斜处理

Job优化

FlinkSQL调优

常见故障排除

非法配置异常

Java堆空间异常

直接缓冲存储器异常

元空间异常

网络缓冲区数量不足

超出容器内存异常

Checkpoint失败

Checkpoint慢

Kafka 动态发现分区

Watermark 不更新

依赖冲突

超出文件描述符限制

脏数据导致数据转发失败

通讯超时

其他常见错误

Flink on YARN（下）：常见问题与排查思路-阿里云开发者社区 (aliyun.com)

笑一笑、
关注
  • 5
    点赞
  • 踩
  • 40
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
flink任务内存调优，TaskManager、JobManager内存配置
weixin_47019045的博客
06-28 7006
Flink是基于java的JVM运行，拥有高效的数据处理能力，但是考虑到用户在 Flink 上运行的应用的多样性，尽管flink框架已经为所有配置项提供合理的默认值，仍无法满足所有情况下的需求。 flink进程总内存、taskmanager内存、jobmanager内存配置...
flink sql 优化
最新发布
努力工作学习的程序员
05-05 1365
不是所有job资源越堆越多好。有时作业的复杂或数据的特殊情况(外部系统性能除外，例如写数据库)，增加资源只会让job性能越来越差或报错(亲身经历job性能差，特别痛苦，一直加资源性能还是差或运行报错)。需要不断找根源问题，多使用不同方法测试才能找到适合job的处理性能。如果优化很多次后job性能还是很差(资源给的很多性能还是不理想)(略增加一些资源)可以将一个job拆分两个job(将占用比较多的业务数据(50%更好)在新的job单独处理)
Flink调优指南
VgfCbzgNIP32
07-08 3922
此章节主要介绍了 Flink的调优方式：1.资源配置调优 2.反压处理 3.数据倾斜 4.kafkasource调优 5.FlinkSQL调优几个部分。
Flink内存调优篇-广告实时统计的优化
一亿年开发经验
08-25 1422
布隆过滤器本质上是一个二进制向量(位数组)和一系列随机映射函数(哈希函数)，用于判断数据一定不存在，或者可能存在。使用布隆过滤器去重，首先准备长度为M的位数组和K个哈希函数，对于到来的数据进行K次哈希，并将位数组中hash值对应的位置修改为1。举例说明，现有4条所需处理数据(ZFB,WX,DY,ZFB)，准备以下位数组以及2个哈希函数位数组第一条数据ZFB到来，经过两次哈希，分别将位数组哈希对应位置由0修改为1第二条数据WX到来，经过两次哈希，分别将位数组哈希对应位置由0修改为1。
Flink几个性能调优
yang灬仔
10-24 834
flink性能优化
Flink的性能优化
chbxw
06-10 3570
[返回总目录](https://blog.csdn.net/wuxintdrh/article/details/106452793)
高性能FlinkSQL优化技巧
03-01
MicroBatch在元素序列化效率、反压表现、吞吐和延迟性能上都要优于MiniBatch。微批处理通过增加延迟换取高吞吐，如果您有超低延迟的要求，不建议开启微批处理。通常对于聚合的场景，微批处理可以显
flink调优之RocksDB设置.doc
07-10
Flink 调优之 RocksDB 设置 Flink 是一个流处理引擎，它可以处理高-throughput 和低延迟的数据流。RocksDB 是 Flink 中的一个状态后端，它基于 LSM Tree 实现，写数据都是先缓存到内存中，然后才写入磁盘中。Rocks...
Flink 全网最全资源（视频、博客、PPT、入门、原理、实战、性能调优、源码解析、问答等持续更新）
10-25
Flink 全网最全资源（视频、博客、PPT、入门、原理、实战、性能调优、源码解析、问答等持续更新），包含 Flink 入门、概念、原理、实战、性能调优、大型案例、源码解析
flink-learning：flink学习博客。 http://www.54tianzhisheng.cn含Flink入门，概念，原理，实战，性能调优，子程序解析等内容。涉及Flink连接器，指标，库，DataStream API，表API和SQL等内容的学习案例，还有Flink落地应用的大型项目案例（PVUV，日志存储，百亿数据实时去重，监控细分）分享。欢迎大家支持我的专栏《大数据实时计算引擎Flink实战与性能优化》
02-03
Flink学习 麻烦路过的各位亲亲给这个项目点个star，太不易了，写了这么多，算是对我坚持下来的一种鼓励吧！ 随着时间的推移观星人 本项目结构 如何建造 也许您的Maven conf文件settings.xml镜像可以添加aliyun中央...
面向Flink的多表连接计算性能优化算法
12-25
面向Flink的多表连接计算性能优化算法，李旺，双锴，分布式计算引擎Flink已经被广泛应用到大规模数据分析处理领域，多表连接是Flink常见作业之一，因此提升Flink多表连接的性能能够加速数
Flink流式计算实际生产项目代码
12-19
网上很少能找到flink的生产项目，这个项目是关于系统运维方面的流式处理，生产上的注意点，代码里基本都有体现，对初学者应该有一些帮助，其他的，就去官方demo上学习吧。
flink1.10内存模型及参数详解
weixin_41745141的博客
03-22 1261
flink1.10内存模型参数详解
学不会去当产品吧？Flink实战任务调优
微信搜：import_bigdata，大数据领域硬核原创作者
01-09 385
背景 在大数据领域我们都知道，开发是最简单，任务的合理调优、问题排查才是最重要的。 我们在之前的文章《Flink面试通关手册》中也讲解过，作者结合线上出现的一些问题，总结了一些任务调优需要注意的点。 一些简单的原则 我们在之前的文章《Flink面试通关手册》中提到过一个问题，Flink任务延迟高，想解决这个问题，你会如何入手？ 当时我们给出的答案是： 在Flink的后台任务管理中，我们可以看到Flink的哪个算子和task出现了反压。最主要的手段是资源调优和算子调优。资源调优即是对作业中的Operato.
Flink流性能优化与调优
禅与计算机程序设计艺术
01-18 937
1.背景介绍 Flink是一个流处理框架，用于处理大规模数据流。它提供了一种高效、可扩展的方法来处理实时数据流，并可以与其他系统集成，以实现更复杂的数据处理任务。Flink流性能优化和调优是一项重要的技能，可以帮助开发人员更有效地利用Flink框架，提高数据处理速度和效率。 在本文中，我们将讨论Flink流性能优化和调优的核心概念、算法原理、具体操作步骤、数学模型公式、代码实例以及未来发展趋势...
Flink进阶与调优
LSur_king的博客
04-18 1038
【知识点1】Flink在处理网络传输时，通过NetworkBuffer来实现攒批，权衡吞吐和延迟的关系。Flink 1.10 及以后的版本直接通过配置参数execution.buffer-timeout: 100ms可以设置，Flink 1.10 之前通过代码env.setBufferTimeout(100)设置 。当设置为 0 时表示没有 timeout 策略，即：每条数据来了都认为 buffer 满了，将这一条数据单独发送给下游。保障了实时性，但吞吐可能会下降。要想吞吐不下降，就需要消耗更多的资...
【Flink精讲】Flink性能调优：内存调优
话数Science
02-25 858
【Flink精讲】Flink性能调优：内存调优 JVM metaspace： JVM 元空间taskmanager.memory.jvm-metaspace.size，默认 256mb2） JVM over-head 执行开销： JVM 执行时自身所需要的内容，包括线程堆栈、 IO、编译缓存等所使用的内存。总进程内存*fraction，如果小于配置的 min（或大于配置的 max） 大小，则使用 min/max大小。
Flink参数设置和性能优化
litlit023的专栏
04-02 522
4、分桶聚合-适用于去重聚合场景例如count(distinct userId)，将数据的key先打散到多个桶进行聚合，再对分桶中的数据最后聚合。去重计算的分桶聚合（例如groupby分钟去重，如果一个key数据500w，另一个key数据1w）导致数据倾斜，开启分桶聚合、分桶个数。0、状态访问性能差、大状态以及数据倾斜这3种场景提供的微批处理、去重场景BitMap复用、两阶段聚合以及去重计算的分桶聚合的优化原理。3、2阶段聚合（适合计数、累加的聚合场景）：热点数据倾斜，先聚合再传递给下游。
Flink有没有什么调优
05-24
Flink是一个分布式流处理框架，对于大规模的数据处理任务，需要进行一定的调优才能达到更好的性能和效率。 以下是一些可以进行的调优方式： 1. 调整并行度：适当调整Flink作业中各个算子的并行度，可以提高作业的处理能力。 2. 使用状态后端：Flink支持多种状态后端，如MemoryStateBackend、FsStateBackend和RocksDBStateBackend等。选择合适的状态后端可以提高作业的稳定性和性能。 3. 内存管理：Flink中的内存管理非常重要，可以通过调整堆内存和堆外内存的大小、使用Off-heap Memory等方式来进行优化。 4. 网络通信：Flink作业需要进行大量的网络通信，可以通过调整buffer大小、使用TCP nodelay等方式来提高网络传输效率。 5. 数据倾斜：Flink中的数据倾斜问题会影响作业的性能。可以通过使用keyBy算子、使用broadcast变量、使用随机前缀等方式来解决数据倾斜问题。 6. 避免过度重启：Flink作业中的重启机制会造成一定的性能损失，可以通过调整重启策略、避免过度重启等方式来提高作业的性能。 7. 硬件优化：在使用Flink时，合理配置硬件资源也是非常重要的。可以通过使用高速网络、SSD等方式来提高作业的性能。 综上所述，Flink的调优需要根据实际情况进行，需要结合具体的项目需求和硬件资源来进行优化。

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值