本文導(dǎo)讀：

金融壹賬通作為中國平安集團的聯(lián)營公司，依托平安集團 30 多年金融行業(yè)的豐富經(jīng)驗及自主科研能力，向客戶提供“橫向一體化、縱向全覆蓋”的整合產(chǎn)品，以“技術(shù)+業(yè)務(wù)”為獨特競爭力，幫助客戶提升效率、提升服務(wù)、降低成本、降低風險，實現(xiàn)數(shù)字化轉(zhuǎn)型。在搭建數(shù)字化解決方案的過程中，面對傳統(tǒng)報表制作過程中指標口徑不統(tǒng)一、計算重復(fù)與交付效率低等痛點，金融壹賬通決定基于 Apache Doris 搭建一體化指標數(shù)據(jù)服務(wù)平臺，實現(xiàn)指標集中構(gòu)建和管理、減少 ETL 開發(fā)工作量等業(yè)務(wù)目標。本文將詳細介紹金融壹賬通兩代架構(gòu)的演進過程，分享數(shù)據(jù)服務(wù)平臺的建設(shè)經(jīng)驗與應(yīng)用實踐，向大家展示如何基于 Apache Doris 在多表關(guān)聯(lián)與高并發(fā)場景下實現(xiàn)毫秒級查詢響應(yīng)。

作者｜ 金融壹賬通 數(shù)據(jù)挖掘工程師 蘭后

金融壹賬通是面向金融機構(gòu)的商業(yè)科技服務(wù)提供商（Technology-as-a-Service Provider），為國家高新技術(shù)企業(yè)。作為中國平安集團的聯(lián)營公司，金融壹賬通依托平安集團 30 多年金融行業(yè)的豐富經(jīng)驗及自主科研能力，向客戶提供“橫向一體化、縱向全覆蓋”的整合產(chǎn)品，包括數(shù)字化銀行、數(shù)字化保險和提供金融科技數(shù)字基礎(chǔ)設(shè)施的加馬平臺，以“技術(shù)+業(yè)務(wù)”為獨特競爭力，幫助客戶提升效率、提升服務(wù)、降低成本、降低風險，實現(xiàn)數(shù)字化轉(zhuǎn)型。

業(yè)務(wù)痛點

在搭建數(shù)字化解決方案過程中，我們主要利用指標（如銀行經(jīng)營業(yè)績指標：客戶 AUM）來直觀地反映企業(yè)經(jīng)營狀態(tài)，通過指標開發(fā)報表以幫助業(yè)務(wù)人員進行數(shù)據(jù)分析，進而驅(qū)動管理決策、賦能數(shù)字化經(jīng)營。我們早期的報表制作方式是由不同的業(yè)務(wù)線人員根據(jù)自己的業(yè)務(wù)范圍，使用不同的分析工具去定義指標，這種傳統(tǒng)的方式在跨業(yè)務(wù)合作時會帶來兩大痛點：

• 指標口徑、標準不統(tǒng)一： 各個業(yè)務(wù)線生成的報表堆積如山，由于使用不同分析工具，使對接數(shù)據(jù)源多樣復(fù)雜，導(dǎo)致指標口徑相互打架的問題。
• 指標計算重復(fù)、交付效率低： 開發(fā)流程需要業(yè)務(wù)方提出后，由 IT 人員下探數(shù)據(jù)源并加工，再制作報表、上線驗收。整個過程中，IT 需要和業(yè)務(wù)多次溝通來同步信息，導(dǎo)致普通報表開發(fā)需要兩周時間完成。

為了解決這兩大問題，我們集團內(nèi)部決定自研一體化指標數(shù)據(jù)服務(wù)平臺，通過建立指標體系貼合客戶戰(zhàn)略目的，借助服務(wù)平臺規(guī)范開發(fā)流程和使用方式，實現(xiàn)指標集中構(gòu)建和管理。同時，使用 OLAP 查詢引擎助力指標開發(fā)與應(yīng)用，讓業(yè)務(wù)人員能夠快速找到所需數(shù)據(jù)，減少 ETL 開發(fā)工作量、縮短報表開發(fā)周期、加速指標發(fā)布與可視化看板生成的時間。

