本文主要分享了字节击败弗林克州的实用经验。该内容包括相关状态的实践和发动机中某些字节的优化。我希望为Flink用户的开发和调整提供一些参考意义。
Flink的作业需要使用状态来完成计算任务的状态，例如聚合，JOIN和状态一直是分配调整的重点。目前，状态和检查点已在字节跳动中广泛使用，状态支持是典型的方案例如数据集成，实时仓库，功能计算，示例缝合和其他典型方案。提交，窗口聚合计算的索引统计任务，存储数据详细信息的数据缝制任务，例如多流量联接。
以WordCount为例，假设我们需要计算60秒窗口中的单词数：
在尚未触发的60年代窗口中，与每个单词相对应的显示的数量是flink状态。每次窗口收到新数据时，该状态都会更新到最终输出为止。为了防止家庭作业的失败和状态丧失，Flink介绍了分布式快照检查点的概念，该检查点经常将状态转移到HDFS。如果操作是故障转移，则先前成功的检查点的状态（例如Kafka的主持人，窗口，统计数据等）。
在不同的业务场景中，用户通常需要调整状态和检查点机制，以确保任务执行和检查点的稳定性。在阅读以下内容之前，我们可以回忆起使用Flink State时是否面对以下问题：
由于运算符背后的状态卫队仅是DefaultOperateAtateBackend，因此用户通常指定两种类型的FSSTATEBACKEND和ROCKSDBSTATEBACKEND。实际上，状态背式类型对应于KeyedState：
RockSDB是一个嵌入式键值数据库，用作Flink中RocksdbStateBackend的基础存储。如下图所示，RockSDB的持久性SST文件是通过本地文件系统上的多个级别组织的，并且将合并和不同的级别合并和不同级别。通过不同级别之间的异步压实重复，过期和删除。在RockSDB的写作过程中，数据写入序列化后写入写作，并将写入式转换为可变的记忆结构，然后通过Rocksdb的冲洗到岩石的冲洗液，磁盘;写入式和不可变的记忆读取数据。如果找不到，您将查询块缓存。如果没有内存，您将在级别找到底层文件，然后将返回的结果加载到上层应用程序。
以下是RocksdbkeyedStatebecend增量快照，每个人通常都需要在大型状态下调整它。RockSDB具有仅APEND的特征。Flink使用此功能将两个检查点之间的SST文件列表之间的差异上传到分布式文件系统，并通过Jobmaster的共享StatereGistry注册并到期。
如上图所示，任务拍摄了三个快照（假设操作设置保留了最近的检查点）：
增量快速照片涉及任务多线程上传/下载增量文件，Jobmaster参考计数统计信息以及与分布式文件系统的大量交互。与其他状态卫星相比，它更复杂。它更有可能在性能和稳定性瓶颈方面存在问题。
使用该州时，用户会发现操作不是非常“简单”的事情。如果您使用FSSTATEBACKEND，您会经常遇到诸如GC问题和频繁参考之类的问题。在缺少相关指标时找到性能问题并不容易，或者不知道如何调整RockSDB面对面的最佳参数。
目前，在字节击败中的140+作业状态已达到结核病水平，单个操作的最大状态为60TB。在逐渐支持大型家庭作业的实践中，我们积累了一些州在调整方面的经验，并进行了一些引擎。方面的转型以支持更好的性能并降低运营调整成本。
我们都知道FSSTATEBACKKEND适用于小型省作业，RocksdbStateBackend适合大型省作业，但是当实际选择FSStateBackend时，会遇到以下问题：
对于上述FSSTATEBACKEND中存在的一些问题，我们可以看到FSStateBackend的维护成本相对较高。内部字节，我们暂时仅推荐某些操作，而作业小于1GB。使用FSStateBackend。对于大型交通业务，例如短视频，实时广播，电子商务等，我们更倾向于建议用户使用RocksdbStateBackend来降低未来的GC风险。获得更好的稳定性。
从长远来看，随着内部硬件的续订迭代，SSD的促进，我们希望将状态卫星收敛到RocksdbStateBackend，以提高操作稳定性并降低用户的操作和维护成本。在小状态的情况下，RocksdbStateBackend可以使用FSSTATEBACKEND进行SOIT的近距离或束缚。
当Flink的社区版本使用RocksdbStateBackend时，如果遇到绩效问题，基本上很难判断问题的原因。目前，建议打开相关指标进行调查。[1]此外，在Byte Beating中，RocksdbStateBackend Performance瓶颈的原因很多。我们已经构建了一个相对完整的ROCKSDB索引系统，在缩小级别上，一些关键的RockSDB指标已揭示，并且与某些指标的示意图相关的示意图如下：
RockSDB性能的常见瓶颈如下：
除上述指标外，另一种可以与火焰图表合作的方法。诸如Ali [2]的Arthas之类的常见方法。Flink和RocksDB CPU顶部将显示在火焰图表内。示意图如下：
如上所示，可以看出，火焰图中的压实开销非常大。将压实问题定位后，我们可以进一步分析价值大小，岩石能力，操作并行操作和资源的体积。
除了Flink中提供的ROCKSDB参数[3]外，RockSDB还具有许多调整参数供用户使用。用户可以通过自定义RocksdBoptionsFactory [4]进行RockSDB调整[4]。在某些内部实践中，我们列出了两个更有效的参数：两个更有效的参数：
应该注意的是，由于许多参数在内存或磁盘中交换为性能，因此需要将上述参数的使用与特定的性能瓶颈结合使用，以达到最佳效果。。目前，您可以尝试与压缩相关的参数。
使用RockSDB状态相关的API，键和值都需要序列化和得出。如果Java对象更为复杂，并且用户不自定义序列化器，则其序列化费用将相对较大。当序列化和荒漠化时，MB级别对象的序列化开销将达到第二层，这是经营性能的巨大损失。因此，对于复杂的对象，我们建议：
有关序列化的更多性能和指导，您可以参考社区的调整文档[7]。
上面提到的RockSDB的序列化开销可能相对较大。Byte在国内卫和操作员的中间击败了内部构建的状态式缓存层。作业收入很明显。
同样，对于用户，如果操作热点很明显，则可以尝试在内存中构建一个简单的Java对象缓存，但是您需要注意以下几点：
检查点持续时间与许多因素有关，例如反压力操作，足够的资源等。我们在这里查看如何从状态返回的角度提高检查点的成功率。任务 - 级别的快照可以分为以下步骤：
内部殴打，我们还为这四个步骤建立了相关监视板：
在生产环境中，“等待CheckpointLock”和“同步阶段”是更多的时间 - 令人震惊的业务逻辑，通常需要相对较短的时间；从状态卫星的级别，我们可以收集“收集障碍”和“异步阶段”。两阶段被优化以减少检查点的长度。
减少屏障比对时间的核心是减少机上缓冲区的总尺寸。即使未对齐的检查点的数量具有社区的特征，如果飞行中的缓冲区数太大，它也会导致分布式存储的最终状态太大-flicht甚至可能超过状态本身的规模，但它将对异步阶段的时间消耗产生负面影响。
如果所有FLINK操作都在您的群集中使用相同的DFS群集，则在业务增长到一定顺序之后，DFS的IO压力和吞吐量将成为“异步阶段”中非常重要的参考指标，尤其是在逐步快照中。RocksdbStateBackend，每个操作员生成的状态文件将被上传到DFS。在操作中，以高平行性上传，因为每个任务的快照基本上同时出现在同一时间，因此在几分钟之内，DFS的请求数可以可以通常达到数千甚至数万。
在社区版本的增量快照中，RockSDB新生成的每个SST文件都需要上传到DFS。以HDF为例。文件通常低于100MB。对于小数据，即使是KB级别文件的大小，检查点生成的大型且频繁的小文件请求将对HDFS的元数据管理和Namenode访问造成相对较大的压力。
社区提出了合并小文件并在Flink-11937中上传小文件的想法。类似，在实现互动的实现中，我们将小文件的逻辑抽象成stgethe因素，以实现我们自己的业务场景的上传策略。
除了州绩效和DFS瓶颈外，考虑到实际生产过程中，状态卫队的恢复速度也是一个非常重要的一点。我们将在生产过程中发现，由于某些参数的设置是不合理的，因此可能会导致更改操作配置和并发会议，当操作重新启动时，从快照开始，性能尤其较差，并且恢复时间已经上升。到十分钟。
联合状态的特征是，恢复操作时，每个并行性恢复的状态是平行性。此功能使联盟状态在Jobmaster状态分配和任务管理员状态恢复中较重：
在联合状态的实际使用中，除了恢复缓慢的问题外，如果不正确使用，它也会对DF造成很大的压力。
RocksdbStateBackend支持的增量快照和完整的快照（或SavePoint）。这两个快照之间的差异使它们在不同的情况下达到了恢复速度。完整的快照是RockSDB实例的键值，并将其写入DFS。
为了通过是否扩大容量来定义场景，这两个快照下的恢复速度如下：
这里更麻烦的是，当扩展容量恢复时，遇到长时间的问题更容易。由于平行性的过度状态，整体恢复时间被拉长。目前，社区版本还没有彻底的解决方案。将大型州运营的恢复速度优化，并根据社区的支持功能提出一些建议，以加快场景扩展的恢复：此处：此处：
在本文中，我们介绍了状态和RockSDB的相关概念，并给出了字节跳动中内部殴打中的状态应用程序中遇到的问题。我希望在阅读了日常开发中的这种表达应用后，将有更深入的理解和理解。
目前，由字节跳动流量计算团队支持的火山引擎流计算版本是在公共beta中，支持云中性模型，支持公共云，混合云和云部署，全面地与企业云策略全面兼容，欢迎使用进行试用：
原始：https：//juejin.cn/post/711160000262212638