2018 HBase技术总结

1 .

2 .生态篇 HBase 生态介绍 1 HBase 进化之从 NoSQL 到 NewSQL，凤凰涅槃成就 Phoenix 4 案例篇 HBase 在新能源汽车监控系统中的应用 11 HBase 在滴滴出行的应用场景和最佳实践 17 HBase 在人工智能场景的使用 28 HBase 基本知识介绍及典型案例分析 34 HBase RowKey 设计指南 52 HBase 实战之 MOB 使用指南 59 技术篇 HBase 最佳实践－读性能优化策略 63 深入解读 HBase2.0 新功能之 AssignmentManagerV2 72 深入解读 HBase2.0 新功能之高可用读 Region Replica 81 HBase 2.0 之修复工具 HBCK2 运维指南 91 HBase 2.0 新特性之 In-Memory Compaction 101 HBase Coprocessor 的实现与应用 104 平台篇 58 HBase 平台实践和应用-平台建设篇 121 八年磨一剑，重新定义 HBase——HBase 2.0&阿里云 HBase 解读 135 

3 .Apache HBase 实战技术总结 – 中国 HBase 技术社区 中国 HBase 技术社区微信公众号 HBase+Spark 钉钉技术社区群 

4 . Apache HBase 实战技术总结 – 中国 HBase 技术社区 谨以此书献给所有 HBase 爱好者 HBase 是一个高性能，并且支持无限水平扩展的在线数据库，其存储计算分离的 特性非常好地适应了目前的趋势，并且在国内大公司内都被广泛地应用，具有非 常好的生态，是构建大数据系统的不二选择。 杨文龙 HBase PMC&HBase Committer 

5 .Apache HBase 实战技术总结 – 中国 HBase 技术社区 本文档的制作特别感谢以下同学（微信名, 排名不分先后） 快看，阳光 中国人寿保险股份有限公司 大数据研发工程师 米麒麟 陆金所 杨继飞 点评微生活 大数据研发工程师 诸葛子房 京东 大数据研发工程师 赵昆鹏 万达信息股份有限公司 大数据研发工程师 张少华 沈宗强 扎啤 过往记忆 封神 所在 同时感谢中国 HBase 技术社区所有小伙伴以及 2018 年 HBase Meetup 各位讲师。 

6 . HBase 生态介绍 HBase 生态介绍 我们都知道，HBase 是受 Google 公布的 BigTable 论文而产生的一种分布式、 多版本、面向列的开源 KV 数据库。HBase 稀疏矩阵的设计使得其特别适合存储 非结构化的数据，比如用户画像、日志以及消息等数据。但是随着业务的快速发 展，我们面临着各种新挑战和新需求，数据格式也随着业务的发展变得多种多样， 其中包括：KV 数据、关系数据、文档数据、图数据以及时空时序等数据。而且 随着时间的推移，各种数据占比越来越大，如下图所示： 从上图可以看出，从 2013 年开始，关系型数据的总体占比在逐年下降；而图数 据、搜索数据、KV 数据、文档数据以及时序数据等却在逐年上升。到了 2018 年， 关系型数据的占比已经由 2013 年的 90%多下降到 2018 年的 75.4%。 1 

7 .Apache HBase 实战技术总结 – 中国 HBase 技术社区 面对如此多样的数据，我们急需一种系统，能够存储这些逐年增长的数据。所以 很有必要在 HBase 之上引入各种组件，使得 HBase 能够支持 SQL、时序、时空、 图、全文检索能力、及复杂分析。所以，完整的 HBase 生态如下： 从最底下开始看，这里面可以根据不同的需求选择不同的存储介质。比如热数据 我们可以存储在 SSD 中；温数据存储在 HDD 中，冷数据存储在 OSS 中。中间一 层就是 HBase 以及 Solr。最上层是解决各种场景的组件。下面简单介绍下每种组 件的作用。 1. Phoenix：主要提供 SQL 的方式来查询 HBase 里面的数据。一般能够在毫 秒级别返回，比较适合 OLTP 以及操作性分析等场景。目前 Phoenix 支持 ANSI 92 语法，支持构建二级索引。 2. Spark：很多企业使用 HBase 存储海量数据，一种常见的需求就是对这些数 据进行离线分析，我们可以使用 Spark（Spark SQL） 来实现海量数据的离 线分析需求。同时，Spark 还支持实时流计算，我们可以使用 HBase+Spark Streaming 解决实时广告推荐等需求。 3. HGraphDB：HGraphDB 是分布式图数据库，可以使用其进行图 OLTP 查询，同 时我们还可以结合 Spark GraphFrames 实现图分析需求。通过依托图关联技 术，帮助金融机构有效识别隐藏在网络中的黑色信息，在团伙欺诈、黑中介 识别等。 4. GeoMesa：目前基于 NoSQL 数据库的时空数据引擎中功能最丰富、社区贡献 人数最多的开源系统。提供高效时空索引，支持点、线、面等空间要素存储， 百亿级数据实现毫秒(ms)级响应；提供轨迹查询、区域分布统计、区域查询、 2 

