Hive的原理与不足

转自：http://yuntai.1kapp.com/?p=1035

 

架构

 

• UI：用户提交查询请求与获得查询结果。包括三个接口：命令行（CLI）、Web GUI（Hue）和客户端。
• Driver：接受查询请求与返回查询结果。实现了session的概念，以处理和提供基于JDBC/ODBC执行以及颉取的API。
• Compiler: 编译器，分析查询SQL语句，在不同的查询块和查询表达式上进行语义分析，并最终通过从metastore中查找表与分区的元信息生成执行计划。
• Metastore：元数据储存，元数据存储在MySQL或derby等数据库中。元数据包括Hive各种表与分区的结构化信息，包括列与列类型信息，序列化器与反序列化器，从而能够读写hdfs中的数据。
• Execution Engine：执行引擎，执行由compiler创建的执行计划。此计划是一个关于阶段的有向无环图。执行引擎管理不同阶段的依赖关系，通过MapReuce执行这些阶段。

执行流程

• 编译器将Hive SQL 转换成一组操作符(Operator)。
• 操作符是Hive的最小处理单元。
• 每个操作符处理代表一道HDFS操作或MapReduce作业。
• Hive通过ExecMapper和ExecReducer执行MapReduce任务。

编译过程

• Parser：分析器，将SQL转换成抽象语法树。
• Semantic Analyzer：语义分析，将抽象语法树转换成查询块。
• Logic Plan Generator：逻辑查询计划生成器，将查询块转换成逻辑查询计划，该计划是

一棵操作符树。

• LogicalOptimizer：逻辑查询计划优化器。
• Physical Plan Generator：物理查询计划生产器，将逻辑计划转成一些列的MR jobs。
• PhysicalOptimizer：物理查询计划优化器。

例子

HQL：

INSERT OVERWRITE TABLE access_log_temp2

SELECT a.user, a.prono, p.maker, p.price

FROM access_log_hbasea JOIN product_hbasep ON (a.prono= p.prono);

相应物理查询计划：

不足

执行引擎

Hive架构于MapReduce Framework之上，执行计划的灵活性较差，优化器可做的选择很少，例如：Join算法只有Grace Hash Join一种选择，性能更加优秀且稳定的Hybrid Hash Join则无法实现; Map端的Group-by算法只有Hash Group-by一种选择, Reduce端的Group-by只有sort group-by一种选择(不然MapReduce提供的sort就浪费了); limit无法和sort融合起来，很多情况下，用堆排序来融合limit与sort会更加高效。 Join, Group-by, Limit在OLAP，日志分析等任务中非常常用的Operator，而Hive在这3个Operator的实现上都依赖于MapReduce Frameowork提供的partition和sort，好处是实现比较简单，缺点是效率往往不是最优的。 然而，由于MapReduce数据处理流程的限制，效率更高的算法却无法实现。

查询优化器

大多数商用数据仓库使用基于代价的优化器，在生成查询计划时，利用元数据中的统计信息估算每个operator要处理的数据量，选取代价较低的执行 计划。不过，这些商用数据仓库的都起步于基于规则的查询优化器，而Hive正处于这样一个类似的起步阶段。因而Hive查询优化器能做的优化并不多，仅限 于10几条转换规则。

索引和缓冲管理

对于查询来说，索引的作用至关重要，尽管Hive中的partition起到和索引类似的作用，但还比较初级，与并行数据仓库较为完善的索引 (primary,secondary, clustered, unclustered)还有很大差距。当然，Hive也没有缓冲区管理机制，只能依赖于文件系统的缓冲机制；传统的并行数据仓库往往禁用操作系统的缓冲 机制，针对不同的查询的特点设计了多种缓冲机制，从而优化了性能。

内存拷贝开销

内存拷贝会很大程度上拖累系统性能。我们可以注意到，Hive中所有的hash，比较，数值运算操作，都需要操作在Writable Object上，而每次重置(reset)这些Writable Object，都需要将数据从byte array拷贝到这些对象的byte[]成员中。在更精巧的实现中，很多内存拷贝其实是可以避免的，传统的并行数据仓库往往做了很多优化（甚至包含操作系 统内核的优化，比如Teradata的PDE）去节省不必要的内存拷贝，从而又带来了性能提升。

 

评论

1 楼 cc3514772b 2013-09-01  

limit无法和sort融合起来，很多情况下，用堆排序来融合limit与sort会更加高效
见https://issues.apache.org/jira/browse/HIVE-3562  觉得不好为什么不自己去改？？