行式存储下一张表的数据都是放在一起的，但列式存储下都被分开保存了

下面才是那张表本来的样子。经过字典表进行数据压缩后，表中的字符串才都变成数字了。正因为每个字符串在字典表里只出现一次了，所以达到了压缩的目的(有点像规范化和非规范化Normalize和Denomalize)

通过一条查询的执行过程说明列式存储(以及数据压缩)的优点：

HBase是一个开源的非关系型分布式数据库（NoSQL），它参考了谷歌的BigTable建模，实现的编程语言为 Java。

它是Apache软件基金会的Hadoop项目的一部分，运行于HDFS文件系统之上，为 Hadoop 提供类似于BigTable 规模的服务。

因此，它可以容错地存储海量稀疏的数据。

HBase在列上实现了BigTable论文提到的压缩算法、内存操作和布隆过滤器。

Hbase是bigtable的开源版本，是建立的hdfs之上，提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统。

key)和主键的range来检索数据，仅支持单行事务(可通过hive支持来实现多表join等复杂操作)，主要用来存储非结构化和半结构化的松散数据。

与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。

Hbase中的表一般有这样的特点：

1. 大：一个表可以有上亿行，上百万列
2. 面向列:面向列(族)的存储和权限控制，列(族)独立检索。
3. 稀疏:对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏。

Hbase以表的形式存储数据。表有行和列组成。列划分为若干个列族(row family)

访问Hbase table中的行，只有三种方式：

设计key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。(位置相关性)

要保持整形的自然序，行键必须用0作左填充。

行的一次读写是原子操作 (不论一次读写多少列)。这个设计决策能够使用户很容易的理解程序在对同一个行进行并发更新操作时的行为。

Hbase表中的每个列，都归属与某个列族。

列族是表的chema的一部分(而列不是)，必须在使用表之前定义。

访问控制、磁盘和内存的使用统计都是在列族层面进行的。

　　实际应用中，列族上的控制权限能帮助我们管理不同类型的应用：我们允许一些应用可以添加新的基本数据、一些应用可以读取基本数据并创建继承的列族、一些应用则只允许浏览数据(甚至可能因为隐私的原因不能浏览所有数据)。

Hbase中通过row和columns确定的为一个存贮单元称为cell。每个 cell都保存着同一份数据的多个版本。版本通过时间戳来索引。

时间戳的类型是 64位整型。

　　时间戳可以由Hbase(在数据写入时自动 )赋值，此时时间戳是精确到毫秒的当前系统时间。

　　时间戳也可以由客户显式赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。

每个 cell中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。

为了避免数据存在过多版本造成的的管理 (包括存贮和索引)负担，Hbase提供了两种数据版本回收方式。

　　一是保存数据的最后n个版本，

　　二是保存最近一段时间内的版本(比如最近七天)。

用户可以针对每个列族进行设置。

cell中的数据是没有类型的，全部是字节码形式存贮

3、region按大小分割的，

　　每个表一开始只有一个region，随着数据不断插入表，region不断增大，

　　当增大到一个阀值的时候，Hregion就会等分会两个新的Hregion。

　　当table中的行不断增多，就会有越来越多的Hregion。

4、HRegion是Hbase中分布式存储和负载均衡的最小单元。

　　最小单元就表示不同的Hregion可以分布在不同的HRegion server上。但一个Hregion是不会拆分到多个server上的。

5、HRegion虽然是分布式存储的最小单元，但并不是存储的最小单元。

Hfile的格式如下图所示：

HFile分为六个部分：

• Data Block 段–保存表中的数据，这部分可以被压缩。
• Meta Block 段 (可选的)–保存用户自定义的kv对，可以被压缩。
• File Info 段–Hfile的元信息，不被压缩，用户也可以在这一部分添加自己的元信息。
• Index会被读取到内存中，这样，当检索某个key时，不需要扫描整个HFile，而只需从内存中找到key所在的block，通过一次磁盘io将整个block读取到内存中，再找到需要的key。DataBlock Index采用LRU机制淘汰(LRU是Least Recently Used的缩写，即最近最久未使用，常用于，是为虚拟页式服务)。

HFile的Data Block，Meta Block通常采用压缩方式存储，压缩之后可以大大减少网络IO和磁盘IO，随之而来的开销当然是需要花费cpu进行压缩和解压缩。

目前Hfile的压缩支持两种方式：Gzip，Lzo。

首先HFile文件是不定长的，长度固定的只有其中的两块：Trailer和FileInfo。

正如图中所示的，Trailer中有指针指向其他数据块的起始点。

每个Data块的大小可以在创建一个Table的时候通过参数指定，大号的Block有利于顺序Scan，小号Block利于随机查询。

每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成,

　　Magic内容就是一些随机数字，目的是防止数据损坏。

但是这个byte数组里面包含了很多项，并且有固定的结构。我们来看看里面的具体结构：

　　开始是两个固定长度的数值，分别表示Key的长度和Value的长度。

