Impala性能优化总结

  通常对于大数据量来说，Parquet文件格式是最佳的

  在impala外生成数据时，最好是text格式或者Avro，这样你就可以逐行的构建文件，到了impala之后，再通过简单的 insert ... select 语句将其转换为Parquet格式

  合适的分区策略可以对数据进行物理拆分，在查询的时候就可以忽略掉无用数据，提高查询效率，通常建议分区数量在3万以下(太多的分区也会造成元数据管理的性能下降)

  虽然使用string类型也可以作为分区key，因为分区key最后都是作为HDFS目录使用，但是使用最小的整数类型作为分区key可以降低内存消耗

  默认情况下，Impala的 insert ... select 语句创建的Parquet文件都是每个分区256M(在2.0之后改为1G了)，通过Impala写入的Parquet文件只有一个块，因而只能被一个机器当作一个单元进行处理。如果在你的Parquet表中只有一个或者几个分区，或者一个查询只能访问一个分区，那么你的性能会非常慢，因为没有足够的数据来利用Impala并发分布式查询的优势。

我们可以通过如下方式来降低到客户端的数据量:

  在执行之前使用EXPLAIN来查看逻辑规划，分析执行逻辑

  Impala join查询最简单的优化手段就是通过使用 compute stats 来收集join中每张表的统计信息，然后由Impala根据表的大小、列的唯一值数目等来自动优化查询。为了更加精确地获取每张表的统计信息，每次表的数据变更时(如执行 insert 、 load data 、 add partition 、或 drop partition 等)都要重新执行一遍 compute stats 。

  如果join查询中表的统计信息不全或者Impala选择的join顺序不是最优时，你可以在 select [distinct 、all] 之后指定 straight_join 来覆盖掉impala的join顺序如:

这样Impala就会使用查询语句中表的顺序来指导join的处理。

当使用 STRAIGHT_JOIn 技术时，你必须手动指定join查询中表的顺序而不是依赖于Impala优化器。Impala优化器使用特殊的手段来估算join中每个阶段的结果集大小，而对于手动指定顺序来说，可以根据如下方式开始，然后再手动调节来达到最优:

例如:如果你的表的大小如下: BIG 、 MEDIUM 、 SMALL 和 TINY ，那么你的顺序应该如此: BIG join TINY join SMALL join MEDIUM 。

   Impala查询优化器根据表的绝对或者相对大小来选择不同技术来执行join查询。默认情况下是 broadcast join ，右边的表都是小于左边的表，右边的表的内容会被分发到其他的查询节点中。

   另一种技术就是 partitioned join ，这种技术更加适用于大小差不多大的大表join，使用这种方式的话，每张表中的分区都会把数据分发到其他节点中，这样就可以这些数据子集就可以并发处理了。 broadcast 或者 partition join 的选择是根据 compute stats 采集到的可用统计指标来衡量的。对于指定查询语句，可以通过执行 EXPLAIN 就可以查看选用的是哪个join策略。

   当join中表或者列的统计指标不可用时，Impala将无统计指标的表认为统计指标都为0，这些表都将作为右表处理。

  想要了解Impala查询的高性能注意事项，可以阅读查询的 EXPLAIN 输出，你可以获取 EXPLAIN 的执行计划，而无须真正的执行query。

  想要查看一个查询的物理性能特性的概览，可以在执行查询之后立马在 impala-shell 中执行 SUMMARY 命令，输出的信息中将展示哪个阶段耗时最多，以及每一阶段估算的内存消耗、行数与实际的差异。

  想要了解查询的详细性能特征，可以在执行查询之后立马在 impala-shell 中执行 PROFILE 命令,这些底层的信息包括内存、CPU、I/O以及网络消耗的详细信息，因此只能在一个真实的查询之后才可用。

   EXPLAIN 语句概述了查询将执行的逻辑步骤，例如如何在节点间分配工作以及中间结果如何合并为最终结果, 这些你都可以在查询真正执行之前获得，你可以使用这些信息来检查查询是否会以某种非高效的方式执行。

自底向上读取EXPLAIN的输出:

EXPLAIN 也会在 PROFILE 结果的头部输出。

   SUMMARY 命令可以输出每一阶段的耗时，可以快速地了解查询的性能瓶颈，与 PROFILE 输出一样，它只能在查询之后才可用，并且显示实际的时间消耗。 SUMMARY 输出也会在PROFILE的头部输出的显示。

   PROFILE 语句将产生一个关于最近一次查询的底层报告的详细信息展示。与 EXPLAIN 不同，这些信息只在查询完成之后才会生成，它显示了每个节点上的物理详细信息如:读取的字节数，最大内存消耗等。

你可以根据这些信息来确定查询时I/O密集型，还是CPU密集型，网络是否导致瓶颈，是否某些节点性能差但是其它节点性能好等信息。

摘要： Impala ， 分区表 ， hdfs

分区表就是将某个分区的数据的单独存放，当使用 where 语句是针对某个分区查询时，impala只会在该分区扫描，大大减少了从磁盘读取的数据量。

使用 partitioned by 指定分区字段， 分区字段不进入表字段 ，分区字段和表字段在建表语句中都需要指定 字段类型

往分区中插入数据，使用 partition(...) 关键字指定该条数据在分区字段的值，直接顺序指定values作为该条数据各字段的值。

查看插入数据后的分区表数据，分区字段也存在在表数据中

查看impala分区表在hdfs上存储结构，整个表名文件夹下首先是分区的第一列yaer，等于year的值作为下一级目录名

打开分区的第一个字段目录，下一级目录是分区的第二个字段month

打开第二个分区字段目录，第三个分区字段目录是day

最后是第四个分区目录

分区表也可以从现有的hdfs分区目录结构中直接创建，在impala中创建外部表再指向hdfs路径，然后手动添加每条数据的分区。

创建hdfs表名目录（external_partition_test）和子目录作为分区（p=?）

创建三个csv格式数据文件

将三个文件分别put到三个分区目录下

在impala中创建外部分区表

此时查询此表无数据，手动add每条数据的分区值

在手动增加分区值后可以进行查询 *** 作

impala并发设置通过查了Impala的代码，出现这种报错一般是由于两种情况造成：

一种情况是可用内存不足；另一种情况是impalaservicepool已经满了。

Impala是Cloudera公司主导开发的新型查询系统，它提供SQL语义，能查询存储在Hadoop的HDFS和HBase中的PB级大数据。已有的Hive系统虽然也提供了SQL语义，但由于Hive底层执行使用的是MapReduce引擎，仍然是一个批处理过程，难以满足查询的交互性。相比之下，Impala的最大特点也是最大卖点就是它的快速。

优点:Impala不需要把中间结果写入磁盘，省掉了大量的I/O开销。省掉了MapReduce作业启动的开销。MapReduce启动task的速度很慢（默认每个心跳间隔是3秒钟），Impala直接通过相应的服务进程来进行作业调度，速度快了很多。

Impala完全抛弃了MapReduce这个不太适合做SQL查询的范式，而是像Dremel一样借鉴了MPP并行数据库的思想另起炉灶，因此可做更多的查询优化，从而省掉不必要的shuffle、sort等开销。通过使用LLVM来统一编译运行时代码，避免了为支持通用编译而带来的不必要开销。用C++实现，做了很多有针对性的硬件优化，例如使用SSE指令。使用了支持Datalocality的I/O调度机制，尽可能地将数据和计算分配在同一台机器上进行，减少了网络开销。

---