Samza与Strom

最新推荐文章于 2020-05-27 01:43:03 发布

zs808

最新推荐文章于 2020-05-27 01:43:03 发布

阅读量5.3k

点赞数

分类专栏： Samza Storm 文章标签： Samza Strom

Samza 同时被 2 个专栏收录

1 篇文章 0 订阅

订阅专栏

Storm

1 篇文章 0 订阅

订阅专栏

原文地址：http://samza.apache.org/learn/documentation/latest/comparisons/storm.html

Storm

人们通常希望知道类似的系统之间的比较。我们已经尽我们最大的努力去公平的比较Samza与其它系统之间的特性。但是我们并不是这些框架的专家，而且我们的这些比较，毫无疑问，完全是有偏见的。如果我们哪儿出了差错，请告知我们，然后我们会纠正它。
Storm与Samza真的很相似。两个系统都提供了一些高级的特性：一个分区流模型，一个分布式的执行环境，一个流处理API，集群容错，Kafka支持，等等。
Strom与Samza使用不同的术语来描述相似的概念：Stream的spouts与Samza中的stream consumers相似，bolt与tasks相似，以及tuples与messages相似。Storm还有一些其它的Samza所不支持组件。

顺序（Ordering）与保障（Guarantees）

Storm允许你按照你的期望选择消息处理的保障级别：

最基础的模式是 at-most-once delivery，在这种模式下，将会丢弃没有正确的处理或者机器执行流程失败的消息。这种模式不需要特殊的逻辑，并且按照spout产生消息的顺序来处理消息。
另一种模式为 at-least-once delivery，在这种模式下会通过在内存中维护一个包含所有已发出（Emit）元组（Tuple）的记录来追踪每一个输入的元组（还有所有它产生的下游元组）是否成功在一个已配置的超时时间内成功处理。任何没有在超时时间内成功处理的元组将会重新被Spout 发出。这意味着Bolt有可能会重复的接收到相同的元组，并且这些重复元组的处理时机是无法预测的。为了正确的对记录进行确认，这个机制同时需要用户代码执行一些协作处理，这些处理必须能够保持对记录祖先的记录。这在Storm’s wiki有详细解释。
最后，Storm通过Trident提供一种 exactly-once semantics模式，这个模式使用与at-least-once模式相同的错误检测机制。元组实际上被处理至少一次，但是Storm的状态（State）实现允许忽略检测到的重复项。（这个重复项监测机制仅仅适用于被Storm管理的状态。如果你的代码对这种模式有其它的副作用（例如向Topology外部的服务发送消息），它将不适用exactly-once semantics模式）。在这种模式下，Spouts将输入流划分为多个批处理，并且以严格的顺序执行这些批处理。

Samza也提供了交付（delivery）保证——目前只支持 at-least-once delivery，但是支持 exactly-once semantics已经在计划之中。在每一个流分区之中，Samza总是以消息在分区中的顺序来处理消息，但是不保证不同的输入流或分区中的消息的处理顺序。这个模型允许Samza提供 at-least-once delivery 而没有追踪祖先消息的开销。在Samza中，使用 at-most-once delivery（意味着在失败时丢弃消息）没有性能优势，这也就是为什么我们不提供这种模式的原因——因为消息交付始终是被保障的。
另外，因为Samza从不会随机处理在一个分区中的消息，它更适合用于处理具有键的数据。举个例子，如果已有一个数据更新流——在这个流中靠后的数据将会替换前面的数据——在这种情况下重新排序消息将会改变最终的结果。但是如果同一个键的所有更新都在同一个流分区中，Samza就能够保证一致状态。

状态管理

