是骡子是马，拉出来溜溜 ——阿里云HBase在大搜车的试用

        大搜车，中国领先的车商服务平台。凭借多年对汽车行业的深刻洞察与理解，推出了适合汽车经销商集团及大型二手车商的业务经营管理系统“大风车”，适合中小二手车商的经营管理系统“车牛”，汽车消费延保产品“大搜车质保”以及基于蚂蚁金服开放平台赋能的［信用购车 先用后买］金融服务方案—“弹个车”，为车商提供软件服务、金融服务、交易服务及营销服务等，助力经销商提高管理及盈利能力。现已成功为全国超过70%的二手车经销商提供了全方位的业务支持。

        大搜车的业务线众多,对数据的需求也多种多样。其中一条数据流为离线数据, 数据从业务数据库中经过 ETL 工具 将数据导入 Hive 中，生成数仓所需的各层数据，最终将统计数据导入 Mysql 中，另一条数据线将日志,埋点等实时数据导入阿里云HBase，同时在OpenSearch 中产生必要的索引, 最后通过数据网关对外提供实时的服务.

 实时业务线中，要处理 TB 级的的数据量,同时又要保证读写的效率，在数据库的选择上。经过多重考虑，最终决定采用阿里云HBase 来处理这些数据。

选择阿里云HBase主要基于以下考虑：

1 大搜车的数据整体的技术栈都是基于 Hadoop, HBase是Apache的Hadoop项目的子项目，阿里云HBase 完全兼容 Apache HBase 的接口,选择阿里云HBase可以更好的同其他设施集成:

l Spark 可以方便得读写 HBase 中的数据

l 通过 Flume 可以将 Kafka 中的数据写入阿里云 HBase

2  阿里云HBase 相较于其他方案，可以提供更强大的查询功能：

阿里云 HBase 完全兼容了社区版本的接口, Hbase 中原有丰富的过滤器仍可以使用在阿里云 Hbase。同时社区中 Phoneix 等 SQL 方案也在逐渐成熟, 后期 SQL ON HBase 也有更多的选择。

3  由阿里云承担基础运维, 服务更有保障。

Hbase 要提供线上服务, 服务稳定性的要求更高。对于没有运维经验的团队来说, 阿里云 HBase 是更好的选择。这个也是吸引大搜车使用阿里云 Hbase 最主要的原因. 阿里云承诺9个9的稳定性，超过自己可以实现的运维能力。

于是在调研后, 首先被应用到阿里云HBase上的业务是一个新业务——基础服务中的 GIS 服务。存储了大量GPS上报的地理位置数据, 并提供风控后台的数据接口。

大致的业务模型为每分钟各个厂商将 GPS 数据上传到大搜车的服务器(ECS)上,  数据经过 Flume 处理并做简单的完整性过滤后, 先进行基础的统计, 例如每个设备的里程汇总, 离线时间统计等, 用来提供实时的业务报警. 之后数据会被导入 Hbase 中, Rowkey 采用 散列后的设备 ID + 时间戳.用来提供单个设备的轨迹查询. 

随着业务的发展,后面产生了新的需求: 绘制 GPS 的行驶轨迹。这是需要再进行一层汇总, 将原始的 GPS 轨迹进行过滤, 去除重复的轨迹, 寻找轨迹中的拐点, 实现最少的轨迹点来描述车辆的行驶轨迹。技术上可以通过 Spark 定时从 Hbase 中获取数据, 进行汇总后再写入一张新的 Hbase 表, 作为过滤后的轨迹记录。

大致如下图所示：

现在真实业务上线只有两周, 日写入数据 GB 级别，总体感觉目前系统还没有出现运维问题，解决了后顾之忧，而且与社区版本完全兼容，避免了不必要的工作量，创业公司的时间就是金钱，这里点一个大大的赞。

经过这次尝试，阿里云的HBase的成绩有目共睹，后续大搜车内实时的业务也会陆续从自建的Hbase迁移到阿里云Hbase 中,减少运维的风险。

    最后, 使用中也感受到一些不足,但愿阿里云HBase在这些方向上可以走的更远一些, 让开发者更方便一些:

1. SQL ON HBase:这个版本并没有提供 SQL 的接口,不过这个已经是大势所趋, 不知道后续阿里云会基于 Phoneix 来提供服务还是会自己实现一套。

2. 更灵活的 TTL: 当前 TTL 需要在建表时指定, 使用时不是很灵活, 如果可以想 MemCached 等 针对每条数据设置单独的 TTL 将会使使用场景灵活更多。

3. 更多的调试工具: 目前阿里云 HBase 并没有提供数据管理的工具, 还是基于 Hbase Client,  希望也能像 RDS 一样提供一套好用的管理工具。

4. 开发与测试环境: 阿里云 HBase 只能在阿里云内网环境访问, 开发环境无法访问.  目前阿里云 Hbase 和社区版完全兼容, 这个问题还不明显, 总归可以自己搭一份相同的版本, 不过后面等阿里云版本有了更多的特性, 就需要提供工程师本地开发与测试的方案。