**導讀：** 近年來，馬上消費的業務體量呈飛躍式增長，每天產生資料可達上千億條，如何更高效挖掘這些資料的價值，成為了其必須要面臨的挑戰。隨著各業務對實時資料分析的需求越來越強烈，馬上消費於 2021 年引入 [Apache Doris](https://github.com/apache/doris) 構建實時數倉，目前已服務 10+業務團隊的資料應用，99% 以上的查詢響應耗時在 5 秒內，資料時效延遲均不超過 1 分鐘，解決了其對於實時資料分析的強烈訴求，最終效果得到各業務部門的認可與肯定。

作者｜大資料架構師 陳政

馬上消費金融股份有限公司（簡稱“馬上消費”）是一家經中國銀保監會批准，持有消費金融牌照的科技驅動型金融機構。秉承“科技讓生活更輕鬆”的使命，馬上消費以使用者為中心，聚焦普惠金融，透過科技賦能創新，致力於打造成為全球最被信賴的金融服務商，為有金融服務需求的社會各階層和群體提供小額分散的消費金融服務。

自2015年6月正式開業至今，馬上消費的業務體量呈飛躍式增長，截止目前品註冊使用者數達到一億多。作為一家面向 C 端使用者的網際網路金融企業，我們不斷在探索資料提升客戶體驗、資料驅動業務增長的方式，關注資料要素升級對生產關係所帶來的深遠影響。

# 業務需求

基於業務需要，馬上消費內部自主研發了 400 多套與零售信貸相關的系統，同時與外部合作方多套系統進行對接，來服務整個業務鏈路的流轉。這些系統源源不斷的產生資料，每天可達上千億條。如何更高效挖掘這些資料的價值，成為了我們必須要面臨的挑戰。

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6914baa686a945e49f59de6202cbb07e~tplv-k3u1fbpfcp-zoom-1.image)

在正式建設實時數倉之前，業務上的資料應用以離線為主，使用者使用 T+1 的資料來做資料建模和分析，依託資料進行業務決策，並回流到業務系統中。但隨著業務體量的飛躍式增長、以及業務模式的不斷最佳化升級，我們對資料分析的實時性提出了更高訴求，主要包括兩類：

-   **資料時效的實時**。相比過去 T+1 的模式，希望在分析時的資料包含近 10 分鐘以前的新增內容。
-   **查詢響應的實時。** 資料的查詢響應要足夠快，最好能在幾秒鐘甚至毫米級返回結果。

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/53fb8b6eb89147f8bd251ef93da31690~tplv-k3u1fbpfcp-zoom-1.image)

# 早期架構

早期公司內統一的大資料平臺，構建在傳統的 Hadoop 體系之上，以服務離線資料分析為主，缺乏統一的實時資料平臺。每天晚上集中抽取業務資料到 Hive 表中，透過離線排程任務完成資料加工後，提供給使用者做資料查詢和分析。

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4dc5dc86bfb6476aaf581394637f6e65~tplv-k3u1fbpfcp-zoom-1.image)

## **Hadoop 離線架構的不足**

這套技術架構對離線資料業務有較好的支撐，但在應對更廣泛的實時分析場景時，痛點也很明顯：

-   **資料的時效性不足**。平臺中的 Hive 表，都是 T+1 的資料，沒有當日最新資料。使用者若想在平臺上分析當日最新業務情況，簡直是無米之炊，業務決策的準確性和及時性很難得到提升。
-   **資料查詢效率不足**。使用者查詢 Hive 表的資料時，通常需要等待數十秒甚至數分鐘才能返回結果，工作效率受限。雖然也引入了 Presto、Spark 等計算引擎來提升查詢效率，但查詢效率的提升始終不理想，並且資源消耗也比較大。
-   **資料維護成本高**。離線資料從採集到加工，鏈路複雜耗時長，任何一個環節出問題都將影響資料的及時產出。另外，當需要修復歷史資料、或者是調整資料計算邏輯時牽涉面廣，更是費時費力。除此之外，常規的離線數倉分層模型也帶來一些問題，所有資料都是單獨一份物理表，導致衍生出來的表數量龐大、儲存消耗不低。
-   **技術成本較高**。圍繞 Hadoop 體系構建的平臺，元件依賴較高，動輒需要數十種基礎元件組合起來，才能滿足不同功能需要。每一種元件複雜度都很高，各自難免存在一些缺陷，需投入大量的人力物力去維護。

