Impala合并小文件

set compression_codec=snappy

set parquet_file_size=512M

create table if not exists xx.xxx_tmp like xx.xxx

insert overwrite xx.xxx_tmp partition(etl_dt)

select * from xx.xxx where substring(etl_dt,1,7)='2020-02'

--删除指定巧御芹月的分区数

alter table xx.xxx drop partition(substring(etl_dt,1,7)='2020-02')

--将备份分区拆氏数据重新插孝毕入

insert into xx.xxx partition(etl_dt)

select * from xx.xxx_tmp

drop table if exists xx.xxx_tmp

set parquet_file_size=256M

https://www.pianshen.com/article/466643134/

  通常对于大数据量来说，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密集型，网络是否导致瓶颈，是否某些节点性能差但是其它节点性能好等信息。

---