8 . HBase 生态介绍 密度分析、聚合、OD 分析等常用的时空分析功能；提供基于 Spark SQL、REST、 GeoJSON、OGC 服务等多种操作方式，方便地理信息互操作。 5. OpenTSDB：基于 HBase 的分布式的，可伸缩的时间序列数据库。适合做监控 系统；譬如收集大规模集群（包括网络设备、操作系统、应用程序）的监控 数据并进行存储，查询。 6. Solr：原生的 HBase 只提供了 Rowkey 单主键，如果我们需要对 Rowkey 之外的列进行查找，这时候就会有问题。幸好我们可以使用 Solr 来建立二 级索引/全文索引充分满足我们的查询需求。 通过在 HBase 之上引入了各种组件之后，使得 HBase 应用场景得到了极大的扩 展，满足了监控、车联网、风控、实时推荐、政企、人工智能等场景的需求。 目前阿里云提供了 HBase 及 X-Pack 组件，其 X-Pack 组件形式和上面的 HBase 生态很类似；除此之外，X-Pack 组件还针对 HBase 做了大量的优化，满足丰富 业务处理需求、同时更加易用、更加强大功能。 3 

9 .Apache HBase 实战技术总结 – 中国 HBase 技术社区 HBase 进化之从 NoSQL 到 NewSQL，凤凰 涅槃成就 Phoenix 陈明 阿里巴巴 技术专家 1.背景概述 近些年来，数据爆炸或者大数据成为 IT 行业发展的高频词汇，传统单机数据库 处理数据能力的瓶颈成为摆在 IT 工程师面前十分常见且亟待解决的问题。单机 硬件存储容量和计算力的增长远远赶不上数据的增长。在单机软件中，数据库是 数据相关处理技术的集大成者，集合了数据存储、数据实时读写、在线事务和数 据分析等技术，并通过主备、多活等方案保证了可靠性。但是，在实际业务场景 中，我们往往并没有同时用到所有数据库提供的能力，这也为我们解决业务中实 际遇到的大数据难题提供了解决思路。 当前的大数据系统大多是通过分布式原理，重点解决某个方面或者某些方面的困 境和难题，比如 HDFS 解决了大数据存储的问题，MapReduce 解决了大数据量 复杂分析和计算的难题，HBase 解决了实时读写的问题。下面笔者将介绍 HBase 从解决实时读写问题出发，逐步进化，从 NoSQL 发展到 NewSQL 的过程和最新 进展。 图 1 NoSQL 到 NewSQL 单纯从解决大数据实时读写问题角度，最初的 HBase 系统可以去掉很多传统数 据库无关的功能，比如事务，SQL 表达与分析等，重点关注于分布式系统的扩展 4 

10 . HBase 进化之从 NoSQL 到 NewSQL，凤凰涅槃成就 Phoenix 性，容错性，分布式缓存的设计，读写性能的优化以及毛刺的减少等方面。这也 就是 NoSQL 最初的含义，解决大数据的实时存取的核心问题是第一位的，提供 简单的 Get，Put，Scan 接口就可以解决用户的燃眉之急。通过第一阶段的努力， HBase 成为了优秀的大数据实时存取引擎，传统数据库的容量问题解决了，HDFS 实时性不够的问题也解决了。 走过了从无到有的第一阶段，我们需要让 HBase 更强大，更好用，门槛更低，让 HBase 帮助更多的用户解决他们遇到的实际问题。众所周知，SQL 是数据处理领 域的语言标准，简单，好用，表达力强，用户使用广泛。HBase 很有必要回过头 来支持 SQL，包括语言表达的支持和相关的数据处理方式和能力的支持。当然， HBase SQL 的实现和发展跟传统单机数据库有很多不同，便于区别，我们称之为 NewSQL。这也是社区 Phoenix 项目的初衷，如果说 HBase 是功能强大的存储引 擎，那么支持 NewSQL 之后，就变成了新一代的大飞机。 接下来，第二章将介绍 Phoenix 项目是如何让 HBase 从 NoSQL 成长为 NewSQL 的；第三章介绍 Phoenix 在阿里的实践，增强和典型案例；第四章总结全文以及 展望 Phoenix 未来的发展。 2.方案与实现 图 2 Phoenix 架构 系统整体架构如图 2 所示，其中黄色部分是 HBase 的组件，蓝色部分是 Phoenix， 我们可以看出 Phoenix 跟 HBase 是紧密结合的。Phoenix 首先要能通过 SQL 暴露 5 

