工業(yè)物聯(lián)網(wǎng)，車(chē)聯(lián)網(wǎng)和實(shí)時(shí)欺詐風(fēng)控的需求正在飛速的發(fā)展。越來(lái)越多的企業(yè)新應(yīng)用，需要的是快速響應(yīng)客戶(hù)需求，并同時(shí)學(xué)習(xí)和適應(yīng)不斷變化的行為模式。同時(shí)隨著 5G 網(wǎng)絡(luò)、容器云、高性能存儲(chǔ)硬件水平的不斷提高，讓實(shí)時(shí)流處理正在擁有越來(lái)越廣泛的市場(chǎng)前景。

流處理在短時(shí)間內(nèi)就能夠?qū)�連續(xù)生成的數(shù)據(jù)進(jìn)行分析產(chǎn)生價(jià)值，而無(wú)需等待批處理中累積和處理，從攝取到結(jié)果的低延遲是流處理技術(shù)提供的最為關(guān)鍵的優(yōu)勢(shì)。例如對(duì)于車(chē)載系統(tǒng)的分析反饋，集群性能日志數(shù)據(jù)的分析告警，金融欺詐風(fēng)控的精準(zhǔn)定位、物聯(lián)網(wǎng)煤氣泄漏事件處理等應(yīng)用而言，高并發(fā)下的 10ms 級(jí)別的低延時(shí)意味著最關(guān)鍵的商業(yè)價(jià)值。

流式處理看似簡(jiǎn)單 : 只需在數(shù)據(jù)到達(dá)時(shí)以快速、持續(xù)和無(wú)限的方式對(duì)其進(jìn)行處理和操作。但實(shí)際情況是，大多數(shù)企業(yè)并沒(méi)有可以支持到 PB 至 EB 數(shù)據(jù)量級(jí)，并同時(shí)滿(mǎn)足采集速率、故障恢復(fù)能力的實(shí)時(shí)存儲(chǔ) / 計(jì)算引擎。 隨著適合處理批、實(shí)時(shí)場(chǎng)景的各種定制化存儲(chǔ)、計(jì)算引擎的出現(xiàn)，在業(yè)務(wù)不斷擴(kuò)展的過(guò)程中，也就無(wú)法避免地在企業(yè)級(jí)別的大數(shù)據(jù)系統(tǒng)之上堆積復(fù)雜性，造成了不小的資源浪費(fèi)以及運(yùn)維困難。

流式傳輸迫使系統(tǒng)設(shè)計(jì)人員重新思考基本的計(jì)算和存儲(chǔ)原則。當(dāng)前的大數(shù)據(jù)處理系統(tǒng)無(wú)論是何種架構(gòu)都面臨一個(gè)共同的問(wèn)題，即：“計(jì)算是原生的流計(jì)算，而存儲(chǔ)卻不是原生的流存儲(chǔ)” 。Pravega 團(tuán)隊(duì)重新思考了這一基本的數(shù)據(jù)處理和存儲(chǔ)規(guī)則，為這一場(chǎng)景重新設(shè)計(jì)了一種新的存儲(chǔ)類(lèi)型，即原生的流存儲(chǔ)，命名為”Pravega”，取梵語(yǔ)中“Good Speed”之意。

 

 

在 Pravega 之前的流數(shù)據(jù)處理

在大數(shù)據(jù)繁榮的早期階段，MapReduce 興起，我們可以使用數(shù)千臺(tái)服務(wù)器的集群分布式處理大量(TB 至 PB 級(jí)別)的數(shù)據(jù)集。在一個(gè)或多個(gè)大數(shù)據(jù)集上運(yùn)行的這種類(lèi)型的分布式計(jì)算通常被稱(chēng)為批處理作業(yè)。批處理作業(yè)使各種應(yīng)用程序能夠從原始數(shù)據(jù)中獲得價(jià)值，這對(duì)于擁有龐大用戶(hù)數(shù)據(jù)的企業(yè)的成長(zhǎng)起到了重要的作用。

