Google MapReduce 论文提到的单词计数的例子相当于这一编程实践的"hello world"l ,MapReduce 还可以解决什么问题?又有什么最佳实践和陷阱?
MapReduce Design Patterns 和OOP Design Patterns 有类似的产生原因和好处:反复解决问题->发现问题共性-> 模版化描述 -> 方便交流 知识传递.书里面例子全部使用Hadoop实现,即使你不使用Hadoop也太不影响你的理解.
Summarization Patterns
总结归纳模式
相同Key的数据分组汇聚是MapReduce核心,所以总结归纳模式是最容易想到的,书中提到了数值归纳,倒排索引的例子.单词计数就是这类应用的典型,计算过程中高度并行化,Map阶段产出的数据行是信息完备的,后续阶段计算不需要参考其它数据行;这就保证了计算是可以并行实施:不依赖其它数据行,不依赖计算顺序.
中值,均值,标准差,最大值,最小值,倒排索引都可以如法炮制;
Filtering Patterns
过滤模式
这一类模式作用是寻找一个小数据集,这个小数据集合可能是取Top,做Distinct,做filtering 或者Bloom filtering. 直接做Filtering应该是这些模式里面最简单的,每条记录都做一下去留判断,Reduce的过程都没有.但这确有非常经典的应用案例:Distributed grep
Data Organization Patterns
数据重组模式
Structured to Hierarchical 由于只是改变的数据的视图,Combiner帮不了多少忙; 行结构数据外键关联,这样的数据结构构造成类似XML或BSON的结构.
Partitioning 移动数据,并不关心数据的顺序,书中的例子就很典型:3年的日志数据并不是日期排序,取一段时间数据,如果数据按照时间分区,就可以避免全表扫描.如果是按照月分区,该分区内数据顺序并不重要.
Binning 和 Partitioning 的区别在于它是将同一条数据分到一个或多个类别.
Total Order Sorting 整体并行排序,善用Partitioner重定结果,说起来简单实际操作过程中要注意的细节还是非常多的.
Shuffling 除了书中提到的"隐藏用户信息" "随机取样"还有什么使用场景?好奇
Join Patterns
Join模式
Reduce Side Join 将数据映射为外键为Key的形式,在Reduce阶段完成Join. 大量数据发送到Reduce Reduce端join需要大量的网络传输 .如果并不太关注执行时间 就可以用它. 如果要join的数据非常巨大,就只能选这种join.join是在reduce完成,Local优化起不了什么作用
Replicated Join 解决的是Join数据集规模不对称的情况,把小数据集分发出去,消除了Reduce阶段的Shuffle.
