IoT前沿｜實戰說明Pravega的動態伸縮性
歡迎置身於5G時代。
在這裡，你的全身上下都被資料圍繞，無處不在的物聯網、穿梭自如的無人駕駛汽車讓資料來源源不斷產生，就像開著的水管，資料來源一直流出。你發現曾經用於分析大資料的方法已經失效，因為他們更適合批處理。
面對新的資料場景，你迫切需要一種能夠同時滿足低延時、僅處理一次、順序保證、檢查點的新的儲存系統，否則將無法立足於5G時代。
爭分奪秒，在你的悉心研發之下，新的儲存型別終於誕生了，你將它命名為“Pravega”，取梵語中“Good Speed”之意。
•
•
•
在前兩期的內容裡，我們介紹了未來大資料環境下需要新的儲存型別，即原生的流儲存，而Pravega正是為目的這一而生。並介紹了Pravega的關鍵特性，以及它能給開發人員和公司帶來的優勢。今天這篇文章，我們將從Pravega的動態伸縮性來談，並用一份紐約出租車資料寫入Pravega，來看它的動態伸縮表現。
▼▼▼
作者簡介
滕昱
滕昱：就職於Dell EMC中國研發集團，非結構化資料儲存部門團隊並擔任軟體開發總監。2007年加入Dell EMC以後一直專注於分散式儲存領域。參加並領導了中國研發團隊參與兩代Dell EMC物件儲存產品的研發工作並取得商業上成功。從2017年開始，兼任Streaming儲存和實時計算系統的設計開發與領導工作。
黃一帆
黃一帆：畢業於上海交通大學計算機專業，現就職於 DellEMC，10 年分散式計算、搜尋以及架構設計經驗，現從事流式系統相關的設計與開發工作。
周煜敏
周煜敏：復旦大學計算機專業研究生，從本科起就參與Dell EMC分散式物件儲存的實習工作。現參與Flink相關領域研發工作。
Pravega屬於戴爾科技集團IoT戰略下的一個子專案。該專案是從0開始構建，用於儲存和分析來自各種物聯網終端的大量資料，旨在實現實時決策。其結合了戴爾易安信PowerEdge伺服器，並無縫整合到非結構化資料產品組合Isilon和Elastic Cloud Storage（ECS）中，同時擁抱Flink生態，以此為使用者提供IoT所需的關鍵平臺。
Pravega能夠應對瞬時的資料洪峰，做到“削峰填谷”，讓系統自動地伴隨資料到達速率的變化而伸縮，既能夠在資料峰值時進行擴容提升瞬時處理能力，又能在資料谷值時進行縮容節省執行成本，而讀寫客戶端無需額外進行調整。這一特性對於企業尤其重要，Devops開銷在企業中都會被歸入產品TCO(Total Cost of Ownership) , 所以產品自身的動態自適應能力將會是必備條件。
下面我們就詳細講述Pravega動態彈性伸縮特性的實現和應用例項。
動態+伸縮性
對於分散式訊息系統來說，一個設計良好的，可擴充套件的分割槽機制必不可少。分割槽機制使得讀寫的並行化成為可能，而一個良好的分割槽擴充套件機制使得企業在面臨業務增長時可以變得更得心應手。和許多基於靜態分割槽，或者需要手動擴充套件分割槽（如Kafka）系統不同的是，Pravega可以根據資料負載動態地伸縮Stream，以此來實時地應對流量負載變化。
Pravega，把繁瑣變輕鬆
在當前大資料技術環境下，我們通過將資料拆分成多個分割槽並獨立處理來獲得並行性。 例如，Hadoop通過HDFS和map-reduce實現了批處理並行化。 對於流式工作負載，我們今天要使用多訊息佇列或Kafka分割槽來實現並行化。
這兩個選項都有同樣的問題：分割槽機制會同時影響讀客戶端和寫客戶端。 面對持續資料處理的讀/寫，我們的擴充套件要求往往會有不同，而一個同時影響讀寫的分割槽機制會增加系統的複雜性。此外，雖然你可以通過新增佇列或分割槽來進行擴充套件，但這需要分別對讀、寫客戶端和儲存進行手動調整，然後需要手動協調調整後的引數。這樣的操作不僅複雜，也不是動態的，需要人工介入。
而使用Pravega，我們可以輕鬆、彈性並且獨立地擴充套件資料的攝入、儲存和處理，即協調資料管道中每個元件的擴充套件。
Pravega Stream的動態伸縮智慧
Pravega對動態伸縮的支援源自於把Stream劃分成Segment的想法。
在之前的文章中有介紹過，一個Stream可以具有一個或多個Segment。我們可以把一個 Segment類比成一個分割槽，寫入Stream的任何資料都會根據指定路由鍵，通過雜湊計算路由至某一個Segment。 實際應用場景下，我們建議應用開發者基於一些有應用意義的欄位，比如customer-id，timestamp，machine-id等來生成路由鍵，這樣就可以確保將同類的應用資料路由至同一個Segment。
Segment是Stream中最基本的並行單元。
• 並行寫：一個具有更多個Segment的Stream可以支援更大的寫入並行度，多個寫客戶端可以並行地對多個 Segment 進行寫入，而這些Segment可能在物理上分佈於叢集中的多臺伺服器上。
• 並行讀：對讀客戶端來說，Segment的數量意味著最大的讀並行度。一個具有N個讀客戶端的讀者組可以以最大為N的並行讀來消費同一個Stream。這樣，當一個Stream中的Segment數量被動態增加時，我們可以相應地增加同等數量的讀客戶端（同一讀者組）來增加並行度；反之亦然，當Segment數量動態減少時，我們也可以減少相應的讀客戶端來節省資源。
深入剖析
Pravega根據一致性雜湊演算法將路由鍵雜湊至“鍵空間”，該鍵空間被劃分為多個分割槽，分割槽數量和Segment數量相一致，同時保證每一個Segment儲存著一組路由鍵落入同一區間的事件。
根據路由鍵，我們將一個Stream拆分成了若干個Segment，每一個Segment儲存著一組路由鍵落入同一區間的事件，並且擁有著相同的SLO。
同時，Segment可以被封閉（seal），一個被封閉的Segment將禁止寫入。這一概念在動態伸縮中將發揮重要作用。
例項說明伸縮過程
假設某製造企業有400個感測器，分別編號為0~399，我們將編號做為routing key，並將其雜湊分佈到 (0, 1) 的鍵空間中（Pravega也支援將非數值型的路由鍵雜湊到鍵空間中）。隨著部分感測器傳輸頻率的變化，我們來觀察其Segment的變化。
如圖1 所示，在 0~1區間的鍵空間中，Segment的合併和拆分導致了路由鍵隨著時間的推移而被路由至不同的Segment。
圖 1: Segment的合併和拆分對事件路由的影響
上圖所示的Stream從時間 t0 開始，它被配置成具有動態伸縮功能。 如果寫入流的資料速率不變，則段的數量不會改變。
在時間點t1，Pravega監控器注意到資料速率的增加，並且選擇將Segment 1拆分成Segment 2和 Segment 3兩部分，這個過程我們稱之為Scale-up事件。在t1之前，路由鍵雜湊到鍵空間上半部的（值為 200~399）的事件將被放置在 Segment 1中，而路由鍵雜湊到鍵空間下半部的（值為 0~199）的事件則被放置在 Segment 0 中。在 t1 之後Segment 1被拆分成Segment 2 和 Segment 3，Segment 1則被封閉，即不再接受寫入。 此時，具有路由鍵300及以上的事件被寫入 Segment 3，而路由鍵在200和299之間的事件將被寫入Segment 2。Segment 0則仍然保持接受與t1之前相同範圍的事件。
在t2時間點，我們看到另一個Scale-up事件。這次事件將Segment 0拆分成Segment 4和Segment 5。Segment 0因此被封閉而不再接受寫入。
具有相鄰路由鍵雜湊空間的Segment也可以被合併，比如在t3時間點，Segment 2和 Segment 5被合併成為Segment 6，Segment 2和Segment 5都會被封閉，而t3之後，之前寫入Segment 2和Segment 5的事件，也就是路由鍵在100和299之間的事件將被寫入新的Segment 6中。合併事件的發生表明Stream上的負載正在減少。
圖2: 事件的路由
如圖2，在“現在”這個時刻，只有Segment3，6 和4處於活動狀態，並且所有活躍的Segment將會覆蓋整個鍵空間。在上述的規則2和3中，即使輸入負載達到了定義的閾值，Pravega也不會立即觸發scale-up/down的事件，而是需要負載在一段足夠長的時間內超越策略閾值，這也避免了過於頻繁的伸縮策略影響讀寫效能。
真實資料用例
我們使用由美國紐約市政府授權開源的計程車資料， 包括上下車時間，地點，行程距離，逐項票價，付款型別、乘客數量等欄位。我們把歷史資料集模擬成了流式資料實時地寫入Pravega。所取的資料集涵蓋的是2015年3月的黃色計程車行程資料，其資料量為1.9GB，包括近千萬條記錄，每條記錄17個欄位。我們選取了其中12個小時的資料，形成如圖3所示資料統計：
黃色和綠色的計程車行程記錄包括捕獲乘客上車和下車日期/時間，接送和下車地點，行程距離，逐項票價，費率型別，付款型別和司機報告的乘客數量的欄位。我們把歷史資料集模擬成了流式資料實時地寫入Pravega。所取的資料集涵蓋的是2015年3月的黃色計程車的行程資料，其資料量為1.9GB，包括近千萬條記錄，每條記錄17個欄位。我們選取了其中12 個小時的資料，形成如圖3所示資料統計：
圖3: 計程車資料流量記錄
由上圖我們可以觀察到，資料流量在早上4點左右處於谷點，而在早晨9點左右達到峰值。峰值流量的寫入位元組數大約為谷點流量的10倍。我們將Stream的伸縮規則配置為上述規則2（基於大小的伸縮規則）。
相對應地，Stream的Segment熱點圖如圖4所示動態變化：
圖4: Segment 熱點圖
從上圖可以看出，從晚11點至凌晨2點，Segment逐漸合併；從早晨6點至10點，Segment逐步拆分。從拆分次數來看，大部分Segment總共拆分3次，小部分拆分4次，這也印證了流量峰值10倍於谷底的統計值（3
我們使用出租車行程中的出發點座標位置來作為路由鍵。當高峰來臨時，繁忙地段產生的大量事件會導致Segment被拆分，從而會有更多的讀客戶端來進行處理；當谷峰來臨時，非繁忙地段產生的事件所在的Segment會進行合併，部分的讀客戶端會下線，剩下的讀客戶端會處理更多地理區塊上產生的事件。
本章總結：
本期內容我們重點介紹了Pravega的動態伸縮機制。它可以讓應用開發和運維人員不必關心因流量變化而導致的分割槽變化需要，無需手動排程叢集。分割槽的流量監控和相應變化由Pravega來進行，從而使流量變化能夠實時而且平滑地體現到應用程式的伸縮上。獨立伸縮機制使得生產者和消費者可以各自獨立地進行伸縮，而不影響彼此。整個資料處理管道因此變得富有彈性，可以應對實時資料的不斷變化，結合實際處理能力而做出最為適時的反應。
截至目前，我們已經花了3個篇幅（第一期、第二期）詳細了Pravega，相信你對它已經有了一定的瞭解，話說百遍不如自己跑一遍，在下一期的“IoT前沿”中，我們就將為大家帶來實戰演練，介紹Pravega的部署方式。
歡迎大家持續關注，如何你有疑問，可在下方留言或知乎號上（見下方二維碼）找到我們。下一期見~
你和戴爾易安信專家只有一條網線的距離~