Samza 與 Spark Streaming

Spark Streaming

人們通常想知道類似的系統(tǒng)如何比較。我們已盡全力將Samza的功能集與其他系統(tǒng)進(jìn)行對(duì)比。但是我們不是這些框架的專家，當(dāng)然我們也是完全有偏見(jiàn)的。如果我們有任何東西，請(qǐng)讓我們知道，我們會(huì)糾正。

本概述正在比較 Spark Streaming 1.3.1 和 Samza 0.9.0。未來(lái)的版本可能會(huì)有變化。

Spark Streaming 是使用核心 Apache Spark API 的流處理系統(tǒng)。Samza 和 Spark Streaming 都提供數(shù)據(jù)一致性，容錯(cuò)性，編程 API 等。Spark 的流媒體方式與 Samza 不同。Samza處理收到的消息，而 Spark Streaming 將流視為一系列確定性批處理操作。Spark Streaming 將流分組為固定持續(xù)時(shí)間（如1秒）的批次。每個(gè)批處理都表示為彈性分布式數(shù)據(jù)集（RDD）。這些 RDD 的漸進(jìn)序列稱為離散化流（DStream）。

Spark Streaming 概述

在進(jìn)行比較之前，以下是 Spark Streaming 應(yīng)用程序的簡(jiǎn)要概述。如果您已經(jīng)熟悉 Spark Streaming，您可以跳過(guò)此部分。Spark Streaming 應(yīng)用程序有兩個(gè)主要部分：數(shù)據(jù)接收和數(shù)據(jù)處理。

• 數(shù)據(jù)接收由接收器接收數(shù)據(jù)，并在 Spark 中存儲(chǔ)數(shù)據(jù)（此時(shí)不在 RDD 中）。他們?cè)?.3版本中對(duì) Kafka 進(jìn)行了非接收方式的實(shí)驗(yàn)。
• 數(shù)據(jù)處理將存儲(chǔ)在 Spark 中的數(shù)據(jù)傳輸?shù)?DStream 中。然后，您可以在 DStream 上應(yīng)用兩個(gè)操作 - 轉(zhuǎn)換和輸出操作。由于流式傳輸環(huán)境，DStream 的操作與一般 Spark RDD 有所不同。

以下是 Spark Streaming 部署的概述。Spark 有一個(gè) SparkContext（在 SparkStreaming 中，它在驅(qū)動(dòng)程序中被稱為StreamingContext對(duì)象，SparkContext 與集群管理器（例如YARN，Mesos）交談，然后為 Spark 應(yīng)用程序分配資源（即執(zhí)行程序），執(zhí)行程序?qū)⑦\(yùn)行任務(wù)通過(guò) SparkContext，在 YARN 的上下文中，一個(gè)執(zhí)行器相當(dāng)于一個(gè)容器，任務(wù)是容器中運(yùn)行的，驅(qū)動(dòng)程序在提交作業(yè)（客戶端模式）或應(yīng)用程序管理器（客戶端模式）的客戶機(jī)中運(yùn)行，集群模式），數(shù)據(jù)接收和數(shù)據(jù)處理都是執(zhí)行器的任務(wù)，一個(gè)接收器（接收一個(gè)輸入流）是一個(gè)長(zhǎng)期運(yùn)行的任務(wù)。處理有一堆任務(wù)。所有的任務(wù)都將發(fā)送給可用的執(zhí)行者。

消息的排序

Spark Streaming 保證在一個(gè) DStream 中對(duì) RDD 的有序處理。由于每個(gè) RDD 并行處理，所以在 RDD 內(nèi)沒(méi)有保證的順序。這是 Spark 做的一個(gè)權(quán)衡設(shè)計(jì)。如果要在 RDD 中按順序處理消息，則必須在一個(gè)線程中處理它們，這不具有并行性的好處。

Samza 保證按照它們?cè)诹鞯姆謪^(qū)中顯示的順序來(lái)處理消息。Samza 還允許您使用 MessageChooser 定義分區(qū)之間的消息的確定性排序。

