Physical Plan生成过程

优化后的逻辑运行计划被LogToPhyTranslationVisitor处理,生成物理运行计划。

这是一个经典的Vistor设计模式应用场景。

当中,LogToPhyTranslationVisitor的visit()为入口方法,通过DependencyOrderWalker遍历处理逻辑运行计划中的每个LogicalRelationalOperator。DependencyOrderWalker依照依赖顺序遍历DAG中节点,保证当且仅当节点的全部前驱都被訪问后,它才会被訪问。核心逻辑例如以下,doAllPredecessors递归调用自己,将符合无前驱条件的节点加入到fifo队列中,终于实现的效果等效于将图拓扑排序后顺序訪问。

public void walk(PlanVisitorvisitor) throws FrontendException {
List<Operator> fifo = new ArrayList<Operator>();
Set<Operator> seen = new HashSet<Operator>();
List<Operator> leaves = plan.getSinks();
if (leaves == null) return;
for (Operator op : leaves) {
doAllPredecessors(op, seen, fifo);
}
for (Operator op: fifo) {
op.accept(visitor);
}
}

接下来,每一个LogicalRelationalOperator又反过来调用LogToPhyTranslationVisitor对应的visit方法对自身进行处理,转化成PhysicalOperator。终于生成完整的逻辑运行计划。下图是LogToPhyTranslationVisitor中全部的visit
operator方法。

Physical Plan结构

分析之前Pig系统分析(3)中代码生成的运行计划,如图所看到的:

以下是完整的物理运行计划。物理运行计划与逻辑运行计划结构类似,部分Operator一一相应,但存在几个明显差别:

  1. 物理运行计划中包括了实际使用的Loader和Store,以及要操作的文件实际路径。
  2. Group操作被分成了三部分:Local Rearrage、Global Rearrange和Package。(分别相应map-reduce中的map、shuffle和reduce)
  3. 非replicate的join操作先被转换成CoGroup和Foreach操作,然后CoGroup操作与Group操作类似,也被转换为Local Rearrage,Global Rearrange和Package三步。
