【摘要】 广播制播网是广播电台节目播出的重要生产业务平台，对系统运行情况及使用行为进行统计分析有利于我们更好的完成系统运行维护工作，也能为系统改造扩建提供基础数据资料。
【关键字】 广播制播网 数据挖掘 使用行为分析
广播制播网是广播电台重要的生产业务平台之一，是一个面向采编播用户的专用局域网系统。为了满足广播新闻资讯节目的互动要求，制播网需要具备栏目翻单衔接流畅，节目即查即点即播等快速操作响应能力。为了保证系统的稳定运行，我们需要对系统运行情况进行检测，包括了解关键服务器的CPU压力、网络负载状况等表象数据，然后采用数据挖掘数据分析的方法，对系统中存在的数据信息进行统计归纳，分析采编播人员的操作行为习惯和相应产生的业务压力，并由此合理调度业务运行时间和运行模式，分散负荷，保证系统的稳定运行，同时也为今后的系统改造提供有力的数据资料。
一. 当前系统运行情况的监测
目前我们的制播网采用的是C/S结构，各工作站只与服务器发生数据交换，各站之间基本没有数据往来，所以对系统运行情况的监测，主要集中在主服务器和网络之间。分析制播网的运行情况，日常的操作行为可以归结为是对音频文件的读写传输操作和对数据库的读写操作，所以我们对系统负荷的监测可以关注于CPU负荷和网络负荷两个方面。
监测工具和实施方法：对服务器的性能监测和记录，最简便的方法就是采用Windows操作系统自带的Perfmon.msc工具。为了不影响被检服务器性能，我们采用设立专门的监测机实现对主服务器的远程网络监测并且实现长时间日志记录。使用远程监测，我们要注意两个方面，第一：数据采样间隔不要太小，建议为3-5秒，这个时间值，既能实现近似实时的监测效果，又不会对被检服务器产生过大的负荷，第二：选择监测的性能对象不要太多，避免对服务器性能造成额外负担并产生测试噪音，干扰对实际运行状态的正确记录。
图1 服务器系统性能曲线
（绿色：CPU占用百分比；红色\蓝色：网络流量，采样周期54小时）
二. 分析系统，确定数据挖掘元素和分析目标
从获得的54小时服务器性能曲线图上，我们可以看出，系统负荷存在有周期性波动，我们是否可以结合制播网系统中存在的资料和操作日志记录，依靠数据挖掘和统计分析的方法，去甄别各自的负荷波峰所对应的操作行为，判断这些性能负荷波动是否真的存在规律，同时实现对制播网的运行情况和使用者操作行为进行量化分析。
数据挖掘（Data Mining）就是从大量的、不完全的、有噪声的、模糊的、随机的实际应用数据中，提取隐含在其中的、人们事先不知道的、但又是潜在有用的信息和知识的过程。见图2。
图2 数据挖掘流程
性能曲线上的波峰我们理解应该是由节目制作、节目发送、节目编排、节目播出等前端使用操作业务或数据库备份、节目同步备份等后台操作作业所造成的。分析目前制播网数据库保存的数据资料信息和音频节目文件信息，我们可以对系统负荷影响较大的节目制作，广告节目制作和编排行为进行统计和分析。同时也能对系统内节目数量分布、节目制作工作量和站点使用量、节目制作和播出间隔时间、录播节目播出数量等相关项目实现定量分析统计（见表1），通过对这些数据的分析研究，便于我们更加了解编播人员的操作使用习惯，合理分配系统后台操作业务。
三. 建表及数据采集
由于分析所需的各种数据分布于文件系统和数据库中，需要自己制作数据提取工具，我们采用了VB6编制数据采样工具，提取所需数据写入ACCESS表，供预处理使用，由于节目资料及操作信息相当多，为了减少每次采集分析的时间，根据不同的分析目标分别建立了Jminfo、Action等一系列表。
下面举个数据采集例子：统计节目播出和录制时间间隔，流程图见图4。
建立节目信息ACCESS表jminfo.mdb，存放从数据库中导出的节目录制时间。由于我们需要对节目录制时间做统计分析，所以分别建立了节目名称（jm_name）、录制日期（rtime）等相应字段。
sNewDBPathAndName = App.Path & "\jminfo.mdb"
Set dbDatabase = CreateDatabase(sNewDBPathAndName, dbLangGeneral, dbEncrypt)
建立表单：
Set tdExample = dbDatabase.CreateTableDef("jm")
建立字段：
Set fldForeName = tdExample.CreateField("jm_name", dbText, 100)
tdExample.Fields.Append fldForeName
Set fldForeName = tdExample.CreateField("rtime", dbText, 20)
tdExample.Fields.Append fldForeName
dbDatabase.TableDefs.Append tdExample
要得到节目文件录制时间有两种方法，一种利用Windows API函数得到音频文件本身的最后修改时间T1以及在服务器上文件创建的时间T2，第二种方式是访问数据库记录得到节目的录制时间T3。正常的节目流程，T1＜T2≤T3（见图3）,但我们在得到这三种时间进行比较时，发现存在T2＜T1≤T3的现象，仔细分析，发现是节目节目同名覆盖造成的。为之后的数据挖掘提供更多分析资料，我们对这几种时间都进行采集。
图3 文件时间信息
首先采集音频文件的时间信息T1,T2。为了得到音频文件原始信息，不能通过离线采样的方式，(异地备份后文件，文件创建时间会变成备份复制时间)，同时为了防止文件扫描对服务器造成读写压力，首先在离线备份服务器上做了采样测试。经过测试，采样访问时离线服务器CPU占用基本在3%以下，网路访问占用速率在200K以下，因此读取文件信息对系统压力不大，可以实施在线采样，读取文件信息并填充jminfo表相应字段（网络占用速率与运行程序的机器配置有关，机器运算速度越快，占用网络速度越高）。
filetime = f.DateLastModified
filectime = f.DateCreated
rs1("jm_name") = Trim(File1.FileName)
rs1("rtime") = Trim(filetime)
rs1("ctime") = Trim(filectime）
rs1.Update
rs1.MoveNext
对于节目在数据库中的录制时间T3、播出时间T4以及其他相关信息采集，需要对制播网数据库内容进行提取采样，运行压力较大（遍历表持续时间较长），为了避免采样过程影响制播网系统的正常运行，需将数据库恢复到测试服务器后使用离线方式对数据进行采样。
四. 数据预处理
图4 数据采集记录节目文件录制及播出时间等信息
根据采集到的数据的偏差情况，需要对数据进行预处理。对采集到的信息进行检查后，我们发现有一批节目时间信息T3＜T2,也就是节目入库时间小于节目制作时间，这个在理论上是不可能的，经过分析，发现此类节目出现在同一台机器的同一个时间范围内，判断是机器时钟不准，且校时软件被关闭，造成数据失准，所以这批数据需要清除，同时第一次预处理时还需要对采集到记录中只有制作时间没有播出时间的节目记录进行清除（有些节目是临时素材，可能永远不会被播出）。第二次预处理是将节目制作时间和节目播出时间相减，得到节目制播间隔时间Δt并写入“Delay”字段中。在这次统计中，间隔时间是按秒计算，计算结果节目播出最小间隔时间为34秒，最大已播节目播出间隔时间为1308722秒（约15天），如果采用条状图“bar”对“Delay”字段作为统计目标进行分析，由于数据过于离散，统计结果不直观，无法得到有说服力的信息（见图5）。
图5 节目制播时间间隔条状图
图6 节目制播时间间隔直方图
如果使用可分组的直方图进行统计分析，由于播出间隔的时间跨度太大，线性的间隔时间取值也没有太大的指导意义。见图6。
图7 计算节目制作和播出间隔数据预处理
所以需要对数据进行非线性规格化再次预处理，将播出间隔按时间段分分为10个时间间隔：A五分钟以内、B五分钟至10分钟、C10分钟至半小时、D半小时至1小时、E一小时至三小时、F三小时至十二小时、G十二小时至一天、H一天至三天、I三天至一周、J一周以后。预处理流程见图7。
五. 数据统计分析
在对数据做完了预处理后，就可以进行分门别类的统计分析。数据分析可以采用多种工具，最简单的使用Excel，其他还有SAS(Statistical Analysis System)、SPSS(Statistical package for the social science)等等，由于本次分析的数据量较大，所以采用了SPSS来对采集的数据进行分析。在对数据进行采集和预处理时，数据保存为ACCESS数据表，但SPSS并不能直接读取此格式文件，所以我们需要先将不同的ACCESS数据表添加为不同的用户DSN或系统DSN。然后使用SPSS软件，连接新建的ODBC源，将数据打开并进行各种图表显示，能得到相应数据的统计资料图。
六. 分析结果
首先从图1服务器性能曲线图上可以看到整体系统的运行负荷是非常不平衡，这要求我们的系统性能要有较大的冗余度，能满足突发工作产生的压力。
图8 节目制作与播出时间间隔
图9 各频道节目播出制作间隔分布
图10 节目制作时间分布（小时分布图）
图11 频道节目数量对比
图12 各频道制播网节目播出数量统计
图13 制编各类站点使用频数统计
图14 各工作站使用频数统计
制播网运行负荷主要由系统后台操作业务和前端使用操作业务两部分产生，系统后台操作业务主要包括服务器端运行的数据备份、分发和同步服务作业，这类作业一般由管理员分配，相对可控和可预测；前端使用操作业务主要包括编播人员在客户端进行节目制作、发送、查询、编排、播出等操作行为，这些操作行为虽然具有随机性和并发性，但通过统计分析还是可以找到规律。凌晨1点至4点及下午13点网络流量较大，原因是系统在进行文件及数据库备份。早晨8点至10点、16点至17点左右服务器负荷也有一个高峰，结合图10，可以发现这两个时段也是节目制作的高峰，采编播人员在集中进行节目制作编排以及广告编排等工作，这些也和我们日常观察到的情况较为符合（见表2）。所以在今后分配新的系统任务时，需要避开已知的几个繁忙时段，保障系统的稳定运行。
从图8、图9上可以看出目前占总体录制节目的15%以上的节目录制结束后一小时以内此节目需要播出，同时40%的节目录制完后将在12小时内播出，同时三个频道都有节目制作完成后5分钟之内播出的记录，这说明广播节目的时效性较强，这就要求我们的系统结构要适应即录即点即播的方式，系统也要保持较高的运行效率。图11是频道节目数量统计图，能较为直观的分析各频道对库容量的不同需求，为系统资源分配提供一个依据。结合图11和图12，发现一个奇怪的现象，虽然系列台5的节目制作量不是很大，但是制播网内节目播出次数却是遥遥领先，通过了解，发现此频道录制的节目滚动播出较多，一条新闻素材在同一天内播出多次，同时采用了同名覆盖的方式，有效的节约了库空间，减少了编排工作量。在图13上看出，录制站是所有站点中使用最多的，今后在系统扩建时，我们还需要加强对录制站的配比。从图14上可以清楚的看到那些站点使用频度较高，以后在增加站点时可以优先考虑这些频道。
通过对性能的检测和数据挖掘和分析的综合运用，我们能对当前的系统运行情况及采编播人员使用情况作一个更深入的量化了解，以后也可以定制更多的统计分析项目，为系统的运维和今后改造建设提供更有力的数据资料。B&P
参考资料：
1. Visual Basic + Access数据库开发与实例 刘文涛编著 北京 清华大学出版社 2006
2. 英文视窗版SPSS与行为科学研究 王保进著 北京大学出版社 2007