林鈺杰 吳麗賢
(廣東電網有限責任公司 佛山供電局, 佛山 528000)
數據同步與數據交換的場景在大數據時代下一直存在,例如數據同步發生在分布式數據庫中,用戶如需獲取數據,則可以從數據庫中進行修改或管理。DEC,即(Data Exception Control Center),以面向數據以數據為核心的思想來對數據進行管理與提供服務,并解決數據同步與同步過程中可能出現的問題,為解決大數據時代下的軟件結構問題打好基礎。
數據沖突始終是需要考慮的問題。數據沖突是數據源之間的數據不統一、不唯一,任何程序都難免產生數據沖突。一般情況下可以將數據沖突的類型分為兩種,即數據語義沖突與數據結構沖突[1]。前者是指同一個現實事物在數據對象之間的描述方式上與內容上存在語義差異,而后者則是由于數據對象構成差異導致的結構變化,即源數據端與目標數據端。例如在Customer/Server場景當中,客戶端與服務器同步的過程中就可能出現因為版本沖突產生的數據沖突,因而需要進行數據同步管理[2]。具體沖突原因如下表1所示。
可以看到不同的數據沖突問題需要不同的檢測與解決方案,此時也需要有效的機制進行保障,防止數據崩潰的情況產生而導致系統癱瘓[3]。雖然數據沖突并不能百分之百避免,但數據同步時進行的控制可以顯著降低沖突產生的可能性,因而應用層與數據層的數據同步問題就顯得至關重要。
DEC的功能如圖1所示。
DEC即數據異常控制中心,能夠對數據系統進行有效劃分,在行業中具有重要作用。

表1 數據沖突情況

圖1 DEC功能
這項功能的作用是建立在數據維護功能基礎上,數據本身存在著多種管理手段。如果是實時應用的場景,則數據需要快速響應,此時安全數據也需要進行監控和管控,DEC則可以對不同的場景提供自適應管理模式,提供安全保障。
巡檢即對數據進行定期檢查和維護,針對于不同的元數據進行管理。
數據維護的功能包括數據訪問管理、數據操作管理、任務計劃管控與備份數據等[4]。
異常檢測與處理工作主要是針對數據產生的異常情況進行處理,關鍵內容在于數據的檢測,并掌握出現異常的數據。需要注意的是系統功能可以探測異常但不能對其進行處理,處理工作需要相關組件,通過通信機制進行協同工作[5]。
數據量大幅增加的情況下,數據安全性的維護工作固然重要,但數據過多帶來的冗余情況也需要得到控制。如果在計算算法上出現偏差,則數據存在缺失或系統損壞的可能性,此時數據信息量直接包含著明確的不確定性,即數據量越少,冗余度越多,在探測過程中也需要對數據進行掃描,但需要考慮到數據之間的耦合性與數據權重問題[6]。
同步處理是關鍵環節,是保障系統與應用之間的數據交換工作更加穩定的功能要求,尤其是在出現數據變換時,如何保證數據的準確,在云環境中實現同步、高效處理,DEC就可以提供重要的技術支持。
在大數據的時代下,機器的負載量面臨了更高層次的考驗,對于復雜數據的處理能力成為了機器的新要求[7]。例如在百度等全球性搜索網站來說,服務器也不會放置于同一區域。北京用戶可以通過北京服務器來訪問網站,而廣州用戶也可以通過廣州服務器來訪問網站,以此類推。因此,這種負載均衡的方式不僅可以提升訪問的速度與性能,還能極大地增加用戶體驗。
通過以下幾個方面的設計,可以明確同步服務器的模塊劃分,并掌握不同的模塊與子模塊所具有的功能,并闡述了數據表與DOA內部數據同步。
結構分為3個部分,即DOA、應用層與數據層。
DEC同步服務器管理DOA內部的數據同步功能,而DOA內部源數據庫可以提供目標服務器所需要的數據。數據交換格式基于XML存在,研究工作也將設計數據同步格式,DOA平臺會按照這種格式進行數據交換。按照數據流方向可以劃分為不同的種類,即源數據主動向目標數據進行數據上傳,響應下載;元數據與目標數據同時同步上傳,然后服務器同步響應并下載以及服務器同步請求,完成兩端同步數據交換3種模式[8]。但無論是哪種模式的同步都需要基于DEC。
DEC開發者充分了解DOA平臺的內部數據存儲結構,因此對于內部數據的處理可以采取基于觸發器的數據同步方式,讓所有文件操作都能在控制表中完成。但是對于應用層與數據層來說,DEC對于其存儲結構不應該進行過分干預,因為數據獲取在很大程度上與數據存儲的結構有關,需要一個高移植性與低耦合的方案來進行管理,例如數據層和應用層在符合通信數據規范格式的前提下完成數據同步工作。通過是極限DPA內部基于觸發器的方案就可以為同步服務器的工作提供技術參考。
DEC功能與中間件類似,可以將DEC下的同步服務器看做基礎服務器端,而數據層和應用層可以看做客戶端。數據流程也可以分為單向與雙向。
單項數據中的應用層會接受服務器發出的數據請求,然后收集數據,將差異進行組合后,向對端同步服務器進行響應。應用層的單向數據同步流程可以使用于DOA內部的數據管理,可以保持在同一個端口分別接收應用層與服務器的不同請求[9]。例如圖2所示。
雙向數據有所差異,應用層與數據層會先將本地的差異數據進行組合,然后收集兩端數據進行差異處理,分別返回給源數據與目標數據,保持一個端口分別用于應用層與數據層的不同請求。

