導讀：隨著消費信貸規模快速增長，個人信貸市場呈現場景化、體驗感強的特征，精準營銷、精細化風險管理以及用戶使用體驗的優化愈發重要。作為中國卓越的由人工智能驅動的信貸科技服務平臺，奇富科技選擇將 Apache Doris 作為整體 OLAP 場景統一的分析引擎，并使用 Apache Doris 替換了 ClickHouse 和 MySQL ，使得報表分析場景 SLA 達標率提升至 99% 以上，平均查詢耗時降低 50%。使用 Doris 替換了 Elasticsearch，離線標簽場景數據導入時效從 4 小時縮短至 1 小時，為營銷活動、廣告投放等提供強有力的數據支持。此外，憑借 Doris Multi-Catalog 能力，實現湖倉查詢加速，徹底解決配置外表繁瑣、不支持元信息自動同步等問題，極大提升了數據處理與分析的速度。

作為中國卓越的人工智能驅動的信貸科技服務平臺，奇富科技（原 360 數科）致力于幫助金融機構提升智能化水平。經過多年金融領域實踐，奇富科技以自身強大安全生態為依托，完成了在人工智能、大數據、云計算等技術方面的專業積累。目前，已與銀行、消費金融公司、信托公司等建立廣泛合作，針對不同類型金融機構的需求提供定制化解決方案，幫助客戶完成數字化、智能化升級改造。

消費信貸對于促進消費起著越來越重要的作用，是助力消費恢復、激發潛在需求的重要手段之一。近年來，隨著消費信貸規模快速增長，消費信貸的產品和服務也越來越豐富，個人信貸市場呈現的場景化、體驗感強等特征。在此背景下，精準營銷、精細化風險管理以及提升用戶使用體驗愈發重要。

為更貼合場景需求、提供精準運營數據支持，奇富科技自 22 年 3 月開始引入 Apache Doris，希望通過 Apache Doris 融合用戶多維價值數據，基于海量數據進行實時準確的數據分析，以提供個性化的營銷方案及決策支持。截止目前 Apache Doris 已在奇富科技被多個業務線應用，每日線上運行數百同步工作流，日均新增及更新的數據規模達到數十億，承載了上百萬次的有效查詢。Apache Doris 的應用不僅有效提高了數據處理與分析的速度，還降低了運維成本、確保了系統的穩定性，為奇富科技實現精細化運營和營銷廣告精準投放提供了強有力的數據支持。

業務場景及應用現狀

奇富科技大數據平臺提供一站式大數據管理、開發、分析服務，覆蓋大數據資產管理、數據開發及任務調度、自助分析及可視化、統一指標管理等多個數據生命周期流程。其中，最典型的數據應用服務即在線報表分析和離線標簽服務，離線標簽服務又包含了用戶標簽點查、客群畫像、觸發式策略生成和人群圈選四大服務。為滿足不同業務數據需求，早期架構將數據分散存儲在 Clickhouse、Elasticsearch、MySQL 等多個組件中，帶來了數據應用和系統運維的挑戰：

• 部分 SLA 不達標：架構組件過多，原 OLAP 引擎的穩定性及可用性無法滿足 SLA 要求。
• 運維管理復雜：需同時管理多個組件，運維復雜度和難度均較高； ClickHouse 對其他組件依賴性高，擴容難度大；MySQL 單實例容量有限，需維護多個實例且不支持跨實例查詢，增加了管理成本。
• 數據治理難度高：整體數據關系復雜，數據治理難度較高，對于后續數據血緣和數據生命周期管理帶來較高的成本。

除此之外，還存在一些性能及穩定性問題，具體表現為：

• 查詢耗時高：MySQL / ClickHouse 在面對復雜查詢時性能較差，存在關聯查詢失敗率高、查詢響應速度慢等問題，無法滿足秒級查詢響應需求。
• 導入性能差：受限于 MySQL 可承載的數據規模（千萬級），無法滿足大規模數據導入的要求；且 ClickHouse 導入性能較差，容易出現導入不穩定的問題。

