波克科技股份有限公司（以下簡稱“波克城市”）成立于 2010 年，立足于精品休閑游戲的全球化研發、發行，旗下擁有《爆炒江湖》《我是航天員》《貓咪公寓》等精品休閑游戲，連續五年入選中國互聯網百強。目前，波克游戲積極探索和發展“游戲+”模式，努力構建以游戲產業為核心、多產業交融發展的互聯網新生態。

基于大數據和人工智能的技術，波克城市正在組建自己的數據平臺，賦能各個項目組，以保障公司能在信息的洪流中持續前進。從最初的整理數據孤島，到數據開發規范流程化，再到現在的平臺化，每一個階段都成功為公司業務賦能。如今，智能投放和用戶的精細化運營已成為波克城市的主流工作方式。

面對越來越靈活和深入的數據分析要求，原有基于 Apache Impala（以下簡稱?Impala）和 CDH 構建的數據平臺越來越無力支撐。我們基于 StarRocks 構建了全新的數據分析平臺，復雜即席查詢性能提升 3 倍以上，并且可以支持業務數據實時更新，運維管理成本也得到了極大降低。有了 StarRocks，波克城市的游戲分析煥發出了新的活力。

01原有數據平臺難以應對復雜現狀—

業務內容

為了快速響應業務迭代的需求，近年來，波克城市著力于構建公司的綜合數據服務平臺。以現有的信息化系統為基礎，開辟各種系統間的數據通道，對現在的、歷史的、分散的業務數據進行鉆取和整合，充分利用現有的資源，激活數據價值。

波克城市大數據平臺部門借鑒了傳統數倉面向主題域的數據組織方式，基于維度建模理論構建統一的數據公共層和應用層。為了服務于不同的業務組，在綜合數據服務平臺中，根據不同的權限可以拉取核心項目報表，完成實時數據統計、管理監控指標、抽取自助報表查詢等操作。

在公司的數據平臺建設中，大數據平臺部門整理出以下需求： 較強的離線報表任務支撐，T+1 的報表任務必須在每天上午 7 點以前完成； 交互式自助即席查詢，以 SQL 為基礎進行交互式查詢，響應速度要足夠快（秒級別）； 用戶權限管控，必須要方便且快捷；

支撐實時業務，實時指標展示達到秒級別的延遲。

原有架構落地實現

在最初架構中，我們基于 CDH 搭建了綜合數據服務平臺。

上游的源數據庫主要是 MySQL，業務相關的數據和部分日志數據都記錄在里面。我們通過 DataX 和 Sqoop 將數據庫中的數據導入到 HDFS，通過 Apache Hive（以下簡稱 Hive） 的元數據映射生成 Schema，并接入 Impala 實現數據的即席查詢。數據倉庫的分層和建模全部都在 Hive 中完成，借助 LDAP 和 Sentry 進行用戶權限管理。

對于實時指標，我們通過 Flink CDC 和 Canal 采集 MySQL 的 Binlog 日志，解析到 Apache Flink（以下簡稱 Flink）中對數據進行處理建模，并關聯 Apache?Kafka（以下簡稱 Kafka） 中的埋點日志數據，生成實時指標寫入到 MySQL 中。該流程適用于大部分的報表需求，但是由于 MySQL 對于 OLAP 的任務執行效率較低，在單日報表超過 1 萬行的情況下，一些多維分析結果可能需要 10 秒以上才能返回，非常影響報表查看體驗。

我們也提供了相應的數據服務。分析師通過 JDBC 的連接方式自助對數倉數據進行查詢，項目組通過數據 API 將數倉數據直接應用于一線業務，相應的 BI 報表展示也基于 Impala 計算實現。

業務現狀及痛點

綜合數據服務平臺的業務已相對穩定，可以應付公司絕大多數數據業務，但是隨著數據量的增加和業務的增長，該數據平臺暴露了許多問題。

在技術實現方面，我們主要遇到了三個痛點：

1. 使用的組件過多。實現不同的需求需要不同的組件，例如批量處理需要 Hive，即席查詢需要 Impala，用戶權限管理依托 Sentry 和 LDAP……這些都沒有統一的入口，這對于數據倉庫的內部管理非常不友好。

2. 運維難度大。CDH 雖然是商業軟件平臺，可以界面化操作，但是大多數的組件依然需要靠自己去探索，并且官方文檔缺失嚴重。由于 CDH 已不在中國市場提供更新，暴露出來的漏洞也越來越多，數據倉庫的數據安全也面臨嚴峻的考驗。

3. 數據的增刪改非常不方便。Hive 是基于對 HDFS 的文件，不支持事務性的 DML 操作。雖然本身可以支持行級別的改刪，但是效率非常低。所以我們被迫對分區表都進行天級別的分區，又造成了小文件過多的問題。

在應用使用方面，我們也遇到了三個挑戰：

