江西省公安交通管理綜合應(yīng)用平臺分布式架構(gòu)改造的實踐與思考

鄒亞晨 朱永曄 江西省公安廳交通管理局 南昌市 330000

賀宇翔 楊東陽 華為技術(shù)有限公司 南昌市 330000

0 引言

2011年，全國公安交通管理部門依托公安信息通信網(wǎng)，全面建成了覆蓋部、省、市三級的公安交通管理綜合應(yīng)用平臺，實現(xiàn)了機(jī)動車管理、駕駛?cè)斯芾怼⒔煌ㄊ鹿侍幚?、交通違法處理等各項業(yè)務(wù)功能，形成了較為完整的公安交通管理業(yè)務(wù)數(shù)據(jù)庫。業(yè)務(wù)數(shù)據(jù)類型十分豐富，既包括結(jié)構(gòu)化數(shù)據(jù)，例如：機(jī)動車登記、駕駛?cè)丝荚?、交通違法處理記錄，又包含非結(jié)構(gòu)化數(shù)據(jù)，例如：機(jī)動車交通違法電子監(jiān)控圖片、道路交通事故現(xiàn)場勘查視音頻文件。隨著業(yè)務(wù)的快速發(fā)展，綜合應(yīng)用平臺在數(shù)據(jù)管理和服務(wù)能力上的瓶頸日益凸顯，海量數(shù)據(jù)的存儲、備份、擴(kuò)容和日志信息的分析都成為亟待解決的現(xiàn)實難題。隨著分布式技術(shù)日漸成熟，其建設(shè)成本低、擴(kuò)展能力強(qiáng)、適合非結(jié)構(gòu)化數(shù)據(jù)管理和大數(shù)據(jù)分析處理的優(yōu)勢日益顯現(xiàn)，通過搭建分布式架構(gòu)，對綜合應(yīng)用平臺進(jìn)行分布式應(yīng)用改造，能夠快速有效地解決這些現(xiàn)實難題。

1 實施改造前的基本情況

1.1 計算性能出現(xiàn)瓶頸

隨著綜合應(yīng)用平臺系統(tǒng)功能日益豐富，數(shù)據(jù)量快速增長，有限的計算資源已經(jīng)無法滿足快速增長的計算服務(wù)需要（業(yè)務(wù)量每年增長50%）。據(jù)統(tǒng)計，改造前，大量的后臺數(shù)據(jù)統(tǒng)計任務(wù)占據(jù)了綜合應(yīng)用數(shù)據(jù)庫服務(wù)器（小型機(jī)）至少40%的計算資源，白天業(yè)務(wù)高峰時段，數(shù)據(jù)庫服務(wù)器的CPU占用率時常在70%以上。

1.2 存儲容量已經(jīng)飽和

從數(shù)據(jù)量來看，Oracle數(shù)據(jù)庫存儲容量的90%被機(jī)動車交通違法電子監(jiān)控圖片數(shù)據(jù)占據(jù)。隨著電子監(jiān)控圖片增長速度的日益加快（數(shù)據(jù)量日均新增96GB），當(dāng)前的存儲設(shè)備容量已經(jīng)無法滿足業(yè)務(wù)需要，只能依靠不斷刪除歷史數(shù)據(jù)，釋放空間來應(yīng)對。2021年，綜合應(yīng)用平臺業(yè)務(wù)監(jiān)管系統(tǒng)還將上線運(yùn)行，海量的監(jiān)管影像資料、監(jiān)管日志數(shù)據(jù)需要存儲，這進(jìn)一步加劇了存儲資源的供需矛盾。

1.3 數(shù)據(jù)庫架構(gòu)限制應(yīng)用發(fā)展

現(xiàn)有Oracle數(shù)據(jù)庫受框架制約，在后臺數(shù)據(jù)分析、模糊檢索等方面存在缺陷。隨著大數(shù)據(jù)應(yīng)用的日益深化，更深層次的數(shù)據(jù)監(jiān)管、研判分析需求對底層計算框架的要求已無法通過傳統(tǒng)的Oracle數(shù)據(jù)庫技術(shù)來解決。

