我一直在阅读Flink文档，并且需要澄清。希望有人可以在这里帮助我。
状态后端-这基本上是指用于存储我的操作数据的位置，例如，如果我在2小时的窗口中进行汇总，则将缓冲该数据的位置存储在这里。正如文档中指出的，对于大状态，我们应该使用RocksDB。
The RocksDBStateBackend holds in-flight data in a RocksDB database that is (per default) stored in the TaskManager data directories
这里的运行中数据是否是指来自kafka流的尚未经过检查点的传入数据？
Upon checkpointing, the whole RocksDB database will be checkpointed into the configured file system and directory. Minimal metadata is stored in the JobManager’s memory
在创建检查点时使用RocksDb时，所有缓冲数据都存储在磁盘中。然后说，当要在2小时结束时触发窗口时，存储在磁盘中的此状态将被反序列化并用于操作？
Note that the amount of state that you can keep is only limited by the amount of disk space available
这是否意味着我可以使用非常有限的资源对整个潜在的高流量运行分析查询。假设我的Kafka Stream的传输速率为每秒5万条消息，那么我可以在我的EMR集群的单个内核上运行它，而权衡是Flink将无法赶上传入的速率并且会有滞后，给定足够的磁盘空间，它不会出现OOM错误？
检查点完成后，我假设来自所有TM的完成的聚合检查点元数据（如来自每个TM的HDFS或S3路径）将被发送到JM？。如果TM失败，JM将启动新的JM并从最后一个检查点恢复状态。
The default setting for JM in flink-conf.yaml - jobmanager.heap.size: 1024m.
我的困惑是，为什么JM需要1Gb的堆内存。除了TM之间的同步，JM还要处理什么。我实际上如何决定应在生产中为JM配置多少内存。
有人可以验证我的理解是正确的还是正确的方向。预先感谢！
答案 0 :(得分：0)
总体而言，您的理解似乎是正确的。一点：在TM失败的情况下，JM将启动一个新的 TM 并从最后一个检查点恢复状态（而不是启动一个新的 JM ）
但更确切地说，在Flink的最后几个版本中，以前是一个整体的作业管理器已经重构为单独的组件：一个从客户那里接收作业并根据需要启动新作业管理器的调度程序；只关心为一项工作提供服务的工作经理；和一个资源管理器，根据需要启动新的TM。资源管理器是特定于集群框架的唯一组件-例如，有一个YARN资源管理器。
作业管理器还具有其他角色-它是Web UI和度量标准的检查点协调器和API端点。
JM需要多少堆在一定程度上是可变的。选择默认值是为了尝试涵盖多种情况，并且可以直接使用。另外，默认情况下，检查点进入JM堆，因此它需要一些空间。如果您的群集很小，并且正在检查指向分布式文件系统，则应该可以使用不到1GB的空间。