Below is a look at the structure of the Hbase:meta table, Hbase:meta table, save the region address of each table, there are some other information, such as the name of region, Hregioninfo, server information. Each row in the Hbase:meta table corresponds to a single region. For example, we now create a table called "T". The corresponding lines in the Hbase:meta look like the following.
row |
column Family |
column Qualifier |
value |
t,,1351700811858 |
info |
regioninfo |
name => ' t,,1351700811858. 90a3b2353709773 ebc2423. 04a79dcbbc90a3b23 53709773ebc2423. ', Startkey = ', EndKey = ', encoded = 04a79 Dcbbc9 0a3b23537 09773ebc2423, |
|
|
server< /p> |
10.7.73.121:64782 |
|
|
serverstartcode |
1351986939360 |
Specific meaning:
ID]),
- The first delimiter in Rowkey is the name of the table;
- The second delimiter is the first rowkey in region, and here are two things to note, 1. If this place is empty, it indicates that this is the first area of the table. And if the Startkey and EndKey in a region are empty, it indicates that the table has only one region. 2. In the Mata table, the Startkey region in front of the Startkey is in front of the region. (keys in HBase are sorted by field order)
- Region ID is the ID of region, which is usually the timestamp when region is created
- RegionInfo is the serialized value of the Hregioninfo.
- Server refers to the address and port
- Serverstartcode is the timestamp at the beginning of the service.
Find the region of key corresponding to the meta table
When a key needs to be put, the meta table is scanned, the corresponding region is found, and then the insert operation is performed.
For example: There is a table with three region, each region of the Startkey is empty, bar,foo, such as:
1 table,13517008118582 table,bar,13517008198763 table,foo, 1351700829874
If we need to insert key ' Baz ', we can find the corresponding rowkey in the meta table (table,bar,1351700819876).
This will be cached on the client after the search, and the next query will be accessed directly to the region based on the cache.
Auto Split
When you continue to add data to a table, the region will eventually split. In this way, hbase can be guaranteed to grow horizontally. A parent region will split two child region.
There are two things we need to do before the child regions goes live:
- Downline Parentregion
- Add information about the childregions to parent info
The first is to update the value of the Parentregion info:regioninfo column in the Meta table, and then add two columns Info:splita (the hregioninfo of the top child, Here the agreement top for Startkey smaller hregininfo,bottom is reversed), and INFO:SPLITB (bottom child's hregioninfo). This operation can ensure that we can track the exactly what the region has done, convenient follow-up operations, and subsequent if the operation is forced to the terminal, there is also a voucher, can be based on these to recover. Finally, the parent region will be cleared by Catalogjanitor.
Update meta table
When you have updated the Parentregion record in the meta table, you need to insert the child region related to the meta table, and the Startkey and Paretn Startkey of the top child region are the same, This time RegionID play his role, if there is no RegionID, when the meta table has top region and parentregion, we will know what to choose, because their startkey are the same. And we use timestamp as the ID of region (if the top region and the timestamp of the parent region are the same, the top RegionID takes timestamp+1). This way we can guarantee that childregion is always behind the parent region.
Another important thing is that bottom child must first be inserted into the meta table and then top child to insert. Otherwise, in the meta table, the key in bottom region cannot find the corresponding region. For example, the meta Rowkey (table,bar,1351700819876) in which Rowkey is divided into two region based on the above example is (table,bar,1351700819810) and (table,belong,1351700819810), if this time first insert top child:
1 table,,13517008118582 table,bar,1351700819876 <----offline! 3 table,bar,1351700819810 <---- topchild4 table,foo,1351700829874
For example this time I need to find key for Bgood, I will eventually find the third row in the top region, but the top region does not contain Bgood. Bgood This key is in the bottom region. If you join bottom first, you will not have this problem, as follows
Table,,1351700811858table,bar,1351700819876 <----offline! Table,belong, 1351700819810 <---- bottom Childtable,foo,1351700829874
Error Recovery
In general, HBase can be a good recovery server error, but sometimes there will be problems, if in the Slipt, regionserver error, or for other reasons caused slipt the entire cycle only part of the execution. At this time, the meta table may be faulted, such as the region with the error on the disk, or the duplicate regions. At this point we can use the HBCK tool to fix it. Use the following command to view more information about HBCK:
/hbase/bin/hbase hbck-h
Reference:
Https://blog.safaribooksonline.com/2012/11/16/tip-2-hbase-meta-layout/hbase:meta table
Http://hbase.apache.org/book/arch.catalog.html Official Document Meta table
Structure of the HBase meta table