大数据技术原理与应用5Spark、流计算、图计算

第10讲 Spark

10.1 Spark概述

10.1.1 Spark简介

•Spark最初由美国加州伯克利大学（UCBerkeley）的AMP实验室于 2009年开发，是基于内存计算的大数据并行计算框架，可用于构建大 型的、低延迟的数据分析应用程序
•2013年Spark加入Apache孵化器项目后发展迅猛，如今已成为Apache 软件基金会最重要的三大分布式计算系统开源项目之一（Hadoop、 Spark、Storm）
Hadoop进行批量数据离线处理MapReduce负责批处理
Spark基于内存的实时数据分析框架
Storm数据流分析框架
•Spark在2014年打破了Hadoop保持的基准排序纪录
Spark/206个节点/23分钟/100TB数据
Hadoop/2000个节点/72分钟/100TB数据
Spark用十分之一的计算资源，获得了比Hadoop快3倍的速度

Spark具有如下几个主要特点：
•运行速度快：使用DAG执行引擎以支持循环数据流与内存计算
•容易使用：支持使用Scala、Java、Python和R语言进行编程，可以通过Spark Shell进行交互式编程
•通用性：Spark提供了完整而强大的技术栈，包括SQL查询、流式计算 、机器学习和图算法组件
•运行模式多样：可运行于独立的集群模式中，可运行于Hadoop中，也可运行于Amazon EC2等云环境中，并且可以访问HDFS、Cassandra、 HBase、Hive等多种数据源

Spark如今已吸引了国内外各大公司的注意，如腾讯、淘宝、百度、亚马 逊等公司均不同程度地使用了Spark来构建大数据分析应用，并应用到实际的生产环境中

10.1.2 Scala简介

Scala是一门现代的多范式编程语言，运行于Java平台（JVM，Java 虚拟机），并兼容现有的Java程序 。集成了面向对象和函数式编程的特点。
Scala的特性：
•Scala具备强大的并发性，支持函数式编程，可以更好地支持分布式系统
•Scala语法简洁，能提供优雅的API Scala兼容Java，运行速度快，且能融合到Hadoop生态圈中

Scala是Spark的主要编程语言，但Spark还支持Java、Python、R 作为编程语言
Scala的优势是提供了REPL（Read-Eval-Print Loop，交互式解释器），提高程序开发效率

10.1.3 Spark与Hadoop的比较

Hadoop存在如下一些缺点：
•表达能力有限。并不是所有的应用都能抽象成map和reduce函数
•磁盘IO开销大 。尤其是在完成迭代操作时。
•延迟高
任务之间的衔接涉及IO开销
在前一个任务执行完成之前，其他任务就无法开始， 难以胜任复杂、多阶段的计算任务

Spark在借鉴Hadoop MapReduce优点的同时，很好地解决了 MapReduce所面临的问题
相比于Hadoop MapReduce，Spark主要具有如下优点：
•Spark的计算模式也属于MapReduce，但不局限于Map和Reduce操作，还提供了多种数据集操作类型，编程模型比Hadoop MapReduce更灵活
•Spark提供了内存计算，可将中间结果放到内存中，对于迭代运算效率更高
Spark基于DAG的任务调度执行机制，要优于Hadoop MapReduce的迭代执行机制


•使用Hadoop进行迭代计算非常耗资源
•Spark将数据载入内存后，之后的迭代计算都可以直接使用内存中的中间 结果作运算，避免了从磁盘中频繁读取数据

10.2 Spark生态系统

在实际应用中，大数据处理主要包括以下三个类型：
•复杂的批量数据处理：通常时间跨度在数十分钟到数小时之间
•基于历史数据的交互式查询：通常时间跨度在数十秒到数分钟之间
•基于实时数据流的数据处理：通常时间跨度在数百毫秒到数秒之间
当同时存在以上三种场景时，就需要同时部署三种不同的软件
•比如: MapReduce / Impala / Storm

这样做难免会带来一些问题：
•不同场景之间输入输出数据无法做到无缝共享，通常需要进行数据格式的转换
•不同的软件需要不同的开发和维护团队，带来了较高的使用成本
•比较难以对同一个集群中的各个系统进行统一的资源协调和分配

•Spark的设计遵循“一个软件栈满足不同应用场景”的理念，逐渐形成了一套完整的生态系统
•既能够提供内存计算框架，也可以支持SQL即时查询、实时流式计 算、机器学习和图计算等
•Spark可以部署在资源管理器YARN之上，提供一站式的大数据解决方案
•因此，Spark所提供的生态系统足以应对上述三种场景，即同时支持批处理、交互式查询和流数据处理

Spark生态系统已经成为伯克利数据分析软件栈BDAS（Berkeley Data Analytics Stack）的重要组成部分
Spark的生态系统主要包含了Spark Core、Spark SQL、Spark Streaming、 MLLib和GraphX 等组件
提供内存计算、交互式查询分析、流计算、机器学习算法、图计算

10.3 Spark运行架构

10.3.1 基本概念

•RDD：是Resillient Distributed Dataset（弹性分布式数据集）的简称，是分布式内存的一个抽象概念，提供了一种高度受限的共享内存模型
•DAG：是Directed Acyclic Graph（有向无环图）的简称，反映RDD之间的依赖关系
•Executor：是运行在工作节点（WorkerNode）的一个进程，负责运行Task
•Application：用户编写的Spark应用程序
•Task：运行在Executor上的工作单元
•Job：一个Job包含多个RDD及作用于相应RDD上的各种操作
•Stage：是Job的基本调度单位，一个Job会分为多组Task，每组Task被称为 Stage，或者也被称为TaskSet，代表了一组关联的、相互之间没有Shuffle依赖关系的任务组成的任务集

Spark运行架构包括集群资源管理器（Cluster Manager）、运行作业任务的工作节点 （Worker Node）、每个应用的任务控制节点（Driver）和每个工作节点上负责具体任务的执行进程（Executor）

•资源管理器可以自带或Mesos或YARN

与Hadoop MapReduce计算框架相比，Spark所采用的Executor有两个优点：
•一是利用多线程来执行具体的任务，减少任务的启动开销
•二是Executor中有一个BlockManager存储模块，会将内存和磁盘共同作为存储设备， 有效减少IO开销

10.3.2 架构设计

•一个Application由一个Driver和若干个Job构成，一个Job由多个Stage构成，一个 Stage由多个没有Shuffle关系的Task组成

•当执行一个Application时，Driver会向集群管理器申请资源，启动Executor，并向 Executor发送应用程序代码和文件，然后在Executor上执行Task，运行结束后，执行 结果会返回给Driver，或者写到HDFS或者其他数据库中

10.3.3 Spark运行基本流程

（1）首先为应用构建起基本的运行环境，即由Driver创建一个SparkContext， 进行资源的申请、任务的分配和监控
（2）资源管理器为Executor分配资源， 并启动Executor进程
（3）SparkContext根据RDD的依赖关系构建DAG图，DAG图提交给 DAGScheduler解析成Stage，然后把一个个TaskSet提交给底层调度器 TaskScheduler处理；Executor向 SparkContext申请Task，Task Scheduler 将Task发放给Executor运行，并提供应用程序代码
（4）Task在Executor上运行，把执行结果反馈给TaskScheduler，然后反馈给 DAGScheduler，运行完毕后写入数据并释放所有资源

总体而言，Spark运行架构具有以下特点：
（1）每个Application都有自己专属的Executor进程，并且该进程在Application运行期间一直驻留。Executor进程以多线程的方式运行Task
（2）Spark运行过程与资源管理器无关，只要能够获取 Executor进程并保持通信即可
（3）Task采用了数据本地性和推测执行等优化机制

10.3.4 Spark运行原理

1.设计背景

•许多迭代式算法（比如机器学习、图算法等）和交互式数据挖掘工具，共同之处是，不同计算阶段之间会重用中间结果
•目前的MapReduce框架都是把中间结果写入到HDFS中，带来了大量的数据复制、磁盘IO和序列化开销
•RDD就是为了满足这种需求而出现的，它提供了一个抽象的数据架构，我们不必担心底层数据的分布式特性，只需将具体的应用逻辑表达为一系列转换处理，不同RDD之间的转换操作形成依赖关系，可以实现管道化，避免中间数据存储

2.RDD概念

•一个RDD就是一个分布式对象集合，本质上是一个只读的分区记录集合，每个RDD可分成多个分区，每个分区就是一个数据集片段，并且一 个RDD的不同分区可以被保存到集群中不同的节点上，从而可以在集群中的不同节点上进行并行计算
•RDD提供了一种高度受限的共享内存模型，即RDD是只读的记录分区的集合，不能直接修改，只能基于稳定的物理存储中的数据集创建RDD， 或者通过在其他RDD上执行确定的转换操作（如map、join和group by） 而创建得到新的RDD

