導讀： 隨著業務量快速增長，資料規模的不斷擴大，杭銀消金早期的大資料平臺在應對實時性更強、複雜度更高的的業務需求時存在瓶頸。為了更好的應對未來的資料規模增長，杭銀消金於 2022 年 10 月正式引入 Apache Doris 1.2 對現有的風控資料集市進行了升級改造，利用 Multi Catalog 功能統一了 ES、Hive、GP 等資料來源出口，實現了聯邦查詢，為未來統一資料查詢閘道器奠定了基礎；同時，基於 Apache Doris 高效能、簡單易用、部署成本低等諸多優勢，也使得各大業務場景的查詢分析響應實現了從分鐘級到秒級的跨越。

作者｜杭銀消金大資料團隊 周其進，唐海定， 姚錦權

杭銀消費金融股份有限公司，成立於 2015 年 12 月，是杭州銀行牽頭組建的浙江省首家持牌消費金融公司，經過這幾年的發展，在 2022 年底資產規模突破 400 億，服務客戶數超千萬。公司秉承“數字普惠金融”初心，堅持服務傳統金融覆蓋不充分的、具有消費信貸需求的客戶群體，以“資料、場景、風控、技術”為核心，依託大資料、人工智慧、雲端計算等網際網路科技，為全國消費者提供專業、高效、便捷、可信賴的金融服務。

業務需求

杭銀消金業務模式是線上業務結合線下業務的雙引擎驅動模式。為更好的服務使用者，運用資料驅動實現精細化管理，基於當前業務模式衍生出了四大類的業務資料需求：

• 預警類：實現業務流量監控，主要是對信貸流程的使用者數量與金額進行實時監控，出現問題自動告警。
• 分析類：支援查詢統計與臨時取數，對信貸各環節進行分析，對審批、授信、支用等環節的使用者數量與額度情況查詢分析。
• 看板類：打造業務實時駕駛艙與 T+1 業務看板，提供內部管理層與運營部門使用，更好輔助管理進行決策。
• 建模類：支援多維模型變數的建模，通過演算法模型回溯使用者的金融表現，提升審批、授信、支用等環節的模型能力。

資料架構 1.0

為滿足以上需求，我們採用 Greenplum + CDH 融合的架構體系建立了大資料平臺 1.0 ，如下圖所示，大資料平臺的資料來源均來自於業務系統，我們可以從資料來源的 3 個流向出發，瞭解大資料平臺的組成及分工：

• 業務系統的核心繫統資料通過 CloudCanal 實時同步進入 Greenplum 數倉進行資料實時分析，為 BI 報表，資料大屏等應用提供服務，部分資料進入風控集市 Hive 中，提供查詢分析和建模服務。
• 業務系統的實時資料推送到 Kafka 訊息佇列，經 Flink 實時消費寫入 ES，通過風控變數提供資料服務，而 ES 中的部分資料也可以流入 Hive 中，進行相關分析處理。
• 業務系統的風控資料會落在 MongoDB，經過離線同步進入風控集市 Hive，Hive 數倉支撐了查詢平臺和建模平臺，提供風控分析和建模服務。

我們將 ES 和 Hive 共同組成了風控資料集市，從上述介紹也可知，四大類的業務需求基本都是由風控資料集市來滿足的，因此我們後續的改造升級主要基於風控資料集市來進行。在這之前，我們先了解一下風控資料集市 1.0 是如何來運轉的。

風控資料集市 1.0

風控資料集市原有架構是基於 CDH 搭建的，由實時寫入和離線統計分析兩部分組成，整個架構包含了 ES、Hive、Greenplum 等核心元件，風控資料集市的資料來源主要有三種：通過 Greenplum 數倉同步的業務系統資料、通過 MongoDB 同步的風控決策資料，以及通過 ES 寫入的實時風控變數資料。

實時流資料： 採用了 Kafka + Flink + ES 的實時流處理方式，利用 Flink 對 Kafka 的實時資料進行清洗，實時寫入ES，並對部分結果進行彙總計算，通過介面提供給風控決策使用。

