面向流式處理系統的對象管理方法*

王家興，林學練，申 陽，張 韻，張明明，馬 帥

1.北京航空航天大學 計算機學院，北京 100191

2.上海通用識別技術研究所，上海 201100

面向流式處理系統的對象管理方法*

王家興1+，林學練1，申 陽1，張 韻2，張明明1，馬 帥1

1.北京航空航天大學 計算機學院，北京 100191

2.上海通用識別技術研究所，上海 201100

WANG Jiaxing,LIN Xuelian,SHEN Yang,et al.Data object managing method in stream processing system. Journal of Frontiers of Computer Science and Technology,2016,10(11):1512-1523.

在車聯網的應用實踐中，人們將分析車輛數據的任務運行在流式計算系統中。在運行分析中發現，這些任務具有運行周期長，處理延遲低，任務有狀態等需求和特點，并且計算過程中需要在內存中保存大量計算參數和中間狀態等數據對象，其中大量的數據對象并不活躍，任由其占用內存造成了系統資源的浪費。針對該問題開展研究，給出了流式任務的數據對象管理方法，優化了內存的使用。為流式數據對象建立生命周期模型，采用應用驅動、數據驅動的模型參數確定方法為流式數據對象設置合適的過期參數，設計車聯網測試用例，驗證該生命周期管理方法的有效性。實驗結果表明，該方法在用戶可接受的處理延遲范圍內，能夠有效地減少流式系統中不活躍對象的數目，達到了優化內存，降低資源開銷的目的。

車聯網；流式系統；不活躍對象；生命周期管理；數據驅動模型

1 引言

車聯網是綜合電子信息技術，它將每一輛車作為一個信息源，利用無線通信手段建立以車為節點的信息系統。通過人、車、路間的交互，實現人-車-路的和諧統一發展[1]。

車聯網場景下，車載設備上傳GPS數據和OBD（on-board diagnostics，發送的數據內容包括車輛位置、發動機參數等）數據；服務器端持續地接收數據，并實時地對數據進行分析，從而為不同類型的用戶提供相應的服務。例如，為普通用戶提供電子圍欄服務、路線規劃和推薦服務、駕駛員駕駛行為分析；為租車運營商提供車輛實時位置監控服務，根據駕駛員的駕駛行為分析結果進一步為運營商提供司機績效考評服務，從而為其提出運營和管理建議；分析和預測一定范圍、一段時間內的道路流量情況，以便有效地進行分流、調度和指揮，輔助國家車管部門工作。

本文采用流式處理系統[2]作為基礎平臺，開發數據計算任務以處理車聯網數據。針對持續產生的數據流，流式系統完成實時（準實時）的計算，能夠滿足人們對線上業務的運行需求。通過對約兩萬輛車的數據進行處理，發現一些車聯網計算任務有以下3個特點：

（1）任務需要長時間運行。車聯網應用面向的是車載終端持續產生的GPS數據和OBD數據，因此處理該應用的任務需要長時間運行。一旦任務下線，則持續產生的數據不能得到及時的處理，也就不能為用戶提供持續的服務。

（2）處理延遲低，響應速度快。汽車高速行駛帶來了實時性要求高的特點，且汽車的安全行駛事關車內人員的生命和財產安全。如電子圍欄應用是為了車主能夠監控車輛是否處于自己劃定的圍欄內，目的是監控車輛安全，若實時性不能保證，則會造成早已駛出監控范圍很遠之后才報警的情況，車輛安全不能得到保證。同時，如路線推薦、駕駛員行為分析等應用，處理-響應時間直接關系到用戶體驗，因此車聯網應用必須保證實時性要求。

（3）任務有狀態。任務需要保存一定的內存狀態，如電子圍欄應用中，需要保存所有車輛的電子圍欄數據，從而在接收到GPS數據后馬上得到是否越過圍欄的反饋；而在疲勞駕駛提醒的應用中，需要保存車輛自開始行駛到現在的持續狀態，車輛行程不結束，狀態不能從內存中刪除。實際開發中，發現這里的狀態還有一些計數值和緩存（如為提高數據庫寫入率，采取批量寫入時在內存中緩存的數據）。

由于車聯網數據和計算具有上述特點，并且車聯網場景下用戶基數大但在線用戶比例低，流式系統中這些任務運行一段時間后，內存中存在大量不活躍的數據對象。

目前，國內外流式系統層出不窮，主流系統包括Storm[3]、Yahool！S4[4]、Spark Streaming[5]等，目前還沒有關于流式系統中的不活躍對象管理的重要研究及成果。當然，對長周期任務中不活躍數據的研究并不是新問題，Corba[6]、J2EE[7]等中間件上運行著大量的長周期服務，為了防止過多的會話、連接浪費內存，它們均為數據對象提供了生命周期服務。

本文分析了車聯網流式數據的特點，建立了車聯網數據對象的生命周期模型；借鑒中間件技術的對象生命周期管理方法，設計和實現了流式系統的數據對象管理方法，為流式處理系統提供了一套內存優化方法，有效地解決了任務因長期運行而造成的大量不活躍對象無限占用內存的問題。本文研究雖然針對車聯網數據，但本文設計的方案有很好的普適性，可以很方便地推廣到其他流式數據處理場景中，比如社交網絡的用戶分析和事件分析。

本文的研究內容和成果包含以下幾個方面：

（1）經過對車聯網數據的分析，本文定位到流式系統中存在的大量不活躍對象占用內存的問題，將主流中間件系統（Corba/J2EE）采用的對象生命周期服務引入到流式處理系統中。

（2）針對傳統生命周期服務中采用經驗值設定參數的方式，提出一套應用和數據雙驅動的過期參數確定方法，為對象生命周期服務提供更合適的參數，達到內存優化的最優效果。

（3）將數據對象生命周期模塊集成到JStorm系統，并且結合車聯網場景的真實用例和數據，驗證本文方法對流式系統的優化效果。

本文組織結構如下：第2章介紹了車聯網的數據處理需求、目前各流式系統基本情況和內存使用情況的相關工作；第3章對車聯網數據進行研究，著重分析了數據的活躍程度；第4章介紹了流式數據對象的生命周期模型和數據對象過期策略；第5章將流式數據對象管理作為單獨的模塊集成到JStorm系統中；第6章以電子圍欄應用為例建模、實驗并分析結果；第7章是結論和今后的工作介紹。

2 相關工作

2.1 車聯網及其數據處理

近年來，車聯網作為物聯網的重要組成部分，得到了空前的發展。車聯網是保證道路安全，優化公共交通資源的關鍵。通過車聯網，可以提供車輛安全、事故管理、車輛監控、流量調度、電子收費、信息娛樂等方面的服務。開發車聯網相關產品，借此發展與其相關的汽車類電子產業，推動相關領域的經濟變革，是對“互聯網+”的一次有效嘗試。

目前在車聯網方面的研究主要關注在移動無線通信[8-9]、大規模移動對象管理[10-11]、基于車聯網的數據挖掘[12]等方面。本文關注基于車聯網的大數據處理平臺，希望針對車聯網數據特點，提供更合適的數據處理系統。

車輛的高速行駛直接關系到車內人員的生命財產安全，相比于其他網絡應用，車聯網應用具有更高的實時性需求。本文使用流式處理系統來滿足車聯網數據的流式處理需求，當然車聯網場景下，也有批量計算、迭代計算的處理需求，但這并不是本文關注的重點。

車聯網下的流式應用主要分為以下幾類：

（1）基礎統計。基礎統計包括總數據量統計、用戶活躍性統計、錯誤數據等各種特征數據統計。

（2）單條數據處理。對單條數據的簡單處理包括數據解析、錯誤數據過濾，稍復雜的有電子圍欄應用、車輛所屬行政區劃監控等。

（3）序列提取，從流式的數據序列中提取到所需的數據序列。例如，行程分段算法將流式數據按照分段規則分成一段一段的行程，行程分段算法是疲勞駕駛提醒服務的基礎算法。同理可在數據流中提取到低速行駛段，可結合訂單數據為車輛提供實時計價。

2.2 流式處理系統

目前，工業界和產業界推出的較為成型的流式系統實例有：Yahoo!為提高搜索廣告有效點擊率的問題而開發的S4[4]，安裝和使用最多的流式系統Twitter Storm[3]，UC Berkeley建立在Spark[5]上的流式應用框架Spark Streaming，Microsoft StreamInsight[13]針對并行、彈性替換和容錯改進之后的升級版本TimeStream[14]，融合了流處理、批處理、圖處理的Microsoft Naiad[15]，數據傳輸通道和流式數據處理系統Data Freeway and Puma[16]，分布式實時統計系統Twitter Rainbird[17]等。研究多關注在系統框架、編程模型、可靠性、容錯上，并沒有專門的研究關注到流式系統中的不活躍數據問題。

在流式系統上專門針對內存使用方面的研究非常少，Storm等多數流式系統完全依賴于JVM（Java virtual machine）進行內存管理和回收，而對于不活躍數據對象，并不能也不應該被JVM的GC（garbage collection）機制回收[18]；S4任務重啟并恢復狀態時，采用PE懶恢復方法，即直到再次用到PE時，才恢復其狀態，懶恢復使得S4在重啟任務時過濾掉了一部分不活躍的內存數據；Spark Streaming以RDD（resilient distributed datasets）[19]的形式來管理數據，RDD一般保存在內存中，但如果內存不夠，可將其持久化到磁盤上。

2.3 生命周期服務

對長周期任務中不活躍數據的研究并不是新問題，Corba、J2EE等中間件系統上運行著大量的長周期服務。Corba、J2EE都為數據對象（EJB/Servant）提供了生命周期服務，對象處于活躍態時將其放在內存中，轉為不活躍態時將其持久化到可靠存儲中。

J2EE中采用EJB[20-21]容器來限制內存中EJB數量，這讓EJB容器能夠有效地利用內存、數據庫連接、Socket連接等資源，同時增加EJB系統的可伸縮性。EJB容器通過掛起激活Bean實例，有效地完成Bean實例的生命周期管理。

合理的過期參數是生命周期服務是否起作用的基礎。然而，這些系統中對過期策略參數由用戶通過配置文件自行定制（一般設為經驗值）。文獻[22-23]指出應通過模型驅動確定參數，但其是從系統角度做出調整以支持動態參數變化，并沒有給出一套行之有效的參數確定方法。本文認為過期參數應該視應用類型、數據到達情況而定，因此本文將在第4章給出由數據驅動的過期時間確定方法。

3 車聯網數據分析

3.1 數據概述

本文的數據來自國內某租車公司的20 973輛車，月活躍車輛數約18 225輛，日活躍車輛數約為15 200臺，每天的數據量約為6 000萬條。

本文處理的車聯網數據主要包括3種類型：GPS數據、OBD數據和用戶請求數據。其中，GPS數據包括該車的經緯度、行駛速度、行駛方向等；OBD數據包括車輛的剩余油量、發動機轉速、行駛里程等車輛狀態數據；用戶請求數據即是對車聯網應用發出的定制、取消定制請求，以及對應用的參數設定等。

圖1（a）為月均單日GPS數據量隨時間變化曲線。從圖中可以看到明顯的早、晚高峰，早高峰數據流量約為170萬條/小時，晚高峰約為210萬條/小時，凌晨3點到5點數據流量最低（不到20萬條/小時）。上述大規模、高密度數據除了能夠表示車輛本身狀態和行駛狀態外，還能夠刻畫一個城市各個道路的流量、污染排放等情況。

與微博等社交網站相比，車聯網數據有如下特征：第一，數據均為結構化數據；第二，數據反映車輛狀態，本身不具有情感色彩；第三，數據上傳頻率更高，車輛在活躍期間會持續上傳數據，因此在用戶數相同的情況下，車聯網數據量要比微博數據量大得多；第四，車聯網的用戶粘性更大，活躍頻率更高，經統計，超過50%車輛的月活躍天數達到28天以上。由統計[24]可知，截止2014年末，我國汽車保有量約1.4億，其中北京市汽車保有量為537萬輛。如果車聯網得到進一步推廣，按照目前的數據情況推算，車聯網的數據規模將明顯超過微博等各大社交平臺。

3.2 車輛活躍度分析

對于車聯網數據，本文尤其關注車輛的活躍性，這里認為車輛有數據上傳就是活躍的。人們希望知道每一輛車何時活躍，一次活躍會持續多久，總結出每一輛車的活躍規律，從而為車輛提供個性化的服務，同時也可以在后臺計算上采取差異化的處置措施，以達到最佳的處理效果。然而，在數據分析階段，單獨統計一輛車的數據并不具有代表性，因此本文圍繞數據活躍性問題，對數據進行了車輛月活躍天數、月平均每天活躍時間、單次活躍持續時間3項統計。

圖1（b）為所有車輛一個月內活躍天數的比例分布。由圖可知，車輛中約57%的車輛月活躍天數超過27天，其中每天都活躍的車輛約占28%，另外活躍頻率為1～22天/月的車輛比例都非常低，共約占18%。圖1（c）統計了一輛車平均每天活躍時間的分布情況。由圖可知，每天活躍3～5 h的車輛最多，占總車輛的27%，約50%車輛每天活躍時間低于5 h，活躍時間7 h以下的占75%。圖1（b）和圖1（c）的統計說明雖然車輛幾乎都是每天活躍，但是平均每天活躍的時間仍較低。若在處理時將所有對象都保存在內存中，那么一天中的每個時間點都會有大量對象處于不活躍狀態。因此，本文將不活躍對象暫時清出內存，防止不必要的內存浪費。

圖1（d）統計了單段活躍持續時間的分布。由圖可知，約18%的活躍持續時間為0，即車輛突然上傳一條數據，之后一段時間內沒有再次產生數據，將這種活躍叫作點狀活躍；與點狀活躍相對應，將持續一段時間保持活躍的狀態叫作段狀活躍，37%活躍持續時間在0.5 h以內，90%在2 h以內，約3%的行程超過4 h。由此可知，車輛活躍的段狀特征明顯，同時有部分數據以零散點狀方式上傳。當數據表現為明顯的段狀活躍特征時，說明對象在一次活躍后，短時間內很可能被多次訪問，那么可以做出預測：下一次被訪問的對象很可能是最近剛被訪問過的對象。4.2節將基于這一預測設置數據對象的過期策略。

Fig.1 Statistics for IoV data圖1 車聯網數據統計結果

4 SDO生命周期模型

針對流式系統中存在大量不活躍對象問題，本文給出了流式系統的數據對象管理方法，該方法應具有如下特點：

（1）受管對象可以是流式系統中的任何Java對象，對于自定義對象，用戶須為其提供相應的序列化方法。

（2）能夠自動檢測不活躍對象，并將其持久化到可靠存儲中，防止因不必要的內存占用而浪費資源；當對象恢復活躍時，能夠較快地恢復內存狀態，正常地為流式系統提供服務。

為方便敘述，將此類受管對象統一命名為流數據對象（streaming data object，SDO）。流式系統使用SDO容器（SDOContainer）組織和管理SDO。SDOContainer功能包括SDO組織和SDO生命周期管理。

4.1 SDO狀態及狀態轉移

本文將每個SDO的生命周期分為3個階段。

（1）不存在（Does not exist）：SDO還沒有被實例化，不在內存中；

（2）活躍態（Ready）：在此狀態下，SDO可正常被流式系統使用；

（3）不活躍態（Inactive）：SDO從內存中移除，并持久化到磁盤中，可以恢復內存狀態并為流式系統提供服務。

圖2是SDO生命周期的狀態轉換圖。

Fig.2 SDO’s state machine during its lifecycle圖2 SDO生命周期狀態機

（1）Does not exist?Ready：當流式系統用戶創建新的SDO實例時，SDO的生命周期開始，完成初始化后，SDO保存在內存里開始為流式系統使用。

（2）Ready?Inactive：SDO被檢測為不活躍對象，SDO被去活，去活之前先釋放SDO可能持有的所有資源，去活SDO后，SDO容器將SDO的狀態持久化到硬盤或其他存儲源中。默認情況下，將SDO序列化、持久化到硬盤。

（3）Inactive?Ready：被去活的SDO可能再次被激活，這時需要載入并恢復其被持久化的狀態；激活之前SDO須恢復去活時釋放的資源，雖然此時的SDO實例已經不是被去活之前的SDO實例，但是這一切對流式應用是透明的。

（4）Ready/Inactive?Does not exist：SDO被顯式移除。

4.2 SDO過期策略

基于3.2節對車聯網數據活躍規律的分析，對于明顯段狀活躍的數據，應盡量把剛剛訪問過的對象保存在內存中，而將那些很久沒有被訪問的SDO從內存中移除。基于這種移除方式，SDOContainer提供兩種基本的SDO過期策略。

（1）基于空間的過期策略。SDOContainer設定一個SDO數量上限，當到達該上限時，按照最近最少訪問順序來去活對象；此方法是為了防止SDO無限制地占用內存，是對系統資源進行保護。SDO的最大數量根據系統的資源情況和SDO的大小共同估計得到。此方式得到的延遲是在保護系統資源的前提下，為流式任務提供的最低延遲。

（2）基于時間的過期策略。SDOContainer對其管理下的SDO設置一個超時時間，當超過這一時間沒有被訪問時，就將其從內存中剔除。這種方法用于防止長時間未被使用的數據對象長期占用內存而造成內存浪費。SDO的過期時間需根據應用和數據情況而建模確定，下一節將介紹過期時間的確定方法。此方式能夠保證系統延遲在可接受的范圍內，將內存使用降到最低。

4.3 SDO過期窗口確定方法

相比于中間件中采用的用戶自行設定過期時間的方法（設置經驗值），本文采用應用和數據驅動的參數確定方法，為流式任務確定“合適的”SDO過期時間。“合適的”過期時間是指在保證延遲用戶可接受的前提下，最大限度地降低內存占用率。可以將內存中SDO看成是最近最少使用SDO鏈上的滑動窗口范圍內的數據（如圖3所示），窗口代表著SDO的過期時間。