•RDD提供了一组丰富的操作以支持常见的数据运算，分为**“动作” （Action）**和“转换”（Transformation）两种类型
•RDD提供的转换接口都非常简单，都是类似map、filter、groupBy、join 等粗粒度的数据转换操作，而不是针对某个数据项的细粒度修改（不适合网页爬虫）
•表面上RDD的功能很受限、不够强大，实际上RDD已经被实践证明可以高效地表达许多框架的编程模型（比如MapReduce、SQL、Pregel）
•Spark用Scala语言实现了RDD的API，程序员可以通过调用API实现对RDD的各种操作

RDD典型的执行过程如下：

•RDD读入外部数据源进行创建
•RDD经过一系列的转换（Transformation）操作，每一次都会产生不同的RDD，供给下一个转换操作使用
•最后一个RDD经过“动作”操作进行转换，并输出到外部数据源
这一系列处理称为一个Lineage（血缘关系），即DAG拓扑排序的结果
优点：惰性调用、管道化、避免同步等待、不需要保存中间结果、每次操作变得简单

3.RDD特性

Spark采用RDD以后能够实现高效计算的原因主要在于：
（1）高效的容错性
•现有容错机制：数据复制或者记录日志
•RDD：血缘关系、重新计算丢失分区、无需回滚系统、重算过程在不同节点之间并行、只记录粗粒度的操作
（2）中间结果持久化到内存，数据在内存中的多个RDD操作之间进行传递，避免了不必要的读写磁盘开销
（3）存放的数据可以是Java对象，避免了不必要的对象序列化和反序列化

4.RDD之间的依赖关系

•窄依赖表现为一个父RDD的分区对应于一个子RDD的分区或多个父RDD的分区对应于一个子RDD的分区
•宽依赖则表现为存在一个父RDD的一个分区对应一个子RDD的多个分区

5.Stage的划分

Spark通过分析各个RDD的依赖关系生成了DAG，再通过分析各个RDD 中的分区之间的依赖关系来决定如何划分Stage，具体划分方法是：
•在DAG中进行反向解析，遇到宽依赖就断开
•遇到窄依赖就把当前的RDD加入到Stage中
•将窄依赖尽量划分在同一个Stage中，可以实现流水线计算

被分成三个Stage，在Stage2中，从map到union都是窄依赖，这两步操作可以形成一个流水线操作
流水线操作实例：分区7通过map操作生成的分区9， 可以不用等待分区8到分区10这个map操作的计算结束，而是继续进行union操作， 得到分区13，这样流水线执行大大提高了计算的效率

Stage的类型包括两种：ShuffleMapStage和ResultStage，具体如下：
（1）ShuffleMapStage：不是最终的Stage，在它之后还有其他Stage， 所以，它的输出一定需要经过Shuffle过程，并作为后续Stage的输入；
这种Stage是以Shuffle为输出边界，其输入边界可以是从外部获取数据，也可以是另一个ShuffleMapStage的输出，其输出可以是另一个Stage的开始；
在一个Job里可能有该类型的Stage，也可能没有该类型Stage；
（2）ResultStage：最终的Stage，没有输出，而是直接产生结果或存储。
这种Stage是直接输出结果，其输入边界可以是从外部获取数据，也可以 是另一个ShuffleMapStage的输出。
在一个Job里必定有该类型Stage。
因此，一个Job含有一个或多个Stage，其中至少含有一个ResultStage。

6.RDD运行过程

通过上述对RDD概念、依赖关系和Stage划分的介绍，结合之前介绍的Spark运行 基本流程，再总结一下RDD在Spark架构中的运行过程：
（1）创建RDD对象；
（2）SparkContext负责计算RDD之间的依赖关系，构建DAG；
（3）DAGScheduler负责把DAG图分解成多个Stage，每个Stage中包含了多个 Task，每个Task会被TaskScheduler分发给各个WorkerNode上的Executor去执 行。

10.4 Spark SQL

10.4.1 从Shark说起