離線風控資料： 採用基於 CDH 的方案實現，通過 Sqoop 離線同步核心數倉 GP 上的資料，結合實時資料與落在 MongoDB 上的三方資料，經資料清洗後統一彙總到 Hive 數倉進行日常的跑批與查詢分析。

需求滿足情況：

在大資料平臺 1.0 的的支援下，我們的業務需求得到了初步的實現：

• 預警類：基於 ES + Hive 的外表查詢，實現了實時業務流量監控；
• 分析類：基於 Hive 實現資料查詢分析和臨時取數；
• 看板類：基於 Tableau +Hive 搭建了業務管理駕駛艙以及T+1 業務看板；
• 建模類：基於 Spark+Hive 實現了多維模型變數的建模分析；

受限於 Hive 的執行效率，以上需求均在分鐘級別返回結果，僅可以滿足我們最基本的訴求，而面對秒級甚至毫秒級的分析場景，Hive 則稍顯吃力。

存在的問題：

• 單表寬度過大，影響查詢效能。風控資料集市的下游業務主要以規則引擎與實時風控服務為主，因規則引擎的特殊性，公司在資料變數衍生方面資源投入較多，某些維度上的衍生變數會達到幾千甚至上萬的規模，這將導致 Hive 中儲存的資料表字段非常多，部分經常使用的大寬表字段數量甚至超過上千，過寬的大寬表非常影響實際使用中查詢效能。
• 資料規模龐大，維護成本高。 目前 Hive 上的風控資料集市已經有存量資料在百 T 以上，面對如此龐大的資料規模，使用外表的方式進行維護成本非常高，資料的接入也成為一大難題。
• 介面服務不穩定。 由風控資料集市離線跑批產生的變數指標還兼顧為其他業務應用提供資料服務的職責，目前 Hive 離線跑批後的結果會定時推送到 ES 叢集（每天更新的資料集比較龐大，介面呼叫具有時效性），推送時會因為 IO 過高觸發 ES 叢集的 GC 抖動，導致介面服務不穩定。

除此之外，風控分析師與建模人員一般通過 Hive & Spark 方式進行資料分析建模，這導致隨著業務規模的進一步增大，T+1 跑批與日常分析的效率越來越低，風控資料集市改造升級的需求越發強烈。

技術選型

基於業務對架構提出的更高要求，我們期望引入一款強勁的 OLAP 引擎來改善架構，因此我們於 2022 年 9 月份對 ClickHouse 和 Apache Doris 進行了調研，調研中發現 Apache Doris 具有高效能、簡單易用、實現成本低等諸多優勢，而且 Apache Doris 1.2 版本非常符合我們的訴求，原因如下：

寬表查詢效能優異：從官方公佈的測試結果來看，1.2 Preview 版本在 SSB-Flat 寬表場景上相對 1.1.3 版本整體效能提升了近 4 倍、相對於 0.15.0 版本效能提升了近 10 倍，在 TPC-H 多表關聯場景上較 1.1.3 版本上有近 3 倍的提升、較 0.15.0 版本效能提升了 11 倍以上，多個場景效能得到飛躍性提升。

便捷的資料接入框架以及聯邦資料分析能力： Apache Doris 1.2 版本推出的 Multi Catalog 功能可以構建完善可擴充套件的資料來源連線框架，便於快速接入多類資料來源，提供基於各種異構資料來源的聯邦查詢和寫入能力。 目前 Multi-Catalog 已經支援了 Hive、Iceberg、Hudi 等資料湖以及 MySQL、Elasticsearch、Greenplum 等資料庫，全面覆蓋了我們現有的元件棧，基於此能力有希望通過 Apache Doris 來打造統一資料查詢閘道器。

生態豐富： 支援 Spark Doris Connector、Flink Doris Connector，方便離線與實時資料的處理，縮短了資料處理鏈路耗費的時間。

社群活躍： Apache Doris 社群非常活躍，響應迅速，並且 SelectDB 為社群提供了一支專職的工程師團隊，為使用者提供技術支援服務。

