开发者通常想看到是否有其他类似的系统可以做一个对比。我们会竭尽所能，拿其他系统的特征与samza的相关特性做一个对比。但我们不是这些系统的专家。我们的理解有可能完全失之偏颇。如果的确有的话，请让我们知道，我们会改正的。
storm与samza非常相似。这两种系统提供许多相同的高级特性：分区流模型，分布式执行环境，为流处理的API，容错，与kafka的集成等。
Storm 和 Samza 用了不同的名称来描述类似的功能: 在storm中的spouts 与samza的stream consumers是相同的概念, bolts(storm) 与 tasks(samza)是相同的概念, tuples(storm) 与 messages(samza) 是相同的概念. Storm 还增加了 building blocks ,这项功能在samza是没有的。
Storm 允许你选择不同级别的保障数据完整性的处理方案：
最简单的模式是最多只投递一次，如果进程没有处理成功或者处理进程异常，那么消息就丢掉。这种模式不需要特殊的逻辑，能够按照消息的顺序逐步处理。
另外，还有at-least-once的模式，在没有超时的情况下，将会在内存中跟踪记录每个input tuple的处理状态，如果已经超过处理时限，将会重新发送tuple进行重新处理。
最后，Storm 通过利用 Trident 抽象来支持“exactly-once”模式。底层是要通过 at-least-once的模式 来支持，在内存储中进行状态维护，从而在上层保证成功状态的数据不被重新再次处理。
Samza 现在在的模式是at-least-once模式 ，后续将计划支持“exactly-once”模式。
Storm的blots的低级API lower-level API 可以在本地内存或者远程数据库保存流程处理的状态，但是高级API只能通过远程数据库来保存流程处理的状态，这样，当数据流比较大的时候，这将会成为系统处理的瓶颈。
Samza采用了一种完全不同的方式来进行状态管理。并不是使用一个远程数据库进行持久化，每个Samza任务通过在本地进行键值存储。读取和写入到本地的缓存的速度非常快，即使在存储的内容比可用内存更大的时候。同时，更改的数据将会同步到其他机器。因此，如果一台机器死了，它正在运行的任务的状态将可以在另一台机器上面恢复。
Storm的并行模式非常类似Samza。两个框架都可以分割任务以加工成可以并行运行独立的任务。一个小的作业可以将所有的任务在一台机器上的单个进程中执行;大量的工作可以分散在多台机器在许多进程中执行。
最大的区别在于，storm在默认情况下使用每个任务一个线程，而Samza采用一个单线程来对应一个容器。Samza容器可以包含多个任务，但也有是调用每个依次执行的任务却只有一个线程。这意味着每个容器被映射到一个单独的CPU核心，这使得资源模型更简单，并减少来自同一机器上运行的其他任务的干扰。 [译者：samza基于单线程的事件驱动，storm是基于多线程模型]
Storm的资源管理是基于Nimbus，Nimbus的管理机制与yarn的管理机制有些类似。yarn是一个可以支持多类型应用的集群资源管理框架，Nimbus更适合Storm。Yahoo在yarn的框架的基础上开发了支持storm的功能，来替代Nimbus。
samza通过plugin的方式集集群资源管理的组件，开始的时候就是基于yarn的集群资源管理，后续，开发人员也可以通过plugin的方式集成其他类型的组件。
storm是基于java和Clojure开发的。
samza是基于java和scala语言开发的[译者：比较看重这一点，毕竟大数据很多系统都是基于scala语言开发，例如：kafka，spark等]
storm使用ZeroMQ在blot之间进行非持久消息传输，这使得元组间能够以极低的延迟进行消息传输。 Samza不具有等效的机制，始终将任务输出写入到消息流里面。
在另一面，当blot试图发送使用ZeroMQ的消息，而消费者处理的速度不够快，同时，在ZeroMQ的缓冲区生产者有发送了新的消息消息。如果该缓冲增长太多，那么消息的处理就要超时，将导致要重新提交发送消息，这将使消息到ZeroMQ缓冲器的问题处理变得更加糟糕。为了防止这种消息溢出，可以在MQ进行配置，当消息达到最大数量;新消息将会被阻塞，直到一些消息被完全处理。但需要必须仔细配置topology.max.spout.pending。如果在整个拓扑环境中一个blot开始运行缓慢，在整个拓扑的处理会越来越慢直到停止。
Samza采用不同的方法来缓冲。在StreamTask之间，我们决定将buffer 写到磁盘。这种设计决策使得持久化的保证比较容易，且具有允许的缓冲器以吸收大量积压的消息。但是，会使实时数据流的处理产生延时。
storm提供了标准的UNIX进程级隔离。您的拓扑结构可以影响另一种拓扑结构的表现（反之亦然），如过多的CPU，磁盘，网络或内存的使用。
Samza依靠YARN提供资源级隔离。目前，yarn提供存储器和CPU限制（通过cgroup中）显式的控制，并且已经被成功地用于Samza。yarn暂时没有提供磁盘或网络的资源隔离。
In Storm, you can write topologies which not only accept a stream of fixed events, but also allow clients to run distributed computations on demand. The query is sent into the topology as a tuple on a special spout, and when the topology has computed the answer, it is returned to the client (who was synchronously waiting for the answer). This facility is called Distributed RPC (DRPC).
Samza does not currently have an equivalent API to DRPC, but you can build it yourself using Samza’s stream processing primitives.
storm模型的所有消息作为元组定义的数据模型，但序列化发面可以实现plugin方式（自己实现）。
Samza的序列化和数据模型都是实现plugin方式。我们并不固执认为那种方式一定是最好的，将选择留给开发人员。