技術選型

為解決以上問題，奇富科技計劃引入一款分析型數據庫以滿足大部分 OLAP 場景需求，該數據庫應具備以下特性：

• 安全易治理：要求單一數據庫即可滿足大部分 OLAP 需求，簡化數據管理流程，提高數據治理效率；要求具備完善的權限控制機制，以保證數據的安全性和隱私性。
• 準確實時：支持數據實時導入及查詢，確保數據導入不丟不重，實現 Exactly Once 語義。
• 易用低成本：部署簡單、可根據需求實現靈活擴縮容，支持 MySQL 語法、降低開發人員學習門檻，提高開發效率。

基于以上選型要求，奇富科技對 ClickHouse、Apache Doris 進行了調研。其中 Apache Doris 在導入、查詢、運維等方面的性能符合選型要求，同時在社區規范性、活躍度、開放程度和可持續發展方向表現出色。因此，奇富科技選擇 Apache Doris 作為整體 OLAP 場景統一的分析引擎。

接下來將結合真實業務場景，介紹 Apache Doris 在奇富科技的深度應用和優化實踐，更好了解 Apache Doris 如何助力奇富科技實現精準營銷，提升業務收益。

Apache Doris 在報表分析場景的應用

在報表分析場景中，數據分析師通常會基于重要業務報告、圖表、當前業務狀況評估報告進行數據分析，旨在為業務策略決策提供重要依據。

早期架構在應對該場景時，會出現數據表同步時效 SLA 達標率（每日統計）波動較大的問題，經過深入分析是由數據同步過程所涉及組件繁多導致。不僅如此，組件繁多還增加了數據同步的復雜性，對數據源（MySQL、ClickHouse）和同步任務（如 DataX Job、Flink Job 等）的穩定性提出了挑戰。

報表引擎升級

為了解決這些問題，我們使用 Apache Doris 替換了 ClickHouse 和 MySQL ，由 Doris 統一為報表提供服務，降低報表數據源的復雜度。從下圖可知，Doris 架設于 Hive 數倉上層，可充分利用 Doris 強大的查詢性能，為報表分析場景提供查詢加速。同時 Apache Doris 支持原生 MySQL 協議，可與帆軟、觀遠等 BI 工具無縫結合，提升了報表分析的靈活性與易用性。

導入任務優先級

在原先的邏輯中，Doris 對于導入任務的處理沒有優先級的概念。當有大量任務同時提交時，Doris 會按照先進先出的邏輯執行任務。因此，我們主導設計并向社區貢獻了導入任務優先級功能。該功能可以根據用戶設定的優先級來處理導入任務，從而可以保證部分高優任務的時效性。詳細流程如下圖所示：

通過優先級設置，即使在任務高峰期，依然可以保證高優任務的時效性，極大提升了數據表同步時效 SLA 達標率。為數據的傳輸及應用提供了更靈活、高效的支持。

異地雙機房高可用方案

為保障 Doris 集群的可用性及穩定性、確保在機房故障時集群仍然可讀，并在故障恢復后主集群的數據能夠回寫，為 Doris 集群配備雙機房容災能力勢在必行。經過方案調研，決定通過自行開發 Replicator 主從同步插件來實現雙機房容災建設，以下為具體的架構設計：

在主集群安裝 Replicator 插件，該插件可以攔截并解析主集群執行的全量 SQL，經過濾操作，可篩選涉及庫、表結構變更和數據增、刪、改相關的 SQL，并將相關 SQL（部分 SQL 需改寫）發送到從集群進行回放。

更進一步的，為了應對主集群可能遭遇意外情況，奇富科技設計了一套靈活的 DNS 解析地址切換機制。當主集群不可用時，切換 DNS 解析地址到從集群，完成主從集群的切換。