資料架構 2.0

風控資料集市 2.0

基於對 Apache Doris 的初步的瞭解與驗證，22 年 10 月在社群的支援下我們正式引入 Apache Doris 1.2.0 Preview 版本作為風控資料集市的核心元件，Apache Doris 的 Multi Catalog 功能助力大資料平臺統一了 ES、Hive、Greenplum 等資料來源出口，通過 Hive Catalog 和 ES Catalog 實現了對 Hive & ES 等多資料來源的聯邦查詢，並且支援 Spark-Doris-Connector，可以實現資料 Hive 與 Doris 的雙向流動，與現有建模分析體系完美整合，在短期內實現了效能的快速提升。

大資料平臺 2.0

風控資料集市調整優化之後，大資料平臺架構也相應的發生了變化，如下圖所示，僅通過 Doris 一個元件即可為資料服務、分析平臺、建模平臺提供資料服務。

在最初進行聯調適配的時候，Doris 社群和 SelectDB 支援團隊針對我們提出的問題和疑惑一直保持高效的反饋效率，給於積極的幫助和支援，快速幫助我們解決在生產上遇到的問題。

需求實現情況：

在大資料平臺 2.0 的加持下，業務需求實現的方式也發生了變更，主要變化如下所示

• 預警類：基於 ES Catalog+ Doris 實現了對實時資料的查詢分析。在架構 1.0 中，實時資料落在 ES 叢集上，通過 Hive 外表進行查詢分析，查詢結果以分鐘級別返回；而在 Doris 1.2 整合之後， 使用 ES Catalog 訪問 ES，可以實現對 ES 資料秒級統計分析。
• 分析類：基於 Hive Catalog + Doris 實現了對現有風控資料集市的快速查詢。目前 Hive 資料集市存量表在兩萬張左右，如果通過直接建立 Hive 外部表的方式，表結構對映關係的維護難度與資料同步成本使這一方式幾乎不可能實現。而 Doris 1.2 的 Multi Catalog 功能則完美解決了這個問題，只需要建立一個 Hive Catalog，就能對現有風控資料集市進行查詢分析，既能提升查詢效能，還減少了日常查詢分析對跑批任務的資源影響。
• 看板類：基於 Tableau + Doris 聚合展示業務實時駕駛艙和 T+1 業務看板，最初使用 Hive 時，報表查詢需要幾分鐘才能返回結果，而 Apache Doris 則是秒級甚至是毫秒級的響應速度。
• 建模類：基於 Spark+Doris 進行聚合建模。利用 Doris1.2 的 Spark-Doris-Connector功 能，實現了 Hive 與 Doris 資料雙向同步，滿足了 Spark 建模平臺的功能複用。同時增加了 Doris 資料來源，基礎資料查詢分析的效率得到了明顯提升，建模分析能力的也得到了增強。

在 Apache Doris 引入之後，以上四個業務場景的查詢耗時基本都實現了從分鐘級到秒級響應的跨越，效能提升十分巨大。

生產環境叢集監控

為了快速驗證新版本的效果，我們在生產環境上搭建了兩個叢集，目前生產叢集的配置是 4 個 FE + 8個 BE，單個節點是配置為 64 核+ 256G+4T，備用叢集為 4 個 FE + 4 個 BE 的配置，單個節點配置保持一致。

叢集監控如下圖所示：

可以看出，Apache Doris 1.2 的查詢效率非常高，原計劃至少要上 10 個節點，而在實際使用下來，我們發現當前主要使用的場景均是以 Catalog 的方式查詢，因此叢集規模可以相對較小就可以快速上線，也不會破壞當前的系統架構，相容性非常好。

資料整合方案

前段時間，Apache Doris 1.2.2 版本已經發布，為了更好的支撐應用服務，我們使用 Apache Doris 1.2.2 與 DolphinScheduler 3.1.4 排程器、SeaTunnel 2.1.3 資料同步平臺等開源軟體實現了整合，以便於資料定時從 Hive 抽取到 Doris 中。整體的資料整合方案如下：

