"HBase drops travel in application scenarios and best practices."

HBase drops travel in application scenarios and best practices

 

background

 

Docking type of business

 

HBase is built on top of Hadoop ecological Database, Primal offline task support and friendly, but also because the LSM tree is an excellent high-throughput database structure, as well as docking a lot of online business. Online access to latency-sensitive business, and tend to be random access, such as orders, track customer inquiries. Offline service usually is a timing bulk bin number of processing tasks on the data over time processing and outputs the result, the time required to complete the task is not very sensitive, complex and processing logic, such as days level reports, security and user behavior analysis, model training.

 

Multi-language support

HBase provides multilingual solutions, and because of the development of language and pieces of each business line RD used their own preferences, so multi-language support for HBase in the development of the internal bit is a crucial part. We provide a way for users to access multiple languages: HBase Java native API, Thrift Server (mainly used in C ++, PHP, Python), JAVA JDBC (Phoenix JDBC), Phoenix QueryServer (multi-language Phoenix provide external solutions), MapReduce Job (htable / hfile Input), Spark Job, Streaming and the like.

type of data

HBase drops in the main storage of the following four types of data:

• Statistics, data reporting classes: major operators, the result of capacity, income, etc., usually with Phoenix SQL queries. The amount of data is small, high flexibility requirements of the inquiry, the delay requirements in general.
• Original factual data: such as orders, GPS track driver passenger, logs, mainly used for supplying data online and offline. Large amount of data for consistency and high availability requirements, delay-sensitive, real-time written, single or batch query.
• Intermediate results data: refers to the data model training needs. Large amount of data availability and consistency of the general requirements, throughput requirements of high-volume queries.
• Online data backup system: the original user data exists in a relational database or other file services, the HBase as a Disaster Recovery solution.

 

Introduction usage scenarios

 

Scene One: Order Event

This data is used by bit product users should have contact with, it is the history of the order on the App. Recent orders inquiry will fall Redis, over a certain time frame, or when Redis is unavailable, the query will fall on HBase. Business demand side is as follows:

 

• Online poll various status of the order life cycle, including status, event_type, order_detail and other information. The main query from the customer service system.
• Online order history details of the query. Redis to store the near future there will be the top of the order, when Redis Redis not exceed the scope of use or query, the query straight into HBase.
• Offline analysis of the status of the order.
• 10K per second writing event to meet the reading event satisfies 1K per second, the available data required 5s.

 

FIG 1 order flow data flow

According to these requirements, we made the following design Rowkey, are very typical scan the scene.

 

Order Status Table

RowKey: Reverse (order_id) + (MAX_LONG - the TS)
the Columns: the various states of the line

Orders history table

RowKey: Reverse (passenger_id | driver_id) + (MAX_LONG - TS)
the Columns: customer orders within the time frame and other information

 

Scene 2: The driver passenger trajectory

This is a bit close to the user data, online users, and pieces of various lines of business and analysts will use. A few examples of the use of the scenario: When users view order history, through which the route is displayed on the map; passengers disputes occur, call customer service orders Locus scene scene; the map user sector analysis of road congestion.

 

FIG 2 occupant trajectory data flow

Users who proposed requirements:

• Meet the real-time or near real-time trajectory App users or back-end analyst coordinate inquiries;
• Large-scale track meet off-line analysis;
• Satisfies a given geographical area specified, all users within appears taken over a range or ranges of tracks user.

其中，关于第三个需求，地理位置查询，我们知道MongoDB对于这种地理索引有源生的支持，但是在滴滴这种量级的情况下可能会发生存储瓶颈，HBase存储和扩展性上没有压力但是没有内置类似MongoDB地理位置索引的功能，没有就需要我们自己实现。通过调研，了解到关于地理索引有一套比较通用的GeohHash算法 。

GeoHash是将二维的经纬度转换成字符串，每一个字符串代表了某一矩形区域。也就是说，这个矩形区域内所有的点（经纬度坐标）都共享相同的GeoHash字符串，比如说我在悠唐酒店，我的一个朋友在旁边的悠唐购物广场，我们的经纬度点会得到相同的GeoHash串。这样既可以保护隐私（只表示大概区域位置而不是具体的点），又比较容易做缓存。

图3 GeoHash示意图

但是我们要查询的范围和GeohHash块可能不会完全重合。以圆形为例，查询时会出现如图4所示的一半在GeoHash块内，一半在外面的情况（如A、B、C、D、E、F、G等点）。这种情况就需要对GeoHash块内每个真实的GPS点进行第二次的过滤，通过原始的GPS点和圆心之间的距离，过滤掉不符合查询条件的数据。

 

图4 范围查询时，边界GeoHash块示意图

最后依据这个原理，把GeoHash和其他一些需要被索引的维度拼装成Rowkey，真实的GPS点为Value，在这个基础上封装成客户端，并且在客户端内部对查询逻辑和查询策略做出速度上的大幅优化，这样就把HBase变成了一个MongoDB一样支持地理位置索引的数据库。如果查询范围非常大（比如进行省级别的分析），还额外提供了MR的获取数据的入口。

两种查询场景的Rowkey设计如下：

• 单个用户按订单或时间段查询： reverse(user_id) + (Integer.MAX_LONG-TS/1000)
• 给定范围内的轨迹查询：reverse(geohash) + ts/1000 + user_id

 

场景三：ETA

