作者｜騰梭科技 研發(fā)總監(jiān) 劉建波
隨著金融全球化和數字化的發(fā)展，信貸服務市場規(guī)模不斷擴大，個人和企業(yè)對信貸服務的需求也越來越多樣化和細分化，這為信貸服務機構提供了更多的商機和挑戰(zhàn)。
作為互聯網金融科技公司，騰梭科技（騰訊投資且在金融領域的戰(zhàn)略合作伙伴）聯合行業(yè)內各大友商行，共同提供信貸服務。騰梭科技信貸服務已經從早期的網貸轉型為以助貸為核心的業(yè)務模式，并開展了全量客群的挖掘，探索線上、線下結合或純線上貸款全流程業(yè)務模式，為新零售金融場景提供微服務技術應用，包括潛在客戶信用評估、拒貸款分析、貸后管理、預期催收以及風控管理等方面。
基于業(yè)務模式的演進，業(yè)務發(fā)展基石之系統技術架構也隨之發(fā)生了變化與升級，從集中式的單機系統轉化為分布式場景。由于引入了各大合作銀行的 TP 系統（如 MySQL 、Oracle、PostgreSQL 等），使系統規(guī)模不斷擴大。而傳統的關系型數據庫無法完成多種數據源之間的數據關聯，架構逐漸出現數據孤島與數據割裂的現象，因此 OLAP 引擎的應用成為打破數據孤島必不可少的工具。對于助貸系統的架構升級，如何進行高效數據采集和處理、如何在龐大的客戶數據中準確了解潛在客戶需求與信用情況以加快貸款審批速度、如何通過客戶數據管理實現高效精準獲客、賦能營銷策略，成為了我們業(yè)務重點發(fā)展方向。
為了滿足這些要求，騰梭科技歷經三代架構演進。第一代架構基于 Kettle 離線數倉，第二代架構引入 Trino 進行統一查詢，在經過兩代架構使用后發(fā)現其性能的不足，決定引入 OLAP 引擎。最終通過產品調研選擇 Apache Doris 作為第三代架構核心進行數據統一存儲與分析。本文將詳細介紹三代架構的演進歷程和應用實踐，分享業(yè)務場景落地經驗。
架構 1.0 ：基于 Kettle + MySQL 離線數倉
在業(yè)務初期，我們使用 Flume Sink 進行數據采集，利用 DolphineScheduler + Shell 進行數據調度，基于 Kettle 抽取離線數據進入關系型數據庫中形成離線數倉，進行基礎的 T+1 報表取數工作。由于 Kettle 僅支持離線取數的功能，不支持數據存儲，因此數據始終保存在原始端。隨著數據量的不斷增大，當事實表條數達到千萬級時，Kettle 的性能逐漸變得不穩(wěn)定，單表查詢任務的執(zhí)行時間出現延遲現象，無法滿足較大業(yè)務規(guī)模的使用需求。同時，Kettle 不支持多數據源之間的關聯查詢功能，在 TP 系統多樣的情況下，查詢效率無法得到保障。
架構 2.0 ：基于 Presto / Trino 統一查詢
針對第一代架構存在的問題，我們在第二代架構升級中借助 Trino 作為分布式 SQL 查詢引擎進行聯邦查詢，實現多種類型數據源的即席查詢和批量 ETL 查詢，打通信貸、風控之間的多源異構數據查詢需求。由于 Trino 缺少存儲和管理元數據的功能，在面對高并發(fā)點查場景下導致聯合查詢響應較慢，查詢效率依舊無法得到改善。
為了徹底解決早期架構的問題，我們重新整理了架構的核心訴求：滿足企業(yè)數據規(guī)模、支持靈活關聯查詢、架構使用和運維成本可控。基于此，我們對當下熱門的 OLAP 產品進行了調研比對，如 Apache Doris、Clickhouse 等 MPP 數據庫以及除 Presto 以外的其他 SQL on Hadoop 相關引擎。我們首先放棄了 SQL on Hadoop 這一類產品，因為其技術生態(tài)太過于龐大、涉及組件過多，考慮到架構投入產出比，可能造成團隊的負擔，成為技術債務。其次我們放棄了 Clickhouse 選項，主要因為它不支持 MySQL 協議、學習成本高、在多表 Join 查詢性能中表現較差、對組件依賴較高等問題，并且開發(fā)人員需要花費大量成本在擴容與運維工作中，不滿足我們的核心訴求。最終，我們發(fā)現 Apache Doris 不論是在大規(guī)模數據量下的查詢性能還是使用難度與運維成本等方面都具有一定優(yōu)勢，因此決定引入其進行架構重構。
如上圖所示，銀行各類業(yè)務數據與用戶日志由 Flume 與 Flink CDC 進行數據采集、DolphinScheduler 進行數據調度寫入數倉。Apache Doris 實時數倉主要負責數據分層存儲與匯總處理，為應用端提供報表開發(fā)、查詢分析等功能。在 ODS 層中，我們主要利用 Apache Doris 存儲客戶在發(fā)起貸款申請后所產生的身份證 OCR 識別附件、相關征信數據授權（如還款流水、支用記錄、公積金或稅務）等第三方數據，其中身份證 OCR 附件存放于對象存儲中，ODS 層中主要負責存放其在對象存儲的 URL 路徑信息。這些原始數據會通過 DWD 與 DWS 層進行標簽分類匯總，最終在 ADS 層形成各類統計數據，供前端業(yè)務人員查詢與分析。
在搭建過程，Apache Doris 的高性能、極簡易用、實時統一等諸多特性使我們的實時數據流程架構變得簡單，大大降低了維護和使用成本。新架構的升級為我們優(yōu)化了早期架構的痛點，具體表現如下：
元數據管理：Apache Doris 通過對外 API 提供元數據管理功能，徹底解決了早期架構中多源異構數據無法聯合查詢的痛點，實現在各 TP 系統中無縫銜接地進行數據開發(fā)。
查詢性能提升：Apache Doris 完全實現了向量化查詢引擎，能夠勝任各種查詢并發(fā)、吞吐的場景并且性能表現強悍，解決了第二代架構中 Trino 在查詢并發(fā)響應慢的問題。
運維難度低： Apache Doris 基于 Sytemd 進程保活，具備多副本+ 副本自動均衡機制，除了需要定時備份元數據外幾乎可以達到零運維，極大降低了運維成本與難度，實現降本增效的需求。
使用簡單：Apache Doris 兼容 MySQL 協議，能夠支持使用標準 SQL，不僅極大降低了業(yè)務人員的學習成本，還可以輕松實現 MySQL 業(yè)務遷移至 Apache Doris，帶來開發(fā)效率的提升。
在新架構搭建完成后，我們開始基于 Apache Doris 進行應用實踐，通過并發(fā)查詢加速與數倉底座建設兩方面助力復雜場景下的業(yè)務應用。以下是我們總結出來的一些經驗：
并發(fā)查詢加速
風控分析是星云零售最最常見的業(yè)務，由于金融交易系統會涉及大量的交易日志與明細日志等數據，存在大量高并發(fā)低延時的點查詢以及高吞吐低并發(fā)的大表關聯等需求場景，需要在多場景下保持一致的高性能分析體驗，因此我們最重要的實踐就是并發(fā)查詢加速。
在引入新架構之前，我們使用 MySQL 預聚合的方式進行數據分庫，這會造成 IO 與 CPU 消耗非常大的問題，導致 MySQL 系統崩潰。在引入 Apache Doris 之后，我們采用 Unique Key 模型對明細數據進行存儲，引入 Aggregate Key 模型進行數據預聚合，為后續(xù)的物化視圖與實時報表做準備。在社區(qū)的幫助下，我們還使用了邏輯分區(qū)和物理分桶進行了 Key 列的優(yōu)化，利用 Colocation Join 的方式創(chuàng)建業(yè)務關聯表模型，保證分區(qū)和分桶、分區(qū)鍵以及 Key 值統一一致。如上圖所示，各業(yè)務人員在進行大表關聯查詢時，不需要再進行跨節(jié)點 Shuffle Join，可以直接通過本地節(jié)點查詢，避免了數據在網絡傳輸中帶來的性能開銷，有效提升了點查時高吞吐場景下的查詢效率。
除金融交易系統外，風控分析還需要進行特征指標計算與貸中行為分析等業(yè)務。Apache Doris 的 MPP 架構完全支持了業(yè)務所需的高吞吐和多表查詢能力，并且在列表多維度查詢時，可以根據不同的業(yè)務場景，借助其 Bloom Filter 物化索引機制進行 Key 列的優(yōu)化設計。這種方式不僅改善了客戶的查詢體驗，還能夠大幅提升查詢效率，達到毫秒級查詢響應。
數倉底座建設
在與 B 端合作開展助貸業(yè)務過程中會產生大量的離線報表業(yè)務，因此，我們首先基于 Apache Doris 作為數倉底座，利用調度工具 DolphinScheduler、日志采集工具 Flume 以及數據同步工具 DataX 等進行數據采集。同時，通過增量或者全量的方式將數據從業(yè)務端或者異構數據源中采集落庫至 Apache Doris 數據倉庫中，形成數據集市。
在該集市中，業(yè)務人員可以方便地提取所需數據進行報表開發(fā)，并展示于實時交易大屏，以支持風控數據分析和業(yè)務決策。為了確保數倉穩(wěn)定性和性能，我們利用了 Grafana 和 Prometheus 對集群狀態(tài)進行監(jiān)控，主要用于關注 Apache Doris 的內存使用情況、 ETL 過程中 Compaction 的穩(wěn)定性以及查詢響應時間。通過這些監(jiān)控工具，可以幫助我們及時發(fā)現數據集市的運行效果與異常情況。
基于 Apache Doris 的功能實踐，我們建設了星云零售管理后臺、自助報表等一體化業(yè)務分析平臺。接下來，我們主要介紹在業(yè)務場景落地過程中，風控大數據報表平臺、統一日志存儲分析與用戶行為分析的業(yè)務實踐。
交互式分析查詢，實現風控大數據平臺智能化
如上圖所示，星云管理后臺會對風控數據進行分析，涉及授信情況分析、用信分析、放款結構分析、拒絕申貸原因分析等報表業(yè)務，我們希望通過風控報表平臺實現風控策略化、智能化，提升線上的風控能力、提高審批效率并完善信貸業(yè)務流程。以授信情況分析為例，具體的操作流程如下：
數據調度：指標數據首先通過 DolphinScheduler 和 Shell 任務編排實現風控離線數倉各分層數據的調度與流通、統一管理。
數據同步：借助 Apache Doris 的 JDBC Catalog 以 Insert Into 的方式，將多個外部源表中的數據增量導入數倉貼源層，實現統一建模、統一數據口徑。
數據處理：在 Apache Doris 的 DW 層中進行數據關聯分析、聚合、日區(qū)分落盤等操作，最終結合維表數據共同創(chuàng)建物化視圖或者落地大寬表?；?Apache Doris 的分層存儲與數據處理，我們的報表開發(fā)時間從天級別提升至小時級別，大幅提高報表開發(fā)的效率。
數據分析：基于以上三個步驟，業(yè)務人員可以在平臺中進行自定義交互式分析查詢，如查詢某一段時間內授信額度區(qū)間的占比，并以餅狀圖形式呈現。
極致性價比，達成統一日志存儲分析
星云零售在業(yè)務運營過程中會存在大量的日志存儲分析場景，如使用 API 訪問異常日志。在引入 Apache Doris 之前，我們使用 Grafana + Loki 進行多節(jié)點本地支持存儲，這種方式不僅無法保證存儲統一性，并且增加運維成本。
在引入 Apache Doris 后，我們基于 Stream Load 自定義開發(fā) Flume Sink 與 Tail Dir 日志采集組件，能夠支持動態(tài)配置，使節(jié)點靈活且易于擴展。我們還采用了 Apache Doris 的動態(tài)分區(qū)表模型，實現動態(tài)添加分區(qū)或者刪除分區(qū)，減少了運維過程中的使用負擔。更重要的是，Apache Doris 提供了極致的列存儲壓縮比，使存儲成本大幅度下降，并且 2.0 版本的倒排索引功能支持文本類型的全文檢索，也能對普通數值日期的等值、范圍查詢進行加速，能夠從海量數據中秒級檢索出滿足條件的日志，更加契合我們后續(xù)對日志數據分析的需求?？偠灾?Apache Doris 的實時日志存儲功能為我們提供了全面的實時預警監(jiān)控、實時監(jiān)控大屏、故障分析等能力，真正意義上實現統一實時的日志存儲分析。
JSON 統一存儲 + 豐富解析函數，助力用戶行為日志分析
在營收信貸業(yè)務過程中，我們會對潛在客戶進行廣告投放，通過自動獲取用戶行為日志數據，分析信貸需求來加強營銷活動、提升獲客效果，達到精準投放的目的。我們借助 Stream Load 自定義的日志采集工具收集用戶在小程序或者 App 中的訪問日志，利用 JSON 統一存儲功能與豐富的解析函數對行為日志進行實時查詢分析、跑批離線寬表加工等操作。
在這一過程中，Apache Doris 的引入使用戶行為日志降低 70% 的存儲成本，同時提供了豐富且開箱即用的用戶行為分析函數，避免業(yè)務人員重復進行復雜 SQL 函數編寫、驗證、推導再應用，極大提高了數據開發(fā)效率，為后續(xù)廣告精準投放提供了強有力的數據支持。
當前，騰梭科技星云零售信貸業(yè)務基于 Apache Doris 搭建了高度統一實時的數據倉庫，實現星云管理后臺中的風控報表管理、運營報表管理、用戶行為日志分析等信貸業(yè)務應用。Apache Doris 的引入為我們帶來以下收益與成果：
靈活數據分析：不論是業(yè)務端還是數據開發(fā)端，都可以基于 Doris 支持自定義導數、動態(tài)配置，實現靈活及易擴展的多維數據分析。
查詢快速響應：從業(yè)務層面來看，現階段的風控信貸點查、偏離計算等復雜場景都可以基于 Apache Doris 進行多表關聯，并且實現毫秒級查詢響應，大幅提升查詢效率。
交付效率提升：助貸業(yè)務的核心業(yè)務為客戶管理，在引入 Apache Doris 后，其數據分層存儲與開箱即用的分析函數，在用戶行為、信用評估、風險控制等多方面提供了有效報表分析，以挖掘更多潛在用戶，大幅提升交付效率，實現精準獲客的目標。
綜合成本降低：與之前數據源端存儲不同，Apache Doris 極致的存儲壓縮比，降低了 70 % 的存儲成本。同時，Apache Doris 支持集群節(jié)點進程?；睢⒆詣泳鈽O致，幾乎達到零運維，為公司運維成本控制提供了核心收益。
未來，我們希望基于 Apache Doris 冷熱分層技術實現統一的數據歸檔功能，將冷數據、歷史數據定時進行歸檔，進一步優(yōu)化數倉存儲空間。同時，利用 Apache Doris 湖倉一體功能實現智能數據網關，使 Schema 列類型等元數據能夠映射至 Apache Doris 的數據結構中，形成統一元數據映射結構，提供一致性的查詢體驗。
最后，感謝 Apache Doris 社區(qū)和 SelectDB 技術團隊在數倉搭建過程中的積極響應與技術支持，未來我們也會持續(xù)參與社區(qū)活動，將相關成果貢獻回饋社區(qū)，希望 Apache Doris 飛速發(fā)展，越來越好！
免責聲明：此文內容為第三方自媒體作者發(fā)布的觀察或評論性文章，所有文字和圖片版權歸作者所有，且僅代表作者個人觀點，與極客網無關。文章僅供讀者參考，并請自行核實相關內容。投訴郵箱：editor@fromgeek.com。
免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。