11 . Apache HBase 实战技术总结 – 中国 HBase 技术社区 HBase 的能力，然后再通过一系列功能和特性增强 HBase 能力，并且还要做到足 够易用。下面我分别从基于 HBase 的 SQL，SQL 执行与优化以使用接口三个方 面介绍 Phoenix 已经做到的事情。 2.1 基于 HBase 的 SQL 让 HBase 支持 SQL，我们首先能想到的是，把 SQL 语言翻译成 HBase API，并且 HBase 本身的功能特性必须得能通过 SQL 暴露出来。Phoenix SQL 语法即 SQL- 92 标准语法+方言。Phoenix 支持标准语法的绝大部分特性，包括：标准类型； 聚合，连接，in，排序以及子查询等查询语法；create，drop，delete 等数据操作 语法，这些操作在底层都会转变为 HBase API。 此外，HBase 的某些特性也能通过 SQL 方言的形式表达，比如： 1. HBase 的列族，可以把相关的列放到一起，以减少 IO，优化读性能，在创建 Phoenix 表的时候直接写成”cf.col”即可，Phoenix 会自动创建 cf 列族， 如果不指定，则放在默认列族中； 2. Phoenix 将 insert 和 update 合并成 upsert 关键字，来对应 HBase 的 Put 概 念； 3. HBase 为了避免在表初始时只有一个 Region 带来数据热点，支持预分区， Phoenix 支持在建表的时候通过 split on 关键字来表达。 4. HBase 支持动态列的特性在 Phoenix 中也得以保留，存入数据的时候直接声 明新的字段即可使用。 由于充分结合，Phoenix 天然继承了 HBase 所拥有的高并发，大容量，实时存取 等特性。 图 3 SQL vs HBase API 6 

12 . HBase 进化之从 NoSQL 到 NewSQL，凤凰涅槃成就 Phoenix 从图 3 中可以看出，有了 SQL，用户无需编写繁琐的 java 代码，大大简化了代 码逻辑，传统数据库用户可以快速上手，原有基于传统数据库的代码逻辑，只需 要少量修改即可运行起来。 2.2 SQL 查询优化 图 4 Phoenix SQL 执行流程 在很多场景下仅拥有实时存取的特性是不够的，大数据在线原地分析也是自然而 然的需求，Phoenix 基于 HBase 拥有的高效缓存和 LSM 索引，可以做到对 PB 级 数据做操作型分析的毫秒级或秒级返回。Phoenix SQL 的整体执行流程如图 4 所 示，用户输入的查询语句首先经过 SQLParser 解析为执行计划，然后经过 QueryOptimizer 的优化，选取最优的执行计划，执行计划最终会转变为 HBase 的 Scan，RegionServer 端的协处理器会作用于该 Scan，做本地过滤和聚合，然后把 结果返回到客户端做汇总聚合形成最终结果，并通过 ResultSet 的形式返回给用 户。其中主要使用到的策略有：无需数据传输的算子原地计算；实时同步的二级 索引；热点数据自动打散；以及基于代价和规则的执行计划优化等。后面笔者介 绍前三个最具有 Phoenix 特色的策略。 在没有 Phoenix 之前，用户如果需要分析 HBase 数据，只能从 HBase 拖出去或 者绕过 HBase 直接读取 HDFS 上面的 HFile 的方式进行，前者浪费了大量的网络 IO，后者用不到 HBase 本身做的大量缓存和索引优化。Phoenix 使用 HBase 的协 处理器机制，直接在 RegionServer 上执行算子逻辑，然后将算子的结果返回即 可，也就是大数据中的“Move Operator to Data”理念。比如，用户执行“select 7 

13 . Apache HBase 实战技术总结 – 中国 HBase 技术社区 count(*) from mytable where mytime > timestamp’2018-11-11 00:00:00’”，在实 际执行中，会先找到符合过滤条件的 region，然后在 RegionServer 本地计算 count， 最后再对各个 Region 上的结果进行汇总。 索引是传统数据库中常见的技术，HBase 表中可以指定主键，对主键使用 LSM 算 法构建索引。Phoenix 中，用户在创建表的时候，可以指定索引列，可以是单列， 也可以是组合列。很多时候仅有主键索引是不够的，特别是对于列特别多的宽表， 为此，Phoenix 提供二级索引功能，用户能够对表中非主键的列添加索引，并可 以加入其它相关列到索引表中，如果某个查询涉及到的列全部在索引表中，直接 查询索引表即可，无需访问原数据表。索引表跟原表做到实时同步更新，以保证 数据一致性。 索引示例如图 5 所示，创建索引的时候通过“on”关键字指定索引表的主键，实际 HBase 表中会使用 BA 来作为联合主键；“include”关键字指定加入到索引表的其 他列。当执行“select c from data_table where b > xx ”时，Phoenix 直接查询索引 表即可，否者需要返回原表查找。 图 5 Phoenix 二级索引 当数据的访问比较集中，比如物联网场景中需要对最新的的监控数据做查询分析， 而这部分数据往往会集中分布在某个 RegionServer 上，那么就会形成热点，性 能也会大大折扣。此时需要能够把数据打散到不同的 RegionServer 上来解决， 加盐就是这样一个技术。加盐的过程本质上是对原有的主键加上一个字节的前缀， 如下面公式所示： new_row_key = (++index % BUCKETS_NUMBER) + original_key 8 

