在BigTable之后入门HBase（一）

最近刚开学，忙于各种琐事，学习的时间比较少，前几天对于Google的一篇论文BigTable学了学，不得不说关于MIT实验室所做的东西都是相当的有难度，几乎花了一整天的时间，才勉强弄懂了BigTable，但是具体的编程实现可能还需要一段时间，包括MIT专用的Go语言，以及我们自己现在开发用的java和scala语言，最近任务还是挺重的。其实写这篇博客除了为了自己以后复习之外，还有就是我在网上查阅相关的BigTable相关文档时，全是一些Google论文的翻译而已，并没有多少好处，而且还有很多错误，搞了几个月的分布式了，其实最好的学习方法还是看官方的论文以及去官方的网站进行查阅，毕竟翻译过来的东西总是会有些文化差异，翻译永远只能是搭配着看看。
这篇博客主要分为两个部分，一个是对Google论文BigTable的简单理解，另一部分就是对于BigTable的类似实现版本HBase的一些理解与应用。
## ***

BigTable

---

对于Google的经典论文之一，它出现的时间和实现以及技术上的成功真的不是哪一个山寨的东西可以恭维的。简单来说他就是一个结构化的分布式存储系统。提到分布式，可知道几个基本特性了，高可用，一致性，高性能，可扩展，可伸缩，等等，一些CAP理论的东西都可以多多少少掺杂进来，但是，如果真的要完美实现这些，根本不可能，所以一般也只能折中的实现。这个东西类里面有些和关系型数据库差不多的术语，但是呢，内部的实现有完全不同，在他们的性能测试中，完全不比一般的数据库系统要差。现在我们就来仔细的了解了解它。

数据模型—数据结构

看上面这个图片，我们先来理清几个概念。
row：中文意思就是行呗，图片中也可以看出来，官方称作RowKey
ColumnKey：可以看成列，其中有个术语column family叫做列簇。
timestamp：时间戳。代表每一个cell（数据项）的版本，这个时间戳可以是电脑当前时间，也可以是自己所设定的序列号，反正就是用于区分根据row和column确定的value的不同版本。在HBase里面可以设定最多的版本数量，BigTable也可以，多余的那些最旧的版本就可以被回收掉。
有了上面的概念，我们就可以好好来分析了。
我们可以根据上面三个东西确定唯一的一个值，就像是map-value一样，不过这个map有点特殊而已：（row:rk01,column:cf1,timestamp:20190306）=>(value:…)，形成这样的映射关系，我们可以想象成一个立体图，就是一个三维空间一样。
我们需要注意的是row是根据词典顺序排序的，我们根据图片可以看出网站的域名都是按顺序排列，然后作为RowKey每一行又有不同的column，（column：contents，language等等），再又根据时间戳确定value:t5，t6等等,每一个value是一个不间断的字节数组。
Tablet：可以说就是一个小数据块，或者说是小数据表，就说若干Row组成的Tablet

数据块

什么是数据块？
其实就是一些存放上面数据模型的一些数据槽：block
我们不用管它是什么，可以想象成存放数据的卡槽，每一个是64KB。
可是分布式的东西，又是庞大的数据集，这些东西存放在哪里呢？
这时候GFS就有用处了。
Google File System
我在画图里里面画了一张图片，可以很好的形容在GFS里面怎么存储这些数据的。
首先我们来看METADATA Tablets这个东西分成两种，一种是root tablet 还有一种是普通tablet
METADATA Tablets：
root tablet：它是一个根tablet，它知道有哪些普通tablet
普通tablet：他保存了有哪些user tablet，即tablet1,2等等
这样的设计是一个B+的树形数据结构，为的是能够快速找到所需要的tablet以及相关的信息。

这个图片我画的不是很完整，但是呢我们可以大概了解到在GFS里面这些Tablet是怎么找到的。
首先有一个服务器，在Bigtable‘里面’是chubby，在HBase里面是Zookeeper，它了解到哪里是rootTablet，然后根据客户端发来的想要查找的信息找到对应的普通的METADATA tablets 然后在找到具体的tablet，这样就需要三次的网络通信，还有一种比较复杂的情况就是，查找的数据丢失或者错误，还是没有找到，就会返回上一级查找，如果一样没找到就继续返回上一级，如此一来就需要有最多六次的网络通信，当然这是最坏的情况。
服务器可是一个大组件，可不要小看它的功能，在分布式里面他的协调作用可是很大的，不仅这样，他还可能减少整个网络和集群的负担。

组件

