HBase查找一条数据的过程

HBase中的Client如何路由到正确的RegionServer

在HBase中,大部分的操作都是在RegionServer完成的,Client端想要插入,删除,查询数据都需要先找到相应的
RegionServer。什么叫相应的RegionServer?就是管理你要操作的那个Region的RegionServer。Client本身并 不知道哪个RegionServer管理哪个Region,那么它是如何找到相应的RegionServer的?本文就是在研究源码的基础上揭秘这个过程。

在前面的文章“HBase存储架构”中我们已经讨论了HBase基本的存储架构。在此基础上我们引入两个特殊的概念:-ROOT-和.META.。这是什么?它们是HBase的两张内置表,从存储结构和操作方法的角度来说,它们和其他HBase的表没有任何区别,你可以认为这就是两张普通的表,对于普通表
的操作对它们都适用。它们与众不同的地方是HBase用它们来存贮一个重要的系统信息——Region的分布情况以及每个Region的详细信息。

好了,既然我们前面说到-ROOT-和.META.可以被看作是两张普通的表,那么它们和其他表一样就应该有自己的表结构。没错,它们有自己的表结构,并且这两张表的表结构是相同的,在分析源码之后我将这个表结构大致的画了出来:

我们来仔细分析一下这个结构,每条Row记录了一个Region的信息。

首先是RowKey,RowKey由三部分组成:TableName, StartKey 和 TimeStamp。RowKey存储的内容我们又称之为Region的Name。哦,还记得吗?我们在前面的文章中提到的,用来存放Region的文件 夹的名字是RegionName的Hash值,因为RegionName可能包含某些非法字符。现在你应该知道为什么RegionName会包含非法字符 了吧,因为StartKey是被允许包含任何值的。将组成RowKey的三个部分用逗号连接就构成了整个RowKey,这里TimeStamp使用十进制
的数字字符串来表示的。这里有一个RowKey的例子:

Table1,RK10000,12345678

然后是表中最主要的Family:info,info里面包含三个Column:regioninfo, server,
serverstartcode。其中regioninfo就是Region的详细信息,包括StartKey, EndKey 以及每个Family的信息等等。server存储的就是管理这个Region的RegionServer的地址。

所以当Region被拆分、合并或者重新分配的时候,都需要来修改这张表的内容。

到目前为止我们已经学习了必须的背景知识,下面我们要正式开始介绍Client端寻找RegionServer的整个过程。我打算用一个假想的例子来学习这个过程,因此我先构建了假想的-ROOT-表和.META.表。

我们先来看.META.表,假设HBase中只有两张用户表:Table1和Table2,Table1非常大,被划分成了很多Region,因此 在.META.表中有很多条Row用来记录这些Region。而Table2很小,只是被划分成了两个Region,因此在.META.中只有两条Row 用来记录。这个表的内容看上去是这个样子的:

.META.

现在假设我们要从Table2里面插寻一条RowKey是RK10000的数据。那么我们应该遵循以下步骤:

1. 从.META.表里面查询哪个Region包含这条数据。

2. 获取管理这个Region的RegionServer地址。

3. 连接这个RegionServer, 查到这条数据。

好,我们先来第一步。问题是.META.也是一张普通的表,我们需要先知道哪个RegionServer管理了.META.表,怎么办?有一个方法,我们把管 理.META.表的RegionServer的地址放到ZooKeeper上面不久行了,这样大家都知道了谁在管理.META.。

貌似问题解决了,但对于这个例子我们遇到了一个新问题。因为Table1实在太大了,它的Region实在太多了,.META.为了存储这些Region信 息,花费了大量的空间,自己也需要划分成多个Region。这就意味着可能有多个RegionServer在管理.META.。怎么办?在 ZooKeeper里面存储所有管理.META.的RegionServer地址让Client自己去遍历?HBase并不是这么做的。

HBase的做法是用另外一个表来记录.META.的Region信息,就和.META.记录用户表的Region信息一模一样。这个表就是-ROOT-表。这也解释了为什么-ROOT-和.META.拥有相同的表结构,因为他们的原理是一模一样的。

