作者｜腾梭科技研发总监刘建波
随着金融全球化和数字化的发展，信贷服务市场规模不断扩大，个人和企业对信贷服务的需求也越来越多样化和细分化，这为信贷服务机构提供了更多的商机和挑战。
作为互联网金融科技公司，腾梭科技（腾讯投资且在金融领域的战略合作伙伴）联合行业内各大友商行，共同提供信贷服务。腾梭科技信贷服务已经从早期的网贷转型为以助贷为核心的业务模式，并开展了全量客群的挖掘，探索线上、线下结合或纯线上贷款全流程业务模式，为新零售金融场景提供微服务技术应用，包括潜在客户信用评估、拒贷款分析、贷后管理、预期催收以及风控管理等方面。
基于业务模式的演进，业务发展基石之系统技术架构也随之发生了变化与升级，从集中式的单机系统转化为分布式场景。由于引入了各大合作银行的TP系统（如MySQL、Oracle、PostgreSQL等），使系统规模不断扩大。而传统的关系型数据库无法完成多种数据源之间的数据关联，架构逐渐出现数据孤岛与数据割裂的现象，因此OLAP引擎的应用成为打破数据孤岛必不可少的工具。对于助贷系统的架构升级，如何进行高效数据采集和处理、如何在庞大的客户数据中准确了解潜在客户需求与信用情况以加快贷款审批速度、如何通过客户数据管理实现高效精准获客、赋能营销策略，成为了我们业务重点发展方向。
为了满足这些要求，腾梭科技历经三代架构演进。第一代架构基于Kettle离线数仓，第二代架构引入Trino进行统一查询，在经过两代架构使用后发现其性能的不足，决定引入OLAP引擎。最终通过产品调研选择ApacheDoris作为第三代架构核心进行数据统一存储与分析。本文将详细介绍三代架构的演进历程和应用实践，分享业务场景落地经验。
架构1.0：基于Kettle+MySQL离线数仓在业务初期，我们使用FlumeSink进行数据采集，利用DolphineScheduler+Shell进行数据调度，基于Kettle抽取离线数据进入关系型数据库中形成离线数仓，进行基础的T+1报表取数工作。由于Kettle仅支持离线取数的功能，不支持数据存储，因此数据始终保存在原始端。随着数据量的不断增大，当事实表条数达到千万级时，Kettle的性能逐渐变得不稳定，单表查询任务的执行时间出现延迟现象，无法满足较大业务规模的使用需求。同时，Kettle不支持多数据源之间的关联查询功能，在TP系统多样的情况下，查询效率无法得到保障。
架构2.0：基于Presto/Trino统一查询针对第一代架构存在的问题，我们在第二代架构升级中借助Trino作为分布式SQL查询引擎进行联邦查询，实现多种类型数据源的即席查询和批量ETL查询，打通信贷、风控之间的多源异构数据查询需求。由于Trino缺少存储和管理元数据的功能，在面对高并发点查场景下导致联合查询响应较慢，查询效率依旧无法得到改善。
为了彻底解决早期架构的问题，我们重新整理了架构的核心诉求：满足企业数据规模、支持灵活关联查询、架构使用和运维成本可控。基于此，我们对当下热门的OLAP产品进行了调研比对，如ApacheDoris、Clickhouse等MPP数据库以及除Presto以外的其他SQLonHadoop相关引擎。我们首先放弃了SQLonHadoop这一类产品，因为其技术生态太过于庞大、涉及组件过多，考虑到架构投入产出比，可能造成团队的负担，成为技术债务。其次我们放弃了Clickhouse选项，主要因为它不支持MySQL协议、学习成本高、在多表Join查询性能中表现较差、对组件依赖较高等问题，并且开发人员需要花费大量成本在扩容与运维工作中，不满足我们的核心诉求。最终，我们发现ApacheDoris不论是在大规模数据量下的查询性能还是使用难度与运维成本等方面都具有一定优势，因此决定引入其进行架构重构。
如上图所示，银行各类业务数据与用户日志由Flume与FlinkCDC进行数据采集、DolphinScheduler进行数据调度写入数仓。ApacheDoris实时数仓主要负责数据分层存储与汇总处理，为应用端提供报表开发、查询分析等功能。在ODS层中，我们主要利用ApacheDoris存储客户在发起贷款申请后所产生的身份证OCR识别附件、相关征信数据授权（如还款流水、支用记录、公积金或税务）等第三方数据，其中身份证OCR附件存放于对象存储中，ODS层中主要负责存放其在对象存储的URL路径信息。这些原始数据会通过DWD与DWS层进行标签分类汇总，最终在ADS层形成各类统计数据，供前端业务人员查询与分析。
在搭建过程，ApacheDoris的高性能、极简易用、实时统一等诸多特性使我们的实时数据流程架构变得简单，大大降低了维护和使用成本。新架构的升级为我们优化了早期架构的痛点，具体表现如下：
元数据管理：ApacheDoris通过对外API提供元数据管理功能，彻底解决了早期架构中多源异构数据无法联合查询的痛点，实现在各TP系统中无缝衔接地进行数据开发。查询性能提升：ApacheDoris完全实现了向量化查询引擎，能够胜任各种查询并发、吞吐的场景并且性能表现强悍，解决了第二代架构中Trino在查询并发响应慢的问题。运维难度低：ApacheDoris基于Sytemd进程保活，具备多副本+副本自动均衡机制，除了需要定时备份元数据外几乎可以达到零运维，极大降低了运维成本与难度，实现降本增效的需求。使用简单：ApacheDoris兼容MySQL协议，能够支持使用标准SQL，不仅极大降低了业务人员的学习成本，还可以轻松实现MySQL业务迁移至ApacheDoris，带来开发效率的提升。在新架构搭建完成后，我们开始基于ApacheDoris进行应用实践，通过并发查询加速与数仓底座建设两方面助力复杂场景下的业务应用。以下是我们总结出来的一些经验：
并发查询加速风控分析是星云零售最最常见的业务，由于金融交易系统会涉及大量的交易日志与明细日志等数据，存在大量高并发低延时的点查询以及高吞吐低并发的大表关联等需求场景，需要在多场景下保持一致的高性能分析体验，因此我们最重要的实践就是并发查询加速。
在引入新架构之前，我们使用MySQL预聚合的方式进行数据分库，这会造成IO与CPU消耗非常大的问题，导致MySQL系统崩溃。在引入ApacheDoris之后，我们采用UniqueKey模型对明细数据进行存储，引入AggregateKey模型进行数据预聚合，为后续的物化视图与实时报表做准备。在社区的帮助下，我们还使用了逻辑分区和物理分桶进行了Key列的优化，利用ColocationJoin的方式创建业务关联表模型，保证分区和分桶、分区键以及Key值统一一致。如上图所示，各业务人员在进行大表关联查询时，不需要再进行跨节点ShuffleJoin，可以直接通过本地节点查询，避免了数据在网络传输中带来的性能开销，有效提升了点查时高吞吐场景下的查询效率。
除金融交易系统外，风控分析还需要进行特征指标计算与贷中行为分析等业务。ApacheDoris的MPP架构完全支持了业务所需的高吞吐和多表查询能力，并且在列表多维度查询时，可以根据不同的业务场景，借助其BloomFilter物化索引机制进行Key列的优化设计。这种方式不仅改善了客户的查询体验，还能够大幅提升查询效率，达到毫秒级查询响应。
数仓底座建设
在与B端合作开展助贷业务过程中会产生大量的离线报表业务，因此，我们首先基于ApacheDoris作为数仓底座，利用调度工具DolphinScheduler、日志采集工具Flume以及数据同步工具DataX等进行数据采集。同时，通过增量或者全量的方式将数据从业务端或者异构数据源中采集落库至ApacheDoris数据仓库中，形成数据集市。
在该集市中，业务人员可以方便地提取所需数据进行报表开发，并展示于实时交易大屏，以支持风控数据分析和业务决策。为了确保数仓稳定性和性能，我们利用了Grafana和Prometheus对集群状态进行监控，主要用于