Question

我正在设计一个HBase架构，其行键以域名反转开头。例如，com.example.www。虽然有更多的域名以.com而不是.org或.edu结尾，但我认为我不必管理自己的分裂，我可以依赖HBase＆＃ 39;自动拆分以跨区域分配行。即，区域会因为太大而分裂。

我最终会得到更多区域，这些区域的密钥以com.开头而不是org.，但我认为没问题，并且＆＃34; com.区域＆＃34;应该最终分布在我的区域服务器上，对吗？

这里的负载均衡存在问题吗？在Lars的2011 HBase Schema Design video中（链接直接链接到感兴趣的部分），他讨论了一种在密钥开头也具有反向域的模式设计。该视频表示反向域的MD5哈希被用于＆＃34;出于负载平衡的原因＆＃34;。

我可能遗漏了某些内容......如果some.website.com与another.website.org一样可能出现在我的输入中，那么这并不意味着每行都有可能击中一个区域（甚至一个区域服务器）与另一个区域？

Answer 1

HBase通常会在达到hbase.hregion.max.filesize（取决于拆分策略）时在其中点分割2个区域。你可以依靠自动分割，但是由于你的rowkeys的性质（很多＆＃34; com＆＃34;少数几个领域＆＃34; org＆＃34;域）。

可能不是您的确切情况，但请考虑这个潜在的问题：

从只有1个区域的空表开始，按顺序插入145M域，从com。。开始，以org。结尾。
在8000万大关（一个虚构的com.nnnn.www），该区域自动在＆＃34; com.f *＆＃34;中分成2个，产生2个4千万个区域，并继续将行写入区域2
在1.2亿大关（一个虚构的com.yyyy.www），第二个区域达到最大文件大小并在＆＃34; com.p *＆＃34;分成2个4千万个区域。并继续将行写入区域3。
作业以150M域名结束，不再执行拆分。

鉴于此案例，1区和1区2将存储每行40M行，但区域3将存储65M行（它将被分割为80M，但它可能永远不会达到该数量）。此外，由于您将始终写入最后一个区域（即使启用了批处理），该作业也会比同时向多个区域发出批量写入慢很多。

另一个问题，想象你意识到你还需要添加.us域名（10M）。根据这种设计，他们将进入3区，将托管的行数增加到75M。

确保在区域之间均匀分配密钥的常用方法是在密钥的前面添加几个密钥的md5（在本例中为域名）。在HBase中，行键的第一个字节确定将托管它的区域。

只需预先添加md5的几个字符就足以防止尽可能多的热点（一个区域写入太多）并获得良好的自动分割，但通常建议预分割表格以确保更好的分裂。

如果您将md5的2个字符添加到您的行键中，则可以使用15个分割点预分割表格：＆＃34; 10＆＃34;，＆＃34; 20＆＃34;，＆＃34; 30＆＃ 34; ......直到＆＃34; e0＆＃34;。这将创建16个区域，如果它们中的任何一个需要自动分割，它将在它们的中点完成。即：当区域开始于＆＃34; a0＆＃34;结束于＆＃34; af＆＃34;到达hbase.hregion.max.filesize它将被分割为＆＃34; a8＆＃34;而且每个地区都会储存一半的＆＃34; a＆＃34;桶。

如果您有16个带有2个字符前缀的行键的预分割区域，则这是一个区域将托管每一行的示例：

- Region 1 ---------
0b|com.example4.www
- Region 2 ---------
1b|org.example.www
10|com.example.www
- Region 5 ---------
56|com.example3.www
- Region 10 ---------
96|org.example5.www
- Region 11 ---------
af|com.example5.www
- Region 14 ---------
d5|org.example3.www
db|com.example2.www
de|org.example2.www
- Region 16 ---------
fb|org.example4.www

鉴于更多的域名，它会更加均匀，几乎所有地区都会存储相同数量的域名。

在大多数情况下，具有8-16个预分割区域将绰绰有余，但如果没有，您可以选择32个甚至64个预分割区域，直到最大值为256（这将是＆＃ 34; 01＆＃34;，＆＃34; 02＆＃34;，＆＃34; 03＆＃34; ...＆＃34; 9f＆＃34;，＆＃34; a0＆＃34;，＆＃34; a1＆＃34; ......直到＆＃34; fe＆＃34;）

反向域名行密钥，自动拆分和负载均衡

1 个答案: