李志奎 丁立群 關英宇

國網(wǎng)電科院北京科東電力控制系統(tǒng)有限責任公司 北京 100192

0 引言

隨著信息化步伐的加快，企業(yè)為了提高工作效率也建立了相應業(yè)務系統(tǒng)。然而，不同的操作系統(tǒng)、應用軟件存在著數(shù)據(jù)存儲方式不統(tǒng)一的情況，使企業(yè)內(nèi)部及企業(yè)之間的信息資源難以共享，形成了“信息孤島”現(xiàn)象。因此，構建整合管理平臺，建立信息共享機制，通過數(shù)據(jù)中心整合數(shù)據(jù)資源，能夠形成一個物理上集中管理、綜合控制的環(huán)境。

1 一體化繳費接入管理平臺的數(shù)據(jù)組成

1.1 一體化繳費接入管理平臺

一體化繳費管理平臺全面支撐電力公司、金融機構、非金融機構等多種渠道繳費，實現(xiàn)繳費管理、對賬管理、渠道管理、終端管理、擴展業(yè)務等業(yè)務功能，隨著相關行業(yè)的新增業(yè)務的開展，平臺將同時支持更多的新型業(yè)務。在數(shù)據(jù)部署上，一體化繳費管理平臺采用了省集中部署模式，即在全省數(shù)據(jù)大集中的基礎上，在省公司本部部署一套統(tǒng)一的涵蓋繳費交易、渠道注冊及變更管理、繳費渠道運營質量管理、渠道商管理、繳費終端設備資產(chǎn)管理、設備運行管理、擴展功能和系統(tǒng)支撐功能的所有功能應用，滿足省公司本部、地市公司和基層單位不同職能層次的繳費業(yè)務應用要求，這一套業(yè)務應用集中部署在一組應用服務集群之上，同時，也采用統(tǒng)一的系統(tǒng)管理應用，實現(xiàn)全省統(tǒng)一的標準代碼管理、參數(shù)配置管理、工作流管理、權限管理、日志管理、元數(shù)據(jù)管理和接口標準管理等管理維護。

1.2 數(shù)據(jù)組成概述

數(shù)據(jù)架構設計的核心目標是建立一體化繳費管理平臺規(guī)范統(tǒng)一的數(shù)據(jù)架構藍圖，以支持一體化繳費管理平臺的建設目標。提高應用系統(tǒng)運行性能，提升一體化繳費管理平臺數(shù)據(jù)的分析利用價值。其中，數(shù)據(jù)中心的組成包括以下四部分(如圖 1)。

圖1 數(shù)據(jù)中心組成

數(shù)據(jù)庫服務器：數(shù)據(jù)中心的數(shù)據(jù)為多用戶共享，數(shù)據(jù)中心是負責管理和存儲數(shù)據(jù)的軟件和硬件資源。

服務器：數(shù)據(jù)中心的直接服務對象，一般是一個總公司或組織總部。利用客戶端提供的數(shù)據(jù)資源在數(shù)據(jù)中心服務器端建立數(shù)據(jù)庫，創(chuàng)建關系表、索引等，以及查詢和更新數(shù)據(jù)庫中的內(nèi)容。

客戶端：數(shù)據(jù)所有者的服務器。負責元數(shù)據(jù)信息的存儲，包括明密文關系屬性的對應信息、用于加密數(shù)據(jù)、保存密鑰信息等，以及構造密文索引的相關信息等；負責將用戶的明文查詢轉換為密文查詢；解密數(shù)據(jù)中心服務器端傳送過來的加密數(shù)據(jù)；并能夠對解密之后的明文進行二次過濾，并把最終正確的查詢結果呈現(xiàn)給查詢者。

用戶：即是數(shù)據(jù)所有者，又是數(shù)據(jù)中心的間接服務對象。通常是一個人或一個部門。經(jīng)所有者授權后通過瀏覽器向數(shù)據(jù)中心客戶端提交查詢請求，訪問存儲在數(shù)據(jù)中心服務器端的所有者數(shù)據(jù)。

數(shù)據(jù)統(tǒng)一存儲的架構設計打破了企業(yè)信息孤島，實現(xiàn)全公司范圍內(nèi)信息數(shù)據(jù)有效共享，實現(xiàn)數(shù)據(jù)的規(guī)范統(tǒng)一，進而充分發(fā)揮出數(shù)據(jù)的應用價值。

2 數(shù)據(jù)架構設計

一體化繳費管理平臺作為營銷業(yè)務應用系統(tǒng)的重要組成部分，它實現(xiàn)了新型繳費業(yè)務和傳統(tǒng)繳費業(yè)務的優(yōu)化整合，滿足多種繳費渠道的數(shù)據(jù)接入，為營銷業(yè)務應用提供了高質量的客戶繳費數(shù)據(jù)，推動了營銷業(yè)務的深化應用。針對營銷業(yè)務應用及其他相關系統(tǒng)的數(shù)據(jù)需求，共同決定了一體化繳費管理平臺的數(shù)據(jù)模型設計。

數(shù)據(jù)架構基于數(shù)據(jù)模型進行設計，數(shù)據(jù)架構中數(shù)據(jù)技術分類和數(shù)據(jù)部署設計，分別解決每一方面的關鍵問題，同時又相互支撐，互為補充，形成一個統(tǒng)一、有機的整體數(shù)據(jù)架構。數(shù)據(jù)技術分類和數(shù)據(jù)部署設計在數(shù)據(jù)模型的基礎上展開，按照不同的數(shù)據(jù)分類，結合系統(tǒng)架構的要求進行數(shù)據(jù)部署設計。數(shù)據(jù)架構基于數(shù)據(jù)模型從兩個方面進行設計，分別是數(shù)據(jù)技術分類、數(shù)據(jù)部署設計，每個方面分別解決一個領域的關鍵問題，同時又相互支撐，互為補充，形成一個統(tǒng)一、有機的整體數(shù)據(jù)架構。數(shù)據(jù)技術分類和數(shù)據(jù)部署設計在數(shù)據(jù)模型的基礎上展開，按照不同的數(shù)據(jù)分類，結合系統(tǒng)架構的要求進行數(shù)據(jù)部署設計，實現(xiàn)省(直轄市)集中的數(shù)據(jù)部署設計。

一體化繳費管理平臺采用省(直轄市)公司集中部署模式，各地市公司通過網(wǎng)絡訪問省公司一體化繳費管理平臺開展繳費業(yè)務應用，省(直轄市)公司集中對一體化繳費管理平臺業(yè)務進行存儲和管理。一體化繳費管理平臺數(shù)據(jù)包括從營銷業(yè)務應用系統(tǒng)同步過來的基本檔案和應收發(fā)行數(shù)據(jù)，從電力營業(yè)廳、網(wǎng)上營業(yè)廳、自助繳費終端、電力POS終端、金融機構代收和非金融機構代收等不同繳費渠道接收的繳費及對賬數(shù)據(jù)，從用電信息采集系統(tǒng)接收的客戶電量、電費數(shù)據(jù)等相關數(shù)據(jù)。繳費數(shù)據(jù)經(jīng)過一體化繳費管理平臺分析、轉換和處理后，為營銷業(yè)務應用及其相關系統(tǒng)提供數(shù)據(jù)應用支撐。

3 分布式集群緩存技術

一體化繳費管理平臺作為業(yè)務支持軟件系統(tǒng)隨著業(yè)務需求的變化將處于不斷的改進和變化中。同時，系統(tǒng)采用的企業(yè)級數(shù)據(jù)庫系統(tǒng)將建立多種接口，以滿足相關應用系統(tǒng)的按照接口規(guī)范數(shù)據(jù)訪問的要求，由于訪問系統(tǒng)的方式多種多樣，從而將產(chǎn)生不同的類型數(shù)據(jù)，這些數(shù)據(jù)也急需進一步優(yōu)化。

