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

【發(fā)明內(nèi)容】

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