高手如何实践HBase？不容错过的滴滴内部技巧

摘要： HBase和Phoenix的优点你们众所周知，想要落地实践却问题一堆？replication的随机发送、Connection的管理是否让你头痛不已？本次分享中，滴滴以典型的应用场景带你们深刻探究HBase和Phoenix，并分享内核改进措施。同时滴滴就如何实现稳定性与容量规划分享了众多内部技巧，不容错过！

本次直播视频精彩回顾，戳这里！

如下内容根据演讲嘉宾视频分享以及PPT整理而成。

本文将围绕一下几个方面进行介绍：

1. HBase特性应用与内核改进
2. Phoenix改进与实践
3. GeoMesa应用简介与展望
4. 稳定性&容量规划

一． HBase特性应用与内核改进

1.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。

2. replication 的应用与优化

假设原集群有三个主机：ReplicationSource01, ReplicationSource02, ReplicationSource03，目标集群有四个：RS01, RS02, RS03, RS04。若原集群发送replication请求，传统的逻辑会随机发送该请求。若目标集群的表存储在GROUP A中的两个主机上，但随机发送却有可能致使这两个主机接收不到replication请求，而是发送至和该业务无关的GROUP中。所以这里对此做出优化，对执行策略进行适当修改，将可能发送到其余集群的请求在原集群中进行匹配，获取目标集群GROUP的分配，使得请求能够发送至对应的GROUP主机中，防止影响其余业务。

此外，将来但愿在replication中增长table级别的信息统计，统计请求的链接错误信息，从用户角度进行优化。

3. Connection的管理与使用

基于滴滴现在的HBase版本，用户使用中会出现关于Connection的一些问题，例如创建了多个Connection后，对应的ZK也会很是多，所以须要对Connection进行管理。这里采用在RS中建立ClusterConnection来尽可能减小Connection的建立。这会应用在Phoenix二级索引场景中，详情在Phoenix部分介绍。

4. ACL权限认证的优化

ACL主要实现用户的用户名、密码与IP匹配的功能。此处建立了userinfo来存储用户密码信息，rowkey为用户名，CF(Column Family)为对应的密码。HBase:ACL这个表，在ZK中有/acl节点，相似的创建了userinfo节点。

下图所示为userinfo接入流程。最上方是用户客户端封装后的userinfo序列化信息，发送至服务器端，服务器经过AccessController进行一些操做，例如preGetOp, preDelete和prePut等。而后TableAuthManager进行权限判断。TableAuthManager类中会存储权限信息cache，当接收到新的userinfo时，首先会更新cache，供客户端访问时调用。传统cache只包含/hbase/acl信息，滴滴优化后增添了/hbase/userinfo信息。那么此时更新cache须要/acl信息和/userinfo信息进行Join()操做。

可是在使用原生/acl时也遇到一些问题，究其缘由，仍是须要减轻对zookeeper的依赖。
此外，滴滴还对其余方面进行了优化，包括RPC audit log, RSGroup, quota, safe drop table等。RPC audit log能够对用户请求量及错误信息进行分析。quato能够限制用户流量，例如限制用户对某个表每秒内能够执行多少次put操做。另外在drop table时，传统方式为直接清理表格内容，现优化为先存储一份快照再删除，防止误删操做。

二． Phoenix改进与实践

1. Phoenix原理与架构

Phoenix提供基于HBase的sql操做的框架，主要进行源数据的管理。在RegionServer3上存储着SYSTEM.CATALOG表，在每一个RegionServer上有Coprocessor进行查询、聚合、二级索引的创建等操做。

Phoenix client主要进行Connection管理，源数据管理，sql语法物理执行计划，并行Scan的发送与查询，对scanner进行封装。RegionServer中使用coprocessor较多。

2. Phoenix重要业务支持——全量历史订单

接下来主要介绍滴滴基于一个Phoenix重要端上任务，历史订单查询，做出的优化改进。滴滴的APP端改进前能够查询三个月内的历史订单数据，现在已经达到全量历史订单数据，即理论上能够查询全部订单数据。系统稳定性能够达到SLA99.95%。除却HBase集群自身保证的监控和恢复措施外，二级索引写失败处理和业务增长二级索引问题也也做出了较好的改进。而且，滴滴对查询延迟要求也比较高，现使用JDBC客户端P99延迟已达到了30-40ms。在功能上也实现了在每一个column均可以声明default值。

2.1 Index coprocessor改进

在稳定性的改进中，connection的管理相当重要。在HBase中，ZK较为脆弱，connection的数量过多会对ZK形成较大的压力。Phoenix传统写二级索引都是由Index coprocessor完成，当主表声明的Index较多时，会产生较多Region。ZK的链接数即为region数乘以index数量，这会致使可能一个表会包含几千个ZK。所以，为了解决这个问题，在RegionServer内部创建 ClusterConnection，全部Region都复用该ClusterConnection。

2.2 TupleProjector性能优化

为了对客户端P99延迟进行优化，这里针对TupleProjector进行了改进工做。初始phoenix 进行一次Query compilePlan耗时150ms左右，这主要因为订单业务表多达130多个column，对每个column进行get column expression都会耗时1ms，所以这总耗时对系统来讲是难以容忍的消耗。对于上述类型的宽表，最有效的优化措施为配置并行处理。优化后P99能够达到35ms左右。

2.3 二级索引设计

Phoenix的Salting功能很是有效，但对延迟影响较大，所以若延迟要求较高，那么Salting则并不合适，因此这里在主表与索引表中不使用Salting功能，而是采用reverse将主键列散列。索引中使用Function Index和Function Index减小查询延迟。示例代码以下所示：