對(duì)于大型數(shù)據(jù)集的批處理作業(yè)通常具有幾分鐘到幾小時(shí)的完成時(shí)間，如此長(zhǎng)的延遲對(duì)于許多應(yīng)用程序來(lái)說(shuō)并不理想，例如推薦系統(tǒng)，使用最新數(shù)據(jù)至關(guān)重要，但與此同時(shí)，處理的精準(zhǔn)性也需要保證，即使最小程度的推薦失敗也可能最終導(dǎo)致用戶(hù)離開(kāi)。加之硬件水平的提升，很快我們開(kāi)始有了更高的要求。我們希望能夠跟上數(shù)據(jù)產(chǎn)生的步伐得到數(shù)據(jù)處理的結(jié)果，而不是等待數(shù)據(jù)積累然后才處理。低延遲流處理因此慢慢興起。我們將其稱(chēng)為流處理，因?yàn)閭魅氲臄?shù)據(jù)基本上是事件、消息或樣本的連續(xù)流。

許多對(duì)實(shí)時(shí)分析感興趣的公司并不愿意放棄 MapReduce 模型。為了解決延遲限制，一些應(yīng)用程序開(kāi)始使用微批 (micro-batch) 處理方法：在較短時(shí)間內(nèi)累積的較小塊上運(yùn)行作業(yè)。以 Apache Spark Streaming 為代表的微批處理會(huì)以秒級(jí)增量對(duì)流進(jìn)行緩沖，然后在內(nèi)存中進(jìn)行計(jì)算。這種方式的實(shí)際效果非常好，它確實(shí)使應(yīng)用程序能夠在更短的時(shí)間內(nèi)獲得更高價(jià)值。

但由于緩沖機(jī)制的存在，微批處理仍然有著較高的延遲，為了滿(mǎn)足應(yīng)用的低延遲需求，原生的流處理平臺(tái)的研發(fā)在近五年中不斷涌現(xiàn)，百花齊放。早期的系統(tǒng)包括 S4 和 Apache Storm。Storm 使用成熟，有社區(qū)基礎(chǔ)，至今仍然被許多企業(yè)廣泛使用。Heron 是由 Twitter 研發(fā)的新一代流處理引擎，與 Storm 兼容的同時(shí)性能更優(yōu)。Apache Samza 和 Kafka Stream 則基于 Apache Kafka 消息系統(tǒng)來(lái)實(shí)現(xiàn)高效的流處理。

由于批處理和流處理系統(tǒng)使用著不同的框架，企業(yè)為同時(shí)滿(mǎn)足實(shí)時(shí)和批處理的應(yīng)用程序，不得不使用兩套獨(dú)立的計(jì)算基礎(chǔ)架構(gòu)，計(jì)算的結(jié)果也同樣進(jìn)入不同的框架以進(jìn)行查詢(xún)。Storm 的創(chuàng)始人 Nathan Marz 由此提出了 Lambda 的大數(shù)據(jù)處理架構(gòu)(如圖 1)，將大數(shù)據(jù)平臺(tái)分割成了批處理層、流處理層和應(yīng)用服務(wù)層。Lambda 架構(gòu)遵循讀寫(xiě)分離，復(fù)雜性隔離的原則，整合了離線(xiàn)計(jì)算和實(shí)時(shí)計(jì)算，集成 Hadoop，Kafka，Storm，Spark，Hbase 等各類(lèi)大數(shù)據(jù)組件，使得兩種處理能夠在高容錯(cuò)、低延時(shí)和可擴(kuò)展的條件下平穩(wěn)運(yùn)行。

 

 

圖 1: Lambda 架構(gòu)

隨著技術(shù)和架構(gòu)的演進(jìn)，近年來(lái)，工程師們開(kāi)始意識(shí)到用流和批兩個(gè)詞來(lái)區(qū)分應(yīng)用場(chǎng)景，進(jìn)而給計(jì)算框架分類(lèi)并不合適，兩種處理實(shí)質(zhì)上有著許多共同點(diǎn)。在很多場(chǎng)景下，流和批處理應(yīng)用同一套處理邏輯，卻不得不因?yàn)榭蚣懿煌�進(jìn)行重復(fù)開(kāi)發(fā)。數(shù)據(jù)在產(chǎn)生之時(shí)就沒(méi)有所謂批和流的概念，只是我們的處理方式不同才導(dǎo)致了數(shù)據(jù)屬性的不同，進(jìn)而導(dǎo)致了框架的不同。

