Apache Tez—对MapReduce数据处理的归纳

在最近的一篇InfoQ文章中曾讨论过，Hortonworks新的Stinger Initiative非常依赖Tez——一个全新Hadoop数据处理框架。

博客文章Apache Tez:Hadoop数据处理的新篇章中写道：

“诸如Hive和Pig等更高级别的数据处理应用，需要这样的一个执行框架：该框架能够用有效的方式，表达这些应用的复杂的查询逻辑，并且在执行查询时能够保证高性能。Apache Tez……给出了传统MapReduce的一种替代方案，让任务能够满足对快速响应时间和PB量级的极端吞吐量的需求。”

为了实现这一目标，Tez并没有将数据处理按照单任务建模，而是作为一种数据流图来处理：

……图中的顶点表示应用逻辑，而边则表示数据转移。丰富的数据流定义API，让用户能够用直观的方式表达复杂的查询逻辑。对于更高级别的声明式应用程序（如Hive和Pig）所生成的查询计划来说，这简直是一种天作之合……数据流管道可以被表示为单一的Tez任务，它会运行整个计算。而Tez负责将这个逻辑图扩展为任务的物理图，并执行它。

在Tez的顶点上，特定的用户逻辑以输入、处理器和输出模块的形式建模，输入和输出模块定义了输入和输出数据（包括格式、访问方法和位置），而处理器模块定义了数据转换逻辑——它可以用MapReduce任务或Reducer的形式表示。虽然Tez并不明确地强制要求任何数据格式的限制，但它需要输入、输出和处理器能够互相兼容。类似地，由一条边连接的输入/输出对，在格式/位置上必须是兼容的。

博客文章Apache Tez中的数据处理API，描绘了一套简单的Java API，用于表示数据处理的DAG（有向无环图）。该API包含三部分：

• DAG：定义了全体任务。用户为每个数据处理任务创建DAG对象。
• Vertex：定义了用户逻辑，以及执行该用户逻辑所需的资源与环境。用户为任务中的每一步创建Vertex对象，并将其添加到DAG。
• Edge：定义了生产者和消费者顶点之间的链接。用户创建Edge对象，用来连接生产者和消费者顶点。

Tez所定义的边属性，使其能够将用户任务实例化、配置其输入输出、恰当地调度它们，并定义任务之间的数据如何路由。Tez还支持通过指定用户指南、数据大小和资源，为每个顶点的执行定义其并发机制。

• 数据转移：定义了任务之间数据的路由选择。
  • 一对一：数据从第i个生产者任务路由到第i个消费者任务。
  • 广播：数据从一个生产者任务路由到所有消费者任务。
  • 散列：生产者任务以碎片的形式散播数据，而消费者任务收集碎片。来自各个生产者任务的第i块碎片，都会路由到第i个消费者任务。
• 调度：定义了一个消费者任务何时被设定为以下内容。
  • 顺序的：消费者任务被安排在某个生产者任务完成之后。
  • 并发的：消费者任务必须与某个生产者任务同时执行。
• 数据源：将某个任务输出的生命周期/可靠性定义为如下内容。
  • 持续的：在任务推出后，输入将依旧可用——它或许在之后被丢弃。
  • 持久可靠：输入将被可靠地存储，而且将永远可用。
  • 短暂的：输出仅在生产者任务运行过程中可用，

有关Tez架构的更多细节，请参阅Tez设计文档。

用数据流来表现数据处理的理念并不算新鲜——这正是Cascading的基础，而且许多使用Oozie的应用也实现了这一目的。相比之下，Tez的优势在于，将这一切都放在了一个单一的框架中，并针对资源管理（基于Apache Hadoop YARN）、数据传输和执行，对该框架进行了优化。此外，Tez的设计还提供了对可热插拔的顶点管理模块的支持，用来收集来自任务的相关信息，并在运行时改变数据流图，从而为了性能和资源使用进行优化。

查看英文原文：Apache Tez - a Generalization of the MapReduce Data Processing