2.4 Default值的坑

通常业务不会使用Default值，而且传统的Default设计存在不少bug。例如在声明Default列的二级索引中的写入错误，即试图写入新值时，真正写入的仍然是Default值。示例以下：

这里有两种解决方案。一是在Index进行build以前，即在客户端时进行一些特殊处理。方法二为在生成索引表的源数据时对错误填写的值进行修改。
另外一处bug例如在创建异步二级索引生成rowkey和Indexer build rowkey不一致，致使在索引查询数据时double。具体缘由是PTablempl.newKey对Default值的列逻辑上存在bug。示例以下：

2.5 性能压测

在进行上述优化后，分别经过Java-JDBC和Java-queryServer查询进行性能压测。结果以下：

其余非Java语言会经过Go-queryServer查询，压测P99结果会比Java语言稍慢。

2.6 二级索引策略

在传统逻辑中，若Indexer二级索引写失败，则直接disable二级索引表，而后rebuild，但这在线上是不可用的。所以，滴滴采起关闭自动rebuild和disable进行改进。那么关闭自动rebuild和disable后如何感知写失败呢？此时须要定时查询RegionServer log实时收集的ES，而后调用异步二级索引Partial rebuild来进行修补。当主表数据量较大时，进行异步全量二级索引时可能会split大量的maptask，超出master的承受范围。所以须要改进split逻辑，对某些task进行合并。当这些改进完成，就能够提供较为稳定的支持。

2.7 集群升级对二级索引写入影响

当出现集群升级时，二级索引写入确定会失败，该如何将该影响降至最低呢？若是将主表和索引表部署在一块儿，那么一台机器升级，全部机器都会出现写失败。前文中也提到，滴滴在HBase中增添了GROUP功能，那么即可以将主表和索引表分开，部署在不一样GROUP中，下降集群升级的影响。以下图所示：

三． GeoMesa应用简介与展望

1. GeoMesa架构原理

滴滴最近开始对GeoMesa展开调研，暂未取得丰富的线上经验。GeoMesa是基于分布式存储、计算系统上的大规模时空数据查询分析引擎。即在存储时能够选择存储区域，数据输入也能够包含多种形式，如spark kafka等。架构以下图所示：

GeoMesa对地理时空信息进行索引有着极大的优点。以HBase为例，GeoMesa能够将二维或三维数据映射至一维存储，Geohash是较为常见的编码方式。这种索引方法属于点索引，现在使用较为普遍。具体示例以下图所示：

Geohash方法是将经纬度等高维地理时空数据进行01编码映射到一维。首先将维度置于奇数位，经度为偶数位，经过base32生成字符串，降为一维，具体过程见下图：

Geohash的理论基础为Z-order曲线。但Z-order曲线存在突变性，即当地理位置距离很是远，但编码后的逻辑位置可能会产生连续的现象，以下图。所以，经过Geohash查询到的结果会比真正须要的结果数量差别较大，会有不少无效结果。

这会形成上图中，某些点编码前缀相同，但实际地理位置却相差较远，而与实际地理位置较近的编码前缀并不相同。

2. GeoMesa应用

GeoMesa常常应用于热力图绘制。滴滴使用其进行行车轨迹记录，即查询某时间段某区域内通过的车辆。以及对轨迹点加工，经过矢量路径分析拥堵等。往后但愿将XZ-order线和多边形索引应用至滴滴的业务场景中去。

滴滴也将GeoMesa进行了可视化，具体详见视频。

3. GeoMesa将来展望

基于上述Z-order曲线的突变性问题，将来但愿能够基于希尔伯特空间填充曲线编码生成索引。由于希尔伯特空间填充曲线含有地理空间局部性特征，所以一维曲线上离得越近的点在2D空间离得越近。这个特性对Scan具备较好的适用性。此外，GeoMesa中的plan耗时较长，平均每次耗时90ms，将来但愿能够进行优化。

四． 稳定性&容量规划

为了达到稳定性与容量规划，滴滴主要进行了如下工做。
首先是机器规划。其中主要从三个维度进行考虑：每秒读写量、平均流量和存储空间。每秒的读写量影响服务读写能力，平均流量会影响服务读写能力和磁盘IO，而存储空间对应其磁盘空间。若每秒读写量太大，会影响该服务的GC及网络流量等。若须要的存储空间比磁盘的总存储空间要大，那么服务也会受到影响。所以这里能够经过压力测试和DHS统计，将这三个维度进行综合比较，计算机器容量规划。同时，也能够根据上述信息，完成集群的GROUP划分规划。

其次，还对HBase的一些指标进行监控，根据监控状况判断用户服务是否处于健康状态。出现故障时，也能够根据监控排查问题。这里再也不赘述，其中一监控效果以下：

滴滴目前的工做流程大体为，当用户接入时，先预估请求量，进行压力测试，检查后进行上线。上线后业务常常会发生变化，例如发展较好数据量增长等，此时会循环进行一些操做，如根据监控数据自动提示优化线上业务，或者人工按期检查或用户反馈来进行优化。后续工做是但愿能够达到自动化模式，即利用监控数据，优化线上服务，自动发现空闲节点和可优化的GROUP。

同时，滴滴也创建了DHS(Didi HBase Service)平台，接入了用户需求，能够可视化信息、自动验证，帮助用户了解服务状态。现在正致力于以更少的人工计算，统计上述更细致的服务相关信息，帮助管理员了解用户使用方式。

本文做者：聒小小噪
阅读原文本文为云栖社区原创内容，未经容许不得转载。