来自Flink Forward Berlin 2017的最受欢迎的会议是Robert Metzger的“坚持下去：如何可靠，高效地操作Apache Flink”。 Robert所涉及的主题之一是如何粗略地确定Apache Flink集群的大小。 Flink Forward的与会者提到他的群集大小调整指南对他们有帮助，因此我们将他的谈话部分转换为博客文章。 请享用！
Flink社区中最常见的问题之一是如何在从开发阶段转向生产阶段时确定群集的大小。 对这个问题的明确答案当然是“它取决于”，但这不是一个有用的答案。 这篇文章概述了一系列问题，要求您提供一些可用作指导的数字。
做计算并建立基线
第一步是仔细考虑应用程序的运营指标，以获得所需资源的基线。
要考虑的关键指标是：
- 每秒记录数和每条记录的大小
- 您拥有的不同key的数量以及每个key的状态大小
- 状态更新的数量和状态后端的访问模式
最后，更实际的问题是您的服务水平协议（SLA）与客户的停机时间，延迟和最大吞吐量有关，因为这些直接影响您的容量规划。
接下来，根据您的预算查看您可用的资源。例如：
- 网络容量，考虑到也使用网络的任何外部服务，如Kafka，HDFS等。
- 您的磁盘带宽，如果您依赖于基于磁盘的状态后端（如RocksDB）（并考虑其他磁盘使用，如Kafka或HDFS）
- 机器的数量以及它们可用的CPU和内存
基于所有这些因素，您现在可以构建正常操作的基线，以及用于恢复追赶或处理负载峰值的资源缓冲区。我建议您在建立基线时考虑检查点期间使用的资源。
示例：让我们举一些例子
我现在将计划在假设的集群上部署作业，以可视化建立资源使用基准的过程。 这些数字是粗略的“背后”值，并且它们并不全面 - 在帖子的最后，我还将确定在进行此计算时我忽略的一些方面。
示例Flink流式处理作业和硬件
示例Flink Streaming作业拓扑
对于此示例，我将部署一个典型的Flink流式作业，该作业使用Flink的Kafka使用者从Kafka主题读取数据。 然后使用键控聚合窗口运算符来变换流。 窗口操作符在5分钟的时间窗口上执行聚合。 由于总是有新数据，我将窗口配置为一个滑动窗口，滑动时间为1分钟。
这意味着我将获得每分钟更新过去5分钟的聚合。 流式传输作业为每个userId创建一个聚合。 从Kafka主题消耗的消息的大小（平均）为2 KB。
吞吐量是每秒100万条消息。 要了解窗口运算符的状态大小，您需要知道不同键的数量。 在这种情况下，它是userIds的数量，即500,000,000个唯一身份用户。 对于每个用户，您计算四个数字，存储为长（8个字节）。
让我们总结一下这项工作的关键指标：
- Message size: 2KB
- Throughput: 1,000,000 msg/sec
- Distinct keys: 500,000,000 (aggregation in window: 4 longs per key)
- Checkpointing: Once every minute.
假设硬件设置
运行该作业的机器有五台，每台机器都运行Flink TaskManager（Flink的工作节点）。 磁盘是网络连接的（在云设置中很常见），从主交换机到运行TaskManager的每台机器都有一个10千兆以太网连接。 Kafka broker分布在不同的机器上运行。
每台机器有16个CPU核心。 为简单起见，我不会考虑CPU和内存要求。 在现实世界中，根据您的应用程序逻辑和使用中的状态后端，您需要注意内存。 此示例使用基于RocksDB的状态后端，该后端功能强大且内存要求低。
单机的视角
要了解整个作业部署的资源需求，最简单的方法是首先关注一台机器和一台TaskManager中的操作。 然后，您可以使用从一台计算机派生的数字来计算总体资源需求。
默认情况下（如果所有运算符具有相同的并行性且没有特殊的调度限制），则每个计算机上都会运行流式作业的所有运算符。
在这种情况下，Kafka源（或消费者），窗口操作符和Kafka接收器（或生产者）都在五台机器中的每台机器上运行。
机器视角 - TaskManager n
keyBy是上图中的一个单独的运算符，因此计算资源需求更容易。 实际上，keyBy是一个API构造，并转换为Kafka源和窗口运算符之间连接的配置属性。
我现在将从上到下遍历每个运营商，以了解他们的网络资源需求。
The Kafka source
要计算单个Kafka源接收的数据量，首先计算聚合Kafka输入。 源每秒接收1,000,000条消息，每条消息2KB。
2KB x 1,000,000/s = 2GB/s
将2GB / s除以机器数量（5）会产生以下结果：
2GB/s ÷ 5 machines = 400MB/s
群集中运行的5个Kafka源中的每一个都接收平均吞吐量为400 MB / s的数据。
The Kafka source calculation
混洗和分区
接下来，您需要确保具有相同key的所有事件（在本例中为userId）最终位于同一台计算机上。 您正在读取的Kafka主题中的数据可能会根据不同的分区方案进行分区。
混洗过程将具有相同key的所有数据发送到一台计算机，因此您将来自Kafka的400MB / s数据流拆分为userId分区流：
400MB/s ÷ 5 machines = 80MB/s
平均而言，您必须向每台计算机发送80 MB / s的数据。 这个分析是从一台机器的角度来看的，这意味着一些数据已经在指定的目标机器上，因此减去80MB / s来解释：
原文连接：https://www.ververica.com/blog/how-to-size-your-apache-flink-cluster-general-guidelines