本文選擇流式任務的處理延遲、內存占用作為性能指標，那么需要明確窗口對延遲、內存占用的影響。圖4是對內存占用、處理延遲隨窗口大小變化的經驗分析：增大window，導致活躍對象的比例增大，內存占用率與活躍對象比例呈正比，因此內存占用率相應增大；而延遲與內存擊中率直接相關，內存擊中率受活躍對象比例和數據連續性兩方面共同影響，對于連續性穩定的數據，整體上內存擊中率隨活躍對象比例增大而增大。例如：當數據隨機到達時，內存擊中率與活躍對象比例呈正比關系，數據活躍比例一定時，數據的連續性高，內存擊中率大。

Fig.3 Sliding window of SDOContainer based on expiring time圖3 SDOContainer基于過期時間的滑動窗口

Fig.4 Influence of window size on processing delay and memory usage圖4 窗口大小對處理延遲和內存占用的影響

根據以上分析，可得目標函數（1）：

其中，w為窗口大小；t為時間；delay為采用w窗口在t時刻的處理延遲；hr為擊中緩存的概率，它由窗口大小和該時刻的數據情況決定；dmem為直接從內存中取數據并投入計算時應用的處理延時；dload為未擊中內存（從可靠存儲中取出并恢復SDO狀態）時的數據處理延遲。

理論上，用戶給定最大可接受的平均延時，在每個時間點會對應一組window值，由于內存占用隨window的增大而增大，取這組值中最小值作為window，即可達到在給定最大可接受處理延遲的前提下，將內存占用降到最低。

總結window的確定方法為：測試式（1）中參數dload、dmem值，得到處理延遲隨內存擊中率變化的函數；給定最大可接受的處理延遲d1，得到相應的緩存擊中率hr1；統計并擬合出hr=P(w,t)，取hr=hr1，即可得到隨時間變化的窗口大小。此window值可以使得在保證用戶設定平均延遲的前提下，內存占用降到最低。

5 系統實現

本文將SDO生命周期管理作為單獨模塊集成進入JStorm系統。JStorm是一個分布式實時計算引擎，它用Java完全重寫Storm內核，保持了Storm的編程規范性、健壯性和拓展性，不僅如此，JStorm重新設計了調度、采樣、監控、HA，并對Zookeeper[25]和RPC進行大幅改良，從而JStorm比Storm更穩定，功能更強。

JStorm系統由3類節點組成（如圖5所示）。

（1）Zookeeper：JStorm集群資源協調者。Supervisor、任務task定期向Zookeeper發送心跳，Nimbus通過檢測Zookeeper上的心跳數據來監控集群的資源情況和任務的執行情況。

（2）Nimbus：任務分配器。Client向Nimbus提交任務后，Nimbus為任務進行資源分配并寫入Zookeeper，Supervisor從Zookeeper上獲取分配給自己的任務并啟動相應的進程、線程。

（3）Supervisor：JStorm的工作節點。Supervisor啟動Worker執行分配給自己的任務，Supervisor監控本地Worker的狀態，以便及時地進行故障恢復。

運行于Supervisor上的Worker進程是任務的實際執行者。圖的下半部分是Worker對消息的處理流程，tuple首先進入task的接收隊列，BoltExcutor線程根據處理速度從接收隊列取出tuple并做處理，向外發送的tuple被放入序列化隊列待序列化后發送到下級bolt。

SDOContainer作為一個單獨的模塊集成到JStorm中，當開發者需要生命周期管理服務時，可申請相應的SDOContainer，將需要被管理的中間結果或任何數據放入其中。同時設置SDOContainer的過期參數、可靠存儲的相應參數，SDOContianer即可自動地完成對其內部SDO的生命周期管理。

默認狀態下，SDOContainer將Inactive狀態的SDO寫入到外存中，為用戶提供持久化接口，用戶通過連接（Connect）、關閉（Close）、寫入（Store）、讀取（Load）4個函數，即可實現內存數據和任何存儲介質的數據交換。

Fig.5 JStorm+SDOContainer system圖5 JStorm+SDOContainer系統

6 實驗驗證和數據分析

6.1 集群配置和使用

測試資源包括兩個物理節點（test1/test2），每個節點的配置是：8核2.80 GHz Intel?CoreTMi7 CPU860，16 GB內存和1 TB的SATA硬盤。其中，test1單純作為JStorm的工作節點（包含Supervisor進程和Worker進程）；test2除作為JStorm的任務分配節點（啟動Nimbus進程）外，還安裝了MySQL數據庫作為可靠存儲。

測試中，SDOContainer采用默認持久化策略，將不活躍SDO通過序列化工具Kryo序列化并存儲到MySQL數據庫中。

6.2 實驗設計

6.2.1 用例描述