流和批本來(lái)就應(yīng)該沒(méi)有界限!

LinkedIn(Apache Kafka 作者，現(xiàn) Confluent CEO)的 Jay Kreps 提出了 Kappa 架構(gòu)，將批處理層、流處理層簡(jiǎn)化為一致性的流處理。谷歌工程師(Apache Beam 核心人物)Tyler Akidau 提出了 Dataflow 模型則致力于取代谷歌上一代的 MapReduce，將批處理(有限的數(shù)據(jù)流)視為流處理(無(wú)限的數(shù)據(jù)流)的特例，重新定義大數(shù)據(jù)處理的原語(yǔ)。Apache Flink 作為新一代流處理框架的翹楚，其設(shè)計(jì)遵循 Dataflow 模型，從根本上統(tǒng)一了批處理和流處理。而 Apache Spark 也推翻了之前微批處理的設(shè)計(jì)，推出了 Structured Streaming，使用表和 SQL 的概念進(jìn)行處理的統(tǒng)一。

有效地提取和提供數(shù)據(jù)對(duì)于流處理應(yīng)用程序的成功至關(guān)重要。由于處理速度和頻率的不同，數(shù)據(jù)的攝取需要通過(guò)兩種策略進(jìn)行。在典型的 Lambda 架構(gòu)中，分布式文件系統(tǒng)(例如 HDFS)負(fù)責(zé)為批處理應(yīng)用提供高并發(fā)、高吞吐量的數(shù)據(jù)，而消息隊(duì)列系統(tǒng)(例如 RocketMQ)負(fù)責(zé)為流處理應(yīng)用提供數(shù)據(jù)臨時(shí)緩沖，發(fā)布 / 訂閱功能，數(shù)據(jù)不進(jìn)行長(zhǎng)時(shí)間的持久化保留。兩者無(wú)法整合也是目前 Kappa 架構(gòu)對(duì)歷史數(shù)據(jù)處理能力有限的原因。

Pravega 設(shè)計(jì)宗旨是成為流的實(shí)時(shí)存儲(chǔ)解決方案。應(yīng)用程序?qū)��?shù)據(jù)持久化存儲(chǔ)到 Pravega 中，Pravega 的 Stream 可以有無(wú)限制的數(shù)量并且持久化存儲(chǔ)任意長(zhǎng)時(shí)間，使用同樣的 Reader API 提供尾讀 (tail read) 和追趕讀 (catch-up read) 功能，能夠有效滿(mǎn)足兩種處理方式的統(tǒng)一。

Pravega 支持僅一次處理 (exactly-once)，可在 Kappa 架構(gòu)上實(shí)現(xiàn)鏈接應(yīng)用需求，以便將計(jì)算拆分為多個(gè)獨(dú)立的應(yīng)用程序，這就是流式系統(tǒng)的微服務(wù)架構(gòu)。我們所設(shè)想的架構(gòu)是由事件驅(qū)動(dòng)、連續(xù)和有狀態(tài)的數(shù)據(jù)處理的流式存儲(chǔ) - 計(jì)算的模式(如圖 2)。

 

 

圖 2: 流處理的簡(jiǎn)單生命周期

通過(guò)將 Pravega 流存儲(chǔ)與 Apache Flink 有狀態(tài)流處理器相結(jié)合，圖 2 中的所有寫(xiě)、處理、讀和存儲(chǔ)都是獨(dú)立的、彈性的，并可以根據(jù)到達(dá)數(shù)據(jù)量進(jìn)行實(shí)時(shí)動(dòng)態(tài)擴(kuò)展。這使我們所有人都能構(gòu)建以前無(wú)法構(gòu)建的流式應(yīng)用，并將其從測(cè)試原型無(wú)縫擴(kuò)展到生產(chǎn)環(huán)境。擁有了 Pravega，Kappa 架構(gòu)得以湊齊了最后的拼圖，形成了統(tǒng)一存儲(chǔ)、統(tǒng)一計(jì)算的閉環(huán)。

