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）去节省不必要的内存拷贝，从而又带来了性能提升。