金融数据查询增速三倍，服务器成本减半，海尔云链的 OLAP 引擎选型之路

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

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

“ 作者：王沐，

海尔云链科技有限公司数字金融部大数据架构资深开发工程师，

负责海尔云链大数据架构设计和开发，以及数字化应用的开发和建设 ”

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

金融信贷业务

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

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

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

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

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

核心诉求

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

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

主流处理方案

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

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

历史架构

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

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

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

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

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

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

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

在此之后，我们进行了单表和多表关联查询性能测试。测试结果显示，在单表查询上，两者表现相近，大多数情况下均能在毫秒级别返回结果，而 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：

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