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