TEZ运行时重置reduce个数

问题导读
1.tez在性能优化方面做了哪些努力？
2.运行时reduce个数的动态调整是如何实现的呢？




一、Motivation
    分布式数据处理本身就是一个动态过程，很难预先静态的确定最佳并发度和数据迁移方式。而分布式处理过程中却有很多值得参考的信息，比如根据数据抽样计算数据集大小，这些对于执行计划阶段的深层次优化有很大帮助。我们也觉得要实现动态的优化，单靠tez自身并不能时时做出敏捷的反应。在tez的设计目标中包括了对可插拔顶点管理模块的支持，该模块用于收集tez的DAG程序在运行时tasks的相关信息，依据这些信息改变运行时数据流图，以此达到对性能和资源的优化。下图展示了在一个类似mapreduce的job中如何通过观察上个阶段实际输出的数据量来为下个阶段设置一个合适的reducer并行度的过程。

Dynamic Graph Reconfiguration（1）

二、Performance & Efficiency via Dynamic Graph Reconfiguration
    假设tez执行计算时达到了对资源的最高效的使用，也获得了很好的性能，那么这意味着在集群中给定了某个具体的运行时条件并且得到了前一步的计算结果。这项功能的实现基于两个基本的构建块：
1.Pluggable Vertex Management Modules:
    tez的控制流结构中为用户逻辑嵌入了一个pre-vertex可插拔模块，其中用户逻辑专注于数据和计算。tez提供了一个顶点状态机(The vertex state machine )，用于在重要的状态转换时刻唤醒该模块，比如启动一个顶点，源顶点task执行完毕等时刻都会通过状态机唤醒可插拔顶点管理模块。在这些重要的状态转换点，用户逻辑可以检查运行时状态并为tez执行引擎提供一些提示信息，比如顶点中task的并行度。
2.Event Flow Architecture:
    tez定义了一组事件来实现各个顶点之间、各个tasks等之间的信息传递。在提前定义好路由逻辑的基础上，这些事件实现了在源组件和目的组件之间正确的路由选择。比如在这些事件中有一个事件是VertexManager事件，可以通过该事件将各种用户定义的配置发送到一个指定的VertexManager上。
三、Case Study: Reduce task parallelism and Reduce Slow-start
   为mapreduce作业确定合适的reduce tasks个数是一个长久的话题。因为无法预知map tasks的输出，所以要想在job执行之前确定reducer个数确实很难，尤其是在一个计算过程中包含多个stages的情况下，想要为每个阶段确定reduce并行度就更难了。关于这一点tez已经得到实现，接下来就通过一个实例来阐述tez的运行时图重新配置的能力。
1.Reduce Task Parallelism:
    ShuffleVertexManager对于在mapreduce的shuffle传输层定义的基于hash分区的语法很清楚。对一个确定的顶点，tez定义了一个VertexManager事件用户将任何用户定义发送给该顶点的VertexManager。分区任务(即Map tasks)使用该事件将诸如输出分区的大小等统计信息发送给reduce顶点的ShuffleVertexManager。该manager收到这些事件之后会尝试根据其中的抽样统计信息估算出所有map tasks的最终输出的统计信息。理想的情况将是重新分区，然后决定运行时恰当的reduce个数。顶点控制者会在确定了reduce并行度之后，取消多余的tasks并像以前一样正常启动tasks。

2.Reduce Slow-start/Pre-launch:
    Slow-start原本是Mapreduce的特点，即在所有map tasks执行完毕之前启动reduce tasks。假设在map tasks执行的同时，可以启动reduce tasks拉取那些已经计算完成的map tasks的输出结果。而何时预启动这些reduce tasks是很诡异的事情，因为这取决于map tasks的输出结果。如果过早启动reduce tasks拉取数据会导致效率很低，因为此时map tasks还没有执行完。在tez中，slow-start逻辑被嵌入到了ShuffleVertexManager中。每当有一个源task(比如map task)执行完毕，顶点状态的控制者就会通知该顶点的manager。然后manager利用这个信息来决定何时预启动reduce tasks去拉取数据以及启动多少个reduce tasks，然后建议定点控制者去执行。

    对tez来说，要将上述原理扩展到根据分区范围确定合适的并行度的场景是很容易的。可以通过VertexManager事件将数据抽样信息发送给vertex manager，vertex  manager将会以key为划分范围，决定合适的分区个数，然后为每个分区指定合适的key范围。因此，在tez中，这个操作可以在不增加单独的抽样作业的情况下得以实现。
原文: http://zh.hortonworks.com/blog/apache-tez-dynamic-graph-reconfiguration/