1.hbase入门概念整理

1.数据结构  ，传统的表和hbase表对应的一个例子

    通过将一个关系型转化为HBase表来了解HBase的数据模式。以博客表和作者表之间的关系为例。

    上传图片太麻烦，略过

2、基础概念

·Row key（主键）

   行主键，hbase行中的数据根据行键排序，排序根据字节序进行，所有对表的访问通过行健。

·ColumnFamily（列族）

行中的列分为列族，列族下面的成员为列，同一列族下面的列具有相同的前缀。列族必须是由可打印的字符组成，且在建表的时候在表模式中预先给出。列族下面的列可以按需提供。

·Column（列）

Hbase中的列属于一个列族，以列族名为前缀。如article:title,article:content,列不用在创建时定义，可以动态新增，同一个Columns中的column会聚集在一个存储单元，并且以Column key排序，在设计的时候应该将相同I/O特性的Column设计在同一个列族上。

·Timestamp

   HBase通过row和column确定一份数据，一份数据可能保留多个版本，版本通过timestamp来区分，不同版本值按时间倒序排序，查询时默认返回最新的版本。

·Value

   每个值通过4个键唯一索引，tableName+RowKey+ColumnKey+TimeStamp -->value，

，例如上例中

{tableName=’blog’,RowKey=’1’,ColumnName=’author:nickname’,Timestamp=’ 1317180718830’}索引到的唯一值是“yedu”。

·存储类型

  TableName是字符串

  Rowkey和ColumnName是二进制值（java类型是byte[]）

  Timestamp 是64位整数（java是long类型）

  value 是一个字节数组（Java类型 byte[]）。

·存储结构

  HTable按Row key自动排序，Row中包含任意个Columns，Columns按照Column key排序，简单的理解如下

3、HBase使用场景

·半结构化或者非结构化数据

对于数据结构字段不够确定或杂乱无章很难按一个概念去进行抽取的数据适合用HBase。以上面的例子为例，当业务发展需要存储author的email，phone，address信息时RDBMS需要停机维护，而HBase支持动态增加。

·记录非常稀疏

RDBMS的行有多少列是固定的，为null的列浪费了存储空间。而如上文提到的，HBase为null的Column不会被存储，这样既节省了空间又提高了读性能。

·多版本数据

如上文提到的根据Row key和Column key定位到的Value可以有任意数量的版本值，因此对于需要存储变动历史记录的数据，用HBase就非常方便了。比如上例中的author的Address是会变动的，业务上一般只需要最新的值，但有时可能需要查询到历史值。

·超大数据量

当数据量越来越大，RDBMS数据库撑不住了，就出现了读写分离策略，通过一个Master专门负责写操作，多个Slave负责读操作，服务器成本倍增。随着压力增加，Master撑不住了，这时就要分库了，把关联不大的数据分开部署，一些join查询不能用了，需要借助中间层。随着数据量的进一步增加，一个表的记录越来越大，查询就变得很慢，于是又得搞分表，比如按ID取模分成多个表以减少单个表的记录数。

经历过这些事的人都知道过程是多么的折腾。采用HBase就简单了，只需要加机器即可，HBase会自动水平切分扩展，跟Hadoop的无缝集成保障了其数据可靠性（HDFS）和海量数据分析的高性能（MapReduce）。

      以淘宝的业务情况为例分析，淘宝在2011年之前所有的后端持久化存储基本上都是在mysql上进行的(不排除少量oracle/bdb/tair/mongdb等)，mysql由于开源，并且生态系统良好，本身拥有分库分表等多种解决方案，因此很长一段时间内都满足淘宝大量业务的需求。
   但是由于业务的多样化发展，有越来越多的业务系统的需求开始发生了变化。一般来说有以下几类变化：

· 数据量变得越来越多，事实上现在淘宝几乎任何一个与用户相关的在线业务的数据量都在亿级别，每日系统调用次数从亿到百亿都有，且历史数据不能轻易删除。这需要有一个海量分布式文件系统，能对TB级甚至PB级别的数据提供在线服务【海量】

· 数据量的增长很快且不一定能准确预计，大多数应用系统从上线起在一段时间内数据量都呈很快的上升趋势，因此从成本的角度考虑对系统水平扩展能力有比较强烈的需求，且不希望存在单点制约【扩展性好】

· 只需要简单的kv读取，没有复杂的join等需求。但对系统的并发能力以及吞吐量、响应延时有非常高的需求，并且希望系统能够保持强一致性【业务逻辑简单】

· 通常系统的写入非常频繁，尤其是大量系统依赖于实时的日志分析【读写频繁】

· 希望能够快速读取批量数据【批量】

· schema灵活多变，可能经常更新列属性或新增列【schema多变】

· 希望能够方便使用，有良好且语义清晰的java接口

以上需求综合在一起，hbase是一种比较适合的选择。首先它的数据由hdfs天然地做了数据冗余，云梯三年的稳定运行，数据100%可靠己经证明了hdfs集群的安全性，以及服务于海量数据的能力。其次hbase本身的数据读写服务没有单点的限制，服务能力可以随服务器的增长而线性增长，达到几十上百台的规模。LSM-Tree模式的设计让hbase的写入性能非常良好，单次写入通常在1-3ms内即可响应完成，且性能不随数据量的增长而下降。region（相当于数据库的分表）可以ms级动态的切分和移动，保证了负载均衡性。由于hbase上的数据模型是按rowkey排序存储的，而读取时会一次读取连续的整块数据做为cache，因此良好的rowkey设计可以让批量读取变得十分容易，甚至只需要１次io就能获取几十上百条用户想要的数据。最后，淘宝大部分工程师是java背景的同学，因此hbase的api对于他们来说非常容易上手，培训成本相对较低。

    当然也必须指出，hbase本身也有不适合的场景。比如，索引只支持主索引（或看成主组合索引），又比如服务是单点的，单台机器宕机后在master恢复它期间它所负责的部分数据将无法服务等。这就要求在选型上需要对自己的应用系统有足够了解。