流数据的迅速崛起带来了一类全新的应用开发技术。为了应对不断增长的数据（如物联网和机器通信产生的大量数据），同时，利用实时个性化技术改进在线 用户体验，越来越多的应用开发引入了流数据技术。对于流数据应用的定义多种多样，但都包含三个基本功能：实时数据采集，实时分析和自动化决策。
流处理的解决方案也可以采取多种形式。通常其体系结构包含：tuple-at-a-time流处理工具（又名复杂事件处理工具）；面向批处理的流处 理技术，是对灵活性和健壮性的折中方案；内存数据库，强调业务的实时性。虽然这些方法可以解决许多问题，但是就开发量、维护开销、存储容量、性能而言，这 些方法存在很大差异。需要注意的是，了解需要用多少组件来实现你需要的功能是十分重要的。开发、测试、运营一个系统的工作量取决于需要整合在一起的组件的 数量。
举个例子：Apache Storm 是最流行的为开发者用于流式应用的工具之一，但是一个使用storm的流式处理方案通常不仅仅需要storm。正如我在上一篇文章中 讨论到的，Storm通常使用Kafka用于数据采集，而Storm和Kafka都需要Zookeeper用于管理状态。最后，如我下面讨论到的，还需要 第四个系统用于管理状态。最终，当所有工作完成后，一个3结点（指计算节点）的Storm集群会很轻易地掉消耗12个结点！
Apache Storm和快速数据应用
Apache Storm 是一个能近实时地在数据之上运行用户代码片段的流式数据处理框架。它实际上是一系列连在一起的管道。本质上开发者在运行中间部分（指Storm的管道）的代码时，他们将输入数据源和后端数据存储连接起来。Storm的延时比基于Hadoop的系统更接近CEP（复杂事件处理）。它提供的通过书写简单代码处理事件，将更多背景交给框架处理的特性，对于有时间修修补补的开发者来说很有吸引力。
Storm 通常用于简单的分析任务， 诸如计算，以及清洗，使其常规化，并且准备摄入用于长期存储的数据。然而，Storm 不能够有状态操作，这对于进行实时决策非常重要。状态数据的分析正处于快速数据应用程序的中心，诸如：个性化，客户参与，推荐引擎，报警，授权与政策执 行。无需诸如 Zookeeper与 Cassandra 之类的额外组件，Storm 不能查找维度数据，更新汇总，或者直接作用于一个事件（那就是，对实时进行决策）。
这些实例就是一个更广泛有关“快”的数据应用程序的类的一部分。开发人员意识到认识的价值和作用于实时数据，并且快速的数据工具正充实着简单的流媒体方式和传统的分析卖场实现价值。考虑问题并且不涉及技术，什么是一个快速应用程序共同的主题呢？
首先，它们都要读入数据，比如日志记录，传感器记录，财务票据，点击流，在线行为触发等等。这些数据来得比消防龙头喷的水还快，快速数据处理系统必须要能流畅读入这些数据。
然后就是实时解析读入进来的数据。在这之前，某些系统可以读入一个流然后提交给 OLAP 系统处理，这样的处理有可能耗时过长，起不到实时的作用。而快速数据处理系统则通过事件模型来处理读入数据，同时拉取已有数据（比方维度表或历史表）来进 行处理。系统可以将信息展示出来或发送一个提醒，让相关的人员来做决定；但更合适的做法是让系统自动来处理——比如“当X类型的用户满足Y条件时，执行策略Z”。
最后，快速数据处理要和大数据相集成。我们有一个基础假设，就是数据都是有生命周期的。实时数据交给快速数据处理系统来处理，而像机器学习、回归测试和历 史查询这样的深度分析，则交给 OLAP 或基于 Hadoop/HDFS 的系统去做。这种情况下，快速数据处理系统不但将扩充后的数据提交给深度分析系统，同时也接收深度分析系统的处理结果，比如规则学习引擎生成的一条规则。
要想理解 Storm 在整个快速数据处理系统中的角色，最简单的就是看它自身能处理哪些问题，以及它把哪些问题丢给开发者解决。Storm 框架的设计目标是以一种可以自由水平扩展并具有一定容错性的方式，将数据从数据源提交给用户处理。它对于输入数据可以是“最多一次”或“最少一次”的处理 方式，如果处理失败，它也可以再度重试。
对持久化状态的认识明显是不足的。由于各种各样的原因，高速数据应用需要对状态进行记录。保留之前看到的元组信息，可以是未经处理的生数据，也可以是经过 聚合的数据，都能够帮助处理引擎找到数据中蕴藏的模式。在进行任何分析之前，获取更多维度的数据有助于丰富这些元组数据，来进行更广泛的概括和分析。通常 来说，最终决策取决于这些持久储存的动态规则。