# 探索之路

在公司沒有統一建設實時數倉之前，部分業務團隊為了滿足實時資料分析的需要，也曾各自做過一些努力，但受限於實施的複雜度，基本都只侷限在極少數特殊業務。

-   有的團隊採用過相對粗暴的解決方式，直接在業務系統 MySQL 上面查詢最新的資料，雖然查詢速度慢但可以保證是實時資料，但對於跨資料庫例項的關聯分析，使用這種方式很難解決；
-   有的團隊採用過相對進階的方式，將資料實時同步到 Elasticsearch、HBase 中，在其中完成簡單的資料分析；
-   有的團隊也採用過較前沿的方式，使用 Flink 之類的流式計算框架，對流式資料進行預計算之後寫入 HBase、ES 等儲存，供使用者和系統訪問。

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f732990169f64634b3f300008a630f9b~tplv-k3u1fbpfcp-zoom-1.image)

**以上各業務團隊對實時資料分析的分散式初步探索中，也發現了一些問題：**

-   **對分析的支援很不靈活**。MySQL、ES、HBase 等儲存元件，各自擅長的領域不同，對大規模資料的 OLAP 查詢並不友好。使用者要麼只能用於簡單的單表資料分析場景，要麼需要設計很複雜的資料模型和資料處理邏輯來實現複雜的分析需求，這使得研發和維護成本非常高，需求交付時間很長。
-   **重複建設帶來資源浪費**。各業務團隊採用零散的方案去解決需求，各自搭建 ES、HBase 小規模叢集，資源利用率低，並投入技術學習成本，最終卻很難共享複用。另外，不同團隊的業務分析中都會用到賬務、審批等核心資料，最終造成資料的重複拉取和儲存。
-   **資料服務質量難以保障**。資料透過不同的鏈路、不同的寫入方式到達目標端供查詢，服務鏈路的穩定性難以保障，導致資料的準確性、完整性、一致性等質量問題頻發，各團隊花費了大量精力也難以很好地保障整體資料服務質量。

## 架構選型

從我們當前大資料整體架構來看，實質上只需對原有架構做一些擴充和改造即可實現當前的需求。我們已有的平臺產品，比如流式計算平臺、資料交換平臺等，已經足夠支撐實時資料的採集和處理，這也為我們構建實時數倉奠定了良好基礎。因此，**我們當前較為迫切的是需要補充一款綜合能力強勁的分析型資料庫來解決問題。**

對於這類分析型資料庫，我們有一些**基本訴求**：

-   支援分鐘級別延遲的資料近實時寫入（insert）、更新（update）、刪除（delete）；
-   支援標準 SQL 語法來查詢和分析資料，以及常用的函式；
-   千萬級別資料量的多表關聯查詢，能夠在秒級別返回結果；
-   儲存容量和併發支援能夠橫向擴充套件；
-   既能較好支援 OLAP 查詢，也能根據主鍵查詢資料毫秒級響應；
-   具備一定的資料聚合模型或物化檢視的能力，加速查詢；

圍繞以上基本訴求以及業務需求，我們對業界主流的商業和開源元件進行了調研，包括 Clickhouse、Doris、TiDB、Druid、Kudu、Kylin、Hologres 等產品。我們做調研的時間截止在 2020 年底，在這個時期內主流 OLAP 引擎或資料庫都有其各自的優勢與短板。**我們對調研產品的功能特性和原理方面進行了分析對比，也對部分元件做了效能等方面的 POC 測試，最終決定引入 Apache Doris 作為我們實時數倉的基座。**

我們對新技術的引入一直比較審慎，**Apache Doris 以其全面的功能和極速的效能表現吸引了我們**。自 2017年開源之後被小米、美團、鏈家、搜狐等數十家網際網路知名企業引入使用。在 2018 年捐獻到 Apache 基金會之後更是一路高歌猛進，各項核心能力大幅增強，並在 2022 年 6 月升級為 Apache 頂級專案，截止 2022 年底，Apache Doris 已被全球 1000 多家企業生產系統使用。它的幾大重點能力對我們而言非常適用：