14 . HBase 进化之从 NoSQL 到 NewSQL，凤凰涅槃成就 Phoenix 其中，BUCKETS_NUMBER 为桶的个数。主键的分布决定了数据的分布，把主键 打散也就意味着数据打散。具体使用时，一般建议桶的数目等于 RegionServer 的 数目。 2.3 使用接口 Phoenix 提供 JDBC 的方式访问，并支持重客户端和轻客户端两种方式，重客户 端 的 JDBC 串 前 缀 是 “jdbc:phoenix:” ， 轻 客 户 端 的 JDBC 串 前 缀 为 “jdbc:phoenix:thin:”。重客户端中，Phoenix 初执行在 HBase 协处理器之外的逻辑 均运行在客户端，这样可以带来最优的性能，但也带来了客户端的复杂性。轻客 户端则将上诉逻辑运行在单独不熟的 QueryServer 中，客户端仅有很薄的 JDBC 协议转换。轻客户端除支持 Java 语言外，也支持 Python、Go、C#等多种语言。 3.实践案例 阿里云 HBase 产品中集成 Phoenix 功能已经有一年多的时间了，阿里云 HBase 团队对 Phoenix 在稳定性和性能方面做了一系列的改进优化，并积极反馈回社区， 团队的瑾谦同学也成长为了 Phoenix 社区的 commiter。Phoenix 的用户既有来自 于新型大数据业务，如物联网、互联网金融以及新零售等；也有来自传统行业， 比如游戏、养殖业和运输业等。Phoenix 数据既有来在线实时业务，也有从单机 数据库同步进来。下面，笔者以物联网场景为例，说明 Phoenix 如何在实际业务 中解决用户难题。 在物联网场景下，大量传感器会把实时监测到的数据上传到云平台，经过一定的 预处理后实时写入到 Phoenix 中，管控平台从 Phoenix 中直接在线查询和分析数 据，如生成报表，监控异常等。该场景会用到 Phoenix 的一下特性： 1. 对实时写入的并发和 TPS 要求很高，甚至可以达到百万级。 2. 数据量比较大，一般在 TB 到 PB 级别，且需要根据业务增长动态扩容。 3. 有动态列的需求，比如根据业务调整，动态添加监控指标。 4. 在线查询，甚至是毫秒级查询要求。 5. 维度比较多，需要用到二级索引，以加速在线查询。 6. 频繁查询最近一段时间的数据，会造成热点，可以使用加盐的特性。 9 

15 .Apache HBase 实战技术总结 – 中国 HBase 技术社区 图 6 Phoenix 在物联网的应用 4.总结与展望 开源的 HDFS、MapReduce 和 HBase 来源于 Google 的三篇论文，但最终驱动的 还是大数据场景下的实际需求。Phoenix 的出现也是需求驱动的必然结果，它继 承了 HBase 的各种特性，如高并发，水平扩展，实时读写等，并在其基础上实现 了一套 SQL 引擎，增加了如语法解析、二级索引、查询优化以及 JDBC 等功能和 特性，完成了 NoSQL 到 NewSQL 的转变。 阿里云 HBase 团队和社区对 Phoenix 后续还会根据实际需求做进一步的进化， 包括稳定性的进一步加强；执行计划和运行时的进一步优化；轻客户端在易用性 支持上的持续完善；实时交易场景中事务的支持以及跟 Spark 的深度集成等等。 笔者非常希望对 HBase 和 Phoenix 感兴趣的读者朋友可以参与到社区里面，共 同推动技术的发展，满足更多的场景需求。 10 

16 . HBase 在新能源汽车监控系统中的应用 HBase 在新能源汽车监控系统中的应用 颜禹 重庆博尼施科技有限公司 CTO 重庆博尼施科技有限公司是一家商用车全周期方案服务商，利用车联网、云计算、 移动互联网技术，在物流领域 为商用车的生产、销售、使用、售后、回收各个 环节提供一站式解决方案，其中的新能源车辆监控系统就是由该公司提供的。该 系统主要用于东风轻卡等新能源商用车监控服务，目前该系统正在阿里云线上稳 定运行。 新能源车辆监控系统是一个车辆网服务平台，具有高并发、数据量大、实时性要 求高等特点。对车辆监控系统来说最重要的问题就是如何处理车辆产生的海量数 据，我们估计，当车辆数量增长到 10 万时，每天会产生大约 2TB 的数据，这些 数据不仅需要存储，还需要做到实时可查。本文将介绍项目的背景和系统的基本 架构，随后介绍我们在开发过程中遇到的各种问题以及解决方案。 1.项目背景 本项目为车联网监控系统，系统由车载硬件设备、云服务端构成。车载硬件设备 会定时采集车辆的各种状态信息，并通过移动网络上传到服务器端。服务器端接 收到硬件设备发送的数据首先需要将数据进行解析，校验，随后会将该消息转发 到国家汽车监测平台和地方汽车监测平台，最后将解析后的明文数据和原始报文 数据存储到系统中。车辆的数据和其他数据需要通过 web 页面或 rest API 接口 进行查询访问。要求半年内的数据查询响应时间在毫秒级别内，超过半年的数据 需要放到更加低成本的介质上，查询延迟在 3s 以内，这些数据的查询频次比较 低。系统的主要参数有以下几项: 1. 10 万台车辆同时在线； 2. 车辆正常情况下平均每分钟发送两个数据报文到监控平台； 3. 若车辆处于报警状态，则平均一秒钟发送一次数据报文； 4. 数据情况：（1）、车辆数据报文平均大小为 1KB;（2）、解析后的数据包 大小为 7KB；（3）、平均一台车每天会产生 20MB 的数据；（4）、系统每 11 

17 .Apache HBase 实战技术总结 – 中国 HBase 技术社区 天会产生 2TB 的数据；（5）同时系统有 2.9 亿行的数据需要写入到数据库 中； 5. 系统并发量：（1）、3300 的持续并发量；（2）、10 万个长连接； （3）、每秒 3.3MB 的原始数据需要被解析；（4）、每秒 23.1MB 的解析数 据需要被存储。 2.系统设计 系统的技术选型对初创公司来说至关重要，所以在设计系统的时候尤为小心。经 过仔细分析，我们要求新系统必须满足以下几个条件： 1. 必须能够支持海量数据的不间断写入，而且能够存储 PB 级别的数据，具有 高扩展性、高可靠性等； 2. 能够支持简单的关键字查询，响应时间在秒级别内； 3. 能够兼容大数据生态产品(如 Spark、Hive、Hadoop 等)，同时支持离线和准 实时 OLAP； 4. 优先选择有雄厚实力的商业公司支持的云平台，最大限度减少运维成本。 2.1 为何选择 HBase 因为车辆的监控数据非常大，传统关系型数据库（如 Mysql、pg 等）已经无法胜 任存储工作，所以我们需要选用一种分布式数据库用于存储车辆实时数据。 我们在市场上能够找到分布式数据库有 MongoDB 和 HBase。 1. MongoDB：MongoDB 是一种我们曾经使用过的数据库，该数据库是一种基于 文档的数据库。支持分片副本集扩展，但是由于 MongoDB 的分片集群维护 成本过高，另外查询性能严重依赖索引，扩容时分片的迁移速度过慢。所 以在这一版本的监控系统中我们并未采用。 2. HBase：HBase 底层存储基于 HDFS 的面向列数据库，其核心思想来源于谷歌 三大论文内的 bigtable。在谷歌和开源界均拥有丰富的应用实践经验。除 此之外，HBase 还有以下特点：（1）、支持 PB 级别的数据量；（2）、压 缩效率非常高；（3）、支持亿级别的 QPS；（4）、在国内外很多大型互联 网公司使用；（5）、HBase 添加节点及扩容比较方便，无需 DBA 任何干 预。 12 

18 . HBase 在新能源汽车监控系统中的应用 经过对这几种数据库的分析，我们最终选用 HBase，其满足我们前面提到的四个 要求，而且还提供 Phoenix 插件用于 SQL 语句的查询。 作为初创公司，我们的运维能力有限，我们需要业务的快速落地。所以自建机房 以及运维团队意味着前期较大的投入以及高昂的运维成本，所以我们决定使用云 方案。 经过比较国内的各大云厂商，我们最终选用了阿里云平台，因为阿里云提供 SaaS 化的 HBase 服务，同时阿里云 HBase 支持很全面的多模式，支持冷数据存放在 OSS 之中，节约成本；支持备份恢复等特性，做到了真正的 native cloud 的数据 库服务。另外，HBase 在阿里内部部署超过 12000 台机器，历经 7 年天猫双 11 的考验，这些实际数据以及经验增强了我们对阿里云 HBase 的技术信心，同时满 足了我们的技术和业务需求。 2.2 层级系统架构 系统采用层级架构以方便后期扩展和维护，现在主要分为以下几层： 1. 接入层：主要负责管理车辆设备的长连接，认证接收车辆发送的数据，下 放数据和指令等操作。 2. 消息队列层：主要负责缓存接入层收到的车辆实时数据。 3. 实时数据处理与解析层：主要负责解析车辆上传的实时数据，并将其存储 到数据库中。另外还需要负责数据转发、指令生成等工作。 4. 应用层：主要负责处理各种业务逻辑、将解析后的数据进行分析整理提供 给用户使用。 2.3 系统架构预览 最终新能源监控系统的系统架构设计如下 13 