容錯(cuò)語(yǔ)義

Spark Streaming 對(duì)于不同的數(shù)據(jù)源具有不同的容錯(cuò)語(yǔ)義。在這里，為了更好的比較，只討論使用 Spark Streaming 與 Kafka 時(shí)的語(yǔ)義。在 Spark 1.2中，Spark Streaming 在接收端提供了至少一次語(yǔ)義。在 Spark 1.3中，它采用無(wú)接收方式，這提供了一些好處。但是，它仍然不能保證輸出動(dòng)作的一次性語(yǔ)義。因?yàn)楦弊饔玫妮敵霾僮骺赡茉谧鳂I(yè)失敗時(shí)重復(fù)，并從檢查點(diǎn)恢復(fù)。如果您的輸出操作中的更新不是冪等或事務(wù)性的（例如發(fā)送到 Kafka 主題的消息），您將獲得重復(fù)的消息。不要被 Spark Streaming 指南中的“一次性語(yǔ)義”所困惑。

Samza 提供了至少一次的郵件傳遞保證。當(dāng)作業(yè)發(fā)生故障時(shí)，它重新啟動(dòng)容器并從檢查點(diǎn)讀取最新的偏移。當(dāng) Samza 的工作從故障中恢復(fù)時(shí)，它可能會(huì)多次處理一些數(shù)據(jù)。這是因?yàn)樽鳂I(yè)在最后一個(gè)檢查點(diǎn)重新啟動(dòng)，并且在該檢查點(diǎn)和故障之間已處理的任何消息將再次被處理?？梢酝ㄟ^(guò)設(shè)置小的檢查點(diǎn)間隔周期來(lái)最小化再處理數(shù)據(jù)的數(shù)量。

如果您可以確保冪等更新或事務(wù)更新， Spark Streaming 和 Samza 都可以實(shí)現(xiàn)端到端的一次性語(yǔ)義。該鏈接指向 Spark Streaming 頁(yè)面，同樣的想法也適用于 Samza。

狀態(tài)管理

Spark Streaming 提供一個(gè)狀態(tài) DStream，它保持每個(gè)鍵的狀態(tài)和一個(gè)稱為 updateStateByKey 的轉(zhuǎn)換操作來(lái)突變狀態(tài)。每當(dāng)應(yīng)用 updateStateByKey 時(shí)，您將獲得一個(gè)新?tīng)顟B(tài)DStream，其中所有狀態(tài)都通過(guò)應(yīng)用傳遞給 updateStateByKey 的函數(shù)進(jìn)行更新。這種轉(zhuǎn)換可以作為基本的鍵值存儲(chǔ)，盡管它有一些缺點(diǎn)：

• 您只能將 DStream 操作應(yīng)用到您的狀態(tài)，因?yàn)樗旧鲜且粋€(gè) DStream。
• 不提供對(duì)數(shù)據(jù)的任何鍵值訪問(wèn)。如果要訪問(wèn)某個(gè)鍵值，則需要遍歷整個(gè) DStream。
• 當(dāng)狀態(tài)較大時(shí)，由于每次處理新批次時(shí)，Spark Streaming 會(huì)消耗整個(gè)狀態(tài) DStream 來(lái)更新相關(guān)的鍵和值，因此效率低下。

Spark Streaming 定期將狀態(tài)操作（updateStateByKey 和基于窗口的操作）的媒體數(shù)據(jù)寫入 HDFS。在 updateStateByKey 的情況下，在每個(gè)檢查點(diǎn)間隔之后，將整個(gè)狀態(tài) RDD 寫入HDFS。正如我們?cè)?a rel="external nofollow" target="_blank" target="_blank">帶有檢查點(diǎn)的內(nèi)存狀態(tài)中提到的，當(dāng)狀態(tài)變大時(shí)，將整個(gè)狀態(tài)寫入持久存儲(chǔ)是非常昂貴的。

Samza 使用嵌入式鍵值存儲(chǔ)進(jìn)行狀態(tài)管理。這個(gè)商店被復(fù)制，因?yàn)樗峭蛔兊?，并支持非常高的吞吐量寫入和閱讀。并且它給你很大的靈活性來(lái)決定你想要保持什么樣的狀態(tài)。更重要的是，您還可以插入其他存儲(chǔ)引擎，從而在您可以使用的流處理算法中實(shí)現(xiàn)極大的靈活性。在這里可以找到不同類型的國(guó)家經(jīng)理方法的良好比較。

狀態(tài)管理的常見(jiàn)用例之一是流式流連接。雖然星火流有加入操作，該操作僅將兩個(gè)批次是在相同的時(shí)間間隔。它不處理兩個(gè)流中的事件不匹配的情況。Spark Streaming 的updateStateByKey 存儲(chǔ)不匹配事件的方法也有一個(gè)限制，因?yàn)槿绻黄ヅ涫录臄?shù)量很大，會(huì)有一個(gè)很大的狀態(tài)，這會(huì)導(dǎo)致 Spark Streaming 中的無(wú)效。雖然 Samza 沒(méi)有這個(gè)限制。

分區(qū)和并行性

Spark Streaming的并行性是通過(guò)將工作分解成小任務(wù)并將其發(fā)送給執(zhí)行者而實(shí)現(xiàn)的。在Spark Streaming中有兩種并行性：在并行處理流中并行化并行處理流：*在接收端，一個(gè)輸入DStream 創(chuàng)建一個(gè)接收器，一個(gè)接收器接收一個(gè)輸入數(shù)據(jù)流并作為長(zhǎng)時(shí)間運(yùn)行，運(yùn)行任務(wù) 因此，為了并行化接收過(guò)程，您可以根據(jù)某些條件將一個(gè)輸入流分解成多個(gè)輸入流（例如，如果您正在接收一些分區(qū)的 Kafka 流，則可以根據(jù)分區(qū)拆分此流）。然后，您可以為這些流創(chuàng)建多個(gè)輸入 DStream（因此多個(gè)接收器），并且接收器將作為多個(gè)任務(wù)運(yùn)行。因此，您應(yīng)該通過(guò)增加執(zhí)行人員的核心數(shù)量或增加更多的執(zhí)行人員來(lái)提供足夠的資源。然后，如果需要，您可以在處理過(guò)程中將所有輸入的 Dstream 組合成一個(gè) DStream。在 Spark 1.3 中，Spark Streaming + Kafka Integration 正在使用無(wú)接收方式（directsream）。Spark Streaming 創(chuàng)建一個(gè) RDD，其分區(qū)映射到 Kafka 分區(qū)是一對(duì)一的。這簡(jiǎn)化了接收機(jī)側(cè)的并行性。*在處理方面，由于DStream是RDD的連續(xù)序列，所以通過(guò)正常的RDD操作（如map，reduceByKey，reduceByWindow）可以簡(jiǎn)單地實(shí)現(xiàn)并行。Spark Streaming + Kafka Integration 正在使用無(wú)接收器方法（稱為directSream）。Spark Streaming 創(chuàng)建一個(gè)RDD，其分區(qū)映射到Kafka分區(qū)是一對(duì)一的。這簡(jiǎn)化了接收機(jī)側(cè)的并行性。*在處理方面，由于DStream是RDD的連續(xù)序列，所以通過(guò)正常的RDD操作（如map，reduceByKey，reduceByWindow）可以簡(jiǎn)單地實(shí)現(xiàn)并行。Spark Streaming + Kafka Integration 正在使用無(wú)接收器方法（稱為 directSream）。Spark Streaming 創(chuàng)建一個(gè) RDD，其分區(qū)映射到 Kafka 分區(qū)是一對(duì)一的。這簡(jiǎn)化了接收機(jī)側(cè)的并行性。*在處理方面，由于DStream是RDD的連續(xù)序列，所以通過(guò)正常的RDD操作（如map，reduceByKey，reduceByWindow）可以簡(jiǎn)單地實(shí)現(xiàn)并行。