-   **簡單易用**：其架構簡潔只有兩個程式服務，不依賴其他系統，部署和運維管理簡單；使用標準 SQL 做資料查詢，相容 MySQL 協議;
-   **極致效能**：依託現代化的 MPP 架構、列式儲存、預聚合檢視、資料索引等實現，在低延遲和高吞吐查詢上達到了極速效能；
-   **統一數倉服務**：一套平臺系統，可同時支援實時資料服務、互動式資料分析等場景；
-   **支援聯邦查詢**：支援對 Hive、MySQL、Elasticsearch 等資料庫的聯邦查詢分析能力；

# 新架構演進

## 技術架構升級

各業務對實時資料分析的需求越來越強烈，但原有技術架構並不能很好的支撐當前的需求。在分析各業務的需求和痛點之後，我們決定對架構進行升級演進，構建公司級統一的實時數倉平臺。

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a9b7014e09e84b47b3ecb218c65d83d4~tplv-k3u1fbpfcp-zoom-1.image)

在選定 Apache doris 作為我們的實時數倉底座之後，我們規劃並構建了統一的實時資料服務鏈路。一方面我們以 Apache Doris 為核心，將實時增量資料、歷史存量資料整合到 Doris 內提供極速查詢服務；另外我們對資料交換平臺、流式計算平臺、訊息服務匯流排、後設資料中心、資料服務平臺等都做了適配改造；最終達到實時資料統一採集、統一分析、統一服務的目標。

同時對於整個大資料平臺而言，我們也在離線資料平臺之外擴充了實時資料服務能力，進一步增強了大資料平臺對不同業務場景的支撐能力，完善了大資料技術架構藍圖：

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4b3c955d804e4d41a617c4b0636f5e6a~tplv-k3u1fbpfcp-zoom-1.image)

## 架構升級的落地

我們對實時數倉的建設目標絕不僅僅是部署一套 Doris 資料庫，當然也不是一朝一夕可建設成熟，只有諸多與之配套的能力逐步完善後，才能真正高效保質的運轉起來。只不過，Doris 在我們實時數倉的建設中至關重要。

**圍繞新的實時資料架構，我們做了大量的配套工作：**

-   **實時資料的採集交換。** 將實時資料採集到 Doris 中去。我們在現有資料交換平臺上擴充套件功能，支援 MySQL Binlog 實時資料的採集和分發，並能在源頭上對分庫分表資料進行合併，以便下游處理。同時新增 Hive 到 Doris 的資料批次匯入功能，解決大量歷史資料需要載入到 Doris 庫表的問題。
-   **實時訊息服務匯流排。** 不管是採集自 MySQL 的 Binlog 資料，還是應用埋點上報的資料等，均制定統一的資料格式，同時提供標準 SDK 來保障資料的規範性。另外對於訊息資料，我們增加了訊息後設資料中心服務，來方便上下游對資料 Schema 的解析與演變。源端的實時資料，由專人負責接入到統一的 Kafka 中，共享給下游各類業務使用，避免資料被重複接入。
-   **擴充套件流式資料的處** **理**。我們的流式計算平臺底層基於 Flink，為方便使用者解析統一的訊息資料，我們擴充套件了Flink SQL 函式以及 Kafka Connector。由於當時社群並未提供 Flink 跟 Doris 的讀寫聯結器，我們自研了 Flink Doris Connector，並保障資料寫入的 Exactly Once語義，效能上也壓測到單表最大 **20 萬 QPS** 的吞吐。
-   **增強 Doris 的服務能力**。我們部署多個 FE 節點提供服務，面向訪問端我們基於 Nginx 反向代理來實現不同 FE 節點之間的負載均衡、故障轉移。擴充套件 Bitmap、字串解析等函式，方便使用者分析資料。Doris 各節點上的日誌，統一整合到 ELK 供查詢，以及將效能指標整合到 Grafana 實現監控告警。期間偶爾觸發到 Doris 的缺陷也對其進行修復（或透過升級 Doris 版本的方式解決），比如資料寫入過於頻繁時，個別表 Tablet 與 Partition 中的版本元資訊不一致導致查詢異常，以及 FE 節點 HTTP 介面的相容性 Bug 導致啟動時拉取後設資料失敗等等。
-   **完善實時資料研發規範。** 在 Doris 之上的資料模型設計、資料開發方式，相比常規的離線數倉都有較大區別。我們對於資料採集、資料表模型選擇、資料域劃分、分割槽分桶策略、資料生命週期、資料許可權分配、各資料團隊分工等方面都制定了規範，一方面期望實時數倉的資料從一開始就能夠有序組織和管理，同時也羅列一些技術規範讓開發者有據可循，達到效能最優，少走彎路。

