在最近的一篇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
评论