大型電力企業基于GBase分布式數據倉庫建設初探

邱 菊 王 巖 黃佩卓 王 洋

(北京中電普華信息技術有限公司 北京 100085)

0 引 言

計算機和網絡技術的發展帶來日益激烈的市場競爭環境，企業各級管理人員迫切需要根據企業的現狀和歷史數據做出判斷和決策。各級管理人員也希望能夠從企業信息系統中獲取有效的、一致的決策支持信息，及時準確地把握市場變化的脈搏，做出正確有效的判斷和抉擇[1]。隨著企業信息系統的運行和建立，數據量越來越大，企業的數據源越來越多，這種需求比以往任何時候都更加迫切，也更加難以實現。面對這些問題，作為決策支持系統環境的核心，數據倉庫的建設很有必要[2]。

國家電網公司作為全球最大的公用事業行業，擁有繁多的業務類型和管理層級，其信息化建設在經過SG186和SG-ERP工程建設和應用后，已經建成總部、省市公司兩級數據中心，積累數據總量超過5 PB，設計并作為企業標準發布公共信息模型(SG-CIM)，支撐了“三集五大”核心業務的集成融合[3]，為大規模開展大數據應用奠定了基礎。隨著公司各業務條線信息系統建設和應用的不斷深入，公司提出到“十三五”末，建成“數據干凈透明、模型規范統一、分析靈活智能”的全業務統一數據中心，包括處理域、管理域、分析域三部分建設內容，面向全業務范圍、全數據類型、全時間維度提供統一的存儲、管理與服務，實現業務高度融合、數據充分共享。數據是信息化的核心，考慮到現階段數據接入情況以及大數據的分析需求，數據倉庫的建設迫在眉睫[4]。本文結合國網公司的全業務統一數據中心的建設現狀，基于GBase 8a分布式數據庫對數據倉庫的建設進行初步探索。

1 行業內外建設現狀

隨著我國信息化建設的逐步開展，傳統的數據庫技術已經滿足不了企業快速發展的需求，簡單的報表匯總信息不能及時、全面地向管理者提供有效的決策數據，因此，數據倉庫技術應勢而生。數據倉庫技術經過發展融合，如今已經滲透到了各行各業，電信、銀行、金融、保險、制造、零售等，都建立了符合自身行業特色的企業數據模型和數據倉庫系統[5]。

在我國較早引入數據倉庫應用的是電信運營類企業，其中最具有代表性的當屬“中國移動”和“中國聯通”兩家電信運營商。中國移動構建的“經營分析系統”[3]是為企業經營決策提供信息支撐的系統，包括數據獲取層、數據存儲層、數據應用層、數據訪問層和數據管理層五部分，從總體和不同類型客戶角度對每種業務的總量發展、增量發展、新業務使用情況、業務發展構成進行了多維分析與預測。聯通集團的大數據中心建設項目，把數據倉庫模型的層次結構劃分為接口層、整合層、中間層和匯總層，整個業務流程包括：接口層保存接入的源數據，在整合層對源數據進行標準化和編碼統一，接著傳輸到中間層形成基礎寬表支撐數據分析與挖掘，最后在匯總層中依據指標形成可場景化的數據匯聚。這些前期的建設成果為行業內提供了市場管理分析和決策支持的基本數據平臺，實現了通信領域相關業務系統源數據的整合，為行業發展積累了寶貴經驗[6]。銀行業一直是金融領域發展關注的焦點，中國建設銀行借鑒業界領先的FSDM模型和九大概念，對全行業業務數據、業務指標從企業級視角進行規范化、標準化的梳理，打破了以前部門級數據所形成的一個個“信息孤島”。數據倉庫具體劃分為RDW實時數據倉庫、貼源數據區、基礎主題區和應用組件數據區，完成了從數據接入到主體劃分、分析預測的數據處理全過程。

