油田地震数据处理软件的模块迭代规律挖掘

李春生，周志鹏，张可佳，富 宇，刘 涛

(东北石油大学 计算机与信息技术学院，黑龙江 大庆 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利用率、磁盘剩余空间等节点资源等作为动态调度的依据会使调度更加精准。此外，挖掘出的一定业务量下的模块迭代规律和实际工作中无法确定的作业量下的实际模块迭代规律的相关度是比较重要的一点，有待后续做更多的实验进行探究。