Shulou(Shulou.com)06/02 Report--

This article mainly explains the "HBase data reading process analysis", the content of the article is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in depth, together to study and learn "HBase data reading process analysis" bar!

Client-Server interaction logic

OPS has been developing HBase for a long time, and business students often ask why the address information of RegionServer is not configured in the client configuration file. Here is a simple explanation for this question. The interaction phase between client and HBase system mainly includes the following steps:

The client first connects to the zookeeper according to the zookeeper address in the configuration file and reads / / meta-region-server node information, which stores information such as the RegionServer address where the HBase metadata (hbase:meta) table is located and the access port. Users can view the node information through the zookeeper command (get / / meta-region-server).

Based on the access information of the RegionServer where the hbase:meta resides, the client loads the metadata table locally and caches it. Then determine the RegionServer information where the rowkey is to be retrieved in the table.

Based on the access information of the RegionServer where the data is located, the client sends a real data read request to the RegionServer. The server needs to carry out complex processing after receiving the request, and the specific processing flow will be the focus of this project.

Through the above interaction analysis of the client and the HBase system, we can basically make two points clear:

The client only needs to configure the access address and root directory of the zookeeper to make normal read and write requests. There is no need to configure the cluster's RegionServer address list.

The client caches the hbase:meta metadata table locally, so the first two steps in the above steps only occur when the client makes * requests, and then all requests load metadata directly from the cache. If some changes in the cluster cause hbase: meta metadata to change, an exception will occur when the client requests according to the local metadata table. At this time, the client needs to reload a * metadata table locally.

After receiving the get/scan request from the client, RegionServer has done two things successively: building a scanner system (actually doing some preparatory work before scan), and retrieving it line by line based on this system. To take an inappropriate but easy-to-understand example, scan data, like developers building houses, is divided into two steps: building a construction team system that defines the responsibilities of each worker; and building one floor at a time.

Build scanner system-set up construction team

The core of scanner system lies in three layers: scanner:RegionScanner, StoreScanner and StoreFileScanner. The three are hierarchical relationships. A RegionScanner is composed of multiple StoreScanner, and a table is composed of multiple column families, so how many StoreScanner are responsible for scanning the data of the column family. A StoreScanner is also composed of multiple StoreFileScanner. The data of each Store consists of the MemStore in memory and the StoreFile file on disk. Correspondingly, the StoreScanner object employs a MemStoreScanner and N StoreFileScanner to actually read the data, and each StoreFile file corresponds to a StoreFileScanner. Note: StoreFileScanner and MemstoreScanner are the final executors of the entire scan.

Corresponding to the building project, a building is usually composed of several unit buildings (each unit building corresponds to a Store), and each unit building will hire a StoreScanner to be responsible for the construction of the unit building. The supervisor generally does not do specific things, he is responsible for recruiting a lot of workers (StoreFileScanner), these workers are the main body of the building. The following figure is the entire build flowchart:

RegionScanner builds StoreScanner based on column families, and builds as many StoreScanner as there are column families, which is used to retrieve the data of the column families.

Build StoreFileScanner: each StoreScanner constructs a StoreFileScanner for each HFile in the current Store to actually perform the retrieval of the corresponding files. At the same time, a MemstoreScanner is constructed for the corresponding Memstore to perform data retrieval of the Memstore in the Store. This step corresponds to various types of craftsmen needed by supervisors to recruit buildings in the job market.

1.2 filter out StoreFileScanner: filter StoreFileScanner and MemstoreScanner according to Time Range and RowKey Range, and eliminate the Scanner that certainly does not exist in the search results. In the image above, StoreFile3 is eliminated because it checks that RowKeyRange does not have a Rowkey to be retrieved. This step aims at the specific building plan, cutting off some unneeded craftsmen, for example, if the building does not need floor heating installation, the corresponding craftsmen can be removed.

1.3 Seek rowkey: all StoreFileScanner begin preparations and locate the starting Row that meets the criteria in the responsible HFile. Craftsmen also began to prepare their own construction tools, build materials, find their own place of work, and wait for a death. Just as preparation for all important projects is core, the Seek process (omitting Lazy Seek optimization here) is a core step, which consists of the following three steps:

Locate Block Offset: read the index tree structure of the HFile in Blockcache, and retrieve the Block Offset and Block Size of the corresponding RowKey according to the index tree

Load Block: first look for Data Block in BlockCache according to BlockOffset, and then load it in HFile if it is not in cache

Seek Key: locate the specific RowKey within the Data Block by binary search

For details of the overall process, see "HBase principles-exploring HFile Index Mechanism". The HFile index structure and how to locate specific Block and RowKey through the index structure are described in detail.

1.4 StoreFileScanner merge to build a minimum heap: merge all the StoreFileScanner and MemstoreScanner in the Store to form a heap (minimum heap), the so-called heap is a priority queue, the elements in the queue are all scanner, and the sorting rules are sorted from small to large according to the keyvalue size from scanner seek to. Here we need to focus on three questions: first, why do these Scanner need to be sorted from small to big? secondly, what kind of structure keyvalue is, and how to determine who is big and who is small in keyvalue:

Why do these Scanner need to be sorted from small to big?

The most direct explanation is that the results of scan need to be output to users from small to large. Of course, this is not comprehensive. The most reasonable explanation is that only sorting from small to large can make scan efficient. To take a simple example, HBase supports multiple versions of data. If you only want to get the * * version, you only need to sort the data from * to the oldest, and then return the first element of the queue. Then, if you don't sort, you can only iterate through all the elements to see if the user query criteria are met. That's what queuing is all about.

