電網(wǎng)大規(guī)模數(shù)據(jù)倉庫的數(shù)據(jù)接入研究與設(shè)計

李子乾 王樂之 張云志 張旭坤

1(國家電網(wǎng)公司客戶服務(wù)中心 天津 300000)2(南瑞集團(tuán)有限公司(國網(wǎng)電力科學(xué)研究院有限公司)江蘇瑞中數(shù)據(jù)股份有限公司 江蘇 南京 210000)

0 引 言

近年來，隨著售電側(cè)開放實施，電網(wǎng)業(yè)務(wù)得到迅速發(fā)展，相關(guān)的業(yè)務(wù)數(shù)據(jù)也呈現(xiàn)出了爆炸式的增長態(tài)勢。為了提升運營效益、增強(qiáng)電網(wǎng)安全、提高客戶服務(wù)質(zhì)量、拓展新業(yè)務(wù)，國家電網(wǎng)公司對數(shù)據(jù)的運營發(fā)展提出了更高要求[1-2]。

根據(jù)國家電網(wǎng)公司“十三五”規(guī)劃中“四全三化” 信息系統(tǒng)體系建設(shè)綱領(lǐng)，未來將建成“模型規(guī)范統(tǒng)一、數(shù)據(jù)干凈透明、分析靈活智能”的全業(yè)務(wù)統(tǒng)一數(shù)據(jù)平臺。國網(wǎng)客服中心(以下簡稱“中心”)作為供電服務(wù)業(yè)務(wù)的執(zhí)行單位和營銷決策的支撐機(jī)構(gòu)，積累了全網(wǎng)客戶數(shù)據(jù)和海量供電服務(wù)信息，并與電網(wǎng)營銷、生產(chǎn)、運行等業(yè)務(wù)緊密關(guān)聯(lián)，是整個電力系統(tǒng)中最為關(guān)鍵的一環(huán)。建設(shè)中心全業(yè)務(wù)統(tǒng)一數(shù)據(jù)平臺，即實現(xiàn)中心全業(yè)務(wù)范圍、全數(shù)據(jù)類型、全時間維度數(shù)據(jù)的統(tǒng)一存儲、管理和服務(wù)，為中心實現(xiàn)精準(zhǔn)營銷、精準(zhǔn)分析、精準(zhǔn)服務(wù)、智慧化服務(wù)等目標(biāo)提供數(shù)據(jù)保障，成為國網(wǎng)客服中心“十三五”信息化發(fā)展的重要目標(biāo)。

中心全業(yè)務(wù)統(tǒng)一數(shù)據(jù)平臺包含數(shù)據(jù)的集成、存儲、分析、處理、發(fā)布等環(huán)節(jié)。本文重點關(guān)注95598全業(yè)務(wù)數(shù)據(jù)集成環(huán)節(jié)，針對海量結(jié)構(gòu)化業(yè)務(wù)數(shù)據(jù)如何從原有業(yè)務(wù)系統(tǒng)有效地集成到大數(shù)據(jù)數(shù)據(jù)倉庫的問題，結(jié)合實際場景，提出了一種將數(shù)據(jù)同步復(fù)制、ETL等數(shù)據(jù)接入技術(shù)相結(jié)合的解決方案。該方案能夠滿足多種業(yè)務(wù)應(yīng)用需求，并保障數(shù)據(jù)接入過程中盡可能地減少對源端系統(tǒng)的影響。

1 業(yè)務(wù)數(shù)據(jù)類型分析

電網(wǎng)業(yè)務(wù)結(jié)構(gòu)化數(shù)據(jù)包括：工單類數(shù)據(jù)、檔案類數(shù)據(jù)、運營管理類數(shù)據(jù)、話務(wù)類數(shù)據(jù)、營銷類數(shù)據(jù)、常識類數(shù)據(jù)等。數(shù)據(jù)規(guī)模之海量在國內(nèi)外現(xiàn)有數(shù)據(jù)中心中尚數(shù)首例，對這些數(shù)據(jù)的整合極具挑戰(zhàn)和開創(chuàng)性。

