Overview

Tez是基于 Hadoop Yarn 构建的新应用程序框架，可以执行常规数据处理任务的复杂有向无环图。在许多方面，可以将其视为 map-reduce 框架的更灵活，更强大的后继者。

它通过公开用于通用数据处理任务的接口来概括 Map 和归约任务，该接口由三 Tuples 接口组成：Importing，输出和处理器。这些任务是执行图中的顶点。边缘(即任务之间的数据连接)是 Tez 中的头等公民，并且与 Importing/输出接口一起极大地提高了任务之间数据传输方式的灵 Active。

Tez 还极大地扩展了将各个任务链接在一起的可能方式。实际上，任何任意 DAG 都可以直接在 Tez 中执行。

用 Tez 的话来说，Map 归约工作基本上是一个简单的 DAG，它由一个“Map”和由“二分”边(即：边将每个 Map 任务连接到每个归约任务)连接的缩小顶点组成。MapImporting 和归约输出分别是 HDFSImporting 和输出。Map 输出类按特定键在本地对数据进行排序和分区，而 reduceImporting 类在同一键上对数据进行合并排序。

Tez 还提供了一个基本的 map-reduce 兼容层，通过在新的执行框架上实现 Map/Reduce 概念，我们可以在新的执行层之上运行 MR 作业。

关于 Tez 的更多信息可以在这里找到：

• Tez 网站：http://tez.apache.org/

• Tez 设计文档：https://issues.apache.org/jira/browse/TEZ-65

• Tez 演示文稿：http://www.youtube.com/watch?v=9ZLLzlsz7h8

• Tez 幻灯片：http://www.slideshare.net/Hadoop_Summit/murhty-saha-june26255pmroom212

Hive 使用 map-reduce 作为其执行引擎。任何查询都将生成 MR 作业图，这些图可能散布在某些本地/Client 端工作中。这导致查询的计划和执行效率低下。以下是一些示例，可以使用更灵活的 TezPrimitives 进行改进：

多个还原阶段

每当查询有多个 reduce 接收器(无法组合，即：分区键之间没有相关性)时，Hive 都会拆分计划并为每个接收器提交一个 MR 作业。该链中的所有 MR 作业都需要一个一个地排定，每个作业都必须从 HDFS 重新读取前一个作业的输出并对其进行混洗。在 Tez 中，可以直接链接多个 reducesink，无需临时 HDFS 文件就可以对数据进行管道传输。此模式称为 MRR(Map-减少-减少*)。

Pipelining

Tez 不仅仅提供 MRR，还可以立即发送整个查询计划，从而使框架能够更智能地分配资源，并通过各个阶段对数据进行流水线处理。对于更复杂的查询，这是一个巨大的改进，因为它消除了 IO /同步障碍以及各个阶段之间的调度开销。一个示例是一个查询，该查询在 from 子句的子查询中聚合两个表，并将结果关系连接在一起。

内存与磁盘写入

当前，无论数据大小如何，都以相同的方式执行任何随机播放。将已排序的分区写入磁盘，由化简器提取，进行合并排序，然后馈入化简器。 Tez 允许将小的数据集完全在内存中处理，而 map-reduce 中没有这样的优化。完成繁重的工作后，许多仓库查询会对小型数据集进行排序或聚合。这些将受益于内存洗牌。

Joins

分布式联接算法很难用 map-reduce 表示。例如，常规的 shuffle 联接必须在同一 map 任务中处理不同的 Importing，使用将标记写入磁盘以区分表，使用辅助排序以可预测的 Sequences 从每个表中获取行，等等。实现这些算法的自然平台。

例如：可能有一个 Tez 任务将多个二分边作为 Importing，因此将 Importing 关系直接暴露给 join 实现。将多个任务馈入同一随机混入联接任务的情况称为多父级随机混入联接。

Fine-tuned algorithms

不论数据类型如何，map-reduce 中的所有排序都使用相同的二进制排序进行。例如，Hive 可能会选择使用更有效的仅整数排序。 Tez 使它可用。

由于 Hive 使用 map-reduce 来计算聚合，因此即使我们实际上对排序 Sequences 不感兴趣，处理也总是归结为一个排序合并。 Tez 将允许使用更有效的基于哈希的算法来执行相同的操作。