19 .Apache HBase 实战技术总结 – 中国 HBase 技术社区 图中最左端为监控的车辆，它会实时采集车辆的各项数据，并把采集到的数据通 过移动互联网发送到平台。平台验证完数据会将其写入到 Kafka 消息队列中。流 式计算服务器从 Kafka 消息队列中取出车辆的原始数据，并对车辆的数据进行解 析、存储、转发等操作。HBase 集群负责存储车辆实时数据，MySQL 负责存储组 织关系数据。同时，我们还会将超过一定时间（比如半年前）的数据转存到 OSS 存储介质中，以便降低存储成本。Spark ML 会对系统中的各项数据进行分析。终 端用户会从 HBase 中查询一些数据。 3.HBase 使用难点 3.1 Row key 设计 团队在使用 HBase 之前一直使用 MySQL 关系型数据库，在系统设计之初并没有 考虑 HBase 的特性，而是按照关系型数据库的设计原则设计。经过一段时间的了 解后才知道 HBase 主要使用 Row key 进行数据查询。Row key 的设计至关重要。 目前系统中设计的 Row key 如下 1. 设备 ID + 时间戳：此种方式可以快速定位单台车辆。但是由于设备 ID 前 缀为型号，一旦某批次的设备或车辆发送故障，则会造成 HBase 的某个 Region 写入压力过大。 2. subString(MD5(设备 ID),x) + 设备 ID + 时间戳：此种方式可以将所有车 辆打散到每个 Region 中，避免热点数据和数据倾斜问题，式中的 x 一般取 5 左右。但对于某个型号的车辆查询就只能够每台车辆单独进行查询了。 14 

20 . HBase 在新能源汽车监控系统中的应用 3.2 复杂查询问题 虽然通过 Row key 的设计可以解决部分数据查询的需求，但是在面对复杂需求 时难以通过 Row key 直接索引到数据，若索引无法命中，则只能进行大范围或 全表扫描才能够定位数据。所以我们在使用 HBase 时尽量避免复杂的查询需求。 但业务方面仍然会有部分较为复杂的查询需求。针对这些需求，我们主要使用两 种方式来建立二级索引。 1. 手动在事务产生时将索引写入到 HBase 表中：使用这种方式建立索引虽然可 以不借用第三方插件，但是事务的原子性很难得到保障，业务代码也会因为 索引的变化而难以维护。另外索引的管理也较为麻烦，后期的数据迁移很难 能够。 2. 通过 Phoenix 构建索引：通过 Phoenix 构建索引可以避免事务原子性问题， 另外也可以通过重建索引来进行数据迁移。因为使用的 SQL 语句，开发人员 更能够利用之前关系型数据库的设计经验建立数据索引。 目前新能源监控系统中主要使用 Phoenix 实现二级索引，大大增加了数据的查询 使用场景。虽然 Phoenix 能够通过二级索引实现较为复杂的数据查询，但对于更 为复杂的查询与分析需求就显得捉襟见肘。所以我们选用了 Spark 等其他数据分 析组件对数据进行离线分析，分析后对结果通过接口提供给用户。 3.3 多语言连接问题 团队使用 Python 语言构建系统，但 HBase 使用 Java 语言编写，原生提供了 Java API，并未对 Python 语言提供直接的 API。我们使用 happybase 连接 HBase，因 为它提供了更为 Pythonic 的接口服务。另外我们也是用 QueryServer 作为 Python 组件和 Phoenix 连接的纽带。 4.HBase 冷数据存储 系统中车辆数据分为热数据和冷数据，热数据需要 HBase 中实时可查，冷数据虽 不需要实时可查，但却需要一直保存在磁盘中。阿里云 HBase 支持将冷数据直接 存储在 OSS 中，而这些数据的转存只需要简单的设置表相关属性，操作非常简 单。将冷数据存储在 OSS 之中大大减少了数据的存储成本。 15 

