Flink小贴士 (1)：确定Flink作业所需资源大小时要考虑的6件事

本文译自 dataArtisans 官方博文： https://data-artisans.com/blog/6-things-to-consider-when-defining-your-apache-flink-cluster-size

译者：云邪（Jark）

译注：原文标题是“6 things to consider when defining your Apache Flink cluster size”，其实在确定作业所需资源时要考虑的事情是一样的，而作业所需资源的问题是用户更经常遇到的问题，所以这里将标题修改了下。

本文是我们博客新开系列《Flink Friday Tip》的首篇文章。该系列主要涵盖了易理解的最佳实践、如何提高Flink 性能的建议、以及如何最佳地使用 Flink 的各种功能。

译注：这也是我为什么打算开始翻译这个系列的原因，不过我可能做不到每周五同步更新，但是我会尽量做到每周更新，所以翻译过来的系列名叫做《Flink小贴士》。

在 Apache Flink 社区中我们被经常问及的一件事是：如何规划和计算一个 Flink 集群的大小（或者说如何确定一个 Flink 作业所需的资源）。确定集群的大小很显然是决定于多种因素的，例如应用场景，应用的规模，以及特定的服务等级协议（SLA）。另外应用程序中的 checkpoint 类型（增量 vs 全量）和 Flink 作业处理是连续还是突发的也都会影响到 Flink 集群的大小。

以下6个方面是确定 Flink 集群大小时最先要考虑的一些因素：

1. 记录数和每条记录的大小

确定集群大小的首要事情就是估算预期进入流计算系统的每秒记录数（也就是我们常说的吞吐量），以及每条记录的大小。不同的记录类型会有不同的大小，这将最终影响 Flink 应用程序平稳运行所需的资源。

2. 不同 key 的数量和每个 key 存储的 state 大小

应用程序中不同 key 的数量和每个 key 所需要存储的 state 大小，都将影响到 Flink 应用程序所需的资源，从而能高效地运行，避免任何反压。

3. 状态的更新频率和状态后端的访问模式

第三个考虑因素是状态的更新频率，因为状态的更新通常是一个高消耗的动作。而不同的状态后端（如 RocksDB，Java Heap）的访问模式差异很大，RocksDB 的每次读取和更新都会涉及序列化和反序列化以及 JNI 操作，而 Java Heap 的状态后端不支持增量 checkpoint，导致大状态场景需要每次持久化的数据量较大。这些因素都会显著地影响集群的大小和 Flink 作业所需的资源。

4. 网络容量

网络容量不仅仅会收到 Flink 应用程序本身的影响，也会受到可能正在交互的 Kafka、HDFS 等外部服务的影响。这些外部服务可能会导致额外的网络流量。例如，启用 replication 可能会在网络的消息 broker 之间产生额外的流量。

5. 磁盘带宽

如果你的应用程序依赖了基于磁盘的状态后端，如 RocksDB，或者考虑使用 Kafka 或 HDFS，那么磁盘的带宽也需要纳入考虑。

6. 机器数量及其可用 CPU 和内存

最后但并非最不重要的，在开始应用部署前，你需要考虑集群中可用机器的数量及其可用的 CPU 和内存。这最终确保了在将应用程序投入生产之后，集群有充足的处理能力。

更多需要考虑的特定方面是你或者你的组织能接受的SLA（服务等级协议）。例如，考虑你的组织能接受的宕机时间，能接受的延迟和最大吞吐。这些 SLA 都会对 Flink 集群大小产生影响。

在确定 Flink 作业所需资源数目时，上述所有的因素应该能起到良好的指示作用，另外这也算是提供了 Flink 作业如何正常运行的指引。你也需要始终考虑增加一些资源的缓冲用于作业恢复时的追赶和处理一些负载高峰。例如，当你的 Flink 发生故障时，系统会需要额外的资源来做恢复工作以及从 Kafka topic 或其他消息客户端追上最新的数据。

如果你对这个话题感兴趣，可以访问我们早期的博客了解更多细节。下图总结展示了上文讨论的6点考虑项，你可以下载保存以备不时之需。