假设.META.表被分成了两个Region,那么-ROOT-的内容看上去大概是这个样子的:

-ROOT-

这么一来Client端就需要先去访问-ROOT-表。所以需要知道管理-ROOT-表的RegionServer的地址。这个地址被存在ZooKeeper中。默认的路径是:

/hbase/root-region-server

等等,如果-ROOT-表太大了,要被分成多个Region怎么办?嘿嘿,HBase认为-ROOT-表不会大到那个程度,因此-ROOT-只会有一个Region,这个Region的信息也是被存在HBase内部的。

现在让我们从头来过,我们要查询Table2中RowKey是RK10000的数据。整个路由过程的主要代码在

org.apache.hadoop.hbase.client.HConnectionManager.TableServers中:
private HRegionLocation locateRegion(final byte [] tableName,

final byte [] row, boolean useCache)
throws IOException{

if (tableName == null || tableName.length == 0) {

throw new IllegalArgumentException(

“table name cannot be null or zero length”);

}

if (Bytes.equals(tableName, ROOT_TABLE_NAME)) {

synchronized (rootRegionLock) {

// This block guards against two threads trying to find the root

// region at the same time. One will go do the find while the

// second waits. The second thread will not do find.

if (!useCache || rootRegionLocation == null) {

this.rootRegionLocation = locateRootRegion();

}

return this.rootRegionLocation;

}

} else if (Bytes.equals(tableName, META_TABLE_NAME)) {

return locateRegionInMeta(ROOT_TABLE_NAME, tableName, row, useCache,
metaRegionLock);

} else {

// Region not in the cache – have to go to the meta. RS

return locateRegionInMeta(META_TABLE_NAME, tableName, row, useCache, userRegionLock);

}

}

这是一个递归调用的过程:

获取Table2,RowKey为RK10000的RegionServer

=>

获取.META.,RowKey为Table2,RK10000, 99999999999999的RegionServer

=>

获取-ROOT-,RowKey为.META.,Table2,RK10000,99999999999999,99999999999999的RegionServer

=>

获取-ROOT-的RegionServer

=>

从ZooKeeper得到-ROOT-的RegionServer

=>

从-ROOT-表中查到RowKey最接近(小于)

.META.,Table2,RK10000,99999999999999,99999999999999的一条Row,并得到.META.的RegionServer

=>

从.META.表中查到RowKey最接近(小于)Table2,RK10000, 99999999999999的一条Row,并得到Table2的RegionServer

=>

从Table2中查到RK10000的Row

到此为止Client完成了路由RegionServer的整个过程,在整个过程中使用了添加“99999999999999”后缀并查找最接近(小于)RowKey的方法。对于这个方法大家可以仔细揣摩一下,并不是很难理解。

最后要提醒大家注意两件事情:

在整个路由过程中并没有涉及到MasterServer,也就是说HBase日常的数据操作并不需要MasterServer,不会造成MasterServer的负担。

Client端并不会每次数据操作都做这整个路由过程,很多数据都会被Cache起来。至于如何Cache,则不在本文的讨论范围之内。

引用:http://www.shangxueba.com/jingyan/tc454-1136.html

时间: 11-26

HBase查找一条数据的过程的相关文章

SQL查找该条数据,有多少人评论,同一个人评论多次算为一次评论,需要进行分组

数据表结构如下: id  user_name  score 1      aa       20 2      cc       30 3      dd       30 4      aa       50 5      dd       49 6      xx       40 7      aa       50 执行sql语句: $sql = "SELECT user_name,count(*) as num FROM cmessage where csoup_id='".

一条数据的HBase之旅,简明HBase入门教程-Write全流程

如果将上篇内容理解为一个冗长的"铺垫",那么,从本文开始,剧情才开始正式展开.本文基于提供的样例数据,介绍了写数据的接口,RowKey定义,数据在客户端的组装,数据路由,打包分发,以及RegionServer侧将数据写入到Region中的全部流程. NoSQL漫谈 本文整体思路 前文内容回顾 示例数据 HBase可选接口介绍 表服务接口介绍 介绍几种写数据的模式 如何构建Put对象(包含RowKey定义以及列定义) 数据路由 Client侧的分组打包 Client发RPC请求到Regi