# 業務實踐

自 2021 年引入 Apache doris 之後，我們小步快跑，快速在一些業務場景中得到實踐，初具效果。目前我們線上 Doris 叢集有 **50** **個** BE 節點，已接入將近 **800** **個**資料表，支撐每天約 **5 萬餘次**的查詢分析；服務於 **10 多個業務團隊**的資料應用，在其之上產出的資料包表、資料介面大約在 **300 個**左右；**99% 以上的查詢響應耗時在 5 秒內，資料時效延遲均不超過 1 分鐘。**

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b10136081a6a48a4ade348ff302fd39f~tplv-k3u1fbpfcp-zoom-1.image)

一些重點業務在對接實時數倉之後，均取得了不錯的效果，比如幾個典型的業務場景：

-   廣告投放：營銷團隊觀察不同廣告投放渠道、素材等維度的曝光、花費及使用者轉化情況，及時調整資金投放策略；
-   風控策略評估：風控團隊基於實時提現透過率等審批指標，判斷審批策略效果，及時最佳化策略保障審批質量；
-   消保降訴：運營團隊基於話務、客戶關係相關實時資料指標，分析電銷運營質量及關鍵事件，保障客戶服務質量；
-   資管業務：資管團隊基於現場過程實時資料、實時質檢合規敏感詞、實時催收投訴提供資管質檢實時業務監控分析服務；
-   科技大屏：各大部門基於大屏實時展示和監控業務及技術指標，例如風控大屏、資管大屏、人工智慧大屏等；

雖然各個業務場景關注的資料指標不同，資料處理邏輯不同，但圍繞 Doris 的資料開發模式基本一致。我們透過自研的工具將不同來源的資料實時投遞到 Kafka，使用者使用 Flink SQL 消費 Kafka 資料後寫入 Doris，在 Doris 中按照經典的數倉分層模型來組織資料。Doris 作為我們資料鏈路的末端，被報表工具、業務系統直接訪問，快速查詢資料。

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/89b891730d584b93addb64c5f5a5e173~tplv-k3u1fbpfcp-zoom-1.image)

在我們圍繞 Doris 的實時業務實踐過程中，也探索了一些不一樣的實時資料開發模式：

