HBase在大搜车金融业务中的应用实践-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

HBase在大搜车金融业务中的应用实践

简介: 2017云栖大会HBase专场,大搜车高级数据架构师申玉宝带来HBase在大搜车金融业务中的应用实践。本文主要从数据大屏开始谈起,进而分享了GPS风控实践,包括架构、聚集分析等,最后还分享了流式数据统计,包括数据流、数据合流和服务监控等。

2017云栖大会HBase专场,大搜车高级数据架构师申玉宝带来HBase在大搜车金融业务中的应用实践。本文主要从数据大屏开始谈起,进而分享了GPS风控实践,包括架构、聚集分析等,最后还分享了流式数据统计,包括数据流、数据合流和服务监控等。
以下是精彩内容整理:

数据大屏实践

最近几年二手车业务发展非常迅猛,大搜车一直做B端的业务,我们在B端里面4S店的市场占有率已经达到90%以上。今年年初我们觉得时机成熟了,我们就做了弹个车,它是比较典型的汽车金融。无论是车商业务,还是金融业务,都对我们数据采集、数据整理、数据使用提出了非常多的挑战。而HBase性能比较稳定,也可以水平拓展,很好地支撑了我们的业务。

1


图为我们其中一个数据大屏,它是上海地区弹个车业务一个小时以内的行驶轨迹,看起来还是比较震撼的。该大屏还有一个配置的页面,用户可以选择时间、城市,业务同学可以自己配备报表,方便他们对外做一些商务事务。

2


我们看一下报表是如何实现的。这个报表的数据源来自车载GPS设备,GPS设备会定时上报一些数据,包括精度、纬度、点火状态的数据,这些数据会先经过GPS上报,会做状态的管理、里程,之后生成想要的报表,数据到达终点。这个数据会通过数据网关,数据网关是对外提供产品都要经过的地方,并且会进行系统跟踪等。车载设备上传各种的基础数据会存到GPS。针对这个场景,我们根据时间、城市来查数据,所以我们要对报表单独建立一个索引。因为我们在查数据的时候,这个场景只需要精度和纬度,这样在查数据的时候直接在索引中就可以完成所有数据查询,不用再回主表,大大减少了产品的耗时。

3


我们在报表的应用层也做了一些优化,大屏里面是该地区所有车辆轨迹,这个数据量是非常巨大的,如果直接浏览就会卡死,所以我们首先做了分片。刚开始只查询一个小时的少量数据,这个数据拿到以后开始渲染,数据请求下一时间段的数据,前端渲染是不停的,后端数据也一直往上堆积,所以我们在打开页面的时候可以立即开始整个页面的展示。另外,因为数据传输非常频繁,使用Websocket减少建立 HTTP 请求耗时。

4


刚才的大屏是离线大屏,而现实中实时业务大屏非常常见,这是弹个车实时成交数据大屏。大屏数据来自我们的业务埋点日志,大屏当中也会用到基础的纬度数据,我们直接拉到了MySQL,我们内部的计算框架会根据MQ进行数据的处理,组装成我们需要的数据,放到终点Phoenix当中。

GPS风控实践

5


对汽车金融来说风控是生命线,如果风控搞不好分分钟就会破产。我们有一个轨迹监控大屏,通过时间和车辆可以察看车辆在一段时间内的型式轨迹,它的速度、地理位置,还有后台可以设置一些风险区域,比如澳门赌场等正常用户应该不会去的地方,这些地方出没的会有一些贷款风险。还有风控模型,GPS里面会把各种数据统计为模型特征,再交给模型,最后由风控引擎针对这些线上数据判定有没有特征,发出报警。

业务架构

6