F:Store(output:org.apache.pig.builtin.PigStorage) - scope-28
|
|---F: New ForEach(false,false)[bag] - scope-27
| |
| Project[bytearray][0] - scope-22
| |
| POUserFunc(org.apache.pig.builtin.COUNT)[long] - scope-25
| |
| |---Project[bag][1] - scope-24
|
|---E: Package[tuple]{bytearray} - scope-19
|
|---E: Global Rearrange[tuple] -scope-18
|
|---E: LocalRearrange[tuple]{bytearray}(false) - scope-20
| |
| Project[bytearray][2] - scope-21
|
|---D: New ForEach(true,true)[tuple] - scope-17
| |
| Project[bag][1] - scope-15
| |
| Project[bag][2] - scope-16
|
|---D:Package[tuple]{bytearray} - scope-10
|
|---D: GlobalRearrange[tuple] - scope-9
|
|---D: LocalRearrange[tuple]{bytearray}(false) - scope-11
| | |
| | Project[bytearray][0] - scope-12
| |
| |---C: Filter[bag] - scope-1
| | |
| | Greater Than[boolean] - scope-5
| | |
| | |---Cast[int] - scope-3
| | | |
| | | |---Project[bytearray][1] - scope-2
| | |
| | |---Constant(0) - scope-4
| |
| |---A: Load(file:///D:/Develop/projects/pig/file1:org.apache.pig.builtin.PigStorage)- scope-0
|
|---D: LocalRearrange[tuple]{bytearray}(false) - scope-13
| |
| Project[bytearray][1] - scope-14
|
|---B:Load(file:///D:/Develop/projects/pig/file2:org.apache.pig.builtin.PigStorage) -scope-6

PhysicalPlan类代表物理运行计划,继承自OperatorPlan。(继承时会使用PhysicalOperator替换以下代码片段中泛型參数E)

public abstract class OperatorPlan<E extends Operator> implements Iterable<E>, Serializable, Cloneable {
protected Map<E, OperatorKey> mOps;
protected Map<OperatorKey, E> mKeys;
protected MultiMap<E, E> mFromEdges;
protected MultiMap<E, E> mToEdges;
}

Pig系统分析(5)-从Logical Plan到Physical Plan的更多相关文章

  1. Pig系统分析(6)-从Physical Plan到MR Plan再到Hadoop Job

    从Physical Plan到Map-Reduce Plan 注:由于我们重点关注的是Pig On Spark针对RDD的运行计划,所以Pig物理运行计划之后的后端參考意义不大,这些部分主要分析流程, ...

  2. 第六篇:Spark SQL Catalyst源码分析之Physical Plan

    /** Spark SQL源码分析系列文章*/ 前面几篇文章主要介绍的是spark sql包里的的spark sql执行流程,以及Catalyst包内的SqlParser,Analyzer和Optim ...

  3. Catalyst揭秘 Day6 Physical plan解析

    Catalyst揭秘 Day6 Physical plan解析 物理计划是Spark和Sparksql相对比而言的,因为SparkSql是在Spark core上的一个抽象,物理化就是变成RDD,是S ...

  4. 第七篇:Spark SQL 源码分析之Physical Plan 到 RDD的具体实现

    /** Spark SQL源码分析系列文章*/ 接上一篇文章Spark SQL Catalyst源码分析之Physical Plan,本文将介绍Physical Plan的toRDD的具体实现细节: ...

  5. Pig系统分析(8)-Pig可扩展性

    本文是Pig系统分析系列中的最后一篇了,主要讨论怎样扩展Pig功能.不仅介绍Pig本身提供的UDFs扩展机制,还从架构上探讨Pig扩展可能性. 补充说明:前些天同事发现twitter推动的Pig On ...

  6. Spark SQL 源代码分析之Physical Plan 到 RDD的详细实现

    /** Spark SQL源代码分析系列文章*/ 接上一篇文章Spark SQL Catalyst源代码分析之Physical Plan.本文将介绍Physical Plan的toRDD的详细实现细节 ...

  7. ADF_Database Develop系列2_通过UML数据库开发之将Logical UML转为Physical Models

    2013-05-01 Created By BaoXinjian

  8. Pig系统分析(7)-Pig有用工具类

    Explain Explain是Pig提供的调试工具,使用explain能够输出Pig Lation的运行计划.值得一提的是,explain支持-dot选项.将运行计划以DOT格式输出, (DOT是一 ...

  9. Spark SQL源码解析(四)Optimization和Physical Planning阶段解析

    Spark SQL原理解析前言: Spark SQL源码剖析(一)SQL解析框架Catalyst流程概述 Spark SQL源码解析(二)Antlr4解析Sql并生成树 Spark SQL源码解析(三 ...

随机推荐

  1. 20165203《Java程序设计》第三周学习总结

    教材学习内容总结 1.类: (1)类的声明:class+类名 (2)类体:成员变量的声明+方法(局部变量+语句) 注意: 方法体内声明的局部变量只在方法内有效和书写位置有关. 局部变量和成员变量同名: ...

  2. java8 - 4

    import java.io.PrintStream; import java.util.Comparator; import java.util.function.BiFunction; impor ...

  3. jquery跨域请求事例

    //js发送跨域请求部分var requesturl = 'url'; $.ajax({ type:'GET', url:requesturl, data:{'qNum':num}, dataType ...

  4. Rookey.Frame企业级快速开发框架开源了

    Rookey.Frame是一套基于.NET MVC + easyui的企业级极速开发框架,支持简单逻辑模块零代码编程.支持工作流(BPM).支持二次开发,具有高扩展性.高复用性.高伸缩性:应广大网友要 ...

  5. 【LOJ】#2039. 「SHOI2015」激光发生器

    题解 我永远都写不对计算几何-- 首先找到反射的线段比较好找,扫一遍所有线段然后找交点在镜子上并且交点离起点最近的那条线段 然后旋转的时候,有可能是顺时针,也有可能是逆时针,要找出法线,然后判断法线和 ...

  6. Django第一步

    对于一个web框架,掌握了三部分的内容,就可以说是迈出了第一步. 1. 准备开发环境 2. 创建一个工程,并运行 3. 开发hello world应用 1. 准备环境 首先应该是安装python和dj ...

  7. python 与 matlab 混编

    用于 Python 的 MATLAB 引擎 API 快速入门 安装用于 Python 的 MATLAB 引擎 API Matlab的官方文档中介绍了 Matlab 与其余编程语言之间的引擎接口,其中包 ...

  8. CSUOJ 1560 图书管理员的表白方式

    Description 小V是中南大学图书馆的图书管理员,每天要整理很多同学们还回来的书.久而久之,他认识了很多常来图书馆的同学,比如说小L.简而言之吧,就是小V喜欢上了小L,并且想在下一次她来还书的 ...

  9. Bzoj4710 分特产(容斥原理+组合数)

    题面 Bzoj 题解 考虑容斥原理,所有人都有特产的方案数等于: 至少零个人没有特产\(-\)至少一个人没有特产\(+\)至少两个人有特产\(-...\) 接着考虑其中一种情况怎么求(假设现在至少有\ ...

  10. OpenJudge——0003:jubeeeeeat

    OpenJudge——0003:jubeeeeeat 描述 众所周知,LZF很喜欢打一个叫Jubeat的游戏.这是个音乐游戏,游戏界面是4×4的方阵,会根据音乐节奏要求玩家按下一些指定方块(以下称co ...