在當前的硬體配置下，資料同步採用的是 DolphinScheduler 的 Shell 指令碼模式，定時調起 SeaTunnel 的指令碼，資料同步任務的配置檔案如下：

 env{
  spark.app.name = "hive2doris-template"
  spark.executor.instances = 10
  spark.executor.cores = 5
  spark.executor.memory = "20g"
}
spark {
  spark.sql.catalogImplementation = "hive"
}
source {
  hive {
    pre_sql = "select * from ods.demo_tbl where dt='2023-03-09'"
    result_table_name = "ods_demo_tbl"
  }
}
 
transform {
}
 
sink {
  doris {
      fenodes = "192.168.0.10:8030,192.168.0.11:8030,192.168.0.12:8030,192.168.0.13:8030"
      user = root
      password = "XXX"
      database = ods
      table = ods_demo_tbl
      batch_size = 500000
      max_retries = 1
      interval = 10000
      doris.column_separator = "\t"
    }
}

該方案成功實施後，資源佔用、計算記憶體佔用有了明顯的降低，查詢效能、匯入效能有了大幅提升：

1. 儲存成本降低

使用前：Hive 原始表包含 500 個欄位，單個分割槽資料量為 1.5 億/天，在 HDFS 上佔用約 810G 的空間。

使用後：我們通過 SeaTunnel 調起 Spark on YARN 的方式進行資料同步，可以在 40 分鐘左右完成資料同步，同步後資料佔用 270G 空間，儲存資源僅佔之前的 1/3。

1. 計算記憶體佔用降低，效能提升顯著

使用前：上述表在 Hive 上進行 Group By 時，佔用 YARN 資源 720 核 1.44T 記憶體，需要 162 秒才可返回結果；

使用後：

• 通過 Doris 呼叫 Hive Catalog 進行聚合查詢，在設定 set exec_mem_limit=16G 情況下用時 58.531 秒，查詢耗時較之前減少了近 2/3；
• 在同等條件下，在 Doris 中執行相同的的操作可以在 0.828 秒就能返回查詢結果，效能增幅巨大。

具體效果如下：

（1）Hive 查詢語句，用時 162 秒。

select count(*),product_no   FROM ods.demo_tbl where dt='2023-03-09'
group by product_no;

（2）Doris 上 Hive Catalog 查詢語句，用時 58.531 秒。

set exec_mem_limit=16G；
select count(*),product_no   FROM hive.ods.demo_tbl where dt='2023-03-09'
group by product_no;

（3）Doris 上本地表查詢語句，僅用時0.828秒。

select count(*),product_no   FROM ods.demo_tbl where dt='2023-03-09'
group by product_no;

1. 匯入效能提升

使用前：Hive 原始表包含 40 個欄位，單個分割槽資料量 11 億/天，在 HDFS 上佔用約 806G 的空間

使用後：通過 SeaTunnel 調起 Spark on YARN 方式進行資料同步，可以在 11 分鐘左右完成資料同步，即 1 分鐘同步約一億條資料，同步後佔用 378G 空間。

可以看出，在資料匯入效能的提升的同時，資源也有了較大的節省，主要得益於對以下幾個引數進行了調整：

push_write_mbytes_per_sec：BE 磁碟寫入限速，300M

push_worker_count_high_priority: 同時執行的 push 任務個數，15

push_worker_count_normal_priority: 同時執行的 push 任務個數，15

架構收益

（1）統一資料來源出口，查詢效率顯著提升

風控資料集市採用的是異構儲存的方式來儲存資料，Apache Doris 的 Multi Catalog 功能成功統一了 ES、Hive、GP 等資料來源出口，實現了聯邦查詢。 同時，Doris 本身具有儲存能力，可支援其他資料來源中的資料通過外表插入內容的方式快速進行資料同步，真正實現了資料門戶。此外，Apache Doris 可支援聚合查詢，在向量化引擎的加持下，查詢效率得到顯著提升。

（2） Hive 任務拆分，提升叢集資源利用率

