Beyond MapReduce

尽管 MapReduce 在 2000 年以後很夯，但它毕竟是分散式系统中诸多程序框架中的其中一种，取决於数据量、数据结构和数据处理的类型，你还有其他更适合的工具可以使用。

MapReduce 是个很有用的学习工具，因为它是分散式系统上一个清楚和简单的抽象，但是，易於理解不代表易於使用，用原生 MapReduce API 实现一个能动的 job 相当费力，就像你不会想从头实现 join 算法一样。

所以今天就来看看，除了 MapReduce 外还有哪些批次处理工具吧。

中介状态的实体化 (Materialization of Intermediate State)

如同前几天讨论的那般，每一个 MapReduce 的 job 都是独立的，有依赖关系之 job 的唯一接触点是资料位置，第 2 个 job 的输入是第 1 个 job 的输出，所以有些工程师会仰赖外部工具来安排所有 MapReduce job 的调度。

然而在大多数的情况下，job 的输出只会被另一个 job 来使用，所以分散式档案系统上很多资料都处於 中介状态 (intermediate state)，在一个使用 50 ~ 100 个 MapReduce job 的推荐引擎 workflow 下，其中介状态资料的数量可以很惊人。

相比之下，Day 23 示范的用 Unix 工具分析 log 的例子就没有这问题，管线命令 (pipe) 不会完整的实体化 (materialize) 中介状态，而是以逐渐增量的方式，将输出串流到输入，而仅使用一个小的记忆体缓冲区。

跟 Unix 工具相比，MapReduce 这种完全实体化中介状态的方法有以下缺点：

• 一个 MapReudce job 需要等前面的 job 执行完才会开始，如果发生 Day 25 讲的 倾斜 (skew) 就会拖慢 job 处理速度。
• mapper 通常是多余的，在某些案例下，你直接把 reducer 的输出当做下一次 reudcer 的输入会更快，省得用 mapper 再读入一次，然後再做一次一样的排序跟分区。
• 中介状态的资料还是会被分散式档案系统做副本到多个节点上，但其实不需要。

数据流引擎

感谢这些大神，我们有数个工具框架可以解决 MapReduce 的这些问题，像 Spark、Tez 和 Flink，尽管它们设计的方法不样，但有一点是相同的：它们能将整个 workflow 视为单一个 job，而不是细分到多个 subjob。

因为它们将数据流拆成多个处理阶段，所以也被称为 数据流引擎 (dataflow engines)。

就像 MapReduce 那样，它们会重复的呼叫 user-defined 函数来处理一条条的数据，也能在多个分区输入中并行执行，并透过网路让输出成为下个函数的输入。

不像 MapReduce 的是，这些函数并不会严格的把角色区分成 map 和 reduce，而是以更灵活的方式组装，我们称这些函数为 operator，数据流引擎提供多个选项连接这些 operator：

• 一个选项是做 重新分区 (repartition) 和以 key 做排序，就像 Day 24 的 MapReduce shuffle 一样。
• 另一个选项是一次读取多个输入并以同样的方法做分区，但跳过排序，这节省了做 Partitioned hash joins 的力气，排序对 hash table 的建立没有任何影响。
• 对於 Broadcast hash joins，来自同一个 operator 的输出可以发送到 join operator 的所有分区。

你能使用数据流引擎建立跟 MapReudce 一样的 workflow，而且执行的较快。