Helianthus_lu

Helianthus_lu

关注
发信
关注(28)粉丝(399)

hive 结合执行计划 分析 limit 执行原理

在hive查询中要限制查询输出条数， 可以用limit 关键词指定，如 select columnname1 from table1 limit 10; 这样hive将输出符合查询条件的10个记录，从根本上说， hive是hadoop提交作业的客户端，它使用antlr词法语法分析工具，对SQL进行分析优化后翻译成一系列MapReduce作业，向hadoop提交运行作业以得到结果.
   看一条简单的SQL语句：

    

	
  1. 
		select deviceid from t_aa_pc_log where pt='2012-07-07-00' limit 1;  
	
    2.

   这条语句指定分区字段 pt为2012-07-07-00, 限制结果为 limit 1. 假设运行这个MR作业需要5个map, 那么每个map应该输出一条记录，从jobtrack 的 jobdetails页面中的计数器中 Map Input Records 一项应该显示为5(即该作业中Map阶段总共输入5条记录),结果是否如预计的那样， 通过运行改SQL来验证:

    

	
  1. 
		   > select deviceid from t_aa_pc_log where pt='2012-07-07-00' limit 1;                                  
	
    2. 

	
  2. 
		Total MapReduce jobs = 1 
	
    3. 

	
  3. 
		Launching Job 1 out of 1 
	
    4. 

	
  4. 
		Number of reduce tasks is set to 0 since there's no reduce operator 
	
    5. 

	
  5. 
		Starting Job = job_201205162059_1547550, Tracking URL = http://jt.dc.sh-wgq.sdo.com:50030/jobdetails.jsp?jobid=job_201205162059_1547550 
	
    6. 

	
  6. 
		Kill Command = /home/hdfs/hadoop-current/bin/hadoop job  -Dmapred.job.tracker=10.133.10.103:50020 -kill job_201205162059_1547550 
	
    7. 

	
  7. 
		2012-07-07 16:22:42,570 Stage-1 map = 0%,  reduce = 0% 
	
    8. 

	
  8. 
		2012-07-07 16:22:48,628 Stage-1 map = 80%,  reduce = 0% 
	
    9. 

	
  9. 
		2012-07-07 16:22:49,640 Stage-1 map = 100%,  reduce = 0% 
	
    10. 

	
  10. 
		2012-07-07 16:22:50,654 Stage-1 map = 100%,  reduce = 100% 
	
    11. 

	
  11. 
		Ended Job = job_201205162059_1547550 
	
    12. 

	
  12. 
		OK 
	
    13. 

	
  13. 
		0cf49387a23d9cec25da3d76d6988546 
	
    14. 

	
  14. 
		Time taken: 13.499 seconds 
	
    15. 

	
  15. 
		hive>  
	
    16.

正如limit 1限制，输出一条记录，再通过 http://jt.dc.sh-wgq.sdo.com:50030/jobdetails.jsp?jobid=job_201205162059_1547550
查看Map Input Records项:

