樂元素 X Hologres：一站式高效能遊戲運營分析平臺

阿里雲hologres發表於2022-11-23
遊戲

客戶介紹

樂元素創立於2009年，是一家以遊戲研發運營為主營業務的遊戲公司，同時業務涵蓋動畫作品、授權商品、音樂、演唱會、廣播劇等在內的知名互動娛樂公司 。樂元素旗下擁有《開心水族箱》、《開心消消樂》、《海濱消消樂》 《Merc Storia》、《Ensemble Stars》 等多款暢銷產品，以及《星夢手記》動畫 和卡通形象品牌“消消樂萌萌團” 。其中，《開心消消樂》更是堪稱國民級三消遊戲。

面對多款DAU超千萬的熱門遊戲產品，每天產生海量的遊戲日誌資料，如何透過資料運營獲引起家對興趣，提升遊戲體驗，降低使用者流失成為決定遊戲產品成敗的關鍵。然而資料規模巨大、分析模式複雜，對遊戲業務的運營分析資料產品形成了巨大的挑戰。一方面手遊產品迭代速度快、平均生命週期短，市場、運營需要快速的對玩家動態做出判斷，這要求資料流轉速度必須要快；另一方面，產品、使用者、營銷運營關注多資料面廣，既需要透過宏觀資料瞭解產品健康狀況，有需要透過多種微觀資料溯源問題原因，要求資料產品需要提供高靈活性的計算能力。

基於此背景，樂元素數倉團隊升級技術架構，透過阿里雲Hologres替換開源Hive+Presto架構，支援運營分析更加高效、實時，顯著提升運營效率，進一步輔助業務精細化運營。

急需一個實時、靈活、可擴充套件的遊戲資料分析平臺

在樂元素手遊類產品運營分析中更加重視玩家資料的多維資料上卷、下鑽分析能力。例如，運營同學在發現使用者流失嚴重的遊戲關卡時，需要迅速透過調整關卡設定，增加遊戲道具等方式，保持玩家對遊戲的關注度。市場、產品運營分析的主要內容涵蓋以下幾方面：

  1. 使用者相關部分：活躍使用者/裝置數、使用者活躍度、關卡留存率、流失率及實時線上玩家等統計指標；
  2. 推廣效果分析：如抽獎活動的點選率，參與率等分析評估對活躍度、使用者轉化的效果；
  3. 付費分析：付費使用者結構、付費使用者行為等；

在數倉構建方面，手遊資料主體來源於各款遊戲的埋點資料、離線使用者標籤特徵、業務資料。遊戲行業數倉有別於典型的電商、廣告業務的數倉模型，遊戲相關數倉模型構建以玩家行為事件資料為核心，特徵維度資料為輔助，同時遊戲之間玩家資料關聯性較弱，遊戲資料彼此正交，形成如下圖所示的主要數倉結構：

title=

結合業務痛點，樂元素數倉研發、分析工具團隊、運維團隊需要為運營團隊提供具有以下能力的自助分析平臺：

  1. 高實時性：面對海量的日誌資料，需要保障實施入庫，資料產生即可用；
  2. 高靈活性：面對指標資料、多維分析等複雜場景，能提供即席計算能力和豐富的SQL生態支援；
  3. 高擴充套件性：產品、分析需求增長的同時能有效控制資源成本，叢集規模擴充時能提供完善的監控和運維工具；

Hologres替換Hive+Presto助力實時數倉架構升級

數倉架構探索

遊戲業務的資料層應用主要為產品運營、市場運營同學提供高效、靈活的即席查詢能力，滿足報表、分析等常規業務場景，同時在新品釋出、活動推廣等場景中，也需要第一時間提供使用者的行為趨勢，方便運營快速瞭解使用者行為資料，而如果提供天級或者小時級的資料更新，往往不能滿足業務實時性的要求。因此，在遊戲業務的資料應用層中查詢的靈活性、資料的實時性是核心訴求。