Samza 的并行性是通過(guò)將處理分解成可并行化的獨(dú)立任務(wù)來(lái)實(shí)現(xiàn)的。您可以在一個(gè)容器中運(yùn)行多個(gè)任務(wù)，或者每個(gè)容器只運(yùn)行一個(gè)任務(wù)。這取決于您的工作負(fù)載和延遲要求。例如，如果要快速重新處理流，則可以將容器的數(shù)量增加到每個(gè)容器一個(gè)任務(wù)。重要的是注意到一個(gè)容器只使用一個(gè)線程，它映射到一個(gè) CPU。該    設(shè)計(jì)嘗試簡(jiǎn)化資源管理和作業(yè)之間的隔離。

在 Samza 中，您可以靈活地定義一個(gè)任務(wù)所包含的內(nèi)容。例如，在 Kafka 用例中，默認(rèn)情況下，Samza 將具有相同分區(qū) ID 的分區(qū)分組到一個(gè)任務(wù)中。這允許不同流之間的容易連接。開(kāi)箱即用，Samza 還提供了將一個(gè)分區(qū)分配給一個(gè)任務(wù)的分組策略。這提供了可以使用多少個(gè)容器來(lái)處理這些輸入流的最大可擴(kuò)展性，并且適用于不需要輸入流分組的非常高容量的作業(yè)。

緩沖和延遲

Spark 流主要是一系列小批處理。使用快速執(zhí)行引擎，它可以達(dá)到低至1秒的延遲（從他們的論文）。從他們的頁(yè)面，“塊間隔的推薦最小值約為50 ms，低于此值的任務(wù)啟動(dòng)開(kāi)銷可能是一個(gè)問(wèn)題。

如果處理速度比接收速度慢，則數(shù)據(jù)將作為內(nèi)存中的 DStream 排隊(duì)，隊(duì)列將不斷增加。為了運(yùn)行健康的 Spark 流應(yīng)用程序，系統(tǒng)應(yīng)該被調(diào)整，直到處理速度與接收速度一樣快。

使用 Apache Kafka 運(yùn)行時(shí)，Samza作業(yè)可能會(huì)在低毫秒內(nèi)延遲。它具有不同的緩沖方法。緩沖機(jī)制取決于輸入和輸出系統(tǒng)。例如，當(dāng)使用 Kafka 作為輸入和輸出系統(tǒng)時(shí)，數(shù)據(jù)實(shí)際上被緩沖到磁盤。這種設(shè)計(jì)決定，通過(guò)犧牲一點(diǎn)延遲，允許緩沖區(qū)在工作落后于其處理時(shí)吸收大量積壓的消息。

容錯(cuò)

Spark Streaming 和 Samza 中有兩種故障：Spark Streaming 中的工作節(jié)點(diǎn)（運(yùn)行執(zhí)行程序）故障（相當(dāng)于 Samza 中的容器故障）和驅(qū)動(dòng)程序節(jié)點(diǎn)（運(yùn)行驅(qū)動(dòng)程序）故障（相當(dāng)于應(yīng)用程序管理器（AM））失敗 Samza）。

當(dāng) Spark Streaming 中的工作節(jié)點(diǎn)出現(xiàn)故障時(shí)，集群管理器將重新啟動(dòng)它。當(dāng) Samza 中的容器發(fā)生故障時(shí)，應(yīng)用程序管理器將與 YARN 一起啟動(dòng)新的容器。當(dāng) Spark Streaming 中的驅(qū)動(dòng)程序節(jié)點(diǎn)出現(xiàn)故障時(shí)，YARN / Mesos / Spark Standalone 將自動(dòng)重新啟動(dòng)驅(qū)動(dòng)程序節(jié)點(diǎn)。Spark Streaming 可以使用 HDFS 中的檢查點(diǎn)重新創(chuàng)建 StreamingContext。

在薩姆薩，YARN 負(fù)責(zé)處理容錯(cuò)。當(dāng) Samza 的 AM 失敗時(shí)，YARN 將處理重新啟動(dòng) AM。如果 AM 重新啟動(dòng)，Samza 將重新啟動(dòng)所有的容器。當(dāng)集裝箱發(fā)生故障時(shí)，AM 將打開(kāi)一個(gè)新的集裝箱。

部署和執(zhí)行

Spark 有一個(gè) SparkContext 對(duì)象與群集管理器通信，然后為應(yīng)用程序分配資源。目前，Spark 支持三種類型的集群管理器：Spark獨(dú)立，Apache Mesos和Hadoop YARN。除此之外，Spark 還有一個(gè)用于在 Amazon EC2 中啟動(dòng)的腳本。

Samza 目前支持 YARN 和本地執(zhí)行。還有 Mesos 支持正在整合。

隔離

Spark Streaming 和 Samza 有相同的隔離。Spark Streaming 取決于集群管理器（例如 Mesos 或 YARN），Samza 依靠 YARN / Mesos 來(lái)提供處理器隔離。不同的應(yīng)用程序在不同的JVM 中運(yùn)行。除非寫入外部存儲(chǔ)器，否則數(shù)據(jù)不能在不同應(yīng)用程序之間共享。由于 Samza 提供開(kāi)箱即用的 Kafka 集成，因此很容易重用其他 Samza 作業(yè)的輸出（見(jiàn)這里）。

語(yǔ)言支持

Spark Streaming 是用 Java 和 Scala 編寫的，它提供 Scala，Java 和 Python API。

Samza 是用 Java 和 Scala 編寫的，并且有一個(gè) Java API。

工作流程

在 Spark Streaming 中，您將使用 DSL API 構(gòu)建整個(gè)處理圖，并將整個(gè)圖形部署為一個(gè)單元。該圖中的節(jié)點(diǎn)之間的通信（以 DStreams 的形式）由框架提供。那就像風(fēng)暴一樣。Samza 是完全不同的 - 每個(gè)工作只是一個(gè)消息處理器，并且沒(méi)有框架支持拓?fù)?。處理任?wù)的輸出總是需要返回到消息代理（例如 Kafka）。

Samza 設(shè)計(jì)的一個(gè)積極的后果是，工作的產(chǎn)出可以被多個(gè)不相關(guān)的工作所消耗，這些工作可能由不同的團(tuán)隊(duì)運(yùn)行，而這些工作通過(guò) Kafka 的緩沖來(lái)相互隔離。Storm 和 Spark Streaming 的框架內(nèi)部流并不是這樣。

雖然 Storm / Spark Streaming 工作原則上可以將其輸出寫入消息代理，但框架并沒(méi)有真正使這個(gè)簡(jiǎn)單。似乎 Storm / Spark 不是以一種拓?fù)漭敵鰹榱硪煌負(fù)漭斎氲姆绞绞褂玫?。相比之下，在薩薩，這種使用模式是標(biāo)準(zhǔn)的。

到期

Spark 有一個(gè)活躍的用戶和開(kāi)發(fā)人員社區(qū)，最近發(fā)布了1.3.1版本。它有一個(gè)列表的公司，在其 Powered by 頁(yè)面使用它。由于 Spark 包含 Spark Streaming，Spark SQL，MLlib，GraphX 和 Bagel，因此很難告訴列表中的哪些公司實(shí)際上是使用 Spark Streaming，而不僅僅是 Spark。

Samza 還很年輕，但剛剛發(fā)布了0.9.0版本。它有一個(gè)敏感的社區(qū)，正在積極發(fā)展。也就是說(shuō)，它是建立在像 YARN 和 Kafka 這樣的固體系統(tǒng)上。Samza 在 LinkedIn 和其他公司被大量使用。我們希望別人也會(huì)覺(jué)得有用。

API概述  ?