基于總線的兵棋推演實時數據采集管理設計與實現

李榮森,李志強,曹 毅,司光亞

(國防大學聯合作戰學院,北京 100091)

兵棋推演歷史非常久遠,從墨子解帶為城算起,至今已2 000多年,期間人類戰爭也經歷了不同形態的演變。兵棋推演是現代進行戰爭模擬和作戰方案驗證的重要手段,尤其是推演過程中產生的數據,是后續各類分析的基礎。Creveld等在文獻[1]中回顧了戰爭發展的歷程,從大衛對歌利亞的戰斗開始,一直到最新的兵棋推演。文獻[2-3]針對數據本身進行了數據質量等分析。文獻[4-10]進行了各種基于兵棋推演數據的作戰分析,包括火力打擊決策分析模型、指令下達特征、作戰體系網絡模型等。文獻[11-13]進行了基于兵棋推演數據的挖掘、聚類、測量等研究。文獻[14-17]提出了基于兵棋推演數據的不同作戰方案評估方法。文獻[18-22]對深度學習在兵棋推演數據分析中的應用進行了研究。文獻[23]進行了基于兵棋推演數據的后勤物資儲備精確計算,建立了后勤模型和規則算法。文獻[24]開放了一個兵棋推演數據集。

可見,兵棋推演數據在各類分析中起著基礎支撐的作用,因此必須有可靠的兵棋推演數據采集管理方案,以保證數據的高可用性。目前,美軍比較典型的兵棋推演系統有JAS(原JWARS)[25]、JTLS、EADSIM、FLAMES等[26];國內的兵棋推演系統主要有某大型計算機兵棋系統、某大型仿真試驗系統、XSIM[27]、墨子等;此外還有商業化的兵棋推演系統如CMANO等。這些系統在底層數據存儲方面,JAS采用的是Oracle數據庫;JTLS4.0 版本采用的是Oracle數據庫,6.0版本更新為PostgreSQL數據庫;EADSIM、FLAMES、華如XSIM采用的是本地數據文件方式;CMANO采用的是SQLite數據庫;華戍墨子1.0版本采用的是SQLite數據庫,新版本采用的是MySQL數據庫;某大型計算機兵棋系統采用的是Oracle數據庫,某大型仿真試驗系統采用的是MongoDB數據庫。

由于采用單機版磁盤數據庫,原有兵棋推演系統在數據訪問方面存在一些問題,對與推演數據相關的各類應用造成了不利影響。

1 原有數據采集管理機制

1.1 原有數據采集管理機制總體結構

原有數據采集管理機制總體結構如圖 1所示。推演模型子系統將計算結果輸出后,通過通信分發、網盤服務等模塊,交由實時數據采集、歷史數據采集、事件數據采集分別進行入庫。最終的數據存儲在單機版HDD磁盤數據庫中。后續分析評估系統通過檢索實時庫、歷史庫、事件庫,提供各類評估結果。

圖1 原有數據采集管理機制總體結構Fig.1 Structure of original data collection and management mechanism

1.2 原有數據采集管理機制存在的問題

不可否認,原有機制采用這種結構有其優點:1)結構簡單清晰,便于理解和實施;2)推演模型子系統和分析評估子系統共用一套數據庫,相互之間不存在數據延遲問題;3)單機版數據庫便于維護,故障率低。

推演規模較小時,原有系統結構發揮了很好的支撐作用,一直以來運行良好。但隨著推演規模的不斷增大,推演數據量呈指數級增長,并且對分析評估的時效性要求不斷提高,原有數據采集管理機制逐漸暴露出一些問題。問題一:推演模型子系統和分析評估子系統共用一套數據庫,如果分析評估子系統大量訪問數據并導致數據庫“假死”,則推演模型子系統也不能正常寫入數據。問題二:單機磁盤數據庫性能有限,如果分析評估子系統進行較復雜的分析查詢,則整個系統會進入“無限等待”狀態,很長時間不能輸出評估結果。問題三:推演模型子系統推演過程中會形成許多推演分支,各分支之間有大量的交叉數據,如不進行處理,將導致統計結果失真。以前對多分支數據的管理方式為手工在控制臺輸入命令進行分析和去重,效率低,工作量大,易出錯。問題四:原有分析評估應用所有分析結果都直接查詢原始數據,來自不同席位的多次重復查詢導致大量資源浪費,同時查詢效率低下。問題五:由于服務重連等原因,原始輸出數據中存在重復記錄等錯誤;而原有系統不進行糾錯直接入庫,導致分析結果嚴重失真。

針對這些痛點,兵棋推演系統的底層數據管理機制必須要進行重新設計,研發專用數據采集與管理平臺。

2 新的數據采集管理系統總體結構設計

新的兵棋推演實時數據采集與管理系統包括數據采集、數據管理和數據服務3個子模塊,總體架構如圖2所示。

圖2 兵棋推演實時數據采集與管理系統總體架構Fig.2 System architecture of real-time data collection and management system

數據采集模塊采用基于總線的實時采集方式,從模型推演數據總線上實時采集態勢信息和事件信息,經解析重組后,交由數據管理模塊進行入庫處理。

數據管理模塊負責對采集到的數據進行清洗,同時對各數據段進行分析,形成精準的分支數據,然后將組織好的數據存儲到分布式存儲平臺和內存數據庫中。該模塊同時負責對各類數據信息進行可視化編輯和管理。

針對不斷變化的實時數據,數據管理模塊設置兩種實時數據備份方式。一是每隔一段時間(默認30 min)自動對實時數據生成快照;二是在推演系統每生成一個檢查點時,同步生成實時數據快照。

數據服務模塊負責對采集到的數據進行進一步加工,形成各系統直接可用的數據集,提供給上層應用系統,減少應用系統再次組織數據形成結果集的開銷。該模塊同時負責在檢查點重啟等操作引起數據分支變化時,將正確的數據從分布式存儲平臺發布到內存數據庫。

各應用系統通過訪問負載均衡下的內存數據庫來查詢和分析數據。內存數據庫的高性能和低延遲特性,保證了各應用系統的訪問效率。

該架構通過綜合管理和內存數據庫技術,解決了應用系統訪問數據時的低效性和準確性差的問題;通過引入分布式存儲平臺,解決了長期運行時大量推演數據的存儲成本問題。

3 各模塊設計實現

3.1 數據采集模塊

3.1.1 功能設計

數據采集模塊根據系統配置信息從數據總線實時采集數據信息,包括配置管理、實時監控處理、實時信息處理、歷史信息處理、事件信息處理等子模塊,如圖3所示。

配置管理模塊對采集數據源進行配置,如對態勢服務節點、事件服務節點信息配置,也包括對采集間隔、監控頻率、推演想定、輸出數據庫等信息配置。

實時監控模塊對采集過程進行實時監控,在線監測數據源更新情況,監測數據處理量、處理速率、模型各服務節點輸出狀態等,保存并提示采集過程異常情況。

實時信息處理模塊主要功能是處理實時信息,并存入緩存隊列;歷史信息處理模塊主要功能是處理歷史信息,并存入緩存隊列;事件信息處理模塊主要功能是處理事件信息,并存入緩存隊列。

3.1.2 功能實現

數據采集模塊的具體實現如圖4所示。

圖4 數據采集模塊程序流程圖Fig.4 Program flow chart of data acquisition module

1)配置管理

程序啟動后,首先讀取配置信息。包括用于確定數據實時性的采集間隔、用于采集程序注冊認證的想定名稱和程序標識碼、用于網盤掛載的網盤服務器IP地址和本地掛載路徑、用于實時信息定時快照的快照間隔、用于服務接收的態勢服務源和事件服務源等參數,以及數據管理模塊用到的實時數據庫地址、賬號,分布式存儲平臺地址、賬號,分支管理服務端地址端口等。

需要說明的是,用于確定數據實時性的采集間隔并不是越小越好。一方面是因為過小的采集間隔將導致程序“睡眠”時間縮短,增加服務器處理負載。另一方面是因為采集的總線數據也不是連續無間隔輸出,而是類似于波浪一樣的脈沖式輸出,既有連續且較小的持續流量,也有集中的“波峰”。采樣間隔在不大于一個“波峰波谷”周期的前提下,越大越好。具體最佳值要根據推演環境現場確定,通常在10～60 s之間。

2)實時監控

配置信息處理完畢后,隨即創建多個子線程/進程,包括用于程序狀態監控的實時監控進程,用于處理用戶終端命令輸入的終端服務線程,分別用于采集態勢數據和事件數據的態勢服務線程和事件服務線程等。然后,注冊各類回調函數,校驗并修正各類配置信息,進入程序主循環。

程序運行期間,實時監控模塊主要負責監控以下信息:采集的數據量和處理速度,生成的結果集數據量,態勢信息源的服務狀態,事件信息源的服務狀態,網盤服務狀態,模型通信分發服務狀態,模型輸出服務狀態。

如果其中有出現異常的,先嘗試進行修復,如果修復不成功,及時進行告警提示。

3)實時信息處理

初始化完畢后,開始接收并處理各類數據。第一批數據(初始化幀),在態勢服務線程連接上態勢服務后立即下發,其中包含各類實體和目標的初始狀態。當前時刻已經經過的模擬時間片數會隨著其中的仿真狀態數據一并下發(后續模擬時間片數的更新也隨仿真狀態下發)。然后通過讀取網盤中保存的初始仿真時間可以計算出當前的仿真時間,這個時間隨后被更新到緩存隊列的各條記錄中。與此同時,網盤中的詞匯表也會被解析到程序緩存中,以便對數據中的各類編碼進行替換。

初始化數據下發完畢后,就開始了正常的態勢數據下發與處理,處理方法一樣,區別僅在于數據量的大小和詳細程度。這些態勢數據最終會被轉換成通用數據格式,存入共享緩存,并隨著時間的推進不斷更新。

4)歷史信息處理

與實時信息的處理過程類似,首先也是接收數據、解碼、格式轉換。然后存入緩存歷史信息處理。不同之處在于對緩存隊列的管理。

處理實時信息時,緩存隊列是不斷更新的,每個實體僅維持一條最新的狀態記錄。而處理歷史信息時,緩存隊列的更新操作被替換成了增長操作。也就是說,如果某個實體的態勢發生了變化,則在歷史信息緩存隊列中,變化后的態勢是作為一條新的態勢記錄插入到緩存隊列中的,而態勢變化前的那條記錄維持不變。

歷史信息會設置對應的數據段號字段用于記錄各條數據歸屬的數據段,而實時信息是沒有這個字段的。

5)事件信息處理

事件信息的處理與歷史信息類似,也是變化信息被作為新的紀錄插入緩存隊列;不同之處在于每條事件信息自帶事件發生時的仿真時間,不需要額外計算仿真時間。同時,后續過程中數據段號的計算也是依賴于這個自帶的仿真時間,而不是像歷史信息一樣,依賴于當前仿真時間。

3.2 數據管理模塊

3.2.1 功能設計

數據管理模塊對不同分支的數據進行管理,包括數據段計算、分支樹維護、數據清洗、內存庫存取、分布式存儲平臺存取等子模塊,如圖5所示。

圖5 數據管理模塊功能結構圖Fig.5 Functional structure of data management module

數據段計算主要用于計算各條數據記錄的數據段號,更新該條記錄。分支樹維護主要維護推演數據的分支樹型結構,將新生成的數據段插入分支樹中的正確位置,為后續的數據發布提供計算基礎。

數據清洗主要進行基于哈希鏈的數據去重,以及對各條記錄中出錯的異常、缺失字段進行自動更正(目前還不能對全部字段錯誤全自動處理),其中哈希鏈計算主要用于計算各條數據記錄的組合哈希,存入程序緩存。

內存數據庫存取和分布式存儲平臺存取模塊主要負責將數據組織成對應平臺的數據形式,并進行存取。

3.2.2 功能實現

數據管理模塊的具體實現如圖6所示。

圖6 數據管理模塊程序流程圖Fig.6 Program flow chart of data management module

1)分支樹維護

數據管理模塊啟動后,首先讀取數據段配置文件,構建初始分支管理樹。根據每條記錄的數據段號和父數據段號,確定對應的掛載關系。所有的數據記錄按照各自的數據段號,分別歸屬到不同的分支中,并根據需要,進行相應的數據調度。

后續新的數據段產生后,計算其對應的父數據段號,掛載后形成新的分支結構。新產生的該數據段內的數據,也都歸屬到這個數據分支。

2)數據段計算

對于不同類型的數據,采用不同的數據段號計算方法。首先,實時信息數據由于是不斷更新的,都對應的是最新的數據段,故不計算其數據段號。其次,歷史信息數據在采集完成后,用當前數據段號作為其數據段號。

事件數據的數據段號計算方法略微不同。由于采集完畢的每條事件數據都會包含一個仿真時間,且事件數據存在長時間延遲的情況(比如很久以前的事件數據突然被接收,而此時的數據段號比彼時的數據段號已經變化了很多),所以用事件數據記錄內的仿真時間計算數據段更合適,可以避免直接復制當前數據段號引起的錯誤。根據指定的仿真時間,沿著當前分支在分支樹中查詢對應時間段的數據段號并賦值。如果發生跨分支的情況,則查詢失敗,賦默認值。

3)哈希鏈計算

將整條數據輸入,轉換為字符型緩沖區,然后使用MD5、SHA1、RIPEMD160、CRC32等哈希算法分別計算對應的哈希值,得到組合哈希。然后與程序緩存中的哈希鏈做對比,如果發生沖突則說明是重復數據,進行丟棄,否則轉入下一步處理。

4)異常/缺失字段處理

該模塊主要是對數據中存在的一些錯誤進行自動修正。對數據的修正首先是根據各表之間的關聯關系,通過ID進行關聯后,抽取曾經出現過的合理值進行替換,由于聚類分析、回歸分析、牛頓插值等方法計算量較大,如果每個字段都采用此類方法,則服務器負載較重,且程序吞吐量得不到保證,所以僅在推演結束后才能采用,實時數據采集用的是簡化方法。對于不能通過關聯關系修正的數據,則“一例一案”地采用不同的方法進行修正。

對于錯誤的字段,典型的如事件記錄中,一個事件系列結束后,最后一條記錄的更新狀態應該是“V”,而有些情況下該狀態卻被標記為“UN”,此時就自動地把“UN”修正為“V”。再如實體名稱中,按標準是不允許出現“,”符號的,但某些情況下卻出現了“,”符號,此時根據具體情況,直接刪除或采用“_”替換。

對于缺失的字段,如果是數值型的,一般用0進行填充,如果是字符型的,則用“NULL”或“{INVALID}”進行填充。

由于數據出錯的類型較多,且在不同的環境中會出現不同的錯誤(包括新的錯誤類型),所以此處只是進行了力所能及的修正,并不能涵蓋所有情況。

5)內存數據庫存取

該模塊主要是把緩沖隊列中處理好的各類數據寫入內存數據庫。為提高寫入性能,采用批量寫入的方式。首先,構造基礎SQL語句,循環對寫入緩沖區變量數組賦值,然后,把基礎SQL和緩沖區數組統一提交給數據平臺。對于批量寫入失敗的情況,再區分處理:如果是由于資源競爭引起,則再次嘗試單條逐個寫入;如果是由于數據格式錯誤或底層服務異常引起,則進行錯誤告警。

6)分布式存儲平臺存取

該模塊主要是把緩沖隊列中處理好的各類數據,寫入分布式存儲平臺。由于是同一個采集管理模塊同時支撐兩類數據平臺,所以此處以CSV文件為中介。首先采集管理模塊把要寫入的數據輸出到CSV文件中,然后另外啟動一個進程,將CSV文件“load”到分布式存儲平臺。如此可以保證兩套平臺異步并行處理,不會因一套平臺的某個操作阻塞,而卡住另一套平臺的處理。

3.3 數據服務模塊

3.3.1 功能設計

數據服務模塊主要提供結果集生成和分支數據發布兩類服務,包括基于態勢的結果集生成、基于事件的結果集生成、混合型結果集生成、分支數據發布等子模塊,如圖7所示。生成結果集的目的主要有2個:一是規范分析流程,保證數據和指標都相同時,分析結果相同;二是降低分析時需要處理的數據量,提高系統效率。

圖7 數據服務模塊功能結構圖Fig.7 Functional structure of data service module

基于態勢的結果集生成主要是生成各種對態勢數據簡單分析后得到的結果集?；谑录慕Y果集主要是生成各種對事件數據簡單分析后得到的結果集?；旌闲徒Y果集生成主要是生成需要綜合分析態勢數據和事件數據的綜合型結果集。

分支數據發布主要是根據用戶選定的數據分支或檢查點信息,將正確的分支數據發布到目標庫。

3.3.2 功能實現

數據服務模塊的具體實現如圖8所示。其中,結果集生成的流程如圖8a)所示。當有新的態勢數據加入數據緩存隊列,就啟動一個檢查例程,看是否符合結果集的計算條件,如果不符合則略過該條數據,否則進行相應的結果集生成。

圖8 數據服務模塊程序流程圖Fig.8 Program flow chart of data service module

1)基于態勢的結果集生成

部分結果集僅依賴于態勢數據即可生成。主要有基于字段屬性拆分大表、監控實體態勢拐點等。

對于第一類,將原先數據量較大的一張表,根據指定字段的不同取值,分門別類地放入不同的子表內。如可根據視圖字段,將同一個視圖的數據放入一張表。經過這樣拆分后的數據子表,數據量可降低一個數量級,大大加快在后續統計分析中的響應速度。

對于第二類,按照不同的實體ID,分別監控其態勢變化,在態勢出現拐點時及時進行記錄。比如,監控實體的受損信息,當實體輕微受損、嚴重受損、被修復、被消滅時,分別進行記錄。如此處理后,結果集記錄的都是重要的拐點信息,相比于原始無差別的定時采樣,數據量大大減少,后續分析中不需要再處理無關的背景數據。

2)基于事件的結果集生成

部分結果集僅依賴于事件數據即可生成。主要有基于字段屬性拆分大表、基于事件字段表間關聯等。

對于第一類,類似于基于態勢數據做的大表拆分。如可根據實體類型進行拆分,將不同實體類型的事件數據分開存放,同樣可以減少數據量。

對于第二類,主要是利用程序直接計算的快捷性,將大表關聯后的結果直接寫入數據集,避免后續使用SQL語句進行大表關聯的巨大開銷。如可直接將打擊事件與打擊詳情進行基于事件ID的關聯,結果直接寫入新的詳細打擊情況表。

3)混合型結果集生成

部分結果集需要綜合利用態勢信息和事件信息生成,主要有綜合詳情、關聯分析等。

對于第一類,可按照詳情種類,將對應的事件表與實體表做關聯,結果寫入綜合詳情表。如對于交戰事件詳情,可將交戰事件與實體信息以及詞匯表進行綜合關聯。

對于第二類,可按照分析類型,將對應的事件表與實體表做關聯。如對于火力打擊關聯分析,可首先提取指令事件中的ID等信息,然后與開火事件、實體信息、詞匯表進行綜合關聯。

4)分支數據發布

分支數據發布的流程如圖8b)所示。模塊啟動后,首先讀取分支配置信息,生成分支樹;然后讀取待發布分支信息,并與分支樹作比較,生成目標分支數據段集合;其次讀取源庫和目標庫數據段信息,與目標分支數據段集合作比較,計算出需要刪除的數據段和需要插入的數據段;最后從目標數據庫中刪除需要刪除的數據段,從源庫中將需要插入的數據段插入目標數據庫。

4 新機制與原有機制比較

4.1 新機制與原有機制的不同之處

不同之處主要有以下幾點:

1)原有機制下,推演模型子系統和分析評估子系統共用一套數據庫;新機制實現了數據庫的分離,各自使用自己的數據平臺。

2)原有機制下,數據采集基于通信分發傳輸協議;新機制下,數據采集基于事件服務和態勢服務協議。

3)原有機制下,采用的是單機磁盤庫;新機制下,采用的是結合了內存數據庫和分布式存儲平臺的混合型數據平臺。

4)原有機制下,沒有進行多分支管理,所有數據全部無差別地存放在一起;新機制下,進行了基于數據段的非確定性多分支數據管理,所有數據按照分支樹進行組織。

5)原有機制下,沒有進行數據集的提取操作,所有查詢全部針對原始數據直接進行;新機制下,引入了基于數據集的數據治理方法,絕大部分查詢可以查詢治理后的數據集結果。

6)原有機制下,沒有進行數據去重;新機制下對重復數據進行了去重處理。

7)原有機制下,對缺失字段和異常字段沒有進行處理;新機制下,自動化處理了缺失字段和異常字段。

8)原有機制下,數據存儲上采用的是分庫不分表的存儲方式;新機制下,數據存儲上采用的是分表,但不分庫的存儲方式。

4.2 新機制帶來的好處

對應于以上改進措施,新機制帶來的好處主要如下:

1)模型推演子系統和分析評估子系統數據平臺的分離,確保了相互之間不再因數據平臺而相互阻礙。再也沒有發生過因一方對數據平臺的大量訪問,導致另一方無法運行的情況。

2)數據總線采集協議的升級,保證了新機制下事件數據可以采集多份,提高了安全性和應用靈活性。相比于原機制下事件數據只能寫入一個數據庫,解決了單點瓶頸問題。

3)混合型數據存儲平臺的采用,既解決了單機磁盤庫容量有限的問題,又解決了磁盤型數據庫性能問題。分布式存儲平臺可以存儲海量數據。關系型內存數據庫可以保證數據的高速訪問。

4)多分支管理技術的引入,確保了每次進行分析的都是正確的數據。解決了以往分析評估時,因基礎數據有臟數據而導致的評估結果嚴重失真問題。

5)基于數據集的數據治理,提供了可以直接使用的結果集,不必每次都查詢原始數據,節約了大量資源。同時,由于結果集是以列式存儲方式存儲在內存中的窄表,速度和利用效率更好。相比于原機制下以行式存儲方式存儲在磁盤中的大量寬表,數據訪問性能得到了極大提升。

6)數據去重,缺失字段和異常字段的處理,極大地提高了分析結果的準確性。

7)原有分庫不分表的存儲方式,雖然較好地減輕了數據寫入時的壓力,提高了寫入性能;但查詢時因為有大量的跨庫數據傳輸,且沒有通過分表進行數據篩減,降低了性能。新機制下的分表不分庫,通過杜絕大批量跨庫數據傳輸,同時對單條SQL涉及的數據進行篩減,極大地提高了綜合性能。

5 系統運行結果

在CentOS7.9上,使用C++版eclipse 進行了系統實現,總計約20萬行代碼(不含內存數據庫和分布式存儲平臺部分)。共采集生成了4大類225張數據表。目前系統運行穩定,已支撐多場重要推演。

圖9是系統運行過程中生成的部分數據段配置信息,可見本次運行的分支信息還是比較多的,如不進行處理,將會導致存在大量的重復數據,致使各類統計結果偏離甚至翻倍。

圖9 數據段配置信息Fig.9 Snapshot of data segment info config file

圖10 采集數據量隨時間變化圖Fig.10 The change of the amount of collected data over time

圖11 采集數據總量隨時間變化圖Fig.11 The total amount of collected data over time

圖12 采集數據處理速度隨數據量變化圖Fig.12 The processing speed of the collected data over the amount of collected data

對系統的采集效率進行了測試,數據采集節點測試環境配置為:12 Core 2.2GHz CPU,128GB DDR4 RAM,2TB SSD,華為CloudStack云平臺。圖 10是采集到的數據量隨時間的變化曲線,可見數據分布并不是均勻的,有波峰,有波谷,并且波峰的高度和間隔也是隨機的。圖 11是采集的數據總量隨時間變化曲線,可見呈波浪狀階梯上升。圖 12是系統采集數據時的處理速度,當數據量大時,批處理的優勢體現出來,處理速度較快,數據量小時,基本為逐條處理,沒有批處理優勢,處理速度較慢;但受資源競爭等因素影響,處理速度并不是恒定不變的,也具有一定的隨機性。

對采集后的數據訪問速度進行了測試,單表數據量1億條(總數據量10億條)情況下,count查詢響應時間基本小于0.1 s,簡單組合查詢響應時間約0.2 s,大表間復雜多表關聯操作響應時間在1 s左右。原有機制下,這幾個數值分別為約3 s,約2 min,約7 h(原運行環境配置為16Core 2.0Ghz CPU,16GB DDR4 RAM,4TB HDD)。

6 結束語

從系統運行的實際需求出發,設計實現了基于總線的兵棋推演數據實時采集管理平臺。從實際運行情況看,較好地解決了推演數據實時采集和服務問題?；诳偩€的實時采集和數據清洗,保證了數據采集的速度,提高了采集數據的質量?；跀祿蔚姆种Ч芾?保證了提供給應用系統的數據的準確性。數據集和內存數據庫的采用,極大地提高了應用系統訪問數據的速度。分布式存儲平臺的引入,解決了大批量數據的低成本存儲和靈活檢索。

與原有機制相比,實現了數據采集管理平臺從無到有的轉換?；跀祿蔚姆种Ч芾砗蛿祿逑吹裙δ?都是首次實現,相比于原有機制是零的突破。從整體效果上看,實現的數據管理平臺不管是訪問速度還是數據準確性,以及可支持的推演和評估模式的靈活性,都有了較大的提升。