亚马逊托管Apache Flink服务的实时成本节约

关键要点

在本文中，你将了解到如何通过在亚马逊托管Apache Flink服务上运行应用程序来优化成本。这包括：

自由度和灵活性：Apache Flink的无服务器架构使得实时成本优化成为可能。成本组成：了解Kinesis处理单元KPU、存储和备份快照的成本。预算监控：使用AWS成本探查器来监控支出。资源使用：识别资源的过度配置或低效使用。代码优化：优化代码以降低整体资源需求，最终实现成本节约。

在运行Apache Flink应用程序时，利用其无服务器特性可以显著降低实时成本。通过亚马逊托管的服务，用户可以轻松添加或删除计算资源，无需在规划阶段再进行。

Apache Flink是一个开源流处理框架，广泛应用于数百家公司和成千上万的开发者中，尤其是在关键业务应用中。它具有高度可用和可扩展的特性，能够为最苛刻的流处理应用提供高吞吐量和低延迟。Apache Flink的可扩展特性在云中优化成本方面至关重要。

托管Apache Flink服务是一个完全托管的服务，可降低构建和管理Apache Flink应用程序的复杂性。该服务能够管理基础架构和Apache Flink组件，并提供持久的应用状态、指标、日志等功能。

exp加速器官网

接下来，我们将深入了解托管Apache Flink的成本模型、在Apache Flink应用中节约成本的领域，以及更全面地理解数据处理管线。我们还将探讨如何理解成本、判断应用是否过度配置、如何考虑自动扩展，并提出有效的Apache Flink应用优化方法。最后，我们将提出关于工作负载的重要问题，以确定Apache Flink是否适合你的用例。

管理服务Apache Flink上的成本计算

为了优化托管Apache Flink应用的成本，了解其定价组成是非常有帮助的。

托管Apache Flink应用程序由Kinesis处理单元KPU组成，每个KPU包含1个虚拟CPU和4GB内存。分配给应用程序的KPU总数通过两个你可以直接控制的参数相乘得出：

并行度：Apache Flink应用程序的并行处理级别。每KPU的并行度：每个并行度分配的资源。

KPU的数量通过以下简单公式确定：KPU = 并行度 / 每KPU的并行度，向上取整至下一个整数。

每个应用还会额外收取一个KPU用于协调，且并不直接用于数据处理。

KPU的总数量决定了分配给应用程序的资源、CPU、内存和应用存储。每个KPU分配1 vCPU和4GB内存，其中默认3500MB分配给正在运行的应用，剩余的1GB用于应用状态存储管理。每个KPU还附带50GB的存储。Apache Flink将应用状态保留在内存中到可配置的限制，并溢出到附加存储。

第三个成本组件是持久的应用备份或快照。该组件完全可选，对整体成本的影响较小，除非保留非常多的快照。

截至本文撰写时，位于美国东部俄亥俄AWS区域中的每个KPU费用为每小时011，附加的应用存储则为每GB每月010。持久应用备份快照的费用为每GB每月0023。欲了解最新的定价和不同区域的信息，请参阅亚马逊托管Apache Flink定价。

以下图示展示了在托管Apache Flink上运行的应用程序的成本组成比例。你可以通过并行度和每KPU的并行度参数控制KPU的数量。持久应用备份存储未在图中显示。

在接下来的部分中，我们将讨论如何监控你的成本、优化应用程序资源的使用，并找出满足你的吞吐量需求所需的KPU数量。

AWS成本探查器与理解账单

要查看当前托管Apache Flink的花费，可以使用AWS成本探查器。

在成本探查器控制台中，可以按日期范围、使用类型和服务进行过滤，以孤立你的托管Apache Flink应用程序的花费。以下截图展示了过去12个月的费用，分解成之前部分所述的价格类别。在每月的开支中，很多支出都来自于亚马逊托管Apache Flink Studio的交互式KPU。