除此之外，我們還在 Doris 控制臺（內部自研的 Doris 集群維護管理服務）開發了 Validator 數據校驗模塊，可定時對 Doris 數據表主從集群一致性情況進行校驗并上報，包括元信息、行數等。

應用收益

以表同步耗時為例，利用 Doris Broker Load 方式有效降低數據導入的復雜度，提高數據導入時效性，成功將報表數據同步時效 SLA 達標率提升至 99% 以上。

以查詢時效為例，下圖為引入 Apache Doris 后報表分析集群的查詢時效監控，平均耗時穩定在 10s 以內、P90 查詢耗時穩定在 30 秒以內 ，相比舊架構平均耗時降低了 50% 以上。隨著應用程度的加深和數據規模的增長，查詢性能還得以進一步提升，獲得更多內部業務線的認可。

Apache Doris 在離線標簽服務場景的應用

在標簽服務場景中，數據分析師會根據用戶的多重維度信息，基于一定策略進行用戶標簽的打標，標簽主要包括行為標簽和屬性標簽。離線標簽服務則以上述標簽為基礎，為下方四個場景提供服務：

• 用戶標簽點查服務：在風控流程中，特征平臺將查詢用戶的標簽信息，并基于標簽信息構建用戶特征變量。
• 客群畫像服務：基于用戶標簽信息進行客戶畫像描繪，為電銷、營銷等部門制定業務策略提供數據支撐。
• 觸發式策略生成服務：電銷部門基于用戶標簽信息，通過觸發式策略生成人群包，并對篩選出的客戶群進行外呼。
• 人群圈選服務：營銷部門基于用戶的標簽信息，對生成的人群包進行個性化廣告投放。

由于離線標簽服務需同時滿足四個場景的需求，因此對數據導入時效性和可用性有較高要求，以確保服務持續穩定運行。同時，需要保證用戶標簽查詢的點查性能，支持實時查詢標簽信息。在人群圈選方面，還需具備精準去重和集合交并集運算能力，保證營銷活動和廣告投放的精準性和有效性。

在原先的架構中（如上左圖所示），導入的數據會逐步生成標簽信息，并對標簽信息進行加工、合并為 JSON 文件（合并操作是為了減少 Elasticsearch 的更新次數及負載），合并后的 JSON 文件導入到 Elasticsearch 中提供數據服務。然而，這種方式帶來兩個問題：

• 舊標簽服務過度依賴于合并操作，如果某個標簽服務的數據出現問題，那么整個標簽的合并操作就無法完成，進而影響標簽服務的正常運行。
• 數據合并操作基于 Spark 和 MapReduce 進行，處理時效可能超過四個小時甚至更長，這樣長時間的處理耗時會導致場景服務錯過黃金營銷時間，造成業務營收的損失。

為解決上述問題，我們基于 Apache Doris 對架構進行了改造，如上圖右圖所示，在標簽數據加工過程中，利用 Apache Doris 進行標簽寬表的存儲和處理，當上游標簽準備就緒時，可使用 Aggregate Key + replace_if_not_null 實現標簽合并和部分列更新的效果。當所有標簽均更新到標簽寬表后，繼續將其同步到 Duplicate Key 模型的標簽明細寬表中，以提升查詢性能。

這樣的改造使得我們能更加及時地處理標簽數據，標簽數據的導入時效從 4 小時縮短至 1 小時以內。此外，借助 Doris 完善的 Bitmap 索引以及高并發查詢性能，實現了秒級人群圈選。在點查詢方面，QPS 達到 700+，確保了查詢的快速響應。

基于 Apache Doris 的湖倉查詢加速實踐

