斯坦福的MapReduce
MapReduce是由google首先提出来的编程模型（介绍点击这里），专为数据密集型任务而设计。不论是google还是hadoop，都是将MapReduce应用在大规模集群下的。那么它是否适共享内存环境呢？斯坦福的Phoenix项目做出了回答。相关的论文发表在HPCA’07（最佳论文）和MapReduce’11上。
Phoenix适合于共享内存的多处理器计算机（SMP和ccNUMA），以及多核计算机。07年释出第一个版本Phoenix；后经过了大量修改，Phoenix 2在可扩展性和移植性方面得到加强，支持Linux；Phoenix++是Phoenix的C++实现。目前Phoenix只支持x86-64和Spark CPU_V9两种体系结构，不支持32位额。
官网下载的压缩包除了有框架源码，还有论文里的试验数据集和测试方法。Great！
为了证明Phoenix可以适应任何共享内存系统，实验使用两台截然不同的计算机，CMP和SMP。如表3所示。CMP是多核环境，8个4线程核心；SMP是对称多处理器环境，24个单核CPU。
实验还测试了8种应用，分别是：
图2显示了当不断增加核心数量，Phoenix的性能如何增长。纵坐标是加速比，参照物是顺序执行代码。在CMP，为每个核心分配4个worker来利用其4线程特性，因此8核的性能加速比远远超过了8。在不同应用，不同硬件配置下，Phoenix都显示出了极大性能提升。有些应用甚至出现了超线性增长，比如Maxtrix Multiply，原因是更好地利用了缓存。当核心数量过多时，SMP计算机会因为总线的限制而出现性能下降。
MapReduce的键值对结构非常适合Word Count、Matrix Multiply、String Match和Linear Regression。因此这些应用的提速非常明显。而K-means、PCA和Histogram不太适合用键值结构描述，因此总体增速较低。
图4是8核CMP环境下，Phoenix的性能与数据集大小的关系。每种应用都提供了大中小三种数据集。SMP与此类似。很清楚，增大数据集有助于提高Phoenix的加速比。首先，大数据集使得任务管理等开销变得微不足道；其次，缓存更有效，负载更均衡。
输入数据会被划分为N份，数据单元分得越小，Map任务越多。图5所示，将单元大小从4KB调整到128KB，对应的CMP加速比变化。大部分应用能适应各种单元大小。大的单元可以减少分配任务和合并结果的开销，Histogram是例子。有短期时间局部性的应用，则更喜欢小数据单元。
图6比较了Phoenix与原汁原味pthreads程序。有五个应用，Phoenix表现和pthreads差不多，甚至还要好一些。而三个不适合MapReduce模型的应用（K-means、PCA、Histogram），pthreads的性能明显要好。K-means迭代调用MapReduce，两次执行之间需要将输出转换为输入格式，开销很大。
一个良好实现的MapReduce，对于某些类型的计算很有吸引力。当然，最大的优点还是编程简单。不过，MapReduce也并不是适合所有计算。
MapReduce有专门的故障修复机制，比如google的MapReduce，每次完成一个作业，剩余作业都会被重新分配执行。而Phoenix根据超时来判断任务是否出错，已完成任务花费的时间将作为超时的标准，出错的任务会被重新执行。图7显示了注入故障对性能的影响。
永久错误指的是故意让一个核心“挂掉”，瞬时错误指的是故意让一次作业“挂掉”。图7可见Phoenix面对两种错误都能正确完成任务。永久错误对性能影响较大，而1到2个瞬时错误对性能几乎没有影响。
[1] Evaluating MapReduce for Multi-core and Multiprocessor Systems. In proceedings of HPCA’07.
[2] Phoenix. http://mapreduce.stanford.edu/
Phoenix适合于共享内存的多处理器计算机（SMP和ccNUMA），以及多核计算机。07年释出第一个版本Phoenix；后经过了大量修改，Phoenix 2在可扩展性和移植性方面得到加强，支持Linux；Phoenix++是Phoenix的C++实现。目前Phoenix只支持x86-64和Spark CPU_V9两种体系结构，不支持32位额。
官网下载的压缩包除了有框架源码，还有论文里的试验数据集和测试方法。Great！
1. 实验方法
为了证明Phoenix可以适应任何共享内存系统，实验使用两台截然不同的计算机，CMP和SMP。如表3所示。CMP是多核环境，8个4线程核心；SMP是对称多处理器环境，24个单核CPU。
实验还测试了8种应用，分别是：
- Word Count：统计文件集的词频。
- Reverse Index：遍历html，统计链接，将引用了同一链接的网页组成链表。
- Matrix Multiply：矩阵乘法，每个Map函数负责结果矩阵中若干行的计算，返回的结果以坐标为键，计算结果为值。
- String Match：处理两个文件，一个是加密后文件，包含了一系列加密的单词；一个是明文文件，包含一个明文单词列表。目标是找出明文文件里哪些单词出现在加密文件中。每个Map函数负责一部分的明文单词，中间值以单词为键，匹配标记为值。
- KMeans：实现了k-means问题的一个流行算法，算法不懂，已知的是需要迭代使用Phoenix。
- PCA：主成分分析（Principal Component Analysis），算法不懂，已知需要迭代两次Phoenix。
- Histogram：分析一副位图，计算每个像素出现的频率，每个Map处理一部分位图。
- Linear Regression：线性规划，根据坐标集画出近似直线。将点分配给不同的map函数，统计之后交由reduce汇总。
2. 基本性能测试
图2显示了当不断增加核心数量，Phoenix的性能如何增长。纵坐标是加速比，参照物是顺序执行代码。在CMP，为每个核心分配4个worker来利用其4线程特性，因此8核的性能加速比远远超过了8。在不同应用，不同硬件配置下，Phoenix都显示出了极大性能提升。有些应用甚至出现了超线性增长，比如Maxtrix Multiply，原因是更好地利用了缓存。当核心数量过多时，SMP计算机会因为总线的限制而出现性能下降。
MapReduce的键值对结构非常适合Word Count、Matrix Multiply、String Match和Linear Regression。因此这些应用的提速非常明显。而K-means、PCA和Histogram不太适合用键值结构描述，因此总体增速较低。
3. 性能与数据集大小的关系
图4是8核CMP环境下，Phoenix的性能与数据集大小的关系。每种应用都提供了大中小三种数据集。SMP与此类似。很清楚，增大数据集有助于提高Phoenix的加速比。首先，大数据集使得任务管理等开销变得微不足道；其次，缓存更有效，负载更均衡。
4. 性能与输入数据单元大小的关系
输入数据会被划分为N份，数据单元分得越小，Map任务越多。图5所示，将单元大小从4KB调整到128KB，对应的CMP加速比变化。大部分应用能适应各种单元大小。大的单元可以减少分配任务和合并结果的开销，Histogram是例子。有短期时间局部性的应用，则更喜欢小数据单元。
5. 与pthreads比较
图6比较了Phoenix与原汁原味pthreads程序。有五个应用，Phoenix表现和pthreads差不多，甚至还要好一些。而三个不适合MapReduce模型的应用（K-means、PCA、Histogram），pthreads的性能明显要好。K-means迭代调用MapReduce，两次执行之间需要将输出转换为输入格式，开销很大。
一个良好实现的MapReduce，对于某些类型的计算很有吸引力。当然，最大的优点还是编程简单。不过，MapReduce也并不是适合所有计算。
6. 故障修复
MapReduce有专门的故障修复机制，比如google的MapReduce，每次完成一个作业，剩余作业都会被重新分配执行。而Phoenix根据超时来判断任务是否出错，已完成任务花费的时间将作为超时的标准，出错的任务会被重新执行。图7显示了注入故障对性能的影响。
永久错误指的是故意让一个核心“挂掉”，瞬时错误指的是故意让一次作业“挂掉”。图7可见Phoenix面对两种错误都能正确完成任务。永久错误对性能影响较大，而1到2个瞬时错误对性能几乎没有影响。
7. 参考文献
[1] Evaluating MapReduce for Multi-core and Multiprocessor Systems. In proceedings of HPCA’07.
[2] Phoenix. http://mapreduce.stanford.edu/
浙公网安备 33010602011771号