將數(shù)據(jù)從源系統(tǒng)接入和存儲到數(shù)據(jù)倉庫的過程中，必須要保證數(shù)據(jù)的正確性和完整性，同時還需要保障數(shù)據(jù)進(jìn)入到新的環(huán)境中后能夠滿足所有業(yè)務(wù)的使用需求。此外從優(yōu)化存儲的角度應(yīng)當(dāng)具備除了冗余備份的需求以外，數(shù)據(jù)不應(yīng)該存在重復(fù)存儲。這就要求我們從存儲的角度對業(yè)務(wù)數(shù)據(jù)再進(jìn)行一次分類。

經(jīng)過對業(yè)務(wù)數(shù)據(jù)的全面調(diào)研與分析，結(jié)合數(shù)據(jù)接入與存儲的技術(shù)實現(xiàn)，我們將所有業(yè)務(wù)數(shù)據(jù)分為如下三大類：

1) 單純增長類 此類數(shù)據(jù)表只存在插入操作。數(shù)據(jù)一旦插入到數(shù)據(jù)庫中之后，將不會發(fā)生變更。此類表主要有：實時增長的話務(wù)表、定時增長的歸檔表、不定時增長或無增長的常量表。

2) 全更新類 此類數(shù)據(jù)表存在全部的增刪改操作。在插入和刪除方面，這些操作可能是實時的、定時的或不定時的，但在修改方面，只存在實時與不定時的修改，并不存在定時的修改操作。

3) 短期歸檔類 此類數(shù)據(jù)定時產(chǎn)生批量的增刪操作，無修改操作。以工單表為例，某一種業(yè)務(wù)工單的記錄表在存儲方面會分為三張表存儲：在線工單表，存在實時的插入、修改和定時的刪除操作，屬于全更新類；長期歸檔表，只存在定時的插入操作，屬于單純增長類；短期歸檔表，只存在定時插入和刪除操作，每天在線表中完成的工單記錄將從在線表中刪除并插入到短期歸檔表，同時短期歸檔表中超過時限的記錄將刪除并插入到長期歸檔表。

2 大數(shù)據(jù)存儲技術(shù)簡析

2.1 數(shù)據(jù)倉庫

數(shù)據(jù)倉庫主要用于處理復(fù)雜的分析計算，并且提供直觀易懂的查詢結(jié)果來支撐決策。在大數(shù)據(jù)領(lǐng)域，現(xiàn)有的兩大數(shù)據(jù)倉庫為大規(guī)模并行處理MPP(massive parallel process)與Hive。它們各有優(yōu)劣，適用于不同的場合。

MPP架構(gòu)的新型數(shù)據(jù)庫集群[3]，重點面向行業(yè)大數(shù)據(jù)，采用不共享架構(gòu)，擁有高效的分布式計算模式，每個節(jié)點運行自己的操作系統(tǒng)和數(shù)據(jù)庫。通過scan、sort和merge等操作符相對于使用MapReduce框架的Hive，能夠更加實時地返回查詢與計算結(jié)果。在企業(yè)BI分析、報表計算、查詢分析等分析類應(yīng)用領(lǐng)域有著極其廣泛的應(yīng)用[4]。

Hive相對于MPP在計算速度上存在劣勢，但它的優(yōu)勢在于所依托的Hadoop體系，適用于更加復(fù)雜的數(shù)據(jù)挖掘、機(jī)器學(xué)習(xí)和計算模型等應(yīng)用領(lǐng)域[5]。

綜上所述，MPP能夠更好地幫助企業(yè)回顧過去，而Hive能夠更好地幫助企業(yè)展望未來。在中心的全業(yè)務(wù)統(tǒng)一數(shù)據(jù)平臺中將同時使用這兩種數(shù)據(jù)倉庫。本文所研究和設(shè)計的也就是如何給出一個切實可行的方式，將原有業(yè)務(wù)系統(tǒng)關(guān)系庫中的海量結(jié)構(gòu)化業(yè)務(wù)數(shù)據(jù)高效地接入這兩個數(shù)據(jù)倉庫中。

2.2 關(guān)系數(shù)據(jù)庫

關(guān)系數(shù)據(jù)庫主要用于基本的、日常的事務(wù)處理。在大數(shù)據(jù)體系架構(gòu)中，當(dāng)前主要使用的關(guān)系數(shù)據(jù)庫為Mysql與Postgresql。