在數(shù)據(jù)服務(wù)平臺建設(shè)過程中，金融壹賬通經(jīng)歷了兩代數(shù)倉架構(gòu)演進。第一代架構(gòu)基于 Apache Kylin 預(yù)計算的方式查詢指標數(shù)據(jù)，并在架構(gòu)使用后，發(fā)現(xiàn)其查詢性能不足的問題。為了滿足我們的業(yè)務(wù)訴求，我們進一步開展 OLAP 選型調(diào)研，最終引入 Apache Doris 進行架構(gòu)升級，借助 Apache Doris 的高性能分析能力為指標高效查詢保駕護航。

本文將詳細介紹金融壹賬通兩代架構(gòu)的演進過程，分享如何基于 Apache Doris 搭建指標統(tǒng)一構(gòu)建、查詢、治理的一體化數(shù)據(jù)平臺，并在多表關(guān)聯(lián)與高并發(fā)場景下實現(xiàn)毫秒級查詢響應(yīng)。

早期架構(gòu)挑戰(zhàn)

架構(gòu) 1.0 ：Hadoop + Presto + Apache Kylin

在業(yè)務(wù)初期，我們基于 Apache Kylin 進行 T+1 報表開發(fā)，上圖是指標構(gòu)建和查詢的過程。在指標構(gòu)建過程中，開發(fā)人員會根據(jù)選擇的指標和維度進行 SQL 拼接， 通過 API 調(diào)用 Apache Kylin 的方式對各個維度進行與計算，完成模型構(gòu)建和數(shù)據(jù)加載。在指標查詢的過程中，采用快速查詢和下壓查詢的組合策略，如果查詢字段命中 Cube， 我們可以在 Apache Kylin 直接查詢；如果沒有命中，則下壓至 Presto 再進行查詢。

隨著業(yè)務(wù)量不斷增長，使用平臺的業(yè)務(wù)用戶越來越多，在面向客戶推廣與集團內(nèi)部使用過程中，我們發(fā)現(xiàn)該架構(gòu)在以下方面表現(xiàn)不足，無法滿足我們的業(yè)務(wù)訴求：

• 靈活分析： Apache Kylin 預(yù)計算只能滿足部分場景需求，沒有辦法滿足更靈活的分析需求。
• 查詢性能： 當查詢字段未命中 Cube 時，需要下壓至 Presto。而 Presto 的查詢性能得不到保障，特別是在查詢碼值的場景下，會遇到查詢超時的現(xiàn)象，阻礙指標發(fā)布。
• 使用與運維成本： Apache Kylin 架構(gòu)在查詢與開發(fā)過程中需要使用多套組件，造成了過高的維護成本。

基于第一代架構(gòu)的使用經(jīng)驗，我們急需找到一個既可支持指標多表關(guān)聯(lián)查詢的場景，又可以達到降本增效的 OLAP 引擎。 帶著這樣的訴求，我們對比了當下比較熱門的 OLAP 引擎進行系統(tǒng)選型，從多表關(guān)聯(lián)場景、使用協(xié)議、使用成本、金融應(yīng)用場景與案例四大方面進行比較。

OLAP 選型對比

我們首先排除了 TiDB ，主要因為其更傾向于滿足 TP 需求，在應(yīng)對大數(shù)據(jù)量分析場景時性能相對不足。其次，我們也排除了 Clickhouse 和 Greenplum。由于 Greenplum 單機性能較差，不適用于我們的查詢場景；Clickhouse 雖然在單表查詢性能表現(xiàn)不錯，但是不支持 MySQL 協(xié)議，多表 Join 無法發(fā)揮性能，因此兩款產(chǎn)品均不能滿足我們對于海量數(shù)據(jù)在多表關(guān)聯(lián)場景下的查詢訴求。

最終，在集團內(nèi)部其他子公司的使用反饋與推薦下，我們發(fā)現(xiàn) Apache Doris 非常符合我們的訴求，并堅定不移地選擇 Apache Doris 進行架構(gòu)升級，主要原因如下：