通過與上述行業數據倉庫建設的相關專家進行充分研討和交流，國家電網公司參考IEC61968/IEC61970等國際標準模型，結合電力公司實際業務情況，基于公共信息模型(SG-CIM)設計成果開展了企業級數據倉庫設計和建設的探索。目前國家電網公司已經基本完成SG186信息化工程建設，但是隨著各業務的交互和深入，逐漸暴露出跨專業業務協同與信息共享不足，數據多頭輸入，數據準確性，實時性不強，數據反復抽取、冗余存儲、質量不高等問題[7]。為了提高企業信息系統的統一性和數據的一致性，實現企業內部信息資源的共享，需要開展集中的企業數據管理，建立統一的數據管理中心。

2 數據倉庫模型的設計

2.1 總體架構設計

企業數據倉庫的總體架構包括基礎數據層、整合明細層和輕度匯總層，其中基礎數據層包括貼源歷史區和縱向歷史區，如圖1所示。此處數據倉庫模型的設計內容只包含結構化數據模型的設計：確定結構化數據的唯一來源，統一數據編碼規則，形成面向全業務整合、歸集后的非貼源物理表結構，提供數據清洗轉換的依據，初步完成可在國網總部及各省市公司落地實施的數據倉庫標準模型，為公司各類分析應用提供統一的結構化數據支撐。

圖1 數據倉庫架構示意圖

貼源歷史區的數據與源業務系統數據表結構保持一致，用于長期保存歷史數據，便于追溯數據來源，屏蔽對源生產系統的影響。縱向歷史區存儲總部下發到省市公司的數據以及省市公司擬上傳到總部的數據。基礎數據層的分區設計，有助于實現不同功能的數據分類存儲，方便數據倉庫在總部及省市公司的兩級部署和統一管理。

整合明細層中結構化數據模型的設計實現了SG-CIM模型的落地，以企業級視角建立數據倉庫，分域對數據進行整合、統一，保障數據唯一性。具體包括分系統模型設計和分域模型設計。明細層分系統模型設計工作是對各個業務進行初級篩選，達到編碼統一、語義統一、字段長度、類型、量綱等統一的目標，保障數據一致性，兼顧性能，分系統存放明細數據，快速支撐分析域全面建設，指導數據清洗轉換。明細層分域模型設計工作是基于SG-CIM 3.0以企業級視角進行設計，圍繞人員、財務、物資、資產、電網、項目、客戶、市場、安全及綜合等十大主題域按域整合，對各域模型成果進行整合、統一，保障數據唯一性，最終形成覆蓋全業務的、統一的明細數據模型設計成果，支撐分析域的全面建設。

輕度匯總層基于明細數據層模型進行設計，也采用按域整合的方法，以需求為驅動，為提升分析效率，對于計算復雜、關聯表多且數據量大的共性分析需求，預先按照維度建模的方式進行整合、匯總。輕度匯總層模型的設計是下一階段建設重點工作之一，在現階段數據倉庫初步建設過程中尚未體現。

2.2 明細數據層模型設計

按照總體架構的劃分，貼源歷史區處于明細數據層下游，與源業務系統表結構保持一致，為指導各業務系統數據遷移到貼源歷史區的實施工作，從數據接入范圍、數據存儲方式、建表原則等方面對貼源歷史區的數據模型進行規范，增加時間戳等擴充字段，用來長期保存歷史數據，屏蔽對源業務系統的影響。明細數據層位于貼源歷史區之上，以貼源歷史區為數據源，通過對業務系統數據表進行初步篩選，形成涵蓋全部業務含義的全量業務明細數據的模型，是數據倉庫模型設計的核心內容，具體包括分系統模型和分域模型設計兩部分。遵循數據倉庫模型的設計原則，采用“自下而上”和“自上而下”相結合的方式，按照邏輯模型設計、物理模型設計的步驟，分別進行明細層數據模型分系統模型和分域模型的設計[8]。

2.2.1 明細數據層分系統模型設計

明細層分系統模型設計圍繞業務系統的數據實體、屬性、關聯關系開展設計工作，在此基礎上，對數據實體、屬性、關聯關系進行分析，形成分析后的過程成果。基于過程成果，進一步梳理編碼、枚舉類等信息，結合以上成果開展明細層分系統邏輯模型設計工作。基于邏輯模型，明確編碼、枚舉類的統一標準，進而開展明細層分系統物理模型設計工作，在充分的驗證、交叉討論后，形成最終成果。整體設計思路如圖2所示。

