【摘要】 廣播制播網是廣播電臺節目播出的重要生產業務平臺，對系統運行情況及使用行為進行統計分析有利于我們更好的完成系統運行維護工作，也能為系統改造擴建提供基礎數據資料。

【關鍵字】 廣播制播網 數據挖掘 使用行為分析

　　廣播制播網是廣播電臺重要的生產業務平臺之一，是一個面向采編播用戶的專用局域網系統。為了滿足廣播新聞資訊節目的互動要求，制播網需要具備欄目翻單銜接流暢，節目即查即點即播等快速操作響應能力。為了保證系統的穩定運行，我們需要對系統運行情況進行檢測，包括了解關鍵服務器的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