我們將原有的 Hive 跑批任務跟日常的查詢統計進行了隔離，以提升叢集資源的利用效率。目前 YARN 叢集上的任務數量是幾千的規模，跑批任務佔比約 60%，臨時查詢分析佔比 40%，由於資源限制導致日常跑批任務經常會因為資源等待而延誤，臨時分析也因資源未及時分配而導致任務無法完成。當部署了 Doris 1.2 之後，對資源進行了劃分，完全擺脫 YARN 叢集的資源限制，跑批與日常的查詢統計均有了明顯的改善，基本可以在秒級得到分析結果，同時也減輕了資料分析師的工作壓力，提升了使用者對平臺的滿意度。

（3）提升了資料介面的穩定性，資料寫入效能大幅提升

之前資料介面是基於 ES 叢集的，當進行大批量離線資料推送時會導致 ES 叢集的 GC 抖動，影響了介面穩定性，經過調整之後，我們將介面服務的資料集儲存在 Doris 上，Doris 節點並未出現抖動，實現資料快速寫入，成功提升了介面的穩定性，同時 Doris 查詢在資料寫入時影響較小，資料寫入效能較之前也有了非常大的提升，千萬級別的資料可在十分鐘內推送成功。

（4）Doris 生態豐富，遷移方便成本較低。

Spark-Doris-Connector 在過渡期為我們減輕了不少的壓力，當資料在 Hive 與 Doris 共存時，部分 Doris 分析結果通過 Spark 回寫到 Hive 非常方便，當 Spark 呼叫 Doris 時只需要進行簡單改造就能完成原有指令碼的複用，遷移方便、成本較低。

（5）支援橫向熱部署，叢集擴容、運維簡單。

Apache Doris 支援橫向熱部署，叢集擴容方便，節點重啟可以在在秒級實現，可實現無縫對接，減少了該過程對業務的影響； 在架構 1.0 中，當 Hive 叢集與 GP 叢集需要擴容更新時，配置修改後一般需要較長時間叢集才可恢復，使用者感知比較明顯。而 Doris 很好的解決了這個問題，實現使用者無感知擴容，也降低了叢集運維的投入。

未來與展望

當前在架構 2.0 中的 Doris 叢集在大資料平臺中的角色更傾向於查詢優化，大部分資料還集中維護在 Hive 叢集上，未來我們計劃在升級架構 3.0 的時候，完成以下改造：

• 實時全量資料接入：利用 Flink 將所有的實時資料直接接入 Doris，不再經過 ES 儲存；
• 資料集資料完整性：利用 Doris 構建實時資料集市的原始層，利用 FlinkCDC 等同步工具將業務庫 MySQL與決策過程中產生的 MongoDB 資料實時同步到 Doris，最大限度將現有資料都接入 Doris 的統一平臺，保證資料集資料完整性。
• 離線跑批任務遷移：將現有 Hive&Spark 中大部分跑批任務遷移至 Doris，提升跑批效率；
• 統一查詢分析出口：將所有的查詢分析統一集中到 Doris，完全統一資料出口，實現統一資料查詢閘道器，使資料的管理更加規範化；
• 強化叢集穩定擴容：引入視覺化運維管理工具對叢集進行維護和管理，使 Doris 叢集能夠更加穩定支撐業務擴充套件。

總結與致謝

Apache Doris1.2 是社群在版本迭代中的重大升級，藉助 Multi Catalog 等優異功能能讓 Doris 在 Hadoop 相關的大資料體系中快速落地，實現聯邦查詢；同時可以將日常跑批與統計分析進行解耦，有效提升大資料平臺的的查詢效能。

作為第一批 Apache Doris1.2 的使用者，我們深感榮幸，同時也十分感謝 Doris 團隊的全力配合和付出，可以讓 Apache Doris 快速落地、上線生產，併為後續的迭代優化提供了可能。

Apache Doris 1.2 值得大力推薦，希望大家都能從中受益，祝願 Apache Doris 生態越來越繁榮，越來越好！