流式存儲(chǔ)的要求

我們使用的組件需要為它而設(shè)計(jì)，以滿(mǎn)足我們想實(shí)現(xiàn)的需求，不然就會(huì)像現(xiàn)今的大數(shù)據(jù)架構(gòu)那樣，形成復(fù)雜性的堆砌。上述內(nèi)容已經(jīng)提到，現(xiàn)有的存儲(chǔ)引擎同時(shí)無(wú)法滿(mǎn)足兩種數(shù)據(jù)讀取的需求。結(jié)合實(shí)際的應(yīng)用場(chǎng)景，總結(jié)所需要的特性，企業(yè)級(jí)流存儲(chǔ)引擎的實(shí)現(xiàn)相當(dāng)有難度，因?yàn)樗�需要三種看似矛盾的系統(tǒng)功能：

♦ 能夠?qū)��?shù)據(jù)視為連續(xù)和無(wú)限的，而不是有限和靜態(tài)的

♦ 能夠通過(guò)自動(dòng)彈性伸縮數(shù)據(jù)采集、存儲(chǔ)和處理能力，與負(fù)載保持協(xié)調(diào)一致，持續(xù)快速地交付結(jié)果

♦ 即使在延遲到達(dá)或出現(xiàn)亂序數(shù)據(jù)的情況下，也能連續(xù)交付準(zhǔn)確的處理結(jié)果

讓我們具體深入上述特征，以當(dāng)今業(yè)界應(yīng)用最廣的分布式消息系統(tǒng) Apache Kafka 作為對(duì)比，看看 Pravega 如何以今天存儲(chǔ)無(wú)法實(shí)現(xiàn)的方式實(shí)現(xiàn)它們。

將數(shù)據(jù)視為連續(xù)和無(wú)限的

Kafka 源于 LinkedIn 的日志采集系統(tǒng)，采用分布式事務(wù)日志架構(gòu)進(jìn)行持久化層的管理。因此，Kafka 采用添加到文件的末尾并跟蹤其內(nèi)容的方式模擬連續(xù)和無(wú)限的數(shù)據(jù)流。然而文件既沒(méi)有針對(duì)此模式進(jìn)行優(yōu)化，也受限于本地文件系統(tǒng)的文件描述符以及磁盤(pán)容量，因此并非是無(wú)限的。對(duì)于數(shù)據(jù)的可靠性，Kafka 使用同步副本(in-sync replica)方式進(jìn)行，占用了更多的存儲(chǔ)的同時(shí)也意味著對(duì)吞吐率性能的受損。并且它們利用消息頭部的 header 記錄元數(shù)據(jù)以構(gòu)造數(shù)據(jù)結(jié)構(gòu)，使得它們不像字節(jié)序列那樣通用。

將這些想法拼接在一起, 我們提出了 Pravega 將從數(shù)據(jù)的角度支持的連續(xù)和無(wú)限的特點(diǎn)：

♦ Pravega 的 Stream 是一個(gè)命名的、持久的、僅追加的、無(wú)限的字節(jié)序列

♦ 使用低延遲追加尾寫(xiě)并從序列的尾讀 (tail read/write)

♦ 具有來(lái)自序列較舊部分的高吞吐追趕讀 (catch-up read)

基于負(fù)載的自動(dòng) (zero-touch) 彈性伸縮特性 (scale up/scale down)

Kafka 通過(guò)將數(shù)據(jù)拆分為分區(qū)，并獨(dú)立處理來(lái)獲得并行性。這種做法由來(lái)已久，Hadoop 就使用了分區(qū)在 HDFS 和 MapReduce 實(shí)現(xiàn)了并行化的批處理。對(duì)于流式工作負(fù)載，傳統(tǒng)的分區(qū)有著很大的問(wèn)題：分區(qū)會(huì)同時(shí)影響讀客戶(hù)端和寫(xiě)客戶(hù)端。連續(xù)處理的讀寫(xiě)操作所要求的并行程度通常各不相同，使其鏈接固定數(shù)量的分區(qū)就會(huì)增加實(shí)現(xiàn)復(fù)雜性。雖然可以添加分區(qū)以進(jìn)行擴(kuò)展，但這需要手動(dòng)更新寫(xiě)客戶(hù)端、讀客戶(hù)端和存儲(chǔ)。代價(jià)高昂，也并非動(dòng)態(tài)縮放。