針對應用層特點，實時數倉探索的初期為了滿足離線報表和實時查詢的需求。系統架構的示意圖如下：

  • 我們使用自建的HDP叢集作為資料儲存底座，以提供離線ETL、資料包表等需求；
  • 使用Presto讀取HDP資料方式，為自助分析平臺提供即席分析能力。
  • 對於實時性要求高的活動統計、流量分析業務，埋點資料透過實時資料鏈路，將近N分鐘資料寫出到指定的HDFS檔案上，然後在Hive中建立分割槽並關聯到該檔案上，滿足查詢實時資料需求；

title=

整個架構中，實時和離線採用兩套鏈路：

  • 實時資料流：遊戲服務端日誌、業務系統Binlog同步到Kafka，透過Flink關聯維度進行實時ETL，持久化到OSS上每分鐘建立的檔案中；定時將分鐘級檔案透過新分割槽方式追加到Hive的事實表分割槽中，在計算端透過Presto查詢Hive資料提供分鐘級實時能力。
  • 離線資料流：遊戲服務日誌、業務系統資料，離線同步至自建的HDP離線數倉，離線進行ETL用來提供歷史資料分析能力；

上述架構與2019年投入生產，系統上線初期業務規模較小，執行相對穩定。但隨著諸多爆款遊戲的上線，資料規模迅速上漲，基於HDP的系統架構出現多次節點故障，問題排查時間較長，系統升級維護的成本很高；另一方面，計算、儲存資源變得更加不匹配，系統的擴充套件性也面臨一定挑戰。總結來說，主要的問題有以下三點：

  1. 資料流轉慢： 受限於實時鏈路實現方案，實時鏈路端到端的延遲在分鐘級左右，流量高峰時段延遲會更長；
  2. 計算效能差： Presto引擎相容性雖好，但效能遠不如其他開源OLAP引擎，如ClickHouse、Hologres等；另一方面，實時資料鏈路架構檔案數過多，對計算效能影響較大；
  3. 運維成本高：自建HDP版本較老，出現問題排查成本高，且Hortonworks被Cloudera收購之後，後續維護計劃不明朗；叢集規模不斷擴大，出現鏈路故障恢復時間長，運維成本高；
  4. 開發成本高：需要定製開發一些模組來處理實時資料載入排程等功能，需要投入一些人力開發運維；同時鏈路較長，監控成本也比較高；
分析引擎選型

由於歷史技術架構的種種問題，我們開始調研業界實時數倉的實踐模型，希望引入一個全場景的OLAP引擎，來解決資料時效性、計算效能、成本三方面問題。在一段時間的摸索後，我們進行了ClickHouse、Presto、Hologres的多方面對比，Hologres相對於另外兩個引擎優勢較大，主要變現在以下幾方面（效能資料為業務實際測試結果）：

  1. 實時寫入效能較強,  單Core可以支援2萬~3萬RPS的寫入，並且與Flink可以無縫整合，能很好的滿足實時數倉的需求；
  2. 在相同規模性資源下，對業務系統中計算量較大的UV統計、留存計算、漏斗計算等場景進行壓測，效能專案Presto提升了5~10倍，96核的Presto叢集完全可以使用64核的Holgores叢集替換；
  3. Hologres的系統能力，如資源佇列、慢Query監控、連線管理等，可以大大提升管理效率；
  4. Hologres原生內建遊戲行業場景化的解決方案，如留存分析、人群畫像等元件支援，對業務提效有很大幫助。
OLAP 引擎實時寫入計算效能運維成本業務開發成本
Presto需要自建Kudu叢集中中較高
ClickHouse弱較高高較高
Hologres強高免運維較低
數倉架構升級

因此，我們最終決定使用Hologres替換現有基於Hive + Presto構建的實時數倉架構，整體系統架構演化為如下結構：

  • 由Hologres作為統一的資料儲存，儲存Flink實時寫入的資料以及離線加速的資料
  • 透過Hologres對接資料應用層，提供統一對外的資料出口，滿足運營的分析需求。

