首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

Flink RocksDB State Backend:when and how

流处理应用程序通常是有状态的,“记住”已处理事件的信息,并使用它来影响进一步的事件处理。在Flink中,记忆的信息(即状态)被本地存储在配置的状态后端中。为了防止发生故障时丢失数据,状态后端会定期将其内容快照保存到预先配置的持久性存储中。该RocksDB[1]状态后端(即RocksDBStateBackend)是Flink中的三个内置状态后端之一。这篇博客文章将指导您了解使用RocksDB管理应用程序状态的好处,解释何时以及如何使用它,以及清除一些常见的误解。话虽如此,这不是一篇说明RocksDB如何深入工作或如何进行高级故障排除和性能调整的博客文章;如果您需要任何有关这些主题的帮助,可以联系Flink用户邮件列表[2]。

03
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Flink状态后端和CheckPoint 调优

    RocksDB 是嵌入式的 Key-Value 数据库,在 Flink 中被用作 RocksDBStateBackend 的底层存储。如下图所示,RocksDB 持久化的 SST文件在本地文件系统上通过多个层级进行组织,不同层级之间会通过异步Compaction 合并重复、过期和已删除的数据。在 RocksDB 的写入过程中,数据经过序列化后写入到WriteBuffer,WriteBuffer 写满后转换为 Immutable Memtable 结构,再通过 RocksDB 的flush 线程从内存 flush 到磁盘上;读取过程中,会先尝试从 WriteBuffer 和 Immutable Memtable 中读取数据,如果没有找到,则会查询 Block Cache,如果内存中都没有的话,则会按层级查找底层的 SST 文件,并将返回的结果所在的 Data Block 加载到 BlockCache,返回给上层应用。

    03

    云原生架构下B站Flink存算分离的改造实践

    在当前整个行业及公司内部降本增效的大背景下,B站内部也在积极推进实时与在线业务资源的整合,往云原生架构迁移,统一资源池与调度,提升资源利用效率。不过面临的现实问题就是,不同业务场景下,资源的规格诉求不尽相同。在线的业务资源池,由于在线业务的属性,一般只具备很强的计算能力而基本不带存储以及io能力。Flink虽然是一个计算引擎,但是由于其stateful的特性,在很多计算场景下,对存储和io其实有比较强的诉求,因此实时的资源池,同时具备很强的存算能力。两种资源池的整合,必然面临兼容性问题,考虑到大数据整体的存算分离发展趋势,我们尝试对Flink进行存算分离的改造,核心工作就是statebackend的远程化。

    02
    领券