hive 结合执行计划 分析 limit 执行原理-LMLPHP

  上图显示Map Input Records实际上是35，并非之前设想的每个MAP一条，总共5条，那多出来的30条记录又是怎么来的? 实际上这个跟hive mapreduce实现有关，先来看看上面这条SQL的执行计划:

    

	
  1. 
		    > explain select deviceid from t_aa_pc_log where pt='2012-07-07-00' limit 1; 
	
    2. 

	
  2. 
		OK 
	
    3. 

	
  3. 
		STAGE DEPENDENCIES: 
	
    4. 

	
  4. 
		  Stage-1 is a root stage 
	
    5. 

	
  5. 
		  Stage-0 is a root stage 
	
    6. 

	
  6. 
		 
	
    7. 

	
  7. 
		STAGE PLANS: 
	
    8. 

	
  8. 
		  Stage: Stage-1 
	
    9. 

	
  9. 
		    Map Reduce 
	
    10. 

	
  10. 
		      Alias -> Map Operator Tree: 
	
    11. 

	
  11. 
		        t_aa_pc_log  
	
    12. 

	
  12. 
		          TableScan 
	
    13. 

	
  13. 
		            alias: t_aa_pc_log 
	
    14. 

	
  14. 
		            Filter Operator 
	
    15. 

	
  15. 
		              predicate: 
	
    16. 

	
  16. 
		                  expr: (pt = '2012-07-07-00') 
	
    17. 

	
  17. 
		                  type: boolean 
	
    18. 

	
  18. 
		              Select Operator 
	
    19. 

	
  19. 
		                expressions: 
	
    20. 

	
  20. 
		                      expr: deviceid 
	
    21. 

	
  21. 
		                      type: string 
	
    22. 

	
  22. 
		                outputColumnNames: _col0 
	
    23. 

	
  23. 
		                Limit 
	
    24. 

	
  24. 
		                  File Output Operator 
	
    25. 

	
  25. 
		                    compressed: false 
	
    26. 

	
  26. 
		                    GlobalTableId: 0 
	
    27. 

	
  27. 
		                    table: 
	
    28. 

	
  28. 
		                        input format: org.apache.hadoop.mapred.TextInputFormat 
	
    29. 

	
  29. 
		                        output format: org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat 
	
    30. 

	
  30. 
		 
	
    31. 

	
  31. 
		  Stage: Stage-0 
	
    32. 

	
  32. 
		    Fetch Operator 
	
    33. 

	
  33. 
		      limit: 1 
	
    34. 

	
  34. 
		 
	
    35. 

	
  35. 
		 
	
    36. 

	
  36. 
		Time taken: 0.418 seconds 
	
    37.

   改执行计划显示，Stage-1 是一个MR程序，且只有map过程， 没有reduce过程,也就是说在Map过程就直接将结果输出到HDFS文件系统, Stage-0是依赖于Stage-1的文件读取操作，它不是MR作业，只是一个基于hadoop文件系统客户端的分布式文件读取程序。
   重点分析Stage-1过程，一条记录被读取后调用hive自定义mapper函数，依次经过
TableScan Operator -> Filter Operator -> Select Operator -> Limit Operator-> File Output Operator, 以上每一个Operator都是hive定义的一个处理过程, 每一个 Operator都定义有:

    

	
  1. 
		protected List<Operator<? extends Serializable>> childOperators; 
	
    2. 

	
  2. 
		protected List<Operator<? extends Serializable>> parentOperators; 
	
    3.

这样就构成了一个 Operator图，hive正是基于这些图关系来处理诸如limit, group by, join等操作. Operator 基类定义一个:

    

	
  1. 
		protected boolean done; // 初始化值为false
	
    2.

这个字段指示某一个层级的Operator是否已经处理完成，每当一条记录进入特定的Operator操作时，当前Operator会判断自己的childOperators 的done是否全部为true, 如果是， 表示childOperators已去全部处理完毕， 当前这个Operator也把自己的 done设置为true, 这样层层返回，直到最外层的Operator, 这个查询中涉及的部分Operator如下图:

hive 结合执行计划 分析 limit 执行原理-LMLPHP

 该hive MR作业中指定的mapper是:

    

	
  1. 
		mapred.mapper.class = org.apache.hadoop.hive.ql.exec.ExecMapper 
	
    2.

input format是:

    

	
  1. 
		hive.input.format   org.apache.hadoop.hive.ql.io.CombineHiveInputFormat 
	
    2.

部分执行流程：

hive 结合执行计划 分析 limit 执行原理-LMLPHP

