Hbase meta表介绍

HBase meta表介绍

本文转载自 https://www.jianshu.com/p/ea7e03cfbfe0

1.hbase0.98之后，hbase就废弃了ROOT**表，仅保留meta表

2.meta表不允许split

在网上较多的文章都会介绍hbase的两个关键表ROOT表与meta表。

其实在hbase0.98之后，hbase就废弃了ROOT表，仅保留meta表（还有namespace表，该表只与hbase命名空间有关，这里不做介绍），并且该表不允许split。

meta split (×)

在0.98后，meta被禁止进行split操作。要知道meta表的一条记录包含了一个region的位置、起始key，创建时间等信息。那万一region数量过大怎么办？查看了公司集群一共1091个region，meta表的大小如图所示：

假定集群有十万个region，meta表也就400多M。在生产环境下，hbase.hregion.max.filesize配置为10G，如果按照这个大小来看，meta可支持的region的数据是一个很可观的数量。

这是我的

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kKDSxO5p-1571747122876)(C:\Users\HP\Desktop\hadoop课件\images\Hbase meta表介绍\1571742636821.png)]

meta位置

meta表location info以非临时znode的方式注册到zk上，如下图，可知meta region位置为hadoop02机器。

meta rowkey

meta表的rowkey信息在HRegionInfo类的createRegionName方法中构建，代码如下：

hbase 1.2.1版本

    public static byte[] createRegionName(TableName tableName, byte[] startKey, byte[] id, int replicaId, boolean newFormat) {
        int len = tableName.getName().length + 2 + id.length + (startKey == null ? 0 : startKey.length);
        if (newFormat) {
            len += 34;
        }

        byte[] replicaIdBytes = null;
        if (replicaId > 0) {
            replicaIdBytes = Bytes.toBytes(String.format("%04X", replicaId));
            len += 1 + replicaIdBytes.length;
        }

        byte[] b = new byte[len];
        int offset = tableName.getName().length;
        System.arraycopy(tableName.getName(), 0, b, 0, offset);
        b[offset++] = 44;
        if (startKey != null && startKey.length > 0) {
            System.arraycopy(startKey, 0, b, offset, startKey.length);
            offset += startKey.length;
        }

        b[offset++] = 44;
        System.arraycopy(id, 0, b, offset, id.length);
        offset += id.length;
        if (replicaIdBytes != null) {
            b[offset++] = 95;
            System.arraycopy(replicaIdBytes, 0, b, offset, replicaIdBytes.length);
            offset += replicaIdBytes.length;
        }

        if (newFormat) {
            String md5Hash = MD5Hash.getMD5AsHex(b, 0, offset);
            byte[] md5HashBytes = Bytes.toBytes(md5Hash);
            if (md5HashBytes.length != 32) {
                LOG.error("MD5-hash length mismatch: Expected=32; Got=" + md5HashBytes.length);
            }

            b[offset++] = 46;
            System.arraycopy(md5HashBytes, 0, b, offset, 32);
            offset += 32;
            b[offset++] = 46;
        }

        return b;
    }

根据上图源码，再通过hbase shell查询mate表信息如下图：hbase(main):002:0> scan ‘hbase:meta’, {LIMIT => 2}

可知，hash值=MD5Hash.getMD5AsHex(byte(表名,region startKey,创建时间))，meta表的rowkey组成为：。如果当前region为table的第一个region时（第一个region无start key）时，region startKey=null。

Hbase有一个叫做Meta的特殊的目录表，用于保存集群中regions的位置信息（region列表）。ZooKeeper存储着Meta表的位置。

Hbase Meta结构如下：

rowKey:([table],[region start key],[region id])

column family：info

column：regioninfo、server、serverstartcode

下面这些话没咋看懂：

1.rowkey中第一个分隔符前存的是表名；

2.第二分隔符前存的是region的第一个rowKey：

  1）如果这个地方为空的话，表明这是table的第一个region。并且如果一个region中startkey和endkey都为空的为，表明这            个table只有一个region；
  2）在meta表中，startkey 靠前的region会排在startkey 靠后的region前面。（Hbase中的keys按照字段顺序排序的）。
3.region id代表region的id，通常基于region创建时的timestamp；

4.regioninfo是HRegionInfo的序列化值；

5.server是指服务器的地址和端口；

6.serverstartcode是指服务开始的timestamp。

根据meta表查找key对应的region，当一个key需要做put操作时，会先扫描meta表，找到对应的region，然后进行插入操作。

eg：当有一个table有三个region，每个region的startkey分别如下：
1 table,,1351700811858
2 table,bar,1351700819876
3 table,foo,1351700829874

如果我们需要插入key ‘baz’时，我们能找到meta表中对应的rowkey为（table，bar，1351700819876）这个查找完，
会缓存到客户端，下次查询的时候根据缓存直接访问对应的region。

mete info

meta表只有一个列簇info，并且包含四列：
1、regioninfo ：当前region的startKey与endKey，name等消息
2、seqnumDuringOpen： 序列号 （这个前边没说出来 实际是有四列的 ）
3、server：region所在服务器及端口
4、serverstartcode：服务开始的时候的timestamp

另一种更容易看懂的形式：

hbase:meta表数据内容格式

        regionname, info:regioninfo             regioninfo的encodeValue值

        regionname, info:seqnumDuringOpen       序列号

        regionname, info:server                 region所在的server名

        regionname, info:serverstartcode        regionserver 启动的timestamp

下面这个更是没看懂：

region split：

当不断向一个table写数据，会触发region spilt，具体过程不再此描述，主要描述meta表的变化：

1）首先是更新meta表中parent region的info：regionfo列的值，
然后增加两列info：spiltA和info：splitB（top child的regioninfo，
这里约定top为startkey较小的HRegionInfo，bottom则反）。
整个过程正常完成后，会删除parent region；

2）更新完meta表中parent region的记录时，
需要把child region相关信息插入到meta表中，
top child region的startkey和parent key region完全一样，
这个时候regionId就发挥作用了，如果没有regionId，
当meta表中有top region和parent region时，就不知道选哪个了，
因为他们的startkey一样的。而可以通过timestamp作为region的id作区分（top region id取timestamp+1）。
这样就可以保证child region总是排在parent region前面；

3）另外，bottom child必须先插入到meta表中，然后，top child才能插入，
否则，就会出现在meta表中，bottom region里面key找不到对应region的情况。

举个例子还是以上面的例子为基础 meta中rowkey为(table,bar,1351700819876)的region分裂成两个region的meta rowkey分别是(table,bar,1351700819810)和(table,belong,1351700819810),如果这个时候先插入top child：

1 table,,1351700811858
2 table,bar,1351700819876 <---- offline!
3 table,bar,1351700819810 <---- top child
4 table,foo,1351700829874

例如这个时候我需要找key为bgood,我最终会找到这里的第三行top region里面，但是top region里面并不包含bgood。bgood这个这个key是在bottom region里面的。如果先加入bottom就没有这个问题，如下 ：

table,,1351700811858
table,bar,1351700819876 <---- offline!
table,belong,1351700819810 <---- bottom child
table,foo,1351700829874