2 分布式架構(gòu)改造的目標(biāo)

結(jié)合平臺現(xiàn)狀和各類瓶頸問題，需要把圖片、日志和業(yè)務(wù)數(shù)據(jù)分別進(jìn)行獨(dú)立存儲和處理，給業(yè)務(wù)系統(tǒng)騰出更多的計算資源和存儲容量，從而整體上優(yōu)化系統(tǒng)處理效率，提升綜合應(yīng)用平臺的業(yè)務(wù)服務(wù)能力。具體目標(biāo)包括：

2.1 釋放存儲空間給業(yè)務(wù)系統(tǒng)減壓

不同類型數(shù)據(jù)對資源的占用特點均不同。圖片數(shù)據(jù)文件體積和數(shù)量都大，需要占用系統(tǒng)大量的“寫”資源；日志數(shù)據(jù)量大，需要頻繁“讀”和“寫”；業(yè)務(wù)數(shù)據(jù)是核心數(shù)據(jù)，量也大，經(jīng)常要進(jìn)行查詢和統(tǒng)計操作，需要頻繁“讀”。通過把圖片數(shù)據(jù)和日志數(shù)據(jù)遷移到分布式系統(tǒng)和分布式關(guān)系型數(shù)據(jù)庫中，與業(yè)務(wù)數(shù)據(jù)分開存儲，釋放Oracle數(shù)據(jù)庫存儲設(shè)備的存儲壓力和讀寫帶寬壓力。

2.2 分離不同事務(wù)處理，提升整體效率

通過將圖片和日志數(shù)據(jù)大量的聯(lián)機(jī)事務(wù)處理（OLTP）跟業(yè)務(wù)數(shù)據(jù)的聯(lián)機(jī)分析處理（OLAP）分開，解決Oracle數(shù)據(jù)庫對大表（流水表、日志表）查詢統(tǒng)計慢，幾分鐘甚至幾小時才能出統(tǒng)計結(jié)果，效率低的問題。

2.3 強(qiáng)化平臺軟硬件運(yùn)行監(jiān)控能力

改變以往靠系統(tǒng)管理員和數(shù)據(jù)庫管理員后臺登錄服務(wù)器和交換機(jī)，逐臺查看運(yùn)行日志的低效模式，利用分布式系統(tǒng)和分布式關(guān)系型數(shù)據(jù)庫的架構(gòu)優(yōu)勢，開發(fā)圖形可視化管理控制系統(tǒng)，實時監(jiān)控服務(wù)器集群及各系統(tǒng)組件的運(yùn)行性能，監(jiān)控業(yè)務(wù)數(shù)據(jù)的運(yùn)行情況，發(fā)現(xiàn)問題及時告警處置。

2.4 提升平臺軟硬件資源擴(kuò)充發(fā)展能力

利用性能較低的經(jīng)濟(jì)型PC服務(wù)器，通過“分布式系統(tǒng)+分布式關(guān)系型數(shù)據(jù)庫”的組合架構(gòu)實現(xiàn)PB級別數(shù)據(jù)量的處理能力，為超大規(guī)模數(shù)據(jù)庫管理提供高性價比的通用計算平臺，達(dá)到以往使用小型機(jī)和高端存儲陣列才能達(dá)到的性能效果，并且可以通過簡單增加服務(wù)器數(shù)量的方式實現(xiàn)存儲容量和計算能力的線性擴(kuò)充，實現(xiàn)平臺的更高性能、更高可用、更多算力。

3 項目實施過程

3.1 需求分析

2020年6月，該項目正式開展需求分析。具體包括：對綜合應(yīng)用平臺、綜合監(jiān)管系統(tǒng)的功能分析、主要業(yè)務(wù)量分析和資源需求分析。資源需求分析包括對存儲需求的測算和網(wǎng)絡(luò)資源的測算。

3.1.1 存儲需求測算