•Shark即Hive on Spark，为了实现与Hive兼容， Shark在HiveQL方面重用了Hive中HiveQL的解 析、逻辑执行计划翻译、执行计划优化等逻辑， 可以近似认为仅将物理执行计划从MapReduce作业替换成了Spark作业，通过Hive的HiveQL解 析，把HiveQL翻译成Spark上的RDD操作。
•Shark的设计导致了两个问题：
一是执行计划优化完全依赖于Hive，不方便 添加新的优化策略；
二是因为Spark是线程级并行，而 MapReduce是进程级并行，因此，Spark在兼容Hive的实现上存在线程安全问题，导致 Shark不得不使用另外一套独立维护的打了补丁的Hive源码分支 ·

10.4.2 Spark SQL设计

Spark SQL在Hive兼容层面仅依赖HiveQL解析、Hive元数据，也就是说，从 HQL被解析成抽象语法树（AST）起，就全部由Spark SQL接管了。Spark SQL执行计划生成和优化都由Catalyst（函数式关系查询优化框架）负责

•Spark SQL增加了SchemaRDD（即带有Schema信息的RDD），使用户可 以在Spark SQL中执行SQL语句，数据既可以来自RDD，也可以是Hive、 HDFS、Cassandra等外部数据源，还可以是JSON格式的数据
•Spark SQL目前支持Scala、Java、Python三种语言，支持SQL-92规范

10.5 Spark的部署和应用方式

10.5.1 Spark三种部署方式

Spark支持三种不同类型的部署方式，包括：
•Standalone（类似于MapReduce1.0，slot为资源分配单位）
•Spark on Mesos（和Spark有血缘关系，更好支持Mesos）
•Spark on YARN

10.5.2 从Hadoop+Storm架构转向Spark架构

用Spark架构具有如下优点：
•实现一键式安装和配置、线程级别 的任务监控和告警
•降低硬件集群、软件维护、任务监 控和应用开发的难度
•便于做成统一的硬件、计算平台资 源池

需要说明的是，Spark Streaming无 法实现毫秒级的流计算，因此，对 于需要毫秒级实时响应的企业应用 而言，仍然需要采用流计算框架 （如Storm）

10.5.3 Hadoop和Spark的统一部署

•由于Hadoop生态系统中的一些组件所实现的功能，目前还是无法由Spark 取代的，比如，Storm
•现有的Hadoop组件开发的应用，完全转移到Spark上需要一定的成本

不同的计算框架统一运行在YARN中，可以带来如下好处：
•计算资源按需伸缩
•不用负载应用混搭，集群利用率高
•共享底层存储，避免数据跨集群迁移

10.6 Spark编程实践

10.6.1 Spark安装

安装Spark之前需要安装Java环境和Hadoop环境。
•下载地址： http://spark.apache.org
进入下载页面后，点击主页右侧的“Download Spark”按钮进入下载页面，下载页面中提供了几个下载选项，主要是Spark release及Package type的选择，如下图所 示。
第1项Spark release一般默认选择最新的发行版本，如截止至2016年3月份的最 新版本为1.6.0。
第2项package type则选择“Pre-build with user-provided Hadoop [can use with most Hadoop distributions]”，可适用于多数Hadoop版本。选择好之 后，再点击第4项给出的链接就可以下载Spark了。

10.6.2 启动Spark Shell

10.6.3 Spark RDD基本操作

10.6.4 Spark应用程序

第11讲 流计算

11.1 流计算概述

11.1.1 静态数据和流数据

很多企业为了支持决策分析而构建的数据仓库系统，其中存放的大量 历史数据就是静态数据。技术人员可以利用数据挖掘和OLAP（OnLine Analytical Processing）分析工具从静态数据中找到对企业有价值的信息

• 近年来，在Web应用、网络监控、传感监测等领域，兴起了一种新的数据密集型应用——流数据，即数据以大量、快速、时变的流形式持续到达
• 实例：PM2.5检测、电子商务网站用户点击流
• 流数据具有如下特征：
– 数据快速持续到达，潜在大小也许是无穷无尽的
– 数据来源众多，格式复杂 – 数据量大，但是不十分关注存储，一旦经过处理，要么被丢弃， 要么被归档存储 – 注重数据的整体价值，不过分关注个别数据
– 数据顺序颠倒，或者不完整，系统无法控制将要处理的新到达的 数据元素的顺序

11.1.2 批量计算和实时计算

• 对静态数据和流数据的处理，对应着两种截然不同的计算模式：批量计算和实时计算

•批量计算：充裕时间处理静态数据， 如Hadoop
•流数据不适合采用批量计算，因为流数据不适合用传统的关系模型建模
•流数据必须采用实时计算，响应时间为秒级
•在大数据时代，数据格式复杂、来源 众多、数据量巨大，对实时计算提出 了很大的挑战。因此，针对流数据的 实时计算——流计算，应运而生