Postgresql與Oracle的存儲架構(gòu)最為接近，從Oracle將數(shù)據(jù)遷移到Postgresql中的成本很低[6]。但隨著Mysql版本的不斷提升，Mysql在互聯(lián)網(wǎng)行業(yè)積累了大量的高可用架構(gòu)、分布式架構(gòu)與災(zāi)備經(jīng)驗[7]，其集群模式在功能性與性能方面都已經(jīng)超過了Postgresql，并能夠與Oracle分庭抗禮。當(dāng)前企業(yè)的關(guān)系數(shù)據(jù)庫集群越來越青睞使用Mysql存儲事務(wù)用業(yè)務(wù)數(shù)據(jù)。

然而Mysql在高并發(fā)讀寫方面仍然存在一定的瓶頸，當(dāng)數(shù)據(jù)量很大時Mysql的查詢效率會變得很低，這也使得Mysql不適用于存儲與查詢大規(guī)模的業(yè)務(wù)數(shù)據(jù)。在中心的全業(yè)務(wù)統(tǒng)一數(shù)據(jù)平臺的設(shè)計中，Mysql僅存儲短期業(yè)務(wù)數(shù)據(jù)，用來支撐一些在線事務(wù)類業(yè)務(wù)應(yīng)用。在此設(shè)計下，Mysql實際上也可以看作是一個緩存了近期數(shù)據(jù)的緩存庫，我們考慮在將數(shù)據(jù)接入數(shù)據(jù)倉庫的過程中，利用Mysql提供一些支撐。

3 復(fù)合式數(shù)據(jù)接入設(shè)計

3.1 系統(tǒng)架構(gòu)概況

在國網(wǎng)客服中心全業(yè)務(wù)統(tǒng)一數(shù)據(jù)平臺的建設(shè)中，需要接入的數(shù)據(jù)源端為生產(chǎn)環(huán)境中的多個Oracle集群。每個集群分別屬于不同的系統(tǒng)，每個系統(tǒng)與多個業(yè)務(wù)緊密關(guān)聯(lián)，支撐著電網(wǎng)營銷、生產(chǎn)、運行中的各個環(huán)節(jié)，其安全性要求極高。從源端數(shù)據(jù)庫獲取數(shù)據(jù)時應(yīng)保障對源端的影響最小，不能造成源端數(shù)據(jù)庫運行緩慢，不能影響正常的業(yè)務(wù)生產(chǎn)。

數(shù)據(jù)接入的目標(biāo)端為大數(shù)據(jù)集群。該大數(shù)據(jù)集群為廣義上的大數(shù)據(jù)存儲、處理與分析集群，包括Hadoop體系、MPP數(shù)據(jù)倉庫、關(guān)系數(shù)據(jù)庫以及相關(guān)的計算分析組件和數(shù)據(jù)流轉(zhuǎn)組件。本文重點考慮的需要接入數(shù)據(jù)倉庫的數(shù)據(jù)為各系統(tǒng)全量結(jié)構(gòu)化業(yè)務(wù)數(shù)據(jù)。數(shù)據(jù)存入大數(shù)據(jù)集群后，需要能夠同時支撐事務(wù)查詢、BI分析、報表計算、查詢分析、數(shù)據(jù)挖掘、業(yè)務(wù)預(yù)測等多種業(yè)務(wù)應(yīng)用。這些數(shù)據(jù)具有表數(shù)量多、種類復(fù)雜、表中數(shù)據(jù)量大等特點。其中表數(shù)據(jù)的種類已經(jīng)在第2節(jié)中作了闡述。在表數(shù)據(jù)量方面，約有4 000多張。在表數(shù)據(jù)量方面，單表中的數(shù)據(jù)量可達(dá)到8億左右，總表數(shù)據(jù)量為PB級別。

此外，源端數(shù)據(jù)庫與大數(shù)據(jù)集群為異地部署，數(shù)據(jù)傳輸方面受到距離的影響，存在一定的延遲。

3.2 數(shù)據(jù)接入方式分析