數(shù)據(jù)存儲需求：分布式系統(tǒng)應(yīng)滿足綜合應(yīng)用平臺歷史數(shù)據(jù)和至少三年的增量數(shù)據(jù)存儲要求。按照每年50%的增量計算，圖片數(shù)據(jù)庫歷史數(shù)據(jù)為60TB，應(yīng)支持不小于203TB存儲空間；業(yè)務(wù)數(shù)據(jù)庫歷史數(shù)據(jù)為7.5TB，應(yīng)支持不少于25TB存儲空間；日志數(shù)據(jù)庫歷史數(shù)據(jù)為6.6TB，應(yīng)支持不少于22TB數(shù)據(jù)。

分布式系統(tǒng)存儲需求：分布式系統(tǒng)應(yīng)支持203+25+22=250TB存儲空間，考慮數(shù)據(jù)增速會越來越快，預(yù)留10%的冗余，則測算需要275TB的數(shù)據(jù)存儲量。

分布式關(guān)系型數(shù)據(jù)庫存儲需求：并行關(guān)系型數(shù)據(jù)庫主要用于數(shù)據(jù)挖掘、數(shù)據(jù)分析類操作，把待分析的數(shù)據(jù)同步到綜合應(yīng)用平臺分布式數(shù)據(jù)庫的MPP數(shù)據(jù)倉庫，按照30%比例抽取，則三年數(shù)據(jù)量為（25+22）×30%=14TB，考慮數(shù)據(jù)挖掘、統(tǒng)計類操作會逐漸增加，預(yù)留20%冗余，則測算MPP數(shù)據(jù)庫需要17TB的數(shù)據(jù)存儲量。

3.1.2 網(wǎng)絡(luò)資源需求測算

分布式系統(tǒng)需要使用33臺服務(wù)器，每臺服務(wù)器采用2個萬兆端口進(jìn)行業(yè)務(wù)互聯(lián)、雙上行到兩臺不同的萬兆交換機(jī)；每臺服務(wù)器采用1個千兆口進(jìn)行管理業(yè)務(wù)互聯(lián)，上行到一臺獨(dú)立的千兆交換機(jī)，共需要66個萬兆光口及33個千兆端口，因此，此次改造的網(wǎng)絡(luò)部分，共需要2臺萬兆交換機(jī)及1臺千兆交換機(jī)。后續(xù)隨著數(shù)據(jù)量增加，分布式系統(tǒng)集群（Hadoop集群）與分布式關(guān)系型數(shù)據(jù)庫集群（MPPDB集群）還需分為不同平面，管理平面交換機(jī)增至雙配冗余，以確保穩(wěn)定性。

3.2 方案設(shè)計

2020年8月，該項目進(jìn)行總體方案設(shè)計。包括三部分內(nèi)容：

3.2.1 確立建設(shè)目標(biāo)

建設(shè)滿足綜合應(yīng)用平臺實際需求的分布式系統(tǒng)和分布式服務(wù)，實現(xiàn)分布式系統(tǒng)與業(yè)務(wù)功能的無縫對接，實現(xiàn)現(xiàn)有Oracle數(shù)據(jù)庫的圖片數(shù)據(jù)、日志數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)、統(tǒng)計數(shù)據(jù)安全平穩(wěn)遷移至分布式系統(tǒng)，有效釋放Oracle數(shù)據(jù)庫壓力，創(chuàng)新業(yè)務(wù)應(yīng)用模式，為綜合應(yīng)用平臺增加更多信息分析、檢索類功能。

3.2.2 明確建設(shè)內(nèi)容（1）建設(shè)分布式系統(tǒng)基礎(chǔ)環(huán)境

基于Hadoop集群與MPPDB集群，集成分布式生態(tài)環(huán)境中的HDFS、Hive、HBase、ES、MPP等組件進(jìn)行測試和調(diào)優(yōu)，實現(xiàn)綜合應(yīng)用平臺海量數(shù)據(jù)的分布式存儲，實現(xiàn)綜合應(yīng)用平臺分布式系統(tǒng)的運(yùn)行監(jiān)控和管理，包括：平臺運(yùn)行管理、數(shù)據(jù)管理和安全管理。