Storｍ　Bolts中的低级别的API对于流处理过程中的状态管理不提供任何帮助。一个Bolt可以保持内存中的状态（该状态将会在Bolt消亡时丢失），或者它可以通过调用远程的数据库来读写状态。但是，一个Topology对于消息的处理频率通常远远高于调用一个远程数据库可以实现的最大频率，因此快速对每条消息进行远程调用将会成为一个瓶颈。
作为它的高级别Trident API，Storm提供自动状态管理。它将状态保持在内存中，并且定期将它与远程的持久化数据库做对比（如 Cassandra），因此对于远程数据库调用的花费会被若干个已经处理的元组摊销（原句：so the cost of the remote database call is amortized over several processed tuples）。通过维护状态的元数据，Trident可以达成 exactlu-once-processing semantics——举个例子，如果你对事件计数，这个机制允许计数器被及时更新，甚至当机器执行失败元组被重发时仍然可以保证数值的正确。
Storm的缓存方法与批处理状态变化在每个Bolt非常小的情况下工作的非常好——也许小于100kB。这使得它适用于跟踪counters，minimum，maximun与average的度量结果，等等。然而，如果你需要保持大量的状态，这个方法每处理完一个Tuple都会发起一个数据库调用，并且导致相关的性能损失。
Samza带来了一个完全不同的状态管理方法。不同于使用一个远程数据库来持久化，每个Samza任务都包含一个嵌入的键值对仓库，保存在同一台机器上。对这个仓库的读写操作非常快速，甚至当仓库内容的大小多余可用内存。对这个键值对仓库的更改将会复制到集群中的其它机器上，因此如果一台机器宕机，在它上面运行的任务的状态可以从其它的机器上还原。
通过在同一台机器上储存于处理，Samza能够达到非常高的吞吐量，甚至当状态数量非常多的时候。如果以希望执行一个多状态的操作而不仅仅是计数（counters）的时候这么做是非常有必要的。举个例子，如果你希望对多个流进行窗口连接，或加入一个带有数据库表的流（通过Changelog复制到Samza），或者将若干个相关的消息分组成为一个更大的消息，你需要保持如此多的状态所以将状态保持在任务所在的机器是非常有效的。
对Samza状态处理的一个限制是它目前不支持exactly-once semantics——目前只支持 at-least-once。但是我们正在努力解决这个问题，敬请关注最新消息。

分区（Partitioning）和并行处理（Parallelism）

Storm的并行处理模型与Samza非常相似。两个框架都将操作划分为多个独立的任务来实现并行执行。资源分配独立于任务的数量：一个小作业可以分配所有的任务在一台机器的一个进程中，一个大作业可以传递任务到若干个机器中的若干个进程中。
最大的不同点在于Storm默认每一个任务使用单独的线程，而Samza使用单个线程处理容器（Containers）。一个Samza容器可能包含多个任务，但是仅仅一个线程轮流的调用每一个任务。这意味着每一个容器被映射到一个确切的CPU核心中，这使得资源模型更加简单并且减少运行在同一台机器上的其它任务的影响。Storm的多线程模型有在同一台机器上更好的利用过剩产能的优势，以一个不可预知的资源模型为代价。
Storm支持动态平衡（dynamic rebalancing），这意味着可以在不重启Topology或集群的情况下添加更多的线程或者进程到一个Topology中。这是一个非常方便的特性，尤其在开发过程中。我们并没有将这个特性加入到Samza中：从哲学的角度我们觉得这种改变应该通过正常的配置管理过程来实现（例如版本管理，通知，等等）因为它影响生产性能。换句话说，作业的代码与配置应当完全重新创建集群的状态。
当使用一个Trident事务Spout的时候（这个是实现exactly-once semantics的需求之一），并行化可能胡降低。Trident依赖于它的输入流中的一个全局的顺序——也就是说，通过一个流中的所有分区进行排序，而不仅仅实在一个分区中。这意味着Topology的输入流必须通过一个单一的Spout实例，有效地忽略输入流的分区。在大容量的流中，这个Spout可能成为一个瓶颈。在Samza中，所有的流并行处理——没有这样的阻塞点。

部署（Deployment）与执行（Execution）

一个Strom集群由一个节点集合组成并且运行一个Supervisor守护进程。Supervisor与一个名叫Nimbus的守护进程运行的单独的主节点做通讯。Nimbus守护进程的职责为分配作业并且管理集群的资源。详细信息请浏览Storm的教程。这与YARN非常相似；尽管YARN功能齐全并且有望成为多框架（原句 intended to be multi-framework），但Numbus可以更好的整合Storm。
Yahoo!也发布了Storm-YARN。像这篇Yahoo!博文发布的一样，Storm_YARN是一个包装，以使得可以在一个YRAN网格（grid）之中运行单个Storm集群（完整的Nimbus与Supervisors）。
Storm的Nimbus与YARN的ResourceManager有非常多的相似点，Storm的Supervisor与YARN的Node Manager也是如此。与其编写我们自己的资源管理框架，或者在YARN中运行第二个框架，我们认为Samza应该直接使用YARN，在YARN的生态圈中成为一流的成员。YARN是稳定的，被广泛使用的，功能完备的并且可以与Hadoop互相操作。它也提供了一系列优秀的特性如security（用户验证），cgroup进程隔离，等等。
Samza的YARN支持是可插拔的，因此你可以将它换成你希望的不同的执行框架。

语言支持

