隋合軾

（國網(wǎng)營口供電公司，遼寧 營口 115002）

基于一體機架構(gòu)的海量數(shù)據(jù)集中與處理

隋合軾

（國網(wǎng)營口供電公司，遼寧 營口 115002）

通過營銷管控信息系統(tǒng)建設實踐，針對供電企業(yè)各專業(yè)系統(tǒng)海量數(shù)據(jù)集中與處理，提出了基于數(shù)據(jù)庫一體機的解決方案，從業(yè)務邏輯、數(shù)據(jù)架構(gòu)、物理架構(gòu)等方面論述實現(xiàn)途徑，并以實例驗證數(shù)據(jù)庫一體機方案的技術(shù)優(yōu)勢。

數(shù)據(jù)庫一體機；海量數(shù)據(jù)；數(shù)據(jù)集中；數(shù)據(jù)處理

1 概述

隨著集約化、精益化管理的不斷深入推進，電網(wǎng)企業(yè)各專業(yè)系統(tǒng)亟需針對多級部署的專業(yè)系統(tǒng)數(shù)據(jù)實現(xiàn)橫向集成，縱向集中，便于上級機構(gòu)即時訪問、處理、分析。以總部營銷管控信息系統(tǒng)建設為例，提出基于數(shù)據(jù)庫一體機架構(gòu)的海量數(shù)據(jù)實時處理方案，并以實際運行案例驗證取得的實踐效果。

建設總部營銷管控信息系統(tǒng)，最終形成縱貫總部、省、地市三級營銷信息管控系統(tǒng)，支撐營銷業(yè)務統(tǒng)一策劃、統(tǒng)籌部署、全程管控，實現(xiàn)營銷關(guān)鍵指標、核心業(yè)務、重要業(yè)務環(huán)節(jié)的實時監(jiān)控、動態(tài)評價、持續(xù)改進，有利于提升公司總部營銷戰(zhàn)略決策能力、運營管控能力、風險防范能力、服務監(jiān)督能力、市場拓展能力。針對這樣一個大規(guī)模數(shù)據(jù)處理并要求實時展現(xiàn)的重要業(yè)務系統(tǒng)的建設，經(jīng)過大量的前期論證分析，在比對了多種方案后，確定選擇Oracle Exadata數(shù)據(jù)庫一體機方案，并進行了系列開發(fā)和驗證工作。

2 基于數(shù)據(jù)庫一體機的系統(tǒng)架構(gòu)

2.1 總體架構(gòu)

總部營銷管控信息系統(tǒng)以27個網(wǎng)省的營銷業(yè)務應用系統(tǒng)為數(shù)據(jù)源，通過數(shù)據(jù)庫復制技術(shù)將數(shù)據(jù)從網(wǎng)省復制到總部，數(shù)據(jù)包括各省的稽查監(jiān)控業(yè)務匯總數(shù)據(jù)和用戶的明細數(shù)據(jù)。系統(tǒng)采用B／S架構(gòu)，包括運營動態(tài)和稽查監(jiān)控兩大功能。其中，運營動態(tài)模塊直接使用各網(wǎng)省的上傳數(shù)據(jù)，對電量、電價、電費、服務質(zhì)量以及設備等信息進行實時展示。這些數(shù)據(jù)在網(wǎng)省的系統(tǒng)中已經(jīng)安裝統(tǒng)一的結(jié)構(gòu)進行了處理，在總部利用數(shù)據(jù)庫復制技術(shù)實現(xiàn)了“多表對一表”的集中，從業(yè)務的角度來看，這些數(shù)據(jù)基本是實時的，即網(wǎng)省的變化會立即同步到總部；稽查監(jiān)控模塊在直接使用這些實時數(shù)據(jù)的同時，還需要利用存儲過程生成不同維度的數(shù)據(jù)，支撐稽查監(jiān)控任務的開展。

總部營銷管控信息系統(tǒng)建設模式采取總部一級部署應用，總體架構(gòu)如圖1所示。即在總部管理信息大區(qū)部署一套軟件，橫向集成總部運行管控系統(tǒng)與EMS、營銷分析與輔助決策、電網(wǎng)GIS空間信息服務平臺等系統(tǒng)數(shù)據(jù)及應用集成?？v向貫通總部運行管控系統(tǒng)與網(wǎng)省營銷稽查監(jiān)控、營銷業(yè)務應用、用電信息采集、電動汽車、能效管理等系統(tǒng)形成數(shù)據(jù)交換、流程貫通［1］。

圖1 總部營銷管控信息系統(tǒng)總體架構(gòu)

2.2 數(shù)據(jù)架構(gòu)