11.1.3 流计算概念

流计算：实时获取来自不同数据源的海量数据，经过实时分析处理，获得有价值的信息
• 流计算秉承一个基本理念，即数据的价值随着时间的流逝而降低， 如用户点击流。因此，当事件出现时就应该立即进行处理，而不是缓存起来进行批量处理。为了及时处理流数据，就需要一个低延迟、可扩展、高可靠的处理引擎
• 对于一个流计算系统来说，它应达到如下需求： – 高性能 – 海量式 – 实时性 – 分布式 – 易用性 – 可靠性

11.1.4 流计算与Hadoop

• Hadoop设计的初衷是面向大规模数据的批量处理
• MapReduce是专门面向静态数据的批量处理的，内部各种实现机制都为批处理做了高度优化，不适合用于处理持续到达的动态数据
• 可能会想到一种“变通”的方案来降低批处理的时间延迟——将基于 MapReduce的批量处理转为小批量处理，将输入数据切成小的片段 ，每隔一个周期就启动一次MapReduce作业。但这种方式也无法有效处理流数据
– 切分成小片段，可以降低延迟，但是也增加了附加开销，还要处理片段之间依赖关系
– 需要改造MapReduce以支持流式处理

结论：鱼和熊掌不可兼得，Hadoop擅长批处理，不适合流计算

11.1.5 流计算框架

• 当前业界诞生了许多专门的流数据实时计算系统来满足各自需求
• 商业级：IBM InfoSphere Streams和IBM StreamBase
• 开源流计算框架
– Twitter Storm：免费、开源的分布式实时计算系统，可简单、高效、可 靠地处理大量的流数据
– Yahoo! S4（Simple Scalable Streaming System）：开源流计算平台， 是通用的、分布式的、可扩展的、分区容错的、可插拔的流式系统
• 公司为支持自身业务开发的流计算框架：
– Facebook Puma
– Dstream（百度）
– 银河流数据处理平台（淘宝）

11.2 流计算处理流程

11.2.1 概述

• 传统的数据处理流程，需要先采集数据并存储在关系数据库等数据管 理系统中，之后由用户通过查询操作和数据管理系统进行交互

• 传统的数据处理流程隐含了两个前提：
– 存储的数据是旧的。存储的静态数据是过去某一时刻的快照，这 些数据在查询时可能已不具备时效性了
– 需要用户主动发出查询来获取结果

流计算的处理流程一般包含三个阶段：数据实时采集、数据实时计算 、实时查询服务

11.2.2 数据实时采集

• 数据实时采集阶段通常采集多个数据源的海量数据，需要保证实时性 、低延迟与稳定可靠
• 以日志数据为例，由于分布式集群的广泛应用，数据分散存储在不同 的机器上，因此需要实时汇总来自不同机器上的日志数据
• 目前有许多互联网公司发布的开源分布式日志采集系统均可满足每秒 数百MB的数据采集和传输需求，如：
– Facebook的Scribe
– LinkedIn的Kafka
– 淘宝的Time Tunnel
– 基于Hadoop的Chukwa和Flume

• 数据采集系统的基本架构一般有以下三个部分：
– Agent：主动采集数据，并把数据推送到Collector部分
– Collector：接收多个Agent的数据，并实现有序、可靠、高性能的转发
– Store：存储Collector转发过来的数据（对于流计算不存储数据）

11.2.3 数据实时计算

• 数据实时计算阶段对采集的数据进行实时的分析和计算，并反馈实时 结果
• 经流处理系统处理后的数据，可视情况进行存储，以便之后再进行分 析计算。在时效性要求较高的场景中，处理之后的数据也可以直接丢弃

11.2.4 实时查询服务

• 实时查询服务：经由流计算框架得出的结果可供用户进行实时查询、 展示或储存
• 传统的数据处理流程，用户需要主动发出查询才能获得想要的结果。 而在流处理流程中，实时查询服务可以不断更新结果，并将用户所需 的结果实时推送给用户
• 虽然通过对传统的数据处理系统进行定时查询，也可以实现不断地更新结果和结果推送，但通过这样的方式获取的结果，仍然是根据过去某一时刻的数据得到的结果，与实时结果有着本质的区别

• 可见，流处理系统与传统的数据处理系统有如下不同：
– 流处理系统处理的是实时的数据，而传统的数据处理系统处理的 是预先存储好的静态数据
– 用户通过流处理系统获取的是实时结果，而通过传统的数据处理 系统，获取的是过去某一时刻的结果
– 流处理系统无需用户主动发出查询，实时查询服务可以主动将实时结果推送给用户

11.3 流计算的应用

• 流计算是针对流数据的实时计算，可以应用在多种场景中
• 如百度、淘宝等大型网站中，每天都会产生大量流数据， 包括用户的搜索内容、用户的浏览记录等数据。采用流计 算进行实时数据分析，可以了解每个时刻的流量变化情况 ，甚至可以分析用户的实时浏览轨迹，从而进行实时个性 化内容推荐
• 但是，并不是每个应用场景都需要用到流计算的。流计算 适合于需要处理持续到达的流数据、对数据处理有较高实 时性要求的场景

11.3.1 应用场景1: 实时分析

• 传统的业务分析一般采用分布式离线计算的方式，即将数据 全部保存起来，然后每隔一定的时间进行离线分析来得到结 果。但这样会导致一定的延时，难以保证结果的实时性
• 随着分析业务对实时性要求的提升，离线分析模式已经不适 合用于流数据的分析，也不适用于要求实时响应的互联网应 用场景
• 虽然分布式离线分析带来的小时级的分析延时可以满足大部 分商家的需求，但随着实时性要求越来越高，如何实现秒级 别的实时分析响应成为业务分析的一大挑战
• 针对流数据，“量子恒道”开发了海量数据实时流计算框架Super Mario。通过该框架，量子恒道可处理每天TB级的实时流数据，并且 从用户发出请求到数据展示，整个延时控制在2-3秒内，达到了实时 性的要求

11.3.1 应用场景2: 实时交通

• 流计算不仅为互联网带来改变，也能改变我们的生活
• 如提供导航路线，一般的导航路线并没有考虑实时的交通 状况，即便在计算路线时有考虑交通状况，往往也只是使 用了以往的交通状况数据。要达到根据实时交通状态进行 导航的效果，就需要获取海量的实时交通数据并进行实时 分析
• 借助于流计算的实时特性，不仅可以根据交通情况制定路 线，而且在行驶过程中，也可以根据交通情况的变化实时 更新路线，始终为用户提供最佳的行驶路线

11.4 开源流计算框架Storm

11.4.1 Storm简介

• 以前只有政府机构和金融机构能够通过昂贵的定制系统来满足流数据 实时分析计算需求
• 早期对于流计算的研究多数是基于对传统数据库处理的流式化，即实 时数据库，很少研究流计算框架
• Yahoo! S4和Twitter Storm的开源，改变了这个情况
• 在流数据处理上比MapReduce更有优势
• 批处理系统关注吞吐率，流处理系统关注延时
• Yahoo! S4和Twitter Storm改变了开发实时应用的方式
– 以前既要关注处理逻辑，还要解决实时数据获取、传输、存储
– 现在可以快速低成本搭建起实时流处理系统

• Twitter Storm是一个免费、开源的分布式实时计算系统， Storm对于实时计算的意义类似于Hadoop对于批处理的 意义，Storm可以简单、高效、可靠地处理流数据，并支 持多种编程语言
• Storm框架可以方便地与数据库系统进行整合，从而开发 出强大的实时计算系统
• Twitter是全球访问量最大的社交网站之一，Twitter开发Storm流处理 框架也是为了应对其不断增长的流数据实时处理需求

11.4.2 Storm的特点

• Storm可用于许多领域中，如实时分析、在线机器学习、持续计算、 远程RPC、数据提取加载转换等
• Storm具有以下主要特点： – 整合性 – 简易的API – 可扩展性 – 可靠的消息处理 – 支持各种编程语言 – 快速部署 – 免费、开源

11.4.3 Storm设计思想

11.4.4 Storm框架设计

11.5 Spark Streaming、Samza以及三种流计算框架的比较

11.6 Storm编程实践

第12讲 图计算

12.1 图计算简介

12.2 Pregel简介

12.3 Pregel图计算模型

12.4 Pregel的C++ API

12.5 Pregel的体系结构

12.6 Pregel的应用实例——单源最短路径

12.7 Hama的安装和使用

第13讲 大数据在不同领域的应用

13.1 大数据应用概览

13.2 推荐系统

13.3 大数据在智能医疗和智能物流领域运用