Storm由Java与Clojure编写，但是对于non-JVM语言有很好的支持。它遵循一个类似于MapReduce的模式：non-JVM任务运行在一个单独的进程中，数据发送到它的基本输入流中，并且从它的基本输出流中读取数据。
Samza由Java与Scala编写。它的多语言支持已经在考虑，但是目前只支持JVM语言。

工作流

Storm在代码中提供一个Topologies模型（一个多阶段的处理图）。Trident在这基础上提供了一个更高层次的API，包括常见的关系运算符如filters，grouping，aggregation与joins。这意味着整个Topology在一个地方定义，它的优点是它在代码中构建，但是整个Topology需要被开发并且整体被发布。
在Samza中，每个作业是一个独立的实体。你可以定义多个作业在一个代码页中，或者你可以有单独的团队使用不同的代码页，从事不同的作业。每一个作业都被独立的发布，开始或者停止。作业之间仅仅通过命名流通讯，并且你可以在不影响其它任何作业的前提下添加作业到系统中。这使得Samza非常适用于处理大企业的数据流。
Samza的方法可以被Storm通过一个代理连接两个独立的Topologies结构来效仿，比如Kafka。然而，Storm的exactly-once semantics实现仅仅可以在一个Topology中工作。

成熟度

我们对Storm的成熟度作评价，但是他有一个令人印象深刻的使用者，一个强大的特性集，似乎在积极发展。它同许多公用消息系统很好的集成（RabbitMQ，Kestrel，Kafka，等等）。
Samza很不成熟，尽管它建立在坚实的组件之上。YARN是相当新的，但是已经在雅虎中运行了3000多个节点的集群，并且这个产品正在Hortonworks 与 Cloudera的开发下积极的发展。Kafka有一个强大的技术支持页面，并且最近已经被越来越多的采用。它也被Storm频繁的使用。Samza是一个被LinkedIn使用的全新的项目。我们希望其它人可以感受到它的实用之处，并且很好的接受它。

缓冲与延迟时间

Storm使用ZeroMQ用于Bolt之间的非持久化通讯，这使得Tuple之间的转换传递延迟变得非常低。Samza没有类似的机制，并且总是将任务输出写到一个流中。
在另一方面，当一个Bolt尝试用ZeroMQ发送消息，但是Consumer并没有及时的读取它，那么发送端的ZeroMQ缓冲区将会填满消息。如果缓冲区增长太多，Topology就会触发操作超时，这会导致消息被Spout重新Emit并且添加更多的消息到缓冲区中，这导致这个问题更加糟糕。为了避免这样的溢出，你可以配置一个单个Topology正在发送的最大消息数量；当这个阈值达到时，Soput会被阻塞，直到一些正在发送消息被完全的处理。这个机制允许反压力（back pressure），但是需要topology.max.spout.pending被认真的配置。如果一个Topology中的单个Bolt开始运行缓慢，整个Topology的处理就会停顿。
当尝试解决容错性与消息语义时Bolts之间缺乏Broker也会添加复杂度。Storm探测处理失败的元组是一个聪明的机制，但是Samza并不需要这样的机制因为每一个输入输出流是容错并且被复制的。（原文fault-tolerant and replicated）
Samza带来了一个不用的缓存方法。我们在StreamTask每次跳跃的时候缓存到磁盘。这个决定，以及它的权衡取舍，在比较介绍界面中有详细的描述。这个设计使得耐久性保证很容易，并且有允许缓冲区在一个任务处理速度落后时吸收大量积压的消息的优点。然而，它的代价是较的延迟。
向之前WorkFlow部分说明的一样，Samza的方法可以被Storm模拟，但是会有功能上的损失。

功能

Storm提供了基本的UNIX进程级别功能。你的Topology在有过多的CPU，硬盘，网络或者内存被使用时可以影响其它Topology的表现（反之亦然）。
Samza基于YARN来提供一个资源级别的功能。当前，YARN对于内存与CPU限制提供显式控制通过（通过cgroups），并且都已经成功的被Samza所使用。YARN目前没有提供磁盘或网络功能。

可分发RPC

在Storm中，你可以编写Topologies，它不仅支持一个固定数量事件的流，同时也允许客户端运行可分发的计算需求。请求会被以元组的形式发送到Topology上的一个特殊的Spout，当Topology一家计算出结果的时候，它将结果返回到客户端（该客户端之前处于异步等待结果状态）。这个设施被叫做可分发RPC（DRPC）
Samza目前对于DRPC没有一个等效的API，但是你可以使用Samza的流处理单元自己构建。