Pravega，專(zhuān)為動(dòng)態(tài)和獨(dú)立擴(kuò)展而設(shè)計(jì)，支持：

♦ 許多寫(xiě)客戶(hù)端同時(shí)追加寫(xiě)不相交的數(shù)據(jù)子集

♦ 寫(xiě)入數(shù)據(jù)依靠路由鍵 (routing key) 寫(xiě)入不同的 segment 以保證隔離性

♦ 讓?xiě)?yīng)用程序?yàn)閷?xiě)客戶(hù)端分配鍵

♦ 當(dāng)鍵空間或?qū)懣蛻?hù)端發(fā)生改變時(shí)，對(duì)應(yīng)的存儲(chǔ)不能有約束和改變

♦ 許多讀客戶(hù)端同時(shí)處理不相交的數(shù)據(jù)子集

♦ 讀取的數(shù)據(jù)分區(qū)不依賴(lài)于寫(xiě)入分區(qū)

♦ 讀取的分區(qū)由存儲(chǔ)策略控制

♦ 使用 segment 概念代替物理的分區(qū)，且數(shù)量根據(jù)攝取流量進(jìn)行自動(dòng)連續(xù)的更新

連續(xù)處理數(shù)據(jù)生成準(zhǔn)確的結(jié)果

連續(xù)計(jì)算要得到準(zhǔn)確的結(jié)果需要僅一次處理 (exactly-once)。而僅一次處理語(yǔ)義對(duì)數(shù)據(jù)存儲(chǔ)有著明確的要求，數(shù)據(jù)寫(xiě)入必須是：

♦ 持久化的
♦ 有序的
♦ 一致的
♦ 事務(wù)性的

這些關(guān)鍵屬性也是存儲(chǔ)系統(tǒng)設(shè)計(jì)中最困難的部分。如果沒(méi)有事先的設(shè)計(jì)考慮，后期就只能通過(guò)系統(tǒng)重構(gòu)來(lái)完成這些特性。

持久性意味著一旦寫(xiě)入得到確認(rèn)，即使遇到組件故障數(shù)據(jù)也不會(huì)丟失。持久性由于與失敗后數(shù)據(jù)重放相關(guān)因而至關(guān)重要。沒(méi)有持久化的系統(tǒng)意味著數(shù)據(jù)需要開(kāi)發(fā)人員進(jìn)行手動(dòng)歸檔，將永久副本存儲(chǔ)在歸檔系統(tǒng)(通常是 HDFS)中。Pravega 流式存儲(chǔ)通過(guò)數(shù)據(jù)寫(xiě)入可持久化的分層存儲(chǔ)保證持久性，用戶(hù)能夠永久可靠地保存流數(shù)據(jù)。

有序性意味著讀客戶(hù)端將按照寫(xiě)入的順序處理數(shù)據(jù)，Kafka 保證了消費(fèi)者組內(nèi)部是有序的。對(duì)于 Pravega 這樣的通過(guò)路由鍵 (routing key) 來(lái)實(shí)現(xiàn)分區(qū)的系統(tǒng)而言，有序僅對(duì)具有相同鍵的數(shù)據(jù)有意義。例如擁有數(shù)百萬(wàn)傳感器的物聯(lián)網(wǎng)系統(tǒng)中，sensor-ID.metric 可能作為鍵，Pravega 的 Stream 能夠保證讀取該傳感器的數(shù)據(jù)將按其寫(xiě)入的順序進(jìn)行。對(duì)于使用增量更新計(jì)算的聚合函數(shù)之類(lèi)的應(yīng)用，有序性是必不可少的。

