8-3 StarRocks 在游族的多維分析場景與落地實踐.pdf

1、劉成彬 資深大數據開發|StarRocks在游族的多維分析場景01歷史背景歷史背景02StarRocks優勢優勢03應用場景應用場景04未來規劃未來規劃目錄目錄 CONTENT|歷史背景01|歷史背景|痛點1.維護多套組件，運維成本高2.各組件SQL語法存在差異，開發維護任務成本高3.同指標數據下，需要保證不同組件計算的結果與口徑都一致的成本比較高4.結果數據比較大時，MySQL性能比較差訴求|為了解決我們的痛點，并且能夠適應公司未來的實時查詢需求，我們需要統一OLAP引擎，選擇引擎至少需要滿足以下要求：數據秒級寫入，低延遲毫秒級響應復雜場景多表關聯查詢性能好運維簡單，方便擴展支持高并發易用性

2、強，開發簡單方便StarRocks優勢02|StarRocks優勢|極致的查詢性能分布式執行框架(MPP)列式存儲引擎全面向量化引擎CBO優化器StarRocks優勢|豐富的導入方式Broker LoadSpark LoadStream LoadRoutine LoadInsert IntoStarRocks優勢|運維簡單不依賴外部組件，方便縮擴容豐富的數據模型支持明細/聚合/更新/主鍵 四種數據模型，同時支持物化視圖簡單易用兼容MySQL協議，支持標準的SQL語法支持多種外部表MySQL,Elasticsearch,Hive,StarRocks,Apache Iceberg,.應用場景03|

3、實時計算場景/家長監控中心|家長監控中心截圖 數據流轉圖離線覆蓋實時寫入DataAPI實時更新模型選擇|主鍵模型與更新模型對比更新模型：使用merge on read的方式，在執行時實時合并多個版本的數據主鍵模型：使用delete and insert 的方式更新數據，主鍵存儲于內存中主鍵模型不能使用delete方式刪除數據|主鍵模型無法使用delete的方式刪除數據，只能通過Stream Load、Broker Load、Routine Load這三種導入方式進行數據的刪除軟刪除|增加數據有效標志位，通過insert into select 的方式來更變需要刪除數據的標志位，達到軟刪除的目的

4、有刪除操作的情況下，主鍵模型與更新模型應該怎樣抉擇？數據更新頻率很頻繁更新模型的刪除也有一些限制，刪除條件復雜的情況下也無法刪除軟刪除后冗余比較少報表實時指標計算/架構介紹|引入StarRocks后Flink只做簡單的ETL工作統一使用StarRocks做實時指標計算,在StarRocks內部做數據的邏輯分層報表系統直接讀取StarRocks結果數據對外提供的數據以DataAPI的形式提供數據關系模型轉變|會更多的考慮星型模型/雪花模型，以應對更加靈活的多維分析場景精確一次性保證|Flink-Clickhouse 與 Flink-StarRocks 精確一次性對比可以保證精確一次性寫入無法保證

5、精確一次性寫入指標存儲轉變|引入StarRocks之前，報表結果數據存MySQL，需要借助外部工具導入SqoopMySQL庫引擎或程序寫入Hive外表MySQL外表引入StarRocks后，以StarRocks為核心，算存一體，查詢分析統一常用數據導入方式|實時數據 使用Flink-connector-StarRocks，其內部實現是通過緩存并批量由 stream load 導入離線數據 創建Hive外表，用insert into select 的方式直接寫入結果表Hive外表Flink-connector-StarRocksInsert into分區分桶選擇|StarRocks使用先分區后分

6、桶的方式，如果不分區，則把整張表作為一個分區分區選擇：從數據的管理角度來選擇分區鍵，大多數情況下會選擇使用時間分區分桶選擇：通常選擇高基數的列來作為分桶鍵，這樣可以保證數據在各個桶中盡可能均衡分桶個數：計算數據存儲量，將每個tablet設置成 500M 左右慢查詢分析|Profile 與 Plan 查看可以在fe/log/fe.audit.log中看到所有查詢和慢查詢信息Profile是BE執行后的結果，包含了每一步的耗時和數據處理量等數據，可以通過StarRocksManager的圖形界面查看詳細內容未來規劃04|未來規劃|將剩余的實時場景全部遷入StarRocks建立以StarRocks為核心統一的查詢分析平臺DataAPI服務集成StarRocks完善StarRocks監控非常感謝您的觀看|