深度解析 Flink 是如何管理好内存的？

前言

如今，许多用于分析大型数据集的开源系统都是用 Java 或者是基于 JVM 的编程语言实现的。最着名的例子是 Apache Hadoop，还有较新的框架，如 Apache Spark、Apache Drill、Apache Flink。基于 JVM 的数据分析引擎面临的一个常见挑战就是如何在内存中存储大量的数据(包括缓存和高效处理)。合理的管理好 JVM 内存可以将 难以配置且不可预测的系统 与 少量配置且稳定运行的系统区分开来。

在这篇文章中，我们将讨论 Apache Flink 如何管理内存，讨论其自定义序列化与反序列化机制，以及它是如何操作二进制数据的。

数据对象直接放在堆内存中

在 JVM 中处理大量数据最直接的方式就是将这些数据做为对象存储在堆内存中，然后直接在内存中操作这些数据，如果想进行排序则就是对对象列表进行排序。然而这种方法有一些明显的缺点，首先，在频繁的创建和销毁大量对象的时候，监视和控制堆内存的使用并不是一件很简单的事情。如果对象分配过多的话，那么会导致内存过度使用，从而触发 OutOfMemoryError，导致 JVM 进程直接被杀死。另一个方面就是因为这些对象大都是生存在新生代，当 JVM 进行垃圾回收时，垃圾收集的开销很容易达到 50% 甚至更多。最后就是 Java 对象具有一定的

测试是在 8 核机器上运行单线程，因此一个核心的完全利用仅对应 12.5% 的总体利用率。截图显示，对二进制数据进行操作可显著减少垃圾回收活动。对于对象存在堆中，垃圾收集器在排序缓冲区被填满时以非常短的时间间隔运行，并且即使对于单个处理线程也会导致大量 CPU 使用(排序本身不会触发垃圾收集器)。JVM 垃圾收集多个并行线程，解释了高CPU 总体利用率。另一方面，对序列化数据进行操作的方法很少触发垃圾收集器并且 CPU 利用率低得多。实际上，如果使用 Flink 序列化的方式在 Integer 字段上对 Tuple 进行排序，则垃圾收集器根本不运行，因为对于成对比较，不需要反序列化任何对象。Kryo 序列化需要比较多的垃圾收集，因为它不使用二进制排序 key 并且每次排序都要反序列化两个对象。

内存使用情况上图显示 Flink 序列化和 Kryo 序列化不断的占用大量内存

存使用情况图表显示flink-serialized和kryo-serialized不断占用大量内存。这是由于 MemorySegments 的预分配。实际内存使用率要低得多，因为排序缓冲区并未完全填充。下表显示了每种方法的内存消耗。1000 万条数据产生大约 280 MB 的二进制数据(对象数据、指针和排序 key)，具体取决于使用的序列化程序以及二进制排序 key 的存在和大小。将其与数据存储在堆上的方法进行比较，我们发现对二进制数据进行操作可以显著提高内存效率。在我们的基准测试中，如果序列化为排序缓冲区而不是将其作为堆上的对象保存，则可以在内存中对两倍以上的数据进行排序。

总而言之，测试验证了文章前面说的对二进制数据进行操作的好处。

展望未来

Apache Flink 具有相当多的高级技术，可以通过有限的内存资源安全有效地处理大量数据。但是有几点可以使 Flink 更有效率。Flink 社区正在努力将管理内存移动到堆外内存。这将允许更小的 JVM，更低的垃圾收集开销，以及更容易的系统配置。使用 Flink 的 Table API，所有操作(如 aggregation 和 projection)的语义都是已知的(与黑盒用户定义的函数相反)。因此，我们可以为直接对二进制数据进行操作的 Table API 操作生成代码。进一步的改进包括序列化设计，这些设计针对应用于二进制数据的操作和针对序列化器和比较器的代码生成而定制。

总结

• Flink 的主动内存管理减少了因触发 OutOfMemoryErrors 而杀死 JVM 进程和垃圾收集开销的问题。
• Flink 具有高效的数据序列化和反序列化机制，有助于对二进制数据进行操作，并使更多数据适合内存。
• Flink 的 DBMS 风格的运算符本身在二进制数据上运行，在必要时可以在内存中高性能地传输到磁盘。

标题名称：深度解析 Flink 是如何管理好内存的？
转载来于：/news29/102479.html

成都网站建设公司_创新互联，为您提供微信小程序、云服务器、网页设计公司、网站设计、ChatGPT、定制网站

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联