流计算
一、流计算概述
1.1 静态数据和流数据
• 很多企业为了支持决策分析而构建的数据仓库系统，其中存放的大量历史数据就是静态数据。技术人员可以利用数据挖掘和OLAP（On-Line Analytical Processing）分析工具从静态数据中找到对企业有价值的信息
• 近年来，在Web应用、网络监控、传感监测等领域，兴起了一种新的数据密集型应用——流数据，即数据以大量、快速、时变的流形式持续到达
• 实例：PM2.5检测、电子商务网站用户点击流
• 流数据具有如下特征：
– 数据快速持续到达，潜在大小也许是无穷无尽的
– 数据来源众多，格式复杂
– 数据量大，但是不十分关注存储，一旦经过处理，要么被丢弃，要么被归档存储
– 注重数据的整体价值，不过分关注个别数据
– 数据顺序颠倒，或者不完整，系统无法控制将要处理的新到达的数据元素的顺序
1.2 批量计算和实时计算
• 对静态数据和流数据的处理，对应着两种截然不同的计算模式：批量计算和实时计算
•批量计算：充裕时间处理静态数据，如Hadoop
•流数据不适合采用批量计算，因为流数据不适合用传统的关系模型建模
•流数据必须采用实时计算，响应时间为秒级
•数据量少时，不是问题，但是，在大数据时代，数据格式复杂、来源众多、数据量巨大，对实时计算提出了很大的挑战。因此，针对流数据的实时计算——流计算，应运而生
数据的两种处理模型
1.3 流计算概念
• 流计算：实时获取来自不同数据源的海量数据，经过实时分析处理，获得有价值的信息
流计算示意图
• 流计算秉承一个基本理念，即数据的价值随着时间的流逝而降低，如用户点击流。因此，当事件出现时就应该立即进行处理，而不是缓存起来进行批量处理。为了及时处理流数据，就需要一个低延迟、可扩展、高可靠的处理引擎
• 对于一个流计算系统来说，它应达到如下需求：
– 高性能：处理大数据的基本要求，如每秒处理几十万条数据
– 海量式：支持TB级甚至是PB级的数据规模
– 实时性：保证较低的延迟时间，达到秒级别，甚至是毫秒级别
– 分布式：支持大数据的基本架构，必须能够平滑扩展
– 易用性：能够快速进行开发和部署
– 可靠性：能可靠地处理流数据
1.4 流计算与Hadoop
• Hadoop设计的初衷是面向大规模数据的批量处理，每台机器并行运行MapReduce任务，最后对结果进行汇总输出
• MapReduce是专门面向静态数据的批量处理的，内部各种实现机制都为批处理做了高度优化，不适合用于处理持续到达的动态数据
• 可能会想到一种“变通”的方案来降低批处理的时间延迟——将基于MapReduce的批量处理转为小批量处理，将输入数据切成小的片段，每隔一个周期就启动一次MapReduce作业。但这种方式也无法有效处理流数据
– 切分成小片段，可以降低延迟，但是也增加了附加开销，还要处理片段之间依赖关系
– 需要改造MapReduce以支持流式处理
结论：鱼和熊掌不可兼得，Hadoop擅长批处理，不适合流计算
1.5 流计算框架
• 当前业界诞生了许多专门的流数据实时计算系统来满足各自需求
• 目前有三类常见的流计算框架和平台：商业级的流计算平台、开源流计算框架、公司为支持自身业务开发的流计算框架
• 商业级：IBM InfoSphere Streams和IBM StreamBase
• 较为常见的是开源流计算框架，代表如下：
– Twitter Storm：免费、开源的分布式实时计算系统，可简单、高效、可靠地处理大量的流数据
– Yahoo! S4（Simple Scalable Streaming System）：开源流计算平台，是通用的、分布式的、可扩展的、分区容错的、可插拔的流式系统
• 公司为支持自身业务开发的流计算框架：
– Facebook Puma
– Dstream（百度）
– 银河流数据处理平台（淘宝）
二、流计算处理流程
2.1 数据处理流程
• 传统的数据处理流程，需要先采集数据并存储在关系数据库等数据管理系统中，之后由用户通过查询操作和数据管理系统进行交互
传统的数据处理流程示意图
• 传统的数据处理流程隐含了两个前提：
– 存储的数据是旧的。存储的静态数据是过去某一时刻的快照，这些数据在查询时可能已不具备时效性了
– 需要用户主动发出查询来获取结果
• 流计算的处理流程一般包含三个阶段：数据实时采集、数据实时计算、实时查询服务
流计算处理流程示意图
2.2 数据实时采集
• 数据实时采集阶段通常采集多个数据源的海量数据，需要保证实时性、低延迟与稳定可靠
• 以日志数据为例，由于分布式集群的广泛应用，数据分散存储在不同的机器上，因此需要实时汇总来自不同机器上的日志数据
• 目前有许多互联网公司发布的开源分布式日志采集系统均可满足每秒数百MB的数据采集和传输需求，如：
– Facebook的Scribe
– LinkedIn的Kafka
– 淘宝的Time Tunnel
– 基于Hadoop的Chukwa和Flume
• 数据采集系统的基本架构一般有以下三个部分：
– Agent：主动采集数据，并把数据推送到Collector部分
– Collector：接收多个Agent的数据，并实现有序、可靠、高性能的转发
– Store：存储Collector转发过来的数据（对于流计算不存储数据）
数据采集系统基本架构
2.3 数据实时计算
• 数据实时计算阶段对采集的数据进行实时的分析和计算，并反馈实时结果
• 经流处理系统处理后的数据，可视情况进行存储，以便之后再进行分析计算。在时效性要求较高的场景中，处理之后的数据也可以直接丢弃
2.4 实时查询服务
• 实时查询服务：经由流计算框架得出的结果可供用户进行实时查询、展示或储存
• 传统的数据处理流程，用户需要主动发出查询才能获得想要的结果。而在流处理流程中，实时查询服务可以不断更新结果，并将用户所需的结果实时推送给用户
• 虽然通过对传统的数据处理系统进行定时查询，也可以实现不断地更新结果和结果推送，但通过这样的方式获取的结果，仍然是根据过去某一时刻的数据得到的结果，与实时结果有着本质的区别
• 流处理系统与传统的数据处理系统有如下不同：
– 流处理系统处理的是实时的数据，而传统的数据处理系统处理的是预先存储好的静态数据
– 用户通过流处理系统获取的是实时结果，而通过传统的数据处理系统，获取的是过去某一时刻的结果
– 流处理系统无需用户主动发出查询，实时查询服务可以主动将实时结果推送给用户
三、流计算应用
• 流计算是针对流数据的实时计算，可以应用在多种场景中，如Web服务、机器翻译、广告投放、自然语言处理、气候模拟预测等
• 如百度、淘宝等大型网站中，每天都会产生大量流数据，包括用户的搜索内容、用户的浏览记录等数据。采用流计算进行实时数据分析，可以了解每个时刻的流量变化情况，甚至可以分析用户的实时浏览轨迹，从而进行实时个性化内容推荐
• 但是，并不是每个应用场景都需要用到流计算的。流计算适合于需要处理持续到达的流数据、对数据处理有较高实时性要求的场景
3.1 应用场景1: 实时分析
• 传统的业务分析一般采用分布式离线计算的方式，即将数据全部保存起来，然后每隔一定的时间进行离线分析来得到结果。但这样会导致一定的延时，难以保证结果的实时性
• 随着分析业务对实时性要求的提升，离线分析模式已经不适合用于流数据的分析，也不适用于要求实时响应的互联网应用场景
• 如淘宝网“双十一”、“双十二”的促销活动，商家需要根据广告效果来即时调整广告，这就需要对广告的受访情况进行分析。但以往采用分布式离线分析，需要几小时甚至一天的延时才能得到分析结果。而促销活动只持续一天，因此，隔天才能得到的分析结果便失去了价值
• 虽然分布式离线分析带来的小时级的分析延时可以满足大部分商家的需求，但随着实时性要求越来越高，如何实现秒级别的实时分析响应成为业务分析的一大挑战
• 针对流数据，“量子恒道”开发了海量数据实时流计算框架Super Mario。通过该框架，量子恒道可处理每天TB级的实时流数据，并且从用户发出请求到数据展示，整个延时控制在2-3秒内，达到了实时性的要求
Super Mario处理流程
3.2 应用场景2: 实时交通
• 流计算不仅为互联网带来改变，也能改变我们的生活
• 如提供导航路线，一般的导航路线并没有考虑实时的交通状况，即便在计算路线时有考虑交通状况，往往也只是使用了以往的交通状况数据。要达到根据实时交通状态进行导航的效果，就需要获取海量的实时交通数据并进行实时分析
• 借助于流计算的实时特性，不仅可以根据交通情况制定路线，而且在行驶过程中，也可以根据交通情况的变化实时更新路线，始终为用户提供最佳的行驶路线
四、流计算开源框架 – Storm
• 以前只有政府机构和金融机构能够通过昂贵的定制系统来满足流数据实时分析计算需求
• 早期对于流计算的研究多数是基于对传统数据库处理的流式化，即实时数据库，很少研究流计算框架
• Yahoo! S4和Twitter Storm的开源，改变了这个情况
• 在流数据处理上比MapReduce更有优势
• 批处理系统关注吞吐率，流处理系统关注延时
• Yahoo! S4和Twitter Storm改变了开发实时应用的方式
– 以前既要关注处理逻辑，还要解决实时数据获取、传输、存储
– 现在可以快速低成本搭建起实时流处理系统
4.1 Storm简介
• Twitter Storm是一个免费、开源的分布式实时计算系统，Storm对于实时计算的意义类似于Hadoop对于批处理的意义，Storm可以简单、高效、可靠地处理流数据，并支持多种编程语言
• Storm框架可以方便地与数据库系统进行整合，从而开发出强大的实时计算系统
• Twitter是全球访问量最大的社交网站之一，Twitter开发Storm流处理框架也是为了应对其不断增长的流数据实时处理需求
Twitter的分层数据处理架构
4.2 Storm的特点
• Storm可用于许多领域中，如实时分析、在线机器学习、持续计算、远程RPC、数据提取加载转换等
• Storm具有以下主要特点：
– 整合性：Storm可方便地与队列系统和数据库系统进行整合
– 简易的API：Storm的API在使用上即简单又方便
– 可扩展性：Storm的并行特性使其可以运行在分布式集群中
– 容错性：Storm可自动进行故障节点的重启、任务的重新分配
– 可靠的消息处理：Storm保证每个消息都能完整处理
– 支持各种编程语言：Storm支持使用各种编程语言来定义任务
– 快速部署：Storm可以快速进行部署和使用
– 免费、开源：Storm是一款开源框架，可以免费使用
4.3 Storm设计思想
• Storm主要术语包括Streams、Spouts、Bolts、Topology和Stream Groupings
• Streams：Storm将流数据Stream描述成一个无限的Tuple序列，这些Tuple序列会以分布式的方式并行地创建和处理
•每个tuple是一堆值，每个值有一个名字，并且每个值可以是任何类型
•Tuple本来应该是一个Key-Value的Map，由于各个组件间传递的tuple的字段名称已经事先定义好了，所以Tuple只需要按序填入各个Value，所以就是一个Value List（值列表）
Streams无界的Tuple序列
• Spout：Storm认为每个Stream都有一个源头，并把这个源头抽象为Spout
• 通常Spout会从外部数据源（队列、数据库等）读取数据，然后封装成Tuple形式，发送到Stream中。Spout是一个主动的角色，在接口内部有个nextTuple函数，Storm框架会不停的调用该函数
Spouts Streams的来源
• Bolt：Storm将Streams的状态转换过程抽象为Bolt。Bolt即可以处理Tuple，也可以将处理后的Tuple作为新的Streams发送给其他Bolt
• Bolt可以执行过滤、函数操作、Join、操作数据库等任何操作
• Bolt是一个被动的角色，其接口中有一个execute(Tuple input)方法，在接收到消息之后会调用此函数，用户可以在此方法中执行自己的处理逻辑
Bolts处理Tuples、创建新Streams
• 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的处理
4.4 Storm框架设计
•Storm运行任务的方式与Hadoop类似：Hadoop运行的是MapReduce作业，而Storm运行的是“Topology”
•但两者的任务大不相同，主要的不同是：MapReduce作业最终会完成计算并结束运行，而Topology将持续处理消息（直到人为终止）
Storm和Hadoop架构组件功能对应关系
• Storm集群采用“Master—Worker”的节点方式：
– Master节点运行名为“Nimbus”的后台程序（类似Hadoop中的“JobTracker”），负责在集群范围内分发代码、为Worker分配任务和监测故障
– Worker节点运行名为“Supervisor”的后台程序，负责监听分配给它所在机器的工作，即根据Nimbus分配的任务来决定启动或停止Worker进程，一个Worker节点上同时运行若干个Worker进程
• Storm使用Zookeeper来作为分布式协调组件，负责Nimbus和多个Supervisor之间的所有协调工作。借助于Zookeeper，若Nimbus进程或Supervisor进程意外终止，重启时也能读取、恢复之前的状态并继续工作，使得Storm极其稳定
Storm集群架构示意图
(1)worker:每个worker进程都属于一个特定的Topology，每个Supervisor节点的worker可以有多个，每个worker对Topology中的每个组件（Spout或 Bolt）运行一个或者多个executor线程来提供task的运行服务
(2)executor：executor是产生于worker进程内部的线程，会执行同一个组件的一个或者多个task。
(3)task:实际的数据处理由task完成，在Topology的生命周期中，每个组件的task数目是不会发生变化的，而executor的数目却不一定。executor数目小于等于task的数目，默认情况下，二者是相等的
Worker、Executor和Task的关系
• 基于这样的架构设计，Storm的工作流程如下图所示：
•所有Topology任务的提交必须在Storm客户端节点上进行，提交后，由Nimbus节点分配给其他Supervisor节点进行处理
•Nimbus节点首先将提交的Topology进行分片，分成一个个Task，分配给相应的Supervisor，并将Task和Supervisor相关的信息提交到Zookeeper集群上
•Supervisor会去Zookeeper集群上认领自己的Task，通知自己的Worker进程进行Task的处理
•说明：在提交了一个Topology之后，Storm就会创建Spout/Bolt实例并进行序列化。之后，将序列化的组件发送给所有的任务所在的机器(即Supervisor节点)，在每一个任务上反序列化组件
五、Spark Streaming
5.1 Spark Streaming设计
•Spark Streaming可整合多种输入数据源，如Kafka、Flume、HDFS，甚至是普通的TCP套接字。经处理后的数据可存储至文件系统、数据库，或显示在仪表盘里
Spark Streaming支持的输入、输出数据源
Spark Streaming的基本原理是将实时输入数据流以时间片（秒级）为单位进行拆分，然后经Spark引擎以类似批处理的方式处理每个时间片数据
Spark Streaming执行流程
Spark Streaming最主要的抽象是DStream（Discretized Stream，离散化数据流），表示连续不断的数据流。在内部实现上，Spark Streaming的输入数据按照时间片（如1秒）分成一段一段的DStream，每一段数据转换为Spark中的RDD，并且对DStream的操作都最终转变为对相应的RDD的操作
DStream操作示意图
5.2 Spark Streaming与Storm的对比
•Spark Streaming和Storm最大的区别在于，Spark Streaming无法实现毫秒级的流计算，而Storm可以实现毫秒级响应
•Spark Streaming构建在Spark上，一方面是因为Spark的低延迟执行引擎（100ms+）可以用于实时计算，另一方面，相比于Storm，RDD数据集更容易做高效的容错处理
•Spark Streaming采用的小批量处理的方式使得它可以同时兼容批量和实时数据处理的逻辑和算法，因此，方便了一些需要历史数据和实时数据联合分析的特定应用场合
六、Samza
6.1 基本概念
1.作业
一个作业（Job）是对一组输入流进行处理转化成输出流的程序。
2.分区
•Samza的流数据单位既不是Storm中的元组，也不是Spark Streaming中的DStream，而是一条条消息
•Samza中的每个流都被分割成一个或多个分区，对于流里的每一个分区而言，都是一个有序的消息序列，后续到达的消息会根据一定规则被追加到其中一个分区里
3.任务
•一个作业会被进一步分割成多个任务（Task）来执行，其中，每个任务负责处理作业中的一个分区
•分区之间没有定义顺序，从而允许每一个任务独立执行
•YARN调度器负责把任务分发给各个机器，最终，一个工作中的多个任务会被分发到多个机器进行分布式并行处理
4.数据流图
•一个数据流图是由多个作业构成的，其中，图中的每个节点表示包含数据的流，每条边表示数据传输
•多个作业串联起来就完成了流式的数据处理流程
•由于采用了异步的消息订阅分发机制，不同任务之间可以独立运行
6.2 系统架构
•Samza系统架构主要包括
•流数据层（Kafka）
•执行层（YARN）
•处理层（Samza API）
•流处理层和执行层都被设计成可插拔的，开发人员可以使用其他框架来替代YARN和Kafka
MapReduce批处理架构和Samza流处理架构的类比
处理分析过程如下：
•Samza客户端需要执行一个Samza作业时，它会向YARN的ResouceManager提交作业请求
•ResouceManager通过与NodeManager沟通为该作业分配容器（包含了CPU、内存等资源）来运行Samza ApplicationMaster
•Samza ApplicationMaster进一步向ResourceManager申请运行任务的容器
•获得容器后，Samza ApplicationMaster与容器所在的NodeManager沟通，启动该容器，并在其中运行Samza Task Runner
•Samza Task Runner负责执行具体的Samza任务，完成流数据处理分析
七、Storm、Spark Streaming和Samza的应用场景
•从编程的灵活性来讲，Storm是比较理想的选择，它使用Apache Thrift，可以用任何编程语言来编写拓扑结构（Topology）
•当需要在一个集群中把流计算和图计算、机器学习、SQL查询分析等进行结合时，可以选择Spark Streaming，因为，在Spark上可以统一部署Spark SQL，Spark Streaming、MLlib，GraphX等组件，提供便捷的一体化编程模型
•当有大量的状态需要处理时，比如每个分区都有数十亿个元组，则可以选择Samza。当应用场景需要毫秒级响应时，可以选择Storm和Samza，因为Spark Streaming无法实现毫秒级的流计算
八、总结
• 流数据即持续到达的大量数据，对流数据的处理强调实时性，一般要求为秒级。MapReduce框架虽然广泛应用于大数据处理中，但其面向的是海量数据的离线处理，并不适合用于处理持续到达的流数据
• 流计算的处理流程，一般包括数据实时采集、数据实时计算和实时查询服务三个部分，并比较其与传统的数据处理流程的不同。流计算处理的是实时数据，而传统的批处理则处理的是预先存储好的静态数据
• 流计算可应用在多个场景中，如实时业务分析，流计算带来的实时性特点，可以大大增加实时数据的价值，为业务分析带来质的提升
• Storm流处理框架具有可扩展性、高容错性、能可靠地处理消息的特点，使用简单，学习和开发成本较低。Storm框架对设计概念进行了抽象化，其主要术语包括Streams、Spouts、Bolts、Topology和Stream Groupings，在Topology中定义整体任务的处理逻辑，再通过Bolt具体执行，Stream Groupings则定义了Tuple如何在不同组件间进行传输，通过一个单词统计的实例来加深对Storm框架的了解
九、参考资料
《大数据技术原理与应用——概念、存储、处理、分析与应用（第二版）》
