HBase在滴滴出行的应用场景和最佳实践

HBase在滴滴主要存放了以下四种数据类型：

1. 统计结果、报表类数据：主要是运营、运力情况、收入等结果，通常需要配合Phoenix进行SQL查询。数据量较小，对查询的灵活性要求高，延迟要求一般。

2. 原始事实类数据：如订单、司机乘客的GPS轨迹、日志等，主要用作在线和离线的数据供给。数据量大，对一致性和可用性要求高，延迟敏感，实时写入，单点或批量查询。

3. 中间结果数据：指模型训练所需要的数据等。数据量大，可用性和一致性要求一般，对批量查询时的吞吐量要求高。

4. 线上系统的备份数据：用户把原始数据存在了其他关系数据库或文件服务，把HBase作为一个异地容灾的方案。

 

使用场景介绍

场景一：订单事件

这份数据使用过滴滴产品的用户应该都接触过，就是App上的历史订单。

近期订单的查询会落在Redis，超过一定时间范围，或者当Redis不可用时，查询会落在HBase上。

业务方的需求如下：

1. 在线查询订单生命周期的各个状态，包括status、event_type、order_detail等信息。主要的查询来自于客服系统。

2. 在线历史订单详情查询。上层会有Redis来存储近期的订单，当Redis不可用或者查询范围超出Redis，查询会直接落到HBase。

3. 离线对订单的状态进行分析。

4. 写入满足每秒10K的事件，读取满足每秒1K的事件，数据要求在5s内可用。

按照这些要求，我们对Rowkey做出了下面的设计，都是很典型的scan场景。

订单状态表

Rowkey：reverse(order_id) + (MAX_LONG - TS) 
Columns：该订单各种状态

订单历史表

Rowkey：reverse(passenger_id | driver_id) + (MAX_LONG - TS) 
Columns：用户在时间范围内的订单及其他信息

 

场景二：司机乘客轨迹

这也是一份滴滴用户关系密切的数据，线上用户、滴滴的各个业务线和分析人员都会使用。

举几个使用场景上的例子：用户查看历史订单时，地图上显示所经过的路线；发生司乘纠纷，客服调用订单轨迹复现场景；地图部门用户分析道路拥堵情况。

用户们提出的需求：

1. 满足App用户或者后端分析人员的实时或准实时轨迹坐标查询；

2. 满足离线大规模的轨迹分析；

3. 满足给出一个指定的地理范围，取出范围内所有用户的轨迹或范围内出现过的用户。

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

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

 

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

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

1. 单个用户按订单或时间段查询： reverse(user_id) + (Integer.MAX_LONG-TS/1000)

        通过ID查询轨迹
       Rowkey：ID+Timestamp
       Column:轨迹详细信息
       提供javaAPI给用户使用

2. 给定范围内的轨迹查询：reverse(geohash) + ts/1000 + user_id

场景三：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

场景四：监控工具DCM

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

 

 

https://mp.weixin.qq.com/s?__biz=MzA3MDY0NTMxOQ==&mid=2247484343&idx=1&sn=cd0c5bd1fbd8d55dd9779d336880bb3d&chksm=9f38e09fa84f6989105d027e60beb463332313724813ea114ec3f4e29707c8da75fc09434269&scene=21#wechat_redirect