流數據處理技術在資源監測網中的應用摘要隨著大數據時代的到來，網絡流量急劇增加，對于網絡資源監測技術的實時性提出了新的標準：在數據規模大且連續到達的情況下能及時響應用戶的請求。傳統的網絡資源監測中采用先存儲后分析的數據處理方式，資源消耗大且處理時間長，在面對大量、高速數據時，不能滿足當前應用對處理能力和響應時間的要求。流數據處理技術這種能直接在內存中對大量的動態數據進行持續處理的技術能極大的縮短處理時間，很好的應對這種大量、動態數據對于實時性的要求，近些年來由于其廣泛的應用前景得到了眾多研究和關注。本文首先分析了流數據目前的理論研究和技術現狀，結合海洋監測的應用背景，構建了一個資源監測網的整體框架，引入分布式流數據管理系統作為數據處理引擎以保證處理性能和響應速度。此外，本文針對流數據處理引擎應用在資源監測網中產生的關鍵問題進行研究：數據流入引擎前的數據異構問題、引擎處理過程中的過載問題、流出引擎后的流數據需持久化問題。對于流數據異構問題，本文參考現有異構數據轉換思路，結合流數據處理技術，建立多種適配器來將多源異構數據轉換成統一標準的格式，使得轉換后的結果能夠被流數據管理系統識別。對流速波動引起的過載問題，本文將負載均衡與降載技術結合起來，在保障系統的穩定運行同時降低了由于直接降載帶來的數據損失。對于流數據需持久化的問題，本文提出了二次存儲的方式，首次存儲通過批處理的方式將動態流數據持久化為數據庫中的靜態數據；二次存儲采用一種基于時間多粒度的存儲策略對于久遠歷史數據進行壓縮，降低數據庫的存儲壓力。本文的研究立足實際項目，應用流數據處理技術來保證資源監測網的實時性、穩定性，并給出一個具有普適性的解決方案。關鍵詞：資源監測網；流數據管理系統；負載管理；降載