• 開發(fā)簡易方便： Apache Doris 不僅兼容 MySQL 協(xié)議，還能夠支持標準的 SQL 查詢語法使開發(fā)簡單方便。
• 復(fù)雜場景多表關(guān)聯(lián)查詢性能： Apache Doris 支持分布式 Join、明細聚合等方式，在進行多表 Join 時能夠提供多種優(yōu)化機制，提升查詢效率。同時，Apache Doris 還支持物化視圖與索引功能來完成預(yù)計算效果，并在命中物化視圖時實現(xiàn)快速查詢響應(yīng)。
• 運維簡單、方便擴展： Apache Doris 的整體部署只有 FE 與 BE 兩種角色，極大簡化了架構(gòu)鏈路，使架構(gòu)無需再依賴其他組件，實現(xiàn)低成本運維。

基于 Apache Doris 架構(gòu)升級

架構(gòu) 2.0 ：Apache Doris

基于 Apache Doris 的性能優(yōu)勢，我們從數(shù)據(jù)遷移和應(yīng)用兩方面進行了架構(gòu)升級。在數(shù)據(jù)遷移過程中，Apache Doris 替代了第一代架構(gòu)中 Apache Kylin 與 Presto，統(tǒng)一進行指標數(shù)據(jù)存儲、處理、計算，并利用 Duplicate Key 模型對明細數(shù)據(jù)進行查詢，使用 Range 進行時間分區(qū)并制定維度關(guān)聯(lián)鍵作為 Key，有效解決了早期架構(gòu)中 Presto 明細查詢時性能不足、并發(fā)不夠的痛點。同時，Apache Doris 在查詢引擎方面采用了 MPP 模型，具備高并發(fā)、低延遲的計算能力，使節(jié)點間和節(jié)點內(nèi)都能夠并行執(zhí)行，支持多個大表分布式 Shuffle Join，能夠滿足我們對復(fù)雜場景下多表關(guān)聯(lián)查詢的需求。

在應(yīng)用方面，我們重寫了 MySQL 兼容的查詢引擎，當使用指標平臺進行查詢時，不再需要借助架構(gòu) 1.0 中 Apache Kylin 調(diào)用接口、從頁面中點擊重跑指標等一系列比較繁瑣的工作，開發(fā)人員可以基于 Apache Doris 直接使用 MySQL 語法進行查詢，極大簡化了指標發(fā)布過程。

Apache Kylin vs. Apache Doris

我們選取了指標平臺常見的多表關(guān)聯(lián)場景對 Apache Kylin 與 Apache Doris 進行性能對比，發(fā)現(xiàn) Apache Doris 在查詢性能與指標開發(fā)效率上表現(xiàn)都更為優(yōu)異。如上圖所示，Apache Doris 在數(shù)十萬數(shù)據(jù)集關(guān)聯(lián)情況下，查詢響應(yīng)基本達到毫秒級。 同時，我們不再需要等待 Apache Kylin 完成 Segment 構(gòu)建后使用指標，指標發(fā)布從原來的平均 30 分鐘到現(xiàn)在的即發(fā)即用，顯著提升指標開發(fā)效率。

Apache Doris 的引入還大大節(jié)省了指標存儲空間，符合集團降本的需求。集團內(nèi)部的其他業(yè)務(wù)線（產(chǎn)險、壽險）也因此開始對 Apache Doris 進行鋪開使用。新架構(gòu)的升級不論是從硬件、人力、時間上都實現(xiàn)了非常高效能的提升，成為一體化數(shù)字指標平臺建設(shè)的強大后盾。

一體化指標數(shù)據(jù)平臺

在架構(gòu)升級完成后，我們可以建設(shè)統(tǒng)一的指標體系，通過指標內(nèi)容、BI 與 AI 技術(shù)構(gòu)建平臺功能，共同建設(shè)一體化指標數(shù)據(jù)平臺。

構(gòu)建指標體系

金融壹賬通借助歸因關(guān)系分析幫助機構(gòu)自上而下對指標進行建設(shè)，梳理核心 KPI 并逐層拆建指標，保障指標體系的完整性與可落地性。根據(jù)指標生成的方式，將指標類型進行細分，以銀行營銷場景舉例，針對銀行資產(chǎn)管理中對客戶資產(chǎn)總值的衡量指標（AUM）可以細分為以下三種類型：