（2）建設(shè)分布式服務(wù)數(shù)據(jù)接口系統(tǒng)

通過搭建公安部交通科研所統(tǒng)一研發(fā)的綜合應(yīng)用平臺分布式服務(wù)數(shù)據(jù)接口系統(tǒng)，將現(xiàn)有業(yè)務(wù)平臺的非結(jié)構(gòu)化、結(jié)構(gòu)化、半結(jié)構(gòu)化數(shù)據(jù)通過接口接入到分布式系統(tǒng)中，實現(xiàn)交通管理多源異構(gòu)數(shù)據(jù)的接入，實現(xiàn)分布式系統(tǒng)與Oracle數(shù)據(jù)庫之間的數(shù)據(jù)分發(fā)和同步。

（3）進(jìn)行歷史數(shù)據(jù)遷移

將現(xiàn)有Oracle數(shù)據(jù)庫的圖片數(shù)據(jù)、日志數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)、統(tǒng)計數(shù)據(jù)遷移至分布式系統(tǒng)，然后實現(xiàn)“雙寫、雙同步”，最終實現(xiàn)數(shù)據(jù)“單寫”。

3.2.3 設(shè)計總體方案

對照建設(shè)目標(biāo)與建設(shè)內(nèi)容，完成與建設(shè)內(nèi)容相關(guān)的架構(gòu)設(shè)計、網(wǎng)絡(luò)設(shè)計和信息資源規(guī)劃，具體包括：

（1）總體架構(gòu)設(shè)計

從邏輯上將系統(tǒng)分為若干層，從下往上依次為：

?分布式系統(tǒng)基礎(chǔ)平臺：實現(xiàn)數(shù)據(jù)資源的管理、數(shù)據(jù)存儲組件、調(diào)度管理、消息服務(wù)、非結(jié)構(gòu)化數(shù)據(jù)存儲、索引數(shù)據(jù)存儲、計算數(shù)據(jù)存儲以及數(shù)據(jù)計算等，屬于分布式系統(tǒng)的數(shù)據(jù)基礎(chǔ)支撐平臺。

?分布式系統(tǒng)服務(wù)平臺：實現(xiàn)對分布式基礎(chǔ)平臺的數(shù)據(jù)存儲、數(shù)據(jù)組織，高可用訪問和異常處理等機(jī)制，實現(xiàn)對綜合應(yīng)用平臺的各類數(shù)據(jù)服務(wù)，實現(xiàn)訪問權(quán)限控制、訪問日志等服務(wù)管理功能。

?綜合應(yīng)用平臺：實現(xiàn)對傳統(tǒng)業(yè)務(wù)系統(tǒng)的分布式改造，實現(xiàn)更高效的統(tǒng)計分析、模糊檢索和對分布式集群的監(jiān)控。

（2）網(wǎng)絡(luò)架構(gòu)設(shè)計

分布式系統(tǒng)需要在網(wǎng)內(nèi)交換大量的管理和監(jiān)控數(shù)據(jù)，同時，網(wǎng)內(nèi)還要傳輸大量的業(yè)務(wù)數(shù)據(jù)，為了更好地支持這兩類數(shù)據(jù)的傳輸，內(nèi)部將網(wǎng)絡(luò)劃分為管理、業(yè)務(wù)兩個平面，保障兩個網(wǎng)絡(luò)平面相互隔離，互不影響。業(yè)務(wù)平面用來承載用戶端到分布式系統(tǒng)各個業(yè)務(wù)應(yīng)用子系統(tǒng)的流量以及數(shù)據(jù)中心內(nèi)部節(jié)點之間的的流量；管理平面用來承載網(wǎng)絡(luò)、服務(wù)器、存儲及安全等設(shè)備之間的管理數(shù)據(jù)、指令操作數(shù)據(jù)以及分布式系統(tǒng)的維護(hù)和監(jiān)控數(shù)據(jù)。管理平面與業(yè)務(wù)平面共用核心層交換機(jī)，通過VLAN實現(xiàn)兩個平面的隔離。

