适用场景
在介绍完了HBase的数据模型以后,我们可以回答本文一开始的前两个问题:
- 什么样的数据适合用HBase来存储?
- 既然HBase也是一个数据库,能否用它将现有系统中昂贵的Oracle替换掉?
HBase的数据模型比较简单,数据按照RowKey排序存放,适合HBase存储的数据,可以简单总结如下:
- 以实体为中心的数据
实体可以包括但不限于如下几种:
-
自然人/账户/手机号/车辆相关数据
-
用户画像数据(含标签类数据)
-
图数据(关系类数据)
描述这些实体的,可以有基础属性信息、实体关系(图数据)、所发生的事件(如交易记录、车辆轨迹点)等等。
-
以事件为中心的数据
-
监控数据
-
时序数据
-
实时位置类数据
-
消息/日志类数据
上面所描述的这些数据,有的是结构化数据,有的是半结构化或非结构化数据。HBase的“稀疏矩阵”设计,使其应对非结构化数据存储时能够得心应手,但在我们的实际用户场景中,结构化数据存储依然占据了比较重的比例。由于HBase仅提供了基于RowKey的单维度索引能力,在应对一些具体的场景时,依然还需要基于HBase之上构建一些专业的能力,如:
-
OpenTSDB 时序数据存储,提供基于Metrics+时间+标签的一些组合维度查询与聚合能力
-
GeoMesa 时空数据存储,提供基于时间+空间范围的索引能力
-
JanusGraph 图数据存储,提供基于属性、关系的图索引能力
HBase擅长于存储结构简单的海量数据但索引能力有限,而Oracle等传统关系型数据库(RDBMS)能够提供丰富的查询能力,但却疲于应对TB级别的海量数据存储,HBase对传统的RDBMS并不是取代关系,而是一种补充。
HBase与HDFS
我们都知道HBase的数据是存储于HDFS里面的,相信大家也都有这么的认知:
HBase是一个分布式数据库,HDFS是一个分布式文件系统
理解了这一点,我们先来粗略回答本文已开始提出的其中两个问题:
- HBase中的数据为何不直接存放于HDFS之上?
HBase中存储的海量数据记录,通常在几百Bytes到KB级别,如果将这些数据直接存储于HDFS之上,会导致大量的小文件产生,为HDFS的元数据管理节点(NameNode)带来沉重的压力。
- 文件能否直接存储于HBase里面?