• 原子指標：通過數(shù)據(jù)源接入到指標平臺的最細粒度指標，一般為表字段，例如 AUM 余額。
• 衍生指標：為了進一步指標分析，平臺自動衍生一系列指標，如 AUM 同比、環(huán)比凈增等。
• 派生指標：為了滿足復(fù)雜的指標分析場景，基于原子指標，添加過濾條件或者結(jié)合其他指標進行運算，幫助用戶自助配置看板，節(jié)省取數(shù)過程。例如用戶希望生成客均 AUM 余額進行分析，平臺可以借助原子指標 AUM 余額與全量客戶數(shù)生成該指標。

構(gòu)建指標平臺功能

指標平臺的功能實現(xiàn)主要依賴于 Apache Doris 數(shù)倉架構(gòu)的支持，整體指標線上流程基于開發(fā)和業(yè)務(wù)配合完成。開發(fā)人員首先統(tǒng)一在平臺進行元數(shù)據(jù)管理和指標錄入，包括對加工報表的底表進行注冊，配置中間表的數(shù)據(jù)粒度和更新頻率等，接著對表進行關(guān)聯(lián)、錄入指標名稱和指標口徑信息。在輸入指標基礎(chǔ)信息之后，交由業(yè)務(wù)人員負責，選擇對指標分析所需維度，對指標進行發(fā)布。

基于以上兩個步驟，我們可以在平臺中對指標數(shù)據(jù)進一步分析。如上圖左側(cè)所示，指標平臺提供了各種柱狀分析視圖，業(yè)務(wù)人員能夠可視化地查看指標排行榜看板，分析各銀行分行 AUM 排名情況。同時，我們?nèi)谌肓?AI 智能算法，借助時序模型檢測指標異常，通過根因分析算法輔助 KPI 檢視，并分析指標異動原因。對于存量指標，平臺提供了價值評分體系，能夠及時下線價值低的指標，達到邊使用邊治理的目的。

基于 Apache Doris 指標應(yīng)用實踐

一體化數(shù)據(jù)平臺的建設(shè)完全解決了金融壹賬通在傳統(tǒng)報表開發(fā)時指標口徑不統(tǒng)一和指標重復(fù)計算的問題。在分析效率方面，我們希望在復(fù)雜的多表關(guān)聯(lián)場景下，實現(xiàn)接口 600 毫秒響應(yīng)時間、查詢響應(yīng)在 100 毫秒內(nèi)的目標。因此，我們對 Apache Doris 進行了測試與調(diào)優(yōu)，從數(shù)據(jù)的前期準備、集群部署、模型調(diào)優(yōu)三方面分享 Apache Doris 在該場景下的應(yīng)用實踐。

在前期數(shù)據(jù)準備過程中，考慮到我們的數(shù)據(jù)集和官網(wǎng)測試的 SSB 數(shù)據(jù)集很相似，我們選擇了官網(wǎng)推薦的開發(fā)測試環(huán)境配置，選用 Apache Doris 1.1 版本進行測試。因為我們是通過 Python Mock 數(shù)據(jù)直接生成 CSV 文件，所以我們采用 Stream Load 的方式分批導(dǎo)數(shù)，每次導(dǎo)入的 CSV 文件都在 Stream Load 推薦的文件大小 1 - 10G 以內(nèi)，最終數(shù)據(jù)壓縮比達到 3 : 1 ，但單節(jié)點導(dǎo)入速度超過 40 MB /s。

在集群部署過程中，為了對指標性能和服務(wù)器監(jiān)控（CPU、IO、磁盤和內(nèi)存），我們借助 Prometheus 導(dǎo)入 Apache Doris 監(jiān)控模版對集群部署監(jiān)控，由 Prometheus 接收 Apache Doris 暴露監(jiān)控項，再借助 Grafana 進行可視化呈現(xiàn)。