21 .Apache HBase 实战技术总结 – 中国 HBase 技术社区 5.总结 首先，本文介绍了新能源车辆监控系统的项目背景，随后分析了本项目的项目难 点，并介绍了我们团队的各种解决方案。针对项目需求，介绍了我们选择 HBase 的原因，及在 HBase 数据库使用过程中的经验和痛点。 6.展望 未来，我们会在系统接入大量车辆后，使用 golang 重写高性能组件以满足后期 的并发性能需求。由于项目初期考虑到开发时间的问题，并未采用服务拆分的方 式进行开发，这限制了系统的可扩展性，后期我们会根据实际业务需求，将系统 切分成相对独立的模块，增强扩展性可维护性。 另外，车辆数据积累到一定程度后，我们可以利用这些数据进行大数据分析, 如 车辆的故障诊断，车辆状态预测等，这样就可以在车辆出现问题前提前发出预警， 为车主和保险公司避免更大的损失，降低运营成本。 16 

22 . HBase 在滴滴出行的应用场景和最佳实践 HBase 在滴滴出行的应用场景和最佳实践 李扬 滴滴出行 资深软件开发工程师 1.背景 1.1 对接业务类型 HBase 是建立在 Hadoop 生态之上的 Database，源生对离线任务支持友好，又 因为 LSM 树是一个优秀的高吞吐数据库结构，所以同时也对接了很多线上业务。 在线业务对访问延迟敏感，并且访问趋向于随机，如订单、客服轨迹查询。离线 业务通常是数仓的定时大批量处理任务，对一段时间内的数据进行处理并产出结 果，对任务完成的时间要求不是非常敏感，并且处理逻辑复杂，如天级别报表、 安全和用户行为分析、模型训练等。 1.2 多语言支持 HBase 提供了多语言解决方案，并且由于滴滴各业务线 RD 所使用的开发语言各 有偏好，所以多语言支持对于 HBase 在滴滴内部的发展是至关重要的一部分。我 们对用户提供了多种语言的访问方式：HBase Java native API、Thrift Server（主 要应用于 C++、PHP、Python）、JAVA JDBC（Phoenix JDBC）、Phoenix QueryServer （Phoenix 对外提供的多语言解决方案）、MapReduce Job（Htable/Hfile Input）、 Spark Job、Streaming 等。 1.3 数据类型 HBase 在滴滴主要存放了以下四种数据类型： 1. 统计结果、报表类数据：主要是运营、运力情况、收入等结果，通常需要配 合 Phoenix 进行 SQL 查询。数据量较小，对查询的灵活性要求高，延迟要求 一般。 17 

23 .Apache HBase 实战技术总结 – 中国 HBase 技术社区 2. 原始事实类数据：如订单、司机乘客的 GPS 轨迹、日志等，主要用作在线和 离线的数据供给。数据量大，对一致性和可用性要求高，延迟敏感，实时写 入，单点或批量查询。 3. 中间结果数据：指模型训练所需要的数据等。数据量大，可用性和一致性要 求一般，对批量查询时的吞吐量要求高。 4. 线上系统的备份数据：用户把原始数据存在了其他关系数据库或文件服务， 把 HBase 作为一个异地容灾的方案。 2. 使用场景介绍 2.1 场景一：订单事件 这份数据使用过滴滴产品的用户应该都接触过，就是 App 上的历史订单。近期 订单的查询会落在 Redis，超过一定时间范围，或者当 Redis 不可用时，查询会 落在 HBase 上。业务方的需求如下： 1. 在线查询订单生命周期的各个状态，包括 status、event_type、order_detail 等信息。主要的查询来自于客服系统。 2. 在线历史订单详情查询。上层会有 Redis 来存储近期的订单，当 Redis 不可 用或者查询范围超出 Redis，查询会直接落到 HBase。 3. 离线对订单的状态进行分析。 4. 写入满足每秒 10K 的事件，读取满足每秒 1K 的事件，数据要求在 5s 内可用。 图 1 订单流数据流程 18 

24 . HBase 在滴滴出行的应用场景和最佳实践 按照这些要求，我们对 Rowkey 做出了下面的设计，都是很典型的 scan 场景。 订单状态表 Rowkey：reverse(order_id) + (MAX_LONG - TS) Columns：该订单各种状态 订单历史表 Rowkey：reverse(passenger_id | driver_id) + (MAX_LONG - TS) Columns：用户在时间范围内的订单及其他信息 2.2 场景二：司机乘客轨迹 这也是一份滴滴用户关系密切的数据，线上用户、滴滴的各个业务线和分析人员 都会使用。举几个使用场景上的例子：用户查看历史订单时，地图上显示所经过 的路线；发生司乘纠纷，客服调用订单轨迹复现场景；地图部门用户分析道路拥 堵情况。 图 2 司乘轨迹数据流程 用户们提出的需求： 1. 满足 App 用户或者后端分析人员的实时或准实时轨迹坐标查询； 2. 满足离线大规模的轨迹分析； 3. 满足给出一个指定的地理范围，取出范围内所有用户的轨迹或范围内出现过 的用户。 其中，关于第三个需求，地理位置查询，我们知道 MongoDB 对于这种地理索引 有源生的支持，但是在滴滴这种量级的情况下可能会发生存储瓶颈，HBase 存储 和扩展性上没有压力但是没有内置类似 MongoDB 地理位置索引的功能，没有就 19 

