我正在对数据流批量加载进行性能基准测试，发现与 Bigquery 命令行工具上的相同加载相比，加载速度太慢了。
文件大小约为 20 MB，包含数百万条记录。我尝试了不同的机器类型并在n1-highmem-4 上获得了最佳的加载性能，加载目标 BQ 表的加载时间约为 8 分钟。
当通过在命令行实用程序上运行 BQ 命令应用相同的表加载时，处理和加载相同量的数据几乎不需要 2 分钟。 关于使用 Dataflow 作业的这种糟糕的负载性能有什么见解吗？如何提高性能使其与 BQ 命令行实用程序相媲美？
【问题讨论】：
标签： google-bigquery google-cloud-dataflow apache-beam
很可能会花费几分钟来启动和关闭虚拟机。如果您正在做的事情可以直接使用 BQ CLI 完成，那么为此目的使用 Dataflow 可能是矫枉过正。但是，您可以使用更多详细信息（例如您的代码和 Dataflow 作业 ID）更新您的问题 - 也许还有其他低效的事情发生。
【讨论】：
TextIO/AvroIO.read() 从Text/Avro 文件中读取数据。然后我根据一些键比较表中的现有记录和 PCollection 中的新条目，以将表中的新元素列表作为Upsert 进程的一部分。在此过程之后，它只需使用BigqueryIO.write() 将TableRows 的新PCollection 推送到目标表中。这是我试图在 Dataflow 中实现的三步过程。
2017-11-24_03_41_00-13093050104159263095 帮助我分析我面临的延迟问题。这是同一作业的作业 ID，需要 16 分钟才能完成。早些时候使用相同的机器类型，我的工作在 8 分钟内完成。相同的作业 ID 是 2017-11-24_02_47_19-15366595440306710005。
BigqueryIO.read().fromQuery() 操作组成。我观察到一些显着延迟的另一部分是我的Upsert 逻辑，我在其中提取现有表记录，与新记录进行比较，最后合并 PCollections 以加载目标。
Transformation 部分，我认为就处理转换的时间而言没有什么意外的事情发生，但“读取配置”是一个简单的 Bigquery 读取操作。任何见解为什么要花很多时间？明天我会在办公室用示例 sn-p 更新我的问题。