hbase learning

万万没想到，促使我填坑的居然是学习HBase，之前听分享的时候知道它是一个kv型的数据库就没有多了解，现在才开始学习。

hbase和bigtable很像，入门看起来也不太难#flag #下面是对于我看的一个介绍的翻译and理解：

hbase的结构组件

　　物理上，hbase是一个三种服务构成的主从式的结构，Region服务器管理数据的读写，当接收数据的时候，客户和HBase Region服务器直接通信，Region的分配和DDL操作由Master管理，Zookeeper是HDFS的一部分，维护集群的工作状态。

　　Hadoop数据块储存着Region服务器管理的数据，所有的hbase文件都存在HDFS文件里面，(Region server)Rser由HDFS datanode组成，hbase数据在被写入时是是本地的，然而当region被移动(move)，直到压缩前都不是(我认为这句的意思是，写入的东西在压缩前并未更改到hadoop数据块中，所以压缩前，数据块都不是最新的，那段数据存在写入的机器上)

　　“The NameNode”维护所有存储文件的数据块的元数据信息

Region

　　hbase表被按行的范围分成了regions，一个region包括表中的一段行，regions被分配到集群中的块上，叫做region servers，它管理数据的读写，一个Rser可以管理1000regions (regions != regions servers regions = many region)

Hbase Hmaster

　　管理Region分配，ddl操作。

　　对以下负责：

　　　　协调Rser

　　　　- 分配regions当启动、regions重新分配、负载均衡

　　　　- 监听集群中所有Rser状态(从ZK接受通知)

　　　　管理者行为

　　　　- 有创建、删除、更新表的接口

　ZooKeeper：协调者

　　hbase使用zk做一个分布式协调服务，用来维护集群中的服务状态，zk维护可用、安在的服务器，并且提供服务失效通知，zk使用"共识"来保证共同的共享状态，通常三五个共识(共识是，多个zk进行判断，讨论后给出结论)

组件如何一起work

　　zk被用来协调分享分布式系统中的成员状态信息，Rser和活着的master和zk保持会话，zk建立一个临时节点通过心跳信息维护会话

　　每个Rser都创造一个临时节点，master监听这些点来发现可用Rser和GGRser，hmaster争夺创建临时点，ZK认可第一个让它做master，它和zk发心跳信息，GG的hmaster监听okmaterGG的通知

　　如果一个Rser或者okmaster没有发心跳，回话就会关闭，临时节点就会被删除，监听者会广播删除点，okmaster会听Rser，会恢复GGRser，GGmaster会监听okmaster，如果okmasterGG了，GGmaster会变ok(没说是否还要抢，应该是)

hbase 的第一次读写(cache是空的)

　　有一个特殊的hbase目录表叫做meta表，维护了集群中regions的位置，ZK存meta表的位置

　　clinet第一次读或者写hbase:

　　　　client从ZK中找到存meta的Rser

　　　　client去meta里面的meta找到想要的数据在哪个Rser上，存cache

　　　　去Rser里面取数据

　　为了以后的读写，client在cache里面存了meta位置和之前读的行的位置，在一个region被移动之前都不需要再问meta

hbase meta 表

　　一个hbase表存着所有regions的list

　　宛如b树

　　结构：

　　　　key：region start key,region id

　　　　val: Rser

　　　　# 很分块

Rser 组件

　　一个Rser在HDFS数据块上跑并且有下面的组件：

　　　　wal：预写log，一个文件，被用来存没有被持久化到永久存储的数据，用来错误恢复

　　　　blockcache：读cache 使用LRU

　　　　memStore：写cache，存没有被写入硬盘的新数据，在写入硬盘之前会被sort，每个region的每个列族都有一个这个

　　　　hfile：在硬盘上，存成行的被sort后的kv对

hbase写（1）

client建立请求，第一步是写入wal：

　　1.修改被追加到wal最后

　　2.wal被用来恢复未持久化数据当serverGG

Hbase写（2）

　　data写入wal之后，将被放到mem里面去，然后ack到client

hbase mem

　　mem在内存中将更新作为kv对存储，宛如存在hfile一样，每个列族都有一个

hbase region flush

　　一旦mem积累足够多data，这个被排序的集合九江被写成一个新的hfile存到hdfs，一个列族很多hfile，存着所有的项目(cell),这些文件都是被存进mem的不断的修改给flush成文件写到硬盘的

　　之所以要limit列族数量，这是一个原因(并没有看出有什么原因啊)，对每个cf都有一个mem，满了就flush，并且维护了最后一次写的自增id，以便知道现在持久化了多少

　　最大的自增id作为每个hfile的元字段，反应现在存储到的位置，当region启动，读取所有的自增id，选出最大的来用

hbase hfile

　　数据被存成hfile，包括了kv对，当mem凑够了data，就将在hdfs里面写一个新的hfile，这是一个顺序的写，很快并且避免了移动磁盘头（就是一直让盘转就行了）

hbase hfile 的 结构（很acm的设计。。）（讲的是把单个的hfile再分一个块）

　　一个hfile有很多层级索引让hbase找文件的时候不用读完，这个索引很像B+树

　　1 kv被按照升序排列

　　2 键值对的行被分为64kb一块

　　3 每块都有自己的叶子index

　　4 每个块的最后一个key被放在中间索引中（我的理解是他们构成了中间索引）

　　5 root index在中间索引中

　　维护了一个元块，被写到持久化文件的末尾（我认为似乎是在每一块的末尾都有，但是给的图只有最后有，其余的都是bloom），它有像bloom和时间范围的信息，bloom帮助跳过不含有指定kv的文件，时间范围被用来跳过不在指定时间的。（做快速排斥用）

hfile索引

　　当hfile被打开的时候索引加载到blockcache，允许在单个的磁盘里面查找（单一文件查找）

hbase的读合并

　　一个kv的行可能很多地方都有，一行也会被存到多个hfile，最后的一次更新在mem，最后的读在blocache，当读一行的时候，有一个“读合并”过程　　

　　1 读 blocache

　　2 读mem

　　3 用blocache索引和bloom筛选来找出应当含有指定kv的行的hfile，加载到内存找

　　一个mem会产生很多hfile，当读的时候会处理很多文件而影响性能，叫做阅读放大