雖然在應用服務器上采用緩存技術可實現(xiàn)上述要求，但是帶來的缺點是犧牲了應用服務器的內(nèi)存來換取數(shù)據(jù)庫的頻繁I/O操作以提高整個系統(tǒng)的性能。

由多臺虛擬機組成一個集群系統(tǒng)，每臺虛擬機自身都有高速緩存，在集群中多個節(jié)點間采用分布式緩存技術交換信息，從而形成一個整體上的分布式緩存模型。對外提供一個分布式隊列請求接口，應用程序可以通過調用請求接口來訪問集群服務器。當一個遠程應用程序訪問集群服務時，應用程序首先訪問本地的緩存，并將該請求加入到分布式請求隊列，分布式緩存根據(jù)調度算法來響應分布式請求隊列中的請求，當該請求得到響應時，集群系統(tǒng)通過查詢處理接口將本地緩存的結果返回到分布式緩存隊列，分布式緩存將集群中返回的結果以數(shù)據(jù)對象的形式返回給遠程應用程序。對集群外的訪問者，集群內(nèi)的所有緩存信息好像是一個整體，分布式緩存可以及時響應所有客戶的請求。

一體化繳費管理平臺中涉及到的業(yè)務字典表、計費匯總等實時訪問的業(yè)務數(shù)據(jù)，通過分布式集權緩存，就可以非常簡單地調用get方法取得該對象，并且由于分布式集權緩存本身的冗余機制使得任何一個應用服務器節(jié)點的失敗都不會影響到該對象的丟失。這樣既有原來各種應用服務器集群所具有的各種技術特點，而且又增加了原來各種應用服務器集群技術所沒有的共享對象訪問特性。

4 數(shù)據(jù)處理優(yōu)化技術

隨著一體化繳費管理平臺的管理業(yè)務的不斷積累和發(fā)展，數(shù)據(jù)量也成幾何倍數(shù)地增長，同時應用系統(tǒng)采用模塊服務的模式，將導致數(shù)據(jù)庫表的數(shù)據(jù)行數(shù)增多。隨著用戶數(shù)量不斷的增長和新業(yè)務不斷出現(xiàn)以及企業(yè)管理流程的不斷變更，應用系統(tǒng)的數(shù)據(jù)量也會出現(xiàn)進一步的增長。以下為一體化繳費管理平臺采用的數(shù)據(jù)優(yōu)化技術。

4.1 數(shù)據(jù)庫連接池

在讀寫數(shù)據(jù)庫中，資源開銷最大的是建立數(shù)據(jù)庫連接。在每一個用戶訪問時，都重新建立連接。這樣不僅要長時間等待，而且系統(tǒng)可能會由此導致崩潰。為了解決這一問題，提出了連接池技術。

連接池是系統(tǒng)在內(nèi)存中建立的一個連接緩沖池，對于建立好的數(shù)據(jù)庫連接在程序中的斷開為邏輯斷開，而實際物理連接被存儲在連接池中并被加以維護。當下一個連接建立時，直接從連接緩沖池中取得一個數(shù)據(jù)庫連接，而不需重新建立。因此，可以大大地提高數(shù)據(jù)庫的響應速度，從而提高系統(tǒng)的性能。

4.2 優(yōu)化查詢語句

以數(shù)據(jù)庫為中心的應用系統(tǒng)，主要操作往往是查詢操作，查詢語句的優(yōu)劣直接影響數(shù)據(jù)庫訪問的速度，而查詢操作所使用的Select語句在SQL語言中代價最大，同一條查詢語句，表達形式對查詢效率往往影響極大。索引可以快速定位表中的數(shù)據(jù)記錄。使用索引可以提高數(shù)據(jù)庫的速度。如果查詢時不使用索引，查詢語句將查詢表中的所有字段。如果使用索引進行查詢，查詢語句只查詢索引字段，這樣可以減少查詢記錄，提高查詢輸度。