hbase 基本的JavaApi 数据操作及过滤

本文主要是hbase的表操作.数据操作.数据查询过滤等,如果对JDBC或ADO有了解,容易理解HBASE API. hbase版本是2.0. 1.为了方便先贴helper的部分代码(文末git上有完整的测试代码),主要是为了复用Connection. public class HBaseHelper implements Closeable { private Configuration configuration = null; private Connection connection =

8.HCNA_HNTD——数据转发过程

TCP/IP协议族和底层协议配合,保证了数据能够实现端到端的传输.数据传输过程是一个非常复杂的过程,例如数据在转发的过程中会进行一系列的封装和解封装.对于网络工程师来说,只有深入地理解了数据在各种不同设备上的转发过程,才能够对网络进行正确的分析和检测. 学习目标: 1. 掌握数据封装和解封装的过程 2. 处理数据转发过程中的基本故障 数据可以在同一网络内或者不同网络间传输,数据转发过程也分为本地转发和远程转发,但两者的数据转发原理是基本一样的,都是遵循TCP/IP协议簇. 本示例中,主机A需要访

SqlServer 创建聚集索引与非聚集索引处理千万条数据的优化,以及之间的区别

在以下的文章中,我将以"办公自动化"系统为例,探讨如何在有着1000万条数据的MS SQL SERVER数据库中实现快速的数据提取和数据分页.以下代码说明了我们实例中数据库的"红头文件"一表的部分数据结构: CREATE TABLE [dbo].[TGongwen] ( --TGongwen是红头文件表名 [Gid] [int] IDENTITY (1, 1) NOT NULL , --本表的id号,也是主键 [title] [varchar] (80) COLLA

mapreduce 只使用Mapper往多个hbase表中写数据

只使用Mapper不使用reduce会大大减少mapreduce程序的运行时间. 有时候程序会往多张hbase表写数据. 所以有如题的需求. 下面给出的代码,不是可以运行的代码,只是展示driver中需要进行的必要项设置,mapper类需要实现的接口,map函数需要的参数以及函数内部的处理方式. 实现过程比较曲折,只贴代码: class Qos2HbaseDriver extends Configured implements Tool { private static Logger logge

HBase存储剖析与数据迁移

1.概述 HBase的存储结构和关系型数据库不一样,HBase面向半结构化数据进行存储.所以,对于结构化的SQL语言查询,HBase自身并没有接口支持.在大数据应用中,虽然也有SQL查询引擎可以查询HBase,比如Phoenix.Drill这类.但是阅读这类SQL查询引擎的底层实现,依然是调用了HBase的Java API来实现查询,写入等操作.这类查询引擎在业务层创建Schema来映射HBase表结构,然后通过解析SQL语法数,最后底层在调用HBase的Java API实现. 本篇内容,笔者并

给你100万条数据的一张表,你将如何查询优化?

1.两种查询引擎查询速度(myIsam 引擎 ) InnoDB 中不保存表的具体行数,也就是说,执行select count(*) from table时,InnoDB要扫描一遍整个表来计算有多少行. MyISAM只要简单的读出保存好的行数即可. 注意的是,当count(*)语句包含 where条件时,两种表的操作有些不同,InnoDB类型的表用count(*)或者count(主键),加上where col 条件.其中col列是表的主键之外的其他具有唯一约束索引的列.这样查询时速度会很快.就是可

并发拉取HBase大量指定列数据时卡住的问题排查

最近遇到一例,并发拉取HBase大量指定列数据时,导致应用不响应的情形.记录一下. 背景 退款导出中,为了获取商品规格编码,需要从HBase表 T 里拉取对应的数据. T 对商品数据的存储采用了 表名:字段名:id 的列存储方式.由于这个表很大,且为详情公用,因此不方便使用 scan 的方式,担心带来集群的不稳定,进而影响详情和导出的整体稳定性. 要用 multiGet 的方式来获取多个订单的这个列的数据. 就必须动态生成相应的列,然后在 HBase 获取数据的时候指定列集合. 现有记录集合 L