第五讲内存计算
为什么并行计算
• 计算量大
– 单进程算得不够快，多CPU算
• 内存需求大
– 单机内存不够大
– 内存随机访问比硬盘随机访问快100,000倍
• I/O量大
– 单个硬盘读写太慢，多个硬盘读写
并行计算的挑战
• 编程困难
– 并行性识别与表达，难写
– 同步语句，难写对
• 性能调优难，难写快
– 负载平衡
– 局部性
• 容错难

MapReduce的成功之处
• 用户只需要编写串行程序

• 自动并行化和分布式执行
• 自动容错
• 自动负载平衡
用户对系统提出了更高的要求
• 更复杂的多阶段任务
• 交互式查询
MapReduce的局限性
• 表达能力有限
– 只有Map和Reduce两种操作
• 复杂任务通常需要迭代的MapReduce
– 需要将中间结构保存在硬盘上
– 大量I/O操作造成性能急剧下降
• 引入的I/O操作多，只能做离线分析，很难支
持数据的交互式查询

如何抽象多台机器的内存？
• 分布式共享内存（DSM）
– 统一地址空间
– 很难容错
• 分布式键-值存储（Piccolo，RAMCloud）
– 允许细粒度访问
– 可以修改数据（mutable）
– 容错开销大
DSM和键值对的容错机制
• 副本或Log
– 对数据密集应用来说开销很大
– 比内存写要慢10-100倍
解决方案
• RDD（Resilient Distributed Datasets ）
– 基于数据集合，而不是单个数据
– 由确定性的粗粒度操作产生（map，filter，join等）
– 数据一旦产生，就不能修改（immutable）
– 如果要修改数据，要通过数据集的变换来产生新的数据集
高效的容错方法
• 数据一旦是确定性的产生，并且产生后不
会变化
– 就可以通过“重复计算”的方法来恢复数据
– 只要记住rdd的生成过程就可以了，这样一次log可以用
于很多数据，在不出错的时候几乎没有开销
messages = textFile(...).filter(_.contains(“error”))
                                .map(_.split(‘\t’)(2))
编程接口
• 基于Scala语言
– 类似Java的一种函数语言
– 可以在Scala控制台上交互式地使用Spark
– （现在也支持Java和Python）
• 基于RDD的操作
– Transformation：从现有RDD产生新的RDD
• map, filter, groupBy, sort,distinct, sample…
– Action: 从RDD返回一个值
• reduce，count, collect, first, foreach…，,
对需要重用的RDD使用Persist和
Cache提高性能
• 对messages使用cache,意思是将后面可能会重用的
数据保存起来，并“尽量”放到内存中
– 正常计算的时候避免重算
– Cache是Persist的特例

Spark的方法
• 将MapReduce一般化
– 任务DAG和数据共享
• 统一的编程框架有好处