參照中心業(yè)務(wù)需求的不同，目前數(shù)據(jù)接入的方式主要有：ETL(Extract-Transform-Load)方式、數(shù)據(jù)庫同步復(fù)制方式、文件導(dǎo)出導(dǎo)入方式。

3.2.1 ETL方式

ETL即數(shù)據(jù)抽取、轉(zhuǎn)換、加載方式[8]。首先在數(shù)據(jù)抽取階段將數(shù)據(jù)從源端讀取出來，該過程使用源端數(shù)據(jù)庫適用的讀取方式進(jìn)行讀取，就目前常用的Oracle、Mysql等結(jié)構(gòu)化數(shù)據(jù)庫，通常采用jdbc方式進(jìn)行讀取。數(shù)據(jù)讀取出來后，在數(shù)據(jù)轉(zhuǎn)換階段會將源端數(shù)據(jù)經(jīng)過適當(dāng)?shù)募庸づc轉(zhuǎn)換，使得數(shù)據(jù)滿足目標(biāo)端的存儲需求，最終在數(shù)據(jù)加載階段將處理好的數(shù)據(jù)加載到目標(biāo)端數(shù)據(jù)庫。

中心的源數(shù)據(jù)庫為Oracle，采用ETL方式進(jìn)行數(shù)據(jù)接入時采用的是jdbc連接。然而異地數(shù)據(jù)傳輸所產(chǎn)生的延遲對于jdbc連接訪問會造成較大影響，當(dāng)延遲過大時jdbc連接會因超時而斷開。因此，在中心異地數(shù)據(jù)系統(tǒng)之間若采用基于jdbc方式讀取數(shù)據(jù)，會存在不穩(wěn)定問題。另一方面，ETL本身不具備實時數(shù)據(jù)抽取的功能，這一特點也是在本文所考慮的數(shù)據(jù)接入方案中需要注意的。

3.2.2 數(shù)據(jù)庫同步復(fù)制方式

同步復(fù)制方式即實現(xiàn)數(shù)據(jù)在兩個數(shù)據(jù)節(jié)點之間實時地保持一致的一種數(shù)據(jù)備份復(fù)制方式。目前在Oracle數(shù)據(jù)庫集群環(huán)境中被廣泛使用的同步復(fù)制軟件為OGG(Oracle Golden Gate)。而對于異構(gòu)數(shù)據(jù)庫系統(tǒng)，OGG同樣能夠發(fā)揮其作用，實現(xiàn)大量數(shù)據(jù)亞秒級別的實時復(fù)制，且可以實現(xiàn)一對一、一對多、多對一、雙向、點對點、級聯(lián)等多種靈活的拓?fù)浣Y(jié)構(gòu)[9-11]。

采用同步復(fù)制方式能夠保證中心全業(yè)務(wù)數(shù)據(jù)接入大數(shù)據(jù)集群后能夠與數(shù)據(jù)源實時保持一致。然而其存在的問題在于大數(shù)據(jù)量初始化時會存在一定的困難。初始化時間將會比較長，此時間內(nèi)會對數(shù)據(jù)庫形成持續(xù)的訪問壓力，且一旦初始化過程中因網(wǎng)絡(luò)或設(shè)備等原因造成了中斷，則意味著所有數(shù)據(jù)要重新進(jìn)行初始化。此外，OGG方式僅支持關(guān)系數(shù)據(jù)庫之間的數(shù)據(jù)同步，無法做到與數(shù)據(jù)倉庫之間建立數(shù)據(jù)同步。

3.2.3 文件導(dǎo)出導(dǎo)入方式

文件導(dǎo)出導(dǎo)入方式即先將源端數(shù)據(jù)以文件形式從數(shù)據(jù)庫導(dǎo)出，再通過FTP等文件傳輸方式傳輸?shù)侥繕?biāo)端，再在目標(biāo)端將文件導(dǎo)入到數(shù)據(jù)庫中。

該方式適用于大批量數(shù)據(jù)一次性從一個數(shù)據(jù)庫快速復(fù)制到另一個數(shù)據(jù)庫中。但該復(fù)制過程是異步的，無法保障源端與目標(biāo)端實時保持一致，且跨系統(tǒng)之間的文件導(dǎo)出導(dǎo)入過程中需要人工參與，同時做好敏感信息的保密工作。

3.3 存量數(shù)據(jù)接入設(shè)計

存量數(shù)據(jù)只需要一次性接入?？紤]到其存量巨大，若直接采用ETL方式，則效率太低且異地數(shù)據(jù)傳輸時穩(wěn)定性差。因此，我們選擇將存量數(shù)據(jù)先采用文件形式從源端導(dǎo)出，再導(dǎo)入數(shù)據(jù)倉庫所在本地系統(tǒng)。由于源端與目標(biāo)端為異構(gòu)數(shù)據(jù)庫，且依據(jù)生產(chǎn)環(huán)境的運行規(guī)定，源端只允許導(dǎo)出dmp文件，因此需要在數(shù)據(jù)倉庫本地部署一個小型的Oracle數(shù)據(jù)庫作為數(shù)據(jù)中轉(zhuǎn)站。將源端導(dǎo)出的dmp文件導(dǎo)入此Oracle中，然后再使用ETL方式從此Oracle將全量數(shù)據(jù)抽取到數(shù)據(jù)倉庫。整個過程如圖1所示。

圖1 存量數(shù)據(jù)接入示意圖

存量數(shù)據(jù)接入的全過程總結(jié)如下：

1) 源端業(yè)務(wù)系統(tǒng)將所需接入的表導(dǎo)出為dmp文件，同時記錄存量數(shù)據(jù)范圍，作為區(qū)分存量數(shù)據(jù)與增量數(shù)據(jù)的依據(jù)。

2) 將導(dǎo)出的dmp文件通過文件傳輸方式發(fā)送到目標(biāo)端中轉(zhuǎn)數(shù)據(jù)庫所在服務(wù)器。

3) 將dmp文件導(dǎo)入目標(biāo)端中轉(zhuǎn)數(shù)據(jù)庫。

4) 使用ETL方式將目標(biāo)端中轉(zhuǎn)數(shù)據(jù)庫中的數(shù)據(jù)導(dǎo)入MPP數(shù)據(jù)倉庫。

5) 導(dǎo)入成功完成后刪除中轉(zhuǎn)數(shù)據(jù)庫中的數(shù)據(jù)。

6) 重復(fù)1)～5)的步驟直至完成所有表存量數(shù)據(jù)的接入。

3.4 增量數(shù)據(jù)接入設(shè)計

增量數(shù)據(jù)的接入需要考慮接入的頻率。對于事務(wù)型查詢的需求，數(shù)據(jù)要求是實時或準(zhǔn)實時(分鐘級)的，但查詢的數(shù)據(jù)時間范圍較小，通常不超過1年。對于BI分析、報表計算、查詢分析、數(shù)據(jù)挖掘、業(yè)務(wù)預(yù)測等離線計算的場景，則只要增量數(shù)據(jù)滿足離線計算的計算間隔即可，通常這個時間間隔按天或者按月計算，但查詢的數(shù)據(jù)時間范圍較大，最大可以達(dá)到全量級別。

鑒于這樣的數(shù)據(jù)訪問需求，我們使用Mysql作為增量數(shù)據(jù)接入MPP數(shù)據(jù)倉庫前的緩存數(shù)據(jù)庫，在此Mysql中緩存1年的數(shù)據(jù)以同時支撐事務(wù)型查詢的需求。為了滿足數(shù)據(jù)實時性的要求，我們采用OGG方式將數(shù)據(jù)從Oracle同步到Mysql，然后再用ETL方式根據(jù)離線計算場景的最小時間間隔將增量數(shù)據(jù)從Mysql抽取到MPP數(shù)據(jù)倉庫中。

由于OGG方式要求源端與目標(biāo)端數(shù)據(jù)表應(yīng)保持一致，而我們在Mysql中不會存儲與源端Oracle中相同的全量數(shù)據(jù)，因此OGG過程中需要對目標(biāo)端做一些額外的處理。

我們通過OGG把日志解析成只有insert操作的日志，并在目標(biāo)端數(shù)據(jù)表增加增刪改的標(biāo)識字段(增標(biāo)識：i，改標(biāo)識：u，刪標(biāo)識：d)，同時添加時間戳字段。