使用成本探查器不仅可以帮助你理解账单，但也帮助进一步优化那些可能因自动扩展或吞吐量需求而超出预期的特定应用。通过正确的应用程序标签，可以对这些费用进行细分，查看哪些应用占用了较高的成本。

过度配置或资源低效使用的迹象

为了缩小与托管Apache Flink应用相关的成本，一个简单的方法就是减少应用所用的KPU数量。然而，必须注意，这种减少可能会对性能产生不利影响，需经过充分评估和测试。要快速判断应用是否可能过度配置，可以观察一些关键信号，如CPU和内存使用情况、应用程序功能和数据分布。然而，虽然这些信号可能暗示潜在的过度配置，进行性能测试以验证你的扩展模式是至关重要的。

关键指标

在Amazon CloudWatch上分析应用程序指标可能会揭示出过度配置的明确信号。如果containerCPUUtilization和containerMemoryUtilization指标在该项流量模式下的统计显著时期内持续低于20，那么可能可以缩减数量并将更多数据分配给更少的机器。通常，我们认为应用程序适当天数在containerCPUUtilization在5075之间。虽然containerMemoryUtilization在整日中可能波动并可能受代码优化的影响，但若在较长一段时间内的值持续较低，则可能表明潜在的过度配置。

每KPU的并行度未充分利用

如果应用程序纯粹是I/O绑定，或者仅仅是简单的数据库调用和非CPU密集型操作，那么另一个微妙的迹象是应用程序可能过度配置。在这种情况下，你可以使用托管Apache Flink中的每KPU的并行度参数，将更多任务加载到单一处理单元上。

可以将每KPU的并行度参数视为每个计算和内存资源单元的工作负载密度的度量KPU。将每KPU的并行度增加到默认值1以上会使处理更加密集，在单个KPU上分配更多并行进程。

以下图示展示了如何在保持应用程序并行度不变例如，4的情况下，通过增加每KPU的并行度例如，从1到2，应用程序使用更少的资源来实现相同级别的并行运行。

增加每KPU的并行度值的决定就像本文中的所有建议一样，需谨慎对待。如果增加每KPU的并行度值，会对单一KPU施加更多负载，前提是它能承受这种负载。I/O绑定操作不会显著增加CPU或内存使用，但一个数据计算多个复杂操作的过程函数就不适合集成到一个KPU中，因为这可能会超出资源的承载能力。进行性能测试并评估这是否对你的应用程序是一个好的选择。

如何进行规模调整

在启动托管Apache Flink应用程序之前，估算应该为应用分配多少KPU可能会很困难。通常，了解流量模式在巨型字节每秒的级别边际上应该有所了解，可以帮助你approximate一个起始点。

作为一般规则，可以为应用每处理1 MB/s的流量分配1个KPU。例如，如果你的应用平均处理10 MB/s，那么为应用分配10个KPU作为起始点。请记住，这只是一个高层次的近似估计，尽管我们发现它在一般估算中有效，但你同样需要通过性能测试和评估长期是否适合基于指标CPU、内存、延迟、整体作业性能。

要找到应用程序的适当规模，必须对Apache Flink应用程序进行扩展和缩减。如前所述，在托管Apache Flink中，您有两个单独的控制参数：并行度和每KPU的并行度。一起，这些参数决定了应用程序中的并行处理级别以及可用的整体计算、内存和存储资源。

推荐的测试方法是在分别更改并行度或每KPU并行度时进行实验，以找到合适的规模大小。通常，只需更改每KPU的并行度，以增加并行I/O绑定操作的数量，而不增加整体资源。在其他情况下，只需更改并行度KPU将因此发生变化以找到适合工作负载的规模。

你也可以在操作者级别使用设置并行度来限制源、接收器或其他可能需要限制并独立于扩展机制的操作。例如，假设一个Apache Flink应用程序需要读取来自拥有10个分区的Apache Kafka主题。通过setParallelism()方法，可以将KafkaSource限制为10，但将托管Apache Flink应用程序扩展到并行度高于10，而不会为Kafka源创建空闲任务。建议在其他数据处理情况下，不将操作者的并行度静态设置为固定值，而是应用并行度的一个函数，以便在整个应用程序扩展时进行动态扩展。