總部營銷管控信息系統(tǒng)采用數(shù)據(jù)復制技術(shù)，實現(xiàn)網(wǎng)省用電信息采集的縱向數(shù)據(jù)上傳，為了避免從各個網(wǎng)省復制上來的數(shù)據(jù)之間的主鍵、外鍵沖突等問題，在總部將每個省的上傳數(shù)據(jù)獨立存儲，既每個網(wǎng)省建立一個schema，同時建立總部schema作為各網(wǎng)省schema的“上級用戶”，該用戶有權(quán)限訪問存儲在總部的各網(wǎng)省schema內(nèi)的數(shù)據(jù)。

總部的數(shù)據(jù)存儲采用27個網(wǎng)省schema加1個總部schema的方式，數(shù)據(jù)架構(gòu)如圖2所示。網(wǎng)省schema用于存儲該網(wǎng)省的基礎(chǔ)數(shù)據(jù)（包括實時數(shù)據(jù)、明細數(shù)據(jù)、分析數(shù)據(jù)等）；總部schema存儲來自總部運行管控系統(tǒng)產(chǎn)生的基礎(chǔ)數(shù)據(jù)、管理數(shù)據(jù)和從各網(wǎng)省數(shù)據(jù)中生成的匯總數(shù)據(jù)，供前端應用對其進行訪問。將網(wǎng)省用電信息采集系統(tǒng)、營銷業(yè)務應用系統(tǒng)中的數(shù)據(jù)，按照總部營銷管控信息系統(tǒng)的要求歸集到數(shù)據(jù)準備區(qū)（為了保障網(wǎng)省用電信息采集系統(tǒng)的正常使用，在網(wǎng)省用電信息采集系統(tǒng)中劃分數(shù)據(jù)應用區(qū)和數(shù)據(jù)準備區(qū)）?？偛康臄?shù)據(jù)接收區(qū)和網(wǎng)省數(shù)據(jù)準備區(qū)數(shù)據(jù)結(jié)構(gòu)完全一致，去除所有的主、外鍵關(guān)系，降低由于數(shù)據(jù)校驗引起的同步風險。

這里數(shù)據(jù)傳輸是指各網(wǎng)省數(shù)據(jù)從網(wǎng)省準備庫傳遞至總部鏡像庫的過程。經(jīng)分析測算，各網(wǎng)省傳輸至總部的數(shù)據(jù)量較大，更新數(shù)據(jù)達10 MB／s，并且實時性要求高，一般要求為min級。數(shù)據(jù)傳輸擬采用數(shù)據(jù)庫復制技術(shù)，在數(shù)據(jù)源端進行數(shù)據(jù)壓縮，然后上傳至總部，可以節(jié)省網(wǎng)絡帶寬、縮短傳輸時間。根據(jù)總部營銷運行管控系統(tǒng)的技術(shù)需求，引入目前較為流行的數(shù)據(jù)庫復制軟件Oracle Golden Gate（OGG），通過分析數(shù)據(jù)庫重做日志（redolog）和歸檔日志，形成sql隊列，將數(shù)據(jù)傳輸至目標庫后應用到目標數(shù)據(jù)庫［2］。數(shù)據(jù)復制技術(shù)需要在原庫與目標庫都部署配制相應的軟件，但要求對數(shù)據(jù)庫資源的占用相對較小，實時性較強，數(shù)據(jù)吞吐量也較大。

圖2 總部營銷管控信息系統(tǒng)數(shù)據(jù)架構(gòu)

2.3 物理架構(gòu)

根據(jù)所使用的數(shù)據(jù)庫服務器不同，總部營銷信息管控系統(tǒng)的物理部署架構(gòu)有兩種選擇：一種是基于小型機數(shù)據(jù)庫的物理部署架構(gòu)、另一種是基于數(shù)據(jù)庫一體機的物理部署架構(gòu)，如圖3所示［3］。兩種架構(gòu)的區(qū)別在于前者數(shù)據(jù)庫服務器使用小型機雙RAC架構(gòu)，而后者數(shù)據(jù)庫服務器使用數(shù)據(jù)庫一體機。

對前述兩種物理部署架構(gòu)進行了對比分析，結(jié)果如表1所示?？梢钥闯?，基于數(shù)據(jù)庫一體機的物理部署架構(gòu)除初始投資較高外，在體系架構(gòu)、處理能力、擴容投資、智能存儲、運維成本、空間占用、電能消耗等方面都具有較明顯優(yōu)勢［4］。

表1 兩種物理部署架構(gòu)的對比分析表

2.4 系統(tǒng)負載

圖3 基于數(shù)據(jù)庫一體機的物理部署架構(gòu)圖

