HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。
适合于存储大表数据（表的规模可以达到数十亿行以及数百万列），并且对大表数据的读、写访问可以达到实时级别；
利用Hadoop HDFS（Hadoop Distributed File System）作为其文件存储系统，提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统；
利用ZooKeeper作为协同服务。
与RMDB比较：
HBase
分布式存储，面向列。
动态扩展列。
普通商用硬件支持，扩容成本低。
RMDB
数据结构固定。
需要预先定义好数据结构。
需要大量IO，扩展成本大。
HBase适合具有如下需求的应用：
海量数据（TB、PB）
高吞吐量
需要在海量数据中实现高效的随机读取
需要很好的性能伸缩能力
能够同时处理结构化和非结构化的数据
不需要完全拥有传统关系型数据库所具备的ACID特性
数据结构介绍：
- 结构化数据
-
具有固定的结构，属性划分，以及类型等信息。我们通常所理解的关系型数据库中所存储的数据信息，大多是结构化数据， 如职工信息表，拥有ID、Name、Phone、Address等属性信息。
通常直接存放在数据库表中。数据记录的每一个属性对应数据表的一个字段。 - 非结构化数据
-
无法用统一的结构来表示，如文本文件、图像、视频、声音、网页等信息。
数据记录较小时(如KB级别)，可考虑直接存放到数据库表中（整条记录映射到某一个列中），这样也有利于整条记录的快速检索。
数据较大时，通常考虑直接存放在文件系统中。数据库可用来存放相关数据的索引信息。 - 半结构化数据
-
具有一定的结构，但又有一定的灵活可变性。典型如XML、HTML等数据。其实也是非结构化数据的一种。
可以考虑直接转换成结构化数据进行存储。
根据数据记录的大小和特点，选择合适的存储方式。这一点与非结构化数据的存储类似。 - 行列存储：
- 按行存储：
-
数据按行存储在底层文件系统中。通常，每一行会被分配固定的空间。
优点：有利于增加/修改整行记录等操作；有利于整行数据的读取操作；
缺点：单列查询时，会读取一些不必要的数据。 - 按列存储：
-
数据以列为单位，存储在底层文件系统中。
优点：有利于面向单列数据的读取/统计等操作。
缺点：整行读取时，可能需要多次I/O操作。
主键设置规则：
Secondary Index
HBase是一个Key-Value类型的分布式存储数据库。每张表的数据，是按照RowKey的字典顺序排序的，因此，如果按照某个指定的RowKey去查询数据，或者指定某一个RowKey范围去扫描数据时，HBase可以快速定位到需要读取的数据位置，从而可以高效地获取到所需要的数据。
在实际应用中，很多场景是查询某一个列值为XXX的数据。HBase提供了Filter特性去支持这样的查询，它的原理是：按照RowKey的顺序，去遍历所有可能的数据，再依次去匹配那一列的值，直到获取到所需要的数据。可以看出，可能仅仅为了获取一行数据，它却扫描了很多不必要的数据。因此，如果对于这样的查询请求非常频繁并且对查询性能要求较高，使用Filter无法满足这个需求。
这就是HBase二级索引产生的背景。二级索引为HBase提供了按照某些列的值进行索引的能力。 
一般HBase的查询都是通过RowKey(要把多条件组合查询的字段都拼接在RowKey中显然不太可能)，或者全表扫描再结合过滤器筛选出目标数据(太低效)，所以通过设计HBase的二级索引来解决这个问题。
对于HBase而言，如果想精确地定位到某行记录，唯一的办法是通过rowkey来查询。如果不通过rowkey来查找数据，就必须逐行地比较每一列的值，即全表扫瞄。对于较大的表，全表扫瞄的代价是不可接受的。
但是，很多情况下，需要从多个角度查询数据。例如，在定位某个人的时候，可以通过姓名、身份证号、学籍号等不同的角度来查询，要想把这么多角度的数据都放到rowkey中几乎不可能（业务的灵活性不允许，对rowkey长度的要求也不允许）。
所以，需要secondary index来完成这件事。secondary index的原理很简单，但是如果自己维护的话则会麻烦一些。现在，Phoenix已经提供了对HBase secondary index的支持，下面将说明这样用Phoenix来在HBase中创建二级索引。
create index my_index on example (m.c0);
HBase FileStream
HBase文件存储模块（HBase FileStream，简称HFS）是HBase的独立模块，它作为对HBase与HDFS接口的封装，应用在FusionInsight HD的上层应用，为上层应用提供文件的存储、读取、删除等功能。
在Hadoop生态系统中，无论是HDFS，还是HBase，均在面对海量文件的存储的时候，在某些场景下，都会存在一些很难解决的问题：
如果把海量小文件直接保存在HDFS中，会给NameNode带来极大的压力。
由于HBase接口以及内部机制的原因，一些较大的文件也不适合直接保存到HBase中。
HFS的出现，就是为了解决需要在Hadoop中存储海量小文件，同时也要存储一些大文件的混合的
场景。简单来说，就是在HBase表中，需要存放大量的小文件（10MB以下），同时又需要存放一
些比较大的文件（10MB以上）。
HFS为以上场景提供了统一的操作接口，这些操作接口与HBase的函数接口类似。
注意事项
如果只有小文件，确定不会有大文件的场景下，建议使用HBase的原始接口进行操作。
HFS接口需要同时对HBase和HDFS进行操作，所以客户端用户需要同时拥有这两个组件的操作权限。
直接存放在HDFS中的大文件，HFS在存储时会加入一些元数据信息，所以存储的文件不是直接等于原文件的。不能直接从HDFS中移动出来使用，而需要用HFS的接口进行读取。
使用HFS接口存储在HDFS中的数据，暂不支持备份与容灾。 
HBASE+Solr全文检索
背景
某电信项目中采用HBase来存储用户终端明细数据，供前台页面即时查询。HBase无可置疑拥有其优势，但其本身只对rowkey支持毫秒级的快速检索，对于多字段的组合查询却无能为力。针对HBase的多条件查询也有多种方案，但是这些方案要么太复杂，要么效率太低，本文只对基于Solr的HBase多条件查询方案进行测试和验证。
原理
基于Solr的HBase多条件查询原理很简单，将HBase表中涉及条件过滤的字段和rowkey在Solr中建立索引，通过Solr的多条件查询快速获得符合过滤条件的rowkey值，拿到这些rowkey之后在HBASE中通过指定rowkey进行查询。 
HBase与Solr系统架构设计
使用HBase搭建结构数据存储云，用来存储海量数据；使用SolrCloud集群用来搭建搜索引擎，将要查找的结构化数据的ID查找出来，只配置它存储ID。 
wd代表用户write data写数据，从用户提交写数据请求wd1开始，经历wd2，写入MySQL数据库，或写入结构数据存储云中，wd3，提交到Solr集群中，从而依据业务需求创建索引。
rd代表用户read data读数据，从用户提交读数据请求rd1开始，经历rd2，直接读取MySQL中数据，或向Solr集群请求搜索服务，rd3，向Solr集群请求得到的搜索结果为ID，再向结构数据存储云中通过ID取出数据，最后返回给用户结果。
实现方法有两种
手工编码，直接用HBASE的API，可以参考下文
http://www.cnblogs.com/chenz/articles/3229997.html
可以使用HBASE/Solr的LUNA接口，就不用自己管理两者。 
