直播實錄 | 37 手遊如何用 StarRocks 實現使用者畫像分析

語言: CN / TW / HK
時間 2022-07-23 12:03:15
作者：向偉靖，37 手遊大資料開發工程師
 
37 手遊使用 StarRocks 已有半年多，在此期間非常感謝 StarRocks 團隊的積極協助，感受到了服務速度和產品速度一樣快，輔導我們解決了產品使用上的一些問題。
首先介紹下 37 手遊的背景。37 手遊主要專注於移動端遊戲發行和遊戲運營，成功發行運營了《斗羅大陸：魂師對決》、《雲上城之歌》等遊戲。資料是遊戲運營的基石，查詢效率對業務人員的體驗感受非常重要，因此提升查詢效率是我們團隊一直努力的目標。
本次分享主要內容包含：37 手遊的資料架構、StarRocks 對資料架構產生的影響，以及 StarRocks 在使用者畫像實踐上的應用。
 

業務和技術的痛點

在業務上，我們遇到了以下幾個主要痛點：
第一，資料分析效能不足。因為我們遊戲使用者維度指標特別多，資料需要複雜關聯查詢，才能得到相應的分析指標。有時候甚至還需要傳說中的 SQL Boy 幫忙取數。還有就是高併發查詢時間週期特別長的資料，響應特別慢，例如 LTV 這些分析指標，就需要查詢資料週期特別長。這些也是業務經常反饋比較多的問題。
第二，實時分析場景不足。主要體現在運營推廣等資料實時清洗出現延遲，影響到遊戲運營和廣告投放的策略。
同時，我們還面臨幾項主要的技術難點：
第一，大資料產品複雜元件多，運維成本高。
第二，實時同步 MySQL 資料到 OLAP 查詢引擎秒級查詢。當前部分業務資料儲存在 MySQL 上需要同步到 OLAP 進行提速查詢，所以技術需要保證業務資料一致性、時效性和查詢效能。
第三，千萬級維表資料關聯查詢效能低下。
第四，業務發展使資料快速膨脹，線性擴容成本高。
 

舊資料架構和 OLAP 選型

