海尔云链科技 x StarRocks|金融数据查询增速三倍,服务器成本减半

本文发表于: &{ new Date(1646582400000).toLocaleDateString() }

作者:王沐,海尔云链科技有限公司数字金融部大数据架构资深开发工程师,负责海尔云链大数据架构设计和开发,以及数字化应用的开发和建设。

重庆海尔云链科技有限公司成立于 2006 年,作为行业领先的科技场景生态平台,以科技为第一生产力,以消费金融场景为着力点,形成了具备统一支付、数据交换、动态 AI 定价、智能作业及云服务等核心能力。

海尔云链科技打造了成熟的针对 B 端、C 端的综合服务体系,形成了对差异化场景和资源的融入与链接能力,以科技赋能持牌金融机构,助力传统机构的数字化转型。云链科技的金融科技、智能风控及智慧运营等三大解决方案,已在医美、通讯、车、普惠、教育等多个金融场景中应用。

业务背景及其历史架构痛点

金融信贷业务

在传统的金融信贷业务中,业务系统主要划分为贷前、贷中、贷后三个阶段(客户信息录入、放款、贷款清收),而从数据角度出发主要分为贷前和贷后两个阶段(按照是否放款进行区分)。

贷前阶段主要是进行客户个人信息相关的数据处理,相对贷后阶段数据较少,一般较多结合业务系统、在传统的关系型数据库中处理。

贷后的数据量会膨胀为贷前的几十倍(例如房贷、车贷,一个客户成功申请会随之带来几十上百条的账单信息),加上代扣等操作带来的数据量再次膨胀,导致传统的关系型数据库在处理贷后数据时负担极大,每天都需要进行部分数据归档迁移。

然而,贷后的数据极为重要,客户、合作助贷方、渠道、商户、业务人员、财务部门都需要不同的贷后数据,而且大多都需要实时数据。

查询特点上,这些业务方会定时、不定时来获取各个维度的数据,包括历史数据。这导致基于传统关系型数据库的核心业务系统负担极大。

核心诉求

基于以上现实情况,我们开始探索基于大数据处理,打造一个能对内、对外提供实时、离线计算和查询的贷后处理系统。这个系统需要能解决以下各个问题:

  1. 提供实时数据以及批量数据写入、更新的能力;
  2. 能提供大数据量下的数据快速查询能力;
  3. 能提供 SQL 或者类 SQL 的语言,便于报表系统或者业务人员操作;
  4. 能够有较好的数据容灾副本机制;
  5. 能够提供较好的并发支持能力。

主流处理方案

行业内主流处理方案分为如下几种,一般采用其中一种或者多种组合使用:

  1. 数据量相对较小,使用关系型数据库的只读库或者备库,为贷后数据业务提供支撑。该方案使用没有什么问题,也比较成熟;缺点很明显,关系型数据库处理数据量级有限。
  2. 数据量大,使用 ETL 工具将数据写入大数据系统,采用 Hbase+Phoenix 的方案,基于 Phoenix 对外提供数据支撑。该方案能够处理大量数据,也能通过 ETL 将离线数据统一跑批写入 Hbase;缺点是只能做大宽表,而且数据处理流程相对复杂。
  3. 数据量大,依旧使用 ETL 工具将数据写入 ClickHouse。该方案能处理大量数据,也可以做离线数据的统一处理;缺点也是大多做大宽表,而且数据实时性更新能力不强,并发支持也不强。
  4. 数据量大,依旧使用 ETL 工具将数据写入 Hive,基于 Impala、Presto 等方式对外提供数据,或者使用 Druid 等。这几个方式的缺点都是无法完成实时更新且并发能力较弱。

历史架构

基于上述情况,海尔云链科技第一代金融贷后数据处理系统诞生。受限于历史技术条件、业务数据规模和成本考量,第一代金融贷后数据架构的链路较为复杂、数据存在一定冗余,如下图所示。

具体来说,数据从各个核心业务数据库通过 ETL 平台将实时、离线数据汇集到 Hadoop 集群中。数据根据实时性以及数据量被分别写入到 Hbase 与 Hive,结合 Phoenix、Alluxio+Presto 对外统一提供数据。用户通过前端系统调用配置等多种方式获取数据。

在实时数据方面,由于金融数据要求实时可变动,且针对多个部门渠道有不同的数据要求、数据获取的条件灵活多变,而业务部门期望查询都能快速响应,由此建立了大量二级索引。在金融业务中,每天晚上核心业务系统数据会进行大量账务计算,每月还有一个定期数据入账日。面临这种短时间、超大批量数据进入的任务,大数据集群的 Hbase 会出现巨大的写入延迟,同时集群 CPU 拉升、性能大幅下降。

在离线数据方面,由于数据量和业务复杂度的上升,以及客户对 BI 系统的期望越来越高,数据平台对离线分析数据进行了多次升级。在 Hive+Presto 的基础上再附加 Alluxio 作缓存,直接导致系统硬件成本翻倍,并且加大了运维成本。

新 OLAP 引擎选型

进行 OLAP 引擎选型前,首先需要了解大数据金融行业的数据特性:

  1. 数据时效性高,且需要实时或者准实时更新;
  2. 每天、每月有日终、月终结算,会短时间产生大量的变动日志数据;
  3. 数据量差异明显,扣款处理明细等日增量数据之间存在千万级别的差别;
  4. 数据维度丰富,查询条件多样且易变,查询聚合能力要求高。