圖2 明細層分系統模型設計思路

依據明細層分系統模型設計思路，邏輯模型設計先由設計團隊收集各業務系統的最新數據字典和應用需求，將系統表、過程表、快照表、配置表、日志表及業務表的部分屬性去除，再結合收集成果，用建模工具進行邏輯模型設計，形成邏輯數據實體、屬性、關聯關系。物理模型設計是先基于邏輯模型制定統一的標準，在其標準上補充滿足下游使用數據需求及清洗轉換需求的公共字段(如時間戳、來源系統、開始時間、結束時間、修改標識、有效標識等屬性)，同時與源系統物理表核實，結合數據的變化周期、訪問頻度、數據存量機制、數據增量機制等設計要素特性，最終將邏輯模型落地形成面向目標數據庫的物理模型。整體設計方法如圖3所示。

圖3 明細層分系統模型設計方法

2.2.2 明細數據層分域模型設計

明細層分域模型設計依據全業務統一數據中心建設要求，基于SG-CIM3.0模型設計中人員、財務、物資、項目、資產、電網、客戶、市場、安全及綜合十大主題域，分域開展本主題域的明細層分域模型設計工作，形成企業級視角分析域的存儲模型。分域模型設計圍繞著SG-CIM3.0的落地開展，將SG-CIM3.0成果轉換成物理模型，通過轉換后的物理模型的實體、屬性擴充，形成明細層分域的邏輯模型，再制定將各業務系統實體、屬性進行按域整合的標準，進而開展明細層分域物理模型設計，在充分的驗證、交叉討論后，形成最終成果。整體設計思路如圖4所示。

圖4 明細層分域模型的設計思路

明細數據層分域的邏輯模型設計，首先要基于SG-CIM3.0設計成果，按照扁平化設計方式，將SG-CIM3.0中實體類、枚舉類實例化為數據倉庫邏輯模型，并保持實體、屬性及關聯關系命名的一致，形成邏輯模型初設。物理模型設計則需先把邏輯模型初設與分系統邏輯模型進行對比，找出實體、屬性、關系差異，根據差異，擴充邏輯模型實體、屬性，確定權威數據源等關鍵信息，在其基礎上增加必要的公共字段和設計要素(同分系統模型設計)，將原來的實體表和編碼表轉化為數據庫的數據表和建表腳本。整體設計方法如圖5所示。

圖5 明細層分域模型的設計方法

本次模型設計工作采用EA(Enterprise Architect)軟件作為模型設計工具，將業務流程抽象提煉成實體、關系，通過EA工具繪制實體關系圖，依據業務含義詳細描述實體包含的屬性、不同實體間的主外鍵關系。邏輯模型中用類模塊(Class)表示實體，物理模型中用表模塊(Table)表示模型表。遵循設計規范的要求，對邏輯模型與物理模型的實體名、屬性名以及別名進行統一命名。實體間的一對一、一對多或多對一等關聯關系均體現在模型設計圖中，形成最終可交付的模型圖成果。

3 數據倉庫的初步建設

3.1 數據倉庫技術架構

在數據倉庫以43套業務系統為設計范圍的明細數據層模型初步設計完成后，以全業務統一數據中心分析域架構為基礎，對模型現階段成果進行差異比對驗證及實施驗證。首先部署在總部、天津等27家省市公司，形成模型差異反饋意見，向總體設計組進行差異化報備，根據反饋意見組織研討，研討后對模型進行迭代更新；更新后進行物理模型落地和腳本轉換的實施驗證，推進數據倉庫的進一步建設。

數據倉庫的建設是基于國家電網全業務統一數據中心分析域技術架構的，分析域技術架構由大數據平臺+MPP型數據庫混搭結構組成，如圖6所示。

圖6 分析域技術架構

