我正在使用Google Cloud Platform将数据从Azure服务器传输到BigQuery表（从功能上说，工作得很顺利，顺畅）。 管道如下所示： Dataflow streaming pipeline
＆＃39; FetchMetadata＆＃39;管道的一部分是一个简单的TextIO.Read实现，我用GCP存储桶中的元数据读取66行.csv文件：
PCollection<String> metaLine = p.apply(TextIO.Read.named("FetchMetadata")
.from("gs://my-bucket"));
当我在批处理模式下使用我的管道时，这就像一个魅力：首先，元数据文件在不到一秒的vCPU时间内加载到管道中，然后数据本身被加载到管道中。现在当在Streaming模式下运行时，我希望在某种程度上复制该行为，但是当我使用相同的代码时会出现问题：当运行管道仅15分钟（实际时间）时，TextIO.Read块使用高达4小时的vCPU时间。对于将为低预算项目永久运行的管道，这是不可接受的。
所以我的问题是：是否有可能更改代码以便定期再次读取文件（如果文件更改我想要更新管道，那么让我们说每小时更新）并且不会一直喜欢它＆＃ 39;现在正在做。
我找到了一些文档，其中提到了TextIO.Read.Bound，它看起来像是一个开始解决这个问题的好地方，但它不能解决我的定期更新问题（至于我知道）
答案 0 :(得分：1)
我陷入了类似的境地。我解决这个问题的方式有点不同。我希望社群对此解决方案有所了解。
我在GCS存储桶中每小时更新一次文件。我关注Scheduling Dataflow Jobs from App Engine or Google Cloud Function的博客文章。
我将应用引擎端点配置为从GCS存储区接收包含要处理的文件的对象更改通知。对于创建的每个文件（更新也是对象存储中的创建操作），应用引擎应用程序将向Google数据流提交作业。该作业将读取文件中的行（HTTP请求正文中的文件名）并将其发布到Google PubSub主题。
然后，流媒体管道已订阅Google PubSub主题，该主题将处理相关行并将其输出到大查询。这样，流式传输管道在空闲时以最小工作器数量运行，文件的摄取通过批处理管道发生，并且流式传输管道根据Google PubSub主题中的出版物量进行扩展。
在向Google Dataflow提交作业的教程中，jar在基础终端上执行。我修改了代码，使用可以使用参数执行的模板向Google数据流提交作业。这样，作业提交操作变得超轻，同时仍然为每个新文件上传到GCS存储桶创建作业。有关执行Google数据流作业模板的详细信息，请参阅this链接。
注意：请在评论中提及是否需要针对数据流作业模板和应用引擎应用程序的代码片段修改答案，我将相应地更新答案。