Doris实践——信贷系统日志分析场景的实践应用

本文主要是介绍Doris实践——信贷系统日志分析场景的实践应用，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言

一、早期架构演进

1.1 架构1.0 基于Kettle + MySQL离线数仓

1.2 架构2.0 基于 Presto / Trino统一查询

二、基于Doris的新一代架构

三、新数仓架构搭建经验

3.1 并发查询加速

3.2 数仓底座建设

四、Doris助力信DolphinScheduler 和 Shell 贷业务场景落地

4.1 交互式分析查询，实现风控大数据平台智能化

4.2 极致性价比，达成统一日志存储分析

4.3 JSON统一存储+丰富解析函数，助力用户行为日志分析

五、收益效果

原文大佬介绍的这篇助贷系统日志分析场景实践案例有借鉴意义，现摘抄下来用作沉淀学习。如有侵权，请告知~

前言

信贷业务转型过程中，随着系统规模不断扩大，腾梭科技决定引入 Doris 实现业务升级。下文将详细介绍其信贷业务如何基于 Doris 在助贷系统日志分析场景的实践应用，实现毫秒级并发查询响应与极致存储性价比的性能表现。

一、早期架构演进

为了满足这些要求，腾梭科技历经三代架构演进。第一代架构基于 Kettle + MySQL 离线数仓，第二代架构引入 Trino 进行统一查询，在经过两代架构使用后发现其性能的不足，最终通过产品调研选择 Doris 作为第三代架构核心进行数据统一存储与分析。本模块将详细介绍三代架构的演进历程和应用实践，分享业务场景落地经验。

1.1 架构1.0 基于Kettle + MySQL离线数仓

在业务初期，使用Fllume Sink进行数据采集，利用DolphineScheduler + Shell进行数据调度，基于Kettle抽取离线数据进入关系型数据库中形成离线数仓，进行基础的T+1报表取数工作。由于Kettle仅支持离线取数的功能，不支持数据存储，因此数据始终保存在原始端。随着数据量的不断增大，当事实表条数达到千万级，Kettle的性能逐渐变得不稳定，单表查询任务的执行时间出现延迟现象，无法满足较大业务规模的使用需求。同时，Kettle不支持多数据源之间的关联查询功能，在TP系统多样的情况下，查询效率无法得到保障。

1.2 架构2.0 基于 Presto / Trino统一查询

针对第一代架构存在的问题，我们在第二代架构升级中借助 Trino 作为分布式 SQL 查询引擎进行联邦查询，实现多种类型数据源的即席查询和批量ETL查询，打通信贷，风控之间的多源异构数据查询需求。由于Trino 缺少存储和管理元数据的功能，在面对高并发点查场景下导致联合查询响应较慢，查询效率依旧无法得到改善。

二、基于Doris的新一代架构

为了彻底解决早期架构的问题，重新整理了架构的核心诉求：满足企业数据规模，支持灵活关联查询、架构使用和运维成本可控，基于此，对当下热门的 OLAP 产品进行了调研比对，如 Doris、Clickhouse 等 MPP 数据库以及除 Presto 以外的其他 SQL on Hadoop 相关引擎。首先放弃了 SQL on Hadoop 这一类产品，因为其技术生态过于庞大，涉及组件过多，考虑到架构投入产出比，可能造成团队的负担，成为技术债务。

其次放弃了 Clickhouse 选项，主要因为它不支持 MySQL 协议、学习成本高、对多表join查询性能中表现较差，对组件依赖较高等问题，并且开发人员需要花费大量成本在扩容与运维工作中，不满足我们的核心诉求。

最终，发现Doris不论是在大规模数据量下的查询性能还是使用难度与运维成本等方面都具有一定优势，因此决定引入其架构重构。

