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