在準備工作完成后即可開始進行大表關(guān)聯(lián)查詢，我們選擇了耗時較長的 SQL 來查詢指標趨勢圖。基于毫秒級查詢目標，我們實施了兩個優(yōu)化解決方案。第一個方案是利用 Colocation Join 將數(shù)據(jù)在建表時提前聚合。第二個方案是借助 Audit Loader 的方式收集高頻 SQL，反向優(yōu)化數(shù)倉的表構(gòu)建以及改寫 SQL，使用偏寬表設(shè)計代替之前的星型 / 雪花模型。通過兩個方案的測試與評估，我們發(fā)現(xiàn)第二個方案能夠在查詢響應(yīng)、服務(wù)資源節(jié)省中達到更加顯著的收益。

億級數(shù)據(jù)多表關(guān)聯(lián)查詢，實現(xiàn)毫秒級查詢響應(yīng)

我們將 SQL 查詢執(zhí)行時間進行了統(tǒng)計，如上圖所示在采取方案一 Colocation Join 的方式時，查詢響應(yīng)時間從之前的 5 秒提升至 1 秒。雖然查詢效率有所提升，但是我們希望能夠更進一步縮短響應(yīng)時間，完成預(yù)期目標。在采用方案二來調(diào)整數(shù)據(jù)模型后，SQL 執(zhí)行時間從原來的 5 秒達到 63 毫秒響應(yīng)時間，查詢響應(yīng)時間得到顯著提升，滿足我們對查詢響應(yīng)毫秒級的目標。

同時，我們借助 Grafana 查看 Apache Doris 查詢性能，發(fā)現(xiàn)寬表構(gòu)建的方案能夠使查詢時間從原來的十多秒縮短至百毫秒內(nèi)，服務(wù)器也不再出現(xiàn)抖動的情況。

啟用 SQL 緩存，節(jié)省服務(wù)器資源

采取寬表構(gòu)建方案后，為了進一步提升查詢性能，我們還啟用了 SQL 緩存，幫助 T+1 報表場景實現(xiàn)高效查詢性能：

• 在啟用緩存之后，基本所有查詢時長都在個位數(shù)，最終達到單用戶訪問頁面在 4 秒內(nèi)加載的成果；
• 在 30 個指標同時進行時（SQL 指令超 120 條），接口都可以滿足 600ms 內(nèi)返回；
• 在并發(fā)場景下，最優(yōu) TPS 達到 300， CPU、內(nèi)存、磁盤和 IO 滿足 80% 以下；
• 經(jīng)評估，我們發(fā)現(xiàn)在官網(wǎng)推薦的測試集群規(guī)模下，Apache Doris 都可以緩存上萬指標，極大節(jié)省了資源。

未來規(guī)劃

目前，金融壹賬通基于 Apache Doris 實現(xiàn)了指標統(tǒng)一構(gòu)建、查詢、治理的一體化數(shù)據(jù)平臺，為金融機構(gòu)提供了全面的指標分析與展示，智能的指標生命周期管理等服務(wù)。在這樣的平臺建設(shè)下，集團內(nèi)外多場景取得了非常顯著的成果，截止目前，完成上萬活躍指標、上千分析維度的積累，加工形成了上萬個看板，減少了 30 % ETL 開發(fā)工作量。 未來，公司將基于 Apache Doris 不斷探索與優(yōu)化，我們將重點推進以下幾個方面的工作：

• 平臺實時分析 ： 基于 Apache Doris 構(gòu)建湖倉一體，結(jié)合 Flink CDC、Apache Iceberg 共同構(gòu)建統(tǒng)一實時分析。
• 平臺物化視圖： 期待新版本亮點，探索多表關(guān)聯(lián)下的查詢優(yōu)化，比如構(gòu)建多表物化視圖。
• 其他產(chǎn)品遷移： 將中臺的其他產(chǎn)品遷移至 Apache Doris。目前，標簽平臺基于 Elasticsearch 存在一定的使用問題，未來我們也準備將該平臺遷入 Apache Doris。

在此特別感謝 SelectDB 技術(shù)團隊和 Apache Doris 社區(qū)在使用過程中遇到任何問題都能及時響應(yīng)，為我們降低了許多試錯成本。未來，我們也會更積極參與社區(qū)貢獻及活動，與社區(qū)共同進步和成長！文章來源地址http://www.zghlxwxcb.cn/news/detail-532252.html

到了這里，關(guān)于Apache Doris 在金融壹賬通指標中臺的應(yīng)用實踐的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！