電子圍欄應用是車聯網場景下的一個流式應用。管理員為車輛設置電子圍欄范圍，車輛持續向服務器端發送GPS位置數據，服務器端實時判斷車輛是否越過電子圍欄，若超出或重新進入圍欄，為車輛管理員發送狀態變更提醒。該應用用于滿足租車運營商或普通車主的車輛安全需求。

圖6為電子圍欄用例的任務拓撲圖，Storm拓撲中共有4個邏輯節點，其中2個Spout作為數據源和2個Bolt作為數據處理節點。

Fig.6 Topology of electronic-fence application圖6 電子圍欄任務拓撲

（1）Fence_spout（S1）：接收管理員對電子圍欄的設置，發送圍欄數據到InFenceMonitor_bolt節點，更改內存中車輛的圍欄設置。

（2）Location_spout（S2）：持續接收車輛發送的位置信息，發送位置數據到InFenceMonitor_bolt節點。

（3）InFenceMonitor_bolt（B1）：使用優化射線法[26]，判斷車輛位置是否超越電子圍欄，若發生狀態變更（超出圍欄或重回圍欄），則將結果發送到DBvisior_ bolt節點。

（4）DBvisitor_bolt（B2）：數據庫訪問節點，將車輛進出圍欄時間寫入到數據庫中。

6.2.2 數據來源

車輛位置數據來源于國內某租車公司的20 973輛車，車輛未熄火時約5～8 s發送一次GPS數據，熄火時不發送數據。

設置車輛的電子圍欄為注冊城市區域，城市的GPS區域通過百度地圖API獲得，平均約為600邊的多邊形。

6.3 SDO過期參數分析

本節根據4.3節給出的SDO過期參數確定方法，確定SDOContainer最大容量和SDO過期時間。

首先，將任務運行在沒有SDOContainer管理的JStorm平臺，內存使用量約為10.3 GB，數據處理延遲約為13.11 ms。由此可知，任務未達到系統內存瓶頸，因此不必設置SDOContainer的最大容量，系統可達到的最小處理延遲為13.11 ms。

測試得到hr=0.9時，delay=46.79 ms，可知公式中的dload約為349.91 ms/條。因此，目標函數可表示為：

之后，統計各時間點，內存擊中率隨窗口大小的變化hr=P(w,t)，該統計結果擬合出的應為具有二維變量的三維圖形，抽取代表性時間點的數據繪制圖表。由圖7可知，window在0～20 s內，內存擊中率隨window大小急劇增長，幾乎所有時間點的擊中率都達到90%以上，當window進一步增大時，擊中率上升緩慢，最終擊中率為1。

Fig.7 Influence of window size on memory hit rate圖7 內存擊中率隨窗口大小變化

所有時間點的內存擊中率隨窗口大小的曲線幾乎重合，因此可采用不隨時間變化的窗口大小。設定最大可接受的平均處理延遲為30 ms，此時需滿足hr>94.49%，根據圖7的統計結果，對應的窗口大小為30ms（圖7中，30ms對應的平均內存擊中率為95.5%）。

沒有加入SDOContainer之前，平均處理延遲為13.11 ms，內存占用為10.3 GB；加入SDOContianer，且window=30時，延遲為18.81 ms，內存占用為8.3 GB，內存占用降低了近20%。

6.4 SDO性能分析

本節測試使用SDOContainer后，對該應用處理延遲、內存占用方面的改變，以及選擇window=30 s的合理性。

圖8為處理延遲、內存占用隨窗口大小的變化情況。由圖可知，在測試區間（10～120 s）內，處理延遲隨窗口的增大而減小，內存使用隨窗口增大而增大，要使處理延遲低于30 ms，window需大于30 s。雖然由于測試精度的問題，window取30 s、40 s時內存占用均為8.3 GB，但從理論分析和總體趨勢可以知道，window=30是在滿足處理延遲低于30 ms的前提下，內存占用率最低的情況。

Fig.8 Processing delay and memory usage in JStorm and JStorm+SDOContainer圖8 加入/未加入SDOcontainer時JStorm處理延遲和內存占用情況

由上述分析可知，在電子圍欄應用中，引入SDOContainer模塊并設置合適的SDO過期參數之后，可以為流式系統大幅度地節省內存資源。

7 總結和展望

本文針對流式系統中存在大量不活躍對象的問題，對流式數據對象建立生命周期模型，采用數據驅動、應用驅動的參數確定方法，為SDO設置合適的過期參數。實驗結果表明，本文方法在用戶可接受的處理延遲范圍內，能夠有效減少流式系統中不活躍對象的數目，節約系統的內存資源，達到內存優化的目的。

對于SDOContainer模型中SDO過期參數明顯隨時間而變化的用例，本文尚未給出參數確定方法，這也是本文的后續工作。