首先，我們先看看以下 37 手遊的資料架構。這是一個比較經典的實時離線架構。從下往上看，離線傳統的 Apache Hadoop（以下簡稱 Hadoop）叢集加上了資料湖 Apache Hudi（以下簡稱 Hudi）元件和 Apache Kafka（以下簡稱 Kafka）訊息佇列組成儲存層，Apache Hive（以下簡稱 Hive）和 Apache Flink（以下簡稱 Flink）元件組成實時離線處理引擎層，分析層就是眾多且複雜的 OLAP 元件，業務層更多是提供介面、 BI 報表展示等功能。其中分析層 OLAP 元件眾多且資料分析相對分散，就意味著使用這些元件成本高。
​
以下是我們用過的 OLAP 元件，各有優缺點：
1）Apache Kylin（以下簡稱 Kylin）：作為國產第一個 Apache 頂級專案，當時讓國內眾多開發者看到了原來我們可以離開源專案這麼近。如今國內眾多優質開源專案百花齊放，比如我們使用的海豚排程系統、StarRocks 等。Kylin 利用空間換取時間的方式，提前預構建好資料進行快速查詢。這就使得構建資料需要消耗大量計算資源和儲存資源，時效性也比較差，慢慢變得不太適用 37 手遊的場景。
2）ClickHouse：這匹俄羅斯黑馬的單表查詢效能特別強悍，但是隨著業務的深入使用，從單機到叢集構建，發現其運維複雜，且穩定性和資料一致性也有問題。這個時候就要根據我們的業務訴求開始調研其他 OLAP 元件。
3）StarRocks：我們是從技術部落格上發現了 StarRocks。隨著對 StarRocks 的系統架構和產品特性深入瞭解後發現，其產品能力基本解決了我們的痛點。主要體現在以下四點：部署監控運維簡單，相容 MySQL 協議和標準 SQL 語法，大表多表關聯查詢效能優異，支援不同資料來源高效匯入和支援資料實時更新。
經過業務資料匯入進行測試，StarRocks 基本滿足我們的測試效能基準。當前線上部署了3 臺 FE 和 5 臺 BE ， FE 的硬體配置單臺 8核 32G， BE 的硬體配置單臺 32核 128G。當前叢集相對較小，後面隨著業務遷移會逐漸申請擴容。
​
這裡有一張簡短的資料流程圖，可以看出舊架構資料流向和使用的中間元件，這裡使用 ElasticSearch 儲存使用者畫像資料來提供服務應用查詢，中間的 Kafka 作為訊息佇列經過 Logstash 消費到 ElasticSearch。
為什麼歷史資料會推到 Kafka 上呢？
主要在於 ElasticSearch 讀寫效能瓶頸。開始我們嘗試了將離線的 Hive 表，通過外部表的方式直接同步到 ElasticSearch 。在這種方式下，十億級別歷史資料初始化到 ElasticSearch，會導致其服務負載高、同步時間特別長。因此才把歷史資料推到 Kafka 利用其削峰填谷的能力，減輕 ElasticSearch 的部分壓力。但是實踐證明減緩不了多少壓力，另外業務讀取和實時離線寫入也會出現因負載高導致業務查詢超時的情況。
此外，ElasticSearch 不能滿足複雜關聯聚合查詢的需求，不同維度索引無法關聯並且沒有強大的 SQL 查詢能力。ElasticSearch 的限制導致了在複雜查詢場景下不能滿足需求。
簡單總結一下畫像選型的變更時間線：
​
ElasticSearch 在使用者畫像應用使用時間週期是比較長的。因為 ElasticSearch 單索引能快速滿足簡單的圈選人群需求。但是隨著業務發展，需要索引間複雜關聯分析，此時 ElasticSearch 支援不了。
ClickHouse 會出現大表關聯查詢效能低、資料一致性等問題。
最終 StarRocks 測試表現效能相當優異，千萬級維表關聯查詢秒級返回，資料實時同步延遲低等。
​
從上圖可以看到，測試事實表資料量兩億多，維表資料量四千多萬。ClickHouse 的關聯查詢時間大概 50s左右， StarRocks 關聯查詢在 1s 內，效能差異明顯。ClickHouse 的關聯查詢是直接把維表資料全部讀取出來進行匹配關聯查詢，而 StarRocks 對這塊做了關聯優化下推，這也體現了 StarRocks 大表關聯查詢效能優異。
 

替換 StarRocks 後的使用者畫像架構

​
替換為 StarRocks 後的資料架構新增了使用 FlinkCDC 實時同步 MySQL 資料到 OLAP 引擎上，這樣就增加了關聯資料的多樣性。
讀寫效能大幅度提升：1）滿足 ElasticSearch 舊架構讀寫效能；2）內建多種匯入方式，效能高效，測試使用 Broker load 匯入 Hive 十億級資料 ，120 分鐘就能完成處理，資源佔用低，也解決了舊架構讀寫的問題；3）增加了聯邦查詢功能，提供外部表連線 Hive 等異構資料來源查詢加速。
關聯查詢效能優異：1）滿足了畫像不同維度資料的複雜關聯；2）測試 ClickHouse 關聯查詢千萬級維度表，查詢時長為 1min，而 StarRocks 是在 5s 內；3）畫像時可以利用 Bitmap 點陣圖技術對複雜人群圈選進行提速。
​
上圖是一個簡單資料開發流向圖，從 Hive 離線清洗出使用者畫像縱表、寬表和基礎維表。縱表就是一個使用者、一個標籤、一個值。例如，一條記錄是，使用者小明，標籤age，標籤值18。另外一條記錄是，使用者小明，標籤sex，標籤值man。
這在縱表中存有兩條記錄，在寬表裡面構建，就只有一條記錄，兩列分別存取年齡和性別的標籤值。然後把開發好的縱表同步到 StarRocks 上用於構建 Bitmap 表，寬表同步到 StarRocks 的主鍵表，維表使用 StarRocks 外部表連線。實時資料同步到對應的基礎資料表上用於關聯查詢。