示例如下：

1) 用戶刪除一行記錄，則把該被刪除的行寫入到目標(biāo)端的Mysql表中，更新該記錄增刪改標(biāo)識為‘d’，同時更新該記錄變更的時間戳。

2) 用戶修改一行記錄，則把修改后的記錄寫入到目標(biāo)端的Mysql表中，更新該記錄的最新值，更新增刪改標(biāo)識為‘u’，同時更新該記錄變更的時間戳。

3) 用戶插入一條記錄，則把該行記錄寫入到目標(biāo)端的Mysql表中，新增記錄并在該記錄添加增刪改標(biāo)識為‘i’，同時添加記錄被插入到數(shù)據(jù)庫的時間戳。

只有OGG同步復(fù)制過程中能夠從歸檔日志中讀取到的數(shù)據(jù)，才可以添加到增加的字段中。本設(shè)計方案中，增刪改標(biāo)識和時間戳均可以從歸檔日志中獲取，因此增加這兩個字段是可行的。增加字段的示意圖如圖2所示。

圖2 OGG過程中增加字段示意圖

該同步復(fù)制策略的特點如下：

1) 目標(biāo)端Mysql可以只保存近期一段時間內(nèi)的數(shù)據(jù)，不用緩存全量數(shù)據(jù)。

2) OGG在做update和delete操作時不會因為目標(biāo)端缺少數(shù)據(jù)報錯。

3) 不需要做源業(yè)務(wù)系統(tǒng)到mysql數(shù)據(jù)庫的數(shù)據(jù)初始化工作，即mysql中不需要存儲源業(yè)務(wù)系統(tǒng)的歷史數(shù)據(jù)。

增量數(shù)據(jù)進(jìn)入到Mysql中后，將數(shù)據(jù)通過ETL方式做簡單的清洗轉(zhuǎn)換即可很方便地將數(shù)據(jù)抽取到MPP數(shù)據(jù)倉庫中。該清洗轉(zhuǎn)換的核心工作在于將Mysql中的數(shù)據(jù)解析后在MPP數(shù)據(jù)倉庫中進(jìn)行數(shù)據(jù)更新。該過程具體設(shè)計如下：

1) 針對每一張表，逐行讀取抽取區(qū)間(依據(jù)每次ETL抽取的時間間隔所選定的時間區(qū)間)內(nèi)的每條記錄。

2) 對于增刪改標(biāo)記為‘i’的記錄，將其解析為在MPP數(shù)據(jù)倉庫中可執(zhí)行的一條insert語句。

3) 對于增刪改標(biāo)記為‘u’的記錄，將其解析為在MPP數(shù)據(jù)倉庫中可執(zhí)行的一條delete語句和一條insert語句。

4) 對于增刪改標(biāo)記為‘d’的記錄，將其解析為在MPP數(shù)據(jù)倉庫中可執(zhí)行的一條delete語句。

5) 將每條解析后的語句按順序在MPP數(shù)據(jù)倉庫中執(zhí)行，從而完成數(shù)據(jù)更新。

由于數(shù)據(jù)通過OGG方式同步復(fù)制到Mysql的時候，所有數(shù)據(jù)庫操作已經(jīng)是按時間戳逐行插入的，從而在逐行解析過程中并不需要進(jìn)行額外的排序工作。

整個增量數(shù)據(jù)接入過程如圖3所示。

圖3 增量數(shù)據(jù)接入示意圖

增量數(shù)據(jù)接入的全過程總結(jié)如下：

1) 通過OGG方式將源端Oracle中數(shù)據(jù)同步復(fù)制到Mysql中，OGG過程中添加增刪改標(biāo)識、時間戳字段。

2) 定期通過ETL方式將數(shù)據(jù)解析轉(zhuǎn)換后存入MPP數(shù)據(jù)倉庫。

3.5 Hive中數(shù)據(jù)的接入

