优化内存密集型数据流流水线的GCP成本 [英] Optimising GCP costs for a memory-intensive Dataflow Pipeline

问题描述

我们希望提高在GCP数据流中运行特定的阿帕奇光束管道(Python SDK)的成本。

我们构建了一个内存密集型的ApacheBeam管道，它需要在每个执行器上运行大约8.5 GB的RAM。大型机器学习模型当前加载在转换DoFn.setup方法中，因此我们可以为数百万用户预先计算推荐。

现有GCP计算引擎计算机类型的内存/vCPU比率要么低于我们的要求(每个vCPU最多8 GB RAM)，要么比我们要求的高得多(每个vCPU最多24 GB RAM)： https://cloud.google.com/compute/docs/machine-types#machine_type_comparison

我们已使用GCPm1-ultramem-40机器类型成功运行此管道。然而，硬件使用率--因此，成本--不是最优的。此计算机类型的比率为每个vCPU 24 GB RAM。当使用它来运行上述管道时，虚拟机使用了不到36%的可用内存--但正如预期的那样，我们支付了全部费用。

尝试使用custom-2-13312机器类型(2 vCPU和13 GB RAM)运行同一管道时，数据流崩溃，错误为：

   Root cause: The worker lost contact with the service.

在监视运行数据流作业的Compute Engine实例时，很明显它们正在耗尽内存。数据流尝试将模型加载到内存中两次-每个vCPU一次-但可用内存仅够加载一次。

如果我们能够通知ApacheBeam/Dataflow某个特定的转换需要特定的内存量，那么问题就会得到解决。但我们没有设法找到实现这一点的方法。

我们可以想到的另一个解决方案是尝试更改每个计算引擎VM的数据流执行程序的比率。这将允许我们找到一个比率，在该比率中，我们将在考虑流水线内存要求的同时尽可能少地浪费vCPU。在使用前面提到的custom-2-13312机器类型时，我们尝试使用以下配置运行管道：

1. --number_of_worker_harness_threads=1 --experiments=use_runner_v2
2. --experiments=no_use_multiple_sdk_containers --experiments=beam_fn_api
3. --sdk_worker_parallelism=1

使用(1)时，我们设法拥有一个线程，但Dataflow为每个VM派生了两个Python执行器进程。这导致管道崩溃，因为在仅有足够空间容纳一个模型的情况下，试图将模型加载到内存两次。

使用(2)时，每个VM都会产生一个单独的Python进程，但它使用两个线程运行。这些线程中的每一个都试图加载模型，但VM耗尽了内存。 方法(3)的结果与(1)和(2)非常相似。

无法组合这些配置中的多个。

是否会有一(组)配置允许我们控制每台虚拟机的数据流执行器数量？

有没有其他办法来降低我们可能没有想到的成本？

推荐答案

我们正在研究这些问题的长期解决方案，但这里有一个战术解决方案，可以防止您在方法1和方法2中看到的模型重复：

在工作进程间共享VM中的模型，以避免在每个工作进程中重复该模型。 使用以下实用程序(https://github.com/apache/beam/blob/master/sdks/python/apache_beam/utils/shared.py)，该实用程序在梁2.24中提供 如果您使用的是较早版本的Beam，请仅将shared.py复制到您的项目中并将其用作用户代码。

这篇关于优化内存密集型数据流流水线的GCP成本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！