Cloudera Enterprise 6.1.x
文章目录
- Impala SET语句的查询选项
- ABORT_ON_ERROR（default FALSE）
- ALLOW_ERASURE_CODED_FILES（default FALSE）
- ALLOW_UNSUPPORTED_FORMATS （default FALSE）
- APPX_COUNT_DISTINCT （default FALSE）
- BATCH_SIZE（default 0）
- BUFFER_POOL_LIMIT （default MEM_LIMIT的80％）
- COMPRESSION_CODEC（default SNAPPY）
- COMPUTE_STATS_MIN_SAMPLE_SIZE（default 1GB）
- DEBUG_ACTION (default 空字符串)
- DECIMAL_V2 （default false）
- DEFAULT_JOIN_DISTRIBUTION_MODE
- DEFAULT_SPILLABLE_BUFFER_SIZE （default 2mb）
- DISABLE_CODEGEN （default false ）
- DISABLE_CODEGEN_ROWS_THRESHOLD （default 50000）
- DISABLE_ROW_RUNTIME_FILTERING （default false）
- DISABLE_STREAMING_PREAGGREGATIONS （default false ）
- DISABLE_UNSAFE_SPILLS （default false ）
- ENABLE_EXPR_REWRITES （default true ）
- EXEC_SINGLE_NODE_ROWS_THRESHOLD （default 100）
- EXEC_TIME_LIMIT_S （default 0）
- EXPLAIN_LEVEL（default 0）
- HBASE_CACHE_BLOCKS （default false）
- HBASE_CACHING （default 0）
- IDLE_SESSION_TIMEOUT （default 0）
- KUDU_READ_MODE （default "DEFAULT"）
- LIVE_PROGRESS （default false）
- LIVE_SUMMARY （default FALSE ）
- MAX_ERRORS （default 0 【meaning 1000 errors】）
- MAX_NUM_RUNTIME_FILTERS （default 10）
- MAX_ROW_SIZE（default 524288 【512 KB】）
- MAX_SCAN_RANGE_LENGTH （default 0）
- MEM_LIMIT （default 0【unlimited】）
- MIN_SPILLABLE_BUFFER_SIZE（default 65536 【64 KB】）
- MT_DOP (default 0)
- NUM_NODES (default 0)
- NUM_SCANNER_THREADS (default 0)
- OPTIMIZE_PARTITION_KEY_SCANS
- PARQUET_COMPRESSION_CODEC （已过时）
- PARQUET_ANNOTATE_STRINGS_UTF8 （default false ）
Impala SET语句的查询选项
ABORT_ON_ERROR（default FALSE）
启用此选项后，Impala会在任何节点遇到错误时立即取消查询，可能返回不完整的结果。
默认情况下此选项是被禁用的，以帮助在发生错误时收集最大诊断信息
ALLOW_ERASURE_CODED_FILES（default FALSE）
ALLOW_UNSUPPORTED_FORMATS （default FALSE）
此查询选项已在CDH 6.1中删除
APPX_COUNT_DISTINCT （default FALSE）
启用此选项后，impala 会将 COUNT(DISTINCT) 转换为 NDV()，此时得到的计数是近似的而不是精确的。
BATCH_SIZE（default 0）
SQL运算符一次计算的行数。未指定或大小为0时，使用预定义的默认大小。使用大量数据可以提高响应速度，尤其是对于扫描操作，代价是占用更高的内存。
默认值0，意味着预定义的大小为1024。
此选项主要用于Impala开发期间的测试，或在Cloudera支持的指导下使用。
BUFFER_POOL_LIMIT （default MEM_LIMIT的80％）
定义查询可以从内部缓冲池分配的内存量限制。此限制的值适用于每个主机上的内存，而不是群集中的聚合内存。通常不会被用户更改，除非在查询期间诊断出内存不足错误。
此选项的默认设置是MEM_LIMIT的80％，如果查询遇到内存不足错误，请考虑将BUFFER_POOL_LIMIT设置降低到小于MEM_LIMIT设置的80％。
-- 设置一个绝对值
set buffer_pool_limit=8GB;
-- 设置一个相对值，MEM_LIMIT 值的 80%
set buffer_pool_limit=80%;
COMPRESSION_CODEC（default SNAPPY）
当Impala使用INSERT语句写入Parquet数据文件时，基础方式由 COMPRESSION_CODEC 选项控制。
注意：在Impala 2.0之前，此选项名为PARQUET_COMPRESSION_CODEC。 在Impala 2.0及更高版本中，无法识别PARQUET_COMPRESSION_CODEC名称。 对于新代码，使用更通用的名称COMPRESSION_CODEC。
语法：
SET COMPRESSION_CODEC=codec_name;
此查询选项的允许值为SNAPPY（默认值），GZIP和NONE,选项值不区分大小写。使用 COMPRESSION_CODEC = NONE 创建的Parquet文件通常仍小于原始数据
如果该选项设置为无法识别的值，则由于无效选项设置而导致的各种查询都将失败，而不仅仅是涉及Parquet表的查询。BZIP2的值也能被识别，但与Parquet表不兼容。
set compression_codec=gzip;
insert into parquet_table_highly_compressed select * from t1;
set compression_codec=snappy;
insert into parquet_table_compression_plus_fast_queries select * from t1;
set compression_codec=none;
insert into parquet_table_no_compression select * from t1;
set compression_codec=foo;
select * from t1 limit 5;
ERROR: Invalid compression codec: foo
COMPUTE_STATS_MIN_SAMPLE_SIZE（default 1GB）
COMPUTE_STATS_MIN_SAMPLE_SIZE 查询选项指定在 COMPUTE STATS TABLESAMPLE 中扫描的最小字节数。
DEBUG_ACTION (default 空字符串)
设置自定义问题条件，用于内部Cloudera调试和故障排除。
DECIMAL_V2 （default false）
用于修改与 DECIMAL 数据类型相关的行为。
目前不支持此查询选项。 其精确行为目前尚未定义，未来可能会发生变化。
DEFAULT_JOIN_DISTRIBUTION_MODE
根据 Impala COMPUTE STATS 语句生成的表统计信息优化 join 查询。默认情况下，当 join 查询中涉及的表没有数据时，Impala使用“广播”技术将表的全部内容传输到参与查询的所有执行程序节点。
如果联接中涉及的一个表具有统计信息而另一个表没有统计信息，则会广播没有统计信息的表。
如果两个表都缺少统计信息，则会广播连接右侧的表。
当涉及的表相对较小时，此行为是适当的，但如果正在广播的表很大，则可能导致过多的网络，内存和CPU开销。
由于Impala查询经常涉及非常大的表，并且此类表的 join 可能导致溢出或内存不足错误，因此设置 DEFAULT_JOIN_DISTRIBUTION_MODE = SHUFFLE 允许您覆盖默认行为。
shuffle join 机制使用散列算法划分连接查询中涉及的每个表的相应行，并将行的子集发送到其他节点以进行处理。
设置和部署集群时，建议设置 DEFAULT_JOIN_DISTRIBUTION_MODE = SHUFFLE，因为如果查询计划基于不完整的信息，则不太可能导致严重后果，例如溢出或内存不足错误。
允许的值为 BROADCAST（相当于0）或 SHUFFLE（相当于1）。
以下示例演示了此查询选项的每个设置项：
1、十亿行的大表
-- 创建一个十亿行的表.
create table big_table stored as parquet
as select * from huge_table limit 1e9;
-- 对于没有统计数据的大表，
- shuffle join机制是合适的。
set default_join_distribution_mode=shuffle;
...join queries involving the big table...
2、百行的小表
-- 创建一个百行表。
create table tiny_table stored as parquet
as select * from huge_table limit 100;
-- 对于没有统计数据的小表，
- 广播机制是合适的。
set default_join_distribution_mode=broadcast;
...join queries involving the tiny table...
3、统计表信息进行优化
compute stats tiny_table;
compute stats big_table;
-- 计算统计信息后，查询选项对涉及这些表的连接查询没有影响。
-- Impala可以通过检查每个表的行大小，基数等来确定连接查询每一侧的绝对大小和相对大小。
...join queries involving both of these tables...
DEFAULT_SPILLABLE_BUFFER_SIZE （default 2mb）
指定使用的内存缓冲区的默认大小，例如，针对没有统计信息的大型表或大型连接操作的查询。
指定参数大小单位可以为兆字节或前兆字节兆字节（m或mb）、千兆字节（g或gb）。 如果指定无法识别格式的值，则后续查询将失败并显示错误。
此查询选项设置内部缓冲区大小的上限，该大小可在溢出到磁盘操作期间使用。查询计划程序选择缓冲区的实际大小。
如果整体查询性能受溢出所需时间的限制，请考虑增加 DEFAULT_SPILLABLE_BUFFER_SIZE 设置。
较大的缓冲区大小会导致Impala向存储设备发出更大的I / O请求，这可能会导致更高的吞吐量，尤其是在磁盘上。
要通过限制可填充缓冲区大小来确定此设置的值是否有效，可以查看查询计划为特定查询选择缓冲区大小。
set default_spillable_buffer_size=4MB;
DISABLE_CODEGEN （default false ）
DISABLE_CODEGEN 是一个调试选项，它用于解决Impala运行时代码生成的问题。
如果查询失败并显示“非法指令”或其他特定于硬件的消息，请尝试设置DISABLE_CODEGEN = true并再次运行查询。
如果仅在启用 DISABLE_CODEGEN 选项时查询成功，请将问题提交给Cloudera支持并在问题报告中包含该详细信息。
开启 DISABLE_CODEGEN = true 时，大多数查询的运行速度会明显变慢。
在Impala 2.10及更高版本中，DISABLE_CODEGEN_ROWS_THRESHOLD优化会自动禁用小型查询的codegen，因为短期运行的查询可以在没有codegen开销的情况下运行得更快。
DISABLE_CODEGEN_ROWS_THRESHOLD （default 50000）
此设置控制截止点（根据每个Impala守护程序处理的行数），低于该截止点，Impala会禁用整个查询的本机代码生成。本机代码生成对于处理很多行的查询非常有用，因为它减少了处理每一行所花费的时间。但是，生成本机代码会增加查询启动的延迟。因此，为处理相对少量数据的查询自动禁用codegen可以缩短查询响应时间。
此设置适用于可以通过表和列统计信息或LIMIT子句的存在准确确定处理的行数的查询。 如果Impala无法准确估计行数，则此设置不适用。
如果查询使用复杂数据类型STRUCT，ARRAY或MAP，则无论DISABLE_CODEGEN_ROWS_THRESHOLD设置如何，都不会自动禁用codegen。
SET DISABLE_CODEGEN_ROWS_THRESHOLD=number_of_rows
DISABLE_ROW_RUNTIME_FILTERING （default false）
DISABLE_ROW_RUNTIME_FILTERING 查询选项缩小了运行时筛选功能的范围。 查询仍然会动态修剪分区，但不会将过滤逻辑应用于分区中的各个行。仅适用于对Parquet表的查询。 对于其他文件格式，Impala仅修剪分区级别，而不是单个行。
Impala会自动评估每行过滤器是否有效减少中间数据量。 因此，通常仅在极少数情况下才需要此选项，其中Impala无法准确确定每行筛选对查询的有效性。
由于运行时筛选功能主要应用于资源密集型和长时间运行的查询，因此仅在调整涉及大型分区表和涉及大型表的联接的长时间运行查询时调整此查询选项。
由于此设置仅在特定情况下提高查询性能，具体取决于查询特征和数据分布，因此仅在通过基准测试确定它可以提高特定昂贵查询的性能时才使用它。 考虑在昂贵的查询之前设置此查询选项，然后立即取消设置。
文件格式考虑因素
此查询选项仅适用于使用Parquet文件格式对基于HDFS的表的查询。
kudu考虑因素
当应用于涉及Kudu表的查询时，此选项将关闭Kudu表的所有运行时筛选。
DISABLE_STREAMING_PREAGGREGATIONS （default false ）
关闭CDH 5.7 / Impala 2.5及更高版本中提供的“streaming preaggregation”优化。
此优化减少了对具有很少或没有重复值的列执行聚合操作的查询所执行的不必要的工作，例如DISTINCT id_column或GROUP BY unique_column。如果优化导致使用聚合函数的现有查询异常，则可以根据需要将其关闭。
在CDH 5.7.0 / Impala 2.5.0中，只有值1启用该选项，无法识别值true。 IMPALA-3334 问题跟踪此限制，该问题会显示得到解决的版本。
通常，需要启用此选项的查询涉及非常大量的聚合值，例如在每个工作节点上处理十亿或更多不同的字段。
DISABLE_UNSAFE_SPILLS （default false ）
如果您希望查询在超过 Impala 内存限制时失败，而不是将临时数据写入磁盘，请启用此选项。
“溢出”到磁盘的查询通常会成功完成，而在早期的Impala版本中，它们会失败。 但是，由于缺少统计信息或低效的连接子句而导致内存需求过高的查询可能变得非常慢，因此您希望自动取消它们并通过标准Impala调优技术减少内存使用量。
此选项仅防止“不安全”溢出操作，这意味着一个或多个表缺少统计信息，或者查询不包含为连接设置最有效机制或INSERT … SELECT到分区表的提示。
有关使用join，ORDER BY，GROUP BY，DISTINCT，聚合函数或分析函数处理大型结果集的查询的“溢出到磁盘”功能的信息，请参阅“溢出到磁盘的SQL操作”。
ENABLE_EXPR_REWRITES （default true ）
ENABLE_EXPR_REWRITES查询选项控制是启用还是禁用查询编译时优化。 这些优化将表达式树重写为更紧凑和优化的形式，有助于避免在运行时进行冗余表达式评估。
EXEC_SINGLE_NODE_ROWS_THRESHOLD （default 100）
此设置控制截止点（根据扫描的行数），Impala将查询视为“小”查询，关闭并行执行和本机代码生成等优化。 这些优化的开销适用于涉及大量数据的查询，但跳过涉及少量数据的查询是有意义的。 减少小型查询的开销使Impala能够更快地完成它们，从而使得许可控制插槽，CPU，内存等可用于资源密集型查询。
SET EXEC_SINGLE_NODE_ROWS_THRESHOLD=number_of_rows
此设置适用于可以通过表和列统计信息或LIMIT子句的存在准确确定处理的行数的查询。如果Impala无法准确估计行数，则此设置不适用。
在CDH 5.5 / Impala 2.3及更高版本中，Impala支持复杂数据类型STRUCT，ARRAY和MAP，如果查询引用这些类型的任何列，则无论EXEC_SINGLE_NODE_ROWS_THRESHOLD设置如何，都会为该查询关闭小查询优化。
EXEC_TIME_LIMIT_S （default 0）
设置查询执行的时间限制。 如果查询在时间限制到期时仍在执行，则会自动取消。 该选项目的在于防止执行时间超过预期的失控查询。
例如，Impala管理员可以为资源池设置默认值EXEC_TIME_LIMIT_S = 3600，以自动终止执行时间超过一小时的查询。 然后，如果用户意外运行执行超过一小时的大型查询，则会在时间限制到期后自动终止以释放资源。 如果用户不希望将默认EXEC_TIME_LIMIT_S值应用于特定查询或会话，则可以覆盖每个查询或每个会话的默认值。
SET EXEC_TIME_LIMIT_S=seconds;
时间限制仅在查询执行后才开始。 计划查询，调度查询或准入控制所花费的时间不计入执行时间限制。 SELECT语句有资格自动取消，直到客户端获取了所有结果行。 在DML语句完成之前，DML查询有资格自动取消。
EXPLAIN_LEVEL（default 0）
控制EXPLAIN语句输出中提供的详细信息量。 基本输出可以帮助您识别高级性能问题，例如扫描比预期更多的数据或更多分区。 更高级别的详细信息显示了中间结果如何在节点之间流动以及如何在分布式查询中实现不同的SQL操作（如ORDER BY，GROUP BY，join和WHERE子句）。
此选项允许的数值范围是0到3：
0 or MINIMAL: 主要用于在非常长的查询中检查 join 顺序，其中常规EXPLAIN输出太长而无法轻松读取。
1 or STANDARD: 默认的详细级别，显示分布式查询的工作逻辑方式。
2 or EXTENDED: 包括有关查询计划程序如何在其决策过程中使用统计信息的其他详细信息，通过收集统计信息，使用查询提示，添加或删除谓词等来了解如何调整查询。
3 or VERBOSE: 最高级别的详细信息，显示每个节点内的“查询片段”。 这个额外的细节主要用于Impala本身内的低级性能测试和调优，而不是用于在用户级别重写SQL代码。
更改此选项的值可控制EXPLAIN语句输出中的详细信息量。 当您需要确认查询的工作是否按照您期望的方式分发时，来自级别2或级别3的扩展信息特别有用，特别是对于大多数资源密集型操作（例如针对大型表的查询，查询） 针对具有大量分区的表，以及Parquet表的插入操作。
与往常一样，从下到上阅读EXPLAIN输出。 最低行表示查询的初始工作（扫描数据文件），中间的行表示在每个节点上完成的计算以及中间结果如何从一个节点传输到另一个节点，最上面的行表示返回的最终结果 到协调器节点。
在所有EXPLAIN级别，如果查询中的任何表缺少统计信息，则计划将包含警告。 使用COMPUTE STATS语句收集每个表的统计信息并禁止显示此警告。 有关统计信息如何帮助查询性能的详细信息，请参阅表和列统计信息
impala-shell 中的 PROFILE 命令始终以显示完整详细信息的解释计划开始，与 EXPLAIN_LEVEL = 3 相同。 在解释计划出现执行摘要之后，与impala-shell中的SUMMARY命令生成的输出相同。
示例展示：
这些示例使用一个简单的空表来说明如何在EXPLAIN输出中显示查询计划的基本方面：
[localhost:21000] > create table t1 (x int, s string);
[localhost:21000] > set explain_level=1;
[localhost:21000] > explain select count(*) from t1;
+------------------------------------------------------------------------+
| Explain String |
+------------------------------------------------------------------------+
| Estimated Per-Host Requirements: Memory=10.00MB VCores=1 |
| WARNING: The following tables are missing relevant table and/or column |
| statistics. |
| explain_plan.t1 |
| |
| 03:AGGREGATE [MERGE FINALIZE] |
| | output: sum(count(*)) |
| | |
| 02:EXCHANGE [PARTITION=UNPARTITIONED] |
| | |
| 01:AGGREGATE |
| | output: count(*) |
| | |
| 00:SCAN HDFS [explain_plan.t1] |
| partitions=1/1 size=0B |
+------------------------------------------------------------------------+
[localhost:21000] > explain select * from t1;
+------------------------------------------------------------------------+
| Explain String |
+------------------------------------------------------------------------+
| Estimated Per-Host Requirements: Memory=-9223372036854775808B VCores=0 |
| WARNING: The following tables are missing relevant table and/or column |
| statistics. |
| explain_plan.t1 |
| |
| 01:EXCHANGE [PARTITION=UNPARTITIONED] |
| | |
| 00:SCAN HDFS [explain_plan.t1] |
| partitions=1/1 size=0B |
+------------------------------------------------------------------------+
[localhost:21000] > set explain_level=2;
[localhost:21000] > explain select * from t1;
+------------------------------------------------------------------------+
| Explain String |
+------------------------------------------------------------------------+
| Estimated Per-Host Requirements: Memory=-9223372036854775808B VCores=0 |
| WARNING: The following tables are missing relevant table and/or column |
| statistics. |
| explain_plan.t1 |
| |
| 01:EXCHANGE [PARTITION=UNPARTITIONED] |
| | hosts=0 per-host-mem=unavailable |
| | tuple-ids=0 row-size=19B cardinality=unavailable |
| | |
| 00:SCAN HDFS [explain_plan.t1, PARTITION=RANDOM] |
| partitions=1/1 size=0B |
| table stats: unavailable |
| column stats: unavailable |
| hosts=0 per-host-mem=0B |
| tuple-ids=0 row-size=19B cardinality=unavailable |
+------------------------------------------------------------------------+
[localhost:21000] > set explain_level=3;
[localhost:21000] > explain select * from t1;
+------------------------------------------------------------------------+
| Explain String |
+------------------------------------------------------------------------+
| Estimated Per-Host Requirements: Memory=-9223372036854775808B VCores=0 |
| WARNING: The following tables are missing relevant table and/or column |
| statistics. |
| explain_plan.t1 |
| |
| F01:PLAN FRAGMENT [PARTITION=UNPARTITIONED] |
| 01:EXCHANGE [PARTITION=UNPARTITIONED] |
| hosts=0 per-host-mem=unavailable |
| tuple-ids=0 row-size=19B cardinality=unavailable |
| |
| F00:PLAN FRAGMENT [PARTITION=RANDOM] |
| DATASTREAM SINK [FRAGMENT=F01, EXCHANGE=01, PARTITION=UNPARTITIONED] |
| 00:SCAN HDFS [explain_plan.t1, PARTITION=RANDOM] |
| partitions=1/1 size=0B |
| table stats: unavailable |
| column stats: unavailable |
| hosts=0 per-host-mem=0B |
| tuple-ids=0 row-size=19B cardinality=unavailable |
+------------------------------------------------------------------------+
正如警告消息所示，Impala执行高效查询计划所需的大部分信息，以及您要了解查询的性能特征，需要为表运行COMPUTE STATS语句：
[localhost:21000] > compute stats t1;
+-----------------------------------------+
| summary |
+-----------------------------------------+
| Updated 1 partition(s) and 2 column(s). |
+-----------------------------------------+
[localhost:21000] > explain select * from t1;
+------------------------------------------------------------------------+
| Explain String |
+------------------------------------------------------------------------+
| Estimated Per-Host Requirements: Memory=-9223372036854775808B VCores=0 |
| |
| F01:PLAN FRAGMENT [PARTITION=UNPARTITIONED] |
| 01:EXCHANGE [PARTITION=UNPARTITIONED] |
| hosts=0 per-host-mem=unavailable |
| tuple-ids=0 row-size=20B cardinality=0 |
| |
| F00:PLAN FRAGMENT [PARTITION=RANDOM] |
| DATASTREAM SINK [FRAGMENT=F01, EXCHANGE=01, PARTITION=UNPARTITIONED] |
| 00:SCAN HDFS [explain_plan.t1, PARTITION=RANDOM] |
| partitions=1/1 size=0B |
| table stats: 0 rows total |
| column stats: all |
| hosts=0 per-host-mem=0B |
| tuple-ids=0 row-size=20B cardinality=0 |
+------------------------------------------------------------------------+
连接和其他复杂的多部分查询是您最常需要检查EXPLAIN输出并自定义输出中的详细信息量的查询。 此示例显示三向连接查询的默认EXPLAIN输出，然后使用[SHUFFLE]提示的等效输出更改前两个表之间从广播连接到随机连接的连接机制。
[localhost:21000] > set explain_level=1;
[localhost:21000] > explain select one.*, two.*, three.* from t1 one, t1 two, t1 three where one.x = two.x and two.x = three.x;
+---------------------------------------------------------+
| Explain String |
+---------------------------------------------------------+
| Estimated Per-Host Requirements: Memory=4.00GB VCores=3 |
| |
| 07:EXCHANGE [PARTITION=UNPARTITIONED] |
| | |
| 04:HASH JOIN [INNER JOIN, BROADCAST] |
| | hash predicates: two.x = three.x |
| | |
| |--06:EXCHANGE [BROADCAST] |
| | | |
| | 02:SCAN HDFS [explain_plan.t1 three] |
| | partitions=1/1 size=0B |
| | |
| 03:HASH JOIN [INNER JOIN, BROADCAST] |
| | hash predicates: one.x = two.x |
| | |
| |--05:EXCHANGE [BROADCAST] |
| | | |
| | 01:SCAN HDFS [explain_plan.t1 two] |
| | partitions=1/1 size=0B |
| | |
| 00:SCAN HDFS [explain_plan.t1 one] |
| partitions=1/1 size=0B |
+---------------------------------------------------------+
[localhost:21000] > explain select one.*, two.*, three.*
> from t1 one join [shuffle] t1 two join t1 three
> where one.x = two.x and two.x = three.x;
+---------------------------------------------------------+
| Explain String |
+---------------------------------------------------------+
| Estimated Per-Host Requirements: Memory=4.00GB VCores=3 |
| |
| 08:EXCHANGE [PARTITION=UNPARTITIONED] |
| | |
| 04:HASH JOIN [INNER JOIN, BROADCAST] |
| | hash predicates: two.x = three.x |
| | |
| |--07:EXCHANGE [BROADCAST] |
| | | |
| | 02:SCAN HDFS [explain_plan.t1 three] |
| | partitions=1/1 size=0B |
| | |
| 03:HASH JOIN [INNER JOIN, PARTITIONED] |
| | hash predicates: one.x = two.x |
| | |
| |--06:EXCHANGE [PARTITION=HASH(two.x)] |
| | | |
| | 01:SCAN HDFS [explain_plan.t1 two] |
| | partitions=1/1 size=0B |
| | |
| 05:EXCHANGE [PARTITION=HASH(one.x)] |
| | |
| 00:SCAN HDFS [explain_plan.t1 one] |
| partitions=1/1 size=0B |
+---------------------------------------------------------+
对于涉及许多不同表的连接，默认EXPLAIN输出可能会延伸多个页面，您关注的唯一细节可能是连接顺序以及用于连接每对表的机制（广播或随机播放）。 在这种情况下，您可以将EXPLAIN_LEVEL设置为其最低值0，以便仅关注每个阶段的连接顺序和连接机制。 以下示例显示如何对第一个和第二个连接表中的行进行散列并在群集的节点之间进行划分以进行进一步过滤; 然后将第三个表的全部内容广播到所有节点以进行连接处理的最后阶段。
[localhost:21000] > set explain_level=0;
[localhost:21000] > explain select one.*, two.*, three.*
> from t1 one join [shuffle] t1 two join t1 three
> where one.x = two.x and two.x = three.x;
+---------------------------------------------------------+
| Explain String |
+---------------------------------------------------------+
| Estimated Per-Host Requirements: Memory=4.00GB VCores=3 |
| |
| 08:EXCHANGE [PARTITION=UNPARTITIONED] |
| 04:HASH JOIN [INNER JOIN, BROADCAST] |
| |--07:EXCHANGE [BROADCAST] |
| | 02:SCAN HDFS [explain_plan.t1 three] |
| 03:HASH JOIN [INNER JOIN, PARTITIONED] |
| |--06:EXCHANGE [PARTITION=HASH(two.x)] |
| | 01:SCAN HDFS [explain_plan.t1 two] |
| 05:EXCHANGE [PARTITION=HASH(one.x)] |
| 00:SCAN HDFS [explain_plan.t1 one] |
+---------------------------------------------------------+
HBASE_CACHE_BLOCKS （default false）
设置此选项等同于在HBase Java应用程序中调用类org.apache.hadoop.hbase.client.Scan的setCacheBlocks方法。 有助于控制HBase RegionServer上的内存压力，以及HBASE_CACHING查询选项。
HBASE_CACHING （default 0）
设置此选项等同于在HBase Java应用程序中调用类org.apache.hadoop.hbase.client.Scan的setCaching方法。 有助于控制HBase RegionServer上的内存压力，以及HBASE_CACHE_BLOCKS查询选项。
IDLE_SESSION_TIMEOUT （default 0）
IDLE_SESSION_TIMEOUT查询选项设置取消空闲会话的时间（以秒为单位）。 如果该会话中的任何查询都没有发生任何活动，则会话处于空闲状态，并且会话尚未启动任何新查询。 会话过期后，您无法向其发出任何新的查询请求。 会话保持打开状态，但您可以执行的唯一操作是关闭它。
IDLE_SESSION_TIMEOUT查询选项允许JDBC / ODBC连接将会话超时设置为SET语句的查询选项。
SET IDLE_SESSION_TIMEOUT=seconds;
KUDU_READ_MODE （default “DEFAULT”）
KUDU_READ_MODE查询选项允许您为Kudu表的扫描设置所需的一致性级别。
该选项支持以下值：
“DEFAULT”: 使用启动标志的值 --kudu_read_mode。
“READ_LATEST”: 通常称为Read Committed隔离模式，在此模式下，Kudu不为此模式提供一致性保证，除了所有返回的行都在某个时刻提交。
“READ_AT_SNAPSHOT”: Kudu将拍摄数据当前状态的快照，并在快照等待正在进行的写入完成之后对快照执行扫描。 这在单个Impala会话中提供了“Read Your Writes”一致性。
LIVE_PROGRESS （default false）
当LIVE_PROGRESS查询选项设置为TRUE时，Impala会显示一个交互式进度条，大致显示通过impala-shell命令提交的查询已完成的处理百分比。 查询完成后，进度条将从impala-shell控制台输出中删除。
从CDH 6.1开始，摘要输出还包括排队状态，该状态包括查询是否已排队以及最新的排队原因。
您可以通过使用 --live_progress 命令行选项启动shell，在impala-shell中启用此查询选项。 您仍然可以通过 SET 命令在shell中通过此设置关闭或再次打开。
此查询选项的输出将打印为标准错误。 输出仅以交互模式显示，即不使用 -q 或 -f 选项时。
因为百分比完整数字是使用在读取表数据时发生和完成的“扫描范围”的数量计算的，所以进度条可能在查询完全完成之前达到100％。 例如，查询可能在读取所有表数据后执行聚合。 如果您的许多查询属于此类别，请考虑使用 LIVE_SUMMARY 选项来进行更精细的进度报告。
在 COMPUTE STATS 操作期间，LIVE_PROGRESS 和 LIVE_SUMMARY 不会产生任何输出。
因为LIVE_PROGRESS和LIVE_SUMMARY查询选项仅在impala-shell解释器中可用：
- 您无法使用JDBC或ODBC接口通过SQL SET语句更改这些查询选项。impala-shell中的SET命令将这些名称识别为仅限shell的选项。
- 在CDH 5.5之前的系统上使用impala-shell连接到运行在CDH 5.5或更高版本系统上的Impala时要小心。较旧的impala-shell无法识别这些查询选项名称。 在要使用这些查询选项的系统上升级impala-shell。
- 同样，impala-shell命令依赖于CDH 5.5 / Impala 2.3及更高版本中仅提供的一些信息来准备实时进度报告和查询摘要。当impala-shell连接到运行旧版Impala的集群时，LIVE_PROGRESS和LIVE_SUMMARY查询选项无效。
示例
[localhost:21000] > set live_progress=true;
LIVE_PROGRESS set to true
[localhost:21000] > select count(*) from customer;
+----------+
| count(*) |
+----------+
| 150000 |
+----------+
[localhost:21000] > select count(*) from customer t1 cross join customer t2;
[################################### ] 50%
[######################################################################] 100%
LIVE_SUMMARY （default FALSE ）
当LIVE_SUMMARY查询选项设置为TRUE时，Impala将显示与通过impala-shell命令提交的查询的SUMMARY命令相同的输出，并在查询过程中实时更新测量值。 查询完成后，最终的SUMMARY输出在impala-shell控制台输出中仍然可见。
您可以通过使用 --live_summary 命令行选项启动shell来在 impala-shell 中启用此查询选项。 您仍然可以通过SET命令在shell中关闭此设置并再次打开。
实时摘要输出可用于评估长时间运行的查询，评估执行的哪个阶段占用最多时间，或者某些主机在某些操作中花费的时间比其他主机长得多，从而拖累整体性能。 通过实时提供信息，此功能可让您确定在取消比正常时间长得多的查询之前要采取的操作。
例如，您可能会看到HDFS扫描阶段需要很长时间，因此需要重新审视架构设计中与性能相关的方面，例如构建分区表，切换到Parquet文件格式，为表运行COMPUTE STATS语句等等。 或者，您可能会看到所有主机执行某个查询阶段的平均时间和最长时间之间存在很大差异，因此需要调查一个特定主机是否需要更多内存或是否遇到网络问题。
此查询选项的输出将打印为标准错误。 输出仅以交互模式显示，即不使用-q或-f选项时。
在COMPUTE STATS操作期间，LIVE_PROGRESS 和 LIVE_SUMMARY 查询选项不会产生任何输出。
因为LIVE_PROGRESS和LIVE_SUMMARY查询选项仅在impala-shell解释器中可用：
- 您无法使用JDBC或ODBC接口通过SQL SET语句更改这些查询选项。impala-shell中的SET命令将这些名称识别为仅限shell的选项。
- 在CDH 5.5之前的系统上使用impala-shell连接到运行在CDH 5.5或更高版本系统上的Impala时要小心。较旧的impala-shell无法识别这些查询选项名称。 在要使用这些查询选项的系统上升级impala-shell。
- 同样，impala-shell命令依赖于CDH 5.5 / Impala 2.3及更高版本中仅提供的一些信息来准备实时进度报告和查询摘要。当impala-shell连接到运行旧版Impala的集群时，LIVE_PROGRESS和LIVE_SUMMARY查询选项无效。
示例
以下示例显示了在查询过程中显示的一系列LIVE_SUMMARY报告，显示了数字如何增加以显示分布式查询的不同阶段的进度。 在impala-shell中执行相同操作时，任何时候都只显示一个报告，每次更新都会覆盖以前的数字。
[localhost:21000] > set live_summary=true;
LIVE_SUMMARY set to true
[localhost:21000] > select count(*) from customer t1 cross join customer t2;
+---------------------+--------+----------+----------+---------+------------+----------+---------------+-----------------------+
| Operator | #Hosts | Avg Time | Max Time | #Rows | Est. #Rows | Peak Mem | Est. Peak Mem | Detail |
+---------------------+--------+----------+----------+---------+------------+----------+---------------+-----------------------+
| 06:AGGREGATE | 0 | 0ns | 0ns | 0 | 1 | 0 B | -1 B | FINALIZE |
| 05:EXCHANGE | 0 | 0ns | 0ns | 0 | 1 | 0 B | -1 B | UNPARTITIONED |
| 03:AGGREGATE | 0 | 0ns | 0ns | 0 | 1 | 0 B | 10.00 MB | |
| 02:NESTED LOOP JOIN | 0 | 0ns | 0ns | 0 | 22.50B | 0 B | 0 B | CROSS JOIN, BROADCAST |
| |--04:EXCHANGE | 0 | 0ns | 0ns | 0 | 150.00K | 0 B | 0 B | BROADCAST |
| | 01:SCAN HDFS | 1 | 503.57ms | 503.57ms | 150.00K | 150.00K | 24.09 MB | 64.00 MB | tpch.customer t2 |
| 00:SCAN HDFS | 0 | 0ns | 0ns | 0 | 150.00K | 0 B | 64.00 MB | tpch.customer t1 |
+---------------------+--------+----------+----------+---------+------------+----------+---------------+-----------------------+
+---------------------+--------+----------+----------+---------+------------+----------+---------------+-----------------------+
| Operator | #Hosts | Avg Time | Max Time | #Rows | Est. #Rows | Peak Mem | Est. Peak Mem | Detail |
+---------------------+--------+----------+----------+---------+------------+----------+---------------+-----------------------+
| 06:AGGREGATE | 0 | 0ns | 0ns | 0 | 1 | 0 B | -1 B | FINALIZE |
| 05:EXCHANGE | 0 | 0ns | 0ns | 0 | 1 | 0 B | -1 B | UNPARTITIONED |
| 03:AGGREGATE | 1 | 0ns | 0ns | 0 | 1 | 20.00 KB | 10.00 MB | |
| 02:NESTED LOOP JOIN | 1 | 17.62s | 17.62s | 81.14M | 22.50B | 3.23 MB | 0 B | CROSS JOIN, BROADCAST |
| |--04:EXCHANGE | 1 | 26.29ms | 26.29ms | 150.00K | 150.00K | 0 B | 0 B | BROADCAST |
| | 01:SCAN HDFS | 1 | 503.57ms | 503.57ms | 150.00K | 150.00K | 24.09 MB | 64.00 MB | tpch.customer t2 |
| 00:SCAN HDFS | 1 | 247.53ms | 247.53ms | 1.02K | 150.00K | 24.39 MB | 64.00 MB | tpch.customer t1 |
+---------------------+--------+----------+----------+---------+------------+----------+---------------+-----------------------+
+---------------------+--------+----------+----------+---------+------------+----------+---------------+-----------------------+
| Operator | #Hosts | Avg Time | Max Time | #Rows | Est. #Rows | Peak Mem | Est. Peak Mem | Detail |
+---------------------+--------+----------+----------+---------+------------+----------+---------------+-----------------------+
| 06:AGGREGATE | 0 | 0ns | 0ns | 0 | 1 | 0 B | -1 B | FINALIZE |
| 05:EXCHANGE | 0 | 0ns | 0ns | 0 | 1 | 0 B | -1 B | UNPARTITIONED |
| 03:AGGREGATE | 1 | 0ns | 0ns | 0 | 1 | 20.00 KB | 10.00 MB | |
| 02:NESTED LOOP JOIN | 1 | 61.85s | 61.85s | 283.43M | 22.50B | 3.23 MB | 0 B | CROSS JOIN, BROADCAST |
| |--04:EXCHANGE | 1 | 26.29ms | 26.29ms | 150.00K | 150.00K | 0 B | 0 B | BROADCAST |
| | 01:SCAN HDFS | 1 | 503.57ms | 503.57ms | 150.00K | 150.00K | 24.09 MB | 64.00 MB | tpch.customer t2 |
| 00:SCAN HDFS | 1 | 247.59ms | 247.59ms | 2.05K | 150.00K | 24.39 MB | 64.00 MB | tpch.customer t1 |
+---------------------+--------+----------+----------+---------+------------+----------+---------------+-----------------------+
MAX_ERRORS （default 0 【meaning 1000 errors】）
Impala日志文件中记录的任何特定查询的最大非致命错误数。 例如，如果十亿行表在每行中都有非致命数据错误，则可以在不记录十亿错误的情况下诊断问题。 未指定或0表示内置默认值1000。
使用MAX_MEM_ESTIMATE_FOR_ADMISSION查询选项可以将查询的内存估计值设置为超出预估的解决方法，从而阻止查询被允许。
查询选项在满足以下所有条件时生效：
- 为池启用基于内存的控制。
- MEM_LIMIT查询选项未在查询，会话，资源池或全局级别设置。
设置 MEM_LIMIT 查询选项通常是更好的选择。 如果无法为每个单独的查询设置 MEM_LIMIT，请使用 MAX_MEM_ESTIMATE_FOR_ADMISSION 查询选项。
MAX_NUM_RUNTIME_FILTERS （default 10）
设置每个查询生成的运行时筛选器数量的上限。
每个运行时筛选器都会对查询施加一些内存开销。 根据RUNTIME_BLOOM_FILTER_SIZE查询选项的设置，每个筛选器可能会占用每个计划片段1到16兆字节。 每个计划片段通常有5个或更少的过滤器。
Impala评估每个过滤器的有效性，并保留消除最大数量的分区或行的过滤器。 因此，此设置可以防止由于过滤器生成的过多内存开销而导致的潜在问题，同时仍允许对适当的查询进行高级别的优化。
由于运行时筛选功能主要应用于资源密集型和长时间运行的查询，因此仅在调整涉及大型分区表和涉及大型表的联接的长时间运行查询时调整此查询选项。
此查询选项仅影响 Bloom filters，而不影响应用于Kudu表的最小/最大过滤器。 因此，它不会影响对Kudu表的查询性能。
MAX_ROW_SIZE（default 524288 【512 KB】）
确保Impala可以处理至少指定大小的行。 （可能会成功处理较大的行，但无法保证。）在结果集中构造中间行或最终行时适用。 此设置可防止在访问包含大字符串的列时使用导致内存失控。
如果查询失败，因为它涉及具有长字符串或许多列的行，导致总行大小超过 MAX_ROW_SIZE 字节，请增加 MAX_ROW_SIZE 设置以适应存储在最大行中的总字节数。检查任何失败查询的错误消息，以查看导致问题的行的大小。
Impala尝试在可行的情况下处理超过MAX_ROW_SIZE值的行，因此在许多情况下，尽管行数大于此设置，但查询仍会成功。
指定一个远远高于实际需要的值可能会导致Impala保留的内存超过执行查询所需的内存。
在具有高度并发工作负载和处理大量数据的查询的Hadoop集群中，有关最小化浪费内存的传统SQL调优建议值得记住。 例如，如果表具有STRING列，其中单个值可能是多兆字节，请确保查询中的SELECT列表仅引用结果集中实际需要的列，而不是使用SELECT *简写。
示例
1、以下示例显示了需要调整MAX_ROW_SIZE设置的情况。 首先，我们在STRING列中创建一个包含一些非常长的值的表：
create table big_strings (s1 string, s2 string, s3 string) stored as parquet;
-- Turn off compression to more easily reason about data volume by doing SHOW TABLE STATS.
-- Does not actually affect query success or failure, because MAX_ROW_SIZE applies when
-- column values are materialized in memory.
set compression_codec=none;
set;
...
MAX_ROW_SIZE: [524288]
...
-- A very small row.
insert into big_strings values ('one', 'two', 'three');
-- A row right around the default MAX_ROW_SIZE limit: a 500 KiB string and a 30 KiB string.
insert into big_strings values (repeat('12345',100000), 'short', repeat('123',10000));
-- A row that is too big if the query has to materialize both S1 and S3.
insert into big_strings values (repeat('12345',100000), 'short', repeat('12345',100000));
2、使用默认的MAX_ROW_SIZE设置，根据在查询处理期间必须实现哪些列值，不同的查询成功或失败：
-- All the S1 values can be materialized within the 512 KB MAX_ROW_SIZE buffer.
select count(distinct s1) from big_strings;
+--------------------+
| count(distinct s1) |
+--------------------+
| 2 |
+--------------------+
-- A row where even the S1 value is too large to materialize within MAX_ROW_SIZE.
insert into big_strings values (repeat('12345',1000000), 'short', repeat('12345',1000000));
-- The 5 MiB string is too large to materialize. The message explains the size of the result
-- set row the query is attempting to materialize.
select count(distinct(s1)) from big_strings;
WARNINGS: Row of size 4.77 MB could not be materialized in plan node with id 1.
Increase the max_row_size query option (currently 512.00 KB) to process larger rows.
-- If more columns are involved, the result set row being materialized is bigger.
select count(distinct s1, s2, s3) from big_strings;
WARNINGS: Row of size 9.54 MB could not be materialized in plan node with id 1.
Increase the max_row_size query option (currently 512.00 KB) to process larger rows.
-- Column S2, containing only short strings, can still be examined.
select count(distinct(s2)) from big_strings;
+----------------------+
| count(distinct (s2)) |
+----------------------+
| 2 |
+----------------------+
-- Queries that do not materialize the big column values are OK.
select count(*) from big_strings;
+----------+
| count(*) |
+----------+
| 4 |
+----------+
3、以下示例显示如何向上调整MAX_ROW_SIZE允许涉及长字符串列的查询成功：
-- Boosting MAX_ROW_SIZE moderately allows all S1 values to be materialized.
set max_row_size=7mb;
select count(distinct s1) from big_strings;
+--------------------+
| count(distinct s1) |
+--------------------+
| 3 |
+--------------------+
-- But the combination of S1 + S3 strings is still too large.
select count(distinct s1, s2, s3) from big_strings;
WARNINGS: Row of size 9.54 MB could not be materialized in plan node with id 1. Increase the max_row_size query option (currently 7.00 MB) to process larger rows.
-- Boosting MAX_ROW_SIZE to larger than the largest row in the table allows
-- all queries to complete successfully.
set max_row_size=12mb;
select count(distinct s1, s2, s3) from big_strings;
+----------------------------+
| count(distinct s1, s2, s3) |
+----------------------------+
| 4 |
+----------------------------+
4、以下示例显示如何根据包含long值的列的特征推断MAX_ROW_SIZE的适当值：
-- With a large MAX_ROW_SIZE in place, we can examine the columns to
-- understand the practical lower limit for MAX_ROW_SIZE based on the
-- table structure and column values.
select max(length(s1) + length(s2) + length(s3)) / 1e6 as megabytes from big_strings;
+-----------+
| megabytes |
+-----------+
| 10.000005 |
+-----------+
-- We can also examine the 'Max Size' for each column after computing stats.
compute stats big_strings;
show column stats big_strings;
+--------+--------+------------------+--------+----------+-----------+
| Column | Type | #Distinct Values | #Nulls | Max Size | Avg Size |
+--------+--------+------------------+--------+----------+-----------+
| s1 | STRING | 2 | -1 | 5000000 | 2500002.5 |
| s2 | STRING | 2 | -1 | 10 | 7.5 |
| s3 | STRING | 2 | -1 | 5000000 | 2500005 |
+--------+--------+------------------+--------+----------+-----------+
MAX_SCAN_RANGE_LENGTH （default 0）
扫描范围的最大长度。 与表中的HDFS块数进行交互，以确定群集中涉及查询处理的CPU核心数。 （每个核心处理一个扫描范围。）
如果您有未使用的CPU容量，降低值有时会增加并行性，但是太小的值会限制查询性能，因为每个扫描范围都会产生额外的开销。
仅适用于HDFS表。 对Parquet 格式的表没有影响。 未指定或0表示后端默认值，这与每个表的HDFS块大小相同。
尽管扫描范围可以任意长，但Impala内部使用 8 MB读取缓冲区，因此它可以查询具有大块大小的表而无需分配等效的内存块。
在CDH 5.9 / Impala 2.7及更高版本中，参数值可以包括单位说明符，例如100m或100mb。 在以前的版本中，Impala将此类格式化的值解释为0，从而导致查询失败。
MEM_LIMIT （default 0【unlimited】）
MEM_LIMIT查询选项定义查询可在每个节点上分配的最大内存量。 查询可以使用的总内存是MEM_LIMIT乘以节点数。
Impala有两个级别的内存限制：
- -mem_limit 启动选项设置impalad进程的总体限制（同时处理多个查询）。该限制通常以主机上可用RAM的百分比表示，例如-mem_limit = 70％。
- 通过impala-shell或JDBC或ODBC应用程序中的SET语句设置的MEM_LIMIT查询选项适用于每个单独的查询。
如果查询处理超过任何节点上的指定内存限制（每个查询限制或impalad限制），则Impala会自动取消查询。 在查询处理期间会定期检查内存限制，因此实际使用的内存可能会短暂超出限制而不会取消查询。
适用情况
MEM_LIMIT设置主要用于高并发设置，或者在Impala与其他数据处理组件之间共享工作负载的集群上。 您可以防止任何查询意外使用比预期更多的内存，这可能会对其他Impala查询产生负面影响。
设置参考
使用impala-shell中SUMMARY命令的输出来获取每个节点上最重量级查询的每个阶段使用的内存报告，然后将MEM_LIMIT设置为稍高于此值。
示例
1、以下示例显示如何使用固定数量的字节或表示千兆字节或兆字节的后缀来设置MEM_LIMIT查询选项。
[localhost:21000] > set mem_limit=3000000000;
MEM_LIMIT set to 3000000000
[localhost:21000] > select 5;
Query: select 5
+---+
| 5 |
+---+
| 5 |
+---+
[localhost:21000] > set mem_limit=3g;
MEM_LIMIT set to 3g
[localhost:21000] > select 5;
Query: select 5
+---+
| 5 |
+---+
| 5 |
+---+
[localhost:21000] > set mem_limit=3gb;
MEM_LIMIT set to 3gb
[localhost:21000] > select 5;
+---+
| 5 |
+---+
| 5 |
+---+
[localhost:21000] > set mem_limit=3m;
MEM_LIMIT set to 3m
[localhost:21000] > select 5;
+---+
| 5 |
+---+
| 5 |
+---+
[localhost:21000] > set mem_limit=3mb;
MEM_LIMIT set to 3mb
[localhost:21000] > select 5;
+---+
| 5 |
+---+
2、以下示例显示了无法识别的MEM_LIMIT值如何导致后续查询的错误。
[localhost:21000] > set mem_limit=3tb;
MEM_LIMIT set to 3tb
[localhost:21000] > select 5;
ERROR: Failed to parse query memory limit from '3tb'.
[localhost:21000] > set mem_limit=xyz;
MEM_LIMIT set to xyz
[localhost:21000] > select 5;
Query: select 5
ERROR: Failed to parse query memory limit from 'xyz'.
3、以下示例显示了在Impala查询中涉及的任何主机上超过MEM_LIMIT值时的自动查询取消。 首先，它运行一个成功的查询，并检查任何节点上用于查询的任何阶段的最大内存量。 然后它设置一个人为的低MEM_LIMIT设置，以便不能运行相同的查询。
[localhost:21000] > select count(*) from customer;
Query: select count(*) from customer
+----------+
| count(*) |
+----------+
| 150000 |
+----------+
[localhost:21000] > select count(distinct c_name) from customer;
Query: select count(distinct c_name) from customer
+------------------------+
| count(distinct c_name) |
+------------------------+
| 150000 |
+------------------------+
[localhost:21000] > summary;
+--------------+--------+----------+----------+---------+------------+----------+---------------+---------------+
| Operator | #Hosts | Avg Time | Max Time | #Rows | Est. #Rows | Peak Mem | Est. Peak Mem | Detail |
+--------------+--------+----------+----------+---------+------------+----------+---------------+---------------+
| 06:AGGREGATE | 1 | 230.00ms | 230.00ms | 1 | 1 | 16.00 KB | -1 B | FINALIZE |
| 05:EXCHANGE | 1 | 43.44us | 43.44us | 1 | 1 | 0 B | -1 B | UNPARTITIONED |
| 02:AGGREGATE | 1 | 227.14ms | 227.14ms | 1 | 1 | 12.00 KB | 10.00 MB | |
| 04:AGGREGATE | 1 | 126.27ms | 126.27ms | 150.00K | 150.00K | 15.17 MB | 10.00 MB | |
| 03:EXCHANGE | 1 | 44.07ms | 44.07ms | 150.00K | 150.00K | 0 B | 0 B | HASH(c_name) |
| 01:AGGREGATE | 1 | 361.94ms | 361.94ms | 150.00K | 150.00K | 23.04 MB | 10.00 MB | |
| 00:SCAN HDFS | 1 | 43.64ms | 43.64ms | 150.00K | 150.00K | 24.19 MB | 64.00 MB | tpch.customer |
+--------------+--------+----------+----------+---------+------------+----------+---------------+---------------+
[localhost:21000] > set mem_limit=15mb;
MEM_LIMIT set to 15mb
[localhost:21000] > select count(distinct c_name) from customer;
Query: select count(distinct c_name) from customer
ERROR:
Memory limit exceeded
Query did not have enough memory to get the minimum required buffers in the block manager.
MIN_SPILLABLE_BUFFER_SIZE（default 65536 【64 KB】）
指定激活spill-to-disk机制时使用的内存缓冲区的最小大小，例如，针对没有统计信息的大表或 join 操作的查询。
此查询选项设置可在溢出到磁盘操作期间使用的内部缓冲区大小的下限。 查询计划程序选择缓冲区的实际大小。
如果整体查询性能受溢出所需时间的限制，请考虑增加MIN_SPILLABLE_BUFFER_SIZE设置。 较大的缓冲区大小会导致Impala向存储设备发出更大的I / O请求，这可能会导致更高的吞吐量，尤其是在磁盘上。
此设置具有较大值的权衡是在溢出到磁盘操作期间增加的内存使用量。 减小此值可能会减少内存消耗。
要通过限制可填充缓冲区大小来确定此设置的值是否有效，您可以查看查询计划程序为特定查询选择的缓冲区大小。 在EXPLAIN_LEVEL = 2设置生效时解析查询。
set min_spillable_buffer_size=128KB;
MT_DOP (default 0)
设置可用于多线程执行的某些操作的并行度。 您可以指定大于零的值，以在语句处理期间找到响应时间，内存使用情况和CPU使用率的平衡。
Impala执行引擎正在逐步进行修改，以便在单个主机中为某些语句和各种操作添加额外的并行性。 设置MT_DOP = 0使用具有有限的节点内并行性的“旧”代码路径。
目前，受MT_DOP查询选项影响的操作是：
- Impala自动为Parquet表上的COMPUTE STATS和COMPUTE INCREMENTAL STATS语句设置MT_DOP = 4。
- 具有仅包含扫描和聚合运算符的执行计划的查询。 如果MT_DOP设置为非零值，则其他查询会产生错误。 因此，此查询选项通常仅在特定长时间运行的CPU密集型查询的持续时间内设置。
由于Parquet表的COMPUTE STATS和COMPUTE INCREMENTAL STATS语句大大受益于额外的节点内并行性，因此Impala在计算Parquet表的统计数据时会自动设置MT_DOP = 4。
取值范围：0 到 64
示例
1、以下示例显示如何使用或不使用显式MT_DOP设置对Parquet表运行COMPUTE STATS语句：
-- Explicitly setting MT_DOP to 0 selects the old code path.
set mt_dop = 0;
MT_DOP set to 0
-- The analysis for the billion rows is distributed among hosts,
-- but uses only a single core on each host.
compute stats billion_rows_parquet;
+-----------------------------------------+
| summary |
+-----------------------------------------+
| Updated 1 partition(s) and 2 column(s). |
+-----------------------------------------+
drop stats billion_rows_parquet;
-- Using 4 logical processors per host is faster.
set mt_dop = 4;
MT_DOP set to 4
compute stats billion_rows_parquet;
+-----------------------------------------+
| summary |
+-----------------------------------------+
| Updated 1 partition(s) and 2 column(s). |
+-----------------------------------------+
drop stats billion_rows_parquet;
-- Unsetting the option reverts back to its default.
-- Which for COMPUTE STATS and a Parquet table is 4,
-- so again it uses the fast path.
unset MT_DOP;
Unsetting option MT_DOP
compute stats billion_rows_parquet;
+-----------------------------------------+
| summary |
+-----------------------------------------+
| Updated 1 partition(s) and 2 column(s). |
+-----------------------------------------+
2、以下示例显示了为仅涉及Parquet表的扫描和聚合操作的查询设置MT_DOP的效果：
set mt_dop = 0;
MT_DOP set to 0
-- COUNT(DISTINCT) for a unique column is CPU-intensive.
select count(distinct id) from billion_rows_parquet;
+--------------------+
| count(distinct id) |
+--------------------+
| 1000000000 |
+--------------------+
Fetched 1 row(s) in 67.20s
set mt_dop = 16;
MT_DOP set to 16
-- Introducing more intra-node parallelism for the aggregation
-- speeds things up, and potentially reduces memory overhead by
-- reducing the number of scanner threads.
select count(distinct id) from billion_rows_parquet;
+--------------------+
| count(distinct id) |
+--------------------+
| 1000000000 |
+--------------------+
Fetched 1 row(s) in 17.19s
3、以下示例显示了在设置MT_DOP时，与非零MT_DOP设置不兼容的查询如何产生错误：
set mt_dop=1;
MT_DOP set to 1
select * from a1 inner join a2
on a1.id = a2.id limit 4;
ERROR: NotImplementedException: MT_DOP not supported for plans with
base table joins or table sinks.
NUM_NODES (default 0)
限制处理查询的节点数，通常在调试期间使用。
如果您正在诊断由于分布式查询处理而导致计时问题的问题，则可以设置NUM_NODES = 1以验证在单个节点上完成所有工作后问题是否仍然存在。
NUM_SCANNER_THREADS (default 0)
每个查询使用的最大扫描程序线程数（在每个节点上）。 默认情况下，Impala使用尽可能多的内核（每个内核一个线程）。 如果查询在繁忙群集上使用过多资源，则可以降低此值。 Impala自动施加最大值，因此高值没有实际效果。
OPTIMIZE_PARTITION_KEY_SCANS
如果查询包含任何WHERE，GROUP BY或HAVING子句，则此优化不适用。 相关查询应仅计算整个表中分区键列的最小值，最大值或不同值的数量。
PARQUET_COMPRESSION_CODEC （已过时）
已过时。 在Impala 2.0及更高版本中使用COMPRESSION_CODEC。
PARQUET_ANNOTATE_STRINGS_UTF8 （default false ）
Impala INSERT 和 CREATE TABLE AS SELECT 语句写入Parquet文件中的 STRING 列使用UTF-8格式。
此选项旨在帮助使Impala编写的数据与其他数据处理引擎更具互操作性。 Impala本身目前不支持UTF-8数据的所有操作。
尽管Impala处理的数据通常以ASCII格式表示，但在磁盘上存储时将数据指定为UTF-8是有效的，因为ASCII是UTF-8的子集。