title=

上述系統架構在2022年5月上線，對高頻計算場景最佳化效果明顯，即席分析平均耗時降低數倍。截止目前，《海濱消消樂》、《偶像夢幻季》等遊戲已經完全遷移到Hologres架構。

  • 依託Hologres資料加密的功能，我們也部署了海外機房，快速支援了海外業務擴充套件。總體來講，對業務運營效率、研發迭代效率提升明顯。
  • 從系統指標層面看，初期使用128core的Hologres例項，可以承載離線資料高壓力匯入，匯入RPS約400萬+；實時資料承載了當時10k ~ 20k實時讀寫請求，單例項資料規模目前為15~10TB左右；高頻計算場景如近7天留存、近30天漏斗等計算時長均縮短至10s以下，基數運算可以在毫秒級完成。

典型的遊戲行為分析場景實踐

以下，我們針對一些典型的場景介紹下Hologres上的業務落地方案。選擇留存分析和漏斗分析作為示例進行介紹：

留存分析

留存分析是手遊中統計使用者參與度、活躍情況的一種重要的分析模型，透過留存分析可以瞭解手遊使用者的留存率，流失率情況，針對流失率使用者群進行其他潛在維度的上卷統計，可以進一步探索使用者流失原因。

title=

在留存分析中，我們針對玩家在一個時間段內的時間進行統計，指定一個初始事件和多個回訪事件，透過統計玩家在指定時間段內的事件序列計算使用者留存指標。初期基於Presto構建的自助分析平臺，留存分析只能透過使用者事件表的反覆JOIN來計算， 而事件表本身資料規模非常大(百億級別)，JOIN運算開銷非常大，對叢集造成很大壓力。

計算引擎替換成Hologres後，可以直接使用流量分析函式進行計算，函式透過對時間表的一次掃描完成留存計算，大大提升了計算效率，在典型的留存計算場景中，響應時間降低了一個數量級，同時，流量分析函式均支援延伸計算，分析師可以對對留存客群進一步分析。

例如，計算使用者登入到使用者進入遊戲主場景的多日留存情況，並對每日的留存使用者統計遊戲分享次數的計算中；基於Presto我們需要透過透過Join來完成留存人群的過濾，再JOIN一次計算遊戲分享事件次數；計算邏輯示例如下：

WITH init_events AS (
  SELECT uid, ds AS init_date
  FROM dwd_events
  WHERE ds BETWEEN '2021-07-14' AND '2021-08-13' AND event_id = 'sdk_login'
  GROUP BY 1,2
), -- 初始行為
return_events AS(
  SELECT uid, ds AS retention_date
  FROM dwd_events
  WHERE ds BETWEEN '2021-07-14' AND '2021-08-20' AND event_id = 'app_lifecycle'
  GROUP BY 1,2
), -- 回訪行為
mertic_events AS (
  SELECT uid, ds
  FROM dwd_events
  WHERE ds BETWEEN '2021-07-14' AND '2021-08-20' AND event_id = 'sdk_share'
) -- 統計維度
SELECT i.init_date,
       COALESCE(COUNT(CASE WHEN r.retention_date - i.init_date = 1 THEN 1 ELSE NULL END), 0) retention__1, 
       COALESCE(COUNT(CASE WHEN r.retention_date - i.init_date = 3 THEN 1 ELSE NULL END), 0) retention__3,
       COALESCE(COUNT(CASE WHEN r.retention_date - i.init_date = 3 THEN 1 ELSE NULL END), 0) retention__7
FROM init_events i -- JOIN 事件表，關聯回訪行為
JOIN (
  SELECT r.*
  FROM return_events r -- 關聯統計維度
  JOIN mertic_events m ON r.uid = m.uid AND r.retention_date = m.ds
) r ON i.uid = r.uid
GROUP BY i.init_date;

