HBase Introduction (3)---frame structure and process

HBase relies on Hadoop's HDFs as the storage base, so the structure is similar to the master-slave mode of Hadoop, and HBase master server manages all hregion servers, but HBase master The server itself does not store any data in HBase. The HBase logical table is defined as a region stored on a hregion server, and the correspondence between Hregion server and region is a one-to-many relationship. Each hregion is physically divided into three parts: Hmemcache, Hlog, Hstore, respectively, representing the cache, log, and persistence layer. Take a look at the role of these three parts with an update process:

As can be seen by the process, the commit update operation will be written to two parts of the entity, Hmemcache and Hlog, Hmemcache is to improve the efficiency of the cache in memory, to ensure that some of the most recently manipulated data can be quickly read and modified, Hlog is a transaction log that synchronizes Hmemcache and Hstore, and the data in Hmemcache is persisted to hstore when the flush cache command is launched periodically by the Hregion server. At the same time, the data in the Hmemecache is emptied, it is a relatively simple strategy to do the data cache and synchronization, more complex can actually refer to the Java garbage collection mechanism to do.

When reading the region information, first read the contents of the Hmemcache, if not fetched to read the data in the Hstore.

Several details:

1. Because each flash Cache, will produce a hstore file, in the Hstore will be more and more files stored in the performance will have a certain impact, so when the set number of files to the threshold value of the merge these files into a large file.

2. The settings for the cache size and the time interval setting for flush require consideration of memory consumption and performance impact.

3. Hregion server restarts the data in the Hlog without being flush to hstore in the Hmemcache again, so the hmemcache too large has a direct impact on the speed of the boot.

4. The Hstore file stores data in the B-tree algorithm, so it also supports fast location acquisition of column and family data operations mentioned earlier.

5. Hregion can be either merge or split, depending on the size of the hregion. However, when doing these operations, the hregion will be locked and not available.

6. Hbase Master server obtains information about Hregion server and region by Meta-info table, and one of the top region of the meta is the virtual one called Root region, through root Region can be found in each of the following actual region.

7. The client obtains the region server that is located through HBase master server, and then interacts directly with area server, and for region server does not communicate with each other, only the HBase master Server interaction, which is monitored and managed by master server.

Http://wiki.apache.org/hadoop/Hbase/HbaseArchitectureArchitecture and implementation

There is three major components of the HBase architecture:

1. The H! Basemaster (analogous to the Bigtable master server)

2. The H! Regionserver (analogous to the Bigtable tablet server)

3. The HBase client, defined by org.apache.hadoop.hbase.client.HTable

Each would be discussed in the following sections.

Hbasemaster

The H! Basemaster is responsible for assigning regions to H! Regionservers. The first region of assigned is the ROOT of the which locates all the META regions to be assigned. Each META -Region maps a number of user regions which comprise the multiple tables that a particular HBase Instanc E serves. Once all the META regions has been assigned, the master would then assign user regions to the H! Regionservers, attempting to balance the number of regions served by each H! Regionserver.

It also holds a pointer to the H! Regionserver that's hosting the ROOT region.

The H! Basemaster also monitors the health of each H! Regionserver, and if it detects a H! Regionserver is no longer reachable, it'll split the H! Regionserver's Write-ahead log So, there is now a write-ahead log for each region, the H! Regionserver was serving. After it had accomplished this, it would reassign the regions that were being served by the unreachable H! Regionserver.

In addition, the H! Basemaster is also responsible for handling table administrative functions such as on/off-lining of tables, changes to the Table schema (Adding and removing column families), etc.

Unlike Bigtable, currently, when the H! Basemaster dies, the cluster would shut down. In Bigtable, a tabletserver can still serve Tablets after it connection to the Master have died. We tie them together, because we do not currently use a external lock-management system like Bigtable. The Bigtable Master allocates tablets and a lock manager (Chubby) guarantees atomic access by Tabletservers to TA Blets. HBase uses just a single central point for all H! Regionservers to Access:the H! Basemaster.

The META Table

