Hbase学习（五）-hbase常识及habse适合什么场景，hbase-hbase

Hbase学习（五）-hbase常识及habse适合什么场景，hbase-hbase

8.value 是什么类型？

带着以上几个问题去读下面内容：

引言

团队中使用HBase的项目多了起来，对于业务人员而言，通常并不需要从头搭建、维护一套HBase的集群环境，对于其架构细节也不一定要深刻理解（交由HBase集群维护团队负责），迫切需要的是快速理解基本技术来解决业务问题。最近在XX项目轮岗过程中，尝试着从业务人员视角去看HBase，将一些过程记录下来，期望对快速了解HBase、掌握相关技术来开展工作的业务人员有点帮助。我觉得作为一个初次接触HBase的业务开发测试人员，他需要迫切掌握的至少包含以下几点：
深入理解HTable，掌握如何结合业务设计高性能的HTable

掌握与HBase的交互，反正是离不开数据的增删改查，通过HBase Shell命令及Java Api都是需要的

掌握如何用MapReduce分析HBase里的数据，HBase里的数据总要分析的，用MapReduce是其中一种方式

掌握如何测试HBase MapReduce，总不能光写不管正确性吧，debug是需要的吧，看看如何在本机单测debug吧



本系列将围绕以上几点展开，篇幅较长，如果是HBase初学者建议边读边练，对于HBase比较熟练的，可以选读下，比如关注下HBase的MapReduce及其测试方法。

从一个示例说起

传统的关系型数据库想必大家都不陌生，我们将以一个简单的例子来说明使用RDBMS和HBase各自的解决方式及优缺点。
以博文为例，RDBMS的表设计如下：


 

为了方便理解，我们以一些数据示例下

 

上面的例子，我们用HBase可以按以下方式设计

 

同样为了方便理解，我们以一些数据示例下，同时用红色标出了一些关键概念，后面会解释

 


HTable一些基本概念

Row key

行主键， HBase不支持条件查询和Order by等查询，读取记录只能按Row key（及其range）或全表扫描，因此Row key需要根据业务来设计以利用其存储排序特性（Table按Row key字典序排序如1,10,100,11,2）提高性能。

Column Family（列族）

在表创建时声明，每个Column Family为一个存储单元。在上例中设计了一个HBase表blog，该表有两个列族：article和author。

Column（列）

HBase的每个列都属于一个列族，以列族名为前缀，如列article:title和article:content属于article列族，author:name和author:nickname属于author列族。
Column不用创建表时定义即可以动态新增，同一Column Family的Columns会群聚在一个存储单元上，并依Column key排序，因此设计时应将具有相同I/O特性的Column设计在一个Column Family上以提高性能。同时这里需要注意的是：这个列是可以增加和删除的，这和我们的传统数据库很大的区别。所以他适合非结构化数据。

Timestamp

HBase通过row和column确定一份数据，这份数据的值可能有多个版本，不同版本的值按照时间倒序排序，即最新的数据排在最前面，查询时默认返回最新版本。如上例中row key=1的author:nickname值有两个版本，分别为1317180070811对应的“一叶渡江”和1317180718830对应的“yedu”（对应到实际业务可以理解为在某时刻修改了nickname为yedu，但旧值仍然存在）。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的存储结构理解为

 

即HTable按Row key自动排序，每个Row包含任意数量个Columns，Columns之间按Column key自动排序，每个Column包含任意数量个Values。理解该存储结构将有助于查询结果的迭代。

话说什么情况需要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）。

如果要做的话。通常是使用hive（能够直接处理HBase中的数据），或者自己开发mapreduce程序；例子网上有很多。
你这个逻辑如果不很复杂，通过hive简单些，写几条语句就搞定。

另：
如果就是验证下功能，那做做没问题。要是生产的话基于HBase做分析基本不可用。
因为不管哪种方法都要查HBase表，数据多了这个效率你接受不了；多进程并发访问在服务端有缓存的情况下（通过一定条件过滤的场景）才能够达到几千条/秒，如果不做缓存（遍历整表时）只能达到每秒一两百条。慢的要死。
生产的话可以考虑使用hive基于HDFS文件做分析。
 

目前来说，我认为hbase版本还不稳定，使用起来还是会出现很多潜在的bug，你看看淘宝的使用经验就知道了，所以使用hbase的限制：1. 要有比较强大的IT团队，且有一定的nosq 库表的设计经验，否则你无法发挥hbase的性能优势2. hbase的 有效性还存在一定的问题(nosql CAP理论中的A），因为只要集群中的一个节点宕机了，这个节点上的数据暂时就不能访问了，需要等待一定的时间，进行同步处理，查询数据时，你会发现有部分缺失。当然，也有处理方法，淘宝就是找人专门盯着这些集群，以最快的速度恢复这些宕机的机器4. 查询简单，只能根据key,扫描一条记录，或全表扫描，或根据key范围性扫描，不支持复杂的sql处理，也不会具有关系型数据库的ACID特性.5. hbase基本上是采用hdfs作为存储，你使用hdfs,就得考虑它的 单几点问题，也就是HA问题，当然，目前版本好像提供了HA机制，但好不好用，还待验证总之，hbase目前还是存在很多问题的，想要用好它，你得自己考虑这些问题，且做增强，它还不算一个非常成熟的数据库，我猜想，后期版本会有大改