(一)起源及定位

HBase理论知识起源于Google发表的BigTable论文，Google使用其BigTable系统存储从互联网抓取的网页副本(不断更新)，然后通过MapReduce批量处理为这些网页建立索引，供WEB搜索使用。

HBase建立在Hadoop之上，Hadoop理论知识起源于GFS和MapReduce，与BigTable一起构成Google网页搜索业务的技术基础设施。Hadoop与HBase搭档自然适合用于建设网页搜索系统，但并不限于此，它们能在许多大数据情境下发挥重要作用。

Hbase是一种数据库：Hadoop数据库，一个可以随机访问的存储和检索数据的平台。它经常被描述为一种持久化的、分布式的、多维有序映射的、稀疏的，基于行键(row key)、列键(column key)、时间戳(timestamp)建立索引。它也经常被描述为键值(key-value)存储、面向列族的数据库，也是一种能自动保留数据多个历史版本(时间戳)数据库。列族数据库是一种兼顾数据操作(OLTP)和数据分析(OLAP)的数据库。列族数据库逻辑结构常被描述为二级映射(Row Key - Column Key - Cell Value)数据库。有关列族数据更多讨论参考《》

(二)数据模型与基本操作

HBase数据库由一组表构成，不同表的数据结构是一样的，都是五元组<行键、列族、列限定符、时间戳、单元值>。参考下面来自于<<HBase In Action>>中的图所示。

