一種實時流計算流速感知彈性執(zhí)行容錯系統的制作方法
【技術領域】
[0001]本發(fā)明屬于大數據分布式計算領域，更具體地，涉及一種實時流計算流速感知彈性執(zhí)行容錯系統。
【背景技術】
[0002]當前，實時流計算受到了廣泛關注。學術界和工業(yè)界研發(fā)了多個流計算系統:Storm, S4, D-Streams, Puma, Flume, Streambase, Timestream，System S 等。開發(fā)者用上述系統提供的API描述處理邏輯構建應用程序。由于此類應用處理的數據量通常超過了單機器的處理能力且需要經過多個階段計算處理，系統將應用部署到多個機器上分布式執(zhí)行。流應用有如下典型特征:長時間運行，數據實時產生流入系統，流入率不可知，長期運行造成的錯誤累積和集群節(jié)點錯誤累積，所以流應用希望系統提供低延遲的處理能力(盡管輸入流率會變化和可用計算資源會變化)，失效后快速恢復的容錯能力。
[0003]流應用中的數據(通常稱為元組)在系統中經多階段處理。每個階段接收上一階段的元組輸入，此階段有以下處理行為:轉換處理(元組個數保持不變)、衍生出更多元組(元組個數增多)或合并上一階段的元組(元組個數減少)，從而造成各個階段本身具有不同的流速。當流應用起始輸入流速波動時，對各個階段造成的影響是不同的，每個階段需要擴展或收縮的算子(即處理單元)數目不盡相同，需要精細化區(qū)分控制以使各階段處理延遲相對穩(wěn)定。然而，當前的流計算系統精細化控制應用執(zhí)行方面做得不足。
[0004]流應用通常部署在云平臺或者大規(guī)模集群中，長時間運行，不可避免的帶來容錯問題，例如節(jié)點失效問題，元組快速處理過程中元組丟失問題等。
[0005]學術界和工業(yè)界對上述問題進行了積極探索研宄。流應用節(jié)點流速變化且沒有超過節(jié)點處理能力時，Scott Schneider向Stream S添加了彈性化處理單元。依據節(jié)點輸入流速的大小，該處理單元可以喚醒或者休眠不同數目的處理線程。Sparrow采用twochoice、懶綁定等技術使任務調度到負載較小的節(jié)點上去。當節(jié)點輸入流速的大小超過了節(jié)點處理能力，成為增加了整個處理延遲的瓶頸時，StreamCloud以增加處理子鏈的方式維持處理的低延遲。TimeStream使用了彈性替代的方法，在維持語義正確不變的情況下將瓶頸節(jié)點或者瓶頸子處理拓撲圖替換成處理能力更強的節(jié)點或者子處理拓撲圖。
[0006]至于容錯方面，TimeStream系統對每一個被處理的元組進行了跟蹤，并階段性保持處理節(jié)點的狀態(tài)，以便能夠失效恢復和元組在相應的處理單元重放處理。MillWheel提供持久化節(jié)點狀態(tài)和管理節(jié)點狀態(tài)的特性，同時運用水位模型標明元組到來的時間界限，并采用處理回復(ack)的方法保證元組的準確一次處理。Storm采用元組在每次處理前后生產兩個相同的值進行異或的方式，保證每個元組至少一次處理。Raul Castro Fernandez提出了一種基于處理單元狀態(tài)管理的方法并融合擴展和容錯為一體的策略，當節(jié)點成為系統瓶頸時，將其處理狀態(tài)進行分割、并行化擴展以保持低延遲。階段性地對處理節(jié)點狀態(tài)對檢查點，以便失效后快速恢復。
[0007]但是上述方法存在了以下缺點:不能充分利用整個集群的資源進行負載均衡、延遲保證，缺少協調節(jié)點處理速度與節(jié)點可用資源的調度策略；不能根據流速變化靈活快速地產生應對集群角度的整體策略(如調整算子數目，增加資源使用量)；當節(jié)點失效時，節(jié)點狀態(tài)尋回與檢測點時間戳之后的元組從原始階段重放并重新處理需要大量時間。

【發(fā)明內容】

