使用 Apache Beam 的 Dataflow 批量加载的性能问题

Posted 2023-03-25

【中文标题】使用 Apache Beam 的 Dataflow 批量加载的性能问题

【英文标题】：Performance issues on Dataflow batch loads using Apache Beam

【发布时间】：2017-11-25 04:12:13

【问题描述】：

我正在对数据流批量加载进行性能基准测试，发现与 Bigquery 命令行工具上的相同加载相比，加载速度太慢了。

文件大小约为 20 MB，包含数百万条记录。我尝试了不同的机器类型并在n1-highmem-4 上获得了最佳的加载性能，加载目标 BQ 表的加载时间约为 8 分钟。

当通过在命令行实用程序上运行 BQ 命令应用相同的表加载时，处理和加载相同量的数据几乎不需要 2 分钟。 关于使用 Dataflow 作业的这种糟糕的负载性能有什么见解吗？如何提高性能使其与 BQ 命令行实用程序相媲美？

【参考方案1】：

很可能会花费几分钟来启动和关闭虚拟机。如果您正在做的事情可以直接使用 BQ CLI 完成，那么为此目的使用 Dataflow 可能是矫枉过正。但是，您可以使用更多详细信息（例如您的代码和 Dataflow 作业 ID）更新您的问题 - 也许还有其他低效的事情发生。

【讨论】：

谢谢@jkff。周末后我会在办公室分享更多细节（工作 ID 和 sn-ps）。但是我可以解释确切的过程。首先，我的代码使用TextIO/AvroIO.read() 从Text/Avro 文件中读取数据。然后我根据一些键比较表中的现有记录和 PCollection 中的新条目，以将表中的新元素列表作为Upsert 进程的一部分。在此过程之后，它只需使用BigqueryIO.write() 将TableRows 的新PCollection 推送到目标表中。这是我试图在 Dataflow 中实现的三步过程。

请找到工作 ID：2017-11-24_03_41_00-13093050104159263095 帮助我分析我面临的延迟问题。这是同一作业的作业 ID，需要 16 分钟才能完成。早些时候使用相同的机器类型，我的工作在 8 分钟内完成。相同的作业 ID 是 2017-11-24_02_47_19-15366595440306710005。

这项工作似乎包括一个“读取配置”步骤，大部分时间。你能包括一些你的代码吗？另外，您是否查看过 Dataflow Web UI 中的转换时间以及那里的日志？他们可能会提示正在发生的事情。

谢谢@jkff ！！！我还确定了占用大部分时间的部分。 “读取配置”是我使用“NestedValueProvider”查找“文件名”的运行时值并将该值传递给简单的“选择”命令的步骤，我正在获取一些配置值，例如“表名”、“ schema' 等。此过程由BigqueryIO.read().fromQuery() 操作组成。我观察到一些显着延迟的另一部分是我的Upsert 逻辑，我在其中提取现有表记录，与新记录进行比较，最后合并 PCollections 以加载目标。

通过查看 PCollections 上的Transformation 部分，我认为就处理转换的时间而言没有什么意外的事情发生，但“读取配置”是一个简单的 Bigquery 读取操作。任何见解为什么要花很多时间？明天我会在办公室用示例 sn-p 更新我的问题。