对照关系数据库(RDB)术语，行键对应RDB主键。列族对应RDB中1:1关系的垂直分表，不同列族对应不同的存储文件。列对应RDB表字段的“列“，不过HBase把RDB的列放置到行上，这样操作非常适合存储稀疏矩阵(sparse）：表中多数内容为空，只有少数内容有值。时间戳是HBase的一个特色，用于标识和区分存储数据的多个历史版本。

行键作为行记录的主键不能重复，列限定符在行内不能重复，<行键、列限定符、时间戳>是物理排序的唯一索引，其中时间戳是倒序排列。

HBase按照<行键、列限定符、时间戳>排序后顺序存储的特性，便于快速读取行键临近数据，这种特性是否有助于数据分析，则依赖于行键设计。

HBase提供的基本操作主要包括Get、Put、Delete、Scan、Increment指令，另外提供Observer(类似于RDB的触发器)、Endpoint(类似于RDB的存储过程)支持联机处理和MapReduce支持批量分析。

这里比较特殊的指令是Scan，扫描获得一段行键范围内的记录。根据列族数据库的特点，这些记录被连续有序地存储在列族文件中。

为了减少Scan的数据传输，可以为命令提供过滤条件，过滤条件类似于RDB中SQL的Where条件但更灵活，毕竟直接采用Java代码实现。

同样Observer和Endpoint也是用Java实现，比起RDB中使用SQL扩展的私有语言，Java更灵活强大，注:有些RDB也支持使用Java撰写存储过程。

用完整能力的开发语言扩展数据库能力是一件非常有意义的事情，利用已有的成果和强大的能力、广泛的用户群，无需要重复造轮子。如果采用开发数据库平台的兼容语言(例如都运行于JVM)，则方便地集成和低成本计算，避免各类数据转换和环境切换。

(三)数据模式设计

数据库存储数据之前需要先设计数据模式，回答以什么样的结构和格式存储什么东西，如何管理及访问数据等。RDB和HBase设计数据模式的核心概念如下图所示。

RDB数据模式设计

图中左侧是关系数据模式设计方法，业务分析追求逻辑上的完整、清晰、准确，模型强调业务实体以及实体之间的关系，强调完整(包括全部内容)和一致(所有应用、服务看到同样的数据结构)。

为RDB设计数据模式，业界拥有标准化的规范方法、丰富的实践经验。这得益于RDB数据模型建立在关系运算之上，一组简单的、规范的、可自由连接的二维表格。更得益于RDB对数据访问方式不做要求，随机访问、批量访问、还是跨多表的组合访问都非常方便，数据库系统自动优化访问路径，提供完善的事务控制。

HBase数据模式设计

图中右侧是HBase的数据模式设计方法，HBase是一个全新物种，采用完全不同于RDB的设计方法。

HBase这种列族数据库无论在理论研究、应用经验上都无法与RDB相提并论，但它能解决RDB不能支撑的数据规模。

为了解决数据的“大”、模式演进等问题，HBase没有提供组合访问能力(数据join和事务控制)，数据随机访问和批量访问也做了许多限制：只能通过行键进行。如何访问HBase中的数据成为应用数据模式设计的关键。

HBase的列族数据模型直接影响了业务分析方法：从业务的主要问题入手，而不是业务的完整的实体关系。通过分析用户主要活动，获得应用系统的主要访问方式，应用系统的访问方式决定HBase数据库表的访问方式，进一步决定表行键的结构、列和单元值的内容。

HBase行键设计

数据模式设计如果有唯一重要的事情，一定是行键，它决定了随机访问和批量访问的便利和性能，影响数据存储的效率。为了设计便于数据访问行键，往往需要综合运用这里的多种方法。

• 随机访问场景需要防止读/写热点，维护行键离散以便把数据分散到不同节点。

• 离线分析场景需要连续读写，维护行键有序以便把数据放到一起。

• 定长行键有助于行键组合/分割、随机行键有助于随机访问分散、有序行键有助于数据顺序读取、更短的行键有助于缩小存储空间。

• 常用行键候选包括顺序字段、业务字段、组合字段、时间戳、随机数、字段Hash、salt前缀等。

HBase模式设计经验

• 数据规模是第一本质性要素。

• 规范化利于写性能但不利于读性能，反规范化则相反，HBase需要比RDB更多地利用反规范化。把相关信息聚合到一个记录，甚至聚合到一个单元值是常用的方法。注：每个单元值都有完整的坐标，如果把RDB表的列映射到HBase的表列，则更多的坐标占用更多存储空间。

• 字符串数组(字节流)可以存储任何东西，行键、列限定符、单元值均如此。

• 列限定符占用存储空间，建议用更短的列名；列限定符自身可以用于存储数据，就像数据单元一样，这一点类似于JSON格式。

• 同一列族存储同一访问模式的所有东西，列族名长度不影响存储空间但影响网络IO。

• 高表利于随机访问但降低原子性和聚合访问，宽表则反之。高表指多用行键编码更多内容来定位细粒度数据，宽表则多用行键+列限定符定位数据。

• 尽量能否在单个API调用完成访问模式，HBase不支持跨行事务控制。

与关系数据模型映射

所有设计最终都应该来自于业务需求，而不是另一个数据模型。无论是上层的业务模型驱动下层的逻辑数据模型，还是底层的存储数据模型影响上层的逻辑数据模型，都是建立在同一个前提下：更简单有效地解决客户问题。

如果决定用HBase作为应用的存储，那么设计数据模式时就应该使用HBase的方式来思考(Thinking in HBase)，而不是使用关系数据库的方式。事实上选择HBase一定是因为它更善于解决应用的关键问题(通常是规模和随机访问)，且没有阻碍应用落地的重要限制。

仍然有一些与RDB有关联的需求或者你想运用一些关系知识，例如使用HBase搭建数据源为RDB的数据仓库，使用SQL对HBase库进行数据分析等。这些情况下设计HBase数据模型就需要考虑RDB的特点，这种情况下关系模型友好是需求的一部分。

模式设计根本是模型映射

数据模式设计的本质是映射业务需求到数据库存储模型。如果业务模型与存储模型差异很大，就需要大量的代码用于处理访问和转换，这违背了更简单有效地解决问题的初衷。

架构设计选用更适合分析解决业务问题的模型方法，同样需要选用适合落实业务模型的存储模型，这样模映射起来自然简单。

由于模型是对现实世界的抽象思考，往往可以有多种方法进行 (尽管可能有一种方法会更好）。如果采用的某个工具是前提(比如这里的HBase），尽量使用工具的模型思考待解决的问题就会比较好。更多模型映射的讨论请参考《》

    (四)适合的应用场景

对象数据存储

数据历史存储

单元值可以自动存储多个历史版本、以列族为单位控制保留版本数和TTL保存周期，适合用于存储数据的历史版本。列族压缩和有序存储便于大幅度减少存储空间和历史版本读取性能。Google用于存储爬取网页的历史。企业可以用于存储需要跟进变更历史的情景，如文档修订历史、单据审批历史等。

大数据存储

HBase适合处理规模非常大的情景，例如监控日志、行为采集、博客网站等。

大数据平台底层是计算机集群，集群的本质是通过分工来承担更大的存储/计算量，而简单独立的事情更便于分工。数据量不大但逻辑复杂的事情，RDB要比大数据存储合适；但数据量大且逻辑复杂的事情，还是需要大数据存储，通过服务分治等降低复杂性。

HBase起源于搜索引擎，它适合在多少领域范围内作为数据库使用，这是个难于回答的问题。这依赖于其自身的通用性和易用性，更依赖于待解决问题的可用方案候选，这不是谁能胜任而是谁能胜出的问题。与擅长横向扩展的另外两类数据库系统相比，键值数据库代表产品Redis和文档数据库代表产品MongoDB在各自领域获得广泛应用且取得领导地位，HBase的最大优势恐怕还是与Hadoop的无缝整合，便于进一步与其它大数据分析工具整合。

无论您有什么相关想法或建议，欢迎一起探讨。

（本文完）