11.1 流计算概述
11.1.1流数据
流数据：即数据以大量、快速、时变的流形式持续到达
流数据具有如下特征：
– 数据快速持续到达，潜在大小也许是无穷无尽的
– 数据来源众多，格式复杂
– 数据量大，但是不十分关注存储，一旦经过处理，要么被丢弃， 要么被归档存储
– 注重数据的整体价值，不过分关注个别数据
– 数据顺序颠倒，或者不完整，系统无法控制将要处理的新到达的 数据元素的顺序
11.1.2 批量计算和流计算
• 对静态数据和流数据的处理，对应着两种截然不同的计算模式：批量计算和实时计算
•批量计算：充裕时间处理静态数据， 如Hadoop •流数据不适合采用批量计算，因为流数据不适合用传统的关系模型建模
•流数据必须采用实时计算，响应时间为秒级
11.1.3 流计算概述
• 流计算：实时获取来自不同数据源的海量数据，经过实时分析处理，获得有价值的信息
•流计算秉承一个基本理念，即数据的价值随着时间的流逝而降低， 如用户点击流。因此，当事件出现时就应该立即进行处理，而不是缓存起来进行批量处理。为了及时处理流数据，就需要一个低延迟、可扩展、高可靠的处理引擎
• 对于一个流计算系统来说，它应达到如下需求：
– 高性能 – 海量式 – 实时性 – 分布式 – 易用性 – 可靠性
11.2 流计算的处理流程
11.2.1 数据处理流程
•传统的数据处理流程，需要先采集数据并存储在关系数据库等数据管理系统中，之后由用户通过查询操作和数据管理系统进行交互
• 传统的数据处理流程隐含了两个前提：
– 存储的数据是旧的。存储的静态数据是过去某一时刻的快照，这些数据在查询时可能已不具备时效性了
– 需要用户主动发出查询来获取结果
• 流计算的处理流程一般包含三个阶段：数据实时采集、数据实时计算 、实时查询服务
11.2.2 数据实时采集
数据实时采集阶段通常采集多个数据源的海量数据，需要保证实时性 、低延迟与稳定可靠
• 数据采集系统的基本架构一般有以下三个部分：
– Agent：主动采集数据，并把数据推送到Collector部分
– Collector：接收多个Agent的数据，并实现有序、可靠、高性能的转发
– Store：存储Collector转发过来的数据（对于流计算不存储数据）
11.2.3 数据实时计算
• 数据实时计算阶段对采集的数据进行实时的分析和计算，并反馈实时结果
• 经流处理系统处理后的数据，可视情况进行存储，以便之后再进行分析计算。在时效性要求较高的场景中，处理之后的数据也可以直接丢弃
11.2.3 实时查询服务
• 实时查询服务：经由流计算框架得出的结果可供用户进行实时查询、 展示或储存
• 传统的数据处理流程，用户需要主动发出查询才能获得想要的结果。 而在流处理流程中，实时查询服务可以不断更新结果，并将用户所需的结果实时推送给用户 • 虽然通过对传统的数据处理系统进行定时查询，也可以实现不断地更新结果和结果推送，但通过这样的方式获取的结果，仍然是根据过去某一时刻的数据得到的结果，与实时结果有着本质的区别
流处理系统与传统的数据处理系统有如下不同：
– 流处理系统处理的是实时的数据，而传统的数据处理系统处理的 是预先存储好的静态数据
– 用户通过流处理系统获取的是实时结果，而通过传统的数据处理系统，获取的是过去某一时刻的结果
– 流处理系统无需用户主动发出查询，实时查询服务可以主动将实时结果推送给用户
11.3 开源流计算框架Storm
11.3.1 Storm简介
• Twitter Storm是一个免费、开源的分布式实时计算系统， Storm对于实时计算的意义类似于Hadoop对于批处理的意义，Storm可以简单、高效、可靠地处理流数据，并支持多种编程语言
• Storm框架可以方便地与数据库系统进行整合，从而开发出强大的实时计算系统
• Storm可用于许多领域中，如实时分析、在线机器学习、持续计算、 远程RPC、数据提取加载转换等
• Storm具有以下主要特点：
– 整合性 ：Storm可方便地与队列系统和数据库系统进行整合。
– 简易的API
– 可扩展性 ：Storm的并行特性使其可以运行在分布式汲取中
– 容错性：Storm可以自动进行故障节点的重启，以及节点故障时任务的重新分配
– 可靠的消息处理
– 支持各种编程语言
– 快速部署
– 免费、开源
11.3.2 Storm的设计思想
Storm主要术语包括Streams、Spouts、Bolts、Topology和Stream Groupings
Streams：
Storm将流数据Stream描述成一个无限的Tuple序列，这些Tuple序列会以分布式的方式并行地创建和处理
每个tuple是一堆值，每个值有一个名字，并且每个值可以是任何类型
Tuple本来应该是一个Key-Value的Map，由于各个组件间传递的tuple的字段 名称已经事先定义好了，所以Tuple只需要按序填入各个Value，所以就是一个 Value List（值列表）
Spout:
Storm认为每个Stream都有一个源头，并把这个源头抽象为Spout
通常Spout会从外部数据源（队列、数据库等）读取数据 ，然后封装成Tuple形式，发送到Stream中。Spout是一 个主动的角色，在接口内部有个nextTuple函数，Storm 框架会不停的调用该函数
Bolt:
Storm将Streams的状态转换过程抽象为Bolt。Bolt即可以处理 Tuple，也可以将处理后的Tuple作为新的Streams发送给其他Bolt
Bolt可以执行过滤、函数操作、Join、操作数据库等任何操作
Bolt是一个被动的角色，其接口中有一个execute(Tuple input)方法， 在接收到消息之后会调用此函数，用户可以在此方法中执行自己的处理逻辑
Topology：
Storm将Spouts和Bolts组成的网络抽象成Topology，它可以被提交到Storm集群执行。Topology可视为流转换图，图中节点是一个Spout或 Bolt，边则表示Bolt订阅了哪个Stream。当Spout或者Bolt发送元组时，它会把元组发送到每个订阅了该Stream的Bolt上进行处理
Topology里面的每个处理组件（Spout或Bolt）都包含处理逻辑， 而组件之间的连接则表示数据流动的方向
Topology里面的每一个组件都是并行运行的
在Topology里面可以指定每个组件的并行度， Storm会在集群里面分配那么多的线程来同时计算
在Topology的具体实现上，Storm中的Topology 定义仅仅是一些Thrift结构体（二进制高性能的通信中间件），支持各种编程语言进行定义
Stream Groupings：
Storm中的Stream Groupings用于告知 Topology如何在两个组件间（如Spout和Bolt之间，或者不同的Bolt 之间）进行Tuple的传送。每一个Spout和Bolt都可以有多个分布式任务，一个任务在什么时候、以什么方式发送Tuple就是由Stream Groupings来决定的
目前，Storm中的Stream Groupings有如下几种方式：
(1)ShuffleGrouping：随机分组，随机分发Stream中的Tuple，保证每个Bolt的Task接收Tuple数量大致一致
(2)FieldsGrouping：按照字段分组，保证相同字段的Tuple分配到同一 个Task中
(3)AllGrouping：广播发送，每一个Task都会收到所有的Tuple
(4)GlobalGrouping：全局分组，所有的Tuple都发送到同一个Task中
(5)NonGrouping：不分组，和ShuffleGrouping类似，当前Task的执行会和它的被订阅者在同一个线程中执行
(6)DirectGrouping：直接分组，直接指定由某个Task来执行Tuple的处理
11.3.3 Storm的框架设计
Storm集群采用“Master—Worker”的节点方式：
– Master节点运行名为“Nimbus”的后台程序（类似 Hadoop中的“JobTracker”），负责在集群范围内分发代码、为Worker分配任务和监测故障
– Worker节点运行名为“Supervisor”的后台程序，负责监听分配给它所在机器的工作，即根据Nimbus分配 的任务来决定启动或停止Worker进程，一个Worker节点上同时运行若干个Worker进程
Storm使用Zookeeper来作为分布式协调组件，负责Nimbus和多个Supervisor之间的所有协调工作。借助于Zookeeper，若Nimbus进程或Supervisor进程意外终止，重启时也能读取、恢复之前的状态并继续工作，使得Storm极其稳定
Worker进程
(1)Worker进程:每个worker进程都属于一个特定的Topology，每个Supervisor 节点的worker可以有多个，每个worker对Topology中的每个组件（Spout或 Bolt）运行一个或者多个executor线程来提供task的运行服务
(2)Executor：executor是产生于worker进程内部的线程，会执行同一个组件的一个或者多个task。
(3)Task:实际的数据处理由task完成
11.3.4 Storm的工作流程
•所有Topology任务的提交必须在Storm客户端节点上进行，提交后，由Nimbus节点分配给其他Supervisor节点进行处理
•Nimbus节点首先将提交的Topology进行 分片，分成一个个Task，分配给相应的 Supervisor，并将Task和Supervisor相关的信息提交到Zookeeper集群上
•Supervisor会去Zookeeper集群上认领自己的Task，通知自己的Worker进程进行Task的处理
11.4 Spark Streaming
11.4.1 Spark Streaming设计
Spark Streaming可整合多种输入数据源，如Kafka、Flume、 HDFS，甚至是普通的TCP套接字。经处理后的数据可存储至文件 系统、数据库，或显示在仪表盘里 
Spark Streaming的基本原理是将实时输入数据流以时间片（秒级）为单 位进行拆分，然后经Spark引擎以类似批处理的方式处理每个时间片数据 
Spark Streaming最主要的抽象是DStream（Discretized Stream，离散化数据 流），表示连续不断的数据流。在内部实现上，Spark Streaming的输入数据按 照时间片（如1秒）分成一段一段的DStream，每一段数据转换为Spark中的 RDD，并且对DStream的操作都最终转变为对相应的RDD的操作
11.4.2 Spark Streaming 和 Storm的对比
•Spark Streaming和Storm最大的区别在于，Spark Streaming无 法实现毫秒级的流计算，而Storm可以实现毫秒级响应
•Spark Streaming构建在Spark上，一方面是因为Spark的低延迟执行引擎（100ms+）可以用于实时计算，另一方面，相比 于Storm，RDD数据集更容易做高效的容错处理