（3）分布式改造框架設(shè)計

對綜合應(yīng)用平臺進(jìn)行適用于分布式服務(wù)的改造，具體包括：①數(shù)據(jù)層。將原有傳統(tǒng)關(guān)系型數(shù)據(jù)庫改造成：分布式關(guān)系型數(shù)據(jù)庫存儲違法數(shù)據(jù)、日志數(shù)據(jù)和必要的業(yè)務(wù)數(shù)據(jù)，傳統(tǒng)關(guān)系型數(shù)據(jù)庫仍保留，但只存儲車管、駕管、違法和事故等業(yè)務(wù)數(shù)據(jù)；②服務(wù)層。將原有的數(shù)據(jù)服務(wù)平臺改造成滿足分布式需要的分布式服務(wù)平臺；③應(yīng)用層。將原有綜合應(yīng)用平臺的應(yīng)用功能按照傳統(tǒng)關(guān)系型數(shù)據(jù)庫和分布式系統(tǒng)進(jìn)行區(qū)分，實時業(yè)務(wù)操作和實時精確查詢類的功能基于傳統(tǒng)關(guān)系型數(shù)據(jù)庫開展應(yīng)用，海量數(shù)據(jù)分析和非結(jié)構(gòu)化數(shù)據(jù)檢索基于分布式系統(tǒng)開展應(yīng)用。

（4）數(shù)據(jù)流向設(shè)計

綜合應(yīng)用平臺業(yè)務(wù)系統(tǒng)分別向Oracle數(shù)據(jù)庫和分布式系統(tǒng)寫入結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)，并分別向兩個數(shù)據(jù)庫檢索讀取數(shù)據(jù)，分布式系統(tǒng)通過API數(shù)據(jù)接口向綜合應(yīng)用平臺提供服務(wù)，Oracle數(shù)據(jù)庫和分布式系統(tǒng)之間通過數(shù)據(jù)接入工具實現(xiàn)歷史數(shù)據(jù)的遷移。三者之間形成完整的數(shù)據(jù)同步和分發(fā)。

3.3 項目實施步驟

該項目于2021年1月至10月進(jìn)行安裝調(diào)試、集成部署、平臺升級、數(shù)據(jù)遷移等工作，具體包括四個步驟。

（1）硬件上架和安裝調(diào)試

該部分工作于2021年2月至3月完成，具體是對新購置的33臺服務(wù)器、2臺萬兆交換機(jī)等設(shè)備和利舊使用的交換機(jī)進(jìn)行硬件上架和安裝調(diào)試。

（2）分布式系統(tǒng)和關(guān)系型數(shù)據(jù)庫安裝部署

該部分工作于2021年3月至5月完成，具體是對各服務(wù)器節(jié)點進(jìn)行硬件檢查，確認(rèn)無問題后安裝CentOS操作系統(tǒng)，并根據(jù)設(shè)計方案對不同節(jié)點進(jìn)行組件安裝。包括5臺Hadoop管控節(jié)點服務(wù)器、15臺HBase服務(wù)器、3臺Kafka服務(wù)器、4臺ES服務(wù)器、2臺MPPDB集群管控節(jié)點服務(wù)器、4臺MPP數(shù)據(jù)節(jié)點服務(wù)器，共計33臺。

各節(jié)點實際部署流程為：開始—安裝前準(zhǔn)備—配置軟件包—生成配置文件—配置并檢查安裝環(huán)境—（安裝雙機(jī)Manager）—安裝集群—加載License—安裝后檢查—初始配置—結(jié)束。

（3）分布式服務(wù)安裝部署

