數(shù)字化轉(zhuǎn)型的核心就是要充分發(fā)掘數(shù)據(jù)的價值，而這對應(yīng)著兩條非常明確的實(shí)現(xiàn)路徑。其中之一，是對數(shù)據(jù)的產(chǎn)生和變化進(jìn)行即時響應(yīng)，通過提高業(yè)務(wù)及數(shù)據(jù)實(shí)時性的方法來打造敏捷、靈活的數(shù)字化企業(yè)；而另一條路徑則是發(fā)掘存量數(shù)據(jù)的價值，通過對海量數(shù)據(jù)的分析找出不斷變化的趨勢，為企業(yè)提供更高層次的洞察。

兩條路徑的啟點(diǎn)雖然都是數(shù)據(jù)，但在啟點(diǎn)之后的數(shù)據(jù)庫應(yīng)用中卻會走上不同路徑。前者對應(yīng)了頻繁的寫操作，后者則對應(yīng)了大量的讀操作。而這也正是OLTP和OLAP的分水嶺。所謂數(shù)字化轉(zhuǎn)型，二者缺一不可。

作為企業(yè)數(shù)據(jù)庫領(lǐng)域的新晉選手，GaussDB在今年初正式發(fā)布之后可謂賺足了眼球。憑借全自研和分布式的特性，GaussDB一經(jīng)推出便受到了各方注意和爭相報(bào)道。

當(dāng)然，作為面向企業(yè)核心應(yīng)用的數(shù)據(jù)庫產(chǎn)品，推出和應(yīng)用完全是兩回事，更何況是在Oracle等產(chǎn)品已經(jīng)占據(jù)市場相當(dāng)久的情況下，要上馬一款關(guān)乎核心應(yīng)用的新數(shù)據(jù)庫，企業(yè)和華為要考慮的事情還有很多。

廣東是國內(nèi)當(dāng)之無愧的人口與經(jīng)濟(jì)第一大省，無論面對10萬億規(guī)模的GDP還是面對超過1億的常住人口，通訊服務(wù)都是必須保障的基礎(chǔ)服務(wù)。作為廣東省運(yùn)營商市場的絕對主力，2019年6月，廣東移動服務(wù)的用戶總數(shù)已超過1.4億。海量的用戶規(guī)模既意味著巨大的收入，也同時意味著巨大的數(shù)據(jù)挑戰(zhàn)。

業(yè)務(wù)運(yùn)營支持系統(tǒng)，簡稱BOSS系統(tǒng)，在運(yùn)營商應(yīng)用中負(fù)責(zé)記錄用戶的通話詳單，是業(yè)務(wù)中基石的基石，是企業(yè)對用戶收費(fèi)和開展各類高級業(yè)務(wù)的依據(jù)，重要性不言而喻。面對行業(yè)監(jiān)管的硬性規(guī)定，太快刪除這些數(shù)據(jù)是不可能的；面對數(shù)字化轉(zhuǎn)型的壓力，想要把這些數(shù)據(jù)移出主數(shù)據(jù)庫、歸檔到磁帶等冷存儲上也是不可取的。

但現(xiàn)實(shí)的情況卻是，這套目前服務(wù)于1.4億用戶的BOSS系統(tǒng)每月都會產(chǎn)生30TB的增量數(shù)據(jù)。目前，BOSS系統(tǒng)的Oracle數(shù)據(jù)庫中已經(jīng)存儲了150TB數(shù)據(jù)，而承擔(dān)存儲任務(wù)的EMC核心存儲系統(tǒng)的容量上限為200TB……

如果以“數(shù)據(jù)即是財(cái)富”的角度來看，廣東移動每月30TB的新增數(shù)據(jù)和海量的庫存數(shù)據(jù)無疑是座巨大的金礦；但現(xiàn)時的難題卻是負(fù)責(zé)存儲這一數(shù)據(jù)庫的EMC核心存儲已經(jīng)在容量上捉襟見肘，節(jié)點(diǎn)內(nèi)的擴(kuò)展能力早已完全枯竭。

一方面是不斷積累的寶貴用戶數(shù)據(jù)，另一方面則是接近極限的存儲能力；這就相當(dāng)于出海打漁卻發(fā)現(xiàn)船艙太小，廣東移動的心情可想而知。

放在過去，廣東移動似乎除了將存不下的數(shù)據(jù)遷到冷存儲上之外，只剩下?lián)Q裝核心存儲系統(tǒng)這一條路可走了；但這僅剩的選擇也同樣意味著極高的成本和眾多不可預(yù)知的風(fēng)險。不過，隨著數(shù)據(jù)庫技術(shù)的進(jìn)步，華為卻為廣州移動提出了全新的解決思路。

