Apache Impala总结

Impala

基于hive，使用内存计算，提供对HDFS、Hbase数据的高性能、低延迟的交互式SQL查询功能。Impala适合用来处理输出数据适中或比较小的查询。

组件简绍

Impala Statestore :检查集群各个节点上Impala daemon的健康状态,同时不间断地将结果反馈给各个Impala daemon

Impala Catalog :分发hive 的元数据信息到 Impala Daemon,接收来自Statestore的所有请求,一个集群中只需要一个节点上有这个守护进程,

Impala Daemon :Impalad接收client请求,负责读写数据文件,基于内存运行Sql

部署注意事项：

如果Impalad与 Catalog安装到一块，当内存消耗很大时会影响元数据的同步，因此要部署到不同的机器上，Catalog与StateStore 需要进行通信，所以最好部署到同一机器

常遇问题：

1.内存消耗过大导致分析任务异常的BUG

2.impala通常与MR等离线任务运行在一个集群上，通过YARN统一管理资源，如何同时满足交互式查询和离线查询两种需求具有较大挑战性。 YARN通过全局唯一的Resource Mananger调度资源，好处是RM拥有整个集群全局信息，能做出更好调度决策，缺点是资源分配的性能不足。 Impala每个查询都需要分配资源，当每秒查询数上千时， YARN资源分配的响应时间变的很长，影响到查询性能。

3.一个用户执行大量的insert操作，其实这些任务本身是能正常执行的，但是当这种任务大量地执行时，很有可能会对整个集群的io造成一定的影响，这时候正好又有一定数量复杂查询的反复提交，综合起来会使集群在某个时间段内出现io或者某些表被锁住。

4.大量的insert操作或者select操作，会导致对impala的元数据库进行大量的读写，这种频繁的读写操作会造成mysql的锁表。

5.如果在同一个shell脚本中，先执行了ddl操作，然后又对相应的库执行查询，会出现元数据同步延迟导致无法读取信息的操作。

内存溢出问题

Impala从Impala 1.4 for CDH4、CDH5.1版本开始新增了“SQL Operations that Spill to Disk”功能，即当Impala内存运算溢出时转移到磁盘进行运算，虽然在计算时需要占用临时的磁盘空间，增加了磁盘I/O，导致运算时间远高于纯内存运算，但至少解决了内存溢出时分析任务直接失败这一“0”容错的致命问题。

在impalashell中执行“setDISABLE_UNSAFE_SPILLS=0”或者“setDISABLE_UNSAFE_SPILLS=FALSE”命令即可。当设置DISABLE_UNSAFE_SPILLS参数的值为0（FALSE）时，内存运算濒临溢出时转为磁盘运算；设置为1（TRUE）时，当内存溢出时直接报内存溢出“Memory limit exceeded”错误

建议用户尽可能的规避触发“Spill to Disk”功能。该功能目前存在的限制包括：

不是所有的SQL语句都能触发，例如union关键字还是会触发内存溢出错误；
各个节点的内存峰值限制不能过低，低于运算所需分配给各个节点的最小内存；
运算explain输出的各个节点预估内存不能过分高于各个节点的实际物理内存；
当触发“Spill to Disk”功能时有其他并发查询，仍会触发内存溢出错误；
对磁盘的空间有一定的要求，磁盘运算的数据会写入到impala各个节点的临时目录下，增加了磁盘I/O，并且会引发不可控制的磁盘占用。

优化：

1.分区不能超过1w多，否则严重影响查询性能

2.join时，把小表写前面，会把小表广播到其他节点。

3.引入快速、非集中式的查询准入机制，控制查询并发度。

4.LLAM（low latency application master）通过缓存资源，批量分配，增量分配等方式实现降低资源分配延时

5.为Impala中源数据、中间表、结果表选择合适的存储结构。Impala默认是建立TEXT格式的表存储，而对于海量数据的存储，优选Parquet格式的存储方式。在建表时显示的指定以Parquet格式建表，并且避免使用INSER…VALUES语句向Parquet表中插入数据。因为这种方式每插入一行数据就会在HDFS上产生单独的一个小数据文件，会降低数据查询的并行度从而影响查询速度。

6.在Impala的分析任务中，无论是数据库中的原始表、中间表、结果表还是查询用到的海量数据表或者影响性能的关键表，建议在生成表之后执行COMPUTE STATS table_name命令对表的相关信息进行统计，集群会根据统计信息自动选择优化的查询方案。越是规模大的表（GB、TB级以上）统计命令执行时间越长，统计完成后的查询优化效果越是明显

注:压缩数据带来cpu额外耗时，但是减少了io耗时。

元数据操作优化

1.只有通过hdfs增加或删除分区中文件后，才需要人为更新元数据，其余情况依赖impala自带更新机制即可。

2.通过hdfs增加或删除分区中文件后一律使用refresh tablename操作，性能损耗最低。

3.日常查询操作一律不加-r参数。如果出现提示元数据过期，可断开重连或者使用refresh操作。