呂勤

摘要：目前市場上的大數據流式處理系統(tǒng)普遍存在計算結果不能共享、實時處理性能不高、計算時間窗口固定和不能動態(tài)擴容等問題。針對這些問題，本文設計了一種基于新型時間切片原理，具備動態(tài)資源調度、系統(tǒng)容錯、動態(tài)窗口計算能力的高性能大數據流式處理系統(tǒng)。

關鍵詞：大數據流式處理;時間窗口;實時計算

中圖分類號：TP319 文獻標識碼：A 文章編號：1007-9416（2020）03-0140-03

1 大數據流式處理面臨的挑戰(zhàn)

目前業(yè)內主流的大數據流式處理系統(tǒng)面臨諸多挑戰(zhàn)，最突出的包括計算資源和存儲資源的動態(tài)調度分配、系統(tǒng)容錯和動態(tài)時間窗口調整等。在資源調度方面，許多流式處理系統(tǒng)普遍采用多節(jié)點進行分布式數據計算和數據結果的存儲，技術難點在于數據流對多個計算節(jié)點的均勻分配以及數據結果的均勻存儲和各個節(jié)點資源的均衡使用。此外，在大數據流式處理過程中，數據分發(fā)節(jié)點、計算節(jié)點和存儲節(jié)點間存在大量的數據交互，網絡資源消耗極高，往往成為系統(tǒng)性能瓶頸。在系統(tǒng)容錯方面需要在單個節(jié)點出現故障時，能保證整體系統(tǒng)的正常運行。當整個系統(tǒng)資源不足以滿足數據的處理時，還要能在保證當前系統(tǒng)的穩(wěn)定運行情況下動態(tài)添加資源，以實現系統(tǒng)處理能力的動態(tài)擴展[1]。在計算窗口方面，因為存在計算任務執(zhí)行過程中只保存數據處理的結果數據、流入的原始數據被丟棄等原因，多數流式處理系統(tǒng)的計算窗口都是靜態(tài)的，無法支持在計算任務啟動后臨時調整計算窗口。

2 大數據流式處理系統(tǒng)架構

為了滿足業(yè)務發(fā)展對高性能實時指標計算能力的需要，同時解決目前行業(yè)內同類工具普遍存在的問題，采用新型的時間切片原理，在利用Kafka、Netty和Redis等開源組件的技術特性的基礎上，設計了一套高性能的大數據流式處理系統(tǒng)。該系統(tǒng)主要功能包括接受外部系統(tǒng)流水數據、實時指標計算和向外部系統(tǒng)提供指標查詢等功能。系統(tǒng)分為四層架構，分別為通訊層、服務層（Server層）、計算層（Agent層）和計算結果緩存層，每層均為多節(jié)點集群，緩存層由Redis集群組成，計算層與緩存層的節(jié)點按照1∶1配置，部署在同一物理節(jié)點上[2]。系統(tǒng)架構參見圖1。

（1）通信層負責與外部系統(tǒng)的交互。通訊層采用kafka作為數據流入起點。Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，十分適合作為流式處理系統(tǒng)的數據“生產者”和“消費者”。通訊層通過訂閱kafka中的topic，接受外部系統(tǒng)的流水數據并發(fā)送到后端服務層。同時通訊層還負責接受外部系統(tǒng)的指標查詢服務請求，并將從服務層獲取的查詢結果反饋給外部系統(tǒng)。

（2）服務層主要功能包括計算指令分發(fā)、計算任務監(jiān)控和指標結果二次加工等。在接收到通訊層發(fā)來的流水數據后，服務層先通過對流入數據關鍵值的判斷，確定需要執(zhí)行的計算任務（計算任務是最小的計算單位），再通過對計算任務參數的組合計算，確定具體的計算節(jié)點。服務層將流水數據和需要執(zhí)行的計算任務列表進行封裝，通過Netty分發(fā)到指定的計算節(jié)點。

服務層通過收集計算節(jié)點的執(zhí)行狀態(tài)實現對計算任務監(jiān)控。當所有的計算任務都執(zhí)行成功后，服務層認為當前流入數據已被系統(tǒng)正常處理。如果有計算任務執(zhí)行失敗，數據分發(fā)節(jié)點會分析失敗原因并決定是否轉派其他計算節(jié)點再次執(zhí)行。

