深入HBase的组件细节

jieforest

A scale out-based system enables us to have a redundant and high availability system. It is cost effective, which means that there is no need to invest in high-end machines, no application migration overhead, and servers can be located in many locations. It is suitable for massive parallel computing, where a number of machines take up the workload evenly. The following figure shows the HBase scaling method:

jieforest

In HBase, we can add new RegionServers on the fly; for this, new DataNodes are added, the RegionServer daemon is started on these DataNodes, and scalability is obtained. In short, we first add a number to the cluster, and then start the DataNode and RegionServer daemons on the newly added node.

Let's talk about HBase communication between daemons (nodes). The different daemons and the HBase nodes communicate with each other using Remote Procedure Call (RPC), which enables the HBase components to make calls to in-built functions. It also enables each component to behave towards these calls as if they were local. This in turn enables the procedures or subroutines to be executed to a different address space, such as another computer system. This kind of intercommunication prevents the rewriting of the server architecture code.

jieforest

The following figure shows the RPC flow:

jieforest

In HBase, HBaseRPC is the class that facilitates HBase to use RPC among the components. It is based on the Java dynamic proxy pattern. It uses an invoker class that implements InvocationHandler to intercept client-side method calls, and then it marshalls the method name and argument through HBaseClient. The communication between client and server using RPC works as follows:

1. The client contacts ZooKeeper to find who the active HMaster is and what the location of the root RegionServer is.

2. Then, the client communicates RegionServer using HRegionInterface to read/write the table.

3. Client applications talk to HMaster using HMasterInterface in order to dynamically create a table, add a column family, and for other operations.

4. Then, HMaster communicates to RegionServers using HRegionInterface to open, close, move, split, or flush the region.

5. Active HMaster data and the root RegionServer location are cached into ZooKeepers by HMaster.

6. RegionServer then reads the data from ZooKeeper to get information about log-splitting tasks, which is updated to fetch a task report status.

7. RegionServer then communicates with HMaster using HMasterRegionInterface to convey information such as the loading of RegionServer, errors with RegionServer, and the start up process of RegionServers.

jieforest

Sometimes, RegionServer also communicates with the root region or the meta region, with the help of HRegionInterface, to check the current status of a region or to create a new daughter region while region splitting.

8. This communication is repeated with a tick time interval or a threshold time interval to keep everything updated.

jieforest

Reading and writing cycle

Now, let's see how the read-and-write operation takes place in HBase diagrammatically:

jieforest

Let's discuss and understand how the read-and-write operation takes place in and from HBase tables. In HBase, the client does not write data to HFile directly; it is first written to WAL and then to HBase MemStore, which is shared by an HStore in the main memory and then flushed to HFile later. Refer to the following figure:

jieforest

Write-Ahead Logs

Write-Ahead Logs facilitate the data reliability and reside on HDFS; each RegionServer hosts a single WAL. In the case of a RegionServer crash where MemStore is not flushed, WAL is used to restore the data to a new RegionServer. So, only once data is written successfully to WAL and MemStore, the write operation is said to be successful.
MemStore

MemStore acts as an in-memory write buffer with a default size of 64 MB. Once data in MemStore reaches the threshold (which is by default 40 percent of the heap size or 64 MB), it is flushed to a new HFile on HDFS for persistence. The 64 MB HFile is not related to block size here; Hadoop internally manages block allocation and storage. HBase does not play a role in the underlying mechanism of block replication or dividing HFiles into blocks. Each column family might have many HFiles, but the HFile will only belong to a specific column family.

jieforest

Now, let's take a look at the process flow of reading from HBase. The reading process starts when the client initiates a read request; the client gets the RegionServer and region information, and it communicates this to the acquired RegionServer. At the acquired RegionServer, the client first tries to read from MemStore; if hit, the read activity completes; if it's a miss, it navigates to block cache. Finally, it reaches out to HFile to read the required row of data. If there is a missing record, the corresponding HFile is loaded into the memory that contains the required row of data. So, MemStore and block cache provide real-time access to data for performance purposes, and HFile provides persistent, on-demand data.

Block cache follows the least recently used (LRU) algorithm. Every RegionServer has a single block cache that keeps the most frequently accessed data from HFile in the main memory, which results in reducing the disk seek for data access time.

jieforest

HBase housekeeping

As data is being added to HBase, it writes an immutable file to store. Each store is made up of column families, and regions consist of these row-key ordered files as it's immutable. So, there will be more files rather than one on the fly. Due to many files, the I/O will be slower, and hence lag in reading and writing, resulting in slower operation. To overcome these types of problems, HBase uses the compaction methodology; let's look into it now. Refer to the following figure for a better understanding: