我一直在阅读 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 流的速率为 50k 条消息/秒，那么我可以在我的 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 配置多少内存。
有人可以验证我的理解是否正确，并为我指出正确的方向。提前感谢！
总的来说，你的理解似乎是正确的。一点：在 TM 失败的情况下，JM 将启动一个新的TM并从最后一个检查点恢复状态(而不是启动一个新的JM)。
但更准确地说，在 Flink 的最后几个版本中，曾经是整体式作业管理器的内容被重构为单独的组件：从客户端接收作业并根据需要启动新作业管理器的调度程序;只关心为单个作业提供服务的作业管理器;以及根据需要启动新 TM 的资源管理器。资源管理器是唯一特定于集群框架的组件 - 例如，有一个 YARN 资源管理器。
作业管理器还有其他角色 - 它是检查点协调器以及 Web UI 和指标的 API 终结点。
JM 需要多少堆是可变的。选择默认值是为了尝试涵盖不止一组狭窄的情况，并且开箱即用。此外，默认情况下，检查点会转到 JM 堆，因此它需要一些空间。如果您有一个小型集群并且正在对分布式文件系统执行检查点操作，则应该能够以小于 1GB 的内存处理。