我在google dataflow上使用python beam,我的管道如下所示:
从文件读取图像URL >>下载图像>>处理图像
问题是我不能让下载图像逐步扩展,因为我的应用程序可能会被图像服务器阻止。
这是我可以限制步伐的一种方法吗?每分钟输入或输出。
谢谢。
答案 0 :(得分:0)
一种可能性,也许是幼稚的,是在该步骤中引入睡眠。为此,您需要知道可以同时运行的ParDo实例的最大数量。如果将autoscalingAlgorithm
设置为NONE
,则可以从numWorkers
和workerMachineType
(DataflowPipelineOptions)中获得。确切地说,有效率将除以线程总数:desired_rate/(num_workers*num_threads(per worker))
。睡眠时间将是有效率的倒数:
Integer desired_rate = 1; // QPS limit
if (options.getNumWorkers() == 0) { num_workers = 1; }
else { num_workers = options.getNumWorkers(); }
if (options.getWorkerMachineType() != null) {
machine_type = options.getWorkerMachineType();
num_threads = Integer.parseInt(machine_type.substring(machine_type.lastIndexOf("-") + 1));
}
else { num_threads = 1; }
Double sleep_time = (double)(num_workers * num_threads) / (double)(desired_rate);
然后,您可以在受限制的Fn中使用TimeUnit.SECONDS.sleep(sleep_time.intValue());
或同等功能。在我的示例中,作为一个用例,我想读取一个公共文件,解析出空行并以最大1 QPS的速率调用自然语言处理API(我之前将desired_rate
初始化为1):
p
.apply("Read Lines", TextIO.read().from("gs://apache-beam-samples/shakespeare/kinglear.txt"))
.apply("Omit Empty Lines", ParDo.of(new OmitEmptyLines()))
.apply("NLP requests", ParDo.of(new ThrottledFn()))
.apply("Write Lines", TextIO.write().to(options.getOutput()));
速率限制Fn为ThrottledFn
,请注意sleep
函数:
static class ThrottledFn extends DoFn<String, String> {
@ProcessElement
public void processElement(ProcessContext c) throws Exception {
// Instantiates a client
try (LanguageServiceClient language = LanguageServiceClient.create()) {
// The text to analyze
String text = c.element();
Document doc = Document.newBuilder()
.setContent(text).setType(Type.PLAIN_TEXT).build();
// Detects the sentiment of the text
Sentiment sentiment = language.analyzeSentiment(doc).getDocumentSentiment();
String nlp_results = String.format("Sentiment: score %s, magnitude %s", sentiment.getScore(), sentiment.getMagnitude());
TimeUnit.SECONDS.sleep(sleep_time.intValue());
Log.info(nlp_results);
c.output(nlp_results);
}
}
}
这样,我得到的速率为1个元素/秒,如下图所示,即使使用请求的数量没有真正分散,也避免了使用配额不足的情况(您可能会同时收到8个请求,然后睡眠8秒,依此类推。 )。这只是一个测试,可能最好使用番石榴的rateLimiter。
如果管道正在使用自动缩放(THROUGHPUT_BASED
),它将更加复杂,并且应该更新工作程序的数量(例如,Stackdriver Monitoring具有job/current_num_vcpus
度量)。其他一般考虑因素是通过使用虚拟GroupByKey或通过splitIntoBundles等拆分源来控制并行ParDos的数量。我想看看是否还有其他更好的解决方案。