简短的回答 BufferedMutator 通常提供比仅使用 Table#put(List<Put>) 但需要适当调整 hbase.client.write.buffer , hbase.client.max.total.tasks , hbase.client.max.perserver.tasks 以及 hbase.client.max.perregion.tasks 好的表现。

解释

将放置列表传递给hbase客户端时，它将按目标区域对放置进行分组，并按目标区域服务器对这些组进行批处理。为每个批发送一个rpc请求。这降低了rpc开销，特别是在put非常小的情况下，因此每个请求的rpc开销非常大。
这个 Table 客户机立即将所有put发送到区域服务器并等待响应。这意味着，任何可能发生的批处理都限制在单个api调用中的put数量，并且从调用方的Angular 来看，api调用是同步的。然而 BufferedMutator 在一个缓冲区中保持对put的缓冲，并根据由一个名为 AsyncProcess . 从调用者的Angular 来看，每个api调用仍然是同步的，但是整个缓冲策略提供了更好的批处理。后台刷新模型还允许连续的请求流，这与更好的批处理相结合意味着能够支持更多的客户端线程。然而，由于这种缓冲策略，缓冲区越大，调用者看到的每个操作的延迟越差，但是通过拥有更多的客户机线程可以维持更高的吞吐量。
控制bufferedmutator吞吐量的一些配置包括： hbase.client.write.buffer ：缓冲区的大小（字节）（越高，峰值吞吐量越好，占用的内存越多） hbase.client.max.total.tasks ：在asyncprocess开始阻止请求之前，群集中挂起的请求数（越高越好，但可能导致客户端cpu不足，或导致服务器过载） hbase.client.max.perserver.tasks ：asyncprocess开始阻止请求之前一个区域服务器的挂起请求数。 hbase.client.max.perregion.tasks ：每个区域的挂起请求数。
另外，为了完整性，不用说，如果瓶颈在服务器端而不是客户端，那么使用 BufferedMutator 结束 Table 在客户身上。