我们使用50-100个bigtable节点（取决于我们处理的数据量，这个数字在一天中在50到100之间变化）。
我们每天都有一个数据流作业，它扫描整个bigtable（一个特定列系列），并将扫描数据转储到GCS。
我们一直在试验工作节点的数量与扫描整个表的速度。通常，作业扫描~100M行（表中有更多行，但我们将范围设置为24小时窗口），扫描数据的大小约为1TiB。
虽然bigtable节点的数量是固定的（例如，在80），但我们以递增的方式将Dataflow工作节点（n1-standard-1）的数量从15改为50，并且扫描速度似乎没有线性扩展。类似地，当我们保持数据流工作者的数量（在50）固定并改变bt节点的数量（在40和80之间）时，读取吞吐量似乎没有太大变化（只要有“足够的”btnode）。如果是这种情况，我们还有哪些其他选项可以加快扫描速度？我们的一个想法是运行多个扫描作业，其中每个作业扫描连续行的子集，但我们希望避免这种方法。
任何帮助将非常感谢！
如上所述，这个问题在一般意义上很难回答。从Cloud Bigtable读取时调整云数据流性能需要了解您的工作负载，并且可能需要不同数量的Dataflow工作节点或Bigtable服务器节点。
你有可能达到扫描性能的上限，瓶颈是Bigtable层下面的底层存储系统，但是没有更多的细节就很难说。
通常，在调整云数据流时，我们建议调查限制和自动调节器方法，尽管这些方法对于摄取工作负载而言通常比简单扫描更为严重。