HBase 作为 Apache 基金会的 Hadoop 项目的一部分，将 HDFS 作为文件存储系统，使用 MapReduce 进行分布式的数据批量处理（非实时数据批量处理）、利用Zookeeper提供协同管理服务，为 Hadoop 提供海量数据管理服务，因此，HBase也是在一个服务器集群上运行的。
HBase主要适用于海量明细数据（十亿、百亿）的随机实时查询，如日志明细、交易清单、轨迹行为等。因此，实时数据查询和处理是HBase主要功能，用来进行数据实时计算的是Flink或sparkstreaming。
1. HBase优点
HBase=Hadoop Database，是一个高可靠性、高性能、面向列、高扩展性、稀疏的、由行键列键和时间戳进行索引的多维有序映射的分布式存储数据库。HBase与Hadoop的关系密不可分，HBase利用HDFS作为其文件存储系统、利用MapReduce来处理HBase中的海量数据、利用Zookeeper提供协同管理服务。
1.高容量、高性能、高扩展性
HBase 的单表可以有百亿行、百万列，可以在横向和纵向两个维度插入数据，具有很大的弹性，容量极高。
当关系型数据库的单个表的记录在亿级时，查询和写入的性能都会呈现指数级下降，这种庞大的数据量对传统数据库来说是一种灾难，而 HBase 在限定某个列的情况下对于单表存储百亿甚至更多的数据，保持高性能。
HBase可以通过部署廉价的服务器集群实现大规模数据存储，扩展性极高。
2.列存储
关系型数据库是面向行存储的，而HBase数据库面向列存储，如下图所示：
行存储，表的所有数据都放在一起，方便数据的插入与更新；但对于表数据查询，行存储会读取所有数据进行查询，但列存储只需要读取相应的查询列。因此，列存储对数据的交互式查询非常友好。
3.稀疏性
在关系型数据库中，每一列的数据类型和大小都必须事先定义，提前占用固定的存储空间。因此，当数据为NULL值时，依然会占用存储空间。
而 HBase 中的数据都是以字符串形式存储，为空的列并不占用存储空间，因此 HBase 的列存储解决了数据稀疏性的问题，在很大程度上节省了存储开销。
4.高可靠性
HBase利用HDFS作为其文件存储系统，HDFS的多副本存储保障数据存储的高容错性。同时，当HBase集群中当某个节点出现故障时，协调服务组件 ZooKeeper 通知集群的主节点，将故障节点的日志信息分发到各从节点进行数据恢复。
2. HBase应用场景
1.搜索引擎的应用
网络爬虫持续不断地从网络上抓取新页面，并将页面内容存储到 HBase 中，爬虫可以插入和更新 HBase 里的内容；然后，用户可以利用 MapReduce 在整张表上计算并生成索引，为网络搜索做准备；接着，用户发起搜索请求；最后，搜索引擎查询建立好的索引列表， 获取文档索引后，再从 HBase 中获取所需的文档内容，最后将搜索结果提交给用户。
2.广告效果和点击流
在线广告是互联网产品的一项主要收入来源。互联网企业提供免费服务给用户，在用户使用服务时投放广告给目标用户。这种精准投放需要针对用户交互数据做详细的捕获和分析，以理解用户的特征；再基于这种特征，选择并投放广告。企业可使用精细的用户交互数据建立更优的模型，进而获得更好的广告投放效果和更多的收入。
但这类数据有两个特点：它以连续流的形式出现，它很容易按用户划分。在理想情况下，这种数据一旦产生就能够马上使用。
HBase 非常适合收集这种用户交互数据，并已经成功地应用在相关领域。它可以增量捕获第 一手点击流和用户交互数据，然后用不同处理方式来处理数据，电商和广告监控行业都已经非常熟练地使用了类似的技术。
例如，淘宝的实时个性化推荐服务，中间推荐结果存储在 HBase 中，广告相关的用户建模数据也存储在 HBase 中，用户模型多种多样，可以用于多种不同场景，例如，针对特定用户投放什么广告，用户在电商门户网站上购物时是否实时报价等。
3. HBase在滴滴的典型应用场景
滴滴中有一些对HBase简单操作，例如Scan和Get。每一个操作可以应用于不同的场景，例如Scan可以衍生出时序和报表。时序可以应用到轨迹设计中，将业务ID、时间戳和轨迹位置作为整体建立时序。另外在资产管理中，将资产状态分为不同阶段，将资产ID、时间戳、资产状态等信息建立时序。Scan在报表中应用也非常广泛。其实现有多种方式，主流方法是通过phoenix，使用标准的SQL操作Hbase做联机事务处理，该方法中需要注意主键及二级索引设计。报表中会以用户历史行为、历史事件及历史订单为需求进行详细设计。
Get操作可以应用于HBase中存储的语音和滴滴发票等小文件中。最基本的应用方法为根据ID获取实体属性。更深入的例如可以应用于join操作，例如在实时计算中有多个数据流需要合并，此时的ID即为HBase中的rowkey。另例如业务上游存在多个数据源，需要将这多个数据源数据聚合至一个表中。
此外，HBase中仍衍生出一些其他操作。互联网公司需求变化快速，介入业务方众多，可以通过动态列帮助实现这类需求。另有一些综合应用，例如图和Coprocessor。图包括用户自定义的图，可以自定义数据来源与数据分配。HBase集群中也接入了JanusGraph。Coprocessor主要应用于Phoenix和GeoMesa。
HBase在滴滴主要存放了以下四种数据类型：
- 统计结果、报表类数据：主要是运营、运力情况、收入等结果，通常需要配合Phoenix进行SQL查询。数据量较小，对查询的灵活性要求高，延迟要求一般。
- 原始事实类数据：如订单、司机乘客的GPS轨迹、日志等，主要用作在线和离线的数据供给。数据量大，对一致性和可用性要求高，延迟敏感，实时写入，单点或批量查询。
- 中间结果数据：指模型训练所需要的数据等。数据量大，可用性和一致性要求一般，对批量查询时的吞吐量要求高。
- 线上系统的备份数据：用户把原始数据存在了其他关系数据库或文件服务，把HBase作为一个异地容灾的方案。
使用场景介绍
场景一：订单事件
这份数据使用过滴滴产品的用户应该都接触过，就是App上的历史订单。近期订单的查询会落在Redis，超过一定时间范围，或者当Redis不可用时，查询会落在HBase上。业务方的需求如下：
- 在线查询订单生命周期的各个状态，包括status、event_type、order_detail等信息。主要的查询来自于客服系统。
- 在线历史订单详情查询。上层会有Redis来存储近期的订单，当Redis不可用或者查询范围超出Redis，查询会直接落到HBase。
- 离线对订单的状态进行分析。
- 写入满足每秒10K的事件，读取满足每秒1K的事件，数据要求在5s内可用。
图1 订单流数据流程
按照这些要求，我们对Rowkey做出了下面的设计，都是很典型的scan场景。
订单状态表
Rowkey：reverse(order_id) + (MAX_LONG - TS)
Columns：该订单各种状态
订单历史表
Rowkey：reverse(passenger_id | driver_id) + (MAX_LONG - TS)
Columns：用户在时间范围内的订单及其他信息
场景二：司机乘客轨迹
这也是一份滴滴用户关系密切的数据，线上用户、滴滴的各个业务线和分析人员都会使用。举几个使用场景上的例子：用户查看历史订单时，地图上显示所经过的路线；发生司乘纠纷，客服调用订单轨迹复现场景；地图部门用户分析道路拥堵情况。
图2 司乘轨迹数据流程
用户们提出的需求：
- 满足App用户或者后端分析人员的实时或准实时轨迹坐标查询；
- 满足离线大规模的轨迹分析；
- 满足给出一个指定的地理范围，取出范围内所有用户的轨迹或范围内出现过的用户。
其中，关于第三个需求，地理位置查询，我们知道MongoDB对于这种地理索引有源生的支持，但是在滴滴这种量级的情况下可能会发生存储瓶颈，HBase存储和扩展性上没有压力但是没有内置类似MongoDB地理位置索引的功能，没有就需要我们自己实现。通过调研，了解到关于地理索引有一套比较通用的GeohHash算法 。
GeoHash是将二维的经纬度转换成字符串，每一个字符串代表了某一矩形区域。也就是说，这个矩形区域内所有的点（经纬度坐标）都共享相同的GeoHash字符串，比如说我在悠唐酒店，我的一个朋友在旁边的悠唐购物广场，我们的经纬度点会得到相同的GeoHash串。这样既可以保护隐私（只表示大概区域位置而不是具体的点），又比较容易做缓存。