Limit processing

Tez 允许对处理进行完全控制，包括能够在达到限制时停止处理(而不仅仅是跳过记录或依靠文件格式/Importing 格式.)还可以定义特定的边缘语义，该语义可以用来提供通用的 top-k 边缘可简化“限制”处理。

Scope

本文档的其余部分描述了 Hive/Tez 集成的第一阶段。目标是：

• 将 Tez 概念和 Primitives 引入 Hive，使其对所有 Hive 开发人员可用

• 通过 MRR 利用 TEZ(多个还原阶段作业)

• 通过 MPJ(多父级洗牌连接)利用 TEZ

将集成限制在相当简单的 MRR/MPJ 模式中，将需要对计划程序和执行框架进行最小的更改，同时加快各种查询的速度。同时，这将使我们为将来的改进打下坚实的基础。

第一阶段的功能要求

• Hivecontinue 按原样在没有 TEZ 的群集上工作。

• MR 版本 20、20S，23continue 保持不变。

• Hive 可以选择将 MR 作业提交给 TEZ，而无需任何其他改进。

• Hive 可以像对待另一个 Hadoop 23 实例一样对待 TEZ。

• Hive 可以选择检测 MR 作业链并将其优化为 MR *形式的单个 DAG，并将其提交给 TEZ。

• Hive 可以选择检测某个联接何时具有多个父任务，并将它们组合成树形的单个 DAG。

• Hive 将在说明计划中显示 MRR 优化。

• Hive 将在运行 MRR 查询时向用户提供有关查询进度和完成状态的适当反馈。

• 用户将能够像以前一样获取统计信息和诊断信息(计数器，日志，控制台上的调试信息)。

• Hive 具有单元测试以涵盖所有新功能。

以下内容超出了第一阶段的范围：

• 本地任务仍将仅以 MR 身份运行。

• 仅使用带有 SimpleEdges 的 Map 和 Reduce Tez 任务(即：无新任务，新 Importing/输出/处理器，无新边线类型)。

• 不会引入多输出任务优化。

将引入一个新的配置变量：

• hive.optimize.tez
  hive.execution.engine(在HIVE-6103中更改)

• True
  tez：提交针对 MRR/MPJ 优化的本机 TEZ dags

  • False
    先生(默认)：提交单个 Map，单个缩小计划

• 更新：Hive 0.13.0 中引入了几个配置变量。请参阅“配置属性”中的Tez section。

注意：可以针对 TEZ 执行 MR 计划。为此，只需更改以下变量(假设在群集上安装了 Tez)：

• mapreduce.framework.name = yarn-tez

Example

这是启用和未启用 Tez 优化的 TPC-DS 查询和计划：

查询(为 Hive 重写)：

select
  i_item_desc
  ,i_category
  ,i_class
  ,i_current_price
  ,i_item_id
  ,itemrevenue
  ,itemrevenue*100/sum(itemrevenue) over
    (partition by i_class) as revenueratio
from
  (select
     i_item_desc
     ,i_category
     ,i_class
     ,i_current_price
     ,i_item_id
     ,sum(ws_ext_sales_price) as itemrevenue
   from
     web_sales
     join item on (web_sales.ws_item_sk = item.i_item_sk)
     join date_dim on (web_sales.ws_sold_date_sk = date_dim.d_date_sk)
   where
     i_category in ('1', '2', '3')
     and year(d_date) = 2001 and month(d_date) = 10
   group by
     i_item_id
     ,i_item_desc
     ,i_category
     ,i_class
     ,i_current_price) tmp
order by
  i_category
  ,i_class
  ,i_item_id
  ,i_item_desc
  ,revenueratio;

与经济特区合作

Stage 0:

本地工作：为日期暗淡生成哈希表

Stage 1:

Map：SMB 加入项目 web_sales，mapjoin date_dim web_sales，Map 端分组依据/汇总

减少 1：减少/聚合侧组，随机播放窗口

减少 2：计算开窗功能，按 Sequences 排序

减少 3：排序，写入 HDFS

不含 TEZ 的计划

本地工作：为日期暗淡生成哈希表

