背景
对接业务类型
HBase是建立在Hadoop生态之上的Database，源生对离线任务支持友好，又由于LSM树是一个精良的高吞吐数据库构造，以是同时也对接了很多线上业务。在线业务对访问延迟敏感，并且访问趋向于随机，如订单、客服轨迹查询。离线业务常日是数仓的定时大批量处理任务，对一段韶光内的数据进行处理并产出结果，对任务完成的韶光哀求不是非常敏感，并且处理逻辑繁芜，如天级别报表、安全和用户行为剖析、模型演习等。
多措辞支持
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等。
数据类型
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串。这样既可以保护隐私（只表示大概区域位置而不是详细的点），又比较随意马虎做缓存。
图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的实现有一个清晰的认识，大多数业务用户把更多精力放在了业务逻辑上，对架构实现知之甚少，这就须要平台管理者去不断帮助和勾引，有了好的开端和成功案例后，通过这些用户再去向其他的业务方推广。资源隔离掌握则帮助我们有效减少集群的数量，降落运维本钱，让平台管理者从多集群无止尽的管理事情中解放出来，将更多精力投入到组件社区跟进和平台管理系统的研发事情中，使业务和平台都进入一个良性循环，提升用户的利用体验，更好地支持公司业务的发展。
