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