关于Impala优化的几点思考

Impala做为一种查询系统，提供SQL语义，能够查询存储在Hadoop的HDFS和HBase中的PB级大数据。相比于其它查询工具，Impala的最大特色是查询速度较快。因此对Impala的优化也是对其查询速度的一种保障。
一、选择合适的文件存储格式，既然使用impala，无非就是为了一个目的：性能好/资源消耗少，Impala为了作到通用性，也就是为了更好的hive无缝链接，支持了大部分Hive支持的文件格式，例如Text、Avro、RCFile、Parquet等（不支持ORC），可是为了实现更快的ad-hoc查询（基本上都是OLAP查询，查询部分列，聚合，分析），咱们基本上都会选择使用Parquet格式做为数据文件存储格式，即便你的数据导入到hive中存储的使用的是其它格式（甚至经过自定义serde解析，例如Json），仍然建议你新建一个Parquet格式的表，而后进行一次数据的转换。所以这个条目能够看作是：请选用Parquet做为文件存储格式！

二、选择合适的Partition粒度，分区的个数一般是根据业务数据来的，一般时间分区（例如日期/月份）是少不了的，例如对于一个支持多终端的应用，可能在时间分区下面再加一层终端类型的分区，设置对于每个终端的不一样操做在进行一层分区，根据惟物辩证法，凡事都须要保持一个度，那么就从两个极端的状况下来分析分区的粒度如何肯定：1：分区过少:，整个表不使用分区，或者只有一个日期的分区，这样会致使频繁的查询某一个终端的数据不得不扫描成天的数据甚至整个表的数据，这是一种浪费；二、分区过多，对于每个要统计的维度都建立一个分区，这样对于任何一个维度=’xxx’的查询都只须要扫描精确须要的数据，可是这样会致使大量的数据目录，进而致使大量的文件须要扫描，这对于查询优化器是一个灾难。所以最终的建议是：根据查询需求肯定分区的粒度，根据每个分区的成员个数预估总的分区数，保证一个表的分区数不超过30000（经验之谈？），避免太小的分区。

三、尽可能分区的成员的长度，目前分区字段能够支持数值类型和字符串，可是这里推荐尽量的使用合适的整数（通常用0-256就能够保存一个分区成员的映射了，不然分区会不少）而非原始的字符串，能够在外面创建字符串到整数的映射以保存原始信息，这个约束的主要缘由是每个分区会占用一个目录，每个目录名又会在NameNode中占用必定的内存，因此不光光是对于Impala而言，对于使用Hadoop的用户而言，尽可能减少文件目录的长度。

四、选择合适的Parquet Block大小，在条目1中已经明确，要使用Impala得到较快的查询性能，那么就老老实实的使用Parquet做为存储格式，而每个Parquet的Block大小又有什么影响呢，这里暂且把Block的大小理解成一个Parquet分区的大小，在存储上表现为文件大小，若是文件过大，那么会致使这个文件只会一个Impalad进程处理，这样大大下降了Impala的并行处理能力；而若是文件太小则会致使大量的小文件，在带来并发执行的同时也会带来大量的随机I/O的影响，所以须要对于特定的数据进行不一样的parquet Block大小测试以寻求最适合该数据集的Block大小。

五、收集表和分区的统计信息，在执行完数据导入以后，建议使用 COMPUTE STATS语句收集表的统计信息，固然也能够只收集某一个分区的统计信息。

六、减小返回结果大小，若是须要统计聚合，直接在SQL中完成，尽量的在where中执行过滤而不要查出来以后在应用端作过滤，对于查询结果尽量使用LIMIT限制返回结果集大小；避免大量的结果展现在终端，能够考虑经过INSERT xxx的方式把结果输出到文件，或者经过impala-shell参数将结果重定向。

七、对于执行性能较差的查询使用EXPLAIN分析缘由。

八、最后，查询操做系统配置、查看系统使用负载，可使用Query Profile工具来探测。

上面的这些条目是最基本的应对性能调优的方案，主要包括：使用Parquet格式存储数据、分区粒度要肯定好，保证整个表的分区数不要太多（目录不要太多），每个分区下不要存在过多的小文件（选择合适的Parquet文件大小），收集统计信息使得查询优化器可以选择更好的查询方案，最后要学会使用EXPLAIN和Profile功能分析性能问题所在。