存儲成本降低70%！金融信貸業(yè)務(wù)如何實(shí)現(xiàn)毫秒級并發(fā)查詢？

作者｜騰梭科技 研發(fā)總監(jiān) 劉建波

隨著金融全球化和數(shù)字化的發(fā)展，信貸服務(wù)市場規(guī)模不斷擴(kuò)大，個人和企業(yè)對信貸服務(wù)的需求也越來越多樣化和細(xì)分化，這為信貸服務(wù)機(jī)構(gòu)提供了更多的商機(jī)和挑戰(zhàn)。

作為互聯(lián)網(wǎng)金融科技公司，騰梭科技（騰訊投資且在金融領(lǐng)域的戰(zhàn)略合作伙伴）聯(lián)合行業(yè)內(nèi)各大友商行，共同提供信貸服務(wù)。騰梭科技信貸服務(wù)已經(jīng)從早期的網(wǎng)貸轉(zhuǎn)型為以助貸為核心的業(yè)務(wù)模式，并開展了全量客群的挖掘，探索線上、線下結(jié)合或純線上貸款全流程業(yè)務(wù)模式，為新零售金融場景提供微服務(wù)技術(shù)應(yīng)用，包括潛在客戶信用評估、拒貸款分析、貸后管理、預(yù)期催收以及風(fēng)控管理等方面。

基于業(yè)務(wù)模式的演進(jìn)，業(yè)務(wù)發(fā)展基石之系統(tǒng)技術(shù)架構(gòu)也隨之發(fā)生了變化與升級，從集中式的單機(jī)系統(tǒng)轉(zhuǎn)化為分布式場景。由于引入了各大合作銀行的 TP 系統(tǒng)（如 MySQL 、Oracle、PostgreSQL 等），使系統(tǒng)規(guī)模不斷擴(kuò)大。而傳統(tǒng)的關(guān)系型數(shù)據(jù)庫無法完成多種數(shù)據(jù)源之間的數(shù)據(jù)關(guān)聯(lián)，架構(gòu)逐漸出現(xiàn)數(shù)據(jù)孤島與數(shù)據(jù)割裂的現(xiàn)象，因此 OLAP 引擎的應(yīng)用成為打破數(shù)據(jù)孤島必不可少的工具。對于助貸系統(tǒng)的架構(gòu)升級，如何進(jìn)行高效數(shù)據(jù)采集和處理、如何在龐大的客戶數(shù)據(jù)中準(zhǔn)確了解潛在客戶需求與信用情況以加快貸款審批速度、如何通過客戶數(shù)據(jù)管理實(shí)現(xiàn)高效精準(zhǔn)獲客、賦能營銷策略，成為了我們業(yè)務(wù)重點(diǎn)發(fā)展方向。

為了滿足這些要求，騰梭科技?xì)v經(jīng)三代架構(gòu)演進(jìn)。第一代架構(gòu)基于 Kettle 離線數(shù)倉，第二代架構(gòu)引入 Trino 進(jìn)行統(tǒng)一查詢，在經(jīng)過兩代架構(gòu)使用后發(fā)現(xiàn)其性能的不足，決定引入 OLAP 引擎。最終通過產(chǎn)品調(diào)研選擇 Apache Doris 作為第三代架構(gòu)核心進(jìn)行數(shù)據(jù)統(tǒng)一存儲與分析。本文將詳細(xì)介紹三代架構(gòu)的演進(jìn)歷程和應(yīng)用實(shí)踐，分享業(yè)務(wù)場景落地經(jīng)驗(yàn)。

架構(gòu) 1.0 ：基于 Kettle + MySQL 離線數(shù)倉

在業(yè)務(wù)初期，我們使用 Flume Sink 進(jìn)行數(shù)據(jù)采集，利用 DolphineScheduler + Shell 進(jìn)行數(shù)據(jù)調(diào)度，基于 Kettle 抽取離線數(shù)據(jù)進(jìn)入關(guān)系型數(shù)據(jù)庫中形成離線數(shù)倉，進(jìn)行基礎(chǔ)的 T+1 報表取數(shù)工作。由于 Kettle 僅支持離線取數(shù)的功能，不支持?jǐn)?shù)據(jù)存儲，因此數(shù)據(jù)始終保存在原始端。隨著數(shù)據(jù)量的不斷增大，當(dāng)事實(shí)表?xiàng)l數(shù)達(dá)到千萬級時，Kettle 的性能逐漸變得不穩(wěn)定，單表查詢?nèi)蝿?wù)的執(zhí)行時間出現(xiàn)延遲現(xiàn)象，無法滿足較大業(yè)務(wù)規(guī)模的使用需求。同時，Kettle 不支持多數(shù)據(jù)源之間的關(guān)聯(lián)查詢功能，在 TP 系統(tǒng)多樣的情況下，查詢效率無法得到保障。

架構(gòu) 2.0 ：基于 Presto / Trino 統(tǒng)一查詢

針對第一代架構(gòu)存在的問題，我們在第二代架構(gòu)升級中借助 Trino 作為分布式 SQL 查詢引擎進(jìn)行聯(lián)邦查詢，實(shí)現(xiàn)多種類型數(shù)據(jù)源的即席查詢和批量 ETL 查詢，打通信貸、風(fēng)控之間的多源異構(gòu)數(shù)據(jù)查詢需求。由于 Trino 缺少存儲和管理元數(shù)據(jù)的功能，在面對高并發(fā)點(diǎn)查場景下導(dǎo)致聯(lián)合查詢響應(yīng)較慢，查詢效率依舊無法得到改善。

為了徹底解決早期架構(gòu)的問題，我們重新整理了架構(gòu)的核心訴求：滿足企業(yè)數(shù)據(jù)規(guī)模、支持靈活關(guān)聯(lián)查詢、架構(gòu)使用和運(yùn)維成本可控。基于此，我們對當(dāng)下熱門的 OLAP 產(chǎn)品進(jìn)行了調(diào)研比對，如 Apache Doris、Clickhouse 等 MPP 數(shù)據(jù)庫以及除 Presto 以外的其他 SQL on Hadoop 相關(guān)引擎。我們首先放棄了 SQL on Hadoop 這一類產(chǎn)品，因?yàn)槠浼夹g(shù)生態(tài)太過于龐大、涉及組件過多，考慮到架構(gòu)投入產(chǎn)出比，可能造成團(tuán)隊(duì)的負(fù)擔(dān)，成為技術(shù)債務(wù)。其次我們放棄了 Clickhouse 選項(xiàng)，主要因?yàn)樗恢С?MySQL 協(xié)議、學(xué)習(xí)成本高、在多表 Join 查詢性能中表現(xiàn)較差、對組件依賴較高等問題，并且開發(fā)人員需要花費(fèi)大量成本在擴(kuò)容與運(yùn)維工作中，不滿足我們的核心訴求。最終，我們發(fā)現(xiàn) Apache Doris 不論是在大規(guī)模數(shù)據(jù)量下的查詢性能還是使用難度與運(yùn)維成本等方面都具有一定優(yōu)勢，因此決定引入其進(jìn)行架構(gòu)重構(gòu)。

如上圖所示，銀行各類業(yè)務(wù)數(shù)據(jù)與用戶日志由 Flume 與 Flink CDC 進(jìn)行數(shù)據(jù)采集、DolphinScheduler 進(jìn)行數(shù)據(jù)調(diào)度寫入數(shù)倉。Apache Doris 實(shí)時數(shù)倉主要負(fù)責(zé)數(shù)據(jù)分層存儲與匯總處理，為應(yīng)用端提供報表開發(fā)、查詢分析等功能。在 ODS 層中，我們主要利用 Apache Doris 存儲客戶在發(fā)起貸款申請后所產(chǎn)生的身份證 OCR 識別附件、相關(guān)征信數(shù)據(jù)授權(quán)（如還款流水、支用記錄、公積金或稅務(wù)）等第三方數(shù)據(jù)，其中身份證 OCR 附件存放于對象存儲中，ODS 層中主要負(fù)責(zé)存放其在對象存儲的 URL 路徑信息。這些原始數(shù)據(jù)會通過 DWD 與 DWS 層進(jìn)行標(biāo)簽分類匯總，最終在 ADS 層形成各類統(tǒng)計數(shù)據(jù)，供前端業(yè)務(wù)人員查詢與分析。