為縮短業務決策周期、提升數據分析師的工作效率，對于離線湖倉查詢加速的重要性日益凸顯。因此自 22 年 9 月起，我們開始將 Apache Doris 應用在離線查詢加速場景中，彼時 Doris 僅支持以 Hive 外部表的形式進行查詢，由于外部表需要配置映射關系，當 Hive 元數據發生變更時需要手動更新，人工維護成本較高，因此選擇將 Hive 中數據導入進 Doris 中以實現查詢加速。

具體而言，會先根據查詢頻率對數據表優先級進行排序，通過 Doris Broker Load 將查詢頻率 Top 500 的數據表從 Hive 導入到 Doris。通過路由引擎定時調度收集數據表在 Doris 和 Hve 中表的元信息，包括表的字段、字類型以及數據規模。當收到查詢語句時，路由器檢測數據的是否在 Doris 中，如存在則會路由到 Doris 引擎，從而實現查詢加速。

而該方案并不完美，依賴于對于 Hive 數據的導入。當面對大規模數據導入任務時，可能造成集群資源緊張導致查詢和導入性能下降的問題，甚至可能引起集群不穩定，對業務使用產生負面影響。

為解決上述問題，我們對架構進行了進一步升級。在 Apache Doris 1.2 版本支持了 Multi-Catalog 多源數據目錄，基于該能力簡單配置即可將 Hive 集群的數據表完整同步到 Doris 中，解決了配置外表繁瑣、元信息無法自動同步等問題。以下是數倉查詢加速新方案：

在新方案中，主要通過以下幾個步驟完成數倉查詢加速方案：

• 基于 Doris Multi-Catalog 能力，將 Doris 引擎加入到查詢引擎路由策略中（Internal Catalog 和 Hive Catalog）；
• 引入彈性計算節點并落地 Deploy on Yarn 方案，簡化部署流程以支持灰度期間快速升級迭代、快速擴縮容支持；
• 查詢引擎實現自動路由，引擎選擇對用戶透明。

當用戶提交查詢語句后，路由引擎（即查詢網關）會根據收集的數據元信息進行判斷，為查詢語句匹配最優查詢路徑。路由引擎還會分析查詢涉及的分區數和表行數，來匹配最佳執行引擎（ Doris 、Presto、SparkSQL ），例如當查詢語句所依賴數據表都存在于 Doris 內表中且元數據一致時，將直接路由至 Doris 內表進行查詢，無法命中則將查詢下壓，由 Doris Hive Catalog 進行查詢或者通過 Presto 進行查詢。

通過這種策略，用戶無需關心查詢由哪個引擎執行，也無需關注查詢引擎間的語法差異。查詢總能以最高效的方式執行，實現查詢加速，并能保障結果的準確性。使用上述方案也遭遇了一些問題，接下來分享應對策略及優化方案。

Hive 元數據準實時同步

使用上述查詢加速方案時，如果 Hive 元信息更新后無法準實時同步至 Doris ，用戶查詢時會出現結果不一致問題。為避免該問題發生，可使用 Doris 元數據自動刷新特性（基于 HMS Event Listener 實現）實現元信息準實時同步。這種方式需要在 Hive 端開啟 HMS Event Listener ，并在 Doris 端開啟 HMS Event 消費開關。具體實現如下圖所示：

對于 Hive 端，當開啟 Listener 后，因 Hive 本身具有內置的 Listener 實現，會對 Hive 集群中 DDL 操作以及 Insert 操作進行攔截。在發起攔截操作后，生成對應的 HMS Event（事件），并寫入 Hive 元信息數據庫中。

對于 Doris 端，當開啟消費 HMS Event 開關后，Doris 的 Master FE 節點會啟動后臺線程，調度式批量拉取 HMS Event，通過消費 HMS Event 獲取 Hive 端的元數據變化，并將該變化同步到 Doris 內部維護的 Hive 元信息中，實現數據的準實時同步。在實施過程中也遇到了一些新的問題，在此對優化方案進行分享：

優化方案 1：Hive DDL 長時間阻塞：

