【导语】外部数据源采集是在线风控系统的第一步,数据采集的运行效率和高可用性对线上风控系统的风控质量有重要的意义。今天就来介绍一下拍拍贷的数据源采集系统。
现状
目前已对接了公司内部十几条业务线,对外实现了近百种数据源的采集工作,99.9%的采集工作能够在10s内完成。很好的保障了公司风控系统的运作。
一般来说我们的采集流程是这样的:
技术架构
由于需要支持公司所有产品风控流程,外部数据源采集需要支持很高的并发量。因此在技术选型方面,基于高并发高可用以及松耦合的考虑我们选择了SpringCloud的微服务架构,使用SpringBoot实现的RestAPI应用服务结合 Redis和MQ来保障高并发下的高可用性。
根据外部数据采集流程的特点,我们将整个平台拆解为多个子服务:认证日志服务、通知服务、采集服务、存储服务及查询服务。针对不同服务的特点,我们也采用了不同的设计策略:
- 通知服务负责接收业务线的采集指令,并发布到MQ中,尽量减少I/O操作使其能够支持业务线很高的并发量。
- 存储服务负责将采集到的数据写入数据库中,由于数据量非常巨大,我们存储采用了mysql分库分表的设计方式,存储服务的接口我们采用了尽量通用的设计,将复杂的sql拼写封装在了内部实现中,对外尽量保证一致接口形式。
- 在认证日志服务中,我们集成了采集权限管理,日志记录,认证状态记录等功能,拆解了其他几个的服务之间的耦合度,同时集中了管理控制,降低配置复杂度。
- 采集服务可以说是整个系统的核心,它负责调用外部接口并通知存储,因此单个任务一般比较耗时,很容易成为整个系统的瓶颈,因此我们我们水平扩展了数十台服务,订阅MQ的不同partitions来保证采集性能。
由于外部数据供应商的数据结构的差异性,我们抽象了处理逻辑形成固定的模版方法,在不同的子类中自定义解析逻辑,在解析时我们采用了对JSON非常友好且能够与Java无缝对接的Groovy语言来完成,大大提高了开发效率。
问题追踪和系统监控
对于我们采集系统来说,有几项关键的指标:
- 时效性:通知采集到数据落库时长
- 报错率:采集报错数量/采集次数
- 查得率:外部数据查询有数据次数/外部数据查询总次数
这些指标的稳定往往意味着风控系统输出结果的稳定,但与此同时这些指标往往都依赖外部供应商或者网络情况,比较不稳定,一有风吹草动就会影响风控系统的运作, 因此这些指标的实时监控及异常的预警就显得尤为的重要。
为了应对这样的挑战,首先我们使用Cat来实现在API层和SQL执行层的监控:
我们在系统处理任务的几个关键节点:通知采集,采集查询,结果写入都做了埋点处理。这些埋点会同时写入多个数据系统:日志数据库,KairosDB,以及Kafka。
- 日志数据库我们会做T+1同步线下,进而形成数据日报、月报。
- KairosDB结合Grafana可以形成一些实时统计的可视化图表。
- Kafka的消息可以结合后续流处理程序做复杂的实时指标运算,来做定制化指标的预警和监控。
总结
采用微服务模块化的设计思想,大大降低了我们单个系统的复杂程度,同时又能根据每个服务的特定场景做差异化的技术选型。
当前流程中的大部分环节在基于通用设计的思想下都比较稳定,并不需要做太多的改动,当面对接入新的数据源需求时,我们往往只需要关注数据的解析即可,这大大缩短了每个数据源的接入周期。
目前我们将单个数据源接入周期从原来一周降低到了只需要1~2天,这在以风控为核心的互联网行业中无疑是很重要的竞争力。