Bigquery流媒体插入需要时间

时间:2014-11-19 04:44:05

标签: google-bigquery

在我们模块的负载测试期间,我们发现bigquery插入调用需要花费时间(3-4 s)。我不确定这是否可以。我们正在使用java biguqery客户端libarary,平均每个api调用推送500条记录。我们期望每秒有一百万条记录到我们的模块,所以bigq​​uery插入是处理这种流量的瓶颈。目前推出数据需要数小时。 如果我们需要有关代码或方案或任何内容的更多信息,请告诉我。

由于 的Pankaj

1 个答案:

答案 0 :(得分:3)

由于流媒体的有效载荷大小有限,请参阅Quota policy更容易谈论时间,因为有效载荷以同样的方式限制在我们两个人身上,但我也会提到其他副作用。

我们为每个流媒体请求测量1200-2500毫秒,这在过去的一个月中是一致的,如图所示。

enter image description here

我们看到了几种副作用,但是:

  • 请求随机失败,类型为“后端错误”
  • 请求随机失败,类型为“连接错误”
  • 请求随机类型'timeout'随机失败(请注意此处,因为只有部分行失败而不是整个有效负载)
  • 其他一些错误消息是非描述性的,而且它们非常模糊,以至于它们无法帮助您,只需重试即可。
  • 我们每天都会看到数百起此类故障,因此它们几乎不变,与云健康状况无关。

对于所有这些,我们在付费Google Enterprise支持中打开了案例,但不幸的是他们没有解决它。它接缝推荐的选项,因为这是一个指数退避与重试,甚至支持告诉这样做。哪个人不会让我开心。


您选择的方法如果花费数小时就意味着it does not scale,并且无法扩展。您需要使用async processes重新考虑该方法。为了更快地完成,您需要并行运行多个工作程序,流式传输性能将是相同的。只有10名工人并行,这意味着时间将减少10倍。

后台处理IO绑定或cpu绑定任务现在是大多数Web应用程序中的常见做法。有很多软件可以帮助构建后台作业,其中一些基于Beanstalkd等消息传递系统。

基本上,您需要在封闭网络中分配插入作业,确定优先级,然后使用(运行)它们。嗯,这正是Beanstalkd提供的。

Beanstalkd提供了在管中组织作业的可能性,每个管对应于作业类型。

你需要一个API /生产者,它可以将作业放在一个管上,让我们说一下该行的json表示。这是我们用例的杀手级功能。所以我们有一个获取行的API,并将它们放在管上,这只需要几毫秒,因此您可以实现快速响应时间。

另一方面,你现在在一些管子上有一堆工作。你需要一个代理人。代理人/消费者可以预约工作。

它还可以帮助您进行作业管理和重试:成功处理作业后,消费者可以从管中删除作业。在失败的情况下,消费者可以埋葬这份工作。这项工作不会被推回管中,但可供进一步检查。

消费者可以释放一份工作,Beanstalkd会将这项工作推回管中,并将其提供给其他客户。

可以在大多数常见语言中找到Beanstalkd客户端,web interface可用于调试。