ETA是指每次选好起始和目的地后，提示出的预估时间和价格。提示的预估到达时间和价格，最初版本是离线方式运行，后来改版通过HBase实现实时效果，把HBase当成一个KeyValue缓存，带来了减少训练时间、可多城市并行、减少人工干预的好处。

整个ETA的过程如下：

• 模型训练通过Spark Job，每30分钟对各个城市训练一次；
• 模型训练第一阶段，在5分钟内，按照设定条件从HBase读取所有城市数据；
• 模型训练第二阶段在25分钟内完成ETA的计算；
• HBase中的数据每隔一段时间会持久化至HDFS中，供新模型测试和新的特征提取。

 

Rowkey：salting+cited+type0+type1+type2+TS
Column：order, feature

 

图5 ETA数据流程

场景四：监控工具DCM

用于监控Hadoop集群的资源使用（Namenode，Yarn container使用等），关系数据库在时间维度过程以后会产生各种性能问题，同时我们又希望可以通过SQL做一些分析查询，所以使用Phoenix，使用采集程序定时录入数据，生产成报表，存入HBase，可以在秒级别返回查询结果，最后在前端做展示。

 

图6 DCM数据流程

图7、图8、图9是几张监控工具的用户UI，数字相关的部分做了模糊处理。

 

图7 DCM HDFS按时间统计使用全量和增量

图8 DCM HDFS按用户统计文件数

图9 DCM，MR Job运行结果统计

 

滴滴在HBase对多租户的管理

我们认为单集群多租户是最高效和节省精力的方案，但是由于HBase对多租户基本没有管理，使用上会遇到很多问题：在用户方面比如对资源使用情况不做分析、存储总量发生变化后不做调整和通知、项目上线下线没有计划、想要最多的资源和权限等；我们平台管理者也会遇到比如线上沟通难以理解用户的业务、对每个接入HBase的项目状态不清楚、不能判断出用户的需求是否合理、多租户在集群上发生资源竞争、问题定位和排查时间长等。

针对这些问题，我们开发了DHS系统（Didi HBase Service）进行项目管理，并且在HBase上通过Namespace、RS Group等技术来分割用户的资源、数据和权限。通过计算开销并计费的方法来管控资源分配。

图10 DHS项目表监控

DHS主要有下面几个模块和功能：

• 项目生命周期管理：包括立项、资源预估和申请、项目需求调整、需求讨论；
• 用户管理：权限管理，项目审批；
• 集群资源管理；
• 表级别的使用情况监控：主要是读写监控、memstore、blockcache、locality。

 

当用户有使用HBase存储的需求，我们会让用户在DHS上注册项目。介绍业务的场景和产品相关的细节，以及是否有高SLA要求。

之后是新建表以及对表性能需求预估，我们要求用户对自己要使用的资源有一个准确的预估。如果用户难以估计，我们会以线上或者线下讨论的方式与用户讨论帮助确定这些信息。

然后会生成项目概览页面，方便管理员和用户进行项目进展的跟踪。

HBase自带的jxm信息会汇总到Region和RegionServer级别的数据，管理员会经常用到，但是用户却很少关注这个级别。根据这种情况我们开发了HBase表级别的监控，并且会有权限控制，让业务RD只能看到和自己相关的表，清楚自己项目表的吞吐及存储占用情况。

通过DHS让用户明确自己使用资源情况的基础之上，我们使用了RS Group技术，把一个集群分成多个逻辑子集群，可以让用户选择独占或者共享资源。共享和独占各有自己的优缺点，如表1。

表1 多租户共享和独占资源的优缺点

根据以上的情况，我们在资源分配上会根据业务的特性来选择不同方案：

• 对于访问延迟要求低、访问量小、可用性要求低、备份或者测试阶段的数据：使用共享资源池；
• 对于延迟敏感、吞吐要求高、高峰时段访问量大、可用性要求高、在线业务：让其独占一定机器数量构成的RegionServer Group资源，并且按用户预估的资源量，额外给出20%~30%的余量。

 

最后我们会根据用户对资源的使用，定期计算开销并向用户发出账单。

 

RS Group

RegionServer Group，实现细节可以参照HBase HBASE-6721这个Patch。滴滴在这个基础上作了一些分配策略上的优化，以便适合滴滴业务场景的修改。RS Group简单概括是指通过分配一批指定的RegionServer列表，成为一个RS Group，每个Group可以按需挂载不同的表，并且当Group内的表发生异常后，Region不会迁移到其他的Group。这样，每个Group就相当于一个逻辑上的子集群，通过这种方式达到资源隔离的效果，降低管理成本，不必为每个高SLA的业务线单独搭集群。

 

图11 RS Group示意图

 

总结

在滴滴推广和实践HBase的工作中，我们认为至关重要的两点是帮助用户做出良好的表结构设计和资源的控制。有了这两个前提之后，后续出现问题的概率会大大降低。良好的表结构设计需要用户对HBase的实现有一个清晰的认识，大多数业务用户把更多精力放在了业务逻辑上，对架构实现知之甚少，这就需要平台管理者去不断帮助和引导，有了好的开端和成功案例后，通过这些用户再去向其他的业务方推广。资源隔离控制则帮助我们有效减少集群的数量，降低运维成本，让平台管理者从多集群无止尽的管理工作中解放出来，将更多精力投入到组件社区跟进和平台管理系统的研发工作中，使业务和平台都进入一个良性循环，提升用户的使用体验，更好地支持公司业务的发展。