背景:我在存储在Google存储空间中的30个单独的压缩文件中有30天的数据。我必须将它们写入同一个表中30个不同分区的BigQuery表中。每个压缩文件大小约为750MB。
我今天在Google Dataflow上对同一数据集进行了2次实验。
实验1 :我使用TextIO读取每天的压缩文件,应用简单的ParDo转换来准备TableRow对象,并使用BigQueryIO将它们直接写入BigQuery。因此,基本上创建了30对并联的未连接源和接收器。但我发现在任何时候,只有3个文件被读取,转换并写入BigQuery。任何时候,Google Dataflow的ParDo转换和BigQuery写入速度大约为6000-8000个元素/秒。 因此,在任何时候只有3个源和接收器被处理,这显着减慢了过程。在90分钟内,只有7个30个文件被写入表格的单独BigQuery分区。
实验2 :这里我首先从相同的压缩文件中读取每天的数据30天,对这30个PCollections进行ParDo转换,并将这30个结果Pcollections存储在PCollectionList对象中。所有这30个TextIO源都是并行读取的。 现在我直接使用BigQueryIO将与PCollectionList中每天数据相对应的每个PCollection写入BigQuery。因此,30个水槽再次并行写入。 我发现在30个并行源中,只有3个源被读取并以大约20000个元素/秒的速度应用ParDo变换。在写这个问题的时候已经过了1小时,从所有压缩文件中读取甚至没有完全读取50%的文件,并且写入BigQuery表分区甚至还没有开始。
仅当Google Dataflow读取压缩文件时,才会出现这些问题。我曾经问过一个关于它从压缩文件中读取速度慢的问题(Relatively poor performance when reading compressed files vis a vis normal text files kept in google storage using google dataflow),并且被告知并行化工作会使读取更快,因为只有1名工作人员读取压缩文件而多个来源意味着多名工作人员有机会读取多个文件。但这似乎也没有起作用。
有没有办法加快从多个压缩文件读取整个过程并同时写入BigQuery数据流作业中同一个表的不同分区?
答案 0 :(得分:2)
每个压缩文件将由单个工作人员读取。使用numWorkers管道选项可以增加作业的初始工作数,并且可以使用maxNumWorkers管道选项设置可以扩展到的最大数量。