已经有一个月没有更新了，真的是比较懒惰。小编以后会尽量保持两天一更新的

最近因工作需要需要使用impala，在这里对impala进行一个个人的总结

为什么产生impala?

熟悉大数据生态圈的朋友应该对这个并不陌生，hadoop现在主要使用的有三个版本，毕竟hadoop是作为顶级开源项目存在的，有很多优秀的公司去进行二次优化本身也是很正常的事情，主要使用的一般是apache原生的，还有CDH版本，二者的区别可以从很多方面进行进行分析

小编之前实习的公司都是使用apache的原生版本，最近也是刚刚开始接触CDH版本，直观的感受CDH相对于apache来说还是优点较多的，不管是管理系统的统筹调度还是web ui的设计等等。而impala同时也是Cloudera公司为了实现并行的批量sql的查询的产物，因为相对于impala，hive在查询方面的效率太低了（毕竟hive只是一个hadoop的数据仓库，大部分的操作都要依赖MR去执行具体的任务）。

什么是impala？(此处引用w3cschool关于impala的介绍)

Impala是用于处理存储在Hadoop集群中的大量数据的MPP（大规模并行处理）SQL查询引擎。 与其他Hadoop的SQL引擎相比，它提供了高性能和低延迟。

换句话说，Impala是性能最高的SQL引擎（提供类似RDBMS的体验），它提供了访问存储在Hadoop分布式文件系统中的数据的最快方法。

hive的查询速度相对于impala为什么这么慢？

这里我们以一个查询为例简单介绍一下

select u.name, o.orderid from order o join user u on o.uid = u.uid;

启动hive，首先进行map任务，在map任务的时候对任务进行一个简单的划分，并且针对不同的表数据进行一个简单的打标签操作，用户区分在reduce阶段的结合处理，在shuffle阶段通过将数据进行一个初次的处理，发送到Reduce阶段。这里没有进行展开对抽象语法树和具体的执行过程介绍直观来看hive是MR的简易化处理程序，MR是一个大数据批处理的过程，在MR的数据执行过程会包含大量的数据写入到磁盘和从磁盘中再次读取数据，这部分也是hadoop和spark的一个区别

这个过程如果说是用户进行一些需要交互式的操作的话，速度自然是很慢的

Impala的优势

先来看一下impala和hive架构图比较一下

既然impala是在hive之后产生的，针对hive的不足impala肯定进行了相应的优化，

没有使用MapReduce进行并行计算，虽然MapReduce是非常好的并行计算框架，但它更多的面向批处理模式，而不是面向交互式的SQL执行。与MapReduce相比：Impala把整个查询分成一执行计划树，而不是一连串的MapReduce任务，在分发执行计划后，Impala使用拉式获取数据的方式获取结果，把结果数据组成按执行树流式传递汇集，减少了把中间结果写入磁盘的步骤，再从磁盘读取数据的开销。Impala使用服务的方式避免每次执行查询都需要启动的开销，即相比Hive没了MapReduce启动时间。

更好的IO调度，Impala知道数据块所在的磁盘位置能够更好的利用多磁盘的优势，同时Impala支持直接数据块读取和本地代码计算checksum。

通过选择合适的数据存储格式可以得到最好的性能（Impala支持多种存储格式）。

最大使用内存，中间结果不写磁盘，及时通过网络以stream的方式传递

impala的劣势

不支持用户定义函数UDF。这也就意味着impala的灵活性较差，对于很多场景下不如hive灵活

不支持Transforms。

不支持查询期的容错。同样这也就意味着如果impala在查询期间出错了，impala会进行一个

二次的查询，如果数据量较大，择需要消耗更多的时间和资源。而hive是依赖hadoop的各种

容错机制的，所以可用性更高一些

对内存要求高。当然在内存越来越廉价的今天可能相对没有那么重要