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