Bigtable“写请求”不一致答案

【问题标题】：Bigtable 'write-requests' is not consistentBigtable“写请求”不一致
【发布时间】：2016-09-13 19:22:03
【问题描述】：

我正在使用数据流作业将数据从谷歌存储写入 BigTable，我正在使用 3 个节点的 BigTable 集群，并且有 25 个工作人员在我的数据流作业中并行工作

当我检查大表的“写入请求”图表时，我观察到它在 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}'

只是想了解为什么我在“写请求”中看到这样的变化，上面的记录器语句对写请求有什么影响，或者还有其他我不知道的原因吗？

谢谢！提前

【问题讨论】：

1) 您是否有显示此问题的 Dataflow 作业 ID？ 2) 除了您的 Dataflow 作业之外，还有其他内容写入此表吗？
@jkff 只有我的工作是写大表，工作 ID 是 2016-09-13_07_47_13-11809669185152159324
考虑使用 9 个 Dataflow 工作器，或在作业期间将您的 Bigtable 集群增加到 8-9 个节点。 25 个工作人员将压倒 3 个 Bigtable 集群，从而导致高延迟导致重试的不良状态，从而进一步压倒 Bigtable。我的经验法则是 3 个客户端 CPU 到 1 个 Bigtable 节点。
3 个集群 Big Table 节点应该给我们 30,000 QPS 但是当我检查“写入请求”图表时，它在 1.5k-9k 之间变化，因为我使用了 25 个工人（我也尝试过 50 个工人）但我的写请求从未超过 9k/秒。我们正在尝试达到至少 15k 的写入请求，然后根据我们可以决定是否要增加节点来检查我们的工作花费了多少时间。你能告诉我们为什么我们的写请求在 3 个节点的大表集群中不超过 9k。
@Amandeep – 你在写一个全新的空表吗？

标签： google-cloud-dataflow google-cloud-bigtable

【解决方案1】：

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

你已经在 SO 上多次问过这个问题，我已经回答了。如果我的回答不清楚，我很抱歉。正确平衡 Dataflow 工作器和 Cloud Bigtable 节点是解决此问题的唯一方法。

【讨论】：

这是否意味着如果我添加更多的工人它会压倒大表导致大量重试？现在，我正在按照您的建议与 9 名工人重试相同的工作，但仍在日志中我看到此条目“重试失败的呼叫。失败 #1，得到：Status{code=INTERNAL, description=null, cause=com.google.bigtable.repackaged.io.netty.handler.codec.http2.StreamBufferingEncoder$Http2ChannelClosedException: Connection closed}'
嗯。你用的是哪个类？哪个 jar 版本？
我使用的是 0.9.1 版本的 bigTable，1.1.5 版本的 hbase，对于 io.netty，我使用的是以下依赖项 io.nettynetty-tcnative -boringssl-static1.1.33.Fork19
您使用的是 CloudBigtableIO、BigtableIO 还是 AbstractCloudBigtableTableDoFn？
我们使用的是CloudBigtableIO，下面是写入BigTable的代码： CloudBigtableIO.initializeForWrite(p); PCollection fileData = p.apply("从 GS 读取 Krux 数据", TextIO.Read.from(options.getInputGSPath())); fileData.apply("Format as BT Mutation for AID" , ParDo.of(new DoFn() { public void processElement(ProcessContext c) { convertFileDataToRow(c); } })).apply("写入AID_KRUXID 表",CloudBigtableIO.writeToTable(config));

【解决方案2】：

根据 cmets，OP 正在写入一个空表。

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

通过预先拆分表，您是在告诉 Cloud Bigtable 创建多个（空）tablet，它们将分布在不同的服务器节点上。

您只能在创建时预拆分表；创建表后，Bigtable 会接管平板电脑拆分和合并的管理，您将无法影响它。

另外需要注意的是，让预先拆分的表格闲置一段时间（例如超过一天）会导致 Bigtable 撤消您的拆分，因为表格上没有任何活动。因此，您应该打算在创建后立即开始使用预拆分表，然后再撤消您的工作。

另一个经验法则是创建平板电脑拆分，这样每个平板电脑将拥有约 512MB 的数据。

您可以通过两种方式告诉 Bigtable 预先拆分表格：

Using the HBase shell
使用以下任何管理 API：
- Admin.createTable(HTableDescriptor desc, byte[][] splitKeys)
  
  通过自己计算来手动指定拆分键。如果您的数据未在字典键空间中均匀分布，则很有用。
- Admin.createTable(HTableDescriptor desc, byte[] startKey, byte[] endKey, int numRegions)
  
  要求 Bigtable 在两个提供的键之间创建 numRegions 的偶数分割数：startKey 和 endKey。请注意，Bigtable 称为 tablets，HBase 称为 regions，因此这些术语是等价的。
- Admin.createTableAsync(HTableDescriptor desc, byte[][] splitKeys)
  
  与第一种方法相同，但异步。

【讨论】：