1. 大數據量的即席查詢較慢。雖然我們使用 Impala 進行加速查詢，但是由于數據文件沒有有效的索引，對于數據掃描量達到 10 億行的查詢，仍然需要幾十秒才能返回結果。并且自身的 SQL 優化器比較粗糙，SQL 編寫稍不規范，就會產生不必要的資源開銷，導致查詢卡死。

2. Impala 自身存在一些缺陷。在表數據或者表結構更新的情況下，需要手動刷新元數據才能查詢到最新的結果，非常不方便。并且大多數 BI 系統也不兼容 Impala 數據源。

3. 任務執行經常阻塞。由于底層通過 Yarn 進行資源調度，對于集群資源的使用效率不高。隨著數據任務數量的不斷增多，有限的集群核心數就成為了任務并發的瓶頸。即使集群整體的 CPU 使用率很低，也無法避免小任務將資源搶占、大任務無資源可用的尷尬情況。

針對上面的問題挑戰，我們的目標是尋求一個新的 OLAP 分析引擎以減少開發和運維的成本，提供優秀的讀取與寫入性能，并在高并發和高吞吐的場景下都可以提供較好的使用體驗。

目前市面上的 OLAP 數據庫產品百花齊放，如 Impala、Apache Druid（以下簡稱 Druid）、ClickHouse 及 StarRocks。在經過一系列的對比之后，StarRocks 高效的讀寫性能在眾多產品中脫穎而出。同時，高度活躍的社區生態給開發者與用戶帶來了良好的開發與使用體驗，所以我們選擇了 StarRocks 來作為綜合數據服務平臺的數據存儲引擎，替換原有的 CDH 方案。

02使用 StarRocks 改造綜合數據服務平臺—

StarRocks 應用優勢

相比于傳統的大數據解決方案，StarRocks 有以下優點：

極速的大寬表和多表查詢性能 支持高并發分析查詢 秒級數據實時更新能力 不依賴于大數據生態，同時外表的聯邦查詢可以兼容大數據生態 支持在線彈性擴縮容，可以自動負載均衡

兼容 MySQL 5.7 協議和 MySQL 生態

我們在綜合數據服務平臺遇到的痛點問題，在 StarRocks 中都得到了解決：

靈活數據建模方式支撐

在綜合數據服務平臺中，部分的固定報表業務可以根據查詢在數據導入時拼成寬表。但對于數據探查業務更為靈活的自助報表業務，我們很難預定義寬表的結構。

StarRocks 不僅能夠很好支撐寬表模型，也可以支持預聚合與星型/雪花模型。StarRocks 提供了不同的多表關聯方式，如 Shuffle Join、Broadcast Join、Colocation Join 等方式，CBO 會根據表的統計信息自動選擇最優的關聯方式；同時也可以通過物化視圖或聚合模型完成多維度上的預聚合操作。

實時高效的數據更新能力

在 OLAP 數據庫中，可變數據通常是不受歡迎的。在傳統數倉中，一般我們會使用批量更新的方式處理大量數據變更的場景，很難有一種方式能夠實時高效完成數據的更新操作。在 ClickHouse 中，我們可以選擇基于 merge-on-read 模式的 MergeTree 引擎，但會消耗極多資源，無法保證更新性能與數據同步的強一致性。

StarRocks 的主鍵模型采用 delete-and-insert 的模式，避免了 merge-on-read 在查詢時版本合并的開銷，非常好地解決了行級別的更新操作，在我們的業務測試中，可以支撐十幾萬的 TPS，非常適合 MySQL 數據庫實時同步到 StarRocks 需求。

簡單的運維操作

StarRocks 兼容 MySQL 協議。在替換原有的方案是，標準的 SQL 支持減少了對業務的侵入性。同時，相比于維護復雜的 CDH 環境，StarRocks 不依賴于大數據生態中的某一個組件，但又能夠兼容大部分的技術棧；自動化的故障恢復及在線擴縮容功能也極大程度地減少了運維成本。

極速查詢性能

在進行產品選型時，我們用線上業務在 PoC 階段進行了性能測試。在與 Impala、ClickHouse 等進行對比后，我們最終決定選擇 StarRocks。在這個性能測試中，我們選擇了 6 個使用最頻繁的業務 SQL，其中最大基表 game_log 超過百億記錄：

SQL 1 為簡單的點查操作，從 game_log 表中根據 uid 進行過濾，并通過 limit 進行分頁。 SQL 2 為簡單的點查操作，從 game_log 表中根據 game_id 進行過濾，未分頁。 SQL 3 為根據日期進行過濾的查詢語句，從 game_log 表中過濾出一天內的日志，并進行條件篩選。 SQL 4 為分類聚合查詢，根據時間條件進行數據篩選后進行一個維度的聚合，六個聚合指標。 SQL 5 為分類聚合查詢，根據時間條件進行數據篩選后進行三個維度的聚合，八個聚合指標。 SQL 6 為通過窗口函數進行分類聚合。