Stage 1:

Map：SMB 加入项目 web_sales，mapjoin date_dim web_sales，Map 端分组依据/汇总

减少：减少/聚合侧组，写入 HDFS

Stage 2:

Map：读取 tmp 文件，将其随机拖入窗口

减少：计算开窗功能，写入 HDFS

Stage 3:

Map：读取 tmp 文件，按 Sequences 随机播放

减少：排序，写入 HDFS

Design

变更摘要

影响当前 Hive 代码路径的更改：

• 从 SemanticAnalyzer 拆分 MR 编译(简单)

• 将 MapRedWork 分为 MapWork 和 ReduceWork(直截了当，但有很多更改)

• 将执行特定的类从 exec 移动到 exec.mr 包(简单)

• 将某些功能从 ExecDriver 移至 exec.Utilities 以在 Tez 和 MR 之间共享

• 构建系统：添加 Tez 依赖项和 Tez 测试

我相信所有这些本身都是有价值的，并且可使代码更整洁，更易于维护。特别是第二项虽然会触及代码中的很多地方。他们都没有改变功能。

新的代码路径(仅在运行 Tez 时处于活动状态)：

• 执行：TezWork，TezTask，TezJobMonitor(小)

• 规划：编译器以生成 TezTasks，在 Tez 上进行物理优化(大)

下面概述了各个 Hive 组件中的更改：

Execution layer

我们最初研究过将 Tez 作为简单的填充选项添加到代码库中。这主要是因为 Tez 的 API 与 MR API 完全不同，因此无法解决。将整个“执行”基础架构移至填充层没有太大意义。这将需要对代码进行大量更改而几乎没有收益。相反，将为 MR 和 TEZ 提供单独的“任务”实现，而 Hive 将在运行时决定要使用哪种实现。

我们计划有两个软件包：

• org.apache.hadoop.hive.ql.exec.mr

• org.apache.hadoop.hive.ql.exec.tez

两者都将包含 Task 接口的实现，该接口用于封装要由 Driver 类调度和执行的工作单元。

这两个软件包都具有用于作业监视和作业诊断的类，尽管它们是软件包专用的，并且不遵循公共接口。

Job submission

当前，ExecDriver 和 MapRedTask(均为“任务”类型)将通过 JobClient(通过本地作业运行程序或针对集群)提交 Map 缩减工作。所有 MR 特定的职位提交概念都隐藏在这些类的后面。

我们将添加一个 TezTask 作为执行 Tez 的入口。 TezTask 将隐藏工作 DAG 的构建，并协调 DAG 执行的监视和诊断。

Hive 的驱动程序仍将处理任务图以处理执行。无需任何更改即可处理此问题。唯一的区别是，现在计划人员可以在运行时透明地将 TezTasks 添加到混合中。

Job monitoring

我们将添加一个 TezJobMonitor 类，该类处理状态的打印以及报告最终结果。此类提供的功能与用于 MR 处理的 HadoopJobExecHelper 相似。 TezJobMonitor 还将检索并打印在执行时抛出的顶级异常。

Job diagnostics

基本的“作业成功/失败”以及进度将在“作业监视”中讨论。 Hive 当前尝试获取有关失败作业的其他信息的方式在第一阶段将不可用。

当前，一旦完成一项工作，Tez 将提供有限的调试支持。访问详细日志，计数器等的唯一方法是查看 AM 的日志，为特定任务日志找到适当的 URL，然后通过复制和粘贴来访问它们。随着时间的流逝，这将发生变化，并且历史记录信息将可访问，但是对于第一阶段，调试支持将受到限制。

Counters

检索计数器的 API 在 Tez 中会有所不同，因此我们将为此添加一个 shim api。执行时递增计数器将保持不变。

Job execution

第一阶段的基本执行流程将保持不变。ExecMapper/ ExecReducer 将通过 Tez 的 MR 兼容层使用。操作员计划设置将像以前一样通过“临时目录”进行通信。 ExecMapper/Reducer 将相应地进行加载和配置。

Query planning

MapRedWork

MapRedWork 是我们目前在编译/优化期间记录有关 MR 作业的所有信息的地方。

此类将被重构以分别捕获 Map 信息和减少信息(在 MapWork 和 ReduceWork 中)。这需要对计划和执行进行相当多的更改(尽管很简单)。

重构对于纯 MR 执行也有好处。它消除了 Mapper/Reducer 加载和反序列化它们不使用的信息的需要，并且使它更易于阅读和维护代码，因为它清楚地描述了在哪个阶段使用了什么信息。

MapWork 和 ReduceWork 将由 MapRedWork 和 TezWork 共享。 MapRedWork 基本上是 1M 0-1R 的组成，而 TezWork 是 Map/ReduceWork 的树，仅具有 MapWork 类。

如上所述，TezTask 将使用 TezWork，而 MapRedTask 和 ExecDriver 将使用 MapReduceWork。

语义分析和逻辑优化

语义分析器和任何逻辑优化都不会改变。目前，物理优化和 MR 计划的生成也在 SemanticAnalyzer 中完成，并将移至单独的类中。

物理优化和任务生成

现在，MapReduceCompiler 同时执行两项操作。在将操作员计划分解为减少 Map 任务之后，它会优化任务数量并执行物理优化(点选联接实现，总订单排序等)。

为了限制 Tez 的影响，我们将提供一个单独的实现：TezCompiler。 Tez 编译器将尝试在计划级别执行大多数物理优化，而将计划细分分解到 Tez 作业中进行第二轮优化。

稍后，我们可能决定对 MR 和 Tez 使用该物理优化器(在计划级别)，同时在两层中保留特定的优化。

本地求职者

在短期内，Tez 将不支持“ LocalTezDagRunner”。这意味着 Hive 在本地执行时将始终必须提交 MR 作业。为了避免在 Tez 模式下开始执行后重新计划查询，某些将阶段转换为本地作业的优化将不可用。

任务数

一些 MR 作业具有 sched 数量的减速器。发生这种情况的 Sequences 是(numReducers = 1)，在使用存储分区的情况下(numReducers = numBuckets)。用户还可以手动设置减速器的数量。每个减少任务将使用相同的数字。最初，用户没有办法为每个单独的减速级设置不同数量的减速器。已经有一张票证(HIVE-3946)解决了此缺陷，该票证可同时用于 Tez 和 MR。

在大多数情况下，Hive 将通过查看特定 MR 作业的 Importing 大小来确定减速器的数量。 Hive 然后将猜测减速器的正确数量。相同的猜测将用于 Tez 计划中的后续缩减阶段。最终，必须使用超出范围的统计信息来确定此数字，但该统计信息同样适用于 MR 和 Tez。

Explain statements

解释语句(部分)从 MapReduceWork 中的字段驱除。扩展/重构 MapReduceWork 的一部分将是添加足够的信息以打印正确的运算符树，以便为 Tez 进行解释。

Hive variables

Hive 变量的“设置”机制不会改变。变量将像以前一样传递给执行引擎。但是，Hive 不会填充或 Map 任何 mapreduce 变量。如果 Hive 不支持某个变量，它将被忽略。

Build infrastructure

在 Tez 上将有一个新的“ ql”依赖项。罐子的处理方式与 Hadoop 罐子的处理方式相同，即：它们将在编译期间使用，但不包含在最终发行版中。相反，我们将依赖于它们分别安装。这些罐子只需要存在即可运行 Tez 作业，而常规 MR 执行则不需要。

Testing

Mini Tez 群集

迷你 Tez 群集最初将是在单元测试期间运行 Tez 的唯一方法。 LocalRunner 尚不可用。如果 mr.rev 设置为 tez，则所有 MiniMr 测试都将针对 Tez 运行。

安装和配置

有关如何在 Hadoop 2 集群上设置 Tez 的信息，请参阅https://github.com/apache/incubator-tez/blob/branch-0.2.0/INSTALL.txt。

有关如何为 Tez 配置 Hive 0.13.0 的信息，请参阅HIVE-6098，将 Tez 分支合并到主干的发行说明。有关所有 Tez 参数的说明，另请参见配置属性：Tez。

Hive-Tez Compatibility

有关彼此兼容的 Hive 和 Tez 发行版的列表，请参见Hive-Tez Compatibility。