关于此文
最近在忙着准备校招的相关复习，所以也整理了一下上学期上课时候的学到的一些知识。刚好发现当时还写了一篇类似于文献综述性质的文章，就在这里贴出来。题材是关于大数据的，也是比较火热的一个话题，虽然现在接触的项目与大数据不太有关联，可能以后也不一定从事这方面的工作吧。就IT行业的研究成果来讲国外期刊无论是发表速度还是质量都是高于国内，所以参考的大部分都是当时最新在核心期刊上发表的论文，参考文献在最后一一列出。因为文章没有多少自己的创新点，仅仅是最新、最热技术或者分析的一个总结，所以放上来仅仅是对大数据相关前景做一个阶段性汇总。篇幅较长，可能会有几篇。 下部分链接
1 大数据概述
1.1 大数据的产生
我们正处于一个信息化的时代。在信息化时代，我们认为[1]数据就是金钱、就是成功的根基。借助于电脑和卫星等科技的帮助，我们能够收集大量的数据。起初，我们利用电脑和各式各样的存储技术来存储各种形态的数据。然而，随着时间的推移，大量的异构的数据存储构成的数据集就变的异常的庞大。
随着因特网在全球范围的普及，数据量变的如此的巨大，以至于使用现有的数据管理方法或者传统的数据处理应用很难应付。上述所提到的大规模、大体量的数据集我们就称之为大数据。
1.1.1 大数据的形成
大数据就是一类复杂且庞大的数据集合，传统的数据管理工具或者应用已经无法胜任其数据的处理工作。数据之所以会大规模的增长[1]，其中一个原因就在于通过对一些具有单一关联的大型数据集的分析，产生的额外的信息资源。这些通过分析产生的信息资源利用的案例可以在“景点的商业发展趋势的预测”、“研究成果质量的预测”、“疾病的预防”、“打击犯罪”和“预测实时交通拥塞程度”等场景下看到。
1.2 大数据的发展趋势和挑战
大数据通常是和云计算、数据挖掘、机器学习密不可分的。大数据的分析主要涉及到以下的四个方面[2]：数据管理和结构支撑、开发模型和评测、可视化和用户接口、商业模型。
1.2.1 大数据的发展
图1[2]显示了传统的大数据工作流分析经历的一些阶段。数据以数据库，数据流，数据集合以及数据仓库等方式来建模。数据的数量级以及数据的多样性要求在处理之前要进行数据的集成、清洗以及过滤等工作，以保证其后续工作的开展。
数据分析过程中最耗时、耗力的就是[2]数据的准备阶段。通常会遇到的一个问题就是需要分析的数据会使得现有的分析系统达到饱和。因此，分析大规模的数据时必须考虑到数据存储、过滤、移植和检索的效率。
分析处理这些大数据之所以面临挑战的另一个原因是[2]数据形式的多样性。正如图2所示，数据主要有四种形式。而如今大部分的数据，既不是结构化的数据，也不是半结构化的数据。
下面将讨论数据的速率[2]（图3）。这里所说的速率，主要是讨论数据到达的时间问题。在某些应用中，数据的到达以及处理形式可能是成批的，但是在其他的应用中可能数据就需要以连续不断的或者实时的形式展现。一些时候需要对这些数据进行及时的处理和响应。例如为数据中心提供实时的数据活动的管理。
1.2.2 大数据的挑战
大数据已经成为一个炙手可热的话题，但是不可否认，大数据仍然面临一系列的挑战。尤其是现阶段广泛使用的流数据（下面会重点讨论）。
数据的多样性[2]：如何去应对始终呈增长趋势的数据。尤其是当数据以非结构化的形式产生的时候，如何从大量该类型的数据中快速有效的读取出用户所需要的数据。如何从流式数据中聚集并读取数据中的潜在关联性。
数据的存储：如何从非结构化的数据中快速提取并存储重要的信息？如何优化存储的结构，使得存储在其中的数据能够被高效率的检索？现存的文件系统能否有效的满足大数据分析所要求的性能？
数据的集成：需要新的协议和接口来满足不同形态和不同来源的数据。
数据处理和资源管理：需要设计出应用于流式数据的最优模型。需要设计出协同文件系统达到最高效能的处理引擎。
2 数据流挖掘概述
传统的数据处理的方法[3]，对于那些建立在特定数据集上的离线的数据，以及批量到达的数据显得相对有效。但是随着时代的发展和处理任务的更迭，有时候，我们的任务所处理的对象是流式数据，或者在线的实时产生的数据。越来越多的实时应用程序需要动态的处理基于流式数据的一些查询请求。若在这样的请求中，在运用传统的方法，那么无论是对于空间占用还是效率来说，可能花销都是比较大的。现在先对流式数据的一些概念加以阐释。下述内容主要也将针对流式数据展开。
2.1 流式数据概述
为了能够在数据仓库中提取出一些新的潜在信息，我们已经掌握了一些系列数据挖掘的技术。但是[4]如今，当我们试图从大量的流式数据中以一种合适、高效的方法来提取我们所需要的信息时，出现了一系列的挑战。
2.2 流式数据发展及挑战
在处理流式数据挖掘的时候，我们不能无视静态数据和流式数据之间的区别。我们知道，静态数据是预先存储在固定的设备上，供查询和分析，一边找到潜在的价值。但是，由于流式数据连续性特性，很显然无法完全存储不断进入应用的流式数据，而且，应用通常也要求我们要在极短的时间内对请求做出相应，这与处理静态数据来比，时间显然要短得多。因此流式数据的挖掘处理主要面对内存管理、数据结构和资源分配方面的挑战。
3 流式数据工具集
表1[3]列出了大数据（包括流式数据、批量数据等形式）处理所需要的工具集，包括大数据处理的所需要的库、平台和框架引擎。
|
工具集 |
处理对象 |
匹配引擎 |
|
Mahout |
Batch |
MapReduce, Spark, H2O |
|
MLlib |
Batch, Streaming |
Spark |
|
H2O |
Batch |
H2O |
|
SAMOA |
Streaming |
Storm, Samza, S4 |
表1 大数据处理工具集
因为本文主要针对性地调研了流式数据相关方面的内容，因此下面的分析也主要集中于流式数据相关工具集（SAMOA），对于MLlib仅简单介绍。关于匹配引擎和框架的内容将在下一章节具体分析。
3.1 MLlib库
MLlib[3]是一个与Spark几乎同时段出现的产物，MLlib是一个机器学习的库文件。其作为一款常驻内存的分布式处理引擎，广受欢迎并且被许多大数据应用程序所使用。MLlib兼容批量数据和流式数据。MLlib的设计初衷就是为了使用户能够在利用该库的基础上创建自己的算法。Spark.ml提供了一系列统一的接口与MLlib合作创建、扩展以及应用一些机器学习的算法。MLlib支持很多有助于数据处理和模型评估的数学和统计学方法。现在很多的模型都很好的使用了MLlib库，包括分类模型、迭代模型、评价模型、集群以及降维等。
3.2 SAMOA平台
3.2.1 SAMOA平台概述
Samoa(Scalable Advanced Massive Online Analysis)是一种流数据挖掘的平台。该平台为[5]最常用的数据挖掘和机器学习的任务（如：分类、集群、迭代以及抽象等等）提供了一系列分布式的流式处理算法。它的优势在于提供了接口，这使得其能很好的被利用在多种分布式系统，结合一些流式处理引擎（Storm、S4、Samza）。Samoa用Java语言编写，是一个开源的平台，可以在[6]http://samoa-project.net上获取使用。图4描述了平台与引擎之间的关系。
我们既可以将SAMOA看作是一个框架也可以将其看作是一个库（跟上面提到的MLlib类似）。
作为框架，它允许算法的开发人员从底层的硬件设备中抽象，达到代码重用的目的。上文提到，它的优势[5]在于提供了能用在多种分布式系统上的接口，并适配多种流式处理引擎。通过设计了一个基于现代DSPE必要元素的最小化的应用程序接口API。这些接口使得可以很方便的将其绑定到新的引擎上面。SAMOA通过API和部署的方式，隐藏了DSPE的底部细节和底层差异。
图5和图6具体给出了SAMOA的项目架构。作为库，SAMOA包含了为在分布式机器上进行流式数据机器学习所设计的算法的实现。为“分类”这一步的操作，提供了Vertical Hoeffding Tree (VHT)算法，对于集群，其包含了基于CluStream的算法。
Samoa平台在科学研究和实际生产生活的部署中都占有一席之地。
3.2.2 SAMOA算法架构
在SAMOA中，算法[5]被看作有向图上的节点进行消息传递的，这些节点之间通过数据流的形式传递消息。在图7表示的有向图拓扑中，每个节点都是一个通过流来发送和接收消息的处理器。每一个处理机都是节点执行算法的载体[7]。一个数据流可以有一个源节点，但是可以有多个目的节点（类似于PUB/SUB模型）有向图的拓扑是通过一个拓扑建立器的工具来生成的，它连接各部分用户的代码到SAMOA平台上，并且在后台做相应的处理和备份工作。图8则是从集群角度来描述了对应的算法架构。
4 流式数据框架
流式处理平台[8]使得应用程序能够对源源不断进入系统的数据进行分析和处理。现实生活中有许多借助于流式大数据来实现其系统目标的案例。例如，在医院系统中，我们可以通过检测病人的生理构造的变化情况，来预测是否应该为病人进行实时的生命体征状态监控。这些功能的实现都离不开数据框架的支持，下面将对流式数据中采用的主流框架进行分析，并在某些性能方面与应用于其他数据结构的框架进行对比。
4.1 Storm框架
如果[9]只能用一句话来形容storm或者来介绍storm，那么用“分布式实时计算系统”来概括则再好不过了。Storm是一个开源的实时计算系统，它提供了一系列的基本元素用于进行计算。
4.1.1 Storm概述
Apache Storm[10]是一款免费的开源分布式实时计算系统。Storm能够可靠的处理大量的流式数据。现在Storm所做的工作，好比就是Hadoop在批处理数据阶段所做的工作。Storm简单易用，可以兼容任何的编程语言。Storm是一个由一系列用户所编写的消息和应用程序代码所组成的平台。Storm中非常重要的一个概念就是“流”。所谓的“流”就是许许多多无界的数据的元组组成的序列。用户可以通过使用Storm提供的两个概念（spout、bolt），将一组已经存在的流（例如：twitter的消息）传递到新的流（例如：趋势信息）中去。spout和bolt都提供了接口，用户必须实现这些接口来完成自己的逻辑功能的实现。
4.1.2 Storm相关概念
在图4关于SAMOA中已经接触到了storm数据流，现在对图9的数据流加以分析。
Spout就是数据源也称消息源。Storm对于原始数据输入来源并不加以严格的限制。这取决于用户自己编写的代码，无论是来自于队列、来自于数据库、来自于网站还是其他的任何来源。例如。一个spot可能从队列中读取元组然后形成输入流，也可能使用twitter的接口，然后将一系列从twitter获取的数据作为输入。然后这些数据然后被传递给一个或者多个bolt处理。
对于bolt来说，它将接收多个输入流，然后做一些处理工作，并且可能产生一组新的流式数据。一些复杂的流式数据的传递处理过程可能会经历多步骤并且需要不止一个bolt的配合才能够完成。通过将一个大的任务分散成若干个小的任务块，每个bolt可以集中处理单个相对规模较小的任务，从而也会产生较快的响应。使用多个bolt也可以同时带来较高的性能，因为storm可以提供多个源数据给bolt处理以加快其处理的进程和处理的效率。
Spout和bolt都被打包成Topology[8]。Topology就是用户提交给storm执行的一个操作单元。为了能够在storm上面进行实时的计算，首先要创建topology。这个topology就是一个计算图。在其中，每个节点不是bolt就是spout，这些节点都包含了一个逻辑处理，并且图中的箭头表示了数据是如何在不同的节点之间流动的。节点之间的操作都是并发进行的。直到用户主动去终止一个拓扑或者出现崩溃，否则拓扑会一直在运行。当然，如果系统检测到某个spout或者bolt崩溃，那么会结束这单个的spout或者bolt。
结合上述storm中一个拓扑topology的组成部分，图10给出了strom中的一些角色关系。
表2列出了Hadoop与Strom中角色关系的对比。
|
Hadoop |
Storm |
|
|
系统角色 |
JobTracker |
Nimbus |
|
TaskTracker |
Supervisor |
|
|
Child |
Worker |
|
|
应用名称 |
Job |
Topology |
|
组件接口 |
Mapper/Reducer |
Spout/Bolt |
表2 Hadoop与Storm系统角色对比
Hadoop主要是针对于批量数据的大数据处理框架，虽然针对目标不同，但是通过对比还是能轻易的得出Storm各部分角色在框架中所起的作用。
Nimbus：任务调度和资源分配。
Supervisor：接受任务，启动和停止属于自己管理的worker进程。
Worker：运行具体处理组件逻辑的进程。
Task：worker中每一个spout/bolt的线程称为一个task。在storm0.8之后，task不再与物理线程对应，同一个spout/bolt的task可能会共享一个物理线程，该线程称为executor。
4.1.3节中，我们会结合于上面的表格针对Strom具体说明不同的节点运行的角色以及它们是如何相互配合的。
4.1.3 Storm架构
在一个Storm集群中主要有两种类型的节点[8]。主节点和处理节点。
主节点运行一个称之为Nimbus的进程。其负责在集群中部署代码、分派任务、监视任务的进展情况以及回报崩溃的情况。它也同时运行一个UI进程。UI即用户界面，它提供了一个网站给用户以实时观测集群的状态以及管理拓扑和拓扑上的节点。在目前的Storm版本中，会有这样的情况出现：即当主节点崩溃后，处理节点仍然在工作，但是重新配置集群等操作在此期间就是无法进行了，除非我们去重启主节点。也许未来的Strom版本会对这一问题进行改进。
进程节点，运行一个称之为Supervisor的进程。这个Supervisor一直在监听者分派给这台机器的任务。它根据需求动态的开始和停止工作。这个需求是基于主节点分派给这台机器的任务。在一个进程节点中的若干个任务，都执行一系列的拓扑。例如一个或多个spout和bolt、metrics。鉴于此情况。一个拓扑topology很可能是分布在一个集群的若干个机器之间。进程节点同样也运行一个LogViewer进程，该进程可以用来查看网站上的浏览日志。
主节点与进程节点之间的协同工作是通过Zookeeper集群来完成的。在Zookeeper中可以存储和检索有关分配任务情况、进程处理健康状态以及集群的状态。
用户需要手动的将应用程序的代码打包成jar包，并且传递给主节点。将jar包分派给进程节点的工作进程是通过进程节点和主节点之间的直连网络来实现的。图11就展现了Storm架构的主要组成部分。
通常当需要较高的执行性能时，可以通过strom向集群里增加一些节点，同理当不需要的时候，可以实时的移走这些多余的节点，从而达到动态处理的效果。一言以蔽之，Strom赋予用户往平台上增加节点的功能。
4.1.4 Storm集群应用
在自动化计算领域，我们最常见的就是使用监控、分析、计划、执行（MAPE）这样一个循环往复的过程来控制一个系统。通过上述的循环过程使得Strom变得灵活而且可扩展。例如：Strom集群规模的增长和收缩都是基于拓扑结构的需要。首先用传感器来检测Storm集群的工作状态。MAPE的环路然后监测传感器的输出，分析数据的内容查处问题所在，然后找出补救的措施，执行新的选择算法。这个过程最终以动态修改集群的原有配置（通过Effector实现），使其适应新环境下的新需求而结束。图12给出了MAPE的执行流程。
监测：监测一个Storm集群系统可以作用于多个层面。进程节点将提供系统级的信息，包括处理器的使用情况、内存的使用、磁盘使用和网络接口状况。平台自身也是一个数据监测源。Storm本身也提供平台状况信息，包含正在工作的节点的数量和状态、拓扑以及元组数。最后，监测的数据也可以用应用层面提供。例如，一个拓扑检查自动计算系统的日志文件可以汇报其冲突率。监控输出的结果集是一个metrics。
分析：分析阶段通过查验一系列的metrics，来给出结论，判断是否当前的状态是正常的。例如：判断过去5分钟内处理器的平均占用率是否低于百分之七十？当然，其他的复杂的运算情形也是需要考虑在内的，包括结合平台状况、系统性能来分析metrics。在Storm集群中分析阶段需要给出的结论是当前的状态是（1）良好的（2）需要新的进程节点（3）存在过多的进程节点等等。
计划：当前面的分析阶段给出的结论是现在Storm集群存在问题时，必须在计划阶段给出处理的办法。如果需要一个进程节点，那么计划阶段就会立即告知执行阶段此请求，并且要求提供一个已经装有Storm的虚拟机。但是及时加入了新的节点，当前的执行任务不会重新被分配执行，这种情况下，拓扑就不是最优化的。只有当上一个分析阶段指出之一状况时，计划阶段会通知执行阶段重新分派任务，这样，刚刚被加进来的节点就能被利用了。如果当前的进程节点过多，就会销毁一部分。
执行：最后一个阶段就是执行计划阶段所需求的任务。在Storm集群中最主要的就是三方面的任务：第一、添加一个虚拟机，并配置相关的strom软件。第二、重构拓扑结构。第三、删除多余的虚拟机。这一阶段执行的时间可能不仅仅是几秒钟而已，因此必须做好相对应的监控工作，防止引起不必要的灾难。
4.2 Spark框架
Spark[11]是一个高速、通用的集群计算系统。它为Java、Scala、Python以及R语言都提供了应用程序接口。它也是最佳的支持通用执行图的引擎。不仅如此，Spark也提供了非常丰富的插件工具，其中包括为SQL设计的Spark SQL、结构化的数据处理工具、机器学习库MLlib、图像处理工具GraphX和Spark Streaming。
4.2.1 Spark概述
Spark起源于加利福尼亚大学伯克利分校[3]。设计Sprak的目的就是为了解决许多Hadoop MapReduce处理框架所遗留下来的一些问题。Spark项目引进了一个新的概念：弹性分布式数据集（RDD）。该数据集使得数据在集群节点之间的存储和处理直接在内存中进行，从而极大的加快了效率。同时，也创建了一个有向无环图（DAG）实现其容错机制。当集群中的某一个节点崩溃后，可以转由另一个节点来接手处理原来节点所负责的事物。Spark最大的特点和优势就是减少了I/O读写所耗费的时间。在2014年sort benchmark上Spark刷新了记录。使用206个节点在23分钟之内成功排序了100TB的数据。而之前的记录则是由MapReduce保持的（使用210个节点在72分钟内排序同样数量的数据）。Spark兼容Hadoop的组件（如HDFS和Hive）并且可以使用YARN运行在Hadoop上。
4.2.2 Spark架构
Spark的架构图如图13[12]所示。
下面将对几个重要的概念进行说明：
MLlib:在3.1节已经讲到，此处不再赘述。
Spark SQL：Spark SQL是一个Spark为结构化处理所设计的模块。它提供了一个编程的抽象叫DataFrames[13]。当然也可以作为分布式的SQL查询引擎。Spark SQL也可以从已存在的Hive中读取数据。DataFrames则是以列形式组织起来的分布式的数据集。在概念它等同于关系数据库中的一张表或者R/Python语言中的数据框架，但是它又比前者的性能优越。我们可以从几个方面来构造DataFrames：结构化的数据文件、Hive表格、已存在的数据库或者已存在的RDD。DataFrames的API兼容Scala、java、Python和R语言。
GraphX：GraphX是Spark中的一个新的组成部分。可以用于图像和并行图像的计算，同时通过引入了新的图像抽象技术：带权有向图，扩充了RDD。为了支持图像处理，GraphX提出了一系列基本的操作符和API。同时Graphx也在不断的扩充自己的算法库以便不断的简化图像处理的过程。
4.2.3 Spark Streaming
Spark借助于自身的Spark Streaming，提供了数据流处理的功能。结合图14，下面具体分析其计算流程、实时性等评价参数。
Spark Streaming的计算流程是这样的[3]。利用Spark引擎，通过将进入系统的流数据打包成小的批量数据，这与Storm不同，Spark Streaming并不是一次性的处理流式数据。而且在处理数据之前将数据按照时间间隔切割成小的批量数据。从而加速处理。其针对持续性数据流的抽象是通过离散流（Discretized Stream）来实现的。所谓的离散流就是若干的RDD组成的集合。这使得既可以处理流式数据也可以处理批量数据。这也就解释了MLlib能够适用于流式数据处理的原因了。
实时性：实时性不能一概而论，具体的处理框架所涉及的不同应用场合会带来不同的效果。Spark Streaming将流式计算分解成多个Job，对于每一段数据的处理都会经过有向无环图分解，并给予对应的任务集的调度。就当前的Streaming版本来说，最小的Batch Size的选取在0.5~2秒钟之间（Storm目前最小的延迟是100ms左右），所以Spark Streaming能够满足除对实时性要求非常高（如高频实时交易）之外的所有流式准实时计算场景。
4.2.4 RDD
RDD可以说是Spark框架的核心。RDD[15]即Resilient Distributed Dataset,弹性分布式数据集。它是一个分布式的内存抽象，RDD允许程序员在大数据上进行基于内存的计算而仍然能够保持较好的容错率。由于现有的流式数据处理的系统对一下的两种问题无法有效的解决：第一、迭代算法，这在图形学和机器学习中很常见。第二、交互式数据挖掘工具。因此催生了RDD。在两种案例中，使得数据常驻内存可以带来较高的效率。为了同时达到较好的容错性，RDD提供了一种非常严格的内存共享机制：即RDD只能以只读的形式被访问。对于创建RDD，只可以通过其他RDD上的批量操作来进行。
在Sprak框架下，RDD被视为对象。通过这些对象上的方法来实现转换。
一旦RDD被定义后[15]，就能够被程序员使用了（在动作中使用）。所谓的动作就是向程序返回值的操作或者将数据传递给存储系统的一些操作。这些操作包括count（返回RDD的元素数量）、collect（返回元素本身）以及save（将RDD输出到存储系统）。在Spark中，RDD只有在动作第一次使用时，才会计算RDD，这样保证了在构建RDD时，通过管道的方式完成转换。
程序员也可以从两个方面来控制RDD。分别是缓存和分区。用户如果请求缓存RDD，那么在同时可以将已经被计算过的RDD分区存储备用。缓存的RDD通常来说都是存放在内存中。另一方面，RDD还能使用户通过关键字来指定分区顺序，这是个可选的项目。当前支持的分区是哈希分区和范围分区。
借助[14]于RDD，Spark Streaming能有较好的容错性。容错性对于流式计算来说非常的重要，一旦无法保证容错能力，那么对于流式计算来说是致命的打击。因为任何一个RDD都是弹性分布式可重算的数据集，其中包含了确定的操作关系，当数据在某个RDD上出现错误了，可以通过原始的数据转换操作到其余的RDD上重新执行计算操作，从而保证了系统的稳定性和容错能力。图15就是反映RDD操作继承关系的图例。
4.2.5 Spark性能分析（与Hadoop比较）
Spark[16]的出现是为了解决Hadoop框架下的很多问题才应运而生的。Spark的一大闪光点就是RDD。通过RDD，Streaming等结合，极大的增加了大数据分析的效能。下面将Spark与Hadoop进行比较。与Hadoop相比，Spark在I/O操作上花费的时间明显缩小了。但是我们认为其为了引入RDD需要耗费额外的内存空间，很明显Spark这一举动是空间换取时间的一种妥协。下面的实验用来评测Hadoop和Spark的系统性能。在实验中选取了典型的迭代算法PageRank。在真实数据和模拟的数据上都进行了相关的测试。测试的结果见图16、图17和图18。
具体的实验算法和步骤，可以参考附录的参考文献。从上面的三组对比数据可以得出以下的结论。（1）当内存能够满足整个迭代过程时，Spark的效率明显高于Hadoop（2）当内存不够时，结论则相反。这说明了，Spark的确是采用了一种空间换时间的做法。因此在使用时必须预先估计数据的规模。否则，可能无法达到预期的计算效果。
4.3 Samza框架
Apache Samza是一个分布式的流处理框架。它使用Apache Kafka来传递消息，使用Apache Hadoop YARN来提供容错、安全和资源管理等功能。
4.3.1 Samza概述
与Storm和Spark都不同，Samza的处理对象不是元组也不是DStream，而是一条一条的消息。在深入理解Samza之前，需要了解下面几个概念：流、作业、任务、区间分割等。
流[17]的概念与Storm和Spark中提到的概念相同。Samza通过对流进行抽象使得其支持嵌入式系统。在Kafka中，流就是一个主题。在数据库中我们可以通过更新操作来读取流。在Hadoop中我们可以在HDFS中定位文件目录。
作业：在Samza中作业就是在一系列输入流上执行逻辑转换并将其加到输出队列中以供输出到输出流上的代码的集合。如果不考虑可扩展性，我们所需要的仅仅是流和作业。我们将流和作业分割成小的部分：分区和任务。
区间：如图19所示，每一个数据流都被分割成一个或多个区间。流中的每一个区间就是一串有序的消息的序列。序列中的每条消息都有一个唯一的识别码，可以是整型序列、比特字符、或者字符串，这些都是由特定的系统所决定的。当一条消息被添加到一个流中去，它仅仅会被添加到一个区间上，至于如何选定区间，则是由用户通过一些算法来决定的。
任务：大规模的作业将会被分成很多的任务。任务是作业的组成单元，正如区间是数据流的组成单元。每个任务都按顺序的拥有它所在输入区间的消息。
4.3.2 Samza架构
Samza的成分有三层：Streaming layer、execution layer和processing layer。并且为每一层都提供了支持，分别是Kafka、YARN和Samza API。这三块共同构成了Samza（如图20）。
4.4 Storm、Spark和Samza对比
4.1、4.2、4.3节提到的三种框架都是开源的框架。具有延迟低、效率高、容错性强的特点[12]。它们的共同特色在于：当你在框架下运行数据流相关的代码进行操作时可以允许并行的进行操作，提高效率的同时保证了容错性。此外，他们都隐藏了底层的实现细节，通过提供的API简化操作。
虽然三者在不同的框架下的专业术语名称不一致，但是其代表的概念具有很大的相似性。
表3列出了三个框架下的基本术语。
|
Storm |
Spark |
Samza |
|
|
Stream Source（s） |
spouts |
Receivers |
consumers |
|
Stream Primitive（p） |
Tuples |
DStream |
Message |
|
Stream Computation（c） |
Bolts |
Transformation Windows Operations |
Tasks |
表3 三个框架术语表
表4列出了三个框架的不同之处。
|
Storm |
Spark |
Samza |
|
|
Delivery Semantics |
At least Once |
Exactly Once |
At least Once |
|
State Management |
stateless |
stateful |
stateful |
|
Latency |
Sub-second |
seconds |
Sub-second |
|
Language Support |
Any |
Scala,Java,Python |
Scala,Java |
表4 三个框架差异
从表4可以看出，三个框架无论在支持的语言还是其他判断方面都是存在着差异的，但是无法评判哪个更优秀，哪个更完美。只有结合具体的环境、具体的需求才能做出最优的判断。当然，实际上，这三个框架都有很多公司在用。
使用Storm的公司有：Twitter，雅虎，Spotify还有The Weather Channel等。
使用Spark的公司有：亚马逊，雅虎，NASA JPL，eBay还有百度等。
使用Samza的公司有：LinkedIn，Intuit，Metamarkets，Quantiply，Fortscale等。
4.5 其他框架
除了上面具体分析的Storm、Spark和Samza三大主流框架外，还有包括Apache Flink[18]、StreamBase[19]、YAHOO S4[20]等出色的框架，当然也存在着基于上述框架改编的新框架，限于篇幅，此处不再赘述。