編者按：自從2021年1月份推出免費的StarRocks標準版產品後，我們的客戶量出現了爆發式的增長。到目前為止，已經有數十家客戶在生產環境正式上線了StarRocks，並且有數百家客戶正在進行真實業務場景的測試。我們邀請了部分已上線的客戶，分享他們的資料分析經驗。這個系列的文章涉及多個行業，將在未來持續輸出，敬請關注。
作者：寧彥輝
中移物聯網大資料開發工程師，主要從事流計算開發、物聯網機器學習資料探勘以及OLAP查詢引擎資料開發
中移物聯網作為中國行動通訊集團有限公司出資成立的全資子公司。公司按照中國移動整體戰略佈局，圍繞“物聯網業務服務的支撐者、專用模組和晶片的提供者、物聯網專用產品的推動者”的戰略定位， 專業化運營物聯網專用網路，設計生產物聯網專用模組和晶片，打造車聯網、智慧家居、智慧穿戴等特色產品，開發運營物聯網連線管理平臺OneLink和物聯網開放平臺OneNET，推廣物聯網解決方案，形成了五大方向業務佈局和物聯網“雲-網-邊-端 ”全方位的體系架構。
本文主要討論了中移物聯網在PGW實時會話業務資料分析與建模方面，利用SparkStreaming和StarRocks進行的探索與實踐。並希望我們在實時數倉建模領域的應用實踐，能給大家一些啟發，也歡迎大家多多交流，給我們提出寶貴的建議。
PGW實時會話業務背景介紹
中移物聯網作為物聯網業務領域的支撐者，目前線上物聯卡使用者達到6.7億。中移物聯網智慧連線部大資料團隊作為物聯卡使用者與物聯卡之間的資料分析紐帶，主要依託物聯卡的基礎屬性資料和使用行為資料透過數倉建模、大資料探勘等其他手段為使用者提供高效的資料服務。
PGW實時會話業務主要指的是，透過PGW網元裝置實時收集從全球各地傳送回來、符合Radius協議的GGSN報文資料，然後透過大資料分析等手段，進行資料建模、資料探勘等其他子專案。例如為集團客戶提供每張物聯卡的實時位置和分佈情況；透過風險防控模型，對比實時收集的報文資料，為客戶提供每張物聯卡的風險等級等專案。
業務痛點及實時技術的挑戰
目前該業務在具體落地過程中，以及應用業務對實時資料需求方面，主要存在以下問題和技術難點：
1. 流式資料join。目前PGW實時會話業務，峰值每秒資料達到35萬/s，針對不同的業務需求，往往在資料清洗階段，需要對流式資料進行欄位關聯，然後以寬表形式寫入；
2. 存量資料排序、實時分析。一方面因為各地區網元裝置的不穩定等其他因素，往往實時傳送過來的資料存在亂序問題，另一方面因為單條會話長期線上(最長超過14天），對於單條會話的實時分析往往需要對存量資料進行排序；
3. 統一的實時OLAP資料平臺構建。我們的使用者包括：內部售後團隊、運營、產品等內部人員外，還有外部政企平臺客戶。不同的使用者往往關係的資料粒度、時間頻率、維度等各不相同。但是我們希望能建立一套統一的實時OLAP資料平臺，並提供一套靈活、安全可靠的實時資料服務。
目前整個業務的資料規模和業務如下：
技術框架的調研與演進
1. 原有技術框架
原有技術框架以及整個PGW實時會話業務的處理流程如上。實時資料透過流處理元件處理後，針對不同需求和業務方，資料儲存和展示藉助多技術元件。並且大多情況下為滿足一個業務需求往往需要多技術元件配合使用。如PGW明細會話查詢，往往是藉助Redis或ES作為索引元件再去查詢Hbase，一方面Hbase只能進行簡單的模糊查詢，無法做到聯邦查詢、聚合統計查詢，另一方面若統計查詢藉助Impala+Hive時效性往往很難保證。
2. MPP技術框架的調研
為解決實時分析的時效性，同時又能保證資料快速寫入，並且能夠對外提供一個較為統一和簡單的OLAP資料平臺。我們先後調研了ClickHouse、StarRocks、Kudu。並針對我們的業務分析和業務痛點做了以下測試。
ClickHouse：雖然具備較好的OLAP分析效能，但因其底層的架構設計，叢集模式下資料寫入需開發人員手動指定寫入節點以及資料儲存目錄以保證叢集資料平衡。同時叢集擴容後很難做到資料自平衡，對運維人員提出較高要求，另一方面由於該資料庫不支援事務特性，在資料更新時容易出現數據重複，且不易解決此問題。
StarRocks：查詢分析效能強悍，多表關聯速度比其他產品快很多。與Clickhouse類似，StarRocks目前不支援欄位級別的資料更新，同時查詢效能與表的設計和叢集效能密切相關。原則上叢集效能隨資料節點線性增長。另外，簡便的運維管理也是StarRocks的一大亮點。目前StarRocks開發版本迭代快，需要及時跟進官方的版本進展。
Kudu：支援快速資料更新、快速資料分析與即席查詢，但是資料量不宜過大，單表資料量不宜超過15億。
效能方面，批次寫入效能Clickhouse略優於其他系統，相同資源條件下明細查詢效能ClickHouse和StarRocks比Impala+Kudu更快，StarRocks有比較方便的物化檢視（Rollup）可以滿足統計查詢的需求，另外StarRocks在關聯查詢方面效能有比較明顯的優勢。
綜上所述，實時數倉方案，採用Kudu + StarRocks相結合，實現現有PGW實時會話業務。StarRocks作為主要技術元件，Kudu輔助實現欄位級別更新業務場景。
3. 現有技術框架
3.1 現有技術框架整體介紹
為解決現有的業務痛點，同時平衡在實時資料處理技術實現上的難點。我們摒棄了部分技術元件，採用新的技術元件搭建整個實時數倉用於滿足PGW實時會話業務。其中StarRocks可以滿足大多場景的需求。
PGW會話業務中流式Join問題，一部分我們透過在StarRocks中星型建模的方案的解決，另一部分我們藉助關係型記憶體資料庫VoltDB+Google Guava Cache，流式元件處理過程中程式碼實現。
存量資料的排序、實時分析問題。我們藉助StarRocks range分割槽以及高效的OLAP效能初步緩解。
最後統一OLAP分析平臺，我們完全藉助StarRocks實現。
3.2 StarRocks解決的痛點和挑戰
1. 充分利用StarRocks在多表join方面的效能最佳化，如Colocate Join、記憶體表等特性。將原來的流式join方案改為透過星型建模方案，在資料服務層進行多表join的聯邦查詢；
2. 透過StarRocks動態分割槽特性對存量資料進行分割槽，然後利用Bitmap資料型別進行精確去重，然後再在各分割槽內完成排序。排序的結果進一步彙總到一張資料表中，和實時到來的資料放在一起排序，可以有效地解決資料亂序問題，並且保證資料分析的效率。
3. StarRocks可作為資料服務層的統一對外引擎，一方面保證查詢效能，另一方面避免了原來多技術元件帶來的冗餘問題，極大降低了系統的管理成本。
4. 技術實現方面：替代Hbase部分業務，緩解了Hbase分割槽分裂帶來的效能問題；透過ES外表引擎，解決ES表不能進行join、語法特殊等技術問題。
StarRocks在具體專案上的應用及最佳化
目前StarRocks叢集總共25臺BE，4臺FE，儲存採用支援採用NVME協議的SSD硬碟。
1. PGW使用者實時位置軌跡
1.1 方案介紹
實時收集到的GGSN報文，透過StarRocks的聚合模型，將發生位置變更軌跡的明細資料實時沉澱下來。並對不同的區域維度生成Rollup表。最細粒度到基站級別，然後生成省、地市級別的Rollup表以供不同業務查詢。
GGSN報文量35萬/s，透過SparkStreaming處理解析後，每1分鐘StreamLoad一次入StarRocks。
1.2 方案最佳化
最開始因為Rollup表建了省、地市、區縣、鄉鎮，導致在寫入時IO負擔過大，寫入速度跟不上資料推送，SparkStreaming出現擠壓，後期透過效能測試Rollup表只建立了省、地市維度。同時新增一張鄉鎮base表，並在其基礎上建立區縣Rollup表。
同時為保證查詢的時效性,base表Rollup表字首索引在欄位型別和選擇上按照官方建議，避免使用Varchar型別。
2 區域會話明細模型
2.1 專案背景
資料服務層需對外提供每張物聯卡，統一會話發生位置變更後在不同區域的套餐使用情況，會話時常等資訊。進而統計物聯卡各區域的漫入漫出情況。
2.2 專案方案
實時收集到的GGSN報文，透過StarRocks的聚合模型，將發生位置變更時的套餐記錄，變更時間沉澱下來。然後透過定時任務，從聚合模型明細資料中計算出套餐使用情況，會話時長，生成新的DWD表。StarRocks目前的物化檢視很有用，但還不是很靈活，比如，只支援明細資料表模型，並且支援單表建立物化檢視，不支援多表Join構建物化檢視。
StarRocks在中移物聯網PGW實時會話業務領域的展望
一方面我們目前瞭解到，StarRocks開發團隊，目前正在解決StarRocks欄位級別無法支援更新的短板。在未來StarRocks升級過程中，我們可能會摒棄掉Kudu,完全藉助StarRocks實現實時數倉技術架構。
另一方面，我們期待StarRocks物化檢視的靈活性更高，可以支援Join級別的物化檢視和不同表引擎的物化檢視。除此之外，在接下來的專案開發過程中我們也計劃進一步使用bitmap索引、 Colocation Join等更豐富的功能提高我們的查詢速度。
除此之外，為了完善實時數倉的分層結構，我們計劃在未來使用Flink來對接StarRocks，保證數倉的分層結構，同時進一步完善統一的OLAP資料分析平臺。