SQL	Impala	某云DB	ClickHouse	StarRocks
SQL1	5.2s	0.3s	0.16s	0.12s
SQL2	5.2s	138s	0.02s	0.04s
SQL3	0.18s	6.9s	0.04s	0.05s
SQL4	41.8s	46s	18.8s	7.5s
SQL5	95s	103s	58.5s	9.5s
SQL6	47.2s	62s	33.3s	7.2s

在經過一系列的性能測試與功能對比后，我們選擇了 StarRocks 作為綜合數據服務平臺的分析層數據存儲引擎。利用 StarRocks 極速查詢、多種數據建模方式以及 StarRocsk 的實時更新能力，我們將? Impala 上的業務遷移到了 StarRocks 上。

基于 StarRocks 的存儲引擎改造

對于存儲層的改造，我們使用 StarRocks 替換了原有的 CDH 方案。

在數據攝入層，由于 StarRocks 本身可以承接批處理和加速查詢的任務，我們將數據采集從之前的多個工具縮減到了 3 個。T+1 的業務數據通過 DataX 的 StarRocks Writer 組件直接導入 StarRocks；數據庫中的日志數據通過 Canal + Routine Load 的方式實時導入 StarRocks；對于日志服務器寫到 Kafka 的數據，我們在 Flink 中完成處理后通過 Flink Connector 寫入。

在數據建模的過程中，絕大多數的數據開發工作都在 StarRocks 中完成。我們在 StarRocks 中對數倉進行分層，ODS 層后面的 DWD、DIM、DWS 和 ADS 均借助 StarRocks 的計算完成。CDH 組件仍在使用，但是只保留了 HDFS 和 Hive，作為數據的冷備份，一般是兩年前的歷史數據。

針對于權限的管控，我們不再使用操作繁瑣的 Sentry + LDAP 組合，所有數據倉庫的用戶權限管理都通過 StarRocks 的用戶鑒權。由于和 MySQL 的用戶管理方式幾乎一致，所以對用戶的管理非常方便。我們已經將這一套用戶系統集成到了自己的平臺里。

業務改造收益

在引入 StarRocks 后，系統的查詢性能、數據寫入的實時性、技術框架對于業務的拓展性等方面，收益顯著增加。通過使用 StarRocks，解決了我們大部分痛點問題：

查詢速度提升 3 倍以上。即使是億級別的表，由于存在有效的索引和獨特的分區分桶機制，在多維分析的場景下依然可以做到秒級別的響應速度。相對于原有方案，性能得到了數倍提升。

運維簡單。StarRocks 架構簡單，其最主要的組件 FE 和 BE 提供了高可用和水平擴展的機制，即使出現單點故障問題或資源擴充的情況，對集群的穩定和數據安全造成的影響可以控制到極小。官方的文檔也非常豐富，平時也有專門的人員對接解決問題，不需要太關注底層的技術方面問題。

兼容性強。由于 StarRocks 本身在很多方面都和 MySQL 的使用方式一致，所以無論是 SQL 任務開發、BI 對接還是即席查詢，都不需要額外的學習和開發成本。

靈活的數據寫入和 DML 操作。StarRocks 支持多種數據的寫入方式，無論是離線的 DataX 還是實時的 Flink Connector 都可以完美實現。更重要的是支持 95% 以上的增刪改操作，無論是行級別的還是批量的，都支持事務。

03在更多業務推進 StarRocks 落地

—波克城市的大數據工作正朝向“大中臺，小前臺”方向發展，需要統一支撐各個游戲業務的分析，能不能構建極速統一的數據分析能力成為重中之重。StarRocks 強大的查詢性能，可以很好幫助我們構建全新的數據分析平臺，給各個游戲業務提供極速統一的分析能力。同時 StarRocks 架構簡潔，也可以幫助解決原來 Impala 平臺運維管理的復雜性。目前 StarRocks 集群承載著波克城市國內及海外休閑游戲的核心系統，未來我們計劃在更多業務上推進 StarRocks 的生產落地，例如： 實時的廣告投放多維分析，幫助市場部門及時更改投放策略，提高投資回報率。

作為用戶指標的載體，完成用戶畫像等的精細分析需求，賦能數據分析的相關人員。

以 StarRocks 作為公司部門訪問數據倉庫數據的入口和核心，完善交互式查詢的體驗。

關于 StarRocks

StarRocks 成立兩年多來，專注打造世界頂級的新一代極速全場景 MPP 數據庫，幫助企業建立“極速統一”的數據分析新范式，助力企業全面數字化經營。

當前已經幫助騰訊、攜程、順豐、Airbnb 、滴滴、京東、眾安保險等超過 110 家大型用戶構建了全新的數據分析能力，生產環境中穩定運行的 StarRocks 服務器數目達數千臺。

2021 年 9 月，StarRocks 源代碼開放，在 Github 上的星數已超過 2700 個。StarRocks 的全球社區飛速成長，至今已有超百位貢獻者，社群用戶突破 5000 人，吸引幾十家國內外行業頭部企業參與共建。