Hbase table 重复

Hbase table duplication

有办法在集群的每个节点上复制 table 数据吗？ 我需要对数据局部性的最大等级进行性能测试。 默认情况下，HBase 将数据分布在集群节点的一小部分（在 1 或 2 个节点上），可能是因为我的数据不是很大（~ 2 GB）。 我知道 Hbase 是为更大的数据集设计的，但在这种情况下，这对我来说是一个要求。

关于它有很多不错的读物*（请参阅 post 的末尾），但我会尝试用我自己的话来解释它；）

HBase 不负责数据复制，Hadoop HDFS 负责，并且默认配置复制因子为 3，这意味着所有数据将存储在至少 3 个节点中。

数据局部性是获得良好性能的一个关键方面，但实现最大数据局部性很容易：您只需要将 HBase 区域服务器 (RS) 与 Hadoop 数据节点 (DN) 并置，因此，您所有的 DN 也应该具有 RS 角色。一旦你有了它，HBase 会自动将数据移动到需要的地方（在主要压缩上）以实现数据局部性，仅此而已，只要每个 RS 都有它在本地服务的区域的数据，你就会有数据局部性。

即使您将数据复制到多个 DN，每个区域（及其包含的行）也将仅由一个 RS 提供服务，您有复制因子为 3、10 或 100...读取属于区域 #1 的行将始终命中相同的 RS，这将是托管该区域的 RS（它将从 HDFS 本​​地读取数据，因为数据局部性）。如果承载该区域的 RS 出现故障，该区域将自动分配给另一个 RS（因为数据也被复制到其他 DN）

你可以做的是拆分你的 table，每个 RS 都有分配给它的行（区域）桶，所以当你读取或写入数据时，尽可能多的不同 RS 可以同时工作，只要您不总是访问相同的区域（称为区域服务器热点**），就会增加整体吞吐量。

因此，您应该始终首先确保 table 的所有区域都分配给不同的 RS，并且它们收到相同数量的 R/W 请求。完成后，您可以将 table 拆分为更多区域一次，直到集群的所有 RS 上的区域数量为偶数（如果您不满意，您可能需要手动分配它们负载平衡器）。

请注意，即使您似乎拥有完美的区域分布，但如果您的数据访问模式不正确（或不均匀）并且最终没有均匀地到达所有区域，您的性能仍然会很差这完全取决于您的应用程序。

(*) 推荐读物：

(**) 为了避免 RS 热点，我们总是将 table 设计为具有非单调递增的行键，因此第 1、2、3 ... N 行托管在不同的区域，常见的方法是使用 MD5(id) + id 作为 rowkey。这种方法有其自身的一系列缺点：您无法扫描前 10 行，因为它们已加盐。