The META table stores information about every user region in HBase which includes a H! RegionInfo object containing information such as the start and end row keys, whether the region is on-line or off-line, ET C. And the address of the H! Regionserver that's currently serving the region. The META table can grow as the number of the user regions grows.

The ROOT Table

The ROOT table is confined to a, and maps all, the regions in the META table. Like the META table, it contains a H! RegionInfo object for each META region and the location of the H! Regionserver that's serving that META region.

Each row in the ROOT and META tables are approximately 1KB in size. At the default region size of 256MB, this means then the ROOT region can map 2.6 x META-regions, which in turn map a T Otal 6.9 x 1010 User regions, meaning that approximately 1.8 x 1019 ($) bytes of user data.

Hregionserver

The H! Regionserver is responsible for handling client read and write requests. It communicates with the H! Basemaster to get a list of regions to serve and to tell the master, it is alive. Region assignments and other instructions from the master "piggy back" on the heart beat messages.

Write Requests

When a write request was received, it was first written to a write-ahead log called a HLog. All write requests in every region, the region server is serving be written to the same log. Once the request has been written to the HLOG, it's stored in an in-memory cache called the Memcache. There is one Memcache for each hstore.

Read Requests

Reads was handled by first checking the Memcache and if the requested data was not found, the mapfiles was searched for Res Ults.

Cache Flushes

When the Memcache reaches a configurable size, it's flushed to disk, creating a new MapFile and a marker are written to th e HLog, so if it is replayed, log entries before the last flush can be skipped. A flush may also is triggered to relieve memory pressure in the region server.

Cache flushes happen concurrently with the region server processing read and write requests. Just before the new MapFile is moved in place, reads and writes are suspended until the MapFile have been added to the LI St of Active Mapfiles for the Hstore.

Compactions

When the number of mapfiles exceeds a configurable threshold, a minor compaction are performed which consolidates the most Recently written mapfiles. A major compaction is performed periodically which consolidates all the mapfiles to a single MapFile. The reason for don't always performing a major compaction are the oldest MapFile can be quite large and reading and Merg ing it with the latest mapfiles, which is much smaller, can be very time consuming due to the amount of I/O involved in R Eading merging and writing the contents of the largest MapFile.

Compactions happen concurrently with the region server processing read and write requests. Just before the new MapFile is moved in place, reads and writes are suspended until the MapFile have been added to the LI St of Active Mapfiles for the Hstore and the Mapfiles which were merged to create the new MapFile has been removed.

Region splits

When the aggregate size of the mapfiles-a hstore reaches a configurable size (currently 256MB), a region split is req Uested. Region splits divide the row range of the parent, in half and happen very quickly because, the child regions read fro M the parent ' s MapFile.

The parent region was taken off-line, the region server records the new child regions in the META region and the master are Informed that a split have taken place so that it can assign the children to region servers. Should the split message be lost, the master would discover the split has occurred since it periodically scans the META Reg Ions for unassigned regions.

Once The parent is closed, read and write requests for the region is suspended. The client has a mechanism for detecting a region split and would wait and retry the request when the new children is on-l Ine.

When a compaction was triggered in a child, the data from the parent was copied to the child. When both children had performed a compaction, the parent region was garbage collected.

HBase Client

The HBase client is responsible for finding H! Regionservers that is serving the particular row range of interest. On instantiation, the HBase client communicates with the H! Basemaster to find the location of the ROOT region. The only communication between the client and the master.

Once the root region is located, the client contacts this region server and scans the root region to find the META region That would contain the location of the contains the desired row range. It then contacts, the region server, that's serving, that meta-region and scans, that meta-region to determine, the location O f the user region.

After locating the user region, the client contacts the region server serving and issues the read or write req Uest.

This information are cached in the client so, subsequent requests need not go through this process.

Should a region is reassigned either by the master for load balancing or because a region server have died, the client would Rescan the META table to determine the new location of the user region. If the Meta region has been reassigned, the client would rescan the ROOT region to determine the new location of the meta R Egion. If the ROOT region has been reassigned, the client would contact the master to determine the new root region location and W Ill locate the user region by repeating the original process described above.

HBase Introduction (3)---frame structure and process