1.为数据存储选择合适的文件格式(如:Parquet)
通常对于大数据量来说，Parquet文件格式是最佳的
2. 防止入库时产生大量的小文件(insert ... values会产生大量小文件，应该避免使用)
在impala外生成数据时，最好是text格式或者Avro，这样你就可以逐行的构建文件，到了impala之后，再通过简单的insert ... select语句将其转换为Parquet格式
3. 根据实际的数据量大小选择合适的分区粒度
合适的分区策略可以对数据进行物理拆分，在查询的时候就可以忽略掉无用数据，提高查询效率，通常建议分区数量在3万以下(太多的分区也会造成元数据管理的性能下降)
4. 为分区key选择最小的整数类型
虽然使用string类型也可以作为分区key，因为分区key最后都是作为HDFS目录使用，但是使用最小的整数类型作为分区key可以降低内存消耗
5. 选择合适的Parquet块大小
默认情况下，Impala的insert ... select语句创建的Parquet文件都是每个分区256M(在2.0之后改为1G了)，通过Impala写入的Parquet文件只有一个块，因而只能被一个机器当作一个单元进行处理。如果在你的Parquet表中只有一个或者几个分区，或者一个查询只能访问一个分区，那么你的性能会非常慢，因为没有足够的数据来利用Impala并发分布式查询的优势。
6. 在追求性能或者大数据量查询的时候，要先获取所需要的表的统计指标(如:执行compute stats)
7. 减少传输到client端的数据量
聚合(如 count、sum、max等)
过滤(如WHERE)
LIMIT
结果集禁止使用美化格式进行展示(在通过impala-shell展示结果时，添加这些可选参数:-B、 --output_delimiter)
8.通过EXPLAIN Plans和Query Profiles来了解Impala查询性能
想要了解Impala查询的高性能注意事项，可以阅读查询的EXPLAIN输出，你可以获取EXPLAIN的执行计划，而无须真正的执行query。
想要查看一个查询的物理性能特性的概览，可以在执行查询之后立马在impala-shell中执行SUMMARY命令，输出的信息中将展示哪个阶段耗时最多，以及每一阶段估算的内存消耗、行数与实际的差异。
想要了解查询的详细性能特征，可以在执行查询之后立马在impala-shell中执行PROFILE命令,这些底层的信息包括内存、CPU、I/O以及网络消耗的详细信息，因此只能在一个真实的查询之后才可用。
EXPLAIN --你可以获取EXPLAIN的执行计划，而无须真正的执行query
PROFILE --PROFILE语句将产生一个关于最近一次查询的底层报告的详细信息展示。与EXPLAIN不同，这些信息只在查询完成之后才会生成，它显示了每个节点上的物理详细信息如:读取的字节数，最大内存消耗等
SUMMAY --命令可以输出每一阶段的耗时，可以快速地了解查询的性能瓶颈,SUMMARY输出也会在PROFILE的头部输出的显示。
explain
sql sql profile/summay
需要根据具体的计划来调节SQL内容
9.join 的算法
1. hash join: 对于等值join, impala将采用hash的方式处理, 具体又分两种策略, broadcast 和 Shuffle.
broadcast join 非常适合右表是小表的情形, impala 先将右表复制到各个节点, 再和左表做join.
shuffle join, 也叫做partitioned join, 适合大表和大表关联. 注意 partitioned join 和右表的 partition 没有直接关系, impala 会将右表打散成N份, 发送到左表所在的节点, 然后作join.
2. nested loop join: 针对非等值join, impala将使用 nested loop join, 这时我们不能设置 SHUFFLE/BROADCAST hint, 也不能使用 spill disk 功能. impala的非等值join的效率较低, Vertica的效率非常高, Hive直接不支持.
SELECT STRAIGHT_JOIN select_list FROM
join_left_hand_table
JOIN [{ /* +BROADCAST */ | /* +SHUFFLE */ }]
join_right_hand_table
remainder_of_query;
/* +SHUFFLE */ 即 partitioned join, 是将要关联的两个表按照
/* +BROADCAST */ 因为当表和索引统计信息不可用时，默认方式
最佳实践
Impala执行引擎还不是那么智能, 多表join 的SQL最好还是按照下面的推荐的写法:
1. 最大的表应该放在表清单的最左边.
2. 多个join的查询语句, 应该将选择性最强的join放在最前面.
3. 定期对表收集统计信息, 或者在大量DML操作后主动收集统计信息.
4. 在一个单一的查询里面, 参加join的表个数尽量不要超过4个, 不然效率比较低下.