你看看人家阿強(qiáng)，
差點(diǎn)就把后半輩子規(guī)劃想好了
▼
阿強(qiáng)：鑒于對未來一片迷茫，我已經(jīng)想好了后半輩子的人生規(guī)劃...
李小男：哇，受什么刺激了?
阿強(qiáng)：公司在規(guī)劃5G戰(zhàn)略，可我一想到Lambda應(yīng)對流數(shù)據(jù)的能力就開始發(fā)愁。佛了，X煙、喝酒、植發(fā)，這大概就是我今后的人生三件大事......
李小男：聽過那個“藍(lán)鳥”沒有?
阿強(qiáng)：姐，就別拿我開玩笑了...還藍(lán)鳥?下輩子的房貸都在愁呢
李小男：Pravega去了解一下，你會回來感謝我的~
30分鐘后...
阿強(qiáng)：姐，我復(fù)活了，未來，充滿信心!
李小男：先別急著激動，還沒謝謝我吶
然鵝
僅僅拯救這個阿強(qiáng)還不夠
因?yàn)?，還有無數(shù)個阿強(qiáng)在等待
看完這篇文章
救救你身邊的阿強(qiáng)!
▼
上一期內(nèi)容我們講到：5G時代到來，無處不在的物聯(lián)網(wǎng)、自動駕駛汽車等在邊緣產(chǎn)生的數(shù)據(jù)源源不斷，就像開著的水管，數(shù)據(jù)源一直流出，由此誕生了新的數(shù)據(jù)類型即“流數(shù)據(jù)”。然而，無論Hadoop還是Lambda，都無法勝任新數(shù)據(jù)環(huán)境下的要求，因?yàn)橛?jì)算是原生的流計(jì)算，而存儲卻不是原生的流存儲。(上一期文章)
針對流數(shù)據(jù)的應(yīng)用場景，流數(shù)據(jù)存儲需要滿足低延時、僅處理一次、順序保證、檢查點(diǎn)這四點(diǎn)要求。
因此戴爾科技集團(tuán)IoT部門的團(tuán)隊(duì)重新思考了流式數(shù)據(jù)處理和存儲規(guī)則，為流數(shù)據(jù)場景設(shè)計(jì)了新的存儲類型，即原生的流存儲，并由此誕生了“Pravega”。
于是今天我們把目光聚焦Pravega，來一次Deep Dive，潛入深海，重點(diǎn)介紹Pravega的特點(diǎn)與優(yōu)勢，看它是如何解決新數(shù)據(jù)環(huán)境下的流數(shù)據(jù)問題。
▼▼▼
作者簡介
滕昱
滕昱：就職于Dell EMC中國研發(fā)集團(tuán)，非結(jié)構(gòu)化數(shù)據(jù)存儲部門團(tuán)隊(duì)并擔(dān)任軟件開發(fā)總監(jiān)。2007年加入Dell EMC以后一直專注于分布式存儲領(lǐng)域。參加并領(lǐng)導(dǎo)了中國研發(fā)團(tuán)隊(duì)參與兩代Dell EMC對象存儲產(chǎn)品的研發(fā)工作并取得商業(yè)上成功。從2017年開始，兼任Streaming存儲和實(shí)時計(jì)算系統(tǒng)的設(shè)計(jì)開發(fā)與領(lǐng)導(dǎo)工作。
周煜敏
周煜敏：復(fù)旦大學(xué)計(jì)算機(jī)專業(yè)研究生，從本科起就參與Dell EMC分布式對象存儲的實(shí)習(xí)工作。現(xiàn)參與Flink相關(guān)領(lǐng)域研發(fā)工作。
吳長平
吳長平：現(xiàn)就職于Dell EMC，10年+存儲、分布式、云計(jì)算開發(fā)以及架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)，現(xiàn)從事流存儲和實(shí)時計(jì)算系統(tǒng)的設(shè)計(jì)與開發(fā)工作。
Pravega，取梵語中“Good Speed”之意，其設(shè)計(jì)宗旨是成為流的實(shí)時存儲解決方案。它屬于戴爾科技集團(tuán)IoT戰(zhàn)略下的一個子項(xiàng)目。該項(xiàng)目是從0開始構(gòu)建，用于存儲和分析來自各種物聯(lián)網(wǎng)終端的大量數(shù)據(jù)，旨在實(shí)現(xiàn)實(shí)時決策。其結(jié)合了戴爾易安信PowerEdge服務(wù)器，并無縫集成到非結(jié)構(gòu)化數(shù)據(jù)產(chǎn)品組合Isilon和Elastic Cloud Storage(ECS)中，同時擁抱Flink生態(tài)，以此為用戶提供IoT所需的關(guān)鍵平臺。
針對上面說到的四點(diǎn)要求，從訪問模式角度來說，Pravega統(tǒng)一了傳統(tǒng)批數(shù)據(jù)和流數(shù)據(jù)，因此不僅可以實(shí)時到達(dá)數(shù)據(jù)的低延時 (low latency) 讀和寫，還可以滿足對于歷史數(shù)據(jù)的高吞吐 (high throughput) 的讀。
技術(shù)在某種程度上一定是來自此前已有技術(shù)的新的組合。
——《技術(shù)的本質(zhì)》，布萊恩•阿瑟
當(dāng)然，Pravega 也不是憑空發(fā)明出來的，它也是以前的成熟技術(shù)與新技術(shù)的組合。Pravega團(tuán)隊(duì)擁有基于日志存儲的設(shè)計(jì)經(jīng)驗(yàn)，也擁有Apache ZooKeeper/BookKeeper的項(xiàng)目歷史，加之大量實(shí)時系統(tǒng)同樣也采用日志存儲的方式來完成實(shí)時應(yīng)用的消息隊(duì)列，想要滿足尾讀、尾讀和追趕讀這三種據(jù)訪問模式，自然想到了使用僅附加 (Append Only) 的日志作為存儲原語。
圖 1. 日志結(jié)構(gòu)的三種數(shù)據(jù)訪問機(jī)制
如圖1所示：在Pravega里，日志是作為共享存儲原語而存在的，數(shù)據(jù)以事件 (event) 的形式以僅附加的方式寫入日志當(dāng)中。
所有寫入操作以及大部分讀取操作都發(fā)生在日志的尾部 (tail read/write)。寫操作將事件附加到日志中，而大量讀客戶端希望以到達(dá)日志的速度讀取數(shù)據(jù)。這兩種數(shù)據(jù)訪問機(jī)制主要是需要低延遲。
對于歷史數(shù)據(jù)的處理，讀客戶端不從日志的尾部讀取，而是從日志中的任意位置開始讀。這些讀取稱為追趕讀 (catch-up read)。我們可以采用和尾部數(shù)據(jù)一樣的高性能存儲(例如SSD)來存儲歷史數(shù)據(jù)，但這會非常昂貴并迫使用戶通過刪除歷史數(shù)據(jù)來節(jié)省成本。這就需要Pravega架構(gòu)提供一種機(jī)制，允許客戶在日志的歷史部分使用經(jīng)濟(jì)高效，高度可擴(kuò)展的高吞吐量存儲，這樣他們就能夠保留所有的歷史數(shù)據(jù)，來完成對一個完整數(shù)據(jù)集的讀取。
Pravega支持僅一次處理 (exactly-once)，可在Kappa架構(gòu)上實(shí)現(xiàn)鏈接應(yīng)用需求，以便將計(jì)算拆分為多個獨(dú)立的應(yīng)用程序，這就是流式系統(tǒng)的微服務(wù)架構(gòu)。我們所設(shè)想的架構(gòu)是由事件驅(qū)動、連續(xù)和有狀態(tài)的數(shù)據(jù)處理的流式存儲 - 計(jì)算的模式(如圖 2)。
圖 2.流處理的簡單生命周期
通過將Pravega流存儲與Apache Flink有狀態(tài)流處理器相結(jié)合，上圖中的所有寫、處理、讀和存儲都是獨(dú)立的、彈性的，并可以根據(jù)到達(dá)數(shù)據(jù)量進(jìn)行實(shí)時動態(tài)擴(kuò)展。這使我們所有人都能構(gòu)建以前無法構(gòu)建的流式應(yīng)用，并將其從測試原型無縫擴(kuò)展到生產(chǎn)環(huán)境。擁有了Pravega，Kappa架構(gòu)得以湊齊了最后的拼圖，形成了統(tǒng)一存儲、統(tǒng)一計(jì)算的閉環(huán)。
Pravega 邏輯架構(gòu)
圖 3. Pravega架構(gòu)
為了實(shí)現(xiàn)上述的三種訪問模式的性能需求，Pravega采用了如圖3所示的分層存儲架構(gòu)。事件可以存儲在低延遲/高 IOPS的存儲(第一層存儲)和更高吞吐量的存儲(第二層存儲)中。通過這種方式，冷熱數(shù)據(jù)分離有效降低了數(shù)據(jù)存儲成本。上層使用Apache ZooKeeper作為分布式協(xié)調(diào)器，并提供統(tǒng)一的Stream抽象。
第一層存儲
第一層存儲用于快速持久地將數(shù)據(jù)寫入Stream，并確保從Stream的尾讀盡可能快。第一層存儲基于開源Apache BookKeeper項(xiàng)目。BookKeeper是一種底層的日志服務(wù)，具有高擴(kuò)展、強(qiáng)容錯、低延遲等特性。許多Apache開源項(xiàng)目，例如Apache Pulsar，Apache DistributedLog都是基于這一項(xiàng)目實(shí)現(xiàn)。BookKeeper對于復(fù)制、持久性、一致性、可用性、低延時的承諾也正是Pravega所需要的第一層存儲的需求。為達(dá)到高性能的讀寫延遲需求，我們建議第一層存儲通常在更快的 SSD 或甚至非易失性存儲 (non-volatile RAM) 上實(shí)現(xiàn)。
第二層存儲
第二層存儲考慮到經(jīng)濟(jì)效益，選用高度可擴(kuò)展，高吞吐量的云存儲，目前Pravega支持HDFS，NFS和S3協(xié)議的二級存儲，用戶可以選用支持這些協(xié)議的大規(guī)模存儲進(jìn)行擴(kuò)展。Pravega提供了兩種數(shù)據(jù)降層 (retention) 的模式，一種基于數(shù)據(jù)在Stream中保留的時間，另一種基于數(shù)據(jù)在Stream中存儲的容量大小。Pravega會異步將事件從第一層遷移到第二層，而讀寫客戶端將不會感知到數(shù)據(jù)存儲層級的變化，依然使用同樣的Stream抽象操作數(shù)據(jù)的讀寫。
正是基于這樣的分層模型，大數(shù)據(jù)處理的降低開發(fā)成本、減少存儲成本與減少運(yùn)維成本這三大問題被Pravega一次性解決了。
? 對開發(fā)者而言，只需要關(guān)心Stream抽象的讀寫客戶端的操作。實(shí)時處理和批處理不再區(qū)分對數(shù)據(jù)訪問方式，由此提升了效率，帶來開發(fā)成本的降低。
? 數(shù)據(jù)僅在第一層存儲有三份拷貝，在第二層存儲則可以通過商業(yè)分布式 / 云存儲自身擁有的高可用、分布式數(shù)據(jù)恢復(fù)機(jī)制(如 Erasure Coding)進(jìn)一步降低存儲系數(shù)，達(dá)到比公有云存儲更便宜的總體擁有成本 (TCO)。
? 所有的存儲組件歸結(jié)為統(tǒng)一的Pravega，組件僅包括Apache ZooKeeper，Apache BookKeeper以及可托管的第二層存儲，運(yùn)維復(fù)雜程度大大降低。Pravega還提供了額外的“零運(yùn)維”自動彈性伸縮特性，進(jìn)一步減輕了數(shù)據(jù)高峰期的運(yùn)維壓力。
Pravega 產(chǎn)Pravega 產(chǎn)品定位和與 kafka 的對比比
讓我們以當(dāng)今業(yè)界應(yīng)用最廣的分布式消息系統(tǒng)Apache Kafka作為對比，看看Pravega如何實(shí)現(xiàn)了今天存儲無法實(shí)現(xiàn)的方式。
Pravega是從 存儲的視角 來看待流數(shù)據(jù)，而Kafka本身的定位是消息系統(tǒng)而不是存儲系統(tǒng)，它是從 消息的視角 來看待流數(shù)據(jù)。消息系統(tǒng)與存儲系統(tǒng)的定位是不同的，簡單來說，消息系統(tǒng)是消息的傳輸系統(tǒng)，關(guān)注的是數(shù)據(jù)傳輸與生產(chǎn)消費(fèi)的過程。Pravega的定位是企業(yè)級的分布式流存儲產(chǎn)品，除了滿足流的屬性之外，還需要滿足數(shù)據(jù)存儲的持久化、安全、可靠性、一致性、隔離等屬性，關(guān)注數(shù)據(jù)的生產(chǎn)、傳輸、存放、訪問等整個數(shù)據(jù)的生命周期。作為企業(yè)級的產(chǎn)品，一些額外的特性也有支持，例如：數(shù)據(jù)安全、多租戶、自動擴(kuò)縮容、狀態(tài)同步器、事務(wù)支持等，部分特性將在后續(xù)文章詳述。
這里我們把Pravega與Kafka做了對比，大體在功能上的差異如下表所示。功能上的差異也只是說明各個產(chǎn)品針對的業(yè)務(wù)場景不同，看待數(shù)據(jù)的視角不同，并不是說明這個產(chǎn)品不好，另外每個產(chǎn)品自身也在演進(jìn)，因此本對比僅供參考。
總結(jié)：
本期內(nèi)容我們主要介紹了重點(diǎn)介紹了Pravega的關(guān)鍵架構(gòu)以及關(guān)鍵特性，以及它能給開發(fā)人員和公司帶來的優(yōu)勢，并與Kafka做了簡要對比。下一期的“IoT前沿”中，我們將重點(diǎn)介紹Pravega的伸縮性，并通過相關(guān)案例來輔助說明，歡迎大家持續(xù)關(guān)注，如何你有疑問，可以在下方進(jìn)行留言或在知乎號上找到我們(見下方二維碼)我們將為你答疑解惑。下一期見~
掃碼關(guān)注知乎號
你和戴爾易安信專家只有一條網(wǎng)線的距離~
京公網(wǎng)安備 11010502049343號