[1]White paper of Internet of vehicles(IoV)[EB/OL].[2015-06-26].http://mddb.apec.org/Documents/2014/TEL/TEL50-PLEN/14_tel50_plen_020.pdf.

[2]Zhu Jianping,Lai Shengqiang.A survey on streaming data mining and future directions in statistical research[J].Statistical Research,2007,24(7):84-87.

[3]Toshniwal A,Taneja S,Shukla A,et al.Storm@twitter[C]// Proceedings of the 2014 ACM SIGMOD International Conference on Management of Data,Snowbird,USA,Jun 22-27,2014.New York:ACM,2014:147-156.

[4]Neumeyer L,Robbins B,Nair A,et al.S4:distributed stream computing platform[C]//Proceedings of the 2010 IEEE International Conference on Data Mining Workshops,Sydney, Australia,Dec 13,2010.Piscataway,USA:IEEE,2010: 170-177.

[5]Zaharia M,Das T,Li Haoyuan,et al.Discretized streams: fault-tolerant streaming computation at scale[C]//Proceedings of the 24th ACM Symposium on Operating Systems Principles,Farmington,USA,Nov 3-6,2013.New York:ACM, 2013:423-438.

[6]Vinoski S.CORBA:integrating diverse applications within distributed heterogeneous environments[J].IEEE Communications Magazine,1997,35(2):46-55.

[7]The white paper of JavaEE7[EB/OL].[2015-06-26].http:// www.oracle.com/technetwork/java/javaee/.

[8]Wu Hao,Tang Hengliang,Dong Lan.A novel routing protocol based on mobile social networks and internet of vehicles [C]//LNCS 8662:Proceedings of the 1st International Conference on Internet of Vehicles-Technologies and Services, Beijing,Sep 1-3,2014.Basel,Switzerland:Springer International Publishing,2014:1-10.

[9]Sch?nfelder R,Leucker M,Walther S.Efficient profile routing for electric vehicles[C]//LNCS 8662:Proceedings of the 1st International Conference on Internet of Vehicles-Technologies and Services,Beijing,Sep 1-3,2014.Basel,Switzerland: Springer International Publishing,2014:21-30.

[10]Hu Haibo,Xu Jianliang,Lee D L.A generic framework for monitoring continuous spatial queries over moving objects [C]//Proceedings of the 2005 ACM SIGMOD International Conference on Management of Data,Baltimore,USA,Jun 14-16,2005.New York:ACM,2005:479-490.

[11]Alamri S,Taniar D,Safar M,et al.A connectivity index for moving objects in an indoor cellular space[J].Personal and Ubiquitous Computing,2014,18(2):287-301.

[12]Shang Jingbo,Zheng Yu,Tong Wenzhu,et al.Inferring gas consumption and pollution emission of vehicles throughout a city[C]//Proceedings of the 20th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, New York,Aug 24-27,2014.New York:ACM,2014:1027-1036.

[13]Ali M H,Gerea C,Raman B S,et al.Microsoft CEP server and online behavioral targeting[J].Proceedings of the VLDB Endowment,2009,2(2):1558-1561.

[14]Qian Zhengping,He Yong,Su Chunzhi,et al.Timestream: reliable stream computation in the cloud[C]//Proceedings of the 8th ACM European Conference on Computer Systems,Prague,Czech Republi,Apr 15-17,2013.New York: ACM,2013:1-14.

[15]Murray D G,McSherry F,Isaacs R,et al.Naiad:a timely dataflow system[C]//Proceedings of the 24th ACM Symposium on Operating Systems Principles,Farmington,USA, Nov 3-6,2013.New York:ACM,2013:439-455.

[16]Zheng Shao.Data freeway and puma:realtime data streams and analytics[C]//Proceedings of Hadoop in China 2011, Beijing,Dec 2-3,2011.

[17]Rainbird:realtime analytics at twitter[EB/OL].[2015-06-26]. http://www.slideshare.net/kevinweil/rainbird-realtime-analyticsat-twitter-strata-2011.

[18]Liu Yongpo,Jia Xiaoxia,Wu Ji,et al.Analysis of memory usage with low efficiency in Java program[J].Computer Engineering,2008,34(23):84-85.

[19]Zaharia M,Chowdhury M,Das T,et al.Resilient distributed datasets:a fault-tolerant abstraction for in-memory cluster computing[C]//Proceedings of the 9th USENIX Conference on Networked Systems Design and Implementation,San Jose, USA,Apr 25-27,2012.Berkeley,USA:USENIX Association,2012:2.

[20]Sriganesh R P,Brose G,Silverman M.Mastering enterprise JavaBeans 3.0[M].Hoboken,USA:John Wiley&Sons Inc,2005.

