Impala 调优检查列表：

如何通过查看Profile优化Impala：

1. 检查stats：如果表没有统计信息的话，在Profile的header头部会显示警告。
2. 检查文件系统：一般来讲建议Parquet文件格式加上Snappy压缩，除非有像磁盘空间太紧张这样的限制（此时可以用gzip压缩，但不常见）。 可以在scan片段中查找"File Formats:"
3. 检查文件/块的大小。有两个地方可以查看这个信息：一个实在在计划解释中的files=### size=###GB，另外一个是在后面的scan片段中:<# splits>/这样的描述。如果split lengths的值远远小于block size，则需要优化一下如何写文件的方式了。一般来讲缺省的block size的大小不需要调整（对于Hive/Spark为128MB，在Impala中是256MB），除非你试完了其他的优化手段。
4. 检查Execsummary，找到耗时最长的片段。
   1. 有执行倾斜（某个片段的平均执行时间远低于最大值）吗？通常数据的分布不是完美均匀的，因此每个节点的执行时间是不同的，，但任何超过2倍平均值的执行时间是需要注意的，比如优化数据大小、分布或者数据本身。如果看到一个节点对于各种查询都很慢，可能还是节点故障的原因。
   2. 是否这个耗时的步骤是必需的嘛？
   3. 即使是必需的，可以优化吗？比如把一个join转化为反规范化或嵌套类型的模型，或者将其实时数据准备实现为后台离线的ETL任务？使用视图或物化视图？
5. 如果在execsummary中没有看到任何大的时间，检查查询的时间轴，看看是否有长的启动时间或大的元数据DML时间？
6. 如果没有，在检查数据扫描。
   1. 现在可以考虑改变块大小，如果想提高并行性（同时处理更多的文件），可以减少块大小。如果表有很多列（通常大于200或300列）增加块大小可能有所帮助。
   2. 接下来是深入探究查询片段的各个不同指标，洞察缓慢的最终原因。比如，PerReadThreadRawHdfsThroughput是单个HDFS扫描的吞吐率，一般至少为100MB/s，否则可能是集群太忙或其他原因。注意这里的时间有些是墙上时间，有些是单个CPU时间，有些是并行时间总和。

https://www.cloudera.com/documentation/enterprise/5-7-x/topics/impala_runtime_filtering.html