我有一个表存储产品项目信息。行键的格式为业务单位UUID +产品ID +产品序列号。每个行键组件具有固定的字节长度。
写入表将以突发（可能是100K的记录）发生，具有常量BU UUID，但是产品ID，序列号或两者或多或少随机变化。
从表中读取的内容将是一次一行（无扫描），随机键组件。
我的问题是，在写入突发期间BU ID是否会被修复导致特定节点和/或平板电脑的热点？我的理解是，我应该没事，因为我的整体行键值不是单调增加，但我想确定。
正如所罗门所指出的，即使使用更换钥匙，您也可能会观察到热点。它取决于您拥有的节点总数，写入量和行大小。
Bigtable将尝试动态重新平衡，以便密钥空间在其服务器之间均匀分布，但如果应用时间序列架构设计文档中描述的salting技术，您可能会看到更好的结果：https://cloud.google.com/bigtable/docs/schema-design-time-series#ensure_that_your_row_key_avoids_hotspotting
一般来说，如果可能的话，我们建议尝试这样做并进行实验。您可以生成负载，然后使用Cloud Key Visualizer（https://cloud.google.com/bigtable/docs/keyvis-overview）检查您是否遇到热点，只要您有足够的数据可用于执行分析（https://cloud.google.com/bigtable/docs/keyvis-getting-started#viewing-scan）。
您可能还会发现此次演讲在Google Cloud Next 2018中有用：https://www.youtube.com/watch?v=3QHGhnHx5HQ
它描述了在Cloud Key Visualizer的帮助下进行迭代模式设计的方法。