你看看人家阿強(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)線的距離~