Question

我正在将Apache Beam 2.13.0和GCP Dataflow运行器一起使用。

我在从批处理管道流式传输到BigQuery时遇到问题：

PCollection<BigQueryInsertError> stageOneErrors =
  destinationTableSelected
    .apply("Write BQ Attempt 1",
      BigQueryIO.<KV<TableDestination, TableRow>>write()
                .withMethod(STREAMING_INSERTS)
                .to(new KVTableDestination())
                .withFormatFunction(new KVTableRow())
                .withExtendedErrorInfo()
                .withFailedInsertRetryPolicy(InsertRetryPolicy.neverRetry())
                .withCreateDisposition(CreateDisposition.CREATE_NEVER)
                .withWriteDisposition(WriteDisposition.WRITE_APPEND))
                .getFailedInsertsWithErr();

错误：

 Shutting down JVM after 8 consecutive periods of measured GC thrashing. 
 Memory is used/total/max = 15914/18766/18766 MB, 
 GC last/max = 99.17/99.17 %, #pushbacks=0, gc thrashing=true. 
 Heap dump not written.

相同的代码可以在流模式下正常工作（如果省略了显式方法设置）。

该代码适用于相当小的数据集（少于200万条记录）。超过250万失败。

从表面上看，这似乎是与此处描述的问题类似的问题：Shutting down JVM after 8 consecutive periods of measured GC thrashing

创建一个单独的问题以添加其他详细信息。

有什么我可以解决的吗？看来问题出在BigQueryIO组件本身内-GroupBy键失败。

Answer 1

包含GroupByKey的转换的问题在于，它将在分组之前等待直到收到 all 当前窗口的数据。

在流模式下，这通常很好，因为将传入的元素窗口化到单独的窗口中，因此GroupByKey仅对很小的数据块进行操作。

但是，在批处理模式下，当前窗口是“全局窗口”，这意味着GroupByKey将在开始执行分组之前等待读取和接收整个输入数据集。如果输入数据集很大，那么您的工作人员将耗尽内存，这将解释您在这里看到的内容。

这带来了一个问题：处理批处理数据时，为什么要使用BigQuery Streaming插入？与大容量导入相比，流插入是relatively expensive（相比之下，批量插入是免费的！）和have smaller quota/limits：批量插入：即使您解决了所看到的问题，Bigquery本身仍可能发现更多问题..

Answer 2

与支持人员和开发人员进行了广泛讨论之后，我们得知不鼓励使用BigQuery从批处理管道中进行流入口，目前（自2.13.0版本开始）不支持。

运行流式传输的GCP数据流插入到BigQuery：GC释放

2 个答案: