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

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

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

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

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

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

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

在業(yè)務初期，我們使用 Flume Sink 進行數(shù)據(jù)采集，利用 DolphineScheduler + Shell 進行數(shù)據(jù)調(diào)度，基于 Kettle 抽取離線數(shù)據(jù)進入關(guān)系型數(shù)據(jù)庫中形成離線數(shù)倉，進行基礎(chǔ)的 T+1 報表取數(shù)工作。由于 Kettle 僅支持離線取數(shù)的功能，不支持數(shù)據(jù)存儲，因此數(shù)據(jù)始終保存在原始端。隨著數(shù)據(jù)量的不斷增大，當事實表條數(shù)達到千萬級時，Kettle 的性能逐漸變得不穩(wěn)定，單表查詢?nèi)蝿盏膱?zhí)行時間出現(xiàn)延遲現(xiàn)象，無法滿足較大業(yè)務規(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 查詢引擎進行聯(lián)邦查詢，實現(xiàn)多種類型數(shù)據(jù)源的即席查詢和批量 ETL 查詢，打通信貸、風控之間的多源異構(gòu)數(shù)據(jù)查詢需求。由于 Trino 缺少存儲和管理元數(shù)據(jù)的功能，在面對高并發(fā)點查場景下導致聯(lián)合查詢響應較慢，查詢效率依舊無法得到改善。

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

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

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

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

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

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

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

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

并發(fā)查詢加速

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

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

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

數(shù)倉底座建設

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

綜合成本降低：與之前數(shù)據(jù)源端存儲不同，Apache Doris 極致的存儲壓縮比，降低了 70 % 的存儲成本。同時，Apache Doris 支持集群節(jié)點進程?；?、自動均衡極致，幾乎達到零運維，為公司運維成本控制提供了核心收益。

未來，我們希望基于 Apache Doris 冷熱分層技術(shù)實現(xiàn)統(tǒng)一的數(shù)據(jù)歸檔功能，將冷數(shù)據(jù)、歷史數(shù)據(jù)定時進行歸檔，進一步優(yōu)化數(shù)倉存儲空間。同時，利用 Apache Doris 湖倉一體功能實現(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)，提供一致性的查詢體驗。

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

生成海報

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

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