HBase原理总结

HBase知识点整理

1、客户端从hbase中查询数据的过程

    客户端要从hbase数据库中查找数据的时候，会先从zk上查找meta表所在的region server(该信息会在hbase集群启动的时候注册到zk中去)，然后客户端会依据该信息再去meta表中查找自己所要的数据存储在哪台region server上，最后去那台region server上提交要查询的信息。首先会查询该Region在内存中的缓存——Memstore(Memstore是一个按key排序的树形结构的缓冲区)，如果在Memstore中没有查到匹配的数据，接下来会读已持久化的StoreFile文件中的数据。最后region server会将查到的数据返回给客户端。

2、hbase是nosql，类似于mongodb，一行数据可以存储在不同的列族中，每一个列族中插入的kv没有数量和格式的限制。

3、hbase集群有一个HMaster进程，其主要负责HBase系统的各种管理工作：

• 处理用户的各种管理请求，包括建表、修改表、权限操作、切分表、合并数据分片以及Compaction等。
• 管理集群中所有RegionServer，包括RegionServer中Region的负载均衡、RegionServer的宕机恢复以及Region的迁移等。
• 清理过期日志以及文件，Master会每隔一段时间检查HDFS中HLog是否过期、HFile是否已经被删除，并在过期之后将其删除。

4、hbase的优点

• 大：一个表可以有上十亿行，上百万列。
• 面向列：面向列(簇)的存储和权限控制，列(簇)独立检索。
• 高可靠性：WAL预写式日志(write-ahead log)机制保证了数据写入时不会因集群异常而导致写入数据丢失，Replication机制保证了在集群出现严重的问题时，数据不会发生丢失或损坏。而且Hbase底层使用HDFS，HDFS本身也有备份。
• 高性能：底层的LSM数据结构和Rowkey有序排列等架构上的独特设计，使得Hbase具有非常高的写入性能。region切分，主键索引和缓存机制使得Hbase在海量数据下具备一定的随机读取性能，该性能针对Rowkey的查询能到达到毫秒级别。

5、hbase与hive对比。hive是对mapreduce程序的封装，hive能将hql命令转化为mapreduce程序，它只能查找在hdfs中已经存在的数据，并且不像mysql一样还能对数据进行增、删、改操作，hive只支持对数据的查找，并且由于是由mapreduce程序实现的，其效率不高。而hbase可以理解为nosql数据库，只是其数据不是存储在本地，而是存储在hdfs之上的，其支持数据的增、删、改、查（不用通过mapreduce程序实现），并且由于LSM数据结构和region切分以及面向列的特性，使得其速度很快。所以hive不能称之为数据库，它仅支持对数据进行结构化的查询和分析，而hbase则是一个大容量、高性能的分布式数据库。

6、put流程时序图（引自其他博客，侵删）

    每一个HRegionServer都会在其所在节点上维护一个内存区域用于存储热数据，当收到来自客户端的操作请求后，HRegionServer都会先将数据存储在内存menstore中，同时将操作信息作为日志存储在hdfs上的WALs目录中。一旦menstore中的数据达到一定阈值后，就会以Hfile文件格式存储到hdfs中去。如果在某个时候，某个节点宕机了，但是其menstore中的数据信息还没有存储到hdfs中，那么HMaster就会安排其他的某一个节点去读取该宕机节点的操作日志，从而对数据进行恢复。

7、Region/Store/Memstore/StoreFile/Hfile之间的关系  //引自其他博客，侵删

• Region：table在行的方向上分隔为多个Region。Region是HBase中分布式存储和负载均衡的最小单元，即不同的region可以分别在不同的Region Server上，但同一个Region是不会拆分到多个server上。Region按大小分隔，表中每一行只能属于一个region。随着数据不断插入表，region不断增大，当region的某个列族达到一个阈值（默认256M）时就会分成两个新的region

