使用hbase.hregion.max.filesize自动拆分hbase区域

aoyhnmkz  于 2021-06-02  发布在  Hadoop
关注(0)|答案(2)|浏览(472)

我正在使用hbase的cloudera发行版(hbase-0.94.6-cdh4.5.0)和cloudera管理器来设置所有集群的配置。
我为hbase设置了以下属性:

<property>
<name>hbase.hregion.max.filesize</name>
<value>10737418240</value>
<source>hbase-default.xml</source>
</property>

注:10737418240<=>10克
因此,根据我阅读的所有文档,数据应该被累积到一个区域中,直到区域大小达到10g。
但是,它似乎不起作用。。。也许我错过了什么。。。
以下是我的hbase表的所有区域及其大小: root@hadoopmaster01:~# hdfs dfs -du -h /hbase/my_table 719 /hbase/my_table/.tableinfo.0000000001 0 /hbase/my_table/.tmp 222.2 M /hbase/my_table/08e225d0ae802ef805fff65c89a15de6 602.7 M /hbase/my_table/0f3bb09af53ebdf5e538b50d7f08786e 735.1 M /hbase/my_table/1152669b3ef439f08614e3785451c305 2.8 G /hbase/my_table/1203fbc208fc93a702c67130047a1e4f 379.3 M /hbase/my_table/1742b0e038ece763184829e25067f138 7.3 G /hbase/my_table/194eae40d50554ce39c82dd8b2785d96 627.1 M /hbase/my_table/28aa1df8140f4eb289db76a17c583028 274.6 M /hbase/my_table/2f55b9760dbcaefca0e1064ce5da6f48 1.5 G /hbase/my_table/392f6070132ec9505d7aaecdc1202418 1.5 G /hbase/my_table/4396a8d8c5663de237574b967bf49b8a 1.6 G /hbase/my_table/440964e857d9beee1c24104bd96b7d5c 1.5 G /hbase/my_table/533369f47a365ab06f863d02c88f89e2 2.5 G /hbase/my_table/6d86b7199c128ae891b84fd9b1ccfd6e 1.2 G /hbase/my_table/6e5e6878028841c4d1f4c3b64d04698b 1.6 G /hbase/my_table/7dc1c717de025f3c15aa087cda5f76d2 200.2 M /hbase/my_table/8157d48f833bb3b708726c703874569d 118.0 M /hbase/my_table/85fb1d24bf9d03d748f615d3907589f2 2.0 G /hbase/my_table/94dd01c81c73dc35c02b6bd2c17d8d22 265.1 M /hbase/my_table/990d5adb14b2d1c936bd4a9c726f8e03 335.0 M /hbase/my_table/a9b673c142346014e01d7cf579b0e58a 502.1 M /hbase/my_table/ae3b1f6f537826f1bdb31bfc89d8ff9a 763.3 M /hbase/my_table/b6039c539b6cca2826022f863ed76c7b 470.7 M /hbase/my_table/be091ead2a408df55999950dcff6e7bc 5.9 G /hbase/my_table/c176cf8c19cc0fffab2af63ee7d1ca45 512.0 M /hbase/my_table/cb622a8a55ba575549759514281d5841 1.9 G /hbase/my_table/d201d1630ffdf08e4114dfc691488372 787.9 M /hbase/my_table/d78b4f682bb8e666488b06d0fd00ef9b 862.8 M /hbase/my_table/edd72e02de2a90aab086acd296d7da2b 627.5 M /hbase/my_table/f13a251ff7154f522e47bd54f0d1f921 1.3 G /hbase/my_table/fde68ec48d68e7f61a0258b7f8898be4 如你所见,有很多区域,其中任何一个区域的大小都接近10g。。。
如果有人遇到过这种问题,或者知道是否有其他配置需要设置,请帮助我!
谢谢

ubbxdtey

ubbxdtey1#

@姆皮法雷蒂,你看到的很有道理。当我第一次看到自动分割后的区域大小时,我也有点震惊。
在hbase 0.94+中,默认的拆分策略是递增到UpperBoundRegionSplitPolicy。区域大小由下面描述的算法决定。
split size是此服务器上所有区域都属于同一个表的区域数,按立方计算,乘以区域刷新大小或最大区域拆分大小的2倍,以较小者为准。例如,如果刷新大小是128m,那么在两次刷新(256mb)之后,我们将拆分这两个区域,当它们的大小为2^3128m2=2048m时,这两个区域将被拆分。如果其中一个区域分裂,那么就有三个区域,现在分裂的大小是3^3128m2=6912m,依此类推,直到我们达到配置的最大文件大小,然后从那以后,我们将使用它。
这是一个很好的策略,因为您可以在区域服务器上获得一个很好的区域分布,而不必等到它们达到10gb的限制。
或者,最好预先拆分表,因为您希望确保充分利用集群的处理能力—如果只有一个区域,则所有请求都将转到分配了该区域的区域服务器。预拆分将区域如何在行键空间上拆分的控制权交给您。

huus2vyu

huus2vyu2#

公关分裂是更好的选择。希望您的数据不会连续插入到单个区域中,并且在达到区域限制时进行拆分或压缩。
在这种情况下,写操作分布不均匀,表的压缩成为写模块的瓶颈。
活动区域上的请求数将很高。

相关问题