ABSTRACTWiththearriveoftheageofbigdata，asharpincreaseinnetworktrafficproposesanewstandardfornetworkreal-timemonitoringtechnologythatwhendataarrivesinlarge-scalecontinuously,thesystemshouldresponsetouserrequeststimely.Whenthedatafromnetworkcomes，thetraditionalnetworkmonitoringtechnologysaveitindatabaseandthenextracteditfromthedatabaseforprocessing.Thismethodconsumessomanysystemresourcesandneedsuchalongtimeforanalysis,thatitcannotmeetthecurrentapplication’srequirementofprocessingpowerandreal-time.Streamdataprocessingtechnologycancontinuouslyprocessalotofdynamicdatainmemorydirectlywhichgreatlyreducetheprocessingtime.Therefore,itcanmeetthereal-timerequirementofthedynamicdatainlargescale.Inrecentyears,streamdataprocessingtechnologyhasarousednumerousstudiesandconcernduetoitswiderangeofapplications.Inthisthesis,weanalyzescurrentresearchandtechnologytheoryofdatastream,buildtheoverallframeworkofaresourcesmonitoringnetwork,whichadoptsdistributeddatastreammanagementsystemasthedataprocessingenginetoensuretheprocessingperformanceandresponsivenessofsystem.Inaddition,westudythekeyissuesfromtheapplicationofstreamdataprocessingengineinresourcesmonitoringnetwork:heterogeneousdatastream,datastreamoverload,streamdatapersistence.Abouttheproblemofheterogeneousdatastream,thisthesisreferstotheexistingheterogeneousdataconversionideasandcombinesitwithstreamdataprocessingtechnologytocreateavarietyofadapterswhichcanconvertmultipleheterogeneousdatasourcesintoaunifiedstandardformat,sothattheconvertedstreamdatacanbeidentifiedbydatastreammanagementsystem.Abouttheproblemofoverloadcausedbyflowratefluctuations,thethesiscombineloadbalancingandloadsheddingtechnologytoensurethestableoperationofsystemwhilereducingthelossofdataduetothedirectloadsheddingcaused.Aboutdatastreampersistenceproblem,thisthesisproposesamethodoftwicestorage,inthefirststorage,dynamicstreamdataisstoredintothedatabasebybatchprocessing;inthesecondarystorage,historydataiscompressedbyatime-basedmulti-granularitystoragestrategywhichcanreducestoragepressureofthedatabase.Thestudyofthisthesis,basedonanactualproject,appliesstreamingdataprocessingtechniquestoensurereal-timeandstabilityofresourcesmonitoringnetworkwhichproposesageneralsolutionandhasthereferencevalueKeywords:ResourcesMonitoringNetwork;DSMS;LoadManagement;Load-shedding目錄摘要 [31]，在在這種降載策略里對每個查詢設置對應的QoS參數，以此來判斷是否需要降載，在確定需要降載后，通過降載載路標(LSRM)確定卸載計劃，向查詢網絡中插入卸載操作符即將在算子完成卸載，理想的情況下丟棄的是那些對查詢結果QoS影響最小的元組。文獻將控制理論應用在卸載控制中，在這個降載方案通過引入分布式模糊邏輯控制，將每個查詢操作符作為監控對象，周期性監測輸出結果的錯失率，將錯失率超過最大容忍值時進行降載，這是處理具有高度動態性數據的一種有效方法。這種將控制理論引入DSMS自適應處理的方法是一種新的嘗試，但也存在有待改進的地方。上述降載策略主要適用于集中式DSMS，并不能很好的解決DDSMS中的過載現象。文獻REF_Ref388266468\r\h[32]針對分布式數據流查詢處理中的降載技術提出了新的觀點，討論了一種綜合考慮所有節點資源約束以及節點間負載依賴性的降載策略，但沒有考慮網絡帶寬限制。2.4異構數據轉換技術在資源監測網中，通常處理需要不同數據源獲得的監測數據，這些監測數據由于被監測的資源不同，在定義和格式上有較大差異甚至完全不同.以海洋觀測網為例，它需要監測光學、電學、傳感器這三大平臺下數十種設備的運行情況，這些設備尤其是不同平臺下的設備之間由于設備本身特性的關系，產生的監測數據完全不同。譬如，電學平臺下的接駁盒需要監測輸入電壓、漏水情況，光學平臺下的光學可能要監測折射率、光功率，傳感器平臺下可能要監測葉綠素傳感器、等等。這些數據之間基本沒有什么共同之處，因此，在集成處理這些流數據時，會面臨諸如無法統一處理、處理效率低下等問題。對于流數據管理系統而言，在集成處理各種異構的流數據源時，所遇到的最大的問題是數據的格式以及類型的匹配問題，所以在數據流如流數據管理系統時需要將各種數據源產生的數據通過一定的算法和技術轉換為流數據管理系統能夠識別的數據格式和類型。目前，解決異構數據的數據類型、格式等方面的差異性問題通常采用的是異構數據轉換技術。常用的數據類型轉換方法有如下幾種：數據庫廠商提供的工具目前，數據庫都提供了中間件來應用程序與本地或異地的同構或異構數據源的數據交換，但這些工具作用范圍有限，使用范圍往往僅限于自己的DBMS訪問異構數據庫，通用性較差。基于EAI的數據交換工具實現數據交換和整合在源數據庫與目標庫之間編寫數據交換程序，數據交換工具通常具備這樣的功能:支持多種類型數據源的抽取：例如可以從數據庫、XML、外部文件、調用webservice等方式抽取數據：支持特定數據轉換規則：支持多種數據加載方式。XML技術XML(ExtensibleMarkupLanguage)即可擴展標記語言，它與HTML一樣，都是SGML(StandardGeneralizedMarkupLanguage)。XML是一種簡單的數據存儲語言，具有純文本格式、結構化描述等特點，簡單易用。因此XML易于在任何應用程序中讀寫數據，這使XML很快成為數據交換的一種公共語言。本文采用XML作為數據集成的標準，通過實現各種轉換組件將各類數據源進行格式和數據類型的轉換后再讓它們進入流數據管理系統，為基于流數據處理的各種功能提供了基石。2.5本章小結本章首先對流技術進行概述，介紹了流數據的基本概念和模型，并將流數據的處理模型與傳統數據處理模型進行對比，指出兩者具有本質上的區別。然后對現有流數據管理系統，流數據負載管理技術，異構數據轉換技術這三方面的技術現狀進行較全面的分析，為下一章的研究工作奠定了理論基礎。海底觀測網中流數據處理問題海底觀測網背景需求海洋監測發布技術是海洋科學領域重要組成部分，在維護海洋權益、開發海洋資源、預警海洋災害、保護海洋環境、加強國防建設、謀求新的發展空間等方面都有著重大意義。海洋監測技術發展水平也是衡量一個海洋強國的重要標志，因此我國政府非常注重對海洋監測技術的扶持，并將其列為國家863計劃的一個主題，在“九五”、“十五”期間持續加大對海洋監測技術研究的投入力度，旨在加強海洋監測高技術研究，提高對海洋環境的監測和保護能力，并支持海洋資源開發和海上國際建設。本論文的研究依托于863計劃海底觀測網試驗系統項目的課題任務“觀測網絡故障診斷與遠程維護系統（2012AA09A410）”，簡稱海底觀測網故障診斷平臺，它接入光學、電學、傳感器三大平臺下物理設備采集的監測數據來監測設備的運行情況，并在此基礎上進行故障診斷。海底觀測網故障診斷平臺設備數量大、種類多，且主要儀器與設備均工作于海底環境，通過光電纜與海岸基站進行電力和通信連接。由于海底工作環境復雜，傳輸光電鏈路長，外力致損因素多，海底觀測網的故障模式和機理非常復雜，海底傳感、探測儀器及其他海底設備相對陸地更容易出現運行故障，而且儀器與設備運行維護難度大、成本高，故障修復困難，維修成本極為昂貴。針對該種情況，需要對海底觀測網絡水下個環節進行監測和故障診斷，監視海底設備儀器運行狀態，防止異常運行狀態持續而導致嚴重故障發生，在故障不可避免地發生時，進行一系列保護響應機制，及時將故障情況通知相關人員來及時排除故障。從應用背景來看，海洋監測面積較大、范圍較廣，監測數據具有快速、無限、連續、速率不斷變化、實時的特點，是典型的流數據。從數據內容來看，它具有多源多格式、時間跨度大的特點，而基于互聯網或局域網對這些數據的訪問又有速度、效率、可用性等方面的要求。綜上，該系統具有以下特點：第一，數據規模大，且持續不斷增長；第二，數據具有顯著的大時間跨度、多源、多類型、海量、異構特性；第三，系統的實時性和自適應性求高。3.2海底觀測網功能概述由背景需求可知，本文中海洋監測與故障診斷系統需要建立一套完整的設備監控和故障診斷系統。該系統將接入光學監測平臺、電學監測平臺和傳感器監測平臺，通過數據的實時采集和處理分析，對海底觀測網試驗系統的海底光電纜、主次接駁盒、各類水下傳感設備及岸站供電情況進行全面監測，具備對水下設備運行狀態、光電信號采集設備進行故障檢測與診斷、異常信息告警、典型故障定位等功能，為提升海底觀測網絡的長期可靠性提供支撐。系統主要功能有設備狀態展示、故障展示、故障決策與分析、數據回溯與分析。3.2.1設備狀態展示展示光學子系統、電學子系統及其它各種傳感器的基本位置信息和運行狀態。具體功能點如下：展示光纜、岸基設備、主接駁盒、次接駁盒、各設備的物理拓撲信息及基本設備信息；能夠新增、修改或刪除設備，對設備的基本信息和位置信息進行修改；顯示設備的最新狀態，設備共有四種狀態：在線、正常、故障、離線。3.2.2故障展示展示設備的故障信息，根據故障類型（正常、一般故障和系統故障）對設備進行不同顏色的故障標識。具體功能點如下：在拓撲圖上能夠對故障詳細信息進行查看，能夠檢索歷史故障信息；顯示設備的最新故障信息。3.2.3故障決策根據光學、電學和傳感器三大平臺提供的監測指標、分析規則和閾值對各設備的故障檢測規則進行配置。具體功能點如下：針對不同的監測設備，能夠增加或修改故障檢測規則，以方便后期進行檢測設備的擴展；配置故障處理策略，能夠將故障信息以電子郵件和短信的方式發送給相應的值班人員，實現無人值守功能。3.2.4數據回溯與分析回溯某段時間的歷史數據，基于狀態監測數據和故障數據，實現歷史信息統計和數據分析功能。具體功能點如下：能夠以餅狀圖、柱狀圖、折線圖等多種方式對設備統計信息、歷史告警信息進行展示，用戶可選擇的統計項目前考慮有：時間、設備、故障級別、電學設備（過壓、過流、溫度、漏水、接地等）；根據特定統計分析算法，能夠對各種故障數據進行分析和科學研究。3.3關鍵問題分析3.3.1流數據多源異構問題海底觀測網故障診斷平臺需要監測采集的物理設備關系如圖3-1所示，監測數據來源包括三大平臺，共分為五大類：岸基監測站、岸基供電、主接駁盒、次接駁盒、傳感器。其中，光學平臺下的設備包括岸基監測站，監測光纖的工作狀態。電學平臺下的監測設備包括：岸基供電站、主接駁盒和次接駁盒。圖3-1物理監測設備關系圖由圖3-1可知監測設備種類繁多，提供的數據類型和格式也相差較大。以電學平臺下的數據為例，具體的內容見下REF_Ref386810095\h表31：表3SEQ表\*ARABIC\s11電學監測數據內容被監測設備監測模塊觀測量岸基供電站自動轉換系統狀態UPS系統工作狀態、單個電池電壓、電池狀態、輸出電壓、輸出電流、輸出功率、輸出視在功率、輸出電壓負載、溫度主電源柜工作狀態、電壓、電流副電源柜工作狀態、電壓、電流主接駁盒整體工作狀態電源腔輸出電壓、輸出電流、4路溫度檢測控制腔輸入電壓、輸入電流、濕度、2路漏水檢測、4路溫度檢測下接次級接駁盒1是否使用、輸出電壓、輸出電流、接地電阻下接次級接駁盒2是否使用、輸出電壓、輸出電流、接地電阻下接次級接駁盒3是否使用、輸出電壓、輸出電流、接地電阻下接次級接駁盒4是否使用、輸出電壓、輸出電流、接地電阻次接駁盒整體是否使用電壓轉換腔濕度、2路漏水檢測、4路溫度檢測控制腔輸入電壓、輸入電流、濕度、2路漏水檢測、4路溫度檢測負載1（地球物理平臺）是否使用、輸出電壓、輸出電流、接地電阻負載（傳感器平臺）2是否使用、輸出電壓、輸出電流、接地電阻負載（傳感器平臺）3是否使用、輸出電壓、輸出電流、接地電阻負載（傳感器平臺）4是否使用、輸出電壓、輸出電流、接地電阻由REF_Ref386810677\h表31電學監測數據內容可知同一平臺下不同設備提供的監測數據格式就有一定的差別，不同平臺之間的數據差異更明顯，不但數據結構不一樣，連編碼都不同。總之,光學、電學、傳感器三大平臺由于其物理設備的差異性導致其下采集數據在編碼、內容、格式上都有較大差異，這樣在流入系統時無法統一處理，增加系統的復雜度，降低通用性。因此在這些格式各異的數據流入流數據引擎之前，需要對它們進行預處理。預處理時考慮通過適配器按照配置文件中定義的格式，將外界應用領域中的各種數據源轉換成流數據管理系統能夠識別的流(Stream)。如果系統需要增加新的采集數據種類只需要增加對應的輸入適配器和配置文件，其他地方無需改動。由于數據源種類繁多，訪問數據源的方法也多種多樣，因此，不可能構建一個通用的適配器來處理任何類型的數據源，目前的解決方法只能是根據特定的數據源設計相應的適配器。另外，從整個系統的層面來看，流數據管理系統的處理效率和實時性是非常重要的。如果流數據處理引擎無法實時處理完各個數據源不斷到來的數據，那么就只能堆積到各個適配器的緩沖區隊列中，隨著時間的推移和流數據速率變化的無常，這種趨勢變得更為嚴重，致使整個系統資源的耗盡以及系統癱瘓。因此，在流數據處理研究中，很多研究者提出了有關流數據負載管理的一些技術能夠較好的解決了此問題。3.3.2流數據需持久化問題流數據經過流數據處理引擎處理過后無法再次被讀取，若想追溯歷史數據此時會用傳統關系數據庫來存儲數據。一般來說，關系數據庫僅存儲用戶感興趣且重要的樣本數據或者統計數據，這使得數據所占用的存儲空間明顯減小。雖然大型關系型數據庫能夠存儲和管理海量數據，但是這種靜態數據規模的增長遠遠不能夠與動態數據規模的增長相比擬，且隨著時間的延續累積的數據將呈爆炸式的增長，因此同樣需要耗費海量的存儲空間。暫時只考慮電學平臺中某個次接駁盒來進行數據規模估計，原始監測數據到達速率為每秒一條。一天下來累計的數據量為：30條/m*60m*24H=43200條/天。一個月累計的數據量為1296000條。這才僅僅是三個平臺下一個被監控資源的數據量，若是所有的流數據累計起來數據規模在日積月累之下會達到怎樣的程度，可想而知。由于本文中存在對歷史數據回溯的需求，如何有效的存儲流數據，盡可能的減少數據庫資源的開銷成為本文中值得研究的一個問題。從REF_Ref386906310\h圖32中可以看出，流數據的應用中，數據具有很強的時效性，隨著時間的延續，離當前時間越遠的數據，用戶的興趣度越低，而且對于遠期的歷史數據或近期的歷史數據，用戶大部分只關心統計信息。因此，本文充分考慮了數據的時效性，并根據數據的時效性，以時間粒度為單位。對不同時間粒度的數據進行統計分析并存儲相應的統計結果，目的是為了進一步降低存儲空間。圖32數據時效性按照時間粒度選取值的大小可以將其分為粗時間粒度和細時間粒度。對于不同的應用，時間粒度的劃分沒有一個統一的標準。比如常見的劃分按秒、分鐘、小時、天、周、月、季度、年為單位。如圖3-2所示，根據用戶的興趣度，將產生的流數據劃分為當前流數據、近期歷史數據和遠期歷史數據。例如，在網絡流量監控應用中，用戶關心近期某天的流量變化情況時需要查詢詳細的記錄；然而對于上一個季度、上一年或更遠時間的數據，用戶僅僅只需要這個時間段內的平均流量、總流量等統計信息。在本系統中用戶會關心近期某天的監測數據具體數值，但是對于上一季度、上一年或者更遠時間的數據，用戶只需要這段時間內監測數值的分布規律。由下表3-2可知，將原始數據轉化成統計數據之后，不同粒度下數據規模可以壓縮的程度。表3SEQ表\*ARABIC\s12壓縮程度表累計時間時間粒度記錄數范圍1H2s1800—4320012H20s4320—432001D30s28800—432002D60s21600—432005D200s12960—4320010D10m14400—4320020D30m14400—345601M1h10800—259203.3.3流數據過載問題對于流數據管理系統來說，由于流數據本身具有速率多變且無法預知的特點，如果數據輸入在短時間內急劇增加達到一個高峰，就可能導致系統處理性能下降，處理時延增大，影響輸出結果的實時性，如果負載一直持續下去甚至會耗盡CPU、內存等資源導致系統崩潰。本文中采用的是分布式流數據管理系統，當負載過高時，首先將它作為一個分布式環境下的過載問題，可以采用負載均衡技術將高負載節點的算子向低負載節點遷移，從而達到降低部分節點的負載的目的；此外還可以把它當作流數據處理中的過載問題可以采用降載技術來降低整個系統的負載。負載均衡技術主要是通過節點之間的算子調度來實現，由于查詢算子在節點間的遷移會帶來較大的副作用，需要一定的時間和資源消耗，但是可以保證所有的數據都能得到處理。當系統中所有的節點均過載時，不存在進行算子遷移的空間，此時負載均衡失效。降載技術降低負載的原理是按一定的比率拋棄尚未處理的數據，調節速度快效果明顯，但是損失部分數據，對數據的準確性造成負面影響。綜上所述，考慮可以將兩者結合起來可以形成一個完整的在分布式負載管理模型，能夠將兩種負載管理技術的優點結合起來。負載模型的設計與實現降載第四章中進行詳細介紹。3.4本章小結本章首先介紹了海洋資源監測網的研究背景，基于海底光電纜、主次接駁盒、各類水下傳感設備及岸站供電情況進行全面監測這一基本需求，描述了系統的功能模塊，并就應用背景分析其數據特點和對系統的要求。由于監控設備種硬件不同，決定了采集的數據格式、編碼都有所不同，因此海洋監測流數據具有的多源、異構特性。由于數據具有爆發性不穩定性的特點，因此在短時間內輸入數據急劇增大時，系統會面臨過載問題。由于存在對歷史數據進行分析的潛在需求，系統需要具備歷史信息回溯的能力，因此需要將流數據持久化至數據庫中。綜合以上分析，本章提出了有待解決的三個關鍵問題是：流數據異構、流數據過載、流數據需持久化，在詳細分析了三個問題后，給出了基本的解決思路，在下一章中將給出具體的解決方案。4.海底觀測網架構設計與實現4.1海底觀測網總體結構設計4.1.1設計目標資源觀測網的整體架構設計的目標是，以流數據管理系統為核心，向下通過數據轉換方法解決數據多源異構的問題使得流數據管理系統能統一處理源自各地的數據；向上流數據管理系統能給用戶提供實時的查詢結果，為系統提供決策支持；同級將流出的流數據持久化到數據庫中，作為歷史數據回溯來源。4.1.2系統分層結構設計本海底觀測網故障診斷平臺從總體結構來看從頂向下一共分為四層：應用層、流數據處理層、數據預處理層、數據采集層。這四層中最核心的是流數據處理層與數據預處理層。系統整體結構見REF_Ref386635000\h圖41系統整體架構圖。圖4SEQ圖\*ARABIC\s11系統整體架構圖下面對系統分層結構做下簡要介紹，系統一共分為四層：應用層應用層主要為具體各種實際功能，狀態監控、故障策略、數據回溯等各種實時監控與分析應用提供豐富的交互式接口，根據用戶的需求提供包括獲取數據、注冊連續查詢、獲取流數據處理層的數據處理服務等。流數據處理層流數據處理層本文采用分布式流數據管理系統作為數據處理引擎，并采用一定的降載側路使得系統具有良好的自適應性，它是整個系統的核心。向上，它為應用層提供處理好的信息服務；向下，接入預處理層，獲取應用層所需的各種基礎數據。此外，對于流出數據處理引擎的數據不是直接丟棄，而是持久化到關系數據庫中作為歷史數據參考。設計良好，高效地的流數據管理系統至關重要，因為流數據管理系統是整個系統的數據處理引擎，它的延遲、響應時間、性能以及支持的各種處理操作直接影響到各種應用的實時性以及服務質量。數據預處理層數據預處理層的主要功能是對多源異構的數據進行預處理，將不同數據源的數據由對應適配器處理成統一格式，便于流入流數據引擎之后的處理。數據采集層此層通過網絡傳輸接入三大平臺下分布在各處的設備采集的監測數據，為數據預處理層準備數據。下文首先介紹流數據處理層與數據預處理層主要功能和結構，然后給出流數據異構、流數據過載、流數據需持久化這三個關鍵問題的解決方案，對于應用層和數據采集層不在此贅述。4.2數據預處理層數據預處理層由適配器管理模塊和多種適配器構成的，主要功能是解決流數據多源異構問題，其結構如圖42所示。監測數據流入預處理層后，適配器管理模塊根據數據類型指派對應的適配器進行轉換，轉換后的數據具有統一的編碼方式和類似的結構，能被流數據處理引擎識別。具體的數據轉換過程見4.4小節。圖42數據預處理層結構圖4.3流數據處理層流數據處理層是整個系統的核心，本層主要分為流數據管理系統與流數據存儲模塊兩部分。流數據管理系統通過用戶注冊的連續查詢從這些流中實時獲取有用的信息和知識，最后將查詢得到的結果輸出給相關應用和模塊。流數據存儲模塊考慮到數據回溯的需求將處理完畢的流數據存儲到關系數據庫中，并通過基于時間粒度并采用以統計值信息替代原有詳細信息的這種二次存儲方式進一步降低數據庫的存儲壓力。在流數據管理系統中最關鍵的部分是基于響應時間的降載機制。由于應用背景中存在爆發性數據的情況且應用對系統的實時性有一定要求，系統必須能自適應的應對過載的情況，在系統正常運轉的情況下盡可能的保證響應時間。基于響應時間的降載機制是為了應對本文需求而提出的最適合的降載方式。可以看出流數據處理層扮演者引擎的角色，它連續不斷的獲取數據并連續不斷的抽取有用信息給用戶，故本文將流數據管理系統稱之為流數據處理引擎。流數據存儲模塊主要實現流數據的首次存儲及二次存儲。首次存儲將流出引擎的數據緩沖到一個工作緩沖隊列中，當隊列達到一定長度時通過批處理的方式一次性把數據插入到關系數據庫中。二次存儲將時間久遠的歷史數據根據不同時間粒度得出其統計值，并且不斷用粗粒度的數據代替細粒度的數據，從而達到節省存儲空間的效果。4.3.1流數據處理引擎本文中采用第二章中介紹的Borealis這個開源框架作為流數據處理引擎，在它的基礎之上加入了負載管理模塊來應對降載問題，負載管理模塊的設計和實現見4.5這一節。4.3.2流數據存儲模塊為了日后進一步對數據的分析和挖掘，本文存儲模塊聯合傳統的數據庫實現對于流數據的存儲。存儲方式分為首次存儲和二次存儲。數據存儲模塊將流數據處理引擎流出的數據通過批處理的方式存儲到關系數據庫中，此為首次存儲。對于關系數據庫中的靜態數據，通過一定的計算方式不斷用粗粒度的數據代替細粒度數據從而壓縮存儲空間，此為二次存儲。存儲模塊的具體實現方式見4.6小節。4.4流數據異構問題解決方案流數據異構問題的解決方案是通過適配器對數據進行轉換，在預處理層中，每一類資源有一個XML配置文件，該配置文件指明了相應的資產對象資源采集數據的信息。由于不同平臺資源的上報數據協議不一致，上傳的數據類型會有變化，相應的配置信息也會有所區別。不同的資源采集數據需要不同的適配器及相應配置文件，適配器通過讀取配置文件里的信息，將源數據轉化成具有相似格式的數據，再傳遞給流數據處理層。4.4.1配置文件配置文件ConfigXml采用xml的格式作為載體，里面定義了資源類型、采集時間、信息版本等通用信息。此外針對不同的資源類型配置文件中還定義了資源特有信息，下面以電學平臺下的岸基電源為例來描述一下配置文件的具體內容。將配置文件分為兩部分來介紹。配置文件第一部分如圖4-3所示，主要定義了數據源的基本信息，數據類型、接收地址、接收端口等等。<?xmlversion="1.0"encoding="UTF-8"?><DetailTaskOrigTaskID="1"> <ObjectInfo> <TaskTypeID>1</TaskTypeID><?xmlversion="1.0"encoding="UTF-8"?><DetailTaskOrigTaskID="1"> <ObjectInfo> <TaskTypeID>1</TaskTypeID>//任務類型，表明是哪類平臺數據 <DistrictID></DistrictID> <SystemID></SystemID> </ObjectInfo> <TaskInfo> <DataRecieveID>1</DataRecieveID> <LocalHost>14</LocalHost> <SensorIDname="ShorePower">10001</SensorID>//具體數據類型 <SensorIDname="MainJunction">10000</SensorID> <SensorIDname="InferiorJunction">10003</SensorID> <SensorIDname="ShorePowerBoundary">10004</SensorID> <SensorIDname="MainJunctionBoundary">10005</SensorID> <SensorIDname="InferiorJunctionBoundary">10006</SensorID> </TaskInfo>配置文件第二部分如圖4-4所示，定義了被監測資源的詳細信息，如輸入電壓（RealOutputV）、輸出電流（RealOutputV）、工作狀態（WorkingState）等等。<ObjectScanInfo><ObjectScanInfo><ObjectInfoTypetype="ShorePoewer"> <MessageBody> <Headoffset="0"size="1"type="A"></Head> <Modeloffset="1"size="1"type="A"></Model> <Timeoffset='2'size="14"type="A"></Time> <ShorePowerIDoffset="16"size="6"type="A"></ShorePowerID> <RealOutputVunits="KV"offset="22"size="3"type="A"></RealOutputV> <RealOutputIunits="A"offset="25"size="3"type="A"></RealOutputI> <DischargePowerunits="KW"offset="28"ze="3"type="A"></DischargePower> <Reservedoffset="31"size="2"type="A"></Reserved> <FaultFlagoffset="33"size="1"type="A"></FaultFlag> <PowerStateFlagoffset="34"size="1"type="A"></PowerStateFlag> <WorkingStateoffset="35"size="1"type="A"></WorkingState> <InputVunits="V"offset="36"size="3"type="A"></InputV> <InputIunits="A"offset="39"size="3"type="A"></InputI> <OutputVunits="V"offset="42"size="3"type="A"></OutputV> <OutputIunits="A"offset="45"size="3"type="A"></OutputI> <BatteryToUPSunits="V"offset="48"size="3"type="A"></BatteryToUPS> <CheckSuoffset="51"size="2"type="A"></CheckSum> <EndFlagoffset="53"size="2"type="A"></EndFlag> </MessageBody> </ObjectInfoType><ObjectScanInfo>圖44岸基電源配置文件第二部分4.4.2工作流程適配器工作的原理是讀取配置文件中得信息，按照其定義的模式解析源數據并重新組裝。為了提高效率，實際應用中將配置文件的信息在系統啟動時調入內存常駐，適配器直接從內存而不是文件中讀取配置信息。工作流程如下圖4-5所示：圖45適配器工作流程適配器在處理異構數據的基本算法如下：輸入：各種異構數據流數據：統一格式的數據流算法處理過程：連接輸入流讀取數據源中一條元組適配器獲得配置信息通過配置信息里定義的輸入流的模式來解析該元組各個字段，重新組裝該元組寫入到流中斷開連接4.5流數據過載問題解決方案4.5.1負載管理模塊設計對于海底觀測網故障診斷平臺來說，準確性和實時性是最重要的兩個性能指標。在現實情況下，由于系統資源的有限，而數據的速率不可知，為了保證系統的自適應性以及提供實時服務的質量，系統過載的情況下需要采取一定措施來保證系統能繼續穩定運行。本文中通過一個負載管理模塊來解決系統過載問題。本文提出的負載管理模塊是以中心節點為基礎的，負載管理模塊的結構如下圖4-6所示。圖46負載管理模塊結構中心節點的負載管理器是整個負載管理系統的核心，負責一切負載管理的決策，包括負載平衡、降載措施等。負載管理器通過負載監測模塊收集其他處理節點的負載信息，并根據設置好的策略做出決策，然后通知處理節點執行。負載信息由處理節點的狀態統計模塊通過網絡發送而來。處理節點的降載管理和負載平衡是負載管理的最終執行模塊，他們接收中心節點發送過來的決策信息，然后對本地查詢處理器中運行的查詢網絡做出調整：如果是負載平衡，則需要去活一些算子，或激活一些算子；如果是降載措施，則在某些算子前插入一些過濾器。負載監測模塊我們將處理節點中的狀態統計和中心節點的負載監測統一稱為負載監測模塊。狀態統計模塊監測單位時間內節點每條輸入數據流的數據輸入量，計算每個查詢算子的負載以及該節點運行的本地查詢網絡片段的負載；統計每個算子流入和流出的數據量，計算其選擇度；并周期性的將統計信息發送到中心節點。中心節點的負載監測模塊負責收集所有處理節點發送過來的負載信息，并將該信息整理映射為系統需要的數據，為負載決策做準備。具體而言，該模塊需要提供如下功能：（1）單位時間內輸入數據量（即數據流速率）監測；（2）查詢算子負載監測，本地連續查詢網絡片段負載監測；（3）算子選擇度統計；（4）處理節點負載信息收集；（5）信息整理映射。中心節點的負載監測模塊中還存有一些系統元數據，這些元數據指明了分布式系統的資源信息，包括其每個節點的可用CPU資源以及可用網絡帶寬等。負載管理器通過這些元數據和監測的負載信息來衡量網絡是否出現負載不平衡、是否過載。負載管理器負載管理器是負載管理系統的核心，把收集到的負載信息用一些負載模型進行抽象，根據指定的策略做出負載決策。負載信息由負載監測模塊進行抽象映射后，送到管理中心。管理中心根據負載信息和元數據決定何時需要對系統負載做出調整。做出決定后，調用模型管理中的相關負載模型（如負載平衡模型、降載模型，具體見后文）進行計算，然后把模型計算得到的結果轉化為對查詢網絡的調整，把相關信息發送到處理節點執行決策，對整個系統的負載做出調整。負載平衡模塊負載平衡模塊主要用于執行中心節點發送過來的平衡決策，他對本地查詢處理器中的查詢網絡做出調整，激活或去活某些算子，并把算子的輸入輸出數據流向做出一些調整。這些信息都由中心節點發送過來，負載平衡模塊主要負責實現。這實質上是利用了查詢網絡的模塊化設計對外提供的一些接口。負載平衡將負載在節點間均衡分配，目的是為了提高系統資源的利用率，增強系統的處理性能。具體而言，該模塊需要提供如下功能：（1）去活/激活某些算子；（2）調整算子數據流向。降載模塊降載管理模塊的主要任務是在本地查詢網絡中放置、停止一些過濾器，并負責對這些過濾器的管理。過濾器是對降載措施的一個抽象描述，他指出了什么時候，在查詢網絡的什么地方，通過某種策略丟棄多少元組才可以使系統負載處于正常狀態。具體而言，該模塊需要提供如下功能：（1）管理過濾器；（2）放置/停止過濾器，調整過濾器的過濾度。4.5.2負載管理模型的工作機制在本文設計的負載管理模型中，處理節點上的狀態統計模塊監測節點的負載情況以及算子相關信息，并周期性的將統計信息發送到中心節點，中心節點在接收統計信息后由負載管理器按照一定的處理模型判斷系統是否過載，如果過載需執行負載均衡還是執行降載。本文通過一個節點的CPU使用率來衡量它的負載程度，設定一個高負載閾值HL一個低負載閾值LL，如果一個節點的CPU使用率超過HL則將它劃入高負載區，CPU使用率低于LL則將它劃入低負載區，CPU使用率在這兩者之間則劃入中負載區。設系統中高負載區的節點總數為NH，低負載區的節點總數為NL，基于這個前提，中心節點通過圖4-7所示處理流程來判定采用哪種處理模型調整負載。圖47中心節點處理流程由圖4-7可知，只有當系統中所有的節點均過載時才會采用降載方法，這樣能避免在還有可用資源時進行降載帶來的損失。4.5.3負載均衡中心節點判定采用負載均衡模型后會將決策信息發往處理節點，負載由高節點向低節點遷移。假定選中的一對節點為N1、N2，其負載值為L1、L2，則需要轉移的負載為ΔL=(L1―L2)/2。可見，算子選擇是一個NP問題，本文采用貪婪算法求其近似最優解：每次從N1中選出Value值最高的算子進行遷移。由于被選中的兩個節點計算能力可能不相同，CPU主頻存在差異，ΔL對兩個節點的意義是不相同的。因此算子遷移以總負載不超過任一節點的ΔL為條件。4.5.4降載降載前必須解決三個問題，降載時機，降載位置和降載量，由前文已知降載時機是系統中所有節點均過載的情況，此時還有降載位置和降載量這兩個問題需要解決，降載位置和降載量選擇的標準都是既能滿足降載的需要又要求元組的損失率最小，都是尋求最優解的問題。本文采用一種分布式降載策略，將降載問題轉化成一個線性規劃問題，約束條件每個節點的CPU負載程度均不超過最大承受能力，目標函數是整個系統的吞吐率最大。通過對這個線性規劃問題求解可以得到降載率和降載位置，此時技能滿足降載的要求又使得數據錯失率最小。由于本文的應用環境為海底觀測網故障診斷平臺，用戶對于故障數據的關注度遠遠大于狀態數據，考慮到這個特殊因素，在建立降載問題模型的時候考慮給予故障數據更高的權值，此時降載模型里的目標函數是整個系統的帶權吞吐率最大。這種降載方式可以將系統資源向更為重要的故障數據傾斜，在進行降載時優先對丟棄重要性較低的狀態數據，可以減小重要數據的錯失率。4.6流數據持久化解決方案數據存儲模塊將流數據處理引擎流出的數據通過一定的方式存儲到關系數據庫中，此為首次存儲。對于關系數據庫中的靜態數據，通過一定的計算方式不斷用粗粒度的數據代替細粒度的數據從而壓縮存儲空間，此為二次存儲，下面詳細介紹一下兩種存儲方式實現的機制。4.6.1首次存儲首次存儲的工作的基本思路是：一、數據流出流數據處理引擎后，通過數據處理算法(即采樣算法)，根據不同粒度將符合某種條件的部分數據緩沖到一個工作緩沖隊列中；二、當工作緩沖隊列達到一定長度時，通過批處理方式一次性把數據插入到關系數據庫系統中。采樣算法采用等距無偏采樣算法，為了使采樣比較靈活，設定一個采樣系數F，采樣距離distance為1/F。根據系統的負載程度，可以調整采樣系數F來適應系統的負載。具體的采樣算法此處不再贅述。經過采樣之后的數據流出流數據引擎時，需要將數據記錄插入關系數據庫中。若采用一條一條插入數據庫的方式，不僅會造成數據庫性能下降而且消耗的時間巨大。實測表明，將一百條數據依次插入數據庫消耗的時間是通過批處理的方式消耗的時間的百倍。此外，流數據的到達速率和處理速度遠大于數據記錄插入關系數據庫的速度。因此本文中運用批處理方式，將經過等距無偏采樣算法后流出流數據引擎的歷史數據暫時存儲在常駐于內存的工作緩沖隊列中。當工作緩沖隊列里的數據達到一定長度時，一次性地將緩沖在隊列中的數據以關系數據庫所允許的最大插入速度插入到關系數據庫中。4.6.2二次存儲數據量龐大的流數據經過首次存儲，使得僅存儲數據集樣本數據的關系數據庫的存儲空間壓力明顯減小。但是這種方法降低的存儲空間還是無法和動態數據規模的增長相比，且隨著時間的延續，采樣后的數據也將呈現爆炸式增長，因此對于流數據的存儲，關系數據庫的存儲能力還是有所不足，需要進一步使用方法來降低數據庫的存儲壓力。基于時間粒度的二次存儲方法，其目的正是為了繼續減輕關系數據庫的存儲壓力。時間粒度的選取沒有一個固定的標準，隨著應用的不同時間粒度的選取也不同，本文中時間粒度的選取由細到粗分別是：小時、天、月、季度、年。在流數據應用中，用戶或應用程序對流數據的興趣度由產生數據的時間戳決定，近期歷史數據的訪問頻率總是遠大于時間久遠的歷史數據。對近期產生的歷史數據更關心其數據的詳細信息，相反，對于較久遠的歷史數據一般會忽略其詳細信息而僅關心數據的某些統計值或者數據挖掘的結果。例如，在海洋監測網中，用戶會關心近期某天岸基監測站的輸入電壓、輸入電流、漏水監測的變化情況和詳細記錄；然而，對于1年前或時間更為久遠的數據，用戶僅僅會關心輸入電壓在一定范圍內分布的統計值。在這種情況下，數據庫僅需提供統計值信息，如果還通過存儲的原始記錄信息來計算不僅耗時過長也會占據過多的存儲空間，造成嚴重的浪費。常見的求統計值函數包括SUM、COUNT、MAX、MIN、AVERAGE。下面給出了聚集函數accumulate(x，y)的定義：QUOTEaccumulate(x，y)x=x+ysum或二次存儲的具體處理流程如下：輸入：時間粒度為n的數據記錄輸出：時間粒度為n+1的數據記錄If(到達n+1級數據更新點){對時間粒度為n級的數據庫中的數據進行聚集查詢；將查詢結果存儲到n+l級的數據庫中；刪除時間粒度為n級數據庫中的經過聚集查詢過的數據}以上處理流程關鍵的一點是，該處理算法執行時間、各個時間粒度的數據保留時間及更新周期的問題，本文中，數據更新周期為小時，詳細歷史數據保存期為過去半年，每到月底清理一下數據，條件的允許的話會將數據轉儲到備份數據庫中。4.7本章小結本章首先介紹了應用系統的總體設計與分層結構，并詳細介紹了數據預處理層和流數據處理層。把流數據管理系統作為核心的基礎之上，本章針對流數據異構、流數據過載、流數據需持久化三個關鍵問題給出具體的解決方案，形成了一個適用于資源監測網的總體實現方案。對于通過負載管理實現系統自適應性這一重要內容進行了詳細介紹，對負載管理模塊的工作流程，降載策略制定的理由和工作原理給出了具體說明。5.實驗與分析5.1實驗環境準備本文在實驗室局域網內進行試驗，采用一臺PC機作為中心節點，三臺PC機作為處理節點來部署海底觀測網故障診斷平臺。通過分布在三臺電腦上電學平臺模擬程序、光學平臺模擬程序、傳感器模擬程序不斷向系統發送仿真數據。所有仿真數據均由仿真程序模擬現實采集數據生成。實驗結果具有一定參考性。選取實驗數據的標準是盡量模擬真實數據，因此采用光學、電學、傳感器發送數據的模擬程序來模擬真實數據。5.2測試平臺與實驗數據集5.2.1測試平臺本文參與測試PC的軟硬件環境如下：硬件環境：Cpu：IntelPentiumD2.2GHz；內存：3GB；硬盤：160GBytes，7200rpm；操作系統：MicrosoftWindows7運行環境：實驗系統以分布式的方式部署在局域網內，以一臺PC機作為中心節點，光學、電學、傳感器三個數據發送模擬程序分別分布在三臺機器上，以設定的速度向實驗系統發送采集數據。5.2.2實驗數據集本文中通過三個仿真程序模擬三類流數據，以電學仿真數據為例，其格式如所示，從左到右依次是工作狀態、濕度、漏水檢測1等屬性。以電學平臺下次接駁盒為例，具體數據格式格式如REF_Ref386564520\h圖51數據集部分截圖所示。圖5SEQ圖\*ARABIC\s11數據集部分截圖5.3實驗結果分析在本實驗系統中，系統的性能主要兩個因素影響：流數據速率和查詢計劃數量。由于查詢計劃是固定的因此本文的測試計劃主要圍繞流數據流速進行，在流數據速率不同的情況下對觀察系統延時、CPU占用率、以及數據錯失率，從而對系統的實時性、穩定性、準確性進行評價。5.3.1實時性測試實際運行環境中數據平均流速在50條/s左右，讓測試數據流速分布在100條/s到500條/s。在不同流速下觀察監測系統的延時，觀察它能否在高速流下維持穩定工作。圖5-2系統理延時變化由上圖5-2可知，系統剛啟動時延遲較大，隨著運行的推移逐漸平穩，造成最初較大延時的原因時系統正在分配資源會消耗部分時間。系統可以在較高流速下維持穩定工作。5.3.2穩定性測試本實驗中設定初始流速為50條/s，運行一段時間后將流速提升至1000條/s，對比加入負載管理模塊前后的某一節點的CPU使用率，來驗證負載管理模塊能否有效工作。圖5-3加入負載管理模塊前后CPU占用率對比由圖5-3可知，在未添加負載管理模塊前，系統在波峰流速到達時CPU資源很快被耗盡，無法正常工作；在添加負載管理模塊后，當流速波峰到達時，系統能維持穩定工作。因此，負載管理模塊能有效應對流速波峰導致的過載問題。5.3.3準確性測試本實驗中設定初始流速為50條/s，運行一段時間后將流速提升至500條/s，設定故障數據/狀態數據權值比分別為2、5、10，觀察在流速飆升至500條/s時，故障數據和狀態數據的錯失率并進行對比。