4.3 優(yōu)化數(shù)據(jù)庫結構

數(shù)據(jù)庫設計規(guī)范化的目的是為了在表中消除冗余數(shù)據(jù)。減少了數(shù)據(jù)庫中的冗余數(shù)據(jù)，也就提高了數(shù)據(jù)庫的查詢性能。在SQL Server中，數(shù)據(jù)按頁存放，每一頁包含一個頁頭和若干數(shù)據(jù)行，數(shù)據(jù)行的大小是由行中所包含的字段數(shù)和數(shù)據(jù)類型確定，行的大小對數(shù)據(jù)庫的性能影響較大。如果數(shù)據(jù)行較小則每頁可以存放較多的行，同時高速緩存中也就能存放更多的行，減少了數(shù)據(jù)讀寫時間。在數(shù)據(jù)行包含有定長列和變長列兩種，變長列的開銷更大。在SQL Server中，數(shù)據(jù)庫默認把為空值的列作為變長列處理，因此，把列設為非空會提高數(shù)據(jù)庫的性能。數(shù)據(jù)庫對象以頁為單位存儲于磁盤上，頁間通過指針構成鏈，表將頁連成一串，對表分區(qū)是為了創(chuàng)建多個頁鏈， 所以采用了表分區(qū)技術，對于插入操作，分區(qū)為插入提供了多個插入點，減少了頁的互鎖競爭，加快了事務的執(zhí)行速度。

根據(jù)需要在數(shù)據(jù)庫基礎上創(chuàng)建新表或視圖，對于多表關聯(lián)后再查詢信息的可創(chuàng)建新表，對于單表查詢的可創(chuàng)建視圖，這樣可充分發(fā)揮數(shù)據(jù)庫的容量大、可擴充等特點，所有條件的判斷、數(shù)值計算統(tǒng)計均可在數(shù)據(jù)庫服務器后臺統(tǒng)一處理后追加到臨時表中，形成數(shù)據(jù)結果的過程可用數(shù)據(jù)庫的過程或函數(shù)來實現(xiàn)。利用數(shù)據(jù)庫描述語言編寫數(shù)據(jù)庫的過程或函數(shù)，然后把過程或函數(shù)打成包在數(shù)據(jù)庫后臺統(tǒng)一運行包即可。

5 結論

本文依據(jù)企業(yè)應用系統(tǒng)整合的現(xiàn)狀和需求，提出了基于數(shù)據(jù)中心的企業(yè)應用系統(tǒng)整合平臺的整體架構。并探討了數(shù)據(jù)處理優(yōu)化技術，整合了企業(yè)資源，消除信息孤島。符合平臺的發(fā)展方向。隨著行業(yè)的不斷發(fā)展及設備的不斷更新。本設計架構將提供了一個更高效，更靈活，可擴展性更強信息管理平臺。

[1]葉蘇南,彭宏,覃姜維.基于 MVC架構的數(shù)據(jù)挖掘平臺的設計與實現(xiàn)[J].計算機工程與設計.2010.

[2]任慶東,宗喜軍,常凌云.基于面向服務架構的數(shù)據(jù)共享與交換平臺的設計[J].大慶石油學院學報.2007.

[3]王柯柯,崔英志,黃賢英,黃麗豐.基于數(shù)據(jù)中心的企業(yè)應用系統(tǒng)整合平臺架構的研究和設計[J].西南大學學報.2009.

[4]王峰,顧明,李麗.基于 J2EE應用的數(shù)據(jù)庫訪問的性能優(yōu)化[J].計算機工程.2003.

[5]谷震離.SQL Server數(shù)據(jù)庫應用程序性能優(yōu)化方法[J].計算機工程與設計.2006.

[6]尹萍.SQL Server數(shù)據(jù)庫性能優(yōu)化[J].計算機應用與軟件.2005.

[7]陳軍.基于WEB的校園數(shù)據(jù)中心管理研究[D].濟南:山東大學.2006.