怎么在Apache Flink中管理RocksDB内存大小

Apache Flink中的RocksDB状态后端

在深入了解配置参数之前，让我们首先重新讨论在flink中如何使用RocksDB来进行状态管理。当您选择RocksDB作为状态后端时，您的状态将被序列化成字节存在堆外内存或本地磁盘中。RocksDB是一个键值存储，它被组织为一个日志结构的合并树（LMS树）。当用于在Flink中存储Keyed状态时，Key由<Keygroup，Key，Namespace>的序列化字节组成，而value由序列化之后的state的字节组成。每次注册keyed状态时，它都会映射到column family（类似于传统数据库中的表），并且键值对将作为序列化字节存储在RocksDB中。这意味着每次READ或WRITE操作都不得不对数据进行序列化/反序列化，

使用RocksDB作为状态后端有许多优点：它不受垃圾回收的影响，与堆中的对象相比，它通常会有较低的内存开销，并且它是目前唯一支持增量检查点的选项。此外，使用RocksDB，您的状态大小仅受限于可用本地磁盘空间大小，最适合依赖大型状态操作的Flink应用程序。

如果你不熟悉RocksDB，下图说明了其基本的READ和WRITE操作。

RocksDB中的写操作将数据存储在当前活动的内存表（Active MemTable）中。当内存表已满时，它将变为READ ONLY MemTable，并被一个新的、空闲的active状态的MemTable替换。READ ONLY MemTable会被后台线程周期性地flush到磁盘，成为按照key排序的的只读文件 -- 即所谓的SSTables。反过来，SSTables是不可变的，通过后台日志压缩将他们整合到一起（SSTables的多路归并）。如前所述，使用RocksDB，每个注册状态都是一个column family，这意味着每个状态都包含自己的MemTables和SSTables。

 

在RocksDB中的READ操作首先访问Active Memory Table以响应查询。如果找不到要搜索的key，则READ操作会根据key从最新到最旧READ ONLY MemTables依次查找，直到找到要搜索的key。如果在任何MemTable中都找不到该key，则READ操作将再次从最新的位置开始访问SSTable。SSTable文件可以从BlockCache、（如果它包含未压缩的表文件）从操作系统的文件高速缓存获得，或者在最坏的情况下从本地磁盘获得。像SST级别的bloom filters的可选索引可以帮助避免命中磁盘。

3种配置来管理您的RocksDB内存消耗

现在我们已经使用Apache Flink建立了基于RocksDB的一些功能，让我们来看看可以帮助您更有效地管理RocksDB内存大小的配置选项。请注意，以下选项并非是全面的，您可以使用Apache Flink 1.6中引入的State TTL（Time-To-Live）功能管理Flink应用程序的状态大小。以下三个配置是帮助您有效管理RocksDB资源消耗的良好起点：

1.block_cache_size

此配置将最终控制在内存中缓存的未压缩的最大的块数。随着块数的增加，内存大小也会增加 - 因此，通过预先配置它，您可以保持特定的内存消耗级别。

2.write_buffer_size

此配置建立并控制RocksDB中MemTable的最大大小。Active MemTables和READ ONLY MemTables最终将影响RocksDB中的内存大小，因此尽早调整它可能会为您节省一些麻烦。

3.max_write_buffer_number

在RocksDB将state作为SS Tables刷新到本地磁盘之前，此配置决定并控制内存中保留的最大MemTable的数量。这实际上也决定了在内存中 READ ONLY 状态的MemTables的最大数量。

除了上面提到的配置之外，您还可以选择性的配置消耗额外内存空间的索引和 bloom filters ，以及侧边的table cache。表缓存不仅会占用RocksDB中的额外内存，它还会保存打开文件描述符到默认情况下不受限的SST文件，如果配置不正确，可能会和操作系统的配置发生冲突。

我们刚刚引导您完成了一些用RocksDB作为Flink中的状态后端的的配置选项，这将帮助我们有效的管理内存大小。