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

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

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

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

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

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

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

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

在目标驅動下，鬥魚在原有架構的基礎上進行更新改造、引入 Apache Doris（https://github.com/apache/doris） 建構了實時數倉體系，并在該基礎上成功建構了标簽平台以及多元分析平台，在此期間積累了一些建設及實踐經驗通過本文分享給大家。

原有實時數倉架構

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

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

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

新實時數倉架構

技術選型

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

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

架構設計

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

總的來說，引入 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 在标簽中台是如何應用的。

原标簽中台架構

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

終端 APP 在使用标簽中台時，主要解決兩種業務需求：

• 人群圈選，即通過标簽和規則找到符合條件的人。
• 規則比對，即當有一個使用者，找出該使用者在指定的業務場景下符合哪些已配置的規則，也可以了解是“人群圈選“的逆方向。

在應對這兩種場需求中，原标簽中台架構出現了兩個問題：

• 實時标簽鍊路：Flink 計算長周期實時名額時穩定性較差且耗費資源較高，任務挂掉之後由于資料周期較長，導緻 Checkpoint 恢複很慢；
• 人群圈選：Spark 人群圈選效率較低，特别是在實時标簽的時效性上。

新标簽中台架構

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

• 實時标簽鍊路：仍然是通過實時資料源到 Kafka 中，通過 Flink 進行實時加工；不同的是，我們将一部分加工邏輯遷移到 Doris 中進行計算，長周期實時名額的計算從單一的 Flink 計算轉移到了 Flink + Doris 中進行；
• 标簽資料存儲：從 HBase 改成了 Doris，利用 Doris 聚合模型的部分更新特性，将離線标簽和實時标簽加工完之後直接寫入到 Doris 中。

1. 離線/實時标簽混合圈人

• 簡化存儲：原存儲在 HBase 中的大寬表，改為在 Doris 中分區存儲，其中離線标簽 T+1 更新，實時标簽 T 更新、T+1 采用離線資料覆寫矯正。
• 查詢簡化：面對人群圈選場景，無需利用 Spark 引擎，可直接在标簽中台查詢服務層，将圈選規則配置解析成 SQL 在 Doris 中執行、并獲得最終的人群，大大提高了人群圈選的效率。面對規則比對場景，使用 Redis 緩存 Doris 中的熱點資料，以降低響應時間。

2. 長周期實時标簽計算原鍊路

長周期實時标簽：計算實時标簽時所需的資料周期較長，部分标簽還需要采用曆史資料（離線）合并實時資料流一起進行計算的場景。

使用前：

從原來的計算鍊路中可知，計算長周期的實時标簽時會涉及到次元補充、曆史資料 Merge，在經過幾步加工最終将資料寫入到 HBase 中。

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

使用後：

我們在長周期名額計算實時鍊路中加入了 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 場景。