最早设备是来自厂商上报的,后来因为对接的厂商比较多,发现了一些故障。我们上报到网关,包括设备注册、状态维护、里程纠偏,设计运营环境非常复杂,有可能这辆车没有电了,里面存储的数据没有了,也有可能跑到非常偏远的地方,没有办法上报数据,还有一些上报的里程非常奇怪,本来是两万多,突然变成一万,表现在数据上可能会是非常诡异的点,。针对这部分,我们做了一些清洗,比如说偏移,我们会根据前后一些点的关系做一些数据的过滤。还有里程纠偏,我们对时间做了一些分片,每分钟都会有一个点,我们会统计这分钟结束时间减去起始,计算出真正的里程,可以对这块数据作出处理,对一天的影响就非常小。我们在这里花了大量的精力,一大半时间都在清洗数据。
接下来数据通过MQ到HBase,实时轨迹、电子围栏、停留点分析、聚焦分析,这些数据会和材料验证一块提供给我们的贷后运维同学来判断风险。我们发现很多骗贷的并不是个人,而是一些机构,有些村子都是骗贷的团伙,有些是负责伪造材料,有些是负责申请贷款,我们针对这些场景,把每个车的具体情况分析出来,因为正常是面向C端用户,不应该大量车聚焦在一个地方。最后这些数据进入到预警后台。

聚集分析

7


使用GeoHash先对地球进行二维平面化,把地球分成好多个区域,对每一个区域再分成32个区域,不断地细分,让一个区域不断地精确。Base32编码字符串,每个字符由5bit 组成。将每辆车的停留点算出来,再把停留点算出GeoHash值,按照这些区域聚合好选择聚合的点,算出每一个点到底有多少辆车,最后形成一个特征,生成模型。
数据存储部分,原始轨迹支持按设备、时间维度查询详细轨迹,查聚集点按区域、时间维度查询聚集数据。

流式数据统计

8


有些车辆列表大家看到的并不是动态的,会根据流量数量、地理位置来决定一个智能点的排序,这就需要很多特征、流式计算的场景。全国实时车交数据和报表,产品经理都比较人性化,所有数据都想立刻在报表里面更新,所以这些也是我们主要的场景。
这些业务特点:
  • 实时数据间隔非常短,我们会要求10秒或者5秒的时间窗口就要更新过来;
  • 数据量比较大,我们遇到了一些百万兆、亿兆的;
  • 这些场景还有并发要求,毕竟是线上业务,我们是一个B端业务,所以对内部要求还没有太高,100QPS就可以满足我们这个阶段的要求;
  • 业务变化非常快,如果一个需求真的做一个月,做完了以后规则就变了,所以查询纬度很多、变化很大,针对这些我们会细分一些性能,然后提高开放的速度。

    9


这是数据流,最多的数据还是来自RDS,把数据库的各种数据变更转化成MQ消息,再加上以前还有很多埋点消息都会统一到MQ。所有数据会在我们计算框架里面聚合起来,按照我们的业务场景把它放在Phoenix里面,先放到明细数据。我们针对每个场景单独聚合好,可以直接查询。还有一些场景计算量很大,会有一些统计数据,以此来支撑我们的线上业务。A、B、C业务通过数据网关来访问数据。

10


数据合流是我们现在遇到的比较大的问题,有一个定单表,里面有金额、品牌等等,需要把所有数据合并到一起提供服务,对流式处理来说这个问题非常棘手,因为数据是流式到达的,而且到达是无序的。我们也做了一些处理,对每一个处理流里面立一个表为主表,每次数据到达的时候会有一个监测模块,看是否符合合流条件,会从库里面检查数据是否真的到达了,按照业务规则组合数据。这里也要做优化,并不是直接查,是要经过数据缓存。

11


性能测试方面我们找最低配的集群,Master(2C4G)+CORE(4C8G)×2,数据量:—100Million,这对我们场景来说已经绰绰有余,再加上Phoenix性能的拓展非常方便。这些性能测试其实跟性能条件关系非常大,这只是我们内部的测试,更标准的数据还要参考官方的数据。

12


服务监控上,流式和离线不太一样,流式数据一天24小时在线,所以它的稳定性非常重要,不能跑着跑着就挂了。阿里云后台本身的监控可以看到一些机器的信息。另外,我们内部开发了一套业务监控系统,我们所有请求都是通过数据网关,数据网关的重要功能就是整个服务的监控,它每次访问都会记一个日志,日志里面有访问的数量、访问的时间,按表来查,这样对我们查询问题帮助非常大。另外,我们业务监控系统也有移动版,以前出什么问题在公交车上都得拿出电脑,现在直接在移动端里查,比较方便。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: