Samza 與 Storm

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

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

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

分類和保證

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

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

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

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

狀態(tài)管理

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

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

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

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

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

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

分區(qū)和并行性

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

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

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

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

部署和執(zhí)行

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

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

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

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

語言支持

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

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

工作流程

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

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

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

成熟度

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

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

緩沖和延遲

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

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

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

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

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

隔離

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

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

分布式RPC

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

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

數據模型

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

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

Spark Streaming ?