從業(yè)務的角度看，總部營銷管控信息系統(tǒng)是一個大數(shù)據(jù)準實時查詢和在線分析為主的混合型應用系統(tǒng)，由于系統(tǒng)處理的是電網(wǎng)公司核心的商業(yè)信息和管理，使用人員多為公司高級管理人員，系統(tǒng)可預見未來的并發(fā)數(shù)不會太高，但對響應時間會非常敏感。同時，盡管系統(tǒng)采用B／S架構(gòu)，但在應用服務器層更多的是表示層邏輯的處理，而大量的業(yè)務邏輯和數(shù)據(jù)處理的工作在數(shù)據(jù)庫服務器上實現(xiàn)，因此，數(shù)據(jù)庫服務的處理能力將是系統(tǒng)整體性能的關(guān)鍵。從其運行方式上來看，主要的負載主要有3個方面：①通過Oracle Golden Gate從27個網(wǎng)省實時復制上來的數(shù)據(jù)的處理；②來自應用服務器的數(shù)據(jù)服務請求處理；③利用存儲過程實現(xiàn)的ETL（Extract，Transfer和Load，即提取，轉(zhuǎn)換和裝載）功能的處理。

系統(tǒng)負載情況如圖4所示。從圖中可以看出，總部營銷管控信息系統(tǒng)是一個存儲I／O密集型的系統(tǒng)，數(shù)據(jù)從網(wǎng)省上傳到最終被應用服務器使用至少要經(jīng)過多次海量數(shù)據(jù)的I／O操作，過程可描述為：①OGG將網(wǎng)省數(shù)據(jù)寫入隊列文件；②OGG將隊列文件內(nèi)的記錄寫入Schame OMAC的對應表中；③存儲過程從Schame OMAC抽取數(shù)據(jù)，經(jīng)過清洗、轉(zhuǎn)換，加載到Schame SGACMS的表中；④應用服務器訪問兩個Schame中的數(shù)據(jù)。

圖4 總部營銷管控信息系統(tǒng)負載

以現(xiàn)有數(shù)據(jù)范圍，系統(tǒng)在線5年估算，系統(tǒng)數(shù)據(jù)達到PB級。同時，由于電力客戶數(shù)量眾多，明細數(shù)據(jù)是按日產(chǎn)生的，因此單一的表中記錄數(shù)最終會在達到百億條以上，單一表的大小在數(shù)百個GB。而這些表一般都是包含電量、電費、電價等重要數(shù)據(jù)的表，并且業(yè)務處理多為多表關(guān)聯(lián)、聚合、分組等大I／O、高CPU資源占用的操作，對數(shù)據(jù)庫服務器系統(tǒng)的性能要求非常高。

3 數(shù)據(jù)庫一體機架構(gòu)技術(shù)優(yōu)勢及實例驗證

3.1 技術(shù)優(yōu)勢

總部營銷管控信息系統(tǒng)屬于數(shù)據(jù)密集型的應用，并對響應時間敏感，并發(fā)訪問有限，業(yè)務邏輯處理多在數(shù)據(jù)庫層進行，因此系統(tǒng)處理能力焦點在數(shù)據(jù)庫服務器。數(shù)據(jù)庫一體機架構(gòu)的技術(shù)優(yōu)勢主要體現(xiàn)如下。

a.系統(tǒng)I／O能力

與傳統(tǒng)數(shù)據(jù)庫系統(tǒng)相比，Oracle Exadata突破了制約系統(tǒng)性能和容量的I／O瓶頸。傳統(tǒng)的存儲系統(tǒng)性能的提升大多靠增加硬盤驅(qū)動器的數(shù)量取得，而Oracle Exadata的存儲服務器可以感知數(shù)據(jù)，卸載數(shù)據(jù)庫服務器的負載，通過采用大規(guī)模并行架構(gòu)，通過更高的帶寬（40 GB／s Infiniband端口帶寬、Smart Flash Cache緩存高達5.3 TB）連接加快了并行數(shù)據(jù)處理并減少了數(shù)據(jù)移動（EHCC混合列壓縮、分區(qū)修建、存儲索引、Smart Scan智能掃描等）［5］。通過檢索SPC－1和SPC－2的測試結(jié)果可以發(fā)現(xiàn)，當前大部分高端存儲的IOPS指標基本在200 000左右，而Exadata做高可達1 500 100。

b.混合負載

Oracle Exadata可在1個平臺上很好支持混合負載（OLTP＋OLAP），而傳統(tǒng)架構(gòu)由于不能突破性能上的限制，一般采用業(yè)務處理系統(tǒng)和查詢分析系統(tǒng)分離的設計，這種架構(gòu)由于需要兩個系統(tǒng)間的數(shù)據(jù)傳遞，穩(wěn)定和實時性都大打折扣，并且維護成本和難度都較高。

c.性能優(yōu)化方式

