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

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

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

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

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

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

在目標驅動下，斗魚在原有架構的基礎上進行升級改造、引入 Apache Doris 構建了實時數倉體系，并在該基礎上成功構建了標簽平臺以及多維分析平臺，在此期間積累了一些建設及實踐經驗通過本文分享給大家。

原有實時數倉架構

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

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

• 在實際的流式作業開發中，缺乏對實時數據源的管理，在極端情況下接近于煙囪式接入實時數據流，無法關注數據是否有重復接入，也無法辨別數據是否可以復用。

• 離線、實時數倉完全割裂，實時數倉沒有進行數倉分層，無法像離線數倉按層復用，只能面向業務定制化開發。

• 數據倉庫數據服務于業務平臺需要多次中轉，且涉及到多個技術組件，ToB 應用亟需引入 OLAP 引擎緩解壓力。

• 計算引擎和存儲引擎涉及技術棧多，學習成本和運維難度也很大，無法進行合理有效管理。

新實時數倉架構

01 技術選型

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

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

02 架構設計

我們在 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（自建和云廠商）。

03 Overwrite 語義實現

Apache Doris 支持原子替換表和分區，我們在計算平臺（玄武平臺）整合 Doris Spark Connector 時進行了定制，且在 Connector 配置參數上進行擴展、增加了“Overwrite”模式。

當 Spark 作業提交后會調用 Doris 的接口，獲取表的 Schema 信息和分區信息。

• 如果為非分區表：先創建目標表對應的臨時表，將數據導入到臨時表中，導入后進行原子替換，如導入失敗則清理臨時表；
• 如果是動態分區表：先創建目標分區對應的臨時分區，將數據導入臨時分區，導入后進行原子替換，如導入失敗則清理臨時分區；
• 如果是非動態分區：需要擴展 Doris Spark Connector 參數配置分區表達式，配完成后先創建正式目標分區、再創建其臨時分區，將數據導入到臨時分區中，導入后進行原子替換，如導入失敗則清理臨時分區。

04 架構收益

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

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

Doris 在標簽中臺的應用

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

01 原標簽中臺架構

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

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

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

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

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

02 新標簽中臺架構

引入 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 中的輕度匯總/明細數據有助于問題排查，同時任務穩定性也能提升。

03 使用收益

目前標簽中臺底層有近 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 場景。