HBase的架构设计为何这么厉害!

老刘是一名即将找工做的研二学生，写博客一方面是复习总结大数据开发的知识点，一方面是但愿可以帮助和本身同样自学编程的伙伴。因为老刘是自学大数据开发，博客中确定会存在一些不足，还但愿你们可以批评指正，让咱们一块儿进步！

 今天为你们带来的内容是HBase的架构设计，讲讲HBase的架构设计为何这么牛？本文内容不会很长，全是老刘总结的精华，你们不可错过！

1 背景

咱们要提早知道两个问题，这两个问题的解决也刚好回答了HBase的架构设计为何这么牛！

第一个问题是HBase做为一个分布式数据库，它是如何确保在海量数据中，作到低延时的随机读写的呢？

第二个问题是Hbase是如何确保在分布式架构中，保证数据安全的呢？

2 第一个问题解答

确保在海量数据中，低延时的随机读写，HBase真的花了不少心思，作了不少设计，下面让老刘给你们好好说一说！

2.1 内存+磁盘

这个设计在众多框架中都存在，这样作的好处是在数据安全性和数据操做效率之间作了一个权衡，既追求数据安全，也追求数据操做效率。

2.2 内存数据良好的数据结构

HBase为了确保数据操做有更高的效率，也为了保证内存中的数据刷写出来造成有序的文件，这句话是什么意思？什么是数据操做更加高效？

即内存文件为了保证插入删除数据等操做高效，数据有序，因此用到了ConcurentSkipListMap的数据结构！

2.3 范围分区+排序

海量数据作查询通常采用什么方法？

最粗暴的方式就是暴力扫描，但你们通常都不采用，道理都懂！因此咱们通常会采用先排序，再范围分区+分段扫描的办法。那海量数据为了可以让数据有序，在采用插入数据过程当中，怎么作到数据有序的呢？

根据上图，老刘来解释下其中的道理，a先来c随后，最后b也来了，但咱们如何作到把b放在a和c之间呢？

先把数据放在内存里面，a和c已经相邻，如今b来了，要保证abc这样的顺序，其实很容易作到，咱们能够利用数组或链表，把c日后面挪，再把b插入进来，但内存有限，就须要每隔一段时间，把内存中数据写入到磁盘文件，磁盘里的文件就是有序，这样就能方便之后快速定位！

2.4 跳表Topo结构

这是什么意思呢？其实说的是HBase的寻址方式。

HBase的寻址方式分两种，一种是0.96版本以前，一种是0.96版本以后。

在HBase-0.96版本之前，HBase有两个特殊的表，分别是-ROOT-表和.META.表，其中-ROOT-的位置存储在ZooKeeper中，-ROOT-自己存储了.META. Table的RegionInfo信息 。寻址方式的流程以下：

1. Client请求ZooKeeper得到-ROOT-所在的RegionServer地址。
2. Client请求-ROOT-所在的RS地址，获取.META.表的地址，Client会将-ROOT-的相关信息cache下来，以便下一次快速访问。
3. Client请求.META.表的RegionServer地址，获取访问数据所在RegionServer的地址，Client会将.META.的相关信息cache下来，以便下一次快速访问。
4. Client请求访问数据所在RegionServer的地址，获取对应的数据。

咱们能够看出，用户须要3次请求才能知道用户表真正的位置，这在必定程度上带来性能的降低。在0.96以前使用3层设计的主要缘由是考虑到元数据可能须要很大。

那0.96版本以后的寻址流程以下：

1. Client请求ZooKeeper获取.META.所在的RegionServer的地址。
2. Client请求.META.所在的RegionServer获取访问数据所在的RegionServer地址，Client会
   将.META.的相关信息cache下来，以便下一次快速访问。
3. Client请求数据所在的RegionServer，获取所须要的数据。

去掉-ROOT-的缘由主要就是HBase-1.x之后，默认每一个region的最大大小为10G，以前是128M，如今就发现2层的结构已经知足集群的需求了，性能也相对提升了。

讲完Region寻址方式，回到正题跳表Topo结构，就拿0.96版本以前的讲，跳表有三层，第一层是user table，第二层是meta table，第三层是root table，那为何要设计这样的跳表呢？

假设有一张表的数据特别大，一台服务器存不下来，就须要把这张表拆分红好几个部分(例如4个部分)。若是这张表再进行拆分的时候老早已经排好顺序，那拆分出来的数据应该是一段一段的，每一段就包含了这一段的全部数据。

那客户端如今来查询数据，过来扫描数据，那它到底扫描哪一台服务器呢？咱们不肯定，可能每台服务器都要扫描一遍，这样作致使效率不好！

咱们能够先去找一个中间机构去确认要找的数据在这4段中的哪一段，建立一个元数据表meta存真正数据的Region位置，先去找meta表。当元数据表变得特别大，也会切分多个段放在RegionServer中，这个时候就会提供一个ROOT表来肯定meta表的位置。

这就造成了一种层级关系，从ROOT表跳到meta表跳到具体RegionServer。

造成跳表Topo结构下降了扫描次数，原来须要n次或4次扫描，如今变为1次扫描，性能获得提升，而且能够管理很是多的数据。

如何理解能够管理很是多的数据？

hbase1.0以前，每一个Region默认大小是128M，每条元数据为1KB，那它就能存储1千多个元数据，那3层结构就会存储几千万上亿的记录。hbase1.0以后，每一个Region默认大小是10G，两层结构可以存储的数据也足够大，知足集群需求。

2.5 读缓存+写缓存

内存分读缓存和写缓存，把常常查询的数据放在读缓存，能够提高效率。写缓存怎么扫描文件速率最高？就是利用内存+磁盘的方式，先把数据放在内存排序后，再把数据写入到磁盘中，这样磁盘里的文件就是有序的了，接着对磁盘文件二分查找，效率变高。

3 第二个问题解答

为了确保在分布式架构中，数据的安全，HBase怎么作？

3.1 内存+磁盘

HBase采用了内存+磁盘存储的方式，这样作的好处是在数据安全性和数据操做效率之间作了一个权衡，既追求数据安全，也追求数据操做效率。

3.2 WAL机制

WAL意为Write Ahead Log，相似MySQL中的binlog，用来作灾难恢复之用。HBase为了防止数据写入缓存以后不会因RegionServer进程发生异常致使数据丢失，在写入缓存以前会首先将数据顺序写入到HLog(WAL)中。若是不幸一旦发生RegionServer宕机或者其余异常，这种设计能够从HLog中进行日志回放进行数据补救，保证数据不丢失。HBase故障恢复的最大看点就在于如何经过HLog回放补救丢失数据。

4 总结

好啦，HBase的架构设计大体聊得差很少了，老刘主要给你们讲了讲为何HBase的架构设计这么牛。尽管当前水平可能不及各位大佬，但老刘仍是但愿可以变得更加优秀，可以帮助更多自学编程的伙伴。

若是有相关问题，请联系公众号：努力的老刘。若是以为帮到了您，不妨点赞关注支持一波！