hbase经典问题剖析

hbase经典问题剖析

1）hbase架构设计之元数据管理之root表和meta表说明？

hbase0.98版本及之前元数据管理说明

概要说明

HBase的用-ROOT-表来记录.META.的Region信息，就和.META.记录用户表的Region信息一模一样。

-ROOT-只会有一个Region。Client端就需要先去访问-ROOT-表。所以需要知道管理-ROOT-表的RegionServer的地址。

该地址被存在ZooKeeper中。默认的路径是：/hbase/root-region-server

工作流程描述

HBase的所有Region元数据被存储在.META.表中，随着Region的增多，.META.表中的数据也会增大，并分裂成多个新的Region。

为了定位.META.表中各个Region的位置，把.META.表中所有Region的元数据保存在-ROOT-表中，

最后由Zookeeper记录-ROOT-表的位置信息。

所有客户端访问用户数据前，需要首先访问Zookeeper获得-ROOT-的位置，然后访问-ROOT-表获得.META.表的位置，最后根据.META.表中的信息确定用户数据存放的位置，

-ROOT-表永远不会被分割，它只有一个Region，

这样可以保证最多只需要三次跳转就可以定位任意一个Region。

为了加快访问速度，.META.表的所有Region全部保存在内存中。

客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。

如果客户端根据缓存信息还访问不到数据，则询问相关.META.表的Region服务器，试图获取数据的位置，如果还是失败，则询问-ROOT-表相关的.META.表在哪里。

最后，如果前面的信息全部失效，则通过ZooKeeper重新定位Region的信息。所以如果客户端上的缓存全部是失效，则需要进行6次网络来回，才能定位到正确的Region。

hbase0.98版本之后元数据管理说明(为优化执行效率而升级)

即为现在的元数据管理方式，去除-ROOT-表，仅保留.meta.表。

.meta.表有且仅有一个region来存储，其不可再split分割成更多的region块。

通过调整大.meta.表的region文件大小，即可解决海量数据的region元数据管理问题。

2）hbase之rowkey设计技巧

背景说明

HBase是三维有序存储，即rowkey（行键）、column key（column family和qualifier）、TimeStamp（时间戳-版本号）这个三个维度可以对HBase中的数据进行快速定位。

rowkey唯一标识一行记录，有以下几种方式：

1. 通过get方式，指定rowkey获取唯一一条记录

2. 通过scan方式，设置startRow和stopRow参数进行范围匹配

3. 全表扫描，即直接扫描整张表中所有行记录(不推荐)

rowkey设计必要性-避免热点问题

热点发生在大量的client直接访问集群的一个或极少数个节点（访问可能是读，写或者其他操作）。

大量访问会使热点region所在的单个机器超出自身承受能力，引起性能下降甚至region不可用，这也会影响同一个RegionServer上的其他region，由于主机无法服务其他region的请求。

多数是由于rowkey散列设计不合理导致的。

设计技巧说明

长度要越短越好，不要太长

rowkey是二进制码流存储，理论上是可以是任意字符串，一般最大长度64kb，实际应用中一般为10-100bytes，一般设计成定长。

数据持久化文件HFile中是按照KeyValue存储的，rowkey为其key，其它的值为其value，rowkey太长，会极大影响HFile的存储效率；

MemStore会缓存部分数据到内存，如果rowkey字段过长，内存的有效利用率就会降低，系统将不能缓存更多的数据，从而降低检索效率。

rowkey散列原则

原因说明

rowkey是hbase数据的排序、划分的主要依据，如果海量数据环境中，rowkey设计生成的值过于稠密，则会导致数据的集中于某个region上的存储，从而使对应的regionserver的负载过高。

很多人经常时间戳作为rowkey来设计，如果rowkey按照时间戳的方式递增，会经常导致大部分甚至所有的数据都会集中在一个RegionServer上，这样在数据检索的时候负载会集中在个别的RegionServer上，造成热点问题，会降低查询效率。

散列做法

至少不要将时间放在二进制码的前面。

第一种选择是可以将时间错进行倒序后作为rowkey

即常见的 rowkey串反转的作法。比较简单，但是失去了rowkey的可读性、有序性的意义。

第二种是建议将rowkey的高位作为散列字段，由程序随机生成，低位放时间字段，这样将提高数据均衡分布在每个RegionServer，以实现负载均衡的几率。

即常见的加盐做法，可以有效避免热点问题。

如果没有散列字段，首字段直接是时间信息

rowkey唯一原则

rowkey是一行数据的唯一标识，必须在设计上保证其唯一性，rowkey是按照字典顺序排序存储的。

在设计rowkey的时候，要充分利用这个排序的特点，将经常读取的数据存储到一块，即将最近可能会被访问的数据放到一块。

这样更方便利用数据块集中加载、数据缓冲加速等提升查询效率。