服務層在響應指標查詢服務請求，獲取緩存節(jié)點上的中間結果后，根據預置的處理公式進行二次或多次加工，最終完成服務。

（3）計算層主要功能包括計算任務執(zhí)行、異常處理、數據序列化以及時間切片等。計算節(jié)點識別服務層分發(fā)的數據，并使用對應的算子和原有緩存節(jié)點中的計算結果合并計算，合并計算的結果再次保存到緩存節(jié)點中，并向服務層返回任務執(zhí)行成功狀態(tài)。若計算任務出現異常，則向服務層返回計算任務執(zhí)行失敗狀態(tài)，結果數據不保存。

（4）緩存層主要功能為存儲計算結果，由Redis集群構成。Redis集群內置的自動分區(qū)、復制、LRU逐出、事務等特性為系統(tǒng)緩存層的高可用和高性能提供了保證。

3 系統(tǒng)技術特色與實現原理

該系統(tǒng)具備動態(tài)資源調度、系統(tǒng)容錯和動態(tài)調整指標計算時間窗口等能力，處理性能高效，運行穩(wěn)定。該系統(tǒng)實現以上能力，主要實現了以下幾項關鍵的技術。

3.1 動態(tài)資源調度

資源調度的核心技術是本地數據本地計算的MPP架構和均勻存儲均勻計算。

（1）本地數據本地計算的MPP架構設計：通過將計算節(jié)點和存儲節(jié)點1∶1的部署在同一物理節(jié)點的部署方式，實現數據的讀取、計算和結果回寫均能在同一物理節(jié)點上執(zhí)行，形成MPP架構，大幅減少網絡開銷[3]。

（2）均勻存儲均勻計算：系統(tǒng)采用Redis的hash算法以及Server、Agent與Redis的協(xié)同實現了均勻存儲均勻計算。具體來講，均勻存儲的實現是利用Redis Cluster4.0的新技術特性，把所有數據劃分為16384個不同的虛擬槽，根據機器的性能可以把不同的槽位分配給不同的Redis節(jié)點。通過對流水數據的關鍵值和計算任務的ID進行hash計算找到數據對應的槽位。Server端存儲一張槽位與機器的對應關系表，在根據槽位找到對應的具體機器的同時，也確定了對應的Redis存儲節(jié)點。在這種機制下某個Redis節(jié)點只會存儲對應部分的數據，并且保證數據均勻分散在不同的Redis節(jié)點上。均勻計算也遵循了同樣的原理。服務層通過同樣的流水數據的關鍵值和計算任務的ID進行hash計算找到計算任務對應的槽位和對應的Agent節(jié)點。計算任務和數據存儲的分布遵循同樣的hash算法，也保證了計算節(jié)點上的計算任務和存儲節(jié)點上的數據的一致性。

3.2 系統(tǒng)容錯

在傳統(tǒng)的Keepalived+Nginx的容錯技術以外，該系統(tǒng)還通過健康狀態(tài)監(jiān)控機制實現系統(tǒng)容錯。Server節(jié)點和Agent節(jié)點都有各自的健康狀態(tài)監(jiān)聽模塊來記錄本節(jié)點的健康狀態(tài)。此外Agent節(jié)點定期向Server層發(fā)送心跳匯報節(jié)點健康狀態(tài)信息，Server層根據Agent節(jié)點的健康狀態(tài)動態(tài)調整數據的分發(fā)和計算任務的分配，保證分發(fā)時避開不健康的計算節(jié)點。

在計算節(jié)點出現故障時，通過兩段處理的方式保證計算任務的正常進行。第一段處理，服務層在分發(fā)計算內容前，先判斷計算節(jié)點的健康狀態(tài)，如果該計算節(jié)點狀態(tài)為非健康，則隨機選擇一個健康的計算節(jié)點進行分發(fā)。由于新選擇的計算節(jié)點對應的緩存節(jié)點中未存儲對應的數據，該計算節(jié)點通過Redis Cluster的保障機制從其他緩存節(jié)點找到對應的中間數據，保證計算服務的持續(xù)進行。第二段處理，計算節(jié)點在出現故障時會嘗試自動重啟。如果重啟失敗，則繼續(xù)維持第一段處理，如果重啟成功，則Agent會向Server重新上報健康狀態(tài)，恢復正常工作。

3.3 動態(tài)窗口