該部分工作于2021年6月至7月完成，具體是安裝部署數(shù)據(jù)接入系統(tǒng)、圖片數(shù)據(jù)接口、日志數(shù)據(jù)接口、業(yè)務(wù)數(shù)據(jù)接口、數(shù)據(jù)搜索接口、索引管理系統(tǒng)、全文檢索系統(tǒng)、分布式數(shù)據(jù)庫運(yùn)行狀態(tài)監(jiān)控服務(wù)接口。共在6臺PC服務(wù)器上部署了接口服務(wù)，包括6個圖片數(shù)據(jù)接口（image-service），6個業(yè)務(wù)數(shù)據(jù)接口（buslog-service），3個消費(fèi)服務(wù)接口（consumer-service），3個注冊中心（sofa），2個同步服務(wù)接口（task-service），2個代理服務(wù)器（nginx），1個監(jiān)控服務(wù)接口（task-console-ser‐vice）。

（4）綜合應(yīng)用平臺升級改造

該部分工作于2021年7月至8月完成，具體是對證據(jù)圖片庫、工作庫日志數(shù)據(jù)表和基礎(chǔ)信息主表的改造，并新增或優(yōu)化功能，例如新增海量數(shù)據(jù)搜索功能、優(yōu)化統(tǒng)計分析功能。

改造的內(nèi)容包括：將原有部分保存在Oracle數(shù)據(jù)庫的結(jié)構(gòu)化業(yè)務(wù)、日志數(shù)據(jù)和非結(jié)構(gòu)化的圖片數(shù)據(jù)遷移至分布式系統(tǒng)中，并通過平臺的系統(tǒng)參數(shù)調(diào)整，設(shè)置從分布式系統(tǒng)中讀取相應(yīng)數(shù)據(jù)。其中圖片數(shù)據(jù)存在HBase中，日志數(shù)據(jù)和13張復(fù)雜業(yè)務(wù)表存在ES中，用來做多項查詢，日志和業(yè)務(wù)數(shù)據(jù)存入GaussDB中，用來做統(tǒng)計報表和一些查詢。

4 經(jīng)驗做法

4.1 制定詳盡的項目實施計劃

本項目是在綜合應(yīng)用平臺現(xiàn)有的“生產(chǎn)環(huán)境”上直接進(jìn)行改造。為確保改造的順利實施，在開始具體工作前，需要對現(xiàn)有的網(wǎng)絡(luò)拓?fù)?、網(wǎng)絡(luò)安全防護(hù)策略和機(jī)房環(huán)境進(jìn)行現(xiàn)場確認(rèn)，運(yùn)用思維導(dǎo)圖明確實施計劃，通過甘特圖細(xì)化實施步驟和耗時。對于網(wǎng)絡(luò)割接、數(shù)據(jù)遷移和應(yīng)用切換等關(guān)鍵步驟，要做好應(yīng)急預(yù)案。由于綜合應(yīng)用平臺是公安交通管理核心系統(tǒng)，應(yīng)該充分利用部交管局統(tǒng)一部署的系統(tǒng)升級窗口期進(jìn)行需要暫停業(yè)務(wù)的安裝部署操作，減少改造工作對綜合應(yīng)用平臺以及與其緊密關(guān)聯(lián)的互聯(lián)網(wǎng)服務(wù)管理平臺、12123語音平臺、集成指揮平臺以及各類外掛軟件、警務(wù)通系統(tǒng)的影響。

4.2 做出合理周全的設(shè)備網(wǎng)絡(luò)規(guī)劃

本次改造涉及的數(shù)據(jù)量較大，需要采購的各類軟硬件較多，要充分理清本地平臺的軟硬件現(xiàn)狀和數(shù)據(jù)量。對于改造過程中需要使用利舊設(shè)備的，要提前確認(rèn)硬件設(shè)備與采購軟件的兼容性；要提前了解市場主流分布式系統(tǒng)軟件對于網(wǎng)絡(luò)的需求，并按照分布式系統(tǒng)軟件要求，將網(wǎng)絡(luò)按照業(yè)務(wù)平面、管理平面以及設(shè)備MP管理卡劃分為3組網(wǎng)絡(luò)，其中業(yè)務(wù)平面和管理平面應(yīng)為不同的公安信息通信網(wǎng)網(wǎng)段，并進(jìn)行相應(yīng)的網(wǎng)絡(luò)路由設(shè)置。

