油田地震數據處理軟件的模塊迭代規律挖掘

李春生，周志鵬，張可佳，富 宇，劉 濤

(東北石油大學 計算機與信息技術學院，黑龍江 大慶 163319)

0 引 言

目前油田的相關技術人員在利用地震數據處理軟件時所采用的有人工干預的靜態調度策略不具有動態性，沒有考慮到軟件運行的不同時期對節點的各種資源占用具有偏向性，因此可能會造成某些時刻部分節點的閑置或者部分節點負載等問題。而這些大型軟件在運行過程中會調用各個功能模塊，并且每次調用都會向許可服務器發出相應的許可請求，并等待服務器響應請求才會開始調用該模塊。因此在軟件執行過程中會產生大量的許可日志數據。通過利用數據挖掘相關技術對許可日志數據進行處理就可以在一定程度上挖掘出一定業務數據量下軟件執行過程中模塊的迭代規律，結合對節點上的資源監控情況就可以預測出軟件執行過程對節點資源的占用變化情況，為節點的動態調度提供依據[1-3]。

1 相關技術

該文使用Zabbix技術對許可日志文件以及節點的機器KPI數據(內存、CPU利用率等)進行監控，再結合數據挖掘的兩種主要應用技術：關聯規則挖掘和時間序列分析來對地震數據處理軟件執行過程中內部模塊的迭代規律進行挖掘[4-6]。

1.1 Zabbix技術

Zabbix是一個基于web界面的企業級開源監控解決方案，不僅支持對數萬臺服務器、虛擬機和網絡設備的實時監控，還支持對百萬級監控指標的采集。Zabbix主要由Zabbix Server和Zabbix Agent兩個部分組成。它的主要工作原理是Zabbix Agent作為信息采集器部署在需要被采集的主機上，并將采集到的信息發送給Zabbix Server端，Zabbix Server端再將數據存儲在本地的MySQL數據庫中。此外Zabbix還提供十分簡潔的web端進行監控信息的管理[7]。

1.2 關聯規則挖掘

關聯規則挖掘是指挖掘出一個事物與其他事物之間的相互關聯性和依存性。比如說，有趣的“尿布與啤酒”的故事，以美國沃爾瑪超市為背景做的顧客購物車數據關聯分析。分析發現啤酒是跟尿布一起購買最多的商品。這種關聯分析揭示了背后美國人的一種生活習慣，在美國年輕的父親經常需要去超市購買嬰兒尿布，與此同時他們會順手買些自己喜歡的啤酒。根據這種有趣的關聯規則，沃爾瑪超市將尿布和啤酒放到相鄰的位置，大大促進了啤酒的銷量。將關聯規則挖掘應用到油田地震數據處理軟件的模塊迭代規律挖掘中，可以分析出一定業務量下軟件執行時各模塊之間的迭代規律變化。

1.3 時間序列分析

時間序列分析是根據已有的歷史數據對未來可能出現的情況進行預測。比如說，在今年7月份購買華為Mate40的客戶很可能在未來半個月內訂購Mate40的手機殼。將時間序列分析應用到油田地震數據處理軟件的模塊迭代規律挖掘中，可以分析出一定業務量下模塊的迭代隨時間的變化規律。

2 論文模型構建

2.1 模型構建

結合Zabbix技術、時間序列分析和關聯規則挖掘構建油田數據處理軟件的模塊迭代規律挖掘模型。模型分為數據層、控制層和應用層三個層次，具體如圖1所示。

圖1 實驗模型

2.2 模型說明

利用Zabbix技術對地震數據處理軟件執行過程中產生的許可日志數據以及運行軟件的節點的機器KPI數據進行監控和采集，將采集到的源數據存到數據庫中，為控制層做數據分析和規律挖掘提供業務數據。從數據層得到源數據后對其做數據預處理，過濾掉無實際意義的數據,再結合關聯規則挖掘和時間序列分析對油田地震數據處理軟件執行過程中內部的模塊迭代規律進行挖掘，旨在挖掘出各模塊隨時間變化的迭代規律，預測軟件執行的生命周期及各時期所需資源情況，為應用層實現節點資源的動態調度做依據[8-9]。

3 實驗過程

3.1 數據監控及采集

實驗以WGC軟件處理10 G的地震數據為例，利用Zabbix對其許可日志以及機器KPI數據進行監控和采集。

圖2是對WGC軟件的許可日志文件wg-lmgrd_server的采集配置圖。采集方式為Zabbix Agent主動采集，利用Zabbix的log函數：log[file,,,,,

,]，可以記錄許可日志文件的大小和每次修改的時間來保證采集到的日志數據為每次新增的數據。采集頻率設置為每三十秒一次。

圖2 Zabbix采集WGC許可日志配置圖

圖3是運行WGC軟件的某個節點的資源監控配置圖。其中包括Available memory(可用內存)、Total memory(總內存)、Free swap space in %(剩余交換空間)以及Processor load 5 min average per core(五分鐘平均CPU負載)。

圖3 節點資源監控配置圖

圖4是運行WGC地震數據處理軟件的某個節點的可用內存的監控數據折線圖。數據表明，在0:00-8:00節點的可用內存為182.9 G，8：00-18：10節點的可用內存逐漸降低到182.4 G，而18:00-20:00間，可用內存迅速攀升到183.2 G。

圖4 節點內存數據監控折線圖

3.2 數據預處理

由于WGC的許可日志數據量龐大，且包含各模塊與許可服務器之間的許可請求測試數據等無實際意義的信息，因此需要對許可日志數據進行預處理[10]。