[21]Li Huoming.Beginning in EJB3.0[M]//Beijing:Tsinghua University Press,2008.

[22]Bidan C,Issarny V,Saridakis T,et al.A dynamic reconfiguration service for CORBA[C]//Proceedings of the 4thInternational Conference on Configurable Distributed Systems, Annapolis,USA,May 4-6,1998.Piscataway,USA:IEEE, 1998:35-42.

[23]Coulson G,Blair G S,Clarke M,et al.The design of a configurable and reconfigurable middleware platform[J].Distributed Computing,2002,15(2):109-126.

[24]National Bureau of Statistics of China.Statistical communiqué of the People?s Republic of China on the 2014 national economic and social development[EB/OL].[2015-06-26]. http://www.stats.gov.cn/tjsj/zxfb/201502/t20150226_685799. html.

[25]Hunt P,Konar M,Junqueira F P,et al.ZooKeeper:wait-free coordination for Internet-scale systems[C]//USENIX Annual Technical Conference,Boston,USA,Jun 23-25,2010. Berkeley,USA:USENIXAssociation,2010.

[26]Wu Jian,Jiang Hong,Wang Xiaochun.A method for the decision of a point whether in or not in self-intersected polygon[J].Journal of System Simulation,2003,15(11):1592-1594.

附中文參考文獻：

[2]朱建平,來升強.流式數據挖掘的現狀及統計學的研究趨勢[J].統計研究,2007,24(7):84-87.

[18]柳永坡,賈曉霞,吳際,等.Java程序內存低效使用問題的分析[J].計算機工程,2008,34(23):84-85.

[21]黎活明.EJB3.0入門經典[M].北京:清華大學出版社, 2008.

[24]中華人民共和國國家統計局.2014年國民經濟和社會發展統計公報[EB/OL].[2015-06-26].http://www.stats.gov. cn/tjsj/zxfb/201502/t20150226_685799.html.

[26]吳堅,姜虹,王小椿.快速判斷點是否在自交多邊形內的方法[J].系統仿真學報,2003,15(11):1592-1594.

WANG Jiaxing was born in 1990.She is an M.S.candidate at Beihang University.Her research interests include distributed computing and big data processing.

王家興（1990—），女，遼寧阜新人，北京航空航天大學碩士研究生，主要研究領域為分布式計算，大數據處理。

LIN Xuelian was born in 1978.He received the Ph.D.degree from Beihang University in 2013.Now he is a lecturer at Beihang University.His research interests include distributed computing and middleware.

林學練（1978—），男，浙江溫州人，2013年于北京航空航天大學獲得博士學位，現為北航計算機學院講師，主要研究領域為分布式計算，中間件技術。

SHEN Yang was born in 1991.He is an M.S.candidate at Beihang University.His research interests include distributed computing and big data processing.

申陽（1991—），男，河北邯鄲人，北京航空航天大學碩士研究生，主要研究領域為分布式計算，大數據處理。

Data Object Managing Method in Stream Processing System?

WANG Jiaxing1+,LIN Xuelian1,SHEN Yang1,ZHANG Yun2,ZHANG Mingming1,MAShuai1
1.School of Computer Science and Engineering,Beihang University,Beijing 100191,China
2.Shanghai General Recognition Technology Research Institute,Shanghai 201100,China
+Corresponding author:E-mail:wangjx@act.buaa.edu.cn

In the practice of Internet of vehicles,people run several computing applications in streaming systems to analyze GPS/OBD data collected from vehicles.These applications have some common requirements and features, which are long-cycle running,low processing delay,and the need for keeping states in memory.However,after a long time running,such kind of streaming job needs to keep a lot of computation parameters,status and other data in memory, and large numbers of data objects are not active among them.If let them occupy memory,it will cause a great waste of system resource.This paper proposes a data object managing method for stream tasks,and hopes to optimize the memory use of streaming system to solve the according problem.This paper establishes lifecycle model for streaming data object(SDO),and uses application-driven,data-driven method to achieve appropriate expire-parameters for SDO. Finally,this paper tests the proposed method in applications of Internet of vehicles.Experiments show that the proposed method can effectively reduce inactive SDO number and improve resource utilization while ensuring the processing delay can be accepted by users.

Internet of vehicles;streaming system;inactive object;lifecycle management;data-driven model

10.3778/j.issn.1673-9418.1509013

A

TP391

*The National Natural Science Foundation of China under Grant No.91118008(國家自然科學基金).

Received 2015-08,Accepted 2015-10.

CNKI網絡優先出版:2015-10-30,http://www.cnki.net/kcms/detail/11.5602.TP.20151030.1620.006.html