• Store：每一个region有一个或多个store组成，至少是一个store，hbase会把一起访问的数据放在一个store里面，即为每个ColumnFamily（每一个列族）建一个store（即有几个ColumnFamily，也就有几个Store）。一个Store由一个memStore和0或多个StoreFile组成。HBase以store的大小来判断是否需要切分region。
• Memstore：是放在内存里的。保存修改的数据即keyValues。当memStore的大小达到一个阀值（默认64MB）时，memStore会被flush到文件，即生成一个快照。目前hbase 会有一个线程来负责memStore的flush操作。当其中一个CF的Memstore达到阈值flush时，所有其他CF的也会被flush,每次Memstore Flush，会为每个CF都创建一个新的StoreFile,每个CF同时刷新的目的是为了一个region的数据存储在一个服务器节点上.
• StoreFile：memStore内存中的数据写到文件后就是StoreFile（即memstore的每次flush操作都会生成一个新的StoreFile），StoreFile底层是以HFile的格式保存。由于menstore中所有CF同时刷新的原因，导致了StoreFile的大小不一样，当StoreFile文件数量增长到一定阈值,会触发compact操作,将多个StoreFile合并成一个StoreFile。
• Hfile：HFile是HBase中KeyValue数据的存储格式，是hadoop的二进制格式文件。一个StoreFile对应着一个HFile，StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile.。而HFile是存储在HDFS之上的。 HFile文件的特点：1.HFile由DataBlock、Meta信息(Index、BloomFilter)、Info等信息组成。2.整个DataBlock由一个或者多个KeyValue组成。(注:value是指一个单元格,key指的并不是rowkey)。KeyValue: HFile里面的每个KeyValue对就是一个简单的byte数组。但是这个byte数组里面包含了很多项，并且有固定的结构。其结构图如下图所示：

8、布隆过滤器的简单理解以及其在hbase中的作用

    HFile是由一个个数据块与索引块组成，他们通常默认为64KB。hbase是通过块索引来访问这些数据块的。而索引是由每个数据块的第一行数据的rowkey组成的。当hbase打开一个HFile时，块索引信息会优先加载到内存当中，然后hbase会通过这些块索引来查询数据。但是块索引是相当粗粒度的，我们可以简单计算一下。假设一个行占100bytes的空间，所以一个数据块64KB，所包含的行大概有：(64 * 1024)/100 = 655.53 = ~700行。而我们只能从索引给出的一个数据块的起始行开始查询。如果用户随机查找一个行键，则这个行键很可能位于两个开始键（即索引）之间的位置。

    对于hbase来说，它判断这个行键是否真实存在的唯一方法就是加载这个数据块，并且扫描它是否包含这个键，这就需要耗费很多时间。因此引入布隆过滤器，它能够准确判断该HFile的所有数据块中，是否含有我们查询的数据，从而大大减少不必要的块加载。

    对于hbase而言，当我们选择采用布隆过滤器之后，HBase会在生成StoreFile（HFile）时包含一份布隆过滤器结构的数据，称其为MetaBlock；MetaBlock与DataBlock（真实的KeyValue数据）一起由LRUBlockCache维护。所以，开启bloomfilter会有一定的存储及内存cache开销。但是在大多数情况下，这些负担相对于布隆过滤器带来的好处是可以接受的。

    采用row还是rowcol布隆过滤器，这取决于用户的使用模式。如果用户只做行扫描，使用更加细粒度的行加列布隆过滤器不会有任何的帮助，这种场景就应该使用行级布隆过滤器。当用户不能批量更新特定的一行，并且最后的使用存储文件都含有改行的一部分时，行加列级的布隆过滤器更加有用。

 

 

疑惑

1. 在java程序中为什么要将字符串先转化为Byte才能插入hbase数据库中，我直接存入字符串难道最后不还是通过编码系统将字符串值转为二进制存储吗？

2. hdfs中的数据无法修改，那么以hdfs作为存储基础的hbase为什么能修改数据呢？

    解：每次修改的数据都会作为最新的一个版本存储在hdfs中，而原来的旧的数据信息也是存在的，以后查询结果的时候只返回最新的信息就相当于是实现了修改数据这一个操作。

    但是这样导致的冗余的数据如何处理掉呢？

 

参考链接

1. https://blog.csdn.net/linxiyimeng007/article/details/81562081

2. https://blog.csdn.net/u010916338/article/details/80774554

3. https://blog.csdn.net/lijingjingchn/article/details/89924181

4. https://blog.csdn.net/qq_38180223/article/details/80922114