4.3 加強(qiáng)廠商間協(xié)調(diào)和網(wǎng)絡(luò)安全防護(hù)

本次改造除了新增大量網(wǎng)絡(luò)設(shè)備和服務(wù)器設(shè)備，還新增了非常多的分布式系統(tǒng)應(yīng)用服務(wù)，因此，在部署實施前，要按照信息安全等級保護(hù)的要求，做好網(wǎng)絡(luò)安全域劃分，將Oracle數(shù)據(jù)、分布式系統(tǒng)、WAS應(yīng)用、微服務(wù)架構(gòu)應(yīng)用進(jìn)行科學(xué)劃分；要與科信部門提前做好協(xié)調(diào)，爭取公安網(wǎng)核心交換機(jī)對分布式系統(tǒng)軟件要求的相應(yīng)特殊通信端口的支持；要做好安全服務(wù)廠商和應(yīng)用服務(wù)廠商之間的協(xié)調(diào)；要提前收集應(yīng)用服務(wù)所需的端口、應(yīng)用功能和網(wǎng)絡(luò)流向，做好安全防護(hù)設(shè)備的策略部署，做到端口級的網(wǎng)絡(luò)防護(hù)策略。

5 初步成效

5.1 Oracle數(shù)據(jù)庫存儲設(shè)備使用年限大幅延長

此次改造共將72張業(yè)務(wù)表和日志表約1039GB、8張圖片表約54TB數(shù)據(jù)，遷移到了分布式系統(tǒng)中，原Oracle數(shù)據(jù)庫存儲設(shè)備的剩余可用容量大幅提高，可用空間由14.3TB增加到32.2TB，業(yè)務(wù)庫存儲設(shè)備的讀寫帶寬壓力大幅下降，2021年6月1日至2022年1月10日，設(shè)備的讀IOPS由1720下降到1338。按照業(yè)務(wù)數(shù)據(jù)每年50%的增長率和當(dāng)前存儲設(shè)備的實際容量計算，在不增加投入的情況下，Oracle數(shù)據(jù)庫存儲設(shè)備的可使用年限還能延長至少三年。

5.2 平臺運(yùn)行監(jiān)控功能進(jìn)一步加強(qiáng)

改造后，綜合應(yīng)用平臺分布式服務(wù)、分布式系統(tǒng)和分布式關(guān)系型數(shù)據(jù)庫的調(diào)度管理和監(jiān)控預(yù)警都可以通過圖形可視化的方式進(jìn)行，綜合應(yīng)用平臺的運(yùn)行維護(hù)能力得到了進(jìn)一步加強(qiáng)。

5.3 綜合應(yīng)用平臺硬件基礎(chǔ)資源實現(xiàn)了跨越式升級

改造完成后，綜合應(yīng)用平臺硬件基礎(chǔ)資源實現(xiàn)了跨越式升級。平臺的HBase和MPPDB實際可用存儲容量分別達(dá)到了439TB和69TB，ES實際可用存儲容量達(dá)到了44TB，截至2021年12月底，HBase存儲使用率為12%，ES存儲使用率為3%，MPPDB存儲使用率為2.6%，預(yù)計可以滿足平臺在未來四年的非結(jié)構(gòu)化數(shù)據(jù)存儲需求。以5臺PC服務(wù)器組成的Hadoop管控節(jié)點服務(wù)，不僅能夠滿足綜合應(yīng)用平臺分布式系統(tǒng)管控需要，同時也基本能夠滿足省公安廳大數(shù)據(jù)云管中心硬件資源需求。

5.4 實現(xiàn)關(guān)鍵設(shè)施國產(chǎn)自主，信息安全可靠