25 .Apache HBase 实战技术总结 – 中国 HBase 技术社区 需要我们自己实现。通过调研，了解到关于地理索引有一套比较通用的 GeohHash 算法 。 GeoHash 是将二维的经纬度转换成字符串，每一个字符串代表了某一矩形区域。 也就是说，这个矩形区域内所有的点（经纬度坐标）都共享相同的 GeoHash 字 符串，比如说我在悠唐酒店，我的一个朋友在旁边的悠唐购物广场，我们的经纬 度点会得到相同的 GeoHash 串。这样既可以保护隐私（只表示大概区域位置而 不是具体的点），又比较容易做缓存。 图 3 GeoHash 示意图 但是我们要查询的范围和 GeohHash 块可能不会完全重合。以圆形为例，查询时 会出现如图 4 所示的一半在 GeoHash 块内，一半在外面的情况（如 A、B、C、 D、E、F、G 等点）。这种情况就需要对 GeoHash 块内每个真实的 GPS 点进行第 二次的过滤，通过原始的 GPS 点和圆心之间的距离，过滤掉不符合查询条件的 数据。 图 4 范围查询时，边界 GeoHash 块示意图 20 

26 . HBase 在滴滴出行的应用场景和最佳实践 最后依据这个原理，把 GeoHash 和其他一些需要被索引的维度拼装成 Rowkey， 真实的 GPS 点为 Value，在这个基础上封装成客户端，并且在客户端内部对查询 逻辑和查询策略做出速度上的大幅优化，这样就把 HBase 变成了一个 MongoDB 一样支持地理位置索引的数据库。如果查询范围非常大（比如进行省级别的分析）， 还额外提供了 MR 的获取数据的入口。 两种查询场景的 Rowkey 设计如下： 1. 单个用户按订单或时间段查询： reverse(user_id) + (Integer.MAX_LONG- TS/1000) 2. 给定范围内的轨迹查询：reverse(geohash) + ts/1000 + user_id 2.3 场景三：ETA ETA 是指每次选好起始和目的地后，提示出的预估时间和价格。提示的预估到达 时间和价格，最初版本是离线方式运行，后来改版通过 HBase 实现实时效果，把 HBase 当成一个 KeyValue 缓存，带来了减少训练时间、可多城市并行、减少人 工干预的好处。 整个 ETA 的过程如下： 1. 模型训练通过 Spark Job，每 30 分钟对各个城市训练一次； 2. 模型训练第一阶段，在 5 分钟内，按照设定条件从 HBase 读取所有城市数据； 3. 模型训练第二阶段在 25 分钟内完成 ETA 的计算； 4. HBase 中的数据每隔一段时间会持久化至 HDFS 中，供新模型测试和新的特征 提取。 Rowkey：salting+cited+type0+type1+type2+TS Column：order, feature 21 

27 .Apache HBase 实战技术总结 – 中国 HBase 技术社区 图 5 ETA 数据流程 2.4 场景四：监控工具 DCM 用于监控 Hadoop 集群的资源使用（Namenode，Yarn container 使用等），关系 数据库在时间维度过程以后会产生各种性能问题，同时我们又希望可以通过 SQL 做一些分析查询，所以使用 Phoenix，使用采集程序定时录入数据，生产成报表， 存入 HBase，可以在秒级别返回查询结果，最后在前端做展示。 图 6 DCM 数据流程 图 7、图 8、图 9 是几张监控工具的用户 UI，数字相关的部分做了模糊处理。 22 

28 . HBase 在滴滴出行的应用场景和最佳实践 图 7 DCM HDFS 按时间统计使用全量和增量 图 8 DCM HDFS 按用户统计文件数 23 

29 .Apache HBase 实战技术总结 – 中国 HBase 技术社区 图 9 DCM，MR Job 运行结果统计 3. 滴滴在 HBase 对多租户的管理 我们认为单集群多租户是最高效和节省精力的方案，但是由于 HBase 对多租户 基本没有管理，使用上会遇到很多问题：在用户方面比如对资源使用情况不做分 析、存储总量发生变化后不做调整和通知、项目上线下线没有计划、想要最多的 资源和权限等；我们平台管理者也会遇到比如线上沟通难以理解用户的业务、对 每个接入 HBase 的项目状态不清楚、不能判断出用户的需求是否合理、多租户在 集群上发生资源竞争、问题定位和排查时间长等。 针对这些问题，我们开发了 DHS 系统（Didi HBase Service）进行项目管理，并 且在 HBase 上通过 Namespace、RS Group 等技术来分割用户的资源、数据和权 限。通过计算开销并计费的方法来管控资源分配。 24