[0008]針對現有的技術缺陷，本發(fā)明提供了一種融合了流速感知、彈性執(zhí)行和容錯一體化的解決方案一一實時流計算流速感知彈性執(zhí)行容錯系統，旨在保證流應用的穩(wěn)定性與低延遲，同時兼顧提高集群資源的利用率、流應用容錯及快速恢復。
[0009]為實現上述目的，本發(fā)明提供了一種實時流計算流速感知彈性執(zhí)行容錯系統，包括部署管理模塊、流速感知模塊、元組分發(fā)管理模塊、彈性執(zhí)行協調模塊、狀態(tài)管理模塊、錯誤檢測模塊、恢復協調模塊、集群管理模塊、應用管理模塊。
[0010]在本系統中，集群管理模塊、應用管理模塊、部署管理模塊、協調恢復模塊、彈性執(zhí)行協調模塊相應進程都運行在管理節(jié)點上。由于上述模塊資源消耗較少且有的較少用到，所以管理節(jié)點不會因此成為瓶頸。而流速感知模塊、狀態(tài)管理模塊、錯誤檢測模塊部署在所有工作節(jié)點上，默認元組分發(fā)管理模塊同時部署在所有工作節(jié)點上，用戶可以用另外的消息分發(fā)系統如kafka、netty等來代替元組分發(fā)管理模塊，系統提供相應接口。
[0011]應用管理模塊接收用戶提交的應用代碼，將代碼解析成部署管理模塊可以識別和分割的格式。部署管理模塊對應用管理模塊處理后的內容進行相應的識別、分割，根據應用配置向集群管理模塊申請工作節(jié)點，并向工作節(jié)點發(fā)送任務代碼，工作節(jié)點收到任務代碼后，啟動相應的處理單元。元組分發(fā)調整模塊根據處理單元間的邏輯關系，設置發(fā)送關系，并批量地向持久存儲系統發(fā)送元組進行備份。當應用運行后，流速感知模塊啟動，感知工作節(jié)點及其上部署的處理單元處理效率、元組分發(fā)管理模塊中元組停留延遲。流速感知模塊感知因為流輸入率或可用資源的變化而引起的體現在應用延遲、處理效率等方面的變化，將上述變化信息告知彈性執(zhí)行協調模塊。彈性執(zhí)行協調模塊根據感知信息選擇開啟更多處理單元還是合并回收部分節(jié)點以提高資源利用率。當彈性執(zhí)行協調模塊判斷需要開啟更多處理單元時，將向部署管理模塊請求部署更多處理單元，部署管理模塊向集群管理模塊請求新節(jié)點；當部署完成后，向元組分發(fā)管理模塊請求調整元組分發(fā)關系。元組分發(fā)管理模塊結合狀態(tài)管理模塊對系統處理狀態(tài)進行備份以備失效后恢復。狀態(tài)管理模塊階段性地對處理單元處理狀態(tài)做檢查點(快照)，元組分發(fā)管理模塊成批發(fā)送檢查點時間戳之后的元組，持久存儲系統中保留者隨時可供恢復的處理狀態(tài)和此快照檢查點后應該處理的元組。當錯誤檢測模塊檢測到錯誤發(fā)生后，向恢復協調模塊申請恢復，恢復協調模塊向狀態(tài)管理模塊申請找回狀態(tài)，并向部署管理模塊請求重新部署處理單元。
[0012]下面就上述模塊進行簡要說明:
[0013](I)部署管理模塊，用于接收應用管理模塊處理后的流應用邏輯拓撲圖或彈性執(zhí)行協調模塊、恢復協調模塊的命令請求將應用部署成并行的多線程組成的執(zhí)行拓撲圖。
[0014](2)流速感知模塊，用于感知應用數據輸入率、可用資源變化而引起延遲、資源利用率變化，從而結合彈性執(zhí)行協調模塊進行運行時動態(tài)調整以保證系統的穩(wěn)定性、應用的低延遲性。此模塊包括節(jié)點流速感知子模塊和應用級流速感知子模塊；其中，所述節(jié)點流速感知子模塊，用于感知單位時間內通過節(jié)點元組數量即處理單元處理元組的處理效率；所述應用級流速感知子模塊，用于感知應用中的數據流過處理階段的流速，此流速可以用元組在元組分發(fā)子系統(元組分發(fā)管理模塊)中停留的時間來進行衡量。
[0015](3)元組分發(fā)管理模塊，用于根據流速感知信息或彈性執(zhí)行協調模塊的請求調整元組分發(fā)，將元組發(fā)給下一階段中會最快處理的處理節(jié)點；或當流速穩(wěn)定時根據已經固定的分發(fā)關系，快速地成批地分發(fā)元組。同時，成批地將元組發(fā)送一份到持久存儲器中，以便未來恢復使用。
[0016](4)彈性執(zhí)行協調模塊，用于根據流速信息靈活地開啟、關閉處理線程、進程、節(jié)點，調整處理單元并行數，以精確控制元組在分發(fā)系統中的停留時間和處理節(jié)點的處理時延。當收到流速感知模塊的感知信息，分析出應用數據輸入率變大、延遲變大或節(jié)點過于繁忙時，彈性執(zhí)行協調模塊會尋求開啟更多的處理單元；當節(jié)點由于其他應用輸入率變大而使此應用可用資源變少而處理效率變低時，彈性執(zhí)行協調模塊會尋求開啟更多的處理單元。當應用數據輸入率變小(流速降低)并且節(jié)點資源利用率過低時