通過grep命令對包含UNSUPPORT或DENIED等字符串的無效信息進行過濾，并將數據導入到MySQL數據庫中，再利用sql語句根據對許可請求(out)及許可響應(in)之間時間差是否大于1秒來過濾掉許可請求的測試數據。最終獲取到如表1所示的結構化許可日志數據。

表1 結構化許可日志數據片段

數據表示的具體含義為，用戶qiancq在wgcn042節點上運行WGC軟件，該軟件于20:17:50向許可服務器發送請求，申請調用”D3”模塊，于20:18:34向服務器歸還”D3”模塊的使用許可。

3.3 數據分析

對數據預處理得到的結構化許可日志數據進行時間序列分析以及模塊間的關聯規則分析[11]。數據分析流程如圖5所示。

圖5 數據分析流程

根據數據預處理得到的用戶qiancq在各個節點上運行WGC軟件執行地震數據處理任務所產生的結構化許可日志數據，首先找出軟件執行中過程中節點的使用順序[12]。具體如[wgcn096, wgcn064,wgcn066, wgcn069, wgcn097，…,wgcn005, wgcn121, wgcn118]共92個節點。再挖掘出各節點中具體的模塊迭代規律。這里以wgcn096節點為例，利用sql語句得出該節點執行任務時各模塊的迭代規律,如圖6所示。

從圖6中可以發現，wgcn096節點在執行任務時主要是“cp”、“FQC”、“FOU”、“D3”四個模塊在迭代，而且迭代存在一定的規律，比如都是從“cp”開始“D3”結束，中間“FQC”和“FOU”模塊進行迭代，且存在一些迭代方式重復出現的情況[13-14]。將各種迭代方式用ASCII碼進行表示，就可以將wgcn096節點執行任務時的模塊迭代規律表示成：[A, B, A,…, A, G]。將規則保存到規律庫中，再挖掘下一個節點執行任務時的模塊迭代規律，重復該操作就可以挖掘出當前實驗條件下WGC軟件執行過程中模塊的迭代規律。具體規律如圖7所示。

圖6 節點wgcn096中模塊迭代規律

可以清楚地看到，WGC軟件執行時模塊的迭代規律主要分為三類，第一類是“A”、“B”等迭代方式出現的頻率較高的規律，且模塊迭代次數適中。第二類是從節點wgcn117到節點wgcn107，可以看出在這種類型的迭代規律中模塊的迭代次數較第一類相比明顯增多，且都以“m”或“l”兩種迭代方式開始，中間以“A”、“B”兩類迭代方式交互，最后以“F”、“O”等迭代方式結尾。第三類是從節點wgcn043到節點wgcn118。可以看出在這種類型的模塊迭代規律中迭代頻率明顯減少，到最終只有“U”和“,”兩種迭代方式在進行[15]。

將這三類模塊迭代規律所對應的節點劃分為Ⅰ、Ⅱ、Ⅲ三類，再利用Zabbix監控這三類節點的資源消耗情況。根據統計得出各類節點的內存資源消耗折線圖，如圖8所示。

圖8 內存消耗折線圖

可以看出Ⅰ類節點所占內存比較均衡，基本保持在50%左右。Ⅱ類節點所占內存較高，基本保持在70%左右，但這類節點所占內存的峰值時間較短。而第Ⅲ類節點內存消耗較低，僅占到總內存的20%左右。

3.4 挖掘結果分析

根據以上對用戶qiancq在92個節點上運用WGC軟件處理10 G地震數據的數據分析結果來看，在10 G的作業量下，WGC軟件執行時，其中的模塊迭代方式存在一定規律，且將模塊迭代規律對應到節點上主要分為三類。第一類是以“A”、“B”等模塊迭代方式居多的類型，結合資源的監控數據來看，這種類型所占節點內存資源適中，且內存占用峰值持續時間較長。第二類是以“l”、“m”迭代方式開始，以“A”和“B”迭代方式多次迭代后以“O”、“F”等迭代方式結尾的類型，結合資源的監控數據來看，這種類型對內存的需求較高。第三類是以“U”和“,”這兩種迭代方式低頻交替的類型，結合資源監控數據來看，這種類型對內存的需求較低。

結合以上分析，可以一定程度上給執行油田地震數據處理任務的節點的動態調度做理論依據。比如在WGC軟件執行中期可以根據軟件執行時間以及監控的資源推測出哪些節點上的模迭代規律屬于哪一種類型，判斷它接下來會占用多少內存，任務將在多久后結束，是否可以給該節點分配其他的任務等。

4 結束語

從油田的地震數據處理軟件執行任務時節點資源的固定劃分這一實際問題出發，提出了通過監控軟件執行時生成的許可日志和軟件執行過程中所消耗的資源情況來探究一定業務量下軟件執行過程中其內部的模塊迭代規律和資源占用情況，進而為節點資源實現動態調度提供依據。以WGC軟件為實驗對象驗證了這一方案的可行性。

但是該文只是粗淺地將模塊的迭代規律分成了三種類型，沒有對規律進行更深層次的探討。而且以WGC軟件為背景做的實驗只是從內存資源的角度進行分析，若結合CPU利用率、磁盤剩余空間等節點資源等作為動態調度的依據會使調度更加精準。此外，挖掘出的一定業務量下的模塊迭代規律和實際工作中無法確定的作業量下的實際模塊迭代規律的相關度是比較重要的一點，有待后續做更多的實驗進行探究。