处理工作流的输出
它不属于事务处理，也不是分析。它和分析⽐较接近，因为批处理通常会扫过输⼊数据集的绝⼤部分。然⽽MapReduce作业⼯作流与⽤于分析⽬的的SQL查询是不同的（参阅“Hadoop与分布式数据库的对⽐”）。批处理过程的输出通常不是报表，⽽是⼀些其他类型的结构。
建立搜索索引
如果索引的⽂档集合发⽣更改，⼀种选择是定期重跑整个索引⼯作流，并在完成后⽤新的索引⽂件批量替换以前的索引⽂件。如果只有少量的⽂档发⽣了变化，这种⽅法的计算成本可能会很⾼。但它的优点是索引过程很容易理解：⽂档进，索引出。
键值存储作为批处理输出
构建这些数据库⽂件是MapReduce的⼀种很好⽤法的使⽤⽅法：使⽤Mapper提取出键并按该键排序，现在已经是构建索引所必需的⼤量⼯作。由于这些键值存储⼤多都是只读的（⽂件只能由批处理作业⼀次性写⼊，然后就不可变），所以数据结构⾮常简单。
批处理输出的哲学
在这些领域，在Unix上表现良好的设计原则似乎也适⽤于Hadoop，但Unix和Hadoop在某些⽅⾯也有所不同。例如，因为⼤多数Unix⼯具都假设输⼊输出是⽆类型⽂本⽂件，所以它们必须做⼤量的输⼊解析⼯作
hadoop 与分布式数据库的对比
最⼤的区别是，MPP数据库专注于在⼀组机器上并⾏执⾏分析SQL查询，⽽MapReduce和分布式⽂件系统【19】的组合则更像是⼀个可以运⾏任意程序的通⽤操作系统。
存储多样性
事务处理系统中的数据以某种原始形式转储到分布式⽂件系统中，然后编写MapReduce作业来清理数据，将其转换为关系形式，并将其导⼊MPP数据仓库以进⾏分析。数据建模仍然在进⾏，但它在⼀个单独的步骤中进⾏，与数据收集相解耦。这种解耦是可⾏的，因为分布式⽂件系统⽀持以任何格式编码的数据。
处理模型多样性
针对频繁故障设计
这就是MapReduce被设计为容忍频繁意外任务终⽌的原因：不是因为硬件很不可靠，⽽是因为任意终⽌进程的⾃由有利于提⾼计算集群中的资源利⽤率。
MapReduce 之后
但是，MapReduce执⾏模型本身也存在⼀些问题，这些问题并没有通过增加另⼀个抽象层次⽽解决，⽽对于某些类型的处理，它表现得⾮常差劲。⼀⽅⾯，MapReduce⾮常稳健：你可以使⽤它在任务会频繁终⽌的多租户系统上处理⼏乎任意⼤量级的数据，并且仍然可以完成⼯作（虽然速度很慢）。另⼀⽅⾯，对于某些类型的处理⽽⾔，其他⼯具有时会快上⼏个数量级。
物化中间状态
将这个中间状态写⼊⽂件的过程称为物化
数据流引擎
由于它们将⼯作流显式建模为数据从⼏个处理阶段穿过，所以这些系统被称为数据流引擎。
容错
关于物化的讨论
当作业完成时，它的输出需要持续到某个地⽅，以便⽤户可以找到并使⽤它—— 很可能它会再次写⼊分布式⽂件系统。因此，在使⽤数据流引擎时，HDFS上的物化数据集通常仍是作业的输⼊和最终输出。和MapReduce⼀样，输⼊是不可变的，输出被完全替换。⽐起MapReduce的改进是，你不⽤再⾃⼰去将中间状态写⼊⽂件系统了。
图与迭代处理
pregel 处理模型
这与Actor模型有些相似（参阅“分布式的Actor框架”），除了顶点状态和顶点之间的消息具有容错性和耐久性，且通信以固定的⽅式进⾏：在每次迭代中，框架递送上次迭代中发送的所有消息。Actor通常没有这样的时间保证。
并行处理
如果图太⼤，不适合单机处理，那么像Pregel这样的分布式⽅法是不可避免的。⾼效的并⾏图算法是⼀个进⾏中的研究领域
高级 API 和语言
除了少写代码的明显优势之外，这些⾼级接⼝还⽀持交互式⽤法，在这种交互式使⽤中，你可以在Shell中增量式编写分析代码，频繁运⾏来观察它做了什么。这种开发⻛格在探索数据集和试验处理⽅法时⾮常有⽤。这也让⼈联想到Unix哲学，我们在“Unix哲学”中讨论过这个问题。