• 开始是固定长度的数值，表示RowKey的长度，
• 然后是固定长度的数值，表示Family的长度，

　　Value部分没有这么复杂的结构，就是纯粹的二进制数据了。

Hlog记录数据的所有变更,一旦数据修改，就可以从log中进行恢复。

　　优点：这样不同region(来自不同table)的日志会混在一起，这样做的目的是不断追加单个文件相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高对table的写性能。

　　缺点：带来的麻烦是，如果一台region server下线，为了恢复其上的region，需要将region server上的log进行拆分，然后分发到其它region server上进行恢复。

•  HLogKey中记录了写入数据的归属信息，

1. 保证任何时候，集群中只有一个master
2. 存贮所有Region的寻址入口。

1. 管理用户对Table的增、删、改、查操作
2. GFS上的垃圾文件回收

HRegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。

　　　　每个HStore对应了Table中的一个Column Family的存储，可以看出每个Column Family其实就是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个Column Family中，这样最高效。

　　用户写入的数据首先会放入MemStore，

　　当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除，

　　因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。

当单个StoreFile大小超过一定阈值后，会触发Split操作，

在理解了上述HStore的基本原理后，还必须了解一下HLog的功能，因为上述的HStore在系统正常工作的前提下是没有问题的，但是在分布式系统环境中，无法避免系统出错或者宕机，因此一旦HRegionServer意外退出，MemStore中的内存数据将会丢失，这就需要引入HLog了。

　　在每次用户操作写入MemStore的同时，也会写一份数据到HLog文件中（HLog文件格式见后续），

　　HLog文件定期会滚动出新的，并删除旧的文件（已持久化到StoreFile中的数据）。

　　HMaster首先会处理遗留的 HLog文件，

　　　　将其中不同Region的Log数据进行拆分，分别放到相应region的目录下，

　　然后再将失效的region重新分配，

1. 第三层是.META.，它是一个特殊的表，保存了Hbase中所有数据表的region 位置信息。

1. root region永远不会被split，保证了最多需要三次跳转，就能定位到任意region 。
2. META.表每行保存一个region的位置信息，row key 采用表名+表的最后一样编码而成。
3. 为了加快访问，.META.表的全部region都保存在内存中。
4. client会将查询过的位置信息保存缓存起来，缓存不会主动失效，因此如果client上的缓存全部失效，则需要进行6次网络来回，才能定位到正确的region(其中三次用来发现缓存失效，另外三次用来获取位置信息)。

假设，.META.表的一行在内存中大约占用1KB。并且每个region限制为128MB。那么上面的三层结构可以保存的region数目为：

当系统出现意外时，可能导致内存(MemStore)中的数据丢失，此时使用Log(WAL log)来恢复checkpoint之后的数据。

前面提到过StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。

由于对表的更新是不断追加的，处理读请求时，

•  并且StoreFile带有内存中索引，合并的过程还是比较快。

1. 如果客户端没有指定版本，则获取当前系统时间作为数据版本

•  当某个region server启动时，会首先在zookeeper上的server目录下建立代表自己的文件，并获得该文件的独占锁。
•  由于master订阅了server目录上的变更消息，当server目录下的文件出现新增或删除操作时，master可以得到来自zookeeper的实时通知。因此一旦region server上线，master能马上得到消息。

而master不断轮询server目录下文件的锁状态。如果master发现某个region server丢失了它自己的独占锁，(或者master连续几次和region server通信都无法成功),master就是尝试去获取代表这个region server的读写锁，一旦获取成功，就可以确定：

的其中一种情况发生了，无论哪种情况，region server都无法继续为它的region提供服务了，此时master会删除server目录下代表这台region server的文件，并将这台region server的region分配给其它还活着的同志。

如果网络短暂出现问题导致region server丢失了它的锁，那么region server重新连接到zookeeper之后，只要代表它的文件还在，它就会不断尝试获取这个文件上的锁，一旦获取到了，就可以继续提供服务。

1. 扫描.META.region的集合，计算得到当前还未分配的region，将他们放入待分配region列表。

由于master只维护表和region的元数据，而不参与表数据IO的过程，

master下线仅导致所有元数据的修改被冻结(无法创建删除表，无法修改表的schema，无法进行region的负载均衡，无法处理region上下线，无法进行region的合并，唯一例外的是region的split可以正常进行，因为只有region server参与)，表的数据读写还可以正常进行。

因此master下线短时间内对整个Hbase集群没有影响。

从上线过程可以看到，master保存的信息全是可以冗余信息(都可以从系统其它地方收集到或者计算出来)，

因此，一般Hbase集群中总是有一个master在提供服务，还有一个以上的”master”在等待时机抢占它的位置。

1. Pig，可以使用Pig Latin流式编程语言来操作HBase中的数据，和Hive类似，本质最终也是编译成MapReduce Job来处理HBase表数据，适合做数据统计

• 文中介绍了集群的搭建过程，提供了一键安装的脚本。
• 文中介绍了如何安装Phoenix以及使用对hbase进行更新操作。