數(shù)據(jù)庫系統(tǒng)的性能優(yōu)化一般都首先集中在應用層面，既優(yōu)化SQL語句，然后在進行系統(tǒng)層面的調(diào)整，但優(yōu)化的難度很大。Oracle Exadata為性能的優(yōu)化提供了更多的方法和便利條件，降低了系統(tǒng)優(yōu)化的難度，如混合列壓縮、分區(qū)修建、智能掃描等。

3.2 實例驗證

以上各項技術(shù)優(yōu)勢在項目測試中得以驗證，僅舉幾例，列表說明。

例1：以CTAS（Create Table As Select）方式創(chuàng)建不同壓縮方式的表，然后從dba_segments查詢其大小，并與原始table比較得到壓縮率，測試結(jié)果見表2。

表2 EHCC數(shù)據(jù)壓縮前后測試結(jié)果

例2：使用Exadata的各個技術(shù)，依次運行原系統(tǒng)SQL語句，測試結(jié)果見表3。

表3 原系統(tǒng)SQL語句加載Exadata的各個技術(shù)測試結(jié)果

例3：與售電統(tǒng)計相關(guān)的5、6個類似的SQL，運行速度極為緩慢，執(zhí)行大約需要15 min，頁面圖表無法顯示，用戶體驗極差，須進行優(yōu)化，測試結(jié)果見表4。

表4 原系統(tǒng)SQL語句經(jīng)優(yōu)化并加載Exadata的各個技術(shù)測試結(jié)果

4 結(jié)論

通過總部營銷管控系統(tǒng)建設過程中逐步探索，及對Exadata數(shù)據(jù)庫一體機在數(shù)據(jù)壓縮能力、I／O性能和數(shù)據(jù)處理能力的測試，和系統(tǒng)試運行過程中TOP SQL的優(yōu)化實踐，得到如下結(jié)論。

a.總部營銷管控系統(tǒng)這類由下向上逐級數(shù)據(jù)集中與處理，對數(shù)據(jù)實時性、完整性、準確性，以及海量數(shù)據(jù)即時分析提出了更高要求，需要就總部、網(wǎng)省甚至地市各專業(yè)系統(tǒng)建設現(xiàn)狀做出通盤考量再選擇適合的技術(shù)路線。

b.數(shù)據(jù)庫一體機的先進的架構(gòu)和創(chuàng)新性的功能，在大規(guī)模數(shù)據(jù)處理方面具有傳統(tǒng)數(shù)據(jù)庫系統(tǒng)無法比擬的優(yōu)勢；如40 GB的infiniband內(nèi)存互聯(lián)、Smart Flash Cache、Smart scan、混合列壓縮、存儲索引等［6］。

c.數(shù)據(jù)庫一體機具有混合負載，在線OLAP處理能力具有優(yōu)勢，并能夠滿足不斷的業(yè)務創(chuàng)新和功能擴展的需求。

［1］王 楠，陳曉光，高明雙.建立可控的信息網(wǎng)絡安全準入機制［J］.東北電力技術(shù)，2014，35（5）：43－44.

［2］OGG產(chǎn)品介紹及應用場景，應用案例［EB］.http：／／www. oracle.com／technetwork／cn／community／developer?day／4?ogg?app?case?2002394?zhs.pdf.

［3］孟凡博.電力通信傳輸容災架構(gòu)體系研究［J］.東北電力技術(shù)，2014，35（7）：25－27.

［4］Oracle Exadata Technology Portal on OTN［EB］.http：∥www.oracle.com／technology／products／bi／db／exadata.

［5］Oracle Exadata white papers［R］.http：∥www.oracle.com／technetwork／database／features／availability／xmigration?11?133466. dbf，http：／／www.oracle.com／technetwork／middleware／bi?foundation／exadata?smart?flash?cache?twp?v5?1?128560.pdf.

［6］曉 召.大數(shù)據(jù)VS數(shù)據(jù)庫一體機［DB］.http：∥blog. sina.com.cn／s／blog_7ca5799101013dtb.html.

Massive Data Concentration and Processing Based on Database Machine

SUI He?shi
（State Grid Yingkou Electric Power Supply Company，Yingkou，Liaoning 115002，China）

According to concentration and processing of massive data in each professional system of power grid enterprise，this paper proposes the solutions based on the database machine by combining the construction of the power?marketing information monitoring sys?tem，elucidates implementation approach from the business logic，data architecture，physical architecture etc.Introducing the exam?ple，the technology advantage of the solutions are verified.

Database machine；Massive data；Data concentration；Data processing

TM274

A

1004－7913（2015）09－0012－04

隋合軾（1970—），男，碩士，高級工程師，現(xiàn)從事運營監(jiān)測（控）管理工作。

2015－06－30）