为了解决以上问题,海尔云链在 2021 年年中对市面上的主流 OLAP 引擎进行了调研选型测试。数据更新的高要求直接剔除了绝大多数产品,一轮初选后我们暂定了两款 OLAP 引擎作为备选方案。

OLAP 产品

优点

缺点

ClickHouse

单机性能强悍

类 SQL语法支撑

丰富的函数

可以大幅降低当前服务器成本

数据更新能力一般

并发支撑能力不足

大宽表模型数据灵活度较差

运维成本较高

StarRocks

支持 MySQL 协议,支持标准 SQL

多表关联性能非常好,数据灵活建模

支持高并发查询

Hive外表查询性能优异

支持实时数据更新

运维简单

可以大幅降低当前服务器成本

新晋产品,参考案例和方案资料还较少

在此之后,我们进行了单表和多表关联查询性能测试。测试结果显示,在单表查询上,两者表现相近,大多数情况下均能在毫秒级别返回结果,而 StarRocks 在部分查询上更快速。在多表关联查询上,StarRocks 速度明显优于 ClickHouse,且在并发查询时优势更明显。综合评判下来,我们最终选择了 StarRocks。

 

架构升级

 

升级效果

引入 StarRocks 后,我们在实时处理方面用 StarRocks 替代了以前的 Hbase+Phoenix,离线数据方面也部分用 StarRocks 替代了 Hive+Alluxio+Presto。

迭代新架构后,查询效率大幅提升。下图所示对比测试是在 StarRocks v1.19.0,CentOS 7.8 上进行的。响应速度方面,以前是 90% 查询在 5s 内、99% 查询在 10s 内,如今是 90% 查询在 1s 内、99% 查询在 3s 内。Hive 外表查询方面,之前是 99% 在 35s 内返回,如今是 99% 在 5s 内返回,查询平均耗时得到了大幅缩减。

此外,通过升级改造,服务器成本整体减低到接近原体系架构的一半。以前使用多服务多组件,如今统一到 StarRocks,使得运维成本也得到了大大降低。

 

业务应用

金融贷后业务,要查询贷款业务的本金、利息、罚息等指标,需对两张表做关联查询。在核心业务的关系型数据库查询语句如下:

存在两个表:

a 表为贷款每期次的本金、利息、罚息等相关的数据,主键为贷款的编号以及期次;b 表为单个贷款的还款信息,主键为贷款编号。

当需要计算已还款相关的本金、利息、罚息,或者某日待还款等信息时,我们需要将两个表进行关联。同时按照贷款编号聚合 a 表的本金、利息、罚息,与 b 表的数据进行对比计算,以获取需要的指标结果。

但是当贷后数据需要被转入第一代贷后数据系统时,受限于早期组件能力,必须构建大宽表模型,将 a、b 表部分字段整合。整合又带来了如下问题:第一,增添了 ETL操作以及数据质量追溯的复杂性;第二,造成数据冗余,增加了数据治理成本。

选型 StarRocks 后的新一代贷后系统,对关联查询的支持非常友好。我们可以直接通过 ETL 将数据源实时无修改的写入,恢复业务原貌的同时还能满足业务需要,大大降低了 ETL 复杂度。此外,我们还能利用聚合模型提升聚合数据的支撑性能。

StarRocks 的多种模型,支持金融数据根据数据和业务特性,选择最优的解决方案。在上一代贷后系统中,业务代扣信息相关数据只存在新增,数据日增在千万级别。业务部门需要根据业务主键和时间段进行查询,又要附带其他的业务信息,导致这个表字段又多、数据量又大。涉及该表的一些查询都需要 10s 左右,还存在 Hbase 分裂处理、索引设计等一系列复杂情况。

在新一代的贷后系统中,通过利用 StarRocks 的明细模型,可以自动按照日期分区、去除冗余字段、缩减单表数据大小。涉及到该表的相关查询,最多不到 3s 就可以返回结果,并且大部分查询在 1s 内就能完成。

如今,业务部门会议已经无需提前准备数据,会议现场可以直接从贷后系统获取最新实时数据、聚合报表等。申报数据延迟、查询缓慢等问题,也从之前周周提报到现在消声灭迹。

 

总结与规划

在使用 StarRocks 作为新技术架构后,海尔云链充分利用 StarRocks 不同模型,StarRocks 卓越的关联查询能力使得数据灵活性大大提升,查询效率得到了 3-7 倍的提升。

由于新架构不存在老架构索引过多导致数据写入缓慢的问题(如在日终或月度入账时,短时间产生的大量日志数据会在短时间内被处理),并且支持根据数据业务特性选择不同的数据模型,极大解决了业务痛点。

此外,使用 StarRocks 后极大减少了服务器成本,其简单的部署、扩展、监控方式,极大提升了运维效率。

接下来,海尔云链计划在三方面进一步拓展使用 StarRocks:

  1. 在离线处理上,完全迁移扩展到 StarRocks 集群,逐步用 StarRocks 来统一 OLAP 分析全场景;
  2. 扩展使用 StarRocks 的 CBO、物化视图、Hive 外表等功能,进一步降本增效;
  3. 结合当前公司已经开发的 StarRocks 日志处理程序,进一步开发壮大 StarRocks 监控平台。