- 记录数和每条记录的大小
估算预期进入流计算系统的每秒记录数（也就是我们常说的吞吐量），以及每条记录的大小 - 不同 key 的数量和每个 key 存储的 state 大小
应用程序中不同 key 的数量和每个 key 所需要存储的 state 大小，都将影响到 Flink 应用程序所需的资源，从而能高效地运行，避免任何反压。 - 状态的更新频率(10s)和状态后端的访问模式
第三个考虑因素是状态的更新频率，因为状态的更新通常是一个高消耗的动作。而不同的状态后端（如 RocksDB，Java Heap）的访问模式差异很大，RocksDB 的每次读取和更新都会涉及序列化和反序列化以及 JNI (java neative interface)操作，而 Java Heap 的状态后端不支持增量 checkpoint，导致大状态场景需要每次持久化的数据量较大。这些因素都会显著地影响集群的大小和 Flink 作业所需的资源。
RocksDB状态后端是目前唯一支持增量 checkpoint 的后端。增量 checkpoint 非常使用于超大状态的场景，生产场景下推荐 - 故障重启后，资源必须保证能够应对被积压的数据流产生的峰值
- 网络带宽（），磁盘带宽（如果你的应用程序依赖了基于磁盘的状态后端，如 RocksDB），机器数量及其可用 CPU 和内存
网友评论