平臺改造過程中采用的PC服務(wù)器、分布式關(guān)系型數(shù)據(jù)庫和相關(guān)接口服務(wù)均為國產(chǎn)自研，這在江西省公安交管大型信息系統(tǒng)建設(shè)歷程中屬于首次。這既符合國家相關(guān)信息安全要求，又能實現(xiàn)對原有數(shù)據(jù)庫大部分功能的替代，并且可以通過跨集群的分布式數(shù)據(jù)備份和數(shù)據(jù)容災(zāi)，保證數(shù)據(jù)存儲安全可靠。項目實施團(tuán)隊在實施過程中克服了大量兼容性適配問題，順利完成了安裝部署工作，整體運(yùn)行效果也基本達(dá)到了采用進(jìn)口芯片服務(wù)器能夠?qū)崿F(xiàn)的效果，為今后全面實現(xiàn)信息系統(tǒng)軟硬件國產(chǎn)化提供了寶貴經(jīng)驗。

6 后續(xù)管理措施

6.1 開展信息安全等級保護(hù)測評

綜合應(yīng)用平臺是網(wǎng)絡(luò)安全等級保護(hù)定級三級的信息系統(tǒng)，對網(wǎng)絡(luò)安全保障的要求非常嚴(yán)格。平臺自2014年進(jìn)行等級保護(hù)測評以來，歷經(jīng)多次軟硬件升級、機(jī)房搬遷，特別是這次大規(guī)模的改造后，平臺整體架構(gòu)、數(shù)據(jù)庫安全、網(wǎng)絡(luò)安全和運(yùn)行環(huán)境等內(nèi)容已經(jīng)發(fā)生了很大變化，按照網(wǎng)絡(luò)安全等級保護(hù)的要求，需要重新開展等級保護(hù)測評工作，找出系統(tǒng)運(yùn)行環(huán)境與國家技術(shù)標(biāo)準(zhǔn)要求之間的差距并加以改進(jìn)完善，形成嚴(yán)密的安全保護(hù)體系，為綜合應(yīng)用平臺的穩(wěn)定運(yùn)行提供有力安全保障。

6.2 進(jìn)行分布式系統(tǒng)異地容災(zāi)備份

綜合應(yīng)用平臺部署在江西省公安廳大數(shù)據(jù)中心機(jī)房。改造前，Oracle數(shù)據(jù)庫中的圖片庫和業(yè)務(wù)庫數(shù)據(jù)均實現(xiàn)了數(shù)據(jù)級的異地容災(zāi)備份。改造后，圖片庫和業(yè)務(wù)庫的日志數(shù)據(jù)遷移到了分布式系統(tǒng)中。隨著單寫分布式系統(tǒng)的圖片數(shù)據(jù)越來越多，缺少容災(zāi)備份是很大的信息安全隱患。為此，下一步擬結(jié)合公安交通管理非結(jié)構(gòu)化數(shù)據(jù)的特點，開展綜合應(yīng)用平臺異地容災(zāi)數(shù)據(jù)庫的升級，進(jìn)行分布式系統(tǒng)的異地容災(zāi)備份。

6.3 加強(qiáng)綜合應(yīng)用平臺運(yùn)維管理

綜合應(yīng)用平臺升級改造完成后，參與平臺運(yùn)維服務(wù)的技術(shù)團(tuán)隊進(jìn)一步增多，加強(qiáng)平臺的運(yùn)維管理顯得更加迫切。要按照部交管局《公安交通管理信息系統(tǒng)運(yùn)行管理規(guī)定》的總體要求，建立科技部門牽頭，駐場運(yùn)維保障單位負(fù)總責(zé)，各運(yùn)維團(tuán)隊分工負(fù)責(zé)的運(yùn)維保障機(jī)制，進(jìn)一步完善系統(tǒng)升級、日常巡檢、故障排查、安全巡查、應(yīng)急響應(yīng)和服務(wù)基層等各方面內(nèi)容，協(xié)調(diào)運(yùn)維管理工作整體高效運(yùn)轉(zhuǎn)。