HBASE数据库介绍：
hbase是bigtable的开源java版本，是建立在hdfs之上，提供高可靠性，高性能，列存储，可伸缩，实时读写nosql的分布式数据库系统，它介于nosql和RDBMS之间，仅能通过主键(row key)和主键的range来检索数据，仅支持单行事务（可通过hive支持来实现多表join等复杂操作）
主要用来存储结构化和半结构化的松散数据
HBASE查询数据功能很简单，不支持join等复杂操作，不支持复杂的事务（行级的事务）
hbase中支持的数据类型： byte[]
与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力
思想：hbase软件如果只有一个，那么所有的数据操纵都要经过它，那么查询速度会很慢。我们说hbase是分布式的数据库并不是说他的文件存储在hdfs上就是分布式的，而是这个软件本身就是分布式的。那就意味着这个软件就可以在很多台机器上运行。这个时候就会有一个问题。如果客户端发出一条语句。那么哪个软件帮我们查询？
首先理清以下思路：我们要查询数据的话肯定要查询一个表。那我们能不能这样呢？一个hbase负责不同的表，我们查询不同的表就去找不同的服务器。但是这样也不好。
hbase的设计思想就是：这个表可以很大，可能我整个系统一张表就够了。所有的数据都在一张表中，可能有几十亿行，几百万列。数据量可能达到几十个T,那这样就意味着，有很多个查询的时候依然会很慢。
这个时候，我们就需要将表拆开。若干行作为一个片，那么这张表就可以分成很多子范围。就像下面这样：
这样不同的用户就会去查询不同范围内的数据。但是也有一种可能，在某一个时间段，大量的用户都去查询同一个范围的数据，这样就没办法了。
还有一个点，我们说0-10000的数据的查询交给第一台服务器，那是不是就是说0-10000的数据存在这台服务器上了？不是的，它是不过是负责这个范围而已，真正的数据是存在hdfs中的。这样就会有一个好处。假如我们这台服务器挂掉了。我们可以重新指派范围给另外一台服务器。服务器负责的只是功能，而不是数据。
还有一个问题，如果数据只是存在hdfs中的话，查询就会很慢，那么hbase就会变成和hive一样的东西了，慢的要死。那这样就不行了，因为数据库是要做即时查询的。那么怎么办呢？我们可以在内存中放一个缓存。hbase帮我们找文件的时候，这个文件绝对不是一个普通的文本文件。而是一个经过精心组织的文件。它去找的时候还是比较快的。像mysql的表也是放在磁盘文件中的。但是它查询起来一点也不慢为什么呢？因为它的文件是有固定格式的。查询的时候会迅速定位。但是毕竟是磁盘文件传输还是有点慢。
那么我们就这样做，第一次查的时候，从磁盘文件中查，然后就放到缓存。下次再查的时候，就直接从缓存中拿。
如果我们要插入数据呢？这个时候我们就要知道，hdfs是不提供数据的修改功能的。我们顶多是在文件的后面追加。所以我们可以直接将数据插入缓存。这样下次查询就会很快。可是这样还存在问题，我们插入缓存，就和磁盘中的数据不一致了。假如服务器宕机了，就会连数据一起丢掉。所以我们还要记录操作日志到hdfs,记录日志就是追加的。万一一台服务器挂了，我们可以在另一台服务器重放日志，加载文件。就能得到新数据，还在内存中有。但是这个加载过程会很长，万一这台服务器运行了好几个月，就会需要很长时间。那怎么办？我们可以将日志里面的文件定期合并。把日志里的操作合并到文件中。合并文件当然不可能改文件。我们会将文件读进来再根据重放日志生成新的文件，然后老文件就不要了。当然，每台服务器只会负责各自范围内的数据的合并。
上图中的每台服务器就叫region server,一个表划分出一个范围就是region,每个region server负责一些region,但是一个region只会交给一台服务器去管理。注意：这里region server对region的管理只是功能性的管理，数据还是存在hdfs中的。
那这么多region server总要一个统领吧，万一有一台挂了，总要有另一台去管理吧。
所以我们还有一台服务器去管理，叫HMaster,它只负责管理region server.
但是它的管理机制与namenode管理datanode的机制不同。datanode一上线就会向namenode报告，告诉他自己上线了，自己身上有哪些block块。
而region server是不会向HMaster报告的。但是他们可以通过zookeeper协调。region server可以将自己的信息写道zookeeper中，而HMaster可以监听。一旦region server有新的变化，就可以往zookeeper中写，而HMaster就可以读到。之后就可以发出一些指令，指挥他们的操作。