我在有5个区域服务器的hbase中存储数据。我正在使用url的md5散列作为我的行键。目前所有的数据只存储在一个区域服务器上。所以我想对区域进行预分割，这样数据就可以在所有区域服务器上统一传输，这样数据就可以在每个区域服务器上统一传输。我想将数据拆分为行键的第一个字符。因为第一个字符是从0到f（16个字符）。像rowkey从0到3的数据将进入第1个区域服务器，第2个区域服务器为3-6，第3个区域服务器为6-9，第4个区域服务器为a-d，第5个区域服务器为d-f。我该怎么做？
tuwxkamq1#
如果您已经存储了所有数据，我建议您使用hbase shell手动将一些区域移动到另一个区域服务器。
hbase> move ‘ENCODED_REGIONNAME’, ‘SERVER_NAME’
移动区域。可以选择指定目标regionserver，否则我们将随机选择一个。注意：您传递的是编码的区域名称，而不是区域名称，因此此命令与其他命令略有不同。编码的区域名称是区域名称上的哈希后缀：例如，如果区域名称是testtable，则为00944294561289497600452.527db2f95c8a9e0116f0cc13c680396。然后编码的区域名部分是527db2f95c8a9e0116f0cc13c68096。服务器名是它的主机、端口和startcode。例如：host187.example.com，600201289493121758
5lhxktic2#
如果您使用apachephoenix在hbase中创建表，那么可以在create语句中指定salt\u bucket。表将被分割成与bucket所提到的一样多的区域。phoenix计算rowkey的散列（最可能是一个数值散列%u bucket），并将列单元格分配给适当的区域。
CREATE TABLE IF NOT EXISTS us_population ( state CHAR(2) NOT NULL, city VARCHAR NOT NULL, population BIGINT CONSTRAINT my_pk PRIMARY KEY (state, city)) SALT_BUCKETS=3;
这将把表预拆分为3个区域或者，hbase默认ui允许您相应地分割区域。
rbl8hiat3#
创建表时可以提供splits属性。
create 'tableName', 'cf1', {SPLITS => ['3','6','9','d']}
4个分割点将生成5个区域。请注意，hbase的defaultloadbalancer不能保证在regionserver之间100%均匀分布，一个regionserver可能从同一个表托管多个区域。有关其工作原理的更多信息，请查看以下内容：
public List<RegionPlan> balanceCluster(Map<ServerName,List<HRegionInfo>> clusterState)
根据指定的服务器信息Map到每台服务器负载最多的区域，生成全局负载平衡计划。负载平衡不变量是所有服务器都在每个服务器的平均区域数的1个区域内。如果平均值是整数，则所有服务器都将平衡到平均值。否则，所有服务器都将具有楼层（平均）或天花板（平均）区域。hbase-3609使用guava的minmaxpriorityqueue对regionstomove进行建模，这样我们就可以从队列的两端获取数据。首先，我们检查主服务器是否发现了空区域服务器。如果是这样，我们分别从区域的头部/尾部tomove中交替选择新的/旧的区域。这种交替避免了在新发现的区域服务器上聚集年轻区域。否则，我们将从区域负责人中选择新区域。hbase-3609的另一个改进是，我们以循环方式将区域从regionstomove分配给负载不足的服务器。以前一个负载不足的服务器会在我们移动到下一个负载不足的服务器之前被填满，导致年轻区域的集群。最后，我们随机洗牌未加载的服务器，以便它们在对balancecluster（）的调用中相对均匀地接收卸载区域。该算法目前的实现方式如下：确定每个服务器应具有的两个有效区域数，min=楼层（平均值）和max=天花板（平均值）。遍历负载最大的服务器，从每个服务器中去掉区域，这样每个服务器就可以承载最大的区域。到达已具有<=最大区域的服务器后停止。将区域从最近移动到最少。遍历负载最少的服务器，分配区域，使每台服务器正好有最小的区域。到达已具有>=最小区域的服务器时停止。分配给负载不足服务器的区域是上一步中删除的区域。有可能没有足够的区域来填充每台负载不足的服务器，如果是这样的话，我们最终会得到一些需要这样做的区域，需要的区域。也有可能，我们能够填充每个未加载的区域，但最终得到的区域没有从过载的服务器分配，但仍然没有分配。如果这两个条件都不成立（没有区域需要填充负载不足的服务器，没有区域从过载的服务器中剩余），我们就完成并返回。否则我们将在下面处理这些案件。如果neededregions不为零（仍然有负载不足的服务器），我们将再次迭代负载最多的服务器，从每个服务器中去掉一个服务器（这将使它们从具有最大区域变为具有最小区域）。我们现在肯定有更多的区域需要分配，无论是从上一步还是从最初的服务器过载脱落。迭代加载最少的服务器，将每个服务器填充到最小值。如果仍有更多的区域需要分配，请再次迭代加载最少的服务器，这次将每个服务器（将它们填充到最大值）直到用完为止。所有服务器现在都将承载最小或最大区域。此外，任何托管>=max regions的服务器都保证在平衡结束时有max regions。这可确保移动的区域数尽可能少。todo:我们最多可以将离开特定服务器的区域数重新分配为它们报告的负载最多的区域数。我们应该把所有的作业都记在记忆里吗？有反对意见吗？这是不是意味着我们需要对主人进行治疗？或者只是小心监视(目前的想法是我们会把所有的作业都记在记忆里）
3条答案
按热度按时间tuwxkamq1#
如果您已经存储了所有数据，我建议您使用hbase shell手动将一些区域移动到另一个区域服务器。
移动区域。可以选择指定目标regionserver，否则我们将随机选择一个。注意：您传递的是编码的区域名称，而不是区域名称，因此此命令与其他命令略有不同。编码的区域名称是区域名称上的哈希后缀：例如，如果区域名称是testtable，则为00944294561289497600452.527db2f95c8a9e0116f0cc13c680396。然后编码的区域名部分是527db2f95c8a9e0116f0cc13c68096。服务器名是它的主机、端口和startcode。例如：host187.example.com，600201289493121758
5lhxktic2#
如果您使用apachephoenix在hbase中创建表，那么可以在create语句中指定salt\u bucket。表将被分割成与bucket所提到的一样多的区域。phoenix计算rowkey的散列（最可能是一个数值散列%u bucket），并将列单元格分配给适当的区域。
这将把表预拆分为3个区域
或者，hbase默认ui允许您相应地分割区域。
rbl8hiat3#
创建表时可以提供splits属性。
4个分割点将生成5个区域。
请注意，hbase的defaultloadbalancer不能保证在regionserver之间100%均匀分布，一个regionserver可能从同一个表托管多个区域。
有关其工作原理的更多信息，请查看以下内容：
根据指定的服务器信息Map到每台服务器负载最多的区域，生成全局负载平衡计划。负载平衡不变量是所有服务器都在每个服务器的平均区域数的1个区域内。如果平均值是整数，则所有服务器都将平衡到平均值。否则，所有服务器都将具有楼层（平均）或天花板（平均）区域。hbase-3609使用guava的minmaxpriorityqueue对regionstomove进行建模，这样我们就可以从队列的两端获取数据。首先，我们检查主服务器是否发现了空区域服务器。如果是这样，我们分别从区域的头部/尾部tomove中交替选择新的/旧的区域。这种交替避免了在新发现的区域服务器上聚集年轻区域。否则，我们将从区域负责人中选择新区域。hbase-3609的另一个改进是，我们以循环方式将区域从regionstomove分配给负载不足的服务器。以前一个负载不足的服务器会在我们移动到下一个负载不足的服务器之前被填满，导致年轻区域的集群。最后，我们随机洗牌未加载的服务器，以便它们在对balancecluster（）的调用中相对均匀地接收卸载区域。该算法目前的实现方式如下：
确定每个服务器应具有的两个有效区域数，min=楼层（平均值）和max=天花板（平均值）。
遍历负载最大的服务器，从每个服务器中去掉区域，这样每个服务器就可以承载最大的区域。到达已具有<=最大区域的服务器后停止。将区域从最近移动到最少。
遍历负载最少的服务器，分配区域，使每台服务器正好有最小的区域。到达已具有>=最小区域的服务器时停止。分配给负载不足服务器的区域是上一步中删除的区域。有可能没有足够的区域来填充每台负载不足的服务器，如果是这样的话，我们最终会得到一些需要这样做的区域，需要的区域。也有可能，我们能够填充每个未加载的区域，但最终得到的区域没有从过载的服务器分配，但仍然没有分配。如果这两个条件都不成立（没有区域需要填充负载不足的服务器，没有区域从过载的服务器中剩余），我们就完成并返回。否则我们将在下面处理这些案件。
如果neededregions不为零（仍然有负载不足的服务器），我们将再次迭代负载最多的服务器，从每个服务器中去掉一个服务器（这将使它们从具有最大区域变为具有最小区域）。
我们现在肯定有更多的区域需要分配，无论是从上一步还是从最初的服务器过载脱落。迭代加载最少的服务器，将每个服务器填充到最小值。如果仍有更多的区域需要分配，请再次迭代加载最少的服务器，这次将每个服务器（将它们填充到最大值）直到用完为止。
所有服务器现在都将承载最小或最大区域。此外，任何托管>=max regions的服务器都保证在平衡结束时有max regions。这可确保移动的区域数尽可能少。
todo:我们最多可以将离开特定服务器的区域数重新分配为它们报告的负载最多的区域数。我们应该把所有的作业都记在记忆里吗？有反对意见吗？这是不是意味着我们需要对主人进行治疗？或者只是小心监视(目前的想法是我们会把所有的作业都记在记忆里）