重庆海尔云链科技有限公司成立于 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 引擎选型前，首先需要了解大数据金融行业的数据特性：
- 数据时效性高，且需要实时或者准实时更新；
- 每天、每月有日终、月终结算，会短时间产生大量的变动日志数据；
- 数据量差异明显，扣款处理明细等日增量数据之间存在千万级别的差别；
- 数据维度丰富，查询条件多样且易变，查询聚合能力要求高。
| OLAP 产品 | 优点 | 缺点 |
|---|---|---|
| ClickHouse | 单机性能强悍；类 SQL语法支撑；丰富的函数；可以大幅降低当前服务器成本 | 数据更新能力一般；并发支撑能力不足；大宽表模型数据灵活度较差；运维成本较高 |
| StarRocks | 支持 MySQL 协议，支持标准 SQL；多表关联性能非常好，数据灵活建模；支持高并发查询；Hive外表查询性能优异；支持实时数据更新；运维简单；可以大幅降低当前服务器成本 | 新晋产品，参考案例和方案资料还较少 |
架构升级
文章图片
升级效果 【金融数据查询增速三倍，服务器成本减半，海尔云链的 OLAP 引擎选型之路】引入 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 监控平台。
