图1 – Hive系统架构

图1显示了Hive的主要部件以及与Hadoop交互的流程. Hive主要包括以下部件

  • UI – 用户用于提交查询以及操作Hive的的界面. Hive同时提供命令行与GUI
  • Driver – 用于接受查询的组建. 这个组建实现了会话处理, 它基于JDBC/ODBC接口提供了执行与抽取的APIs.
  • Compiler – 解析SQL, 对查询块和查询表达式做语义分析, 最终会产生执行计划. 查询计划附带了来自于metastore中表和分区信息的元数据.
  • Metastore – 该组建存储了各个表与分区的结构信息, 如列名、列类型.
  • Execution Engine – 该组建负责执行由编译器生成的执行计划. 该计划是由stage组成的DAG. 执行引擎负责管理不同阶段plan的依赖以及在相应的系统组件上执行这些计划.

图1显示了系统的执行流. 首先UI向Driver调用执行接口(1:executeQuery). Driver会为查询创建Session, 并且向Compiler发送查询来产生执行计划(2:getPlan). Compiler从Metastore获取必要的元数据(3:getMetaData, 4:sendMetaData). 元数据被用来校验查询树中表达式的类型, 也可能被用来根据查询谓词对分区进行剪枝. 查询计划由Compiler所生成(5:sendPlan), 它是一个包含stages的DAG, 每个stage是map或reduce操作, 也可以是对元数据的操作, 还可以是对HDFS对操作. 对于map/reduce类型的stages来说, 这类plan包含了map操作符树(在mapper端被执行的操作符树)以及reduce操作符树. 执行引擎将这些stages提交到系统相应的组件. 在每个任务(mapper/reducer)中, 与表关联的或与中间结果关联的反序列化器被用来从HDFS上读取行. 一旦产生出输出, 他们就会被序列化然后被当作临时文件写入HDFS(该操作在mapper端完成, 这是防止任务中不包含reduce操作). 之后的map/reduce操作会读取上一步产生的临时文件. 对于DML操作, 最终的临时文件被移动到保存表的路径. 产生临时文件并移动,而不是直接保存到最终路径. 这么做可以避免脏读的发生, 因为在HDFS中文件重命名是原子操作. 对于查询来说, 临时文件中的内容由执行引擎直接从HDFS中读取, 为Driver提取操作提供数据(图中的7, 8, 9).

参考:https://cwiki.apache.org/confluence/display/Hive/Design

pwrliang Hive

Leave a Reply

Your email address will not be published. Required fields are marked *