如上图所示，银行各类业务数据与用户日志由 Flume 与 Flink CDC 进行数据采集、DolphinScheduler进行数据调度写入数仓。Doris实时数仓主要负责数据分层存储与汇总处理，为应用端提供报表开发、查询分析等功能。在ODS层中，主要利用Doris存储客户在发起贷款申请后所产生的身份证 OCR 识别附件、相关征信数据授权（如还款流水、支用记录、公积金或税务）等第三方数据，其中身份证 OCR 附件存放于对象存储中，ODS层中主要负责存放其在对象存储的 URL 路径信息。这些原始数据会通过 DWD 与 DWS 层进行标签分类汇总，最终在ADS层形成各类统计数据，供前端业务人员查询与分析。

在搭建过程，Apache Doris 的高性能、极简易用、实时统一等诸多特性使我们的实时数据流程架构变得简单，大大降低了维护和使用成本。新架构的升级优化了早期架构的痛点，具体表现如下：

元数据管理：Doris 通过对外 API 提供元数据管理功能，彻底解决了早期架构中多源异构数据无法联合查询的痛点，实现在各TP系统中无缝衔接地进行数据开发。
查询性能提升：Doris完全实现了向量化查询引擎，能够胜任各种查询并发，吞吐的场景并且型性能表现强悍，解决了第二代架构中Trino 在查询并发响应慢的问题。
运维难度低： Doris 基于 Sytemd 进程保活，具备多副本+ 副本自动均衡机制，除了需要定时备份元数据外几乎可以达到零运维，极大降低了运维成本与难度，实现降本增效的需求。
使用简单：Apache Doris 兼容 MySQL 协议，能够支持使用标准 SQL，不仅极大降低了业务人员的学习成本，还可以轻松实现 MySQL 业务迁移至 Doris，带来开发效率的提升。

三、新数仓架构搭建经验

在新架构搭建完成后，开始基于Doris进行应用实践，通过并发查询加速与数仓底座建设两方面助力复杂场景下的业务应用。以下是总结出来的一些经验：

3.1 并发查询加速

风控分析是星云零售最常见的业务，由于金融交易系统会涉及大量的交易日志与明细日志等数据，存在大量高并发低时延的点查询以及高吞吐低并发的大表关联登需求场景，需要在多场景下保持一致的高性能分析体验，因此最重要的实践就是并发查询加速。

在引入新架构之前，使用 MySQL 预聚合的方式进行数据分库，这会造成IO与CPU消耗非常大的问题，导致Mysql系统崩溃。在引入Doris 之后，采用Unique Key 模型对明细数据进行存储，引入Aggregate Key 模型进行数据预聚合，为后续的物化视图与实时报表做准备。同时，还使用了逻辑分区和物理分区进行了key列的优化，利用Colocation Join 的方式创建业务关联表模型，保证分区和分桶，分区键以及key值统一一致。如上图所示，各业务人员在进行大表关联查询时，不需要再进行跨节点 Shuffle Join，可以直接通过本地节点查询，避免了数据在网络传输中带来的性能开销，有效提升了点查时高吞吐场景下的查询效率。

除金融交易系统外，风控分析还需要进行特征指标计算与贷中行为分析等。 Doris的MPP 架构完全支持了业务所需的高吞吐和多表查询能力，并且在列表维度查询时，可以根据不同的业务场景，借助其Bloom Filter 物化索引机制进行Key列的优化设计。这种方式不仅改善了客户的查询体验，还能够大幅提升查询效率，达到毫秒级查询响应。

3.2 数仓底座建设

在与B端合作开展助贷业务过程中会产生大量的离线报表业务，因此，首先基于Doris作为数仓底座，利用调度工具DolphinScheduler、日志采集工具Flume 以及数据同步工具 DataX等进行数据采集。同时，通过增量或者全量的方式将数据从业务端或者异构数据源中采集落库至Doris数据仓库中，形成数据集市。

在该集市中，业务人员可以方便的提取所需数据进行报表开发，并展示于实时交易大屏，以支持风控数据分析和业务决策。为了确保数仓稳定性和性能，利用了Grafana 和 Prometheus 对集群状态进行监控，主要用于关注Doris 的内存使用情况、ETL过程中Compaction 的稳定性以及查询响应时间。通过这些监控工具，可以帮助及时发现数据集市的运行效果与异常情况。