所謂動態(tài)時間窗口，即在不需要重新發(fā)布計算任務的前提下，可以實時調整指標查詢窗口的大小，且能立即獲得對應的結果。目前大多數基于窗口的流式計算解決方案都不能很好地支持動態(tài)窗口。其根本原因在于這些解決方案的計算任務都是基于源數據的，由于源數據的數據量大，導致無法在長時間保存源數據的同時又支持快速計算指標結果。在本處理系統(tǒng)中，動態(tài)窗口的實現基于系統(tǒng)獨有的時間切片的設計原理。

時間切片設計原理：時間切片是將時序數據按照一定的時間間隔聚合后的新的時序數據。一個時間切片是數據信息保存的最小單位，也是保存數據的主要形式。在本系統(tǒng)中，時間切片中不存儲源數據，而是存儲該切片時間段內所有流水數據按照指標配置進行聚合計算后得到的結果數據，這種設計大幅壓縮了數據存儲量，可以存儲較長時間的數據。本系統(tǒng)通過Redis技術實現流水數據的時間切片處理。當流水數據進入到某個具體的數據計算任務后，首先提取流水數據的發(fā)生時間，然后根據流水數據的關鍵值和計算任務ID拼裝成Redis的key，根據key取出對應的value，并讀取value中最新切片的時間。如果流水數據的發(fā)生時間比該切片時間早，則不需要創(chuàng)建新的切片，找到當前的流水數據對應的時間切片，并根據任務里配置的聚合函數計算結果并更新該時間切片的value，更新回Redis中。如果流水數據的發(fā)生時間晚于目前的處理時間，則需要創(chuàng)建新的切片，并根據任務里配置的聚合函數計算出當前流水數據的結果后存入Redis中。時間切片在Redis中的存儲參見圖2。

在指標查詢任務中，時間切片的選取采用落入即包含的策略。切片選取策略參見圖3。以5分鐘切片為例，從起始切片開始，每隔5分鐘開啟一個新的切片，T為當前時刻，H為指標計算所需的持續(xù)時間，從T-H到T就是指標計算的時間長度。如果T-H正好處于時間切片首尾，就將X個時間切片納入計算，如果T-H在某個時間切片的中間位置，則采用時間覆蓋原則，將該時間切片全部納入計算。在圖3中，虛線段是指標計算的理論時間長度，實線段是指標計算的實際時間長度。采用這種策略，雖然在精度上有細微損失，但大幅提高了計算效率。當需要動態(tài)調整指標查詢的時間窗口時，無需對源數據重新計算，只需要通過必要的二次計算即可實時獲取新的結果，實現動態(tài)窗口設置的實時生效。

4 結論

本文提出的基于窗口計算的大數據流式處理系統(tǒng)已經實際投入應用。整個系統(tǒng)采用三臺服務器搭建Kafka集群、兩臺服務器搭建服務層、四臺服務器搭建數據計算集群和存儲集群。在壓力測試中，在并發(fā)數為100且單條數據大小不超過5M的情況下，集群的指標查詢性能達到7萬TPS，成功率100%。以實際生產數據測試，在60秒內發(fā)起2.3億次指標查詢請求，系統(tǒng)的平均響應時間為16ms，TPS為24600左右，且此時的各節(jié)點硬件資源使用均未達到極限。通過橫向動態(tài)擴展和網絡優(yōu)化，該流式處理系統(tǒng)的計算能力還能線性提高[4]。

參考文獻

[1] 孫大為，張廣艷，鄭緯民.大數據流式計算：關鍵技術及系統(tǒng)實例[J].軟件學報，2014，25（04）：839-862.

[2] 王奇.基于發(fā)布訂閱的分布式復雜事件處理系統(tǒng)的研究與實現[D].北京：北京郵電大學，2018.

[3] 蘇錦.基于Netty的高性能RPC服務器的研究與實現[D].南京：南京郵電大學，2018.

[4] 崔曉旻.基于Netty的高可服務消息中間件的研究與實現[D].成都：電子科技大學，2014.

Abstract：At present， there are many problems in big data streaming processing systems in the market， such as the calculation results can not be shared， the real-time processing performance is not high， the calculation time window is fixed， and the calculation capacity cannot be expanded dynamically. To solve these problems， this paper designs a high-performance streaming data processing system based on the new time slicing principle， which has the ability of dynamic resource scheduling， system fault tolerance and dynamic window computing.

Key words：big data stream processing; time window; real time computing