在不替換現(xiàn)有數(shù)據(jù)庫和存儲系統(tǒng)的前提下再接入一套分布式數(shù)據(jù)庫，兩套數(shù)據(jù)庫均通過JDBC（Java Database Connectivity）與上層的BOSS系統(tǒng)及其他業(yè)務(wù)系統(tǒng)相連。這樣，通過定期將Oracle主數(shù)據(jù)庫在EMC核心存儲中的數(shù)據(jù)遷移到分布式數(shù)據(jù)庫上就能在不對核心數(shù)據(jù)庫及存儲進(jìn)行大改的前提下實(shí)現(xiàn)對數(shù)據(jù)庫的擴(kuò)容。

從這一升級思路中，我們不難看出，其中的關(guān)鍵點(diǎn)在于承擔(dān)擴(kuò)展任務(wù)的分布式數(shù)據(jù)庫不僅要具備能夠滿足未來數(shù)據(jù)需求的擴(kuò)展能力，更要擁有足夠的可靠性來承載業(yè)務(wù)核心數(shù)據(jù)。當(dāng)然，最關(guān)鍵的是，數(shù)據(jù)要足夠安全，遷移要又快又穩(wěn)。

在這其中扮演關(guān)鍵角色的分布式數(shù)據(jù)庫正是站在聚光燈下的華為GaussDB。

目前，GaussDB有兩個版本，分別對應(yīng)OLTP和OLAP應(yīng)用。仔細(xì)判斷廣東移動對遷移數(shù)據(jù)的需求，我們不難發(fā)現(xiàn)，需要遷移的數(shù)據(jù)并非近幾月產(chǎn)生的最新數(shù)據(jù)，而是數(shù)月之前的數(shù)據(jù)。這些數(shù)據(jù)已經(jīng)不會再進(jìn)行頻繁的修改操作，反倒是對于總結(jié)業(yè)務(wù)在季度/半年/全年當(dāng)中的變化趨勢仍有不小幫助，查詢需求大于修改需求。因此，GaussDB OLAP是最適合的選擇。

作為一款分布式數(shù)據(jù)庫，GaussDB OLAP由負(fù)責(zé)響應(yīng)SQL任務(wù)的Coordinator Node（CN節(jié)點(diǎn)）和負(fù)責(zé)存儲數(shù)據(jù)的Data Node（DN節(jié)點(diǎn)）共同組成，CN節(jié)點(diǎn)和DN節(jié)點(diǎn)均可自由擴(kuò)展，理論上限達(dá)到2048個，以實(shí)現(xiàn)更好的訪問性能和存儲性能及容量。由此，相互解耦的CN與DN節(jié)點(diǎn)便相對輕松的實(shí)現(xiàn)了數(shù)據(jù)庫與存儲容量的橫向擴(kuò)展。這是解決Oracle+EMC組合缺乏擴(kuò)展能力問題的關(guān)鍵。

同樣是通過這種多個CN節(jié)點(diǎn)對多個DN節(jié)點(diǎn)的形式，GaussDB OLAP能夠?qū)崿F(xiàn)更好的并發(fā)查詢、讀取性能，為日后的大規(guī)模數(shù)據(jù)分析提供了很好的性能保障。

另一方面， GaussDB OLAP也通過集群內(nèi)冗余的方式解決了數(shù)據(jù)庫服務(wù)及數(shù)據(jù)存儲的可靠性問題。在整套系統(tǒng)中每個CN節(jié)點(diǎn)均可訪問全部DN節(jié)點(diǎn)，因此，只要還有一個CN節(jié)點(diǎn)在線，整個數(shù)據(jù)庫就處于可用狀態(tài)。另一方面，由于采用了DN節(jié)點(diǎn)中HDFS文件系統(tǒng)，數(shù)據(jù)也通過分布式和冗余的方式保障了整體的可靠性。

在項(xiàng)目實(shí)施過程中，華為為廣東移動配置了由3個CN節(jié)點(diǎn)和12個DN節(jié)點(diǎn)的GaussDB OLAP集群，并通過GDS（Gauss Data Service）工具完成了第一期431GB數(shù)據(jù)的遷移。這431GB數(shù)據(jù)遷移共耗時502.6秒，傳輸速度達(dá)到了驚人的879.74MB/s。作為對比，廣東移動在從一個Oracle數(shù)據(jù)庫向另一個Oracle數(shù)據(jù)庫導(dǎo)入數(shù)據(jù)時，速度從來沒有超過10MB/s。

當(dāng)然，不同品類數(shù)據(jù)庫的數(shù)據(jù)遷移過程中不發(fā)生問題幾乎是不可能的。在廣東移動上馬GaussDB OLAP的數(shù)據(jù)遷移過程中，雖然配套的GDS工具能夠提供非?？斓膫鬏斔黉洠@一工具卻無法完成對blob字段（大體積的非結(jié)構(gòu)化字段）的遷移工作。

發(fā)生問題不可怕，找不到解決問題的人才可怕。在遇到問題之后，華為工程團(tuán)隊(duì)立即投入戰(zhàn)斗。經(jīng)過摸索，華為工程團(tuán)隊(duì)發(fā)現(xiàn)Oracle在針對醫(yī)療領(lǐng)域的解決方案中提供了一款專門針對大體積非結(jié)構(gòu)化字段的數(shù)據(jù)遷移工具HDR（Oracle Healthcare Data Repository），利用這款工具，團(tuán)隊(duì)完美的解決了blob字段的遷移工作，項(xiàng)目得以順利進(jìn)行。

任何數(shù)據(jù)庫的換裝和遷移，核心目的都不是數(shù)據(jù)庫本身，而是要為上層應(yīng)用提供數(shù)據(jù)服務(wù)，廣東移動的GaussDB項(xiàng)目同樣如此。換裝之后，廣東移動的BOSS系統(tǒng)要對接兩套數(shù)據(jù)庫，這必然涉及到業(yè)務(wù)邏輯和操作代碼的變更與轉(zhuǎn)換。這個問題不解決，后期必然會伴隨大量的業(yè)務(wù)人員重新培訓(xùn)成本。

為此，廣東移動團(tuán)隊(duì)仔細(xì)梳理了整個BOSS系統(tǒng)的業(yè)務(wù)邏輯和每一個數(shù)據(jù)庫接口，找到了新舊數(shù)據(jù)庫在語法和接口上的數(shù)百個不同點(diǎn)，為GaussDB上線后的調(diào)整及修改確立了方向。而在修改之后，GaussDB也終于做到無論在接口還是語法層面都與原系統(tǒng)如出一轍，真正做到了業(yè)務(wù)層面對底層變化的無感。

可以說，除了GaussDB本身的眾多先進(jìn)特性之外，廣東移動和華為團(tuán)隊(duì)的無間合作同樣是項(xiàng)目成功實(shí)施的核心保障。

數(shù)據(jù)是企業(yè)數(shù)字化轉(zhuǎn)型過程中的核心驅(qū)動力，是企業(yè)在數(shù)字時代的核心資產(chǎn)。與所有其他資產(chǎn)一樣，數(shù)據(jù)本身也有著自己的生命周期，因此，讓處在生命周期不同階段的數(shù)據(jù)正確發(fā)揮自身的價值也就成了完成數(shù)字化轉(zhuǎn)型的前提。

對于廣東移動們來說，在上個時代構(gòu)建的核心數(shù)據(jù)庫及存儲系統(tǒng)往往面臨著性能夠用但空間捉襟見肘的現(xiàn)實(shí)困境。這一困境使得企業(yè)不得不在一個兩難局面之間進(jìn)行選擇：要么花費(fèi)大量金錢并冒著巨大風(fēng)險對原有存儲系統(tǒng)進(jìn)行升級或橫向擴(kuò)展；要么把那些還有分析價值的數(shù)據(jù)導(dǎo)出來，直接打入冷存儲的廣寒宮。前者是對業(yè)務(wù)的不負(fù)責(zé)，后者是對數(shù)據(jù)的不負(fù)責(zé)，都是數(shù)字化轉(zhuǎn)型中的大“罪過”。

數(shù)據(jù)庫擴(kuò)容并不是新問題，市面上的解決方案也絕非GaussDB一種。而之所以廣東移動要選擇初出茅廬的華為GaussDB，一方面是源于GaussDB強(qiáng)大的擴(kuò)展能力及新穎的方案；另一方面則是因?yàn)樯蠈拥腂OSS系統(tǒng)本身就是華為軟件團(tuán)隊(duì)的作品，把這個項(xiàng)目交給一群既懂應(yīng)用又懂?dāng)?shù)據(jù)庫的人，顯然是更靠譜的選擇。而在之后的方案選型及推進(jìn)過程中，廣東移動團(tuán)隊(duì)也與華為緊密協(xié)作，論證了方案的可行性并制定了詳細(xì)規(guī)劃，最終推動方案成型。

目前，廣東移動正在就新數(shù)據(jù)庫與業(yè)務(wù)系統(tǒng)的兼容性進(jìn)行細(xì)致測試，確保業(yè)務(wù)在穩(wěn)定可靠的前提下滿足擴(kuò)展性與性能的需求。

兩個團(tuán)隊(duì)，一個初心；廣東移動與GaussDB未來想必還會有更多關(guān)于數(shù)字化轉(zhuǎn)型的精彩故事。