-   **資料不直接同步到 Doris**。我們並沒有選擇將源頭實時資料直接同步到 Doris，而是先把所有資料都集中傳送到了 Kafka，啟動一些 Flink 任務消費資料寫入 Doris。這樣做主要有兩方面的考慮，一是 Kafka 中的資料可被重複利用，除了消費資料寫入 Doris，其他特殊業務也可消費後流轉到其他流程中，避免實時資料重複採集；二是資料在寫入 Doris 之前，我們的 Flink 任務可預先做一些資料清洗或者聚合，儘量減少在 Doris 中再次處理。
-   **上層儘量使用檢視表。** 我們對公司的核心資料做了主題分類，遵循維度建模的思想把資料也分為了ODS、DWD、DWS、ADS 等層次，每一層的資料的聚合維度不同。區別於離線數倉的資料加工模式，我們圍繞 Doris 的實時加工方式有較大不同：我們基本只有 ODS、DWD 層的資料是物理表，DWS、ADS 層中的資料主要為檢視表。這樣做的初衷也很簡單，就是想減少傳統方式的層層資料預處理，最大化利用 Doris 的極速分析能力直接從明細表中分析資料。**這樣做有幾個大的收益**，一是物理表數量少了，降低了儲存開銷；二是減少了大量的資料預處理計算任務，資源消耗低、維護成本低、業務交付速度快；三是上層資料基於檢視表，當業務規則變化時，快速重建檢視邏輯即可，無需把層層資料再重新處理一遍，簡單高效。
-   **計算邏輯儘量交給 Doris**。在沒有 Doris 之前，比如 Flink 結合 HBase 的架構，我們通常會在 Flink 任務端做大量的資料預處理（包括複雜的流表關聯、維度聚合、視窗計算）。而在引入 Doris 之後，我們將資料計算邏輯儘可能的轉移到 Doris 內，Flink 只承擔簡單的資料讀寫與轉換。這對資料開發者來說無疑會更友好，畢竟對於普通開發者來說 Flink 的門檻較高，比如對延遲資料的處理、歷史資料回溯等方面很難控制。當然，我們會對資料的體量和分析複雜度做綜合考慮，在必要時仍會在 Flink 端對資料先做聚合，靈活調整。
-   **合理利用 Doris 特性**。我們期望基於 Doris 自身的極致查詢效能，來降低資料加工鏈路的複雜度，提高需求交付效率。但任何資料庫或計算引擎的效能，都受其自身設計、叢集規模、資料規模、計算複雜度的綜合影響，Doris 效能雖然很優越但也不是萬能。我們儘量合理使用 Doris，來讓他的效能表現更好，比如合理設計表的分割槽分桶、設定資料清理週期、主鍵欄位的型別等；ODS 和 DWD 層的資料優先使用 Unique 模型，部分大表配套建立 Rollup 表；查詢語句的 Join 關聯注意大表在左小表在右，合理使用 Runtime Filter 等。

# 總結與展望

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9bc1d17ce072428d879cc7ed3ffcd9e8~tplv-k3u1fbpfcp-zoom-1.image)

自 2021 年引入 Doris 構建實時數倉以來，很多以前只能使用頭一天資料做離線分析的業務，紛紛嘗試以新的方式來完成實時資料分析、製作實時資料包表。**在新的實時資料架構下，資料分析的時效性有了極大的提升，不同型別使用者均從中獲得收益：**

-   對於業務人員、資料分析師、決策者，他們能夠基於最新的資料，更快速的洞察業務狀態，及時調整業務策略；
-   對於資料開發者，實時資料的開發變得更簡單，以前需要花費好幾天才能完成的工作，現在只需一天甚至半天時間即可完成；
-   對於實時平臺管理方，資料的儲存成本、系統的運維成本、業務的運營成本均得到一定程度的降低。

技術和資料服務業務的腳步永不停歇，當業務與資料規模持續變化後，新的技術挑戰必然又會產生。**在當前環境下，不管是解決現有問題、還是為將來做準備，我們還有很多工作需不斷深入：**

-   Doris 能力的增強。由於引入 Doris 較早，我們升級幾次之後停留在 0.15.3 版本，對比社群 1.1.4 版本和即將發版的 1.2  版本差距太大。新版本在效能和穩定性上都有了巨大的提升，比如向量化引擎等、Hudi 資料查詢等，版本升級是我們近期首要的計劃。另外 Doris 即將釋出的版本將支援跨叢集資料複製、存算分離的能力，我們的核心業務對這些需求也非常強烈，後續我們將聯合社群一同完善，推進落地應用。
-   生態系統的完善。Doris 成為了我們實時數倉的主力資料庫，但同屬於我們大資料生態的一部分，資料安全、資料質量等要素也是需要被共同關注的內容。原有後設資料管理、資料質量、資料安全、運維監控等平臺側重對離線 Hadoop 體系資料的管理，需進一步擴充套件，支援將 Doris 鏈路的實時數倉納入統管。另外尤其是面向資料開發者、資料分析使用者，最佳化資料開發流程和工具，讓大家獲得更好的體驗。
-   更多業務的覆蓋。一方面源自於業務側旺盛的需求量，另一方面我們也期待基於 Doris 的實時數倉體系能夠發揮更大的作用，在資料的接入數量和資料模型上，能夠支撐到更多的業務域。在服務的應用型別上，除了傳統的報表應用，也能支撐更多偏中後端的資料產品，比如使用者行為分析平臺等。

實時分析全面賦能金融業務，馬上消費基於 Apache Doris 構建實時數倉的實踐

相關文章