MapRunner会循环调用CombineHiveRecordReader的doNext方法读入行记录，直到doNext方法返回false, doNext方法中有一个重要的逻辑来控制记录读取是否结束

    

	
  1. 
		@Override 
	
    2. 

	
  2. 
		public boolean doNext(K key, V value) throws IOException { 
	
    3. 

	
  3. 
		  if (ExecMapper.getDone()) { 
	
    4. 

	
  4. 
		    return false; 
	
    5. 

	
  5. 
		  } 
	
    6. 

	
  6. 
		  return recordReader.next(key, value); 
	
    7. 

	
  7. 
		} 
	
    8.

   每读取一条记录都会判断 MapRunner.getDone()是否为真， 如果是则结束Mapper读取过程,  ExecMapper类中定义了一个静态变量done（静态非常重要，因为在hadoop框架下执行时 CombineHiveRecordReader无法拿到 ExecMapper实例), 当 MapRunner读取一条记录后就会调用 MapRunner的map函数,  ExecMapper中定义了一个MapOperator，MapOperator的 childOperators 列表中持有TableScanOperator实例，依次类推， 各Operator递归包含.
    ExecMapper的map函数被调用时会先判断 MapOperator的done是否为true, 如果是，则将自己的静态变量done设置为true(这样 CombineHiveRecordReader在下一次读取记录时发现 ExecMapper的done为true, 结束mapper记录读取),  否则执行MapOperator的process方法, 具体逻辑如下:

    

	
  1. 
		public void map(Object key, Object value, OutputCollector output, 
	
    2. 

	
  2. 
		      Reporter reporter) throws IOException { 
	
    3. 

	
  3. 
		    if (oc == null) { 
	
    4. 

	
  4. 
		      oc = output; 
	
    5. 

	
  5. 
		      rp = reporter; 
	
    6. 

	
  6. 
		      mo.setOutputCollector(oc); 
	
    7. 

	
  7. 
		      mo.setReporter(rp); 
	
    8. 

	
  8. 
		    } 
	
    9. 

	
  9. 
		    // reset the execContext for each new row 
	
    10. 

	
  10. 
		    execContext.resetRow(); 
	
    11. 

	
  11. 
		 
	
    12. 

	
  12. 
		    try { 
	
    13. 

	
  13. 
		      if (mo.getDone()) { 
	
    14. 

	
  14. 
		        done = true; 
	
    15. 

	
  15. 
		      } else { 
	
    16. 

	
  16. 
		        // Since there is no concept of a group, we don't invoke 
	
    17. 

	
  17. 
		        // startGroup/endGroup for a mapper 
	
    18. 

	
  18. 
		        mo.process((Writable)value); 
	
    19.

接下来再看看各Operator如何判断自己状态是否为执行完成:

    

	
  1. 
		int childrenDone = 0; 
	
    2. 

	
  2. 
		for (int i = 0; i < childOperatorsArray.length; i++) { 
	
    3. 

	
  3. 
		  Operator<? extends Serializable> o = childOperatorsArray[i]; 
	
    4. 

	
  4. 
		  if (o.getDone()) { 
	
    5. 

	
  5. 
		    childrenDone++; 
	
    6. 

	
  6. 
		  } else { 
	
    7. 

	
  7. 
		    o.process(row, childOperatorsTag[i]); 
	
    8. 

	
  8. 
		  } 
	
    9. 

	
  9. 
		} 
	
    10. 

	
  10. 
		 
	
    11. 

	
  11. 
		// if all children are done, this operator is also done 
	
    12. 

	
  12. 
		if (childrenDone == childOperatorsArray.length) { 
	
    13. 

	
  13. 
		  setDone(true); 
	
    14. 

	
  14. 
		} 
	
    15.

每个Operator都判断自己的子Operator状态是否全部完成， 如果是则把自己的状态也设置成done=true.
最后再看LimitOperator的判断逻辑:

    

	
  1. 
		@Override 
	
    2. 

	
  2. 
		public void processOp(Object row, int tag) throws HiveException { 
	
    3. 

	
  3. 
		  if (currCount < limit) { 
	
    4. 

	
  4. 
		    forward(row, inputObjInspectors[tag]); 
	
    5. 

	
  5. 
		    currCount++; 
	
    6. 

	
  6. 
		  } else { 
	
    7. 

	
  7. 
		    setDone(true); 
	
    8. 

	
  8. 
		  } 
	
    9. 

	
  9. 
		} 
	
    10.

currCount 是一个记录处理的计数器， 初始值为0， 当该值大于等于limit后，将自己标识成处理完成状态,即设置done=true.
   分析到现在， 已经可以非常清晰的解释最初的疑问了， 为什么 limit 1， map数为5的前提下， Map Input Records 是35而不是5
1. 第一条记录进入LimitOperator done 为false
2. 第二条记录进入LimitOperator done 为true
3. 第三条记录进入SelectOperator done 设置为true
4. 第四条记录进入FilterOperator done设置为true
5. 第五条记录进入TableScanOperator done设置为true
6. 第六条记录进入MapOperator done设置为true
7. 第7条记录进入ExecMapper 静态变量done设置为true
8. 读取第八条记录时 CombineHiveRecordReader 发现 ExecMapper 的done已经为true, 结束数据读取，从而 MapRunner 退出循环， 结束mapper过程.
从上面8个步骤看出， 每个map会读取7条记录， 5个map， 正好是35条记录.
   在平时工作中， 通过分析 hive 执行计划可以让我们清楚的知道MR中的每一个过程，理解HIVE执行过程， 进而对SQL优化.


本文出自 “yyj0531” 博客，http://yaoyinjie.blog.51cto.com/3189782/923378
[Nice!感谢作者的分享，解决了我关于hive内核学习中的疑惑之处]
12-18 07:12
Powered by LMLPHP ©2024 Helianthus_lu 0.079830