電網大規模數據倉庫的數據接入研究與設計

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

1(國家電網公司客戶服務中心 天津 300000)2(南瑞集團有限公司(國網電力科學研究院有限公司)江蘇瑞中數據股份有限公司 江蘇 南京 210000)

0 引 言

近年來，隨著售電側開放實施，電網業務得到迅速發展，相關的業務數據也呈現出了爆炸式的增長態勢。為了提升運營效益、增強電網安全、提高客戶服務質量、拓展新業務，國家電網公司對數據的運營發展提出了更高要求[1-2]。

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

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

1 業務數據類型分析

電網業務結構化數據包括：工單類數據、檔案類數據、運營管理類數據、話務類數據、營銷類數據、常識類數據等。數據規模之海量在國內外現有數據中心中尚數首例，對這些數據的整合極具挑戰和開創性。

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

經過對業務數據的全面調研與分析，結合數據接入與存儲的技術實現，我們將所有業務數據分為如下三大類：

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

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

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

2 大數據存儲技術簡析

2.1 數據倉庫

數據倉庫主要用于處理復雜的分析計算，并且提供直觀易懂的查詢結果來支撐決策。在大數據領域，現有的兩大數據倉庫為大規模并行處理MPP(massive parallel process)與Hive。它們各有優劣，適用于不同的場合。

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

Hive相對于MPP在計算速度上存在劣勢，但它的優勢在于所依托的Hadoop體系，適用于更加復雜的數據挖掘、機器學習和計算模型等應用領域[5]。

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

2.2 關系數據庫

關系數據庫主要用于基本的、日常的事務處理。在大數據體系架構中，當前主要使用的關系數據庫為Mysql與Postgresql。

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

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

3 復合式數據接入設計

3.1 系統架構概況

在國網客服中心全業務統一數據平臺的建設中，需要接入的數據源端為生產環境中的多個Oracle集群。每個集群分別屬于不同的系統，每個系統與多個業務緊密關聯，支撐著電網營銷、生產、運行中的各個環節，其安全性要求極高。從源端數據庫獲取數據時應保障對源端的影響最小，不能造成源端數據庫運行緩慢，不能影響正常的業務生產。

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

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

3.2 數據接入方式分析

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

3.2.1 ETL方式

ETL即數據抽取、轉換、加載方式[8]。首先在數據抽取階段將數據從源端讀取出來，該過程使用源端數據庫適用的讀取方式進行讀取，就目前常用的Oracle、Mysql等結構化數據庫，通常采用jdbc方式進行讀取。數據讀取出來后，在數據轉換階段會將源端數據經過適當的加工與轉換，使得數據滿足目標端的存儲需求，最終在數據加載階段將處理好的數據加載到目標端數據庫。

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

3.2.2 數據庫同步復制方式

同步復制方式即實現數據在兩個數據節點之間實時地保持一致的一種數據備份復制方式。目前在Oracle數據庫集群環境中被廣泛使用的同步復制軟件為OGG(Oracle Golden Gate)。而對于異構數據庫系統，OGG同樣能夠發揮其作用，實現大量數據亞秒級別的實時復制，且可以實現一對一、一對多、多對一、雙向、點對點、級聯等多種靈活的拓撲結構[9-11]。

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

3.2.3 文件導出導入方式

文件導出導入方式即先將源端數據以文件形式從數據庫導出，再通過FTP等文件傳輸方式傳輸到目標端，再在目標端將文件導入到數據庫中。

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

3.3 存量數據接入設計

存量數據只需要一次性接入。考慮到其存量巨大，若直接采用ETL方式，則效率太低且異地數據傳輸時穩定性差。因此，我們選擇將存量數據先采用文件形式從源端導出，再導入數據倉庫所在本地系統。由于源端與目標端為異構數據庫，且依據生產環境的運行規定，源端只允許導出dmp文件，因此需要在數據倉庫本地部署一個小型的Oracle數據庫作為數據中轉站。將源端導出的dmp文件導入此Oracle中，然后再使用ETL方式從此Oracle將全量數據抽取到數據倉庫。整個過程如圖1所示。

圖1 存量數據接入示意圖

存量數據接入的全過程總結如下：

1) 源端業務系統將所需接入的表導出為dmp文件，同時記錄存量數據范圍，作為區分存量數據與增量數據的依據。

2) 將導出的dmp文件通過文件傳輸方式發送到目標端中轉數據庫所在服務器。

3) 將dmp文件導入目標端中轉數據庫。

4) 使用ETL方式將目標端中轉數據庫中的數據導入MPP數據倉庫。

5) 導入成功完成后刪除中轉數據庫中的數據。

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

3.4 增量數據接入設計

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

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

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

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

示例如下：

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

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

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

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

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

該同步復制策略的特點如下：

1) 目標端Mysql可以只保存近期一段時間內的數據，不用緩存全量數據。

2) OGG在做update和delete操作時不會因為目標端缺少數據報錯。

3) 不需要做源業務系統到mysql數據庫的數據初始化工作，即mysql中不需要存儲源業務系統的歷史數據。

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

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

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

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

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

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

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

整個增量數據接入過程如圖3所示。

圖3 增量數據接入示意圖

增量數據接入的全過程總結如下：

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

2) 定期通過ETL方式將數據解析轉換后存入MPP數據倉庫。

3.5 Hive中數據的接入

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

4 實驗與驗證

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

表1 增量數據接入實驗環境

在Oracle向Mysql數據庫進行數據同步時觀測各類型數據量、源端與目標端服務器性能數值如表2所示。

表2 Oracle向Mysql數據同步實驗結果

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

表3 Mysql向MPP解析接入實驗結果

綜合上述實驗結果，數據能夠高效而準確地同步且對源端和目標端服務器性能影響較小，滿足中心信息系統實時業務響應速度需求和安全運行需求。

5 結 語

在信息發展速度越來越快的今天，傳統數據庫架構已經越發難以滿足更加復雜、更加多樣化的業務需求，包括電網在內的各大行業正在積極開展傳統數據庫架構向大數據技術下數據架構的轉型工作。其中一大重點和難點在于如何有效實現從傳統數據庫向大數據技術下數據存儲載體進行的數據遷移。在這方面，數量最多需求最大的就是結構化數據從傳統數據庫向大數據數據倉庫遷移的問題。

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