啟動 Hive 端的 HMS Event Listener 后，Hive 處理新增表和分區時需要獲取表、分區名和文件信息，生成相應的 HMS Event，而 Doris 回放 HMS Event 時并不需要文件信息。因此當 Hive 表、分區文件數過多或集群繁忙時，獲取文件信息的操作會延長 HMS Event 生成時間，導致 Hive DDL 操作耗時增加。

基于此，我們重寫了 Hive DbNotification Listener，屏蔽對 Hive 表、表分區文件信息收集，有效減少不必要信息的拉取與采集，縮短了 Hive 端的執行效率。

優化方案 2：消費速率與事件產生速率不匹配：

Hive 集群繁忙時，DDL 或 Insert 事件頻率高，且 Doris 采用單線程串行模式消費 HMS Event，可能會出現 Doris 消費速率與Hive 時間產生速率不匹配的問題。

為了提高 Doris 消費速度，我們在 Doris 端增加了預先事件合并（HMS Event Merge）步驟，過濾掉一部分 HMS Event，大幅降低了需要消費的 HMS Even 數量。預先事件合并的核心思想是判斷批量 HMS Event 中是否存在可以抵消前面某個 HMS Event 產生的效果，如果是則跳過前面的 HMS Event。通過這樣的方式，HMS Event 數量能夠大幅度降低，進而提升了 Doris 處理 HMS Event 的消費速度。

預先事件合并原理如上圖所示，第一個事件 DropPartitionEvent（db1.tbl1）和最后一個事件 DropTableEvent（db1.tbl1）針對同一張 Hive 表。DropPartitionEvent 發生在前，DropTableEvent 發生在后。在處理 DropPartitionEvent 時，Doris 會刪除該 Hive 表的應分區緩存信息；在處理 DropTableEvent 時，Doris 會刪除該 Hive 表的表緩存信息。由于后一個 HMS Event 產生的效果可以完全抵消前一個 HMS Event 產生的效果，因此可以跳過前面的 HMS Event。

我們對集群 4 天內所處理 HMS Event 處理情況進行抽取，從上圖可知，經 HMS Event Merge 操作后，Doris 消費事件數量時顯著降低，較原來減少約 2-5 倍的數量。完成優化后，再未出現消費速率低于產生速率的問題。

優化方案 3：HMS Event 類型缺失，影響 FE 穩定性

針對 CDH 或者 HDP 集群 Hive 版本產生壓縮格式的 Event ，新增了 GzipJSONMessageDeserializer 反序列化器進行處理。原因是 Slave FE 節點一般通過 Journal Log 方式消費 HMS Event ，如果消費失敗會導致 FE 服務直接退出，通過新增 Fallback 策略可以提升消費邏輯的健壯性，盡量避免 FE 服務退出的問題。

引入彈性計算節點，Deploy on Yarn 實現彈性擴縮容

當需要處理大規模數據或進行高性能計算時，需要更多計算資源提供支持。若部署的 Doris BE 集群時有上百個節點，每一個節點需要多個 CPU，那么在運行過程中需要龐大的資源支撐，從而帶來較大的資源成本和部署成本。為降低資源和部署成本，我們選擇引入 Doris 的彈性計算節點（Elastic Compute Node），并選擇將彈性計算節點與 Hadoop 集群的其他組件（如 DataNode 節點）混合部署，能夠更好地管理和優化計算資源。

在此基礎上，基于 Doris 計算節點的無狀態特性，可通過 Skein 進一步簡化 Doris 計算節點 Deploy on Yarn 的部署流程，實現節點彈性擴縮容。在實際運行過程中，我們依據用戶的查詢習慣，在夜間查詢較少時縮容、在白天業務高峰時擴容，最大化利用集群資源、提高資源利用率。

如上圖，在 Yaml 文件中定義 Doris 計算節點的數量和所需資源信息，并將安裝包、配置文件、啟動腳本統一打包至分布式文件系統。當需進行版本升級或集群啟停時，只需一行命令即可在分鐘內完成整個集群上百個計算節點的啟停操作。