四、Doris助力信DolphinScheduler 和 Shell 贷业务场景落地

基于Doris 的功能实践，建设了星云零售管理后台，自助报表等一体化业务分析平台。接下来，主要介绍在业务场景落地过程中，风控大数据报表平台，统一日志存储分析与用户行为分析的业务实践。

4.1 交互式分析查询，实现风控大数据平台智能化

如上图所示，星云管理后台会对风控数据进行分析，涉及授信情况分析，用信分析，放款结构分析、拒绝申贷原因分析等报表业务，希望通过风控报表平台实现风控策略化，智能化，提升线上的分控力、提高审批效率并完善信贷业务流程。以授信情况分析为例，具体的操作流程如下：

数据调度：指标数据首先通过DolphinScheduler 和 Shell任务编排实现风控离线数仓各分层数据的调度与流通，统一管理。
数据同步：借助 Doris 的 JDBC Catalog 以 Insert Into 的方式，将多个外部源表中的数据增量导入数仓贴源层，实现统一建模，统一数据口径。
数据处理：在Doris的DW层中进行数据关联分析，聚合，按日区分，并落盘等操作，最终结合维表数据共同创建物化视图或落地大宽表。基于Doris 的分层存储与数据处理，报表的开发时间从天级别提升至小时级别，大幅提高报表开发的效率。
数据分析：基于以上三个步骤，业务人员可以在平台中进行自定义交互式分析查询，如查询某一段时间内授信额度区间的占比，并以饼状图形式呈现。

4.2 极致性价比，达成统一日志存储分析

星云零售在业务运营过程中会存在大量的日志存储分析场景，如使用 API 访问异常日志。在引入 Doris 之前，使用 Grafana + Loki 进行多节点本地支持存储，这种方式不仅无法保证存储统一性，并且增加运维成本。

在引入Doris后，基于 Stream Load 自定义开发Flume Sink 与 Tail Dir 日志采集组件，能够支持动态配置，使节点灵活且易于扩展。还采用了Doris的动态分区表模型，实现动态添加分区或者删除分区，减少了运维过程中的使用负担。更重要的是，Doris 提供了极致的列存储压缩比，使存储成本大幅度下降，并且 2.0 版本的倒排索引功能支持文本类型的全文检索，也能对普通数值日期的等值、范围查询进行加速，能够从海量数据中秒级检索出满足条件的日志，更加契合后续对日志数据分析的需求。总而言之，基于Doris的实时日志存储功能提供了全面的实时预警监控，实时监控大屏，故障分析等能力，真正意义上实现统一实时的日志存储分析。

4.3 JSON统一存储+丰富解析函数，助力用户行为日志分析

在营收信贷业务过程中，会对潜在客户进行广告投放，通过自动获取用户行为日志数据，分析信贷需求来加强营销活动，提升获客效果，达到精准投放的目的。借助Stream Load 自定义的日志采集工具收集用户在小程序或者 App 中的访问日志，利用 JSON 统一存储功能与丰富的解析函数对行为日志进行实时查询分析、跑批离线宽表加工等操作。

五、收益效果

当前，信贷业务基于Doris 搭建了高度统一实时的数据仓库，实现星云管理后台中的风控报表管理，运营报表管理，用户行为日志分析等信贷业务应用。 Doris 的引入带来以下收益与成果：

灵活数据分析：不论是业务端还是数据开发端，都可以基于Doris 支持自定义导数、动态配置，实现灵活及易扩展的多维数据分析。
查询快速响应：从业务层面来说，现阶段的风控信贷点查、偏离计算等复杂场景都可以基于 Doris 进行多表关联，并且实现毫秒级查询响应，大幅提升查询效率。
交付效率提升：助贷业务的核心业务为客户管理，在引入Doris 后，其数据分层存储与开箱即用的分析函数，在用户行为，信用评估，风险控制等多方面提供了有效报表分析，以挖掘更多潜在用户，大幅提升交付效率，实现精准获客的目标。