流数据的处理存在很多技术：
1、简单的事件处理器
2、复杂的事件处理器
3、流处理器

分布式流处理需求日益增加，包括支付交易、社交网络、物联网（IOT）、系统监控等。业界对流处理已经有几种适用的框架来解决，下面我们来比较各流处理框架的相同点以及区别。
分布式流处理是对无边界数据集进行连续不断的处理、聚合和分析。它跟MapReduce一样是一种通用计算，但我们期望延迟在毫秒或者秒级别。这类系统一般采用有向无环图（DAG）。

当选择不同的流处理系统时，有以下几点需要注意的：
运行时和编程模型：平台框架提供的编程模型决定了许多特色功能，编程模型要足够处理各种应用场景。这是一个相当重要的点，后续会继续。

函数式原语：流处理平台应该能提供丰富的功能函数，比如，map或者filter这类易扩展、处理单条信息的函数；处理多条信息的函数aggregation；跨数据流、不易扩展的操作join。

状态管理：大部分应用都需要保持状态处理的逻辑。流处理平台应该提供存储、访问和更新状态信息。

消息传输保障：消息传输保障一般有三种：at most once，at least once和exactly once。At most once的消息传输机制是每条消息传输零次或者一次，即消息可能会丢失；A t least once意味着每条消息会进行多次传输尝试，至少一次成功，即消息传输可能重复但不会丢失；Exactly once的消息传输机制是每条消息有且只有一次，即消息传输既不会丢失也不会重复。

容错：流处理框架中的失败会发生在各个层次，比如，网络部分，磁盘崩溃或者节点宕机等。流处理框架应该具备从所有这种失败中恢复，并从上一个成功的状态（无脏数据）重新消费。

性能：延迟时间（Latency），吞吐量（Throughput）和扩展性（Scalability）是流处理应用中极其重要的指标。

平台的成熟度和接受度：成熟的流处理框架可以提供潜在的支持，可用的库，甚至开发问答帮助。选择正确的平台会在这方面提供很大的帮助。

对海量事件的收集和处理要满足：低开销、低延迟。流处理器对此提供了比较好的支持。考虑每秒数据量的大小，再确定如何选用何种技术。（例如流量每秒几百条消息，每秒数十万条消息，处理的技术可以完全不同）

Flume 和 NiFi 确切地属于数据收集（DC）和单事件处理器（SEP），而其它的是多事件流处理器（ESP）引擎或复杂的事件处理器（CEP）。

Spark 本身和 Ignite 确切来说不仅仅是流处理器，他们还提供流媒体功能。Apex 也是同样的情况，这是一个统一批次和流数据的平台，它应该是介于一个数据收集引擎、一个基本 ETL 工具与一个事件流处理器之间。

Kafka 流是一个 Kafka 的 Java 库，主要用于消息的处理。Kafka流是最初由 LinkedIn 开发的消息传递系统。Kafka 目前在 LinkedIn、Netflix 和 Spotify 中被广泛应用。Kafka流的特点是低延迟、高容量、分布式的队列系统。

在 CEP 市场上当然还有许多其他选择，例如：Software AG 的 Apama，微软的 StreamInsight，Oracle 事件处理，SAP ESP，Tibco 的 BusinessEvents＆Streambase。它们列出时并没有按具体的顺序！另外还有Esper，其中有一个可获取的开源版本，是 GNU GPL 许可的。

In-flight 修改表示没有任何停机或应用程序重新提交的情况。有时也被称为零停机扩容，和即席或动态应用程序修改。对于 in-flight 修改，Spooker是一个值得多看一眼的项目。