其中支撐結構化數據存儲和計算的數據倉庫建設在MPP數據庫上；數據倉庫的數據接入采用ETL、OGG等技術方式，將數據源中各業務系統的結構化數據進行技術對應；數據存儲計算層作為整個架構的核心分為數據倉庫、大數據平臺和數據集市三個存儲計算區域，數據倉庫是針對結構化數據進行存儲計算的；統一分析服務層包括多維分析、數據挖掘等技術組件及算法，以數據存儲計算層為基礎結合技術處理方法，實現專題分析挖掘、多維報表、定制應用等功能。

大規模分布式并行數據庫集群系統(GBase 8a MPP Cluster)屬于MPP型數據庫，是在 GBase 8a 列存儲數據庫基礎上開發的一款 Shared Nothing架構的分布式并行數據庫集群，具備高性能、高可用、高擴展特性，可以為超大規模數據(TB至PB級)管理提供高性價比的通用計算平臺，廣泛地用于支撐各類數據倉庫系統。傳統的行式存儲數據庫在查詢機制方面存在一定的局限性，在數據規模較大情況下進行查詢操作具有明顯的性能瓶頸，如速度較慢、耗時長等。列式存儲數據庫是把同一屬性的數據存放在一起，此種機制更適合處理大規模復雜分析。除此之外，GBase 8a數據庫具有粗粒度智能索引的技術特征，在哈希鍵的指引下能夠實現高速查詢，表現出突出優勢。本次國網全業務統一數據中心數據倉庫建設選用GBase 8a Cluster集群產品進行落地實施。

3.2 模型驗證與建設成果

在模型初步設計完成后，經過項目組各組成員的內部評審，根據評審建議進行修訂完善，完善后的版本在總部及各省市公司進行匹配驗證及差異反饋工作。將邏輯模型圖、物理模型圖和模型設計說明書以及物理模型建表腳本等模型成果，下發到總部及27家省市公司分析域實施團隊，通過將模型中的來源表、來源字段與業務系統數據字典進行匹配驗證，形成模型驗證反饋意見。具體是將數據倉庫模型中的每一個實體及實體的每一個屬性，與相關業務系統數據字典中的每一張表及每一個字段進行逐一比對；首先比對名稱，對于模型中存在而數據字典中不存在，或者模型中不存在而數據字典中存在的情況，進一步進行業務含義的比對。若名稱比對和業務含義比對過程中都不能完全匹配的，則記錄下差異反饋，在模型后續版本迭代更新中進行補充。各省市公司反饋數據倉庫明細數據層分系統模型與業務系統數據字典基本可以實現匹配，除個別數據量較小的業務系統(如員工報銷、憑證協同等)由于省市公司系統建設的個性化差異而未能與總體設計組的典設模型完全匹配外，其他設計范圍內的系統都可以匹配，模型數據可以支撐企業經營決策和分析挖掘應用的數據需求，因此本次設計的數據倉庫模型可用、接入數據可溯源。

差異比對驗證后的模型繼續進行實施驗證，在數據庫表中建立表結構，使實施環境具備數據接入的條件。利用EA工具由物理模型圖能夠自動導出Oracle建表語句，由于目標數據庫為GBase 8a，因此必須轉換為GBase 8a的建表腳本。Oracle與GBase 8a在表類型、存儲、索引、分區、主外鍵、關聯關系標識、觸發器等機制方面存在諸多差異，給建表語句語法轉換和表類型選擇等方面帶來巨大的人工工作量。針對該問題，本文提出如下解決策略：轉換過程的軟件環境要求為Oracle數據庫、虛擬機Linux操作系統、GBase 8a數據庫等；編寫三個shell腳本實現文件的批處理過程；編寫存儲過程實現在GBase 8a數據庫中創建表結構的功能。硬件環境要求為GBase 8a MPP集群只部署單節點即可執行該轉換操作，具體步驟如下：根據模型在Oracle數據庫中生成表結構，再依據GBase 8a表類型劃分規則對所有的模型表分類，其中分類為哈希分布表的標注出哈希列；由GBase 8a建表語法可知，哈希列按照主鍵、字段值唯一、關聯查詢等值字段、重復值低的字段、group by字段的優先級原則進行選取，哈希鍵的數據類型只能是varchar、int或bigint。根據分類之后的不同表類型，針對在Oracle數據庫中已經建立的表，通過調用存儲過程分別生成GBase 8a中各類型表的建表腳本。最后在分析域實施團隊搭建的GBase 8a集群數據庫中驗證建表語句的語法，確保語句的合法性。