一致性意味著即使面對(duì)組件故障，而且無(wú)論是從流的尾讀還是追趕讀，所有讀客戶(hù)端都會(huì)看到給定鍵的相同的有序數(shù)據(jù)視圖。與持久性一樣，Pravega 的一致性?xún)H依靠存儲(chǔ)系統(tǒng)的一致性是不夠的。對(duì) Pravega 而言，寫(xiě)客戶(hù)端的寫(xiě)入操作是冪等的，而寫(xiě)入的數(shù)據(jù)對(duì)于 Pravega 而言也是不透明的(無(wú)法再次進(jìn)行修改)，我們以此實(shí)現(xiàn)了強(qiáng)一致性。我們基于 Pravega 的強(qiáng)一致性還抽象出了狀態(tài)同步器的 API，用戶(hù)可以在此之上構(gòu)建輕量級(jí)的其它分布式系統(tǒng)的狀態(tài)同步。

事務(wù)性寫(xiě)入對(duì)于跨鏈接的應(yīng)用程序一次完全正確是必要的。不僅 Pravega 本身支持事務(wù)性的寫(xiě)入，更和 Apache Flink 的 Sink 集成，在 Flink 檢查點(diǎn)之間建立事務(wù)，通過(guò)分布式兩階段提交協(xié)議支持端到端的事務(wù)和僅一次處理。

Pravega 系列文章計(jì)劃

Pravega根據(jù) Apache 2.0 許可證開(kāi)源，我們歡迎對(duì)流式存儲(chǔ)感興趣的大家加入社區(qū)，與 Pravega 共同成長(zhǎng)。下一篇系列文章將會(huì)從 Pravega 本身的架構(gòu)出發(fā)，進(jìn)一步介紹 Pravega 的特性細(xì)節(jié)。之后的文章會(huì)逐一介紹 Pravega 的各大特性、具體實(shí)現(xiàn)細(xì)節(jié)以及使用方法等，敬請(qǐng)大家期待。

本篇文章為系列文章第一篇，后面系列文章標(biāo)題如下：

♦ Pravega 架構(gòu)和細(xì)節(jié)
♦ Pravega 應(yīng)用實(shí)例
♦ Pravega 的動(dòng)態(tài)伸縮特性
♦ Pravega 的僅一次語(yǔ)義及事務(wù)支持
♦ 分布式一致性解決方案：狀態(tài)同步器 (StateSynchronizer)
♦ 與 Apache Flink 集成使用

參考：

http://pravega.io

http://blog.pravega.io/2017/04/09/storage-reimagined-for-a-streaming-world/

http://blog.pravega.io/2017/12/14/i-have-a-stream/

作者介紹

滕昱: 就職于 DellEMC 非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)部門(mén) (Unstructured Data Storage) 團(tuán)隊(duì)并擔(dān)任軟件開(kāi)發(fā)總監(jiān)。2007 年加入 DellEMC 以后一直專(zhuān)注于分布式存儲(chǔ)領(lǐng)域。參加并領(lǐng)導(dǎo)了中國(guó)研發(fā)團(tuán)隊(duì)參與兩代 DellEMC 對(duì)象存儲(chǔ)產(chǎn)品的研發(fā)工作并取得商業(yè)上成功。從 2017 年開(kāi)始，兼任 Streaming 存儲(chǔ)和實(shí)時(shí)計(jì)算系統(tǒng)的設(shè)計(jì)開(kāi)發(fā)工作。

周煜敏：復(fù)旦大學(xué)計(jì)算機(jī)專(zhuān)業(yè)研究生，從本科起就參與 DellEMC 分布式對(duì)象存儲(chǔ)的實(shí)習(xí)工作�，F(xiàn)參與 Flink 相關(guān)領(lǐng)域研發(fā)工作。

標(biāo)簽： 大數(shù)據(jù) 大數(shù)據(jù)處理 大數(shù)據(jù)架構(gòu) 大數(shù)據(jù)平臺(tái) 大數(shù)據(jù)系統(tǒng) 服務(wù)器 谷歌 金融 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀(guān)點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。