扩展与自动扩展

在托管Apache Flink中，修改并行度或每KPU的并行度是应用程序配置的更新。这将导致应用程序自动进行一次快照除非已停用，停止应用程序并使用新的规模重新启动，恢复状态。扩展操作不会导致数据丢失或不一致，但在增加或移除基础设施时，数据处理会暂停一段短时间。这一点在生产环境中调整规模时需要考虑。

在测试和优化过程中，我们建议禁用自动扩展，并修改并行度和每KPU的并行度，以找到最佳值。如前所述，手动扩展只是一项应用配置的更新，可以通过AWS管理控制台或API使用UpdateApplication操作进行。

一旦找到最佳规模，如果预计你的吞吐量会有显著变化，可以决定启用自动扩展。

在托管Apache Flink中，你可以使用多种类型的自动扩展：

现成的自动扩展：可以启用此功能，根据containerCPUUtilization指标自动调整应用程序的并行度。新应用默认启用自动扩展。有关自动扩展算法的详细信息，请参阅自动扩展。细粒度、基于指标的自动扩展：这很简单实现。自动扩展几乎可以基于任何指标，包括应用程序暴露的自定义指标。调度扩展：如果你预计在某些特定时段会出现流量高峰，这可能会很有用。

现成的自动扩展和细粒度基于指标的扩展是互斥的。有关细粒度基于指标的自动扩展、调度扩展和完全工作代码示例的更多详细信息，请参见为亚马逊托管Apache Flink启用基于指标的和调度的扩展。

代码优化

另一个节约托管Apache Flink应用成本的方法是通过代码优化。未经优化的代码将需要更多机器才能执行相同的计算。优化代码可以降低整体资源需求，从而实现缩减和遵循相应的成本节约。

了解代码性能的第一步是通过Apache Flink中内置的工具火焰图进行的。

火焰图可以通过Apache Flink仪表板访问，提供了堆栈跟踪的可视化表示。每当调用方法时，表示该方法调用的条形图根据总样本计数增大。这意味着，如果你代码中有低效的部分，而在火焰图中显示的条形图非常长，那么这就是需要调查如何提高该代码效率的原因。此外，你可以使用亚马逊CodeGuru Profiler来监控和优化在托管Apache Flink上运行的Apache Flink应用程序的性能。

在设计应用程序时，建议使用在给定时间要求的最高级别API。Apache Flink提供了四种级别的API支持：Flink SQL、Table API、Datastream API 和 ProcessFunction API，责任和复杂性逐步增加。如果应用程序可以完全用Flink SQL或Table API编写，使用它们可以更好地利用Apache Flink框架，而不必手动管理状态和计算。

数据倾斜

在Apache Flink仪表板上，你可以收集有关托管Apache Flink作业的其他有用信息。

在仪表板上，可以检查作业应用程序图中的个别任务。每个蓝框代表一个任务，而每个任务由子任务组成，或该任务的分布式工作单元。通过这种方式，你可以识别出子任务中潜在的数据倾斜。

数据倾斜表示与其他子任务相比，一个子任务接收的数据量较多，从而使处理该数据的子任务工作量加大。若出现这样的数据倾斜现象，你可以通过识别源头来消除这一问题。例如，一个GroupBy或者KeyedStream可能在键的分布上存在偏差。这意味着数据在键之间的不均匀分配，导致在Apache Flink计算实例之间的工作负载不均衡。想象一下，一个按userId分组的场景，但你应用程序的某个用户的数据远高于其他用户。这可能导致数据倾斜。为了消除这一问题，可以选择不同的分组键，以便在子任务之间均匀分配数据。请注意，这将需要代码修改，以选择不同的键。

当消除数据倾斜后，可以再次查看containerCPUUtilization和containerMemoryUtilization指标，以减少KPU的数量。

其他代码优化的领域包括确保你通过[异步I/O API](https//awsamazoncom/blogs