表5-SEQ表\*ARABIC\s11不同權值比下錯失率對比故障數據/狀態數據權值比2510平均數據錯失率故障數據錯失率0.0500狀態數據錯失率0.230.305.4本章小結本章從實時性、穩定性、準確性三個方面進行了測試，驗證了本文解決方案的可行性。實驗二和實驗三驗證了本文負載管理工作的有效性，證明它能在保證重要數據盡可能準確的情況下更快的調整系統負載，使系統進入穩定狀態。6.總結及展望6.1論文工作總結流數據這種新型數據由于其本身的連續、無界、可變等特征對傳統數據庫技術提出了嚴峻挑戰。近些年來，流數據處理技術已經成為研究熱點。本文結合海底觀測網的研究背景，引入分布式流數據管理系統作為數據處理引擎，構建了一個資源監測網的整體架構，對流數據處理與應用背景結合產生的流數據異構、流數據降載、流數據需持久化這三個應用問題進行分析和研究。針對流數據過載這個核心問題，設計了一個負載管理模型結合負載均衡和降載技術來解決過載問題，保證系統在在流速峰值到達時能繼續穩定工作同時降低了直接降載對數據準確性帶來的負面影響。針對流數據多源異構的問題，提出了通過適配器結合配置文件進行轉換的方法，解決了對于分布在各地的異構源數據統一處理的問題。針對流數據需持久化問題，本文采用兩次存儲的方法，首次存儲時通過批處理的方式將流數據持久化后到數據庫中，第二次存儲采取基于時間多粒度存儲的策略，極大的降低了歷史數據占用的存儲空間，同時相對完整的保持了數據的有效性。在降低存儲開銷的同時，還能對引擎處理后的數據進行更大時間粒度的統計分析。6.2下一步工作本文對流數據處理方法在資源監測網中的應用做了一些研究，針對一些問題提出了自己的解決思路和方法。由于時間和精力的有限，本文的研究還需要進一步的完善，下一步的工作主要集中在以下幾個方面：降載策略的優化。本文中降載策略在拋棄數據時采取隨機方法，雖然通過賦予重要數據更高的權值可以避免在降載時丟棄重要數據，但只有重要數據和非重要數據權值相差很大時才具有理想效果，有一定的局限性。因此下一步研究基于語義的降載方法，進一步降低降載對于數據準確性帶來的負面影響。建立更加有效、通用的服務質量控制機制。研究對各類數據流應用進行標準化監測，采用統一的模型衡量系統負載并做出管理決策的通用方法。參考文獻BabcockB,BabuS,DatarM,etal.Modelsandissuesindatastreamsystems:Proceedingsofthetwenty-firstACMSIGMOD-SIGACT-SIGARTsymposiumonPrinciplesofdatabasesystems,Madison,Wisconsin,2002[C].ACM.CranorC,JohnsonT,SpataschekO,etal.Gigascope:astreamdatabasefornetworkapplications:Proceedingsofthe2003ACMSIGMODinternationalconferenceonManagementofdata,SanDiego,California,2003[C].ACM.CarneyD,U,Ur,etal.Monitoringstreams:anewclassofdatamanagementapplications:Proceedingsofthe28thinternationalconferenceonVeryLargeDataBases,HongKong,China,2002[C].VLDBEndowment.D.J.Abadi,Y.Anmad,M.Balazinska,etal.TheDesignoftheBorealisStreamArasuA,BabcockB,BabuS,etal.STREAM:thestanfordstreamdatamanager(demonstrationdescription):Proceedingsofthe2003ACMSIGMODinternationalconferenceonManagementofdata,SanDiego,California,2003[C].ACM.ChandrasekaranS,CooperO,DeshpandeA,etal.TelegraphCQ:continuousdataflowprocessing:Proceedingsofthe2003ACMSIGMODinternationalconferenceonManagementofdata,2003[C].ACM.AbadiDJ,CarneyD,?etintemelU,etal.Aurora:anewmodelandarchitecturefordatastreammanagement[J].TheVLDBJournal—TheInternationalJournalonVeryLargeDataBases,2003,12(2):120-139. ChenJ,DeWittDJ,TianF,etal.NiagaraCQ:Ascalablecontinuousquerysystemforinternetdatabases:ACMSIGMODRecord,2000[C].ACM.ZhuY,ShashaD.Statstream:Statisticalmonitoringofthousandsofdatastreamsinrealtime:Proceedingsofthe28thinternationalconferenceonVeryLargeDataBases,2002[C].VLDBEndowment.S.Zdonik,M.Stonebraker,M.Cherniack,etal.TheAuroraandMedusaProjects,IEEEDataEngineeringBulletin,March2003,26(1):3~10.DaiB,HuangJ,YehM,etal.Clusteringondemandformultipledatastreams:DataMining,2004.ICDM'04.FourthIEEEInternationalConferenceon,2004[C].IEEE.MouratidisK,BakirasS,PapadiasD.Continuousmonitoringoftop-kqueriesoverslidingwindows:Proceedingsofthe2006ACMSIGMODinternationalconferenceonManagementofdata,2006[C].ACM.GuhaS,MishraN,MotwaniR,etal.Clusteringdatastreams:Foundationsofcomputerscience,2000.proceedings.41stannualsymposiumon,2000[C].IEEE.HultenG,SpencerL,DomingosP.Miningtime-changingdatastreams:ProceedingsoftheseventhACMSIGKDDinternationalconferenceonKnowledgediscoveryanddatamining,2001[C].ACM.DomingosP,HultenG.Mininghigh-speeddatastreams:ProceedingsofthesixthACMSIGKDDinternationalconferenceonKnowledgediscoveryanddatamining,2000[C].ACM.ZhouA,CaiZ,WeiL,etal.M-kernelmerging:Towardsdensityestimationoverdatastreams:DatabaseSystemsforAdvancedApplications,2003.(DASFAA2003).Proceedings.EighthInternationalConferenceon,2003[C].IEEE.CaiYD,ClutterD,PapeG,etal.MAIDS:Miningalarmingincidentsfromdatastreams:Proceedingsofthe2004ACMSIGMODinternationalconferenceonManagementofdata,2004[C].ACM.BifetA,HolmesG,KirkbyR,etal.Moa:Massiveonlineanalysis[J].TheJournalofMachineLearningResearch,2010,11:1601-1604.LinW,YangS,HongT.Memory-AwareMiningofIndirectAssociationsOverDataStreams[M]//UDENL,WANGLSL,HONGT,etal.The3rdInternationalWorkshoponIntelligentDataAnalysisandManagement.SpringerNetherlands,2013:15-25.李巖,王惠文,葉明.數據流分析與技術研究[J].計算機工程與應用,2008,44(15):8-11.ProcessingEng