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

重庆海尔云链科技有限公司成立于 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 引擎作为备选计划。

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