Craftsmen also need to sort, first to do the front of the floor, followed by walls, and * * to make doors and windows. The interior of the wall also needs to be re-sorted, the front of the inner wall and the back of the outer wall, so that if the designer temporarily decides not to do the outer wall, he can skip the work of the outer wall directly. Obviously, if it is not sorted, there is no way to make a temporary decision, because this part of the work may already be done.

What is the structure of KeyValue in HBase?

KeyValue in HBase is not a simple KV data pair, but a structure with complex elements, in which Key is composed of RowKey,ColumnFamily,Qualifier, TimeStamp,KeyType and other parts, and Value is a simple binary data. The element KeyType in Key indicates the type of the KeyValue, with four values of Put/Delete/Delete Column/Delete Family. KeyValue can be represented as shown in the following figure:

After understanding the logical structure of KeyValue, we might as well further consider why HBase developers designed it in this way from a theoretical point of view. Let's start with the data operations supported by HBase. HBase supports four main data operations, namely Get/Scan/Put/Delete, where Get and Scan represent data query, and Put operation represents data insertion or update (insert operation if Put RowKey does not exist, otherwise update operation). It is particularly important to note that the update operation in HBase does not directly overwrite and modify the original data, but generate new data. The new data and the original data have different versions (timestamps) The Delete operation performs data deletion, which is the same as the data update operation. Data deletion performed by HBase will not immediately delete the data from the database, but will only generate a deleted record, which will be deleted uniformly when the system performs file merging.

The update and delete operation in HBase does not directly manipulate the original data, but generates a new record, so the question is, how to know whether a record is an insert operation, an update operation or a delete operation? This is the opportunity for KeyType and Timestamp to use their talents. The four KeyType values mentioned above are Put/Delete/Delete Column/Delete Family. If KeyType is Put, the record is an insert or update operation, and no matter it is insert or update, you can use the version number (Timestamp) to select the record; if KeyType is Delete, the record is a whole row deletion operation; the corresponding KeyType is Delete Column and Delete Family indicates the deletion of a row, a column and a column family operation, respectively

How do I compare the sizes of different KeyValue?

As mentioned above, Key in KeyValue consists of five parts, such as RowKey,ColumnFamily,Qualifier and TimeStamp,KeyType. HBase sets the Key size to compare the smaller the RowKey,RowKey is, the smaller the Key is; if the RowKey is the same, the smaller the CF,CF is, the smaller the Key is; if the CF is the same, the smaller the Qualifier,Qualifier is, the smaller the Key is; if the Qualifier is the same, the larger the Timestamp,Timestamp means the newer the time, the smaller the corresponding Key. If the Timestamp is still the same, you can see that the corresponding Key of KeyType,KeyType is getting larger and larger in the order of DeleteFamily-> DeleteColumn-> Delete-> Put.

2. StoreScanner merge to build the smallest heap: the above discussion is about how a supervisor builds his own team of craftsmen and how craftsmen do preparation and sorting work. In fact, supervisors also need to be sorted, such as the front of the supervisor of the first unit and the supervisor of the second unit. Like StoreScanner, the small StoreScanner row is in front of the row and the big StoreScanner row is behind the row.

Scan query-Building layer upon layer

The Scanner system is built to better execute scan queries, just as a team of craftsmen is set up to build houses. Scan queries are always queried in one row, first check all the data in the * * row, and then all the data in the second row, but there is no essential difference in the query flow of each row. The same is true of building a house, whether it is to build 8 or 18 floors, you need to build one layer at a time, and there is no difference in the way you cover each floor. So in fact, we only need to pay attention to how one row of data is queried.

For the query of a row of data, it can be divided into queries of multiple column families, such as the one-row data query of RowKey=row1, which first queries the data set of the row in column family 1, and then queries the data set of the row in column family 2. The same is to build a house, first build the first floor of the first unit, and then change the first floor of the second unit, after the completion of the first floor, and then begin to build the second floor. So we only need to pay attention to how the data of a certain row and a column family is queried.

Remember that the end result of the construction of the Scanner system is a heap (minimum heap) made up of StoreFileScanner and MemstoreScanner? here it comes in handy. The following figure is a logical view of a table with two column families, cf1 and cf2 (we only focus on cf1), cf1 has only one column name, and there are five rows of data in the table, where each cell has basically multiple versions. If the data of cf1 is actually stored in three regions, there are R2 and R4 * * data in memstore, and the earliest data is in hfile1. Now you need to query the data of RowKey=r2. According to the above theory, the corresponding Scanner direction is shown in the figure:

The heap composed of the three Scanner is Scanner arranged from small to large. When querying, first pop the top element of heap, namely MemstoreScanner, and get the data of keyvalue = r2:cf1:name:v3:name23. After getting the keyvalue, you need to make the following decision:

Check whether the KeyType of the KeyValue is Deleted/DeletedCol, etc., if so, directly ignore all other versions of the column and skip to the following (column family)

Check whether the Timestamp of the KeyValue is in the Timestamp Range range set by the user, and if not, ignore

Check whether the KeyValue meets the various filter filters set by the user. If not, ignore

Check whether the KeyValue satisfies the number of versions set in the user query. For example, if you only query the * * version, ignore other versions of the cell; anyway, if you query all versions, you also need to query other versions of the cell.

Now suppose the user queries all versions and the keyvalue check passes, and the current heap top element needs to execute the next method to retrieve the next value and reorganize the minimum heap. That is, the MemstoreScanner in the figure will point to R4. After reorganizing the minimum heap, the minimum heap will become, the top element of the heap will become StoreFileScanner2, get keyvalue=r2:cf1:name:v2:name22, make a series of decisions, then next, and then reorganize the minimum heap.

Thank you for reading, the above is the content of "HBase data reading process parsing". After the study of this article, I believe you have a deeper understanding of the problem of HBase data reading process parsing, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.