**導讀：** 鬥魚是一家彈幕式直播分享網站，為使用者提供影片直播和賽事直播服務。隨著鬥魚直播、影片等業務的高速發展，使用者增長和營收兩大主營業務線對精細化運營的需求越發地迫切，各個細分業務場景對使用者的差異化分析訴求也越發的強烈。為更好滿足業務需求，鬥魚在 2022 年引入了 [Apache Doris](http://doris.apache.org) 構建了一套比較相對完整的實時數倉架構，並在該基礎上成功構建了標籤平臺以及多維分析平臺，在此期間積累了一些建設及實踐經驗透過本文分享給大家。

作者**｜**鬥魚資 深大資料工程師、OLAP 平臺負責人 韓同陽

鬥魚是一家彈幕式直播分享網站，為使用者提供影片直播和賽事直播服務。鬥魚以遊戲直播為主，也涵蓋了娛樂、綜藝、體育、戶外等多種直播內容。隨著鬥魚直播、影片等業務的高速發展，使用者增長和營收兩大主營業務線對精細化運營的需求越發地迫切，各個細分業務場景對使用者的差異化分析訴求也越發的強烈，例如增長業務線需要在各個活動（賽事、專題、拉新、招募等）中針對不同人群進行差異化投放，營收業務線需要根據差異化投放的效果及時調整投放策略。

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

根據業務場景的訴求和精細化運營的要求，我們從金字塔自下而上來看，需求大致可以分為以下幾點：

-   分析需求更加複雜、精細化，不再滿足簡單的聚合分析；資料時效性要求更高，不滿足於 T+1 的分析效率，期望實現近實時、實時的分析效率。
-   業務場景多，細分業務場景既存在獨立性、又存在交叉性，例如：針對某款遊戲進行專題活動投放（主播、使用者），進行人群圈選、AB 實驗等，需要標籤/使用者畫像平臺支援。
-   多維資料分析的訴求強烈，需要精細化運營的資料產品支援。

**為更好解決上述需求，我們的初步目標是：**

-   構建離線/實時數倉，鬥魚的離線數倉體系已成熟，希望此基礎上構建一套實時數倉體系；
-   基於離線/實時數倉構建通用的標籤中臺（使用者畫像平臺），為業務場景提供人群圈選、AB實驗等服務；
-   在標籤平臺的基礎上構建適用於特定業務場景的多維分析和精細化運營的資料產品。

在目標驅動下，鬥魚在原有架構的基礎上進行升級改造、**引入 [Apache Doris](https://github.com/apache/doris) 構建了實時數倉體系，並在該基礎上成功構建了標籤平臺以及多維分析平臺**，在此期間積累了一些建設及實踐經驗透過本文分享給大家。

# 原有實時數倉架構

鬥魚從 2018 年開始探索實時數倉的建設，並嘗試在某些垂直業務領域應用，但受制於人力的配置及流計算元件發展的成熟度，直到 2020 年第一版實時資料架構才構建完成，架構圖如下圖所示：

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

原有實時數倉架構是一個典型的 Lambda 架構，上方鏈路為離線數倉架構，下方鏈路為實時資料倉架構。鑑於當時離線數倉體系已經非常成熟，使用 Lambda 架構足夠支撐實時分析需求，但隨著業務的高速發展和資料需求的不斷提升，**原有架構凸顯出幾個問題**：

-   在實際的流式作業開發中，缺乏對實時資料來源的管理，在極端情況下接近於煙囪式接入實時資料流，無法關注資料是否有重複接入，也無法辨別資料是否可以複用。
-   離線、實時數倉完全割裂，實時數倉沒有進行數倉分層，無法像離線數倉按層複用，只能面向業務定製化開發。
-   資料倉儲資料服務於業務平臺需要多次中轉，且涉及到多個技術元件，ToB 應用亟需引入 OLAP 引擎緩解壓力。
-   計算引擎和儲存引擎涉及技術棧多，學習成本和運維難度也很大，無法進行合理有效管理。

# 新實時數倉架構

### **技術選型**

帶著以上的問題，我們希望引入一款成熟的、在業內有大規模落地經驗的 OLAP 引擎來幫助我們解決原有架構的痛點。我們希望該 OLAP 引擎不僅要具備傳統 OLAP 的優勢（即 Data Analytics），還能更好地支援資料服務（Data Serving）場景，比如標籤資料需要明細級的查詢、實時業務資料需要支援點更新、高併發以及大資料量的複雜 Join 。除此之外，我們希望該 OLAP 引擎可以便捷、低成本的的整合到 Lambda 架構下的離線/實時數倉架構中。**立足於此，我們在技術選型時對比了市面上的幾款 OLAP 引擎，如下圖所示**：

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

根據對選型的要求，**我們發現 Apache Doris 可以很好地滿足當前業務場景及訴求，同時也兼顧了低成本的要求，因此決定引入 Doris 進行升級嘗試**。

### **架構設計**

我們在 2022 年引入了 Apache Doris ，並基於 Apache Doris 構建了一套比較相對完整的實時數倉架構，如下圖所示。

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

總的來說，引入 Doris 後為整體架構帶來幾大變化：

-   統一了計算平臺（玄武計算），底層引擎支援 Flink、Spark 等元件，接入層支援統一 SQL 和 JAR 包接入。
-   引入 Doris 後，我們將實時數倉分為 ODS、DWD、DWS、ADS 層，部分中間層實時資料直接使用 Doris 進行儲存；
-   構建了基於 Doris 的 HOLAP 多維分析平臺，直接服務於業務；簡化了原來需要透過 Hive 進行預計算的加工鏈路，逐步替換使用難度和運維難度相對較高的 ClickHouse；
-   下游應用的資料儲存從之前的 MySQL 和 HBase 更換為 Doris，可以在資料集市和大寬表的資料服務場景下直接查詢 Doris。
-   支援混合 IDC（自建和雲廠商）。

### Overwrite 語義實現

Apache Doris 支援原子替換表和分割槽，我們在計算平臺（玄武平臺）整合 Doris Spark Connector 時進行了定製，且在 Connector 配置引數上進行擴充套件、增加了“Overwrite”模式。

當 Spark 作業提交後會呼叫 Doris 的介面，獲取表的 Schema 資訊和分割槽資訊。

-   如果為非分割槽表：先建立目標表對應的臨時表，將資料匯入到臨時表中，匯入後進行原子替換，如匯入失敗則清理臨時表；
-   如果是動態分割槽表：先建立目標分割槽對應的臨時分割槽，將資料匯入臨時分割槽，匯入後進行原子替換，如匯入失敗則清理臨時分割槽；
-   如果是非動態分割槽：需要擴充套件 Doris Spark Connector 引數配置分割槽表示式，配完成後先建立正式目標分割槽、再建立其臨時分割槽，將資料匯入到臨時分割槽中，匯入後進行原子替換，如匯入失敗則清理臨時分割槽。

### 架構收益

透過架構升級及二次開發，我們獲得了 3 個明顯的收益：

-   構建了規範、完善、計算統一的實時數倉平臺
-   構建了統一混合 OLAP 平臺，既支援 MOLAP，又支援 ROLAP，大部分多維分析需求均由該平臺實現。
-   面對大批次資料匯入的場景，任務吞入率和成功率提升了 50%。

# Doris 在標籤中臺的應用

標籤中臺（也稱使用者畫像平臺）是鬥魚進行精準運營的重要平臺之一，承擔了各業務線人群圈選、規則匹配、A/B 實驗、活動投放等需求。接下來看下 Doris 在標籤中臺是如何應用的。

### 原標籤中臺架構

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

上圖為鬥魚原來的標籤中臺架構，離線標籤在數倉中加工完成後合入寬表，將最終資料寫入 HBase 中，實時標籤使用 Flink 加工，加工完直接寫入到 HBase 中。

終端 APP 在使用標籤中臺時，主要解決兩種業務需求：

-   人群圈選，即透過標籤和規則找到符合條件的人。
-   規則匹配，即當有一個使用者，找出該使用者在指定的業務場景下符合哪些已配置的規則，也可以理解是“人群圈選“的逆方向。

在應對這兩種場需求中，原標籤中臺架構出現了兩個問題：

-   實時標籤鏈路：Flink 計算長週期實時指標時穩定性較差且耗費資源較高，任務掛掉之後由於資料週期較長，導致 Checkpoint 恢復很慢；
-   人群圈選：Spark 人群圈選效率較低，特別是在實時標籤的時效性上。

### 新標籤中臺架構

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

引入 Apache Doris 之後，我們對標籤中臺架構的進行了改進，主要改進集中在實時鏈路和標籤資料儲存這兩個部分：

-   實時標籤鏈路：仍然是透過實時資料來源到 Kafka 中，透過 Flink 進行實時加工；不同的是，我們將一部分加工邏輯遷移到 Doris 中進行計算，長週期實時指標的計算從單一的 Flink 計算轉移到了 Flink + Doris 中進行；
-   標籤資料儲存：從 HBase 改成了 Doris，利用 Doris 聚合模型的部分更新特性，將離線標籤和實時標籤加工完之後直接寫入到 Doris 中。

#### **1. 離線/實時標籤混合圈人**

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

-   簡化儲存：原儲存在 HBase 中的大寬表，改為在 Doris 中分割槽儲存，其中離線標籤 T+1 更新，實時標籤 T 更新、T+1 採用離線資料覆蓋矯正。
-   查詢簡化：**面對人群圈選場景**，無需利用 Spark 引擎，可直接在標籤中臺查詢服務層，將圈選規則配置解析成 SQL 在 Doris 中執行、並獲得最終的人群，大大提高了人群圈選的效率。**面對規則匹配場景**，使用 Redis 快取 Doris 中的熱點資料，以降低響應時間。

#### **2. 長週期實時標籤計算原鏈路**

長週期實時標籤：計算實時標籤時所需的資料週期較長，部分標籤還需要採用歷史資料（離線）合併實時資料流一起進行計算的場景。

**使用前：**

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

從原來的計算鏈路中可知，計算長週期的實時標籤時會涉及到維度補充、歷史資料 Merge，在經過幾步加工最終將資料寫入到 HBase 中。

在實際使用中發現，在這個過程中 Merge 離線聚合的資料會使鏈路變得很複雜，往往一個實時標籤需要多個任務參與才能完成計算；另外聚合邏輯複雜的實時標籤一般需要多次聚合計算，任意一箇中間聚合資源分配不夠或者不合理，都有可能出現反壓或資源浪費的問題，從而使整個任務除錯起來特別困難，同時鏈路過長運維管理也很麻煩，穩定性也比較低。

**使用後：**

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

我們在長週期指標計算實時鏈路中加入了 Apache Doris，在  Flink 中只做維度補充和輕度加工彙總，只關注短的實時資料流，對於需要 Merge 的離線資料，Merge 的計算邏輯轉移到 Doris 中進行計算，另外 Doris 中的輕度彙總/明細資料有助於問題排查，同時任務穩定性也能提升。

### 使用收益

目前標籤中臺底層有近 4 億+條使用者標籤，每個使用者標籤 300+，已有 1W+ 使用者規則人群，每天定時更新的人群數量達到 5K+。標籤中臺引入 Apache Doris 之後，**單個人群平均圈選時間實現了分鐘級到秒級的跨越**，實時標籤任務穩定性有所提高，實時標籤任務的產出時間相較於之前約有 **40% 的提升**，資源使用成本大大降低。

# Doris 在多維資料分析平臺的應用

除以上所述應用及收益之外，Apache Doris 也助力內部多維資料分析平臺——鬥魚 360 取得了較大的發展，受益於 Apache Doris 的 Rollup、物化檢視以及向量化執行引擎，使原來需要預計算的場景可以直接匯入明細資料到 Doris 中，簡化了業務資料開發流程，提升了分析效率；Doris 相容 MySQL 協議，並具有獨立簡單的分散式架構，使得業務開發人員入門使用也更容易，縮短了業務開發週期，有效降低了開發成本；同時我們原來基於 ClickHouse 的查詢目前也全部切換到了 Doris 中進行。

目前我們用於多維分析場景的 Doris 叢集共有兩個，節點規模約 120 個，儲存資料量達 90~100 TB，每天增量寫入到 Doris 的資料約 900GB，其中查詢 QPS 在 120 左右，Apache Doris 應對起來毫不費力，輕鬆自如。

*因文章篇幅限制，該部分應用不再贅述，後續有機會與大家進行詳細分享。*

# 未來展望

未來隨著 Apache Doris 在鬥魚更廣泛業務場景的落地，我們將在視覺化運維、問題快速定位排查等方面進行更多實踐和深耕。我們關注到， Apache Doris 1.2.0 版本已經對 Multi Catalog 功能進行了支援，我們也計劃對其進行探索、解鎖更多使用場景，同時也期待即將釋出 Apache Doris 2.x 版本的行列混存功能，更好的支援 Data Serving 場景。

賦能直播行業精細化運營，鬥魚基於 Apache Doris 的應用實踐

相關文章