BigTable里面有几大组件：Chubby（服务器） Maseter（HBase里面是HMaster） tablet server，链接客户端的库。
Chubby：这是一个协调整个集群的服务器。里面可以有一个derectory，里面包含了某些file，每个file有一个lock，当有一个tablet server注册进来时，就会创建一个file，并且这个tablet server能够获取到这个file的锁，暗示着这个集群有了这个tablet server，一般master也会通过这个文件锁来detect某个tablet server是否存在或者是否停机，故障，同时只要经过master和tablet server进行通信后，就可以直接和tablet server进行联系。这个服务器的功能：
1：保证只有一个服务器能够运行，其实Chubby有几个副本，他们会通过某种算法来选择这个主要的服务器（可以去看看PAXOS算法）。
2：保存那个Root tablet的位置信息，以便访问存储信息。
· 3：负责tablet server的生命周期调控
4：存储访问控制的列表
5：存储表格信息
这几个可以在官方文档里面找到，我也不具体说，在以往的分布式系统，前三个功能减轻了master的负担，这样替master分担一部分。
master： 先说一说它的功能：
1：分配tablet给tablet server管理
2：检测tablet server的状态
3：平衡tablet server的负载
4：垃圾回收GFS，比如已经过期的tablet，或者是一些混杂的tablet
5：处理一些tabelt更改信息，比如创建，删除
这个是一个主要的server，这个东西一出来，就要检测当前所有tablet和tablet server的状态，看所有的tablet是否对应到了归一个tablet server管理比如一个master出了故障，该怎么恢复。对于当前没有分配的tabelt，会分配给对应的当前存活的tablet server。刚才也说过了，master可以通过服务器的derectory中tablet的文件锁观察某个tabletserver是否存过。
tablet server：
1：管理自己对应的tablet
2：处理对应的读写操作
3：当tablet到达一定的大小时候，分割他们
总体来说，就是处理自己所管理的tablet信息，它本来就是这样。
链接客户端的库： 这个建立在tablet server和master上，进行一些通信等等。这个不详细说了，我也不知道里面有些什么东东。

master启动

关于master启动，可能是因为原来的master没用了，这样就导致必须使用新的master，但是新的master进来之后怎么搞呢，
首先我们可以想象成注册到Chubby服务器的一个锁，或者说是抢占Chubby服务器中唯一的master资源，避免其它的master做无用的竞争。
然后就是扫描那个Chubby中tablet server注册的文件锁，来获取当前存活的tablet server的状态。 然后和tablet
server进行通信，来找到哪些tablet对应哪些tablet server 如果GFS里面那个root
tablet没有被注册到，那么就会重新选一个root tablet。 最后就是通过root tablet扫描METADATA
tablet，进而扫描所有的tablet，就知道哪些tablet没有分配tablet server了，前面的选择root
tablet就为整个操作奠定了基础。

读写操作

先看1,2，就是一个写操作过来了，这个tablet
server根据来得写操作，先检查他的格式是否符合规范，并且检查发送者是否有操作他的权限。
3就是把这个操作加入这个日志，等下再分析这个日志有什么用。 4:就是把具体的操作执行，并把写的文件加入memtable
需要注意的是看清这个图，memtable是在tablet server的内存中，而Commit log和SST file是在GFS中。
一旦一个memtable满了，就会形成一个新的SST（SS table），写入到GFS，并且清理原来的memtable。这个叫做minor compaction。
当然当SST越来越多了，也会合成一个大的SST，这个过程叫做Merging compaction
还有就是合成所有的SST 叫做Major compaction

当一个读操作过来了，同样也是检查这个请求格式是否是对的，检查请求者是否有权限。然后这个读操作就是从memtable和SST中读过来

这个是基本的读写操作。以及穿插了一部分merging操作。和split操作

也是有人会问，这么多东西，那个Commit log到底有什么用处，他不过就是充当一下恢复tablet时，执行这个log可以恢复到原来的状态。
缓存

在tablet server索引某个key-value时，会有个scan Cache，记录近段时间所索引的key-value，当在block index查找这个key-value时是在哪个block，又有个block Cache，记录是否索引过block。这样就加大了读取过着写操作速度。

好了，我对于基本的BigTable理解就差不多这样了，通过这几个图就可以好好理解一下了。下面我们来看看HBase了。

**

HBase

**
一：HBase安装配置
这个不用多说，跟着官网文档来，当然我是在LInux环境下的安装配置
进入HBase官方网站http://hbase.apache.org/，在Download选择click here，下载对应的bin包。


然后进入终端，解压你下载的包。

看到conf文件里面有两个配置文件，hbase-env.sh和hbase-site.xml

按照官方文档里面的方法，有单机模式，伪分布式模式，还有完全分布式，具体配置会额外的写一篇博客进行商量。

HBase也不过是一个分布式的存储系统而已，具体原理和BigTable差不多
先介绍到这里，后面我们再细说HBase的shell以及一些java API。