2016-09-13 14 views
0

我从谷歌存储使用数据流任务写入数据到BigTable的,我使用3个节点的BigTable集群,有25名工人在平行于我的数据流任务的工作Bigtable的“写请求”是不相符

当我检查Big表的'Write-requests'图表,然后我观察到它在1.5k-9k之间波动,按照我的观点,它应该保持一致,因为我一直在传递数据。

当我检查了日志,我发现这个说法来得频繁'Retrying failed call. Failure #1, got: Status{code=UNAVAILABLE, description=Temporary problem while looking up metadata for table AID_KRUXID, cause=null}'

只是想知道为什么我看到在“写请求”做上述记录语句上的写请求的任何影响或这种变化还有其他原因我不知道?

谢谢!提前

+0

1)你有没有出现此问题的一个数据流作业ID? 2)除了Dataflow作业外,还有其他什么东西正在写入此表中? – jkff

+0

@jkff只有我的工作正在写入大表并且作业ID是2016-09-13_07_47_13-11809669185152159324 – Amandeep

+0

考虑使用9个Dataflow工作者,或者在作业期间将您的Bigtable群集增加到8-9个节点。 25名员工将压倒3 Bigtable集群,导致状态不佳,导致高延迟导致重试,从而进一步压倒Bigtable。我的经验法则是将3个客户端CPU连接到1个Bigtable节点。 –

回答

1

考虑使用9个Dataflow工作者,或者在作业期间将您的Bigtable群集增加到8-9个节点。 25名员工将压倒3 Bigtable集群,导致状态不佳,导致高延迟导致重试,从而进一步压倒Bigtable。我的经验法则是将3个客户端CPU连接到1个Bigtable节点。

你已经问过这个问题几次了,我已经回答了。如果我的回答不明确,我很抱歉。 Dataflow工作人员和Cloud Bigtable节点的正确平衡是解决此问题的唯一方法。

+0

这是否意味着如果我添加更多的工人,它会压倒大表导致大量的重试?现在,我正在按照您的建议与9名工人一起重试相同的工作,但仍然在日志中看到此条目“重试失败的呼叫”。失败#1,得到:状态{code = INTERNAL,description = null,cause = com.google.bigtable.repackaged.io.netty.handler.codec.http2.StreamBufferingEncoder $ Http2ChannelClosedException:连接关闭}' – Amandeep

+0

呵呵。你在用哪一堂课?哪个jar版本? –

+0

我使用0.9.1版本的BigTable的,1.1.5版本的HBase的和io.netty我使用以下依赖 io.netty 网状-tcnative-boringssl静电 1.1.33.Fork19 Amandeep

1

根据评论,OP正在写入一个空表。

要提高写入空表的性能,您需要预先拆分表。如果您不预先拆分表,则该表具有一个由单个Cloud Bigtable服务器节点托管的平板电脑,因此您的吞吐量限于单个节点,而不是跨整个集群并行化。

通过预分割表格,您告诉Cloud Bigtable创建大量(空)平板电脑,这些平板电脑将分布在不同的服务器节点上。

您只能在创建时预分割表;在您创建表格后,Bigtable将接管平板电脑分割和合并的管理,并且您无法影响它。

另一件需要注意的事情是,让一个预分割表空闲一段时间(例如超过一天)会导致Bigtable撤消分割,因为表中没有任何活动。因此,在您的工作撤消之前,您应该打算在创建后不久开始使用预先拆分表。

另一个经验法则是旨在创建平板分割,使每个平板电脑都有〜512MB的数据。

有两种方法你可以告诉Bigtable的预拆表:

  1. Using the HBase shell

  2. 使用这些管理的API: