基于開放平臺的民航大型主機跟蹤數據存儲和查詢

李巍偉，何 寧，王宗強（通信作者），梁紅艷，張 鑫，張 勁

（中國民航信息網絡股份有限公司運行中心 北京 101318）

0 引言

中國民航信息網絡股份有限公司（中航信）運營的民航商務信息系統使用的是基于36位字操作系統（OS2200）的大型主機應用系統USAS，在國外有多家航空公司使用，例如西班牙國家航空公司和斯堪的納維亞航空公司。主機系統的跟蹤數據存儲的是與數據庫恢復相關的重要信息，記錄了主機數據庫的每一次修改和用戶的所有輸入與輸出。跟蹤數據常用于查找故障原因、檢索某個時刻符合某個條件的操作等信息，是中航信在提供民航系統IT服務過程中重要的信息源，不僅是保證數據庫恢復完整性的核心數據，也是應用程序員調試系統BUG以及客戶服務人員處理客戶投訴的重要數據證據。

主機系統直接將跟蹤數據寫入磁盤上的跟蹤數據文件。跟蹤數據文件共有32個，每個文件都有限制寫入的最大數據量。當一個文件寫滿后，會刪除最早的文件后再新建一個文件繼續寫入數據，基本每天覆蓋一輪。主機系統通過定時啟動批處理作業流將跟蹤數據從磁盤文件備份到磁帶。中航信之前使用的主機跟蹤數據工具是廠商專為中航信開發，其他使用USAS系統的用戶所使用的產品也大多類似。由于大型主機設計的限制，跟蹤數據只能保存在主機專用磁帶庫（包含虛擬磁帶庫）上，讀取數據時必須在主機上執行。由于磁帶數據的順序性，無法編制任何索引，且磁帶數據是以“塊”為單位記錄的，而“塊”與實際時間沒有必然的關系，因此跟蹤數據磁帶時，按時間跳轉變成了讀過所有的數據按塊判斷，往回倒退時有可能往回倒一秒鐘的數據大概要花幾分鐘。由于保存同一時間點的磁帶只有一盤，所以同時只能有一個人讀該磁帶，而磁帶機的數量也限制了同時讀取不同磁帶的用戶數量。主機跟蹤數據工具只有有限的固定條件，只能提供簡單條件的查詢，對于更復雜的組合條件就無能為力。隨著主機業務系統松耦合架構的實現[1]，每個業務系統由四個主機分區構成，原本一盤磁帶就可以解決的問題，在松耦合架構實施之后需要同時讀四盤磁帶才能實現，這就占用了更多的磁帶機，磁帶定位所花費的時間更長，人工要處理的情況更加復雜，耗費的CPU資源越來越高。

基于開放平臺的大型主機跟蹤數據存儲和查詢系統（OpenAudit）通過建立一套開放平臺系統，在主機開發數據傳輸軟件，讀取跟蹤數據磁帶，發送到開放平臺服務器。在開放平臺服務器上開發數據接收軟件，接收主機發送的跟蹤數據，壓縮后保存為數據文件。在開放平臺服務器上開發數據查詢軟件，接收客戶端的查詢指令，讀取跟蹤數據文件，返回查詢結果。在主機開發查詢軟件客戶端，以便通過主機測試系統訪問OpenAudit系統。該系統把主機磁帶的順序存儲方式轉變為開放平臺的磁盤隨機存儲格式，再加上其他技術手段，可以大幅提高查找跟蹤數據信息的效率，從而有力地降低了讀取跟蹤數據文件的時間成本，進而提高了故障診斷效率和客戶滿意度。

1 功能設計

OpenAudit系統主要目標是節省主機系統資源并提高跟蹤數據查詢能力和查詢速度，總體設計圖如圖1所示，整體上分為五大部分：數據傳輸、存儲、壓縮、索引、查詢。主機上開發語言為C語言，為提高執行效率，部分代碼用匯編優化。開放平臺上開發語言為Java，數據壓縮部分會用到C++。

1.1 傳輸模塊

該模塊將主機跟蹤數據無損傳輸到開放平臺，主要難點是讀取跟蹤數據磁帶的系統接口和分析跟蹤數據磁帶的數據格式，以及把主機36位字數據編碼為8位網絡傳輸字節。解決的關鍵技術包括：

1）通過調用系統底層接口IOW$功能讀取跟蹤數據磁帶，并分析磁帶的數據格式。采用讀取跟蹤數據磁帶是因為讀取跟蹤數據文件只能在各自的業務系統進行且資源消耗是讀取磁帶的三倍，而讀取磁帶可以選取業務不繁忙的生產系統讀取所有業務系統的磁帶。此外，如果程序出現BUG導致最早的跟蹤數據文件被占用之后，由于系統最多支持32個跟蹤數據文件，將會導致無法創建新的跟蹤數據文件，從而導致對外業務中斷。

2）將主機使用的36位字數據編碼為網絡傳輸使用的8位字節。主機地址空間是以字為單位，而不是開放平臺以字節為單位，所以主機讀取一個字的某一部分效率低于讀一個字，因此編碼方式采用將每8個字的每9位的最高位合并成一個新的字，這樣把每8個字編碼為36字節，而不在主機進行字節操作。代價是當數據不足8個字時要補足8個字，所以傳輸時需要傳輸數據原始長度。因為跟蹤數據磁帶“塊”平均都在幾百個字以上，所以用8個字為邊界多出的代價不大。

3）數據校驗：為了保證數據傳輸準確，將傳輸的所有數據取移位校驗和，并在傳輸結束時發到服務器，由服務器判定數據校驗結果。

4）數據簡單壓縮：由于數據量很大，且存在相當大量的重復數據，直接傳輸會對主機通信模塊以及網絡產生壓力，所以在主機端使用簡單的行程編碼技術RLE[2]進行初步壓縮。該算法由匯編語言實現，以便降低CPU消耗。

5）通過TCP/IP網絡將編碼數據傳輸到開放平臺。主機端采用廠商標準COMAPI接口通過CPCOMM通信模塊傳輸，傳輸使用TCP/IP網絡。為了避免對主機生產核心交換機的沖擊，采用分配專用網卡，配以獨立交換機連接開放平臺服務器的方式。

1.2 存儲模塊

在開放平臺存儲跟蹤數據原始數據并進行壓縮存儲。數據存儲主要解決兩個問題：海量存儲的管理和數據文件格式。主要的難點是建立存儲跟蹤數據的文件格式、文件管理、壓縮算法以及讀取數據文件的接口。解決的關鍵技術包括：

1）壓縮算法：使用高壓縮比的開源壓縮算法LZMA[3]，通過設計壓縮服務器分散計算量并支持未來的容量擴展。由于LZMA算法過慢，所以集群20個服務器使用分布式的壓縮計算。在程序開發中，將開源LZMA庫用JNI支持Java語言。雖然LZMA有Java Native版本,但為了提高速度，使用了JNI調用C++庫。根據計算，相同數量的跟蹤數據使用DEFLATE算法[4]壓縮后的數據量是使用LZMA算法[5]壓縮后的數據量的1.78倍，因此使用LZMA算法。但是LZMA算法的壓縮速度遠遠小于DEFLATE算法。根據計算，使用LZMA算法順序壓縮一盤跟蹤數據磁帶所需的時間是180 min，而系統高峰期每45 min就生成一盤跟蹤數據磁帶，因此使用并行壓縮才能滿足工作的需要，這就需要較多的壓縮服務器。通過對LZMA算法的測算，使用了20臺計算機作為壓縮服務器，使得一盤跟蹤數據磁帶的壓縮時間降到30 min左右。

2）設計一個壓縮服務器并包裝壓縮API接口使調用者可以方便使用集群壓縮分散計算量，同時集群服務器個數支持動態調整。

3）設計分塊壓縮文件格式，解決壓縮文件和隨機讀取的矛盾，建立分散存儲大量文件的管理模式。數據文件以分段壓縮的方式存儲，文件名包含系統、起始時間、時間長度的信息。這樣通過搜索文件名建立文件列表，可以很方便地找到所需文件。維護時將過期文件移到垃圾箱目錄。若重復傳輸已有數據，將原文件移到垃圾箱目錄。建立常駐的維護軟件監控過期文件和過期垃圾箱文件以回收文件系統空間。

4）建立讀取數據文件的接口。在開放端的數據傳輸服務器端負責接收從主機數據傳輸軟件發來的數據，經過解碼，解壓縮還原后校驗。所收到的數據寫入特定的數據文件，保存在存儲中。存儲以卷為單位分配磁盤空間，并自動在各卷中查找適合的空間來存儲新數據文件。

1.3 索引模塊

倒排索引技術（invertedindex）廣泛應用于全文檢索等領域[6]，在針對已知條件進行索引后，查詢效率非常高。通過倒排索引技術，由原始數據編制索引，提高檢索速度。索引的基本原理是以壓縮塊為基本單元，計算給定條件，包括時間與壓縮塊的對應關系，保存為索引文件。查詢時可以通過索引文件計算查詢條件，得出所需數據在哪個文件的哪個壓縮塊中。由于壓縮塊需要解壓縮，所以以壓縮塊為基本單元索引效率比較高。代價是復雜條件計算時，可能索引精度不高。

由于分段壓縮后，壓縮塊內的數據需要經過解壓縮之后才可以讀出，所以倒排索引只針對壓縮塊為單位進行編制。每個文件的每個壓縮塊為一個點，一般每個文件包含3 000～8 000個點，這樣每個索引表包含排序存儲的所有索引項的值和每個值對應的索引點編號表。由于每個索引表經常有50 000到更多值，如果不經處理，整個索引文件會非常大。最終方案是每個索引表中所有的索引點編號表采用差異數值數組和反相差異數值數組的綜合存儲方式，并進行合并。經過優化后，索引文件平均為15 M左右，與數據文件平均2 188 M相比索引文件只占數據文件大小的7‰。

1.4 查詢模塊

通過主機終端運行客戶端軟件驅動查詢服務器提供查詢功能，通過完全表達式化開發讓用戶能夠便捷地讀取跟蹤數據。查詢服務器接收用戶查詢命令，讀取相應數據文件和索引文件，給出查詢結果，并提供完善的日志服務。

查詢軟件在主機的客戶端采用C語言開發，是基于行命令的交互式用戶界面，支持異步中斷功能以便打斷長時間運行的查詢指令，使用多線程使服務器端來的信息與用戶輸入可以同時發生。

查詢條件的表達式化設計以KEY=VALUE列表的格式表示所有用戶可能使用的條件。除倒排索引已編制的條件外，另外增加數據按字匹配、忽略大小寫字符串匹配、正則表達式字符串匹配等，以實現自由表達任何條件。表達式互相可以用(), ＆,表達復雜的與或關系。

2 技術創新

通過在開放平臺實現主機跟蹤數據的存儲和查詢功能，使用相對低成本的開放平臺磁盤存儲主機跟蹤數據，節約主機用于存儲跟蹤數據的磁帶數量和對磁帶庫的需求以節約成本,在以下五個方面實現了技術創新。

2.1 用低成本存儲降低主機生產成本

使用開放平臺的中低端存儲設備，降低了主機對磁帶和磁帶庫的需求量，開放平臺存儲采用RAID技術[7]保證數據不會因為某一塊磁盤損壞而丟失，提高了數據安全性。

2.2 移植主機應用

在開放平臺移植主機應用，處理主機原始數據，有效降低了主機資源需求。采用編碼的方法將36位字的主機原始數據完整地保存在8位字的開放平臺上，并能夠進行數據分析，從而保證處理結果與主機中處理的結果一致。

2.3 分布式壓縮

分布式壓縮可以將原本需要在一臺機器處理的數據分散到其他機器上執行，并將結果組合起來，提高了服務器利用率，降低了應用部署復雜度。分布式壓縮幾乎可以支持無限擴展，且部署無須更改應用程序。

2.4 分段壓縮存儲模式

存儲數據文件使用分段壓縮方式，并設計了通用的分段壓縮文件格式。配合倒排索引，很好地平衡了壓縮與檢索速度之間的矛盾，節約磁盤空間達90%以上。通過隨機讀取磁盤文件的方式快速定位，并通過索引輔助減少讀取的數據量，以提高搜索速度。

2.5 基于表達式的搜索條件設置

將已知條件全部表達式化，而且支持對任何未知條件的表達，所有條件可以進行無限與或組合表達任意條件。實現的基于表達式的搜索條件可以讓用戶不依賴程序開發而描述預定義之外的條件，能夠讓用戶不通過開發就表達任意組合的條件。

3 結語

OpenAudit系統所采用的存儲和查詢方式與基于主機跟蹤數據工具相比，優勢明顯。由于采用倒排索引技術專門編制索引，所以查詢速度比只通過讀取原始數據判斷的主機工具要快很多。當查詢條件與索引條件相符合時，效率最高可以達到傳統工具的幾千倍，一天的數據可以幾秒鐘掃過。在索引效率最高時（這一天中沒有指定條件的數據），該系統得到結果只需要10 s，在索引效率最低時（需要讀所有數據），全天數據需要44 min。如果只查找用戶輸入輸出數據，數據量只有全部跟蹤數據的十分之一，所以效率更高10倍。而主機跟蹤數據工具讀取一天的數據大約需要9 h。

OpenAudit系統提供了更快的查詢速度和更豐富的查詢功能，不僅有效節省主機CPU消耗，而且在生產工作中對解決技術問題起到重要作用，為快速響應用戶需求提供了強有力的武器，有效提升了中航信的服務質量。在該系統投入使用之前，主機系統讀取跟蹤數據工具平均每月330次訪問，每次約50 min，投產之后平均每月完成1 205次訪問，最高的月份達到8 712次。目前主機跟蹤數據工作已經完全轉移到該系統。