HBase is a distributed column-oriented database built on top of HDFS. HBase is the Hadoop application to use when you require real-time read/write random access to very large datasets.

Applications store data into labeled tables. Tables are made of rows and columns. Table cells—the intersection of row and column coordinates—are versioned. By default, their version is a timestamp auto-assigned by HBase at the time of cell insertion. A cell’s content is an uninterpreted array of bytes. Table row keys are also byte arrays, so heoretically anything can serve as a row key, from strings to binary representations of long or even serialized data structures. Table rows are sorted by row key, the table’s primary key. The sort is byte-ordered. All table accesses are via the table primary key.2 Row columns are grouped into column families. All column family members have a common prefix, so, for example, the columns temperature:air and tempera-ture:dew_point are both members of the temperature column family, whereas station:identifier belongs to the station  amily.3 The column family prefix must be com-posed of printable characters. The qualifying tail, the column family qualifier, can be made of any arbitrary bytes.

A table’s column families must be specified up front as part of the table schema definition, but new column family members can be added on demand. For example, a new column station:address can be offered by a client as part of an update, and its value persisted, as long as the column family station is already in existence on the targeted

table.Physically, all column family members are stored together on the filesystem. So although earlier we described HBase as a column-oriented store, it would be more

accurate if it were described as a column-family-oriented store. Because tunings and storage specifications are done at the column-family level, it is advised that all column

family members have the same general access pattern and size characteristics.In synopsis, HBase tables are like those in an RDBMS, only cells are versioned, rows

are sorted, and columns can be added on the fly by the client as long as the column family they belong to preexists.

 

Internally, HBase keeps special catalog tables named -ROOT- and .META., within which it maintains the current list, state, and location of all regions afloat on the cluster. The

-ROOT- table holds the list of .META. table regions. The .META. table holds the list of all user-space regions. Entries in these tables are keyed by region name, where a region

name is made of the table name the region belongs to, the region’s start row, its time of creation, and finally, an MD5 hash of all of the former

 

1 我们常说HBase是“数据即日志”的数据库，它是怎样修改和删除数据的？和Oracle这类传统的RDBMS有什么区别？ 

答：首先Hbase中的一个“元素”是由行键、列族名、限定符、时间戳唯一标识的并且行键作为数据行在表里的唯一标识，我们只有通过行键来访问列族别无他法。

修改数据：我们先找到要修改的行键把新的数据记录追加到对应的列族中并打上一个新时间戳代表最新版本。

删除数据：插入带有删除标记的行进入，相当于把整个行键所在的行删了。

小结：hbase中所有修改和删除都是用insert方式来完成的，这是由底层HDFS文件系统特性决定的，HDFS中的文件只能一次性写入不能修改可以删除在写回。因此hbase是天生面向时间查询的数据库。例如 查询最近一段时间一个人发布的博客、发布签名、发布照片so on。

hbase特点

(1)适合大量插入同时key-value查询，例如可以输入一个key查询一个value，还可以输入一组key查询一组value。

(2)瓶颈是硬盘的传输速度，因为有大量的插入操作和读出操作，使用SSD  SCSI  IDE不同的硬盘效率是不同的。

(3)适合数据分析。

(4)列式数据库会把相同列的数据都放在一块即列为单位存储。当我们查询某一列的时候只需要调出相应的块即可，这样还可以减少很多I/O。

(5)如果数据元素间的相似性很高的话可以进行大幅度的压缩，相似度越高压缩比越大，甚至可以压缩到原来十几分之一、上百分之一。即节约了空间又减少了I/O，从而提高性能。

(6)hbase只有主键索引，它使用的是LSM（Log Structure Merge）索引，因为hbase所有的修改都是使用追加方式完成的，从数据流上看按照顺序方式写入与日志写入的方式相同，我们又可以认为数据和日志一体化，这又节约了很多空间。

oracle特点

(1)适合小事务短时间片密集型OLTP系统，例如在线交易系统。

(2)瓶颈是硬盘的寻道时间（磁头移动时间），因为oracle随机写随机修改块，首先要找到块这个过程就是寻道时间，而寻道时间又由硬盘转速决定的，5400 7200 15000转/秒 不同的转速效率也是不同的。

(3)适合做SQL统计。

(4)行式数据库会按照数据行顺序集中存放即行为单位存储。当我们查询某一列的时候必须把表里所有的行读完才能抽取我们所要的行，这样很不划算，还要付出很大的I/O资源。

(5)那么从结构上讲oracle的压缩性能就要略逊一筹。

(6)oracle常用的是B+树索引，比较大小来查找记录，小的走左边大的走右边，如果列中的相似度较高的话性能较差。

2 HBase合并storefile的原因是什么？在合并的过程中会做什么操作？如果在合并过程中恰好有涉及到有关storefile的查询发生，会发生什么情况！

答：首先我们介绍一下Hbase数据存储的物理结构

一个物理节点只能跑一个HRegionserver

一个HRegionServer可以包括很多个Region实例，可以是不同表Region

一个Region包含一个hlog和多个store（一个store就是一个列族，因为同列族元素在物理上存放在同一个地方，不同列族在物理上是分离的）

一个store包含一个memstore和多个storefile

当我们在处理数据的时候，首先把数据加载到memstore，数据越来越多直到memstore占满，再写入硬盘storefile中，每次写入形成一个单独storefile，当storefile达到一定的数量后，就会开始把小storefile合并成大storefile，因为hadoop不擅长处理小文件，文件越大性能越好。

在合并的过程中会抛弃删除标识的行和版本过旧的行（hbase版本抛弃方式（1）我们可以预先定义版本的个数，超过这个值就抛弃（2）还可以预先定义版本的时间长短，超过这个时间就抛弃），合并完后形成更大的storefile，当达到数量再次合并，直到storefile容量超过一定阀值后会把当前的Region进行分裂为2个并由Hmaster（hbase数据库主控节点）分配到不同的HRegionServer服务器处理实现负载均衡。

如果在合并过程中恰好有涉及到有关storefile的查询发生的话，我们先是把小storefile加载到内存中进行合并此时如有用户访问可以在内存中检索相关数据返回给用户，我们可以想象在内存中做一个独立镜像备份专门提供被查询需求，另一个主体在另一块内存空间里进行合并，当合并完成后释放备份的内存空间，返回到原来的状态。

 

3 Hbase具有怎么样的一致性水平

答：hbase是最终一致性的系统，因为hbase是架构在hadoop之上的数据库，“错误是常态”是hadoop座右铭，在cap理论中hbase为了满足可用性和分区容错性牺牲了一部分的数据一致性。

举例：我们要进行电信的指标汇总，并且把汇总结果冗余三份分布在3个datanode中，我们可以设置阀值只要有2份结果保存了我们就可以继续做下面的操作，在一定时间范围内允许第3份结果稍后一致性同步，这就是最终一致性。所以说hbase是适用于AP理论的系统，最终一致性也满足分布式集群的特点。