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