透過Hologres的留存函式進行延伸計算時，可以透過range_retention_count函式直接計算留存人群，該函式透過一次表掃描即可完成留存運算，效率非常高，運算邏輯示例如下：

WITH retention_detail AS (
  SELECT uid, 
         to_timestamp((unnest(detail) >> 32) * 86400)::date AS init_date,
         to_timestamp((unnest(detail) & 4294967295) * 86400)::date  AS retention_date
  FROM (
      SELECT uid, 
             public.range_retention_count(
              ds >= '2021-07-14' AND ds < '2021-08-13' AND event_id = 'sdk_login', -- 初始行為
              ds >= '2021-07-14' AND ds < '2021-08-20' AND event_id = 'app_lifecycle', -- 回訪行為
              ds, 
              ARRAY[1, 3, 7],  -- 計算1、3、7天的留存
              'day', 
              'expand'
            ) AS detail
      FROM dwd_events
      WHERE ds >= '2021-07-14' AND ds < '2021-08-20'
      GROUP BY uid
  ) r
)
SELECT  r.init_date, 
        COUNT(CASE WHEN r.retention_date - r.init_date = 1 THEN 1 ELSE NULL END) AS retention_1, 
        COUNT(CASE WHEN r.retention_date - r.init_date = 3 THEN 1 ELSE NULL END) AS retention_3,
        COUNT(CASE WHEN r.retention_date - r.init_date = 7 THEN 1 ELSE NULL END) AS retention_7
FROM retention_detail r
JOIN dwd_events m ON r.uid = m.uid AND r.retention_date = m.server_time::date  -- 關聯統計維度
GROUP BY r.init_date;
漏斗分析

在遊戲玩家的轉化率穩定階段，漏斗分析可以應用於多個流量採渠道評估轉化效果，同時對於新使用者的轉化過程，透過漏斗分析，可以找出轉化過程中使用者的流失環節，進行及時的查漏補缺。

title=

初期使用老架構的自助分析平臺，需要針對性的開發UDF，用來完成漏斗分析計算。計算引擎升級成Hologres 後可以直接使用windowfunnel漏斗函式進行運算。同時Hologres內表可以透過clustering_key 指定資料排序欄位、透過event_time_column可以實現資料分割槽內更細粒度的資料過濾，諸多特性都可以直接應用在windowfunnel的計算中。替換成Hologres引擎後，漏斗分析的效能也有5倍以上的提升。

升級數倉架構，業務運營效率提升10倍+

自助分析平臺互動式分析引擎底座自2022年5月投入生產以來， 運營團隊、產研團隊對平臺都給予了很高評價；從整體資料服務角度，使用Hologres進行技術升級帶來諸多好處：

  1. 運營效率顯著提升：在基礎的使用者分群、活動分析、使用者留存、漏斗分析場景中，計算耗時都有數倍的提升；其中留存、漏斗計算效能提升近10倍。
  2. 平臺穩定性提升：基於Hologres的引擎，完全可以承載高峰時期實時寫入壓力，相對歷史架構有質的改善；同時，極大降低自建系統的運維成本，高峰時期系統的彈性擴縮容能力也能在分鐘級完成，大大提升資料產品的穩定性、擴充套件性、可運維性，產研同學得以將更多精力，投入到資料研發方面；
  3. 成本節省：升級使用Hologres為分析引擎後，整體節約約50%機器成本，年節約成本數十萬元；

未來的展望

  1. 目前在Hologres中行為類資料的儲存仍然較高，計劃透過Hologres後續釋出冷熱資料分層功能，將查詢頻次低、長週期的資料遷移到冷儲存中；實現持續的降本增效；
  2. 目前離線資料仍然使用oss外表方式進行匯入，手工運維的成本比較高；計劃透過Hologres後續External Schema以及資料湖整合能力，降低手工運維成本。

瞭解Hologres：https://www.aliyun.com/product/bigdata/hologram

相關文章