Samza 與 Storm

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

Storm 和 Samza 是相當相似的。兩個系統(tǒng)提供了許多相同的高級功能：分區(qū)流模型，分布式執(zhí)行環(huán)境，流處理 API，容錯，卡夫卡集成等。

Storm 和 Samza 對于類似的概念使用不同的單詞：Storm 中的噴口類似于 Samza 中的流消費者，螺栓類似于任務，元組類似于 Samza 中的消息。一些額外的構(gòu)建塊，如三叉戟，拓撲等，在 Samza 中沒有直接的等價物。

分類和保證

Storm允許您選擇要處理郵件的保證級別：

• 最簡單的模式是一次性傳遞，如果處理不正確，或者執(zhí)行處理的機器失敗，則會丟棄消息。此模式不需要特殊邏輯，并按照它們由噴口生成的順序處理消息。
• 還有至少一次傳遞，它跟蹤每個輸入元組（以及其生成的任何下游元組）是否在配置的超時內(nèi)成功處理，通過保留所有發(fā)出的元組的內(nèi)存中記錄。在超時期間未完全處理的任何元組都將由噴口重新發(fā)出。這意味著螺栓可能會多次看到相同的元組，并且該消息可以被無序處理。該機制還需要用戶代碼的一些合作，用戶代碼必須維護記錄的祖先，以便適當?shù)卮_認其輸入。這在Storm 的維基上有深入的解釋。
• 最后，Storm 使用其 Trident 抽象提供了一次性的語義。該模式使用與至少一次模式相同的故障檢測機制。元組實際上至少處理了一次，但是 Storm 的狀態(tài)實現(xiàn)允許檢測和忽略重復數(shù)據(jù)。（重復檢測僅適用于由 Storm 管理的狀態(tài)，如果您的代碼具有其他副作用，例如向拓撲之外的服務發(fā)送消息，則不會具有完全一次的語義。）在此模式下，輸入流批量，并按嚴格順序處理批次。

Samza 還提供保證交貨 - 目前僅交貨至少一次，但計劃支持一次性語義。在每個流分區(qū)中，Samza 總是按照它們在分區(qū)中顯示的順序來處理消息，但不能保證在不同的輸入流或分區(qū)之間進行排序。該模型允許 Samza 至少提供一次，而不需要祖先跟蹤的開銷。在 Samza，使用最多的一次交付（即丟棄消息失敗）將不會有性能優(yōu)勢，這就是為什么我們不提供這種模式 - 消息傳遞總是得到保證。

此外，由于 Samza 從未在分區(qū)無序處理消息，所以更適合處理密鑰數(shù)據(jù)。例如，如果您有一個數(shù)據(jù)庫更新流 - 以后的更新可能會替代以前的更新，那么重新排序消息可能會改變最終結(jié)果。如果同一個密鑰的所有更新顯示在同一流分區(qū)中，則 Samza 能夠保證一致的狀態(tài)。

狀態(tài)管理

Storm 的較低級別的 API 不支持在流過程中管理狀態(tài)。螺栓可以保持內(nèi)存狀態(tài)（如果螺栓死了，則會丟失），或者可以調(diào)用遠程數(shù)據(jù)庫來讀取和寫入狀態(tài)。然而，拓撲通?？梢砸员瓤梢赃M行遠程數(shù)據(jù)庫的調(diào)用更高的速率來處理消息，因此對每個消息的遠程調(diào)用迅速成為瓶頸。

作為其更高級別 Trident API 的一部分，Storm 提供自動狀態(tài)管理。它將狀態(tài)保存在內(nèi)存中，并定期檢查它到遠程數(shù)據(jù)庫（例如 Cassandra）以獲得持久性，因此遠程數(shù)據(jù)庫調(diào)用的成本在多個處理的元組中進行分攤。通過在狀態(tài)旁邊維護元數(shù)據(jù)，Trident 能夠?qū)崿F(xiàn)一次處理語義 - 例如，如果您計算事件，該機制允許計數(shù)器正確，即使機器故障并且元組被重播。

如果每個螺栓的狀態(tài)數(shù)量相當小 - 也許小于100kB，Storm 的緩存和批處理狀態(tài)變化的方法效果很好。這使得它適合于跟蹤計數(shù)器，度量的最小值，最大值和平均值等。但是，如果您需要維護大量的狀態(tài)，則這種方法本質(zhì)上會降低到每個處理的元組進行數(shù)據(jù)庫調(diào)用，以及相關的性能成本。

薩馬對國家管理采取了完全不同的做法。每個 Samza 任務都不包括使用遠程數(shù)據(jù)庫進行持久存儲，而是包含位于同一機器上的嵌入式鍵值存儲。即使當商店的內(nèi)容大于可用內(nèi)存時，對此商店的讀寫也非常快。對此鍵值存儲的更改將復制到集群中的其他計算機，以便如果一臺計算機已停止，則其運行的任務的狀態(tài)可以在另一臺計算機上恢復。

通過在同一臺機器上共存存儲和處理，即使有大量的狀態(tài)，Samza 也能夠?qū)崿F(xiàn)非常高的吞吐量。如果要執(zhí)行不僅僅是計數(shù)器的有狀態(tài)操作，這是必要的。例如，如果要執(zhí)行多個流的窗口連接，或者使用數(shù)據(jù)庫表（通過更改日志復制到Samza）加入流，或?qū)⒍鄠€相關消息分組到更大的消息中，則需要保持這么多狀態(tài)將狀態(tài)保持在本地的任務更為有效。

Samza 的狀態(tài)處理的局限性在于它目前不支持一次性語義 - 現(xiàn)在至少支持一次。但是我們正在努力修復這個問題，請隨時關注更新。

分區(qū)和并行性

風暴的并行模式與 Samza 相似。兩種框架將處理分解成可以并行運行的獨立任務。資源分配獨立于任務數(shù)量：一個小工作可以將單個進程中的所有任務保存在單個計算機上; 大量工作可以在許多機器上將任務分散在許多過程中。

最大的區(qū)別是 Storm 在默認情況下每個任務使用一個線程，而 Samza 使用單線程進程（容器）。Samza 容器可能包含多個任務，但只有一個線程依次調(diào)用每個任務。這意味著每個容器映射到一個 CPU 核心，這使得資源模型更簡單，并減少了在同一臺機器上運行的其他任務的干擾。Storm 的多線程模型的優(yōu)點是可以以較不可預測的資源模型為代價，更好地利用空閑機器上的多余容量。

Storm 支持動態(tài)重新平衡，這意味著向拓撲添加更多的線程或進程，而無需重新啟動拓撲或集群。這是一個方便的功能，特別是在開發(fā)過程中。我們沒有把它添加到 Samza：在哲學上，我們認為這種變化應該經(jīng)歷一個正常的配置管理過程（即版本控制，通知等），因為它會影響生產(chǎn)性能。換句話說，作業(yè)的代碼和配置應該完全重新創(chuàng)建集群的狀態(tài)。

當使用具有 Trident 的事務性噴嘴（實現(xiàn)一次語義的要求）時，并行性可能會降低。Trident 依賴于其輸入流中的全局排序，即排序流的所有分區(qū)，而不僅僅是在一個分區(qū)內(nèi)。這意味著拓撲的輸入流必須經(jīng)過單個噴口實例，有效地忽略了輸入流的劃分。這個噴口可能成為大容量流的瓶頸。在 Samza，所有的流處理是平行的 - 沒有這樣的阻塞點。

部署和執(zhí)行

Storm 集群由運行 Supervisor 守護程序的一組節(jié)點組成。主管守護進程與運行名為 Nimbus 守護進程的單個主節(jié)點進行通信。Nimbus 守護進程負責在集群中分配工作和管理資源。有關詳細信息，請參閱 Storm's Tutorial 頁面。這與 YARN 非常相似；盡管 YARN 有一些更加全面的特征，旨在成為多框架，Nimbus 更好地與 Storm 集成。

雅虎 還發(fā)布了Storm-YARN。如這個雅虎 博客文章 所述，Storm-YARN 是一個封裝，在 YARN 網(wǎng)格內(nèi)啟動了一個單一的 Storm 集群（與 Nimbus 和 Supervisors 完成）。

Storm 的 Nimbus 和 YARN 的 ResourceManager 之間以及 Storm 的主管和 YARN 的節(jié)點管理器之間有很多相似之處。作為 YARN 生態(tài)系統(tǒng)中一流的公民，Samza 應該直接使用YARN，而不是編寫自己的資源管理框架，或在 YARN 內(nèi)部運行第二個資源管理框架。YARN 穩(wěn)定，采用，功能齊全，可與 Hadoop 進行互操作。它還提供了一些很好的功能，如安全性（用戶驗證），cgroup 進程隔離等。

Samza 的 YARN 支持是可插拔的，因此如果愿意，您可以將其交換為不同的執(zhí)行框架。

語言支持

Storm 是用 Java 和 Clojure 編寫的，但對非 JVM 語言有很好的支持。它遵循類似于 MapReduce Streaming 的模型：非 JVM 任務在單獨的進程中啟動，數(shù)據(jù)被發(fā)送到其 stdin，并且從其 stdout 讀取輸出。

Samza 是用 Java 和 Scala 編寫的。它是以多語言支持構(gòu)建的，但目前只支持 JVM 語言。

工作流程

Storm 提供了代碼中拓撲的建模（多個階段的處理圖）。Trident 還提供了一個更高級別的API，包括熟悉的關系類運算符，如過濾器，分組，聚合和連接。這意味著整個拓撲結(jié)構(gòu)在一個地方被連線，這具有代碼中記錄的優(yōu)點，但是缺點是整個拓撲需要作為一個整體來開發(fā)和部署。

在薩姆薩，每個工作都是一個獨立的實體。您可以在單個代碼庫中定義多個作業(yè)，也可以使用不同的代碼庫，使用不同的工作組來處理不同的作業(yè)。每個作業(yè)都被單獨部署，啟動和停止。作業(yè)僅通過命名流進行通信，您可以將作業(yè)添加到系統(tǒng)中，而不會影響任何其他作業(yè)。這使得 Samza 非常適合處理大型公司的數(shù)據(jù)流。

Samza 的方法可以在 Storm 中通過代理（如 Kafka ）連接兩個獨立的拓撲來模擬。然而，Storm 的完全一次語義的實現(xiàn)只能在單個拓撲中起作用。

成熟度

我們不能說 Storm 的成熟度，但是它擁有令人印象深刻的采納者，強大的功能，似乎正在積極發(fā)展。它與許多常見的消息系統(tǒng)（RabbitMQ，Kestrel，Kafka等）很好地集成。

雖然 Samza 建立在固體組件上，但是相當不成熟。YARN 是相當新的，但已經(jīng)在雅虎的3000多個節(jié)點集群上運行，該項目正在由 Hortonworks 和 Cloudera 積極開發(fā)。Kafka 擁有強大的頁面，近期日益普及。它也經(jīng)常用于 Storm。Samza 是在 LinkedIn 中使用的全新項目。我們的希望是別人會覺得有用，也可以采納。

緩沖和延遲

Storm 使用 ZeroMQ 進行螺栓之間的非持久通信，從而實現(xiàn)了極少延遲的元組傳輸。Samza 沒有等效的機制，并且總是將任務輸出寫入流。

另一方面，當一個螺栓嘗試使用 ZeroMQ 發(fā)送消息，并且消費者不能足夠快地讀取消息時，生產(chǎn)者流程中的 ZeroMQ 緩沖區(qū)開始填滿消息。如果此緩沖區(qū)增長太多，則可能會達到拓撲的處理超時，從而導致消息在噴口處重新發(fā)出，并通過向緩沖區(qū)添加更多消息使問題更糟。為了防止這種溢出，您可以隨時在拓撲中配置最多可能在飛行中的消息; 當達到該閾值時，噴口阻塞，直到飛行中的某些消息被完全處理。這種機制允許背壓，但需要仔細配置拓撲。如果拓撲中的單個螺栓開始運行緩慢，

在嘗試處理容錯和消息傳遞語義時，螺栓之間缺乏經(jīng)紀人也增加了復雜性。Storm 具有檢測未被處理的元組的聰明機制，但 Samza 不需要這樣的機制，因為每個輸入和輸出流都是容錯和復制的。

Samza 采取不同的緩沖方法。我們在 StreamTask 之間的每一跳緩沖到磁盤。比較介紹頁面詳細描述了這一決定及其權(quán)衡。這種設計決策使得耐久性保證容易，并且具有允許緩沖器在其處理中已經(jīng)落后的情況下吸收大量積壓的消息的優(yōu)點。然而，它的延遲稍微更高的代價。

如上面的工作流程部分所述，Samza 的方法可以在 Storm 中模擬，但功能上會丟失。

隔離

Storm 提供標準的 UNIX 進程級隔離。如果使用太多的 CPU，磁盤，網(wǎng)絡或內(nèi)存，您的拓撲可能會影響另一個拓撲的性能（反之亦然）。

Samza 依靠 YARN 提供資源級隔離。目前，YARN 為內(nèi)存和 CPU 限制（通過cgroups）提供了明確的控制，并且都已經(jīng)成功地與 Samza 一起使用。目前，YARN 不提供磁盤或網(wǎng)絡的隔離。

分布式RPC

在風暴中，您可以編寫不僅接受固定事件流的拓撲，還可以讓客戶端按需運行分布式計算。該查詢作為特殊口上的元組發(fā)送到拓撲中，當拓撲計算出答案時，它將返回給客戶端（誰同步等待答案）。該工具稱為分布式RPC（DRPC）。

Samza 目前沒有與 DRPC 相同的 API，但您可以使用 Samza 的流處理原語自行構(gòu)建它。

數(shù)據(jù)模型

Storm 將所有消息作為具有定義的數(shù)據(jù)模型的元組，但是可插入序列化。

Samza 的序列化和數(shù)據(jù)模型都是可插拔的。我們對于哪種方法是最好的并不是非常愚蠢的。

Spark Streaming ?