Hbase
Hbase architecture follows the master server architecture. Region servers serve data for reads and writes. When accessing data, clients communicate with hbase region servers directly and Hbase Master handles region assignment, creation and deletion of tables. Hbase uses Hadoop distributed file system and stores all data on top of the HDFS files. Also Hbase uses Zookeeper to maintain the distributed tasks and track the health of the cluster.
The Hadoop Data Nodes stores the data of the Region servers and region servers are collocated with the HDFS data nodes while preserving the data locality.
Hbase tables are divided horizontally by row key range into Regions and a region contains all the rows in the table between the region’s start and end key
Hbase maintains a special catalog table called as META table which tracks the location of the regions in the cluster of row keys and zookeeper stores the location of the META table.
There is a special HBase Catalog table called the META table, which holds the location of the regions in the cluster. ZooKeeper stores the location of the META table.
To view more details on Hbase architecture refer this.
Hbase Hotspotting
Records in Hbase are stored as sorted list of row keys according to the lexicographically order and allows fast access to an individual record by its key or fast fetching of a range of data between a given start and end row keys.
Simply we can refer row keys with natural sequence at data insertion time, but this can cause regionserver hotspotting.
By its default behavior Hbase stores rows with similar keys to the same region. When records with sequential keys are being written to HBase, all this data writes hit one Region. So large amount of client traffic is directed at one node, or only a few nodes, of a cluster.
But this would not be a problem if a Region was served by multiple Region Servers since the writes gits multiple region server even they serves as a single region.
But the common situation is that each Region lives on just one Region Server and each Region has a predefined maximal size. If a Region reaches that maximal size it is split in two smaller Regions becoming a hotspot victim because one of these new Regions takes all new records (Limits the write throughput to the capacity of a single server instead of making use of multiple/all nodes in the HBase cluster).
Solutions for Hbase Hotspotting
Add a salt to the Row Key
Include a random data to the start of a row key (randomly assigned prefix) to cause it to sort differently than it otherwise would. Salting prefixes can be used correspond to the number of regions we want spread the data.
Use of Hashed Row Key
This approach is suitable when application reads query a record at a time and records will spread between multiple regions / region servers according to the hash function. Using a deterministic hash allows the client to reconstruct the complete row key and use a Get operation to retrieve that row as normal.
Reverse the row key 
Reverse a fixed-width or numeric row key so that the part that changes the most often (the least significant digit) is first. This effectively randomizes row keys, but sacrifices row ordering properties.
Bucketing approach
row_key = (++index % BUCKETS_NUMBER) + original_key
Where,
index - The numeric (or any sequential) part of the specific record.
BUCKETS_NUMBER - the number of “buckets” we want our new row keys to be spread across.
original_key - The original key of the record we want to write.
New row keys of bucketed records will no longer be in one sequence, but records in each bucket will preserve their original sequence. Since data is placed in multiple buckets during writes, we have to read from all of those buckets when doing scans based on “original” start and stop keys and merge data so that it preserves the “sorted” attribute. Scan per bucket can be parallelized and so the performance won’t be degraded.
No comments:
Post a Comment