基于上述驗證，數據倉庫現階段的建設成果顯著。項目組已完成38套業務系統的數據倉庫明細層分系統邏輯模型及物理模型的評審、征求意見反饋、修訂完善設計成果并下發。基于該成果，目前國家電網在總部、天津、冀北、山東、山西、重慶、湖北、湖南等全國范圍內27家省市公司全面開展了全業務統一數據中心分析域物理環境的部署、數據遷移和數據清洗轉換等工作。GBase 8a Cluster的物理環境是以集群形式組織的，數據遷移和清洗轉換工作開始之前，已完成管理節點和數據節點的硬件部署、系統安裝、數據庫的軟件部署、定制化服務器的上架等集群部署工作。在與業務部門協商后，確定生產系統的權限開放期限，進行數據接入數據倉庫貼源歷史區的工作，以屏蔽對生產系統正常運行的影響。通過配置ETL服務器進行抽取、轉換、加載，數據由貼源歷史區接入數據倉庫明細層分系統模型中，數據倉庫完成初步建設。建設成果示例如總部分析域實施環境，現搭建的集群規模為3個管理節點，15個數據節點，采用NF5280M4型號的x86機，操作系統為Linux 6.8系統，數據庫系統為GBase 8a Cluster 862版。管理節點和數據節點分別部署完成后，開始遷移源業務系統的歷史數據到集群中。在60天內，總部已接入應急指揮、后勤管理、安監一體化等36個業務系統的歷史數據及部分增量數據合計共169 968.677 GB到貼源歷史區。

4 結 語

在國家電網全業務統一數據中心建設目標的要求下，為了實現全業務、全類型、全維度數據的融合，本文進行了企業級數據倉庫模型建設的初步探索。結合國網的業務特征和實際需求可知，數據倉庫的建設是分層次分階段逐步開展的，現階段以明細層分系統模型的設計、貼源歷史層的數據遷移與分系統層的數據接入為主要設計、建設內容。通過明細層分系統模型的設計，將業務系統中的系統表、配置表、統計表、日志表等非業務數據表進行了清理，保留了表征業務含義的明細數據，有效規避了數據倉庫上游應用在調用業務數據時對源系統的運行性能影響。

在明細層分系統模型設計成果基礎上，以企業級信息模型為指導，圍繞國網人員、財務、物資、項目、資產、電網、客戶、市場、安全及綜合十大主題域按域設計，通過交叉討論和統籌設計的方式對各域模型成果進行整合、統一，保障數據唯一性，形成明細數據層分域模型。基于明細層模型設計成果，結合實際業務需求，采用反范式的設計方式，通過改變數據粒度(如：按照日、周、月、季、年等顆粒度)對公司熱點數據進行分析，采用聚合、合并、增加屬性、去掉屬性等方法，最終形成統一的數據倉庫輕度匯總層模型，為分析挖掘應用提供高效的支撐，是企業級數據倉庫設計的下一步重點建設任務。

參 考 文 獻

[1] 游建培.數據倉庫應用及未來發展[J].金融電子化,2007(9):65-67.

[2] 任潤虎.電力系統數據倉庫技術及其應用[D].天津大學,2010.

[3] 王建偉.移動通信經營分析系統數據集市設計與實現[D].北京郵電大學,2012.

[4] 羅先賢.數據倉庫在城市公共建筑能耗管理中的應用[J].計算機應用,2011,31(10):2853-2857.

[5] 丁學英.企業數據中心建設探討[J].電力信息化,2007,5(9):30-33.

[6] 戴心凌.大型商業銀行企業級數據倉庫系統的構建[D].復旦大學,2010.

[7] 付立辰.電力企業中數據倉庫模型的研究與應用[D].華北電力大學,2012.

[8] 張玉芳,熊忠陽.數據倉庫數據模型的設計[J].計算機應用,1999,19(9):10-12.