導讀：本文分享的主題是 StarRocks 在遊族的多元分析場景，将從以下 4個方面展開：
- 遊族 OLAP 系統曆史背景
- StarRocks 的特點和優勢
- StarRocks 在遊族 OLAP 系統中的應用場景
- 遊族 StarRocks 應用的未來規劃
分享嘉賓｜劉成彬 遊族網絡 資深大資料開發
編輯整理｜Henry hypers
出品社群｜DataFun
01
遊族 OLAP 系統曆史背景
1. 曆史背景與痛點
首先分享一下我們的曆史背景，上圖是我們之前做實時和離線名額計算所使用的一些元件：
- 分鐘級别排程的名額計算：用 Presto 或者是 Clickhouse。
- Kafka資料流的計算：用 SparkStreaming 或者 Flink 去讀取并計算。
- 标簽表的計算：會導入一些标簽表到 HBase 裡面，然後通過 Data API 的方式去提供給其他的系統使用（比如我們公司是做遊戲的，會有一些玩家的标簽表在對接客服之類的系統，他們會實時去檢視每一個玩家的資訊，進行一些問題的解答，我們會提供這樣的資料）。
- 報表展示：報表的實時名額的結果會落到 MySQL 庫裡面，報表系統會直接讀取 MySQL 作為名額的展示。
這些元件其實各有優勢：比如 Presto 直聯 Hive，不需要做其他的操作，就可以做一些自主分析；ClickHouse 的一些單表，查詢性能也特别好。
但是慢慢的演變之後，我們就會産生特别多的元件，給我們帶來了一些痛點：
- 首先元件太多，維護多套元件的運維成本是比較高的。
- 其次，各元件的 SQL 文法存在差異，特别是 ClickHouse 不支援标準 SQL，是以開發維護任務的成本也會比較高。
- 第三，同名額資料因為有多套系統在計算，需要去保證不同元件計算的結果和口徑都一樣，成本也是比較高。
- 最後，我們的結果資料是落在 MySQL 裡面的，有一些次元比較多的資料結果資料量是比較大的，需要對 MySQL 通過分表去支援資料的存儲和查詢，然而資料量大的時候，即使分表，其查詢性能也比較差，是以我們的報表系統時間上響應會比較慢。
2. 訴求
為了解決以上痛點，我們需要選擇統一的 OLAP 引擎，該引擎至少要滿足以下要求：
- 資料秒級寫入，低延遲毫秒級響應
- 複雜場景多表關聯查詢性能好
- 運維簡單，友善擴充
- 支援高并發
- 易用性強，開發簡單友善
我們對比了市面上一些元件，希望用一款存算一體的元件去優化我們的整個架構。首先，ClickHouse 的使用和運維比較困難，并且多表關聯的性能比較差，是以我們沒有選擇 ClickHouse。我們又對比了 StarRocks 和 Doris，因為 StarRocks 在性能上會更好，是以我們最終選擇了 StarRocks 作為統一的 OLAP 引擎。
--
02
StarRocks 的特點和優勢
1. 極緻的查詢性能
StarRocks 是有着極緻的查詢性能的，主要得益于以下的這幾點：
- 分布式執行 MPP：一條資料/一條查詢請求會被拆分成多個實體的執行單元，可以充分利用所有節點的資源，這樣對于查詢性能是一個很好的提升。
- 列式存儲引擎：對于大多數的 OLAP 引擎來說的話，基本會選擇列式存儲，因為很多的 OLAP 場景當中，計算基本上隻會涉及到部分列的一些提取，是以相對于“行存”來說，列存隻讀取部分列的資料，可以極大的降低磁盤 IO。
- 全面向量化引擎：StarRocks 所有的算子都實作了向量化，向量化簡單的了解就是它可以消除程式循環的優化，是實作了 Smid 的一個特性，也就是當對一列資料進行相同的操作的時候，可以使用單條指令去操作多條資料，這是一個在 CPU 寄存器層面實行的對資料并行操作的優化。
- CBO 優化器：這是 StarRocks 從 0 開始設計的一款全新的優化器，在多表查詢或者一些複雜查詢的情況下，光有好的一些執行性能是不夠的，因為同樣的一條 SQL，會有不同的執行計劃，不同計劃之間的執行性能的差異可能會差幾個量級，是以需要一款更好的優化器，才能夠選擇出相對更優的一個執行計劃，進而提升查詢效率。
上面的圖表是一個 SSB 的基準測試，把一個星型模型轉變成了一個單表，然後用一些 SQL 查詢語句去測試。在這種情況下可以看到 StarRocks 的性能是好于 ClickHouse 和 Druid 的。下面的圖表是一些低基準資料聚合查詢的對比，同樣也是 StarRocks 的性能會顯得更好一些。
2. 豐富的導入方式
StarRocks 還擁有着豐富的導入方式，使用者可以根據自己的實際場景選擇合适的導入方式。以前使用其他元件時，在大多數情況下我們都會選擇一些其他的導入工具來幫助我們完成資料的導入，比如 Sqoop、 DataX，等等一些工具；但是 StarRocks 有豐富的導入方式，是以無需借助其他工具，對接大多數元件都可以通過 StarRocks 提供的這些導入方式去直接完成資料的導入，可以極大節省開發時間。
3. StarRocks 的優勢特點
StarRocks 還有一些其他優勢：
- 運維簡單：右側這個圖是 StarRocks 一個簡單的架構圖，隻有 FE 和 BE 兩種元件，不依賴于外部元件，運維簡單，并且也友善擴縮容。
- 豐富的資料模型：StarRocks 支援明細、聚合、更新、主鍵4種資料模型，同時它還支援物化視圖，友善我們針對不同的場景去選擇合适的資料模型。
- 簡單易用：StarRocks 相容 MySQL 協定，支援标準的 SQL 文法，不需要太多的學習成本就可以去直接使用它。
- 支援多種外部表：StarRocks 支援多種外部表，比如 MySQL、ElasticSearch、Hive、StarRocks（這裡指另一個叢集的 StarRocks）等等，做跨叢集的、跨元件的關聯查詢也無需資料的導入，可以直接建立外部表，基于多個資料源去做關聯查詢，在一些分析當中是比較友善的。
--
03
StarRocks 在遊族 OLAP 系統中的應用場景
1. 實時計算場景/家長監控中心
首先分享一個實質性比較高的場景。
- 左側圖看到的是我們的一款小程式
這款小程式是根據文化部的指導和要求研發的，目的是為了加強家長對未成年參與網絡遊戲的監護，提供一種家長監護的管道，可以使得家長能夠看到未成年的一些遊戲時長的資料或者是充值金額，進而對孩子進行遊戲時長的限制和遊戲充值的限制。
這需要我們為該遊戲提供有各個未成年賬号的一些實時的線上資料，或者是充值資料。
- 右側圖是這一需求的資料流轉圖
我們會通過讀取 Kafka 裡面的資料在 Flink 當中進行計算，實時寫入StarRocks，再通過 Data API 的方式去提供給小程式使用，因為跨部門協作，是以用 Data API 的方式去提供資料比較安全；我們也有一條離線覆寫的線路，因為在 Flink 計算，難免會有一些上報的資料存在網絡延遲，在這個場景中資料都會實時更新到 StarRocks，部分資料的計算可能會有一些差異，是以我們最終要用離線資料去覆寫。
這裡因為我們會實時去更新賬号資訊，StarRocks 可更新的特性也為我們提供了很大的友善。
2. 實時更新模型選擇
StarRocks 中提供了兩種模型可以用于資料的更新，這兩種元件的内部機制是有所差別的，是以使用場景也不太一樣。
- 更新模型
内部是使用 Merge on Read 的方式去實作資料的更新的，也就是說 StarRocks 在底層操作的時候不會去更新資料，但是會在查詢的時候實時去合并版本，是以同一主鍵的資料會存儲多個版本；這樣的好處是在寫入的時候會非常流暢，但是也有壞處，在頻繁導入資料的時候，主鍵會存在多個版本的資料，這對于查詢性能會有所影響。
- 主鍵模型
内部是使用 Delete and Insert（删除并更新）的方式，StarRocks 會将主鍵存于記憶體中，在資料寫入的時候，會去記憶體中找到這條資料，然後執行一個标記删除的操作，之後會把新的資料插入進去，最後合并的時候隻需要過濾掉那些标記删除的資料就可以了，這樣它的查詢性能會比更新模型更高；因為我們的這一需求實時性要求是比較高的，是以更新特别頻繁，最終的使用也是給小程式提供實時的服務，是以我們最終還是會優先考慮查詢性能。我們更傾向于去選擇主鍵模型，去作為表的資料模型。
3. 主鍵模型不能使用 Delete 方式删除資料
前文提到離線覆寫實時的一個操作，場景是當我們在資料有一些差異的時候，需要用離線資料覆寫實時資料；使用 StarRocks 的主鍵模型進行這種操作時，其實并不是用 Delete 的方式去删除資料的，隻能夠通過 Stream Load、Broker Load、Routine Load 等這三種導入的方式去删除資料，這是非常不友善的，導入時需要先提供一個标志位，去标明這是 Upsert 還是 Delete；對于直接寫 SQL 語句去删除是非常不友好不友善的，下圖中是使用主鍵模型時删除資料的代碼示例。
4. 軟删除
在這種情形下，我們會選擇使用軟删除的方式去标記删除，因為 StarRocks主鍵模型能夠更新資料的特性，可以使我們把這些需要删除的資料先查詢出來，再變更它的一個删除标志位，這樣就可以達到了删除的目的了。
資料在 StarRocks 的更新模型是可以支援删除操作的，但是在這種情況下，我們為什麼還是選擇主鍵模型，而不是去選擇更新模型呢？主要是由以下的 3 點情況：
- 第一，我們這個場景的資料更新，頻率是非常高的，是以用更新模型的查詢性勢必會有所下降。
- 第二，更新模型的删除也是有一些限制的，在删除條件比較複雜的情況下也是無法删除的；比如說隻能夠根據“排序列”去删除，或者是删除條件隻能用與 AND 不能用或 OR，或者是隻能使用一部分的操作符，并不是所有的删除情況、所有的條件下都可以去删除；在我們的場景和删除條件下，在更新模型裡面無法滿足。
- 第三，我們會用離線資料去覆寫實時資料，這兩份資料其實是非常相近的，隻會有很少的不一緻，是以我們删除的備援也是很少的；此外這個需求隻會保留 30 天的資料，我們也會對表做一個動态分區，讓 StarRocks 自己去對這些表的資料做一個生命周期的管理；總結下來，我們删除的無效資料是非常少的，也就是備援會比較少，是以并不會影響到查詢性能。
是以基于這三點原因，我們在這種場景下會更傾向于去選擇主鍵模型。
5. 報表實時名額計算/架構介紹
接下來介紹一下報表的一些實時名額的計算，首先報表是固定次元的，我們會有各種時效性的名額，是以在引進 StarRocks 之後，我們的架構也做了一些變化。
- 首先，Flink 會讀取 Kafka 的資料，但是隻做一些簡單的ETL操作；
- 其次，我們也會去跟 HBase 互動，實時生成比如賬号首次登入表，或者是角色首登表這種資訊，并且把這些資訊關聯到日志上面。
- 做完上述操作之後，資料會寫入到下級的 Kafka，最終同時寫入 Hive 和 StarRocks 裡面。
- 最終，名額計算會統一在 StarRocks 裡面做分鐘級别的排程，完成實時名額的計算，一些資料的邏輯分層也是在這裡面做。
最終我們的報表系統也是以 StarRocks 為核心，直接讀取 StarRocks 的結果資料，不需要再像之前一樣，在一個元件裡面計算完的資料還導到 MySQL 裡面進行展示；此外，我們對外提供的資料存在 StarRocks 裡面，也能夠通過一個統一的 Data API 的方式去提供，因為它是支援多并發的。
6. 資料關系模型轉變
在資料模組化方面，我們也有一些轉變。以前在使用 ClickHouse 時，因為多表 Join 的能力不理想，我們的資料關系模型基本會使用一些大寬表，盡量使用單表查詢，以保證查詢性能；但寬表模型的問題是，一旦次元有所變化，回溯的成本是很高的。
在引入 StarRocks 之後，因為它有很好的多表 Join 的能力，是以我們盡量會去考慮星型模型或者雪花模型，當次元不變化的時候，我們不需要回溯的成本，可以直接用多表 Join 的方式去查詢資料，同時也把事實表和次元表去解耦，以便去應對更多的靈活分析、多元分析的場景。
7. 精确一次性保證
在精準一次性保證的方面，以前我們使用 Flink 寫入 ClickHouse 的時候，是無法保證資料的精确一次性的，這樣我們在下遊做計算時，會去做各種去重的操作，比如說日志 ID 的去重，賬号的去重、訂單的去重等等。
在引入 StarRocks 之後，我們使用官方的插件 Flink-Connector 去寫入，是可以保證資料的精确一次性的。雖然說我們計算原始日志，也會對日志做去重，因為我們不能夠保證日志從手機端上報到我們最終落入StarRocks 全鍊路的精确一緻性；但是對于Flink處理過的資料，能夠保證精确一次性，這對我們來說也是非常有意義的，能夠減少一些後續的操作。
8. 名額存儲轉變
以前實時計算的結果都會寫入 MySQL，需要借助其他工具，比如 Sqoop、DataX，或者是程式寫入等等；對于 ClickHouse 可能會用庫引擎的方式或者是程式寫入。
在引入 StarRocks 之後，實作了算存一體，不需要其他導入；在做查詢分析需要關聯其他元件的時候，我們也可以根據其他資料源建立外表，然後直接做查詢分析；這對于資料的流通性來說是非常友好的，也更能友善我們的開發工作，比如一些 adhoc 臨時的分析也不用導數，直接做一些多資料源的查詢就可以了。
9. 常用資料導入方式
實時資料：使用Flink-connector-StarRocks，其内部實作是通過緩存并批量由 Stream Load 導入 。
離線資料：建立 Hive 外表，用 Insert Into Select 方式直接寫入結果表。
①實時資料
我們使用官方的 Flink-Connector 插件導入資料，它的内部是通過緩存并批量由 Stream Load 去導入的，而 Stream Load 是通過 HTTP 協定送出和傳輸資料。
Flink Sync 資料并要支援精确一次性的話，需要外部系統支援“兩階段送出”的機制；但是 StarRocks 沒有這個機制，是以精确一次性的導入依賴于 StarRocks 的 Label 機制，就是說在 StarRocks 當中，所有的導入資料都會有一個 Label 用于辨別每一個導入的作業；Label 相同時 StarRocks 會保證資料隻導入一次，這樣保證 Flink 到 StarRocks 的精确一次性。
Label 預設儲存三天，也可以通過參數去調節，但因為該機制下系統要檢視它的 Label 是否存在，如果 Label 儲存的時間過長，肯定影響導入性能，是以也不可能無限期的儲存。隻要我們做好任務的監控，在通常情況下，我們是可以保證資料精确一次性寫入的。
②離線資料
我們目前主要是把以前 Hive 的一些結果資料遷移到StarRocks，以及一些離線計算的結果，也會刷到 StarRocks 裡面去，是以我們使用Hive外表這種方式，雖然該方式性能不如 Broker Load，但更友善。這種導入方式也有一些需要注意的點，因為 Hive 的源資料資訊，包括分區資訊以及分區下的一些檔案資訊，都是存儲在 StarRocks FE 中的，是以在更新 Hive 資料的時候，需要及時更新FE的緩存。
在 StarRocks 裡面提供了三種緩存的更新方式，首先是自動重新整理緩存，預設是兩個小時會自動重新整理一次；但是我們在導入離線資料的任務中，傾向于用第二種方式，就是手動的去重新整理緩存，能保證下一個導入任務執行的時候，緩存就已經更新了；最後一種是自動增量更新，跟第一種的差別是能夠自動的增量去更新，效率更高，是以也能夠提升更新頻率。
10. 分區分桶選擇
下面分享一下我們在 StarRocks 建表的時候會涉及到的分區分桶的選擇。
①先分區後分桶：如果不分區，StarRocks 會把整張表作為一個分區；分區是使用 Range 方式，分桶是使用 Hash 方式。
②分區選擇：通常會從資料管理的角度來選擇分區，第一要友善過濾資料；第二大多數情況下會選擇時間分區，這樣可以使用動态分區，能夠自動的幫我們删減分區。
③分桶選擇：因為分桶是用哈希的方式落到各個檔案上面，是以通常會選擇一個高基數的列來作為分桶鍵，這樣可以盡量保證資料在各個桶中是均衡的；分桶的個數我們會先去計算它的存儲量，然後盡量将每個 Tablet 設定成 500 兆左右。
在使用初期也曾遇到過問題，我們按照官方指南分成8個桶或32個桶，後來發現按天分區的話，一天的資料是在一天這個分區裡面去分桶，是以有些表就會小檔案特别多，然後在查詢的時候，掃描時間會特别長，這樣也會降低查詢性能，因為分桶是影響查詢的并行度的，分桶如果太少，并行度會比較低，太多的話又會導緻小檔案比較多。
是以這需要我們在建表設定分桶的時候，就對這個表的資料量有一個預估，然後去選擇合适的分桶個數。
11. 慢查詢分析
最後介紹下慢查詢分析。
StarRocks 也提供了一些慢查詢分析工具，比如可以到日志裡面去檢視慢查詢的資訊，或者是到頁面上去看它的 Profile（如圖所示）。
Profile 是 BE 執行後的一個結果，包含了每一步的耗時和處理量的結果。當遇到慢查詢時，你可以去具體分析這個 SQL 的執行情況，然後去通過對應的一些資訊達到優化。
--
04
遊族 StarRocks 應用的未來規劃
最後分享一下遊族對于 StarRocks 使用的一些未來規劃。
①首先我們會将剩餘的實時場景全部遷入到 StarRocks 裡面，建立以StarRocks 為核心的統一的查詢分析平台。
②我們之前的 Data API 服務其實是臨時的，是以我們也會去完善，建成一個全面的內建 StarRocks 的 Data API
③最後，我們會完善 StarRocks 的一些監控，比如慢查詢的監控、任務的監控、性能的監控等等。
--
05
問答環節環節
Q1：謝謝成彬老師的分享，下面是問答環節，歡迎直播間的小夥伴們留言提問。祖瑪提了第一個問題，他問家長中心的場景中延遲資料為什麼不适用 Flink 在計算，而是用離線資料的方式去覆寫
A1：首先因為我們每條資料的計算，涉及到 Flink 狀态的變更，還有我們 StarRocks 裡面的資料也會變更，是以說如果我們要再把延遲的資料加入，會改變掉它原來的一個計算結果，因為我們的計算是有持續性的。
當邏輯複雜的時候，我們還要這樣操作的話，首先是我們這樣操作會特别的複雜，第二我們這樣去回溯也是更浪費資源的，會把之前的很多資料再計算一遍，再就是我們在實作需求的時候，會先去觀察我們整體鍊路的資料延遲情況，然後去設定一個合理的水位線去計算。
是以基于這些原因，我們最終選擇了用離線覆寫的方式，去糾正我們的延遲資料。
Q2：謝謝成彬老師。第二個問題是威克特提的，他的問題是 StarRocks可以確定資料的一緻性，為什麼還需要 Hive 進行一次資料覆寫？是出于什麼考慮？
A2：因為 StarRocks 它是可以確定資料的一緻性；在使用 Flink 實時計算的時候，它的時效性和準确性是有取舍的；因為你不知道可能是使用者的網絡原因，或者是資料采集的一些過程，都有可能導緻資料的延遲。
比如你設定的一個就是實時計算的延遲是一分鐘，隻要有一條資料它在一分鐘甚至是十分鐘他都沒有來的話，Flink 計算的結果始終是不準确的（因為資料的延遲，在計算的時刻拿不到完整的資料去做計算）。
是以我們用離線計算覆寫，因為離線計算能夠保證前一天的所有資料，所有能采集的都已經采集到了，這樣的話我們去進行一個離線的覆寫。
今天的分享就到這裡，謝謝大家。
｜分享嘉賓｜
劉成彬｜遊族網絡 資深大資料開發
遊族網絡資深大資料開發，負責公司裝置資料貫通，實時數倉建設與名額開發。
｜《資料智能知識地圖》下載下傳｜
上下滑動⬆️⬇️，檢視《資料智能知識地圖》資料內建闆塊（點選可看大圖），關注公衆号“大話數智”，下載下傳完整版知識地圖
｜DataFun新媒體矩陣｜
｜關于DataFun｜
專注于大資料、人工智能技術應用的分享與交流。發起于2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公衆号 DataFunTalk 累計生産原創文章900+，百萬+閱讀，近16萬精準粉絲。