圖2 數據流程示意圖
業務功能可以分為單項業務流程與雙向業務流程,但需要考慮到數據沖突與數據傳輸中斷問題[10]。
單項業務流程中,應用層會先對服務器進行更新要求提交,然后請求同步后,服務器端會接受來自應用層的消息。在驗證完畢后,服務器也會向數據層獲取更新,服務器此時對數據沖突與數據差異情況進行數據收集,如果出現合并失敗,那么服務器會將錯誤的狀態碼返回。反之,如果數據成功地合并,那么服務器也會將處理結果返回至應用層與數據層,然后分別更新數據,同步服務器端和數據庫中表示時間戳的字段[11]。
雙向業務流程則是由配置文件設定的實踐,并由定時器來觸發數據管理的事件。此時同步服務器會檢查兩端的數據是否存在數據沖突,如果有則進行解決[12]。另外,如果合并失敗,數據層與應用層在接收到同步結果后也會更新自身的數據,再根據兩端返回的相應消息來更新數據庫中表示時間戳的字段。
模塊管理涉及到業務層、數據層與通信層的相關內容。
3.5.1 業務層
業務層的功能包括數據轉換、同步處理與程序的調試和跟蹤,本質上也是同步模塊的公共基礎模塊,可以在協商過程中解決數據沖突。另外,作為同步過程中的基礎模塊,數據以Web Service的XML數據流方式進行傳輸,然后可以轉換并轉發給同步處理模塊[13]。業務層模塊還包括非結構化數據轉換模塊,非結構化的數據通過編碼、解碼的過程才能夠進行轉發,然后組裝到消息文檔之中,用于控制數據變化與記錄數據變化。
3.5.2 數據層
數據層的功能是為數據庫提供了數據結構,可以提供本地數據庫訪問時的服務。由于數據庫本身帶有驅動程序,模塊只需要對驅動程序的結構進行封裝,就能正常地訪問數據庫。但出于系統調用時的細節問題,軟件開發過程中可能需要自定義封裝不同的數據庫接口模塊[14]。此外,文件系統模塊也能提供操作系統級別的文件房問題模式,而控制表模塊還能夠記錄系統的操作,不僅可以為應用層和數據層提供同步使用的數據,還能有效作用于DOA內部的數據交換過程。
3.5.3 通信層
通信層的功能在于網絡數據的接收與發送,除了通信接口之外還包括Web Service框架。服務器在數據同步的工作中,業務模塊生成的數據可以通過通信接口進行轉發,然后將數據序列化之后再轉發至操作系統,并最終將字節化的數據發送給網絡端[15]。
數據庫設計方案可以根據結構化數據信息表與非結構化數據信息表的結構來確定,字段名與結構化數據之間有著密切的聯系。在dbinfo表的設計過程中,源數據在與目標數據通信時只有通過DEC才能實現同步,顯著提升了系統的安全性與穩定性[16]。但對于非結構化的文件數據來說,存儲結構化數據的設備如果是FTP服務器,那么port字段不應該設置為空。
DEC作為面向數據體系結構DOA的核心組件,對于數據的定義和管理都具有顯著的作用,解決數據同步中可能出現的問題,提供理論支持與技術保障。本研究圍繞大數據環境下的數據特點,以DEC理論為研究切入點,探討了應用層與數據層數據同步問題的相關內容,對已有的數據同步方案與差異變化進行了分析和討論,探究它們不同的優勢與應用場合,在未來更好地解決數據沖突、數據中斷恢復等相關工作。但需要注意的是,針對一些不符合規范的數據,服務器在數據不出現錯誤的前提下也會將其同步至數據庫當中,因此在未來的校驗工作還需要進一步深入。