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