針對數(shù)據(jù)挖掘、業(yè)務(wù)預(yù)測等業(yè)務(wù)場景，需要將數(shù)據(jù)接入到Hive中進(jìn)行計算。Hive中只需要存儲計算需要用到的數(shù)據(jù)。根據(jù)業(yè)務(wù)需求在MPP數(shù)據(jù)倉庫中對全量業(yè)務(wù)數(shù)據(jù)進(jìn)行輕度匯總和重度匯總形成若干數(shù)據(jù)集市后，無論存量數(shù)據(jù)還是增量數(shù)據(jù)，都采用ETL方式(例如sqoop等)將數(shù)據(jù)分批接入Hive中即可[11]。

4 實驗與驗證

本方案的核心和瓶頸在于3.4節(jié)的增量數(shù)據(jù)接入部分，因此本次實驗針對增量數(shù)據(jù)接入場景搭建環(huán)境并進(jìn)行了實驗。環(huán)境中中包含一個Oracle集群、一個Mysql集群、一個MPP數(shù)據(jù)倉庫集群和一個Hive集群。各集群概況如表1所示。

表1 增量數(shù)據(jù)接入實驗環(huán)境

在Oracle向Mysql數(shù)據(jù)庫進(jìn)行數(shù)據(jù)同步時觀測各類型數(shù)據(jù)量、源端與目標(biāo)端服務(wù)器性能數(shù)值如表2所示。

表2 Oracle向Mysql數(shù)據(jù)同步實驗結(jié)果

在Mysql向MPP數(shù)據(jù)倉庫解析接入時觀測各類型數(shù)據(jù)量、源端與目標(biāo)端服務(wù)器性能數(shù)值如表3所示。

表3 Mysql向MPP解析接入實驗結(jié)果

綜合上述實驗結(jié)果，數(shù)據(jù)能夠高效而準(zhǔn)確地同步且對源端和目標(biāo)端服務(wù)器性能影響較小，滿足中心信息系統(tǒng)實時業(yè)務(wù)響應(yīng)速度需求和安全運行需求。

5 結(jié) 語

在信息發(fā)展速度越來越快的今天，傳統(tǒng)數(shù)據(jù)庫架構(gòu)已經(jīng)越發(fā)難以滿足更加復(fù)雜、更加多樣化的業(yè)務(wù)需求，包括電網(wǎng)在內(nèi)的各大行業(yè)正在積極開展傳統(tǒng)數(shù)據(jù)庫架構(gòu)向大數(shù)據(jù)技術(shù)下數(shù)據(jù)架構(gòu)的轉(zhuǎn)型工作。其中一大重點和難點在于如何有效實現(xiàn)從傳統(tǒng)數(shù)據(jù)庫向大數(shù)據(jù)技術(shù)下數(shù)據(jù)存儲載體進(jìn)行的數(shù)據(jù)遷移。在這方面，數(shù)量最多需求最大的就是結(jié)構(gòu)化數(shù)據(jù)從傳統(tǒng)數(shù)據(jù)庫向大數(shù)據(jù)數(shù)據(jù)倉庫遷移的問題。

本文分析了國網(wǎng)客服中心在建設(shè)全業(yè)務(wù)統(tǒng)一數(shù)據(jù)平臺過程中的數(shù)據(jù)與業(yè)務(wù)需求。結(jié)合現(xiàn)有系統(tǒng)的客觀條件，提出了ETL、同步復(fù)制、文件導(dǎo)出導(dǎo)入相結(jié)合的復(fù)合式數(shù)據(jù)接入設(shè)計方案。經(jīng)過實驗驗證，該方案能夠有效實現(xiàn)異構(gòu)數(shù)據(jù)庫之間的數(shù)據(jù)流轉(zhuǎn)，且在存量數(shù)據(jù)接入和增量數(shù)據(jù)接入兩個環(huán)節(jié)均能將對源端生產(chǎn)系統(tǒng)造成的壓力降至最低。同時通過Mysql關(guān)系數(shù)據(jù)庫、MPP數(shù)據(jù)倉庫和Hive相結(jié)合的方式滿足事務(wù)查詢、BI分析、報表計算、查詢分析、數(shù)據(jù)挖掘、業(yè)務(wù)預(yù)測等多種業(yè)務(wù)應(yīng)用。本文方案是一種切實可行且具有較高應(yīng)用價值的數(shù)據(jù)接入方案。