Hive 視圖查詢優化

在 Hive Catalog 查詢運行過程中會有偶發的查詢失敗問題，因此我們對數百業務用戶查詢失敗的原因進行了深度分析，發現 28% 是由查詢視圖引起，24% 是由于用戶使用了 Doris 無法匹配的函數導致。

如下圖所示，當用戶發送查詢請求后，在 Doris 內部將經歷詞法分析、語法分析、邏輯執行計劃和分布式執行計劃四個階段。Hive 視圖識別在第三階段進行，即當邏輯執行計劃階段生成 Hive ScanNode 后，對其進行初始化時，Doris 會識別該表是否為 Hive 視圖。如果是 Hive 視圖，將直接拋出查詢異常導致查詢失敗。

因此我們對 Hive 查詢執行進行了優化，將 Hive 視圖的識別提前至語法分析階段（第二階段）進行，如果識別為 Hive 視圖，則通過 HMS Client 客戶端獲取該視圖定義的 DDL ，并將 DDL 帶入 Doris 解析視圖依賴的 Hive 實體表。在邏輯執行計劃生成階段（第三階段），將生成與 Hive 實體表相對應的 HiveScanNode，查詢將繼續進行。通過簡單改造，Doris 即可通過 Hive Catalog 實現對 Hive 視圖的查詢支持。

應用收益

查詢加速主要得益于 Apache Doris 的 Multi-Catalog 特性，相對于外部表，Multi-Catalog 無需創建表與表之間的映射關系，可以實現元數據層的對接，如上文所述只需簡單的配置，實現將整個 Hive 集群的數據表完整地同步到 Doris 中，徹底解決了以往配置外表繁瑣、不支持元信息自動同步等問題。

此外，借助 Doris Multi-Catalog 替代了早期架構中多個數據組件，統一了數據源入口和數據查詢出口，降低架構的復雜度、縮短數據處理與查詢的流程，大大提高數據查詢的效率。

結束語

從 22 年引入 Doris 以來，憑借其優異的性能、較低的運維復雜度和較高穩定性，迅速在奇富科技內部多個業務場景得到大規模的應用。截止目前，生產環境共有近十套集群、上百 BE 節點、CPU Core 超過 1000+，總數據規模達到數十 TB ，每日有數百個同步工作流在運行，日新增數據或更新的規模達近百億，每天支持業務方百萬次的有效查詢量。通過 Doris 的應用極大的降低了架構的復雜度，有效提高了數據處理與分析的速度，降低了運維成本，確保了系統的穩定性。

未來我們將繼續深入使用 Apache Doris 、并引入 2.0 版本，為用戶帶來更加實時、統一的數據處理和分析體驗。后續我們將重點關注存算分離架構、數據湖分析特性以及 Doris Manager 組件的應用。

• 存算分離架構：通過存算分離架構實現集群融合，消除不同集群間 Doris 版本的差異，提供更加靈活的負載隔離策略和彈性部署支持，為用戶帶來更加穩定、可靠的數據處理環境，滿足不同業務需求。
• 數據湖分析特性：持續深入使用，通過統一查詢引擎簡化內外表數據流通過程，降低數據處理的復雜性。
• Doris Manager 組件：為了讓用戶更加輕松的進行數據庫的運維和管理，飛輪科技開發了一站式數據庫集群管理工具 Cluster Manager for Apache Doris（簡稱 Doris Manager）。該工具提供輕松部署和接管 Doris 集群的功能，支持物理機和虛擬機環境。借助直觀的界面，為用戶提供了簡單易用的可視化運維體驗。同時用戶還可以快捷的對節點進行擴縮容和重啟，設置監控告警等操作。這將極大地提升運維效率，減少錯誤和中斷，提高服務質量和穩定性。