我正在使用数据流作业从谷歌存储中向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}'
只是想了解为什么我会在“写入请求”中看到这种变化。上面的logger语句对写请求有什么影响，还是有其他我不知道的原因？
谢谢！提前
答案 0 :(得分：1)
考虑使用9个Dataflow工作程序，或在作业期间将Bigtable集群增加到8-9个节点。 25名工作人员将压倒3个Bigtable集群，导致一个糟糕的状态，其中高延迟导致重试，这进一步压倒了Bigtable。我的经验法则是3个客户端CPU到1个Bigtable节点。
你已经在SO上问了几次这个问题，我已经回答了。如果我的回答不清楚，我很抱歉。 Dataflow worker和Cloud Bigtable节点的正确平衡是解决此问题的唯一方法。
答案 1 :(得分：1)
根据评论，OP正在写入空表。
要提高写入空表的性能，需要预先拆分表。如果您没有预先拆分表，则该表具有单个平板电脑，该平板电脑由单个Cloud Bigtable服务器节点托管，因此您的吞吐量仅限于单个节点，而不是在整个集群中并行化。 / p>
通过预先拆分表，您告诉Cloud Bigtable创建了许多（空）平板电脑，这些平板电脑将分布在不同的服务器节点上。
您只能在创建时预分割表格;在您创建表格后，Bigtable接管了平板电脑拆分和合并的管理，您无法对其进行影响。
另外需要注意的是，将预分割表空闲一段时间（例如，超过一天）将导致Bigtable撤消您的分割，因为表上没有活动。因此，您应该在创建之后立即开始使用预拆分表，然后再撤消工作。
另一个经验法则是创建平板电脑分割，使每个平板电脑拥有~512MB的数据。
有两种方法可以告诉Bigtable预分割表：
使用以下任何管理API：
Admin.createTable(HTableDescriptor desc, byte[][] splitKeys)
通过自己计算拆分键来手动指定。如果您的数据不是均匀分布在字典键空间中，则非常有用。
Admin.createTable(HTableDescriptor desc, byte[] startKey, byte[] endKey, int numRegions)
要求Bigtable在两个提供的密钥之间创建Crystal Report个偶数分割：numRegions和startKey。请注意，Bigtable调用平板电脑，HBase调用区域，因此这些条款是等效的。
Admin.createTableAsync(HTableDescriptor desc, byte[][] splitKeys)
与第一种方法相同，但是异步。