大佬教程收集整理的这篇文章主要介绍了Flink 减少 shuffle 开销和内存消耗，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
我的 Flink 工作经常与一个或另一个任务管理器发生 OOM。我有足够的内存和存储空间来完成我的工作（2 个 JobManager/16 个 TaskManager - 每个都有 15 核和 63GB RAM）。有时作业在抛出 OOM 前运行 4 天，有时作业在 2 天内进入 OOM。但与前几天相比，流量是一致的。
我收到了一个建议，不要在流管道中传递对象，而是使用原语来减少改组开销和内存消耗。
我工作的 flink 作业是用 Java 编写的。让我们说下面是我的管道
Kafka source
deserialize (converted bytes to java object,the object contains String,int,long types)
FirstKeyeDWindow (the above serialized java objects received herE)
reduce
SecondKeyeDWindow (the above reduced java objects received herE)
reduce
Kafka sink (above java objects are serialized into bytes and are produced to kafka)
我的问题是我应该考虑什么来减少开销和内存消耗？ 用字符数组替换字符串是否有助于减少开销？要么 我应该只处理整个管道中的字节吗？ 如果我在 Keyedwindows 之间序列化对象，它是否有助于减少开销？但是如果我必须读回字节，那么我需要反序列化，根据需要使用然后序列化它。它不会增加序列化/反序列化的开销吗？
感谢您的建议。注意，我说的是每天收到 10TB 的数据。
更新 1：
我看到的 OOM 异常如下：
org.apache.flink.runtime.io.network.netty.exception.RemoteTransportException：连接被远程任务管理器“主机/主机：端口”意外关闭。这可能表明远程任务管理器丢失了。
回答大卫安德森的评论如下： 使用的 Flink 版本是 v1.11 使用的状态后端是 RocksDB，基于文件系统。作业堆内存不足。来自 Kafka 源的每条消息的大小最大为 300 字节。 reduce 函数执行重复数据删除（删除同一组内的重复项），第二个 reduce 函数执行聚合（更新对象内的计数）。
更新 2：
经过深入探索，我发现Flink使用Kyro默认序列化器，效率低下。我明白 custom_serializers 可以帮助减少开销，如果我们定义一个而不是使用 Kyro 默认。我现在正在试用 Google-protobuf，看看它的性能是否更好。
而且，我也期待增加适合我工作并行度的 taskmanager.network.memory.fraction。尚需找出正确的计算方法来设置上述配置。
在我尝试的方法对我有用之后，我在这里回答我自己的问题。我在 Grafana 中发现了与我的 Flink 工作相关的额外指标。其中两个指标是GC 时间和 GC 计数。我在 GC（垃圾收集）指标中看到了一些很好的峰值。原因可能是，我在作业管道中创建了一些新对象。考虑到我正在处理的 TB 数据和每天 200 亿条记录，这个对象的创建陷入了混乱。我对其进行了优化，以尽可能多地重用对象，从而减少了内存消耗量。
我已经将 taskmanager.network.memory 增加到所需的值，默认设置为 1GB。
在我上面的问题中，我谈到了自定义序列化程序以减少网络开销。我尝试使用 Kyro 实现 protobuf 序列化器，并且 protobuf 生成的类是 final。如果我必须更新对象，我必须创建新对象，这会在 GC 指标中产生峰值。所以，避免使用它。也许我可以进一步更改 protobuf 生成类以满足我的需要。如果情况不一致，将考虑该步骤。
以上是大佬教程为你收集整理的Flink 减少 shuffle 开销和内存消耗全部内容，希望文章能够帮你解决Flink 减少 shuffle 开销和内存消耗所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。