自從2021年1月份推出免費的DorisDB標準版產(chǎn)品后，我們的客戶量出現(xiàn)了爆發(fā)式的增長。到目前為止，已經(jīng)有數(shù)十家客戶在生產(chǎn)環(huán)境正式上線了DorisDB，并且有數(shù)百家客戶正在進行真實業(yè)務場景的測試。我們邀請了部分已上線的客戶，分享他們的數(shù)據(jù)分析經(jīng)驗。這個系列的文章涉及多個行業(yè)，將在未來持續(xù)輸出，敬請關注。
作者：寧彥輝——中移物聯(lián)網(wǎng)大數(shù)據(jù)開發(fā)工程師，主要從事流計算開發(fā)、物聯(lián)網(wǎng)機器學習數(shù)據(jù)挖掘以及OLAP查詢引擎數(shù)據(jù)開發(fā)
中移物聯(lián)網(wǎng)作為中國移動通信集團有限公司出資成立的全資子公司。公司按照中國移動整體戰(zhàn)略布局，圍繞“物聯(lián)網(wǎng)業(yè)務服務的支撐者、專用模組和芯片的提供者、物聯(lián)網(wǎng)專用產(chǎn)品的推動者”的戰(zhàn)略定位，專業(yè)化運營物聯(lián)網(wǎng)專用網(wǎng)絡，設計生產(chǎn)物聯(lián)網(wǎng)專用模組和芯片，打造車聯(lián)網(wǎng)、智能家居、智能穿戴等特色產(chǎn)品，開發(fā)運營物聯(lián)網(wǎng)連接管理平臺OneLink和物聯(lián)網(wǎng)開放平臺OneNET，推廣物聯(lián)網(wǎng)解決方案，形成了五大方向業(yè)務布局和物聯(lián)網(wǎng)“云-網(wǎng)-邊-端”全方位的體系架構(gòu)。
本文主要討論了中移物聯(lián)網(wǎng)在PGW實時會話業(yè)務數(shù)據(jù)分析與建模方面，利用SparkStreaming和DorisDB進行的探索與實踐。并希望我們在實時數(shù)倉建模領域的應用實踐，能給大家一些啟發(fā)，也歡迎大家多多交流，給我們提出寶貴的建議。
PGW實時會話業(yè)務背景介紹
中移物聯(lián)網(wǎng)作為物聯(lián)網(wǎng)業(yè)務領域的支撐者，目前在線物聯(lián)卡用戶達到6.7億。中移物聯(lián)網(wǎng)智能連接部大數(shù)據(jù)團隊作為物聯(lián)卡用戶與物聯(lián)卡之間的數(shù)據(jù)分析紐帶，主要依托物聯(lián)卡的基礎屬性數(shù)據(jù)和使用行為數(shù)據(jù)通過數(shù)倉建模、大數(shù)據(jù)挖掘等其他手段為用戶提供高效的數(shù)據(jù)服務。
PGW實時會話業(yè)務主要指的是，通過PGW網(wǎng)元設備實時收集從全球各地傳送回來、符合Radius協(xié)議的GGSN報文數(shù)據(jù)，然后通過大數(shù)據(jù)分析等手段，進行數(shù)據(jù)建模、數(shù)據(jù)挖掘等其他子項目。例如為集團客戶提供每張物聯(lián)卡的實時位置和分布情況;通過風險防控模型，對比實時收集的報文數(shù)據(jù)，為客戶提供每張物聯(lián)卡的風險等級等項目。
業(yè)務痛點及實時技術的挑戰(zhàn)
目前該業(yè)務在具體落地過程中，以及應用業(yè)務對實時數(shù)據(jù)需求方面，主要存在以下問題和技術難點：
1.流式數(shù)據(jù)join。目前PGW實時會話業(yè)務，峰值每秒數(shù)據(jù)達到35萬/s，針對不同的業(yè)務需求，往往在數(shù)據(jù)清洗階段，需要對流式數(shù)據(jù)進行字段關聯(lián)，然后以寬表形式寫入;
2.存量數(shù)據(jù)排序、實時分析。一方面因為各地區(qū)網(wǎng)元設備的不穩(wěn)定等其他因素，往往實時傳送過來的數(shù)據(jù)存在亂序問題，另一方面因為單條會話長期在線(最長超過14天)，對于單條會話的實時分析往往需要對存量數(shù)據(jù)進行排序;
3.統(tǒng)一的實時OLAP數(shù)據(jù)平臺構(gòu)建。我們的用戶包括：內(nèi)部售后團隊、運營、產(chǎn)品等內(nèi)部人員外，還有外部政企平臺客戶。不同的用戶往往關系的數(shù)據(jù)粒度、時間頻率、維度等各不相同。但是我們希望能建立一套統(tǒng)一的實時OLAP數(shù)據(jù)平臺，并提供一套靈活、安全可靠的實時數(shù)據(jù)服務。
目前整個業(yè)務的數(shù)據(jù)規(guī)模和業(yè)務如下：
技術框架的調(diào)研與演進
1.原有技術框架
原有技術框架以及整個PGW實時會話業(yè)務的處理流程如上。實時數(shù)據(jù)通過流處理組件處理后，針對不同需求和業(yè)務方，數(shù)據(jù)存儲和展示借助多技術組件。并且大多情況下為滿足一個業(yè)務需求往往需要多技術組件配合使用。如PGW明細會話查詢，往往是借助Redis或ES作為索引組件再去查詢Hbase，一方面Hbase只能進行簡單的模糊查詢，無法做到聯(lián)邦查詢、聚合統(tǒng)計查詢，另一方面若統(tǒng)計查詢借助Impala+Hive時效性往往很難保證。
2.MPP技術框架的調(diào)研
為解決實時分析的時效性，同時又能保證數(shù)據(jù)快速寫入，并且能夠?qū)ν馓峁┮粋€較為統(tǒng)一和簡單的OLAP數(shù)據(jù)平臺。我們先后調(diào)研了ClickHouse、DorisDB、Kudu。并針對我們的業(yè)務分析和業(yè)務痛點做了以下測試。
ClickHouse：雖然具備較好的OLAP分析性能，但因其底層的架構(gòu)設計，集群模式下數(shù)據(jù)寫入需開發(fā)人員手動指定寫入節(jié)點以及數(shù)據(jù)存儲目錄以保證集群數(shù)據(jù)平衡。同時集群擴容后很難做到數(shù)據(jù)自平衡，對運維人員提出較高要求，另一方面由于該數(shù)據(jù)庫不支持事務特性，在數(shù)據(jù)更新時容易出現(xiàn)數(shù)據(jù)重復，且不易解決此問題。
DorisDB：查詢分析性能強悍，多表關聯(lián)速度比其他產(chǎn)品快很多。與Clickhouse類似，DorisDB目前不支持字段級別的數(shù)據(jù)更新，同時查詢性能與表的設計和集群性能密切相關。原則上集群性能隨數(shù)據(jù)節(jié)點線性增長。另外，簡便的運維管理也是DorisDB的一大亮點。目前DorisDB開發(fā)版本迭代快，需要及時跟進官方的版本進展。
Kudu：支持快速數(shù)據(jù)更新、快速數(shù)據(jù)分析與即席查詢，但是數(shù)據(jù)量不宜過大，單表數(shù)據(jù)量不宜超過15億。
性能方面，批量寫入性能Clickhouse略優(yōu)于其他系統(tǒng)，相同資源條件下明細查詢性能ClickHouse和DorisDB比Impala+Kudu更快，DorisDB有比較方便的物化視圖(Rollup)可以滿足統(tǒng)計查詢的需求，另外DorisDB在關聯(lián)查詢方面性能有比較明顯的優(yōu)勢。
綜上所述，實時數(shù)倉方案，采用Kudu+DorisDB相結(jié)合，實現(xiàn)現(xiàn)有PGW實時會話業(yè)務。DorisDB作為主要技術組件，Kudu輔助實現(xiàn)字段級別更新業(yè)務場景。
3.現(xiàn)有技術框架
3.1現(xiàn)有技術框架整體介紹
為解決現(xiàn)有的業(yè)務痛點，同時平衡在實時數(shù)據(jù)處理技術實現(xiàn)上的難點。我們摒棄了部分技術組件，采用新的技術組件搭建整個實時數(shù)倉用于滿足PGW實時會話業(yè)務。其中DorisDB可以滿足大多場景的需求。
PGW會話業(yè)務中流式Join問題，一部分我們通過在DorisDB中星型建模的方案的解決，另一部分我們借助關系型內(nèi)存數(shù)據(jù)庫VoltDB+Google Guava Cache，流式組件處理過程中代碼實現(xiàn)。
存量數(shù)據(jù)的排序、實時分析問題。我們借助DorisDB range分區(qū)以及高效的OLAP性能初步緩解。
最后統(tǒng)一OLAP分析平臺，我們完全借助DorisDB實現(xiàn)。
3.2 DorisDB解決的痛點和挑戰(zhàn)
1.充分利用DorisDB在多表join方面的性能優(yōu)化，如Colocate Join、內(nèi)存表等特性。將原來的流式join方案改為通過星型建模方案，在數(shù)據(jù)服務層進行多表join的聯(lián)邦查詢;
2.通過DorisDB動態(tài)分區(qū)特性對存量數(shù)據(jù)進行分區(qū)，然后利用Bitmap數(shù)據(jù)類型進行精確去重，然后再在各分區(qū)內(nèi)完成排序。排序的結(jié)果進一步匯總到一張數(shù)據(jù)表中，和實時到來的數(shù)據(jù)放在一起排序，可以有效地解決數(shù)據(jù)亂序問題，并且保證數(shù)據(jù)分析的效率。
3.DorisDB可作為數(shù)據(jù)服務層的統(tǒng)一對外引擎，一方面保證查詢性能，另一方面避免了原來多技術組件帶來的冗余問題，極大降低了系統(tǒng)的管理成本。
4.技術實現(xiàn)方面：替代Hbase部分業(yè)務，緩解了Hbase分區(qū)分裂帶來的性能問題;通過ES外表引擎，解決ES表不能進行join、語法特殊等技術問題。
DorisDB在具體項目上的應用及優(yōu)化
目前DorisDB集群總共25臺BE，4臺FE，存儲采用支持采用NVME協(xié)議的SSD硬盤。
1.PGW用戶實時位置軌跡
1.1方案介紹
實時收集到的GGSN報文，通過DorisDB的聚合模型，將發(fā)生位置變更軌跡的明細數(shù)據(jù)實時沉淀下來。并對不同的區(qū)域維度生成Rollup表。最細粒度到基站級別，然后生成省、地市級別的Rollup表以供不同業(yè)務查詢。
GGSN報文量35萬/s，通過SparkStreaming處理解析后，每1分鐘StreamLoad一次入DorisDB。
1.2方案優(yōu)化
最開始因為Rollup表建了省、地市、區(qū)縣、鄉(xiāng)鎮(zhèn)，導致在寫入時IO負擔過大，寫入速度跟不上數(shù)據(jù)推送，SparkStreaming出現(xiàn)擠壓，后期通過性能測試Rollup表只建立了省、地市維度。同時新增一張鄉(xiāng)鎮(zhèn)base表，并在其基礎上建立區(qū)縣Rollup表。
同時為保證查詢的時效性,base表Rollup表前綴索引在字段類型和選擇上按照官方建議，避免使用Varchar類型。
2區(qū)域會話明細模型
2.1項目背景
數(shù)據(jù)服務層需對外提供每張物聯(lián)卡，統(tǒng)一會話發(fā)生位置變更后在不同區(qū)域的套餐使用情況，會話時常等信息。進而統(tǒng)計物聯(lián)卡各區(qū)域的漫入漫出情況。
2.2項目方案
實時收集到的GGSN報文，通過DorisDB的聚合模型，將發(fā)生位置變更時的套餐記錄，變更時間沉淀下來。然后通過定時任務，從聚合模型明細數(shù)據(jù)中計算出套餐使用情況，會話時長，生成新的DWD表。DorisDB目前的物化視圖很有用，但還不是很靈活，比如，只支持明細數(shù)據(jù)表模型，并且支持單表創(chuàng)建物化視圖，不支持多表Join構(gòu)建物化視圖。
DorisDB在中移物聯(lián)網(wǎng)PGW實時會話業(yè)務領域的展望
一方面我們目前了解到，DorisDB開發(fā)團隊，目前正在解決DorisDB字段級別無法支持更新的短板。在未來DorisDB升級過程中，我們可能會摒棄掉Kudu,完全借助DorisDB實現(xiàn)實時數(shù)倉技術架構(gòu)。
另一方面，我們期待DorisDB物化視圖的靈活性更高，可以支持Join級別的物化視圖和不同表引擎的物化視圖。除此之外，在接下來的項目開發(fā)過程中我們也計劃進一步使用bitmap索引、Colocation Join等更豐富的功能提高我們的查詢速度。
除此之外，為了完善實時數(shù)倉的分層結(jié)構(gòu)，我們計劃在未來使用Flink來對接DorisDB，保證數(shù)倉的分層結(jié)構(gòu)，同時進一步完善統(tǒng)一的OLAP數(shù)據(jù)分析平臺。
（免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。 ）