在搭建過程，Apache Doris 的高性能、極簡易用、實(shí)時統(tǒng)一等諸多特性使我們的實(shí)時數(shù)據(jù)流程架構(gòu)變得簡單，大大降低了維護(hù)和使用成本。新架構(gòu)的升級為我們優(yōu)化了早期架構(gòu)的痛點(diǎn)，具體表現(xiàn)如下：

元數(shù)據(jù)管理：Apache Doris 通過對外 API 提供元數(shù)據(jù)管理功能，徹底解決了早期架構(gòu)中多源異構(gòu)數(shù)據(jù)無法聯(lián)合查詢的痛點(diǎn)，實(shí)現(xiàn)在各 TP 系統(tǒng)中無縫銜接地進(jìn)行數(shù)據(jù)開發(fā)。

查詢性能提升：Apache Doris 完全實(shí)現(xiàn)了向量化查詢引擎，能夠勝任各種查詢并發(fā)、吞吐的場景并且性能表現(xiàn)強(qiáng)悍，解決了第二代架構(gòu)中 Trino 在查詢并發(fā)響應(yīng)慢的問題。

運(yùn)維難度低： Apache Doris 基于 Sytemd 進(jìn)程?；?，具備多副本+ 副本自動均衡機(jī)制，除了需要定時備份元數(shù)據(jù)外幾乎可以達(dá)到零運(yùn)維，極大降低了運(yùn)維成本與難度，實(shí)現(xiàn)降本增效的需求。

使用簡單：Apache Doris 兼容 MySQL 協(xié)議，能夠支持使用標(biāo)準(zhǔn) SQL，不僅極大降低了業(yè)務(wù)人員的學(xué)習(xí)成本，還可以輕松實(shí)現(xiàn) MySQL 業(yè)務(wù)遷移至 Apache Doris，帶來開發(fā)效率的提升。

在新架構(gòu)搭建完成后，我們開始基于 Apache Doris 進(jìn)行應(yīng)用實(shí)踐，通過并發(fā)查詢加速與數(shù)倉底座建設(shè)兩方面助力復(fù)雜場景下的業(yè)務(wù)應(yīng)用。以下是我們總結(jié)出來的一些經(jīng)驗(yàn)：

并發(fā)查詢加速

風(fēng)控分析是星云零售最最常見的業(yè)務(wù)，由于金融交易系統(tǒng)會涉及大量的交易日志與明細(xì)日志等數(shù)據(jù)，存在大量高并發(fā)低延時的點(diǎn)查詢以及高吞吐低并發(fā)的大表關(guān)聯(lián)等需求場景，需要在多場景下保持一致的高性能分析體驗(yàn)，因此我們最重要的實(shí)踐就是并發(fā)查詢加速。

在引入新架構(gòu)之前，我們使用 MySQL 預(yù)聚合的方式進(jìn)行數(shù)據(jù)分庫，這會造成 IO 與 CPU 消耗非常大的問題，導(dǎo)致 MySQL 系統(tǒng)崩潰。在引入 Apache Doris 之后，我們采用 Unique Key 模型對明細(xì)數(shù)據(jù)進(jìn)行存儲，引入 Aggregate Key 模型進(jìn)行數(shù)據(jù)預(yù)聚合，為后續(xù)的物化視圖與實(shí)時報表做準(zhǔn)備。在社區(qū)的幫助下，我們還使用了邏輯分區(qū)和物理分桶進(jìn)行了 Key 列的優(yōu)化，利用 Colocation Join 的方式創(chuàng)建業(yè)務(wù)關(guān)聯(lián)表模型，保證分區(qū)和分桶、分區(qū)鍵以及 Key 值統(tǒng)一一致。如上圖所示，各業(yè)務(wù)人員在進(jìn)行大表關(guān)聯(lián)查詢時，不需要再進(jìn)行跨節(jié)點(diǎn) Shuffle Join，可以直接通過本地節(jié)點(diǎn)查詢，避免了數(shù)據(jù)在網(wǎng)絡(luò)傳輸中帶來的性能開銷，有效提升了點(diǎn)查時高吞吐場景下的查詢效率。

除金融交易系統(tǒng)外，風(fēng)控分析還需要進(jìn)行特征指標(biāo)計算與貸中行為分析等業(yè)務(wù)。Apache Doris 的 MPP 架構(gòu)完全支持了業(yè)務(wù)所需的高吞吐和多表查詢能力，并且在列表多維度查詢時，可以根據(jù)不同的業(yè)務(wù)場景，借助其 Bloom Filter 物化索引機(jī)制進(jìn)行 Key 列的優(yōu)化設(shè)計。這種方式不僅改善了客戶的查詢體驗(yàn)，還能夠大幅提升查詢效率，達(dá)到毫秒級查詢響應(yīng)。

數(shù)倉底座建設(shè)

在與 B 端合作開展助貸業(yè)務(wù)過程中會產(chǎn)生大量的離線報表業(yè)務(wù)，因此，我們首先基于 Apache Doris 作為數(shù)倉底座，利用調(diào)度工具 DolphinScheduler、日志采集工具 Flume 以及數(shù)據(jù)同步工具 DataX 等進(jìn)行數(shù)據(jù)采集。同時，通過增量或者全量的方式將數(shù)據(jù)從業(yè)務(wù)端或者異構(gòu)數(shù)據(jù)源中采集落庫至 Apache Doris 數(shù)據(jù)倉庫中，形成數(shù)據(jù)集市。

在該集市中，業(yè)務(wù)人員可以方便地提取所需數(shù)據(jù)進(jìn)行報表開發(fā)，并展示于實(shí)時交易大屏，以支持風(fēng)控數(shù)據(jù)分析和業(yè)務(wù)決策。為了確保數(shù)倉穩(wěn)定性和性能，我們利用了 Grafana 和 Prometheus 對集群狀態(tài)進(jìn)行監(jiān)控，主要用于關(guān)注 Apache Doris 的內(nèi)存使用情況、 ETL 過程中 Compaction 的穩(wěn)定性以及查詢響應(yīng)時間。通過這些監(jiān)控工具，可以幫助我們及時發(fā)現(xiàn)數(shù)據(jù)集市的運(yùn)行效果與異常情況。

基于 Apache Doris 的功能實(shí)踐，我們建設(shè)了星云零售管理后臺、自助報表等一體化業(yè)務(wù)分析平臺。接下來，我們主要介紹在業(yè)務(wù)場景落地過程中，風(fēng)控大數(shù)據(jù)報表平臺、統(tǒng)一日志存儲分析與用戶行為分析的業(yè)務(wù)實(shí)踐。

交互式分析查詢，實(shí)現(xiàn)風(fēng)控大數(shù)據(jù)平臺智能化

如上圖所示，星云管理后臺會對風(fēng)控數(shù)據(jù)進(jìn)行分析，涉及授信情況分析、用信分析、放款結(jié)構(gòu)分析、拒絕申貸原因分析等報表業(yè)務(wù)，我們希望通過風(fēng)控報表平臺實(shí)現(xiàn)風(fēng)控策略化、智能化，提升線上的風(fēng)控能力、提高審批效率并完善信貸業(yè)務(wù)流程。以授信情況分析為例，具體的操作流程如下：

數(shù)據(jù)調(diào)度：指標(biāo)數(shù)據(jù)首先通過 DolphinScheduler 和 Shell 任務(wù)編排實(shí)現(xiàn)風(fēng)控離線數(shù)倉各分層數(shù)據(jù)的調(diào)度與流通、統(tǒng)一管理。

數(shù)據(jù)同步：借助 Apache Doris 的 JDBC Catalog 以 Insert Into 的方式，將多個外部源表中的數(shù)據(jù)增量導(dǎo)入數(shù)倉貼源層，實(shí)現(xiàn)統(tǒng)一建模、統(tǒng)一數(shù)據(jù)口徑。

數(shù)據(jù)處理：在 Apache Doris 的 DW 層中進(jìn)行數(shù)據(jù)關(guān)聯(lián)分析、聚合、日區(qū)分落盤等操作，最終結(jié)合維表數(shù)據(jù)共同創(chuàng)建物化視圖或者落地大寬表?；?Apache Doris 的分層存儲與數(shù)據(jù)處理，我們的報表開發(fā)時間從天級別提升至小時級別，大幅提高報表開發(fā)的效率。

數(shù)據(jù)分析：基于以上三個步驟，業(yè)務(wù)人員可以在平臺中進(jìn)行自定義交互式分析查詢，如查詢某一段時間內(nèi)授信額度區(qū)間的占比，并以餅狀圖形式呈現(xiàn)。

極致性價比，達(dá)成統(tǒng)一日志存儲分析

星云零售在業(yè)務(wù)運(yùn)營過程中會存在大量的日志存儲分析場景，如使用 API 訪問異常日志。在引入 Apache Doris 之前，我們使用 Grafana + Loki 進(jìn)行多節(jié)點(diǎn)本地支持存儲，這種方式不僅無法保證存儲統(tǒng)一性，并且增加運(yùn)維成本。

在引入 Apache Doris 后，我們基于 Stream Load 自定義開發(fā) Flume Sink 與 Tail Dir 日志采集組件，能夠支持動態(tài)配置，使節(jié)點(diǎn)靈活且易于擴(kuò)展。我們還采用了 Apache Doris 的動態(tài)分區(qū)表模型，實(shí)現(xiàn)動態(tài)添加分區(qū)或者刪除分區(qū)，減少了運(yùn)維過程中的使用負(fù)擔(dān)。更重要的是，Apache Doris 提供了極致的列存儲壓縮比，使存儲成本大幅度下降，并且 2.0 版本的倒排索引功能支持文本類型的全文檢索，也能對普通數(shù)值日期的等值、范圍查詢進(jìn)行加速，能夠從海量數(shù)據(jù)中秒級檢索出滿足條件的日志，更加契合我們后續(xù)對日志數(shù)據(jù)分析的需求?？偠灾?，基于 Apache Doris 的實(shí)時日志存儲功能為我們提供了全面的實(shí)時預(yù)警監(jiān)控、實(shí)時監(jiān)控大屏、故障分析等能力，真正意義上實(shí)現(xiàn)統(tǒng)一實(shí)時的日志存儲分析。

JSON 統(tǒng)一存儲 + 豐富解析函數(shù)，助力用戶行為日志分析

在營收信貸業(yè)務(wù)過程中，我們會對潛在客戶進(jìn)行廣告投放，通過自動獲取用戶行為日志數(shù)據(jù)，分析信貸需求來加強(qiáng)營銷活動、提升獲客效果，達(dá)到精準(zhǔn)投放的目的。我們借助 Stream Load 自定義的日志采集工具收集用戶在小程序或者 App 中的訪問日志，利用 JSON 統(tǒng)一存儲功能與豐富的解析函數(shù)對行為日志進(jìn)行實(shí)時查詢分析、跑批離線寬表加工等操作。

在這一過程中，Apache Doris 的引入使用戶行為日志降低 70% 的存儲成本，同時提供了豐富且開箱即用的用戶行為分析函數(shù)，避免業(yè)務(wù)人員重復(fù)進(jìn)行復(fù)雜 SQL 函數(shù)編寫、驗(yàn)證、推導(dǎo)再應(yīng)用，極大提高了數(shù)據(jù)開發(fā)效率，為后續(xù)廣告精準(zhǔn)投放提供了強(qiáng)有力的數(shù)據(jù)支持。

當(dāng)前，騰梭科技星云零售信貸業(yè)務(wù)基于 Apache Doris 搭建了高度統(tǒng)一實(shí)時的數(shù)據(jù)倉庫，實(shí)現(xiàn)星云管理后臺中的風(fēng)控報表管理、運(yùn)營報表管理、用戶行為日志分析等信貸業(yè)務(wù)應(yīng)用。Apache Doris 的引入為我們帶來以下收益與成果：

靈活數(shù)據(jù)分析：不論是業(yè)務(wù)端還是數(shù)據(jù)開發(fā)端，都可以基于 Doris 支持自定義導(dǎo)數(shù)、動態(tài)配置，實(shí)現(xiàn)靈活及易擴(kuò)展的多維數(shù)據(jù)分析。

查詢快速響應(yīng)：從業(yè)務(wù)層面來看，現(xiàn)階段的風(fēng)控信貸點(diǎn)查、偏離計算等復(fù)雜場景都可以基于 Apache Doris 進(jìn)行多表關(guān)聯(lián)，并且實(shí)現(xiàn)毫秒級查詢響應(yīng)，大幅提升查詢效率。

交付效率提升：助貸業(yè)務(wù)的核心業(yè)務(wù)為客戶管理，在引入 Apache Doris 后，其數(shù)據(jù)分層存儲與開箱即用的分析函數(shù)，在用戶行為、信用評估、風(fēng)險控制等多方面提供了有效報表分析，以挖掘更多潛在用戶，大幅提升交付效率，實(shí)現(xiàn)精準(zhǔn)獲客的目標(biāo)。

綜合成本降低：與之前數(shù)據(jù)源端存儲不同，Apache Doris 極致的存儲壓縮比，降低了 70 % 的存儲成本。同時，Apache Doris 支持集群節(jié)點(diǎn)進(jìn)程?；睢⒆詣泳鈽O致，幾乎達(dá)到零運(yùn)維，為公司運(yùn)維成本控制提供了核心收益。

未來，我們希望基于 Apache Doris 冷熱分層技術(shù)實(shí)現(xiàn)統(tǒng)一的數(shù)據(jù)歸檔功能，將冷數(shù)據(jù)、歷史數(shù)據(jù)定時進(jìn)行歸檔，進(jìn)一步優(yōu)化數(shù)倉存儲空間。同時，利用 Apache Doris 湖倉一體功能實(shí)現(xiàn)智能數(shù)據(jù)網(wǎng)關(guān)，使 Schema 列類型等元數(shù)據(jù)能夠映射至 Apache Doris 的數(shù)據(jù)結(jié)構(gòu)中，形成統(tǒng)一元數(shù)據(jù)映射結(jié)構(gòu)，提供一致性的查詢體驗(yàn)。

最后，感謝 Apache Doris 社區(qū)和 SelectDB 技術(shù)團(tuán)隊(duì)在數(shù)倉搭建過程中的積極響應(yīng)與技術(shù)支持，未來我們也會持續(xù)參與社區(qū)活動，將相關(guān)成果貢獻(xiàn)回饋社區(qū)，希望 Apache Doris 飛速發(fā)展，越來越好！

生成海報

免責(zé)聲明：此文內(nèi)容為第三方自媒體作者發(fā)布的觀察或評論性文章，所有文字和圖片版權(quán)歸作者所有，且僅代表作者個人觀點(diǎn)，與極客網(wǎng)無關(guān)。文章僅供讀者參考，并請自行核實(shí)相關(guān)內(nèi)容。投訴郵箱：editor@fromgeek.com。

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。