使用者畫像Bitmap表的開發設計

​
基於資料流向，這裡首先闡述下 Bitmap 資料表的開發設計。上圖展示了 Hive 明細縱表推送到 StarRocks 後的更新模型表。在 StarRocks 聚合模型的 Bitmap 表中，就有構建 Bitmap 表的一個 SQL 語句，到此 Bitmap 表構建設計已完成。
我們在明細資料聚合表設計上遇到過一些效能問題。一開始，我們根據 Hive 直接設計 StarRocks 更新表 Key 和桶順序分別是 uid，tag_type 這樣的順序的。但是我們構建 Bitmap 表的時候基本是使用 where tag_type in 的方式來查詢構建的，導致每次讀取 IO 基本打滿，影響實時資料寫入。後來，我們重新設計表的 Key 值順序，把 tag_type 提到 uid 前，修改之後讀取 IO 只佔用 20% 以下了。

使用者畫像查詢效能對比

​
再看下簡單查詢效能對比，當前明細縱表資料接近六百億資料，100多個標籤值，構建完 Bitmap 表後資料量在四十萬左右。上圖簡單查詢對比了 Apache Impala（以下簡稱 Impala）和 StarRocks 的 Bitmap 表的圈選速度，使用 StarRocks 後提升了接近 26 倍。
​
上圖左是一個 Bitmap 表使用的 SQL 示例，右邊是畫像業務實現的 SQL 邏輯。左邊示例中，應該填寫其他維度畫像的 Bitmap 表，或者填寫其它基礎資料表進行復雜關聯查詢圈選，這樣可能會更好地展現 StarRocks 優勢。

使用者畫像提供的基礎查詢服務 

​
在基於 Bitmap 表實現的人群圈選的功能模組中，現在支援按規則或非規則建立人群包，自定義上傳人群包，自由組合建立人群包。 未來會支援外聯更多資料
我們還直接使用了 StarRocks 提供的監控模版直接使用配置相關監控告警。下圖是 StarRocks 實時消費 Kafka 監控面板。
​

展望

接下來我們會有更多業務接入 StarRocks，替換原有 OLAP 查詢引擎；運用更多的業務場景，積累經驗，提高叢集穩定性。未來希望 StarRocks 優化提升主鍵模型記憶體佔用，支援更靈活的部分列更新方式，持續優化提升 Bitmap 查詢效能，同時優化多租戶資源隔離。
今後我們也會繼續積極參與 StarRocks 的社群討論，反饋業務場景。之前我經常參加社群群進行討論，在社群群裡獲得過很多技術上的支援和答疑。在此，感謝流木大佬、穎婷等 StarRocks 社群夥伴在技術上的耐心指導！
 
本文整理自 37 手遊 Meetup 直播
收看影片回顧請至：
http://www.bilibili.com/video/BV1ES4y1v7Eu?spm_id_from=333.999.0.0
如需完整版講師 PPT，請新增小助手微信 StarRocks-1，報暗號“37”
 
關於 StarRocks
  StarRocks 創立兩年多來，一直專注打造世界頂級的新一代極速全場景 MPP 資料庫，幫助企業建立“極速統一”的資料分析新正規化，助力企業全面數字化經營。
當前已經幫助騰訊、攜程、順豐、Airbnb 、滴滴、京東、眾安保險等超過 110 家大型使用者構建了全新的資料分析能力，生產環境中穩定執行的 StarRocks 伺服器數目達數千臺。
2021 年 9 月，StarRocks 原始碼開放，在 Github 上的星數已超過 3000 個。StarRocks 的全球社群飛速成長，至今已有超百位貢獻者，社群使用者突破 5000 人，吸引幾十家國內外行業頭部企業參與共建。
 

 

「」
「」