作者zhuqibs·2020-04-06 19:38

软件开发工程师·Adidas

impala的优化--分区表优化-8个方法让分区最优化

字数 64118阅读 4471评论 0赞 5

分区表优化-8个方法让分区最优化
默认情况下，表中的所有数据文件都位于一个目录中。分区是在加载过程中基于从一个或多个列的值的物理上划分数据的技术，以加快对这些列进行查询。例如，一个school_records设置年为分区字段，那么不同的年值将位于一个单独的数据目录。对于查询来说，如Where条件为 YEAR=1966, YEAR IN(1989,1999), 或者YEAR BETWEEN 1984 AND 1989 ，只会获取对应年份的数据文件，大大减少了数据读取量。

1.什么时候使用分区表
分区通常适合以下情况：
l 表非常大的，在读取整个数据集需要很长的时间
l 总是或几乎总是在分区列上的条件查询的表
l 有合理的基数列（不同值的数量）。如果一个列只有一个小的值，例如男性或女性，你没有得到太多的效率，通过消除只有约50%的数据读取每个查询。如果一列只有几行的匹配值，处理目录的数量可以成为一个限制因素，并在每个目录中的数据文件可能太小，利用Hadoop的机制在多兆字节的数据分块传输。例如，您可能会在一年内分区统计数据，通过年和月的存储销售数据，以及年、月和日的Web流量数据。（一些高容量的输入数据的用户甚至可能划分到每小时和每分钟。）
数据已通过提取、变换、和加载（ETL）管道。分区列的值从原始数据文件中剥离，并由目录名表示，因此将数据加载到分区表中涉及到某种形式的转换或预处理。
1.1.2 对于分区表的SQL语句
在Impala的SQL语法，分区影响这些语句：
createtable ：您在创建表时指定了一个PARTITIONEDBY条件，以确定分区列的名称和数据类型。这些列不包含在表的列中的主要列表中。
在CDH 5.7 /Impala2.5及更高，你也可以使用分区在创建表的条款为SELECT语句。此语法允许您使用一个语句来创建一个分区表，将数据复制到它，并基于插入的数据中的值创建新的分区。
改变表：可以添加或删除分区，可以使用一个庞大的数据集的不同部分工作。你可以为一个特定的分区指定的HDFS目录保存数据文件。通过日期值划分的数据，您可能会“老化”不再相关的数据。
注：如果您正在创建一个分区，并指定它的位置，为最大效率，使用一个单一的更改表语句，包括添加分区和位置子句，而不是单独的语句与添加分区和设置位置子句。
1.1.3 静态和动态分区子句
在SQL语句中指定的所有分区列称为静态分配，因为语句影响单个预测分区。例如，您使用静态分区与一个改变表语句，只影响一个分区，或与一个插入语句插入到同一个分区中的所有值：
insertinto t1 partition(x=10,y='a') select c1 from some_other_table;
当你指定分区键列在INSERT语句，但离开了价值，Impala决定插入哪个分区。这种技术被称为动态分区：
insert intot1 partition(x,y='b') select c1, c2 from some_other_table;
-- Createnew partition if necessary based on variable year, month, and day; insert asingle value.
insert intoweather partition(year, month, day) select'cloudy',2014,4,21;
-- Createnew partition if necessary for specified year and month but variable day;insert a single value.
insert intoweather partition(year=2014, month=04, day) select'sunny',22;
在分区子句中指定的更重要的列，在“选择列表”中需要的列数较少。在选择列表中的尾随列以顺序替换没有指定值的分区键列。

1.1.4 分区的子目录的权限
默认情况下，如果插入语句创建任何新的子目录下面的分区表，这些子目录分配权限的用户默认的HDFS的权限。使每个子目录具有相同的权限为在HDFS的父目录，指定--insert_inherit_permissions启动选项的impalad守护。
1.1.5 查询的分区精简
分区精简指的是一个查询可以跳过一个或多个分区对应的数据文件的机制。如果您可以安排查询，从查询执行计划中删除大量的不必要的分区，查询使用更少的资源，因此比例更快，更可扩展性。
例如，如果一个表是由列年，月，日，分区，然后在条款如年为2013年，其中＜2010，或1995和1998让Impala跳过数据文件在指定范围外的所有分区之间。同样地，在一年的2013和1和3之间的一个月，可以精简更多的分区，读取数据文件只有一年的一部分。
要检查分区修剪对于查询的有效性，在运行它之前检查解释输出为查询的结果。例如，这个示例显示了一个有3个分区的表，其中查询只读取其中的1个分区。符号#partitions=1/3在解释计划证实了impala可以做适当的分区修剪。
[localhost:21000]> insert into census partition (year=2010) values ('Smith'),('Jones');
[localhost:21000]> insert into census partition (year=2011) values('Smith'),('Jones'),('Doe');
[localhost:21000]> insert into census partition (year=2012) values ('Smith'),('Doe');
[localhost:21000]> select name from census where year=2010;
+-------+
| name |
+-------+
| Smith |
| Jones |
+-------+
[localhost:21000]> explain select name from census where year=2010;
+------------------------------------------------------------------+
| ExplainString |
+------------------------------------------------------------------+
| PLANFRAGMENT 0 |
| PARTITION: UNPARTITIONED |
| |
| 1:EXCHANGE |
| |
| PLANFRAGMENT 1 |
| PARTITION: RANDOM |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 1 |
| UNPARTITIONED |
| |
| 0:SCAN HDFS |
| table=predicate_propagation.census #partitions=1/3 size=12B |
+------------------------------------------------------------------+
对于在查询的每个阶段实际读取和处理的数据量的报表，在运行查询后立即检查汇总命令的输出。对于一个更详细的分析，看配置文件命令的输出；它包括在配置文件输出的开始附近的这个相同的汇总报告。
1) 检查是否对查询进行分区修剪
2) 什么SQL构造分区修剪工作
3) 动态分区修剪
1.1.5.1 检查是否对查询进行分区修剪
要检查分区修剪对于查询的有效性，在运行它之前检查解释输出为查询的结果。例如，这个示例显示了一个有3个分区的表，其中查询只读取其中的1个分区。符号#分区= 1 / 3在解释计划证实了impala可以做适当的分区修剪。
[localhost:21000]> insert into census partition (year=2010) values ('Smith'),('Jones');
[localhost:21000]> insert into census partition (year=2011) values('Smith'),('Jones'),('Doe');
[localhost:21000]> insert into census partition (year=2012) values ('Smith'),('Doe');
[localhost:21000]> select name from census where year=2010;
+-------+
| name |
+-------+
| Smith |
| Jones |
+-------+
[localhost:21000]> explain select name from census where year=2010;
+------------------------------------------------------------------+
| ExplainString |
+------------------------------------------------------------------+
| PLANFRAGMENT 0 |
| PARTITION: UNPARTITIONED |
| |
| 1:EXCHANGE |
| |
| PLANFRAGMENT 1 |
| PARTITION: RANDOM |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 1 |
| UNPARTITIONED |
| |
| 0:SCAN HDFS |
| table=predicate_propagation.census #partitions=1/3 size=12B |
+------------------------------------------------------------------+
对于在查询的每个阶段实际读取和处理的数据量的报表，在运行查询后立即检查汇总命令的输出。对于一个更详细的分析，看配置文件命令的输出；它包括在配置文件输出的开始附近的这个相同的汇总报告。
1.1.5.2 什么SQL构造分区修剪工作
impala甚至可以做分区修剪的情况下，分区键列是不能直接比较恒定，通过传递性质的WHERE子句中的其他部分。这种技术被称为谓词的传播，并在impala1.2.2后来。在这个示例中，普查表包括另一列，该列指示当数据被收集时，发生在10年的时间间隔内。即使查询并不比分区键列（年）到一个恒定值，impala可以推断出，只有= 2010是必需的分区的一年，又一次只读取了3个分区1。
[localhost:21000]> drop table census;
[localhost:21000]> create table census (name string, census_year int) partitioned by (yearint);
[localhost:21000]> insert into census partition (year=2010) values('Smith',2010),('Jones',2010);
[localhost:21000]> insert into census partition (year=2011) values('Smith',2020),('Jones',2020),('Doe',2020);
[localhost:21000]> insert into census partition (year=2012) values('Smith',2020),('Doe',2020);
[localhost:21000]> select name from census where year = census_year and census_year=2010;
+-------+
|name |
+-------+
| Smith |
| Jones |
+-------+
[localhost:21000]> explain select name from census where year = census_year andcensus_year=2010;
+------------------------------------------------------------------+
| ExplainString |
+------------------------------------------------------------------+
| PLANFRAGMENT 0 |
| PARTITION: UNPARTITIONED |
| |
| 1:EXCHANGE |
| |
| PLANFRAGMENT 1 |
| PARTITION: RANDOM |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 1 |
| UNPARTITIONED |
| |
| 0:SCAN HDFS |
| table=predicate_propagation.census #partitions=1/3 size=22B |
| predicates: census_year = 2010, year =census_year |
+------------------------------------------------------------------+
如果一个视图适用于一个分区表，任何分区修剪都认为在原始查询和任何额外的谓词在查询中的语句，是指视图的子句。impala1.4之前，只有在条款对原始查询从创建视图的语句进行分区修剪。
在解析函数和分区表的查询中，只发生在由解析函数调用的分区中命名的列的分区修剪。例如，如果一个解析函数查询有一个条款，如在年= 2016，使查询修剪所有其他年分区的方法是包括在解析函数调用划分；例如，在（分区的一年，other_columns other_analytic_clauses）。
1.1.5.3 动态分区修剪
原来的机制用于修剪分区是静态分区修剪，在其中的条件，在条款进行分析，以确定提前哪些分区可以安全地跳过。在Impala 2.5 /CDH5.7及更高版本，impala可以执行动态分区修剪，在分区信息中查询收集，和impala修剪不必要的分区方式是提前预测不切实际。
例如，如果分区键列进行比较的文字值WHERE子句中，impala可以执行静态分区修剪规划阶段在阅读相关的分区：
-- Thequery only needs to read 3 partitions whose key values are known ahead of time.
-- That'sstatic partition pruning.
SELECTCOUNT(*) FROM sales_table WHERE year IN (2005, 2010, 2015);
动态分区修剪涉及使用信息只有在运行时，如查询结果：
createtable yy (s string) partitioned by (year int) stored as parquet;
insert intoyy partition (year) values ('1999', 1999), ('2000', 2000),
('2001', 2001), ('2010',2010);
computestats yy;

createtable yy2 (s string) partitioned by (year int) stored as parquet;
insert intoyy2 partition (year) values ('1999', 1999), ('2000', 2000),
('2001', 2001);
computestats yy2;

-- Thequery reads an unknown number of partitions, whose key values are only
-- known atrun time. The 'runtime filters' lines show how the information about
-- thepartitions is calculated in query fragment 02, and then used in query
-- fragment00 to decide which partitions to skip.
explainselect s from yy2 where year in (select year from yy where year between 2000and 2005);
+----------------------------------------------------------+
| ExplainString |
+----------------------------------------------------------+
| EstimatedPer-Host Requirements: Memory=16.00MB VCores=2 |
| |
|04:EXCHANGE [UNPARTITIONED] |
| | |
| 02:HASHJOIN [LEFT SEMI JOIN, BROADCAST] |
| | hash predicates: year = year |
| | runtime filters: RF000 <- year |
| | |
||--03:EXCHANGE [BROADCAST] |
| | | |
| | 01:SCAN HDFS [dpp.yy] |
| | partitions=2/4 files=2 size=468B |
| | |
| 00:SCANHDFS [dpp.yy2] |
| partitions=2/3 files=2 size=468B |
| runtime filters: RF000 -> year |
+----------------------------------------------------------+
在这种情况下，impala评价子查询，子查询结果发送所有Impala节点参与查询，然后每个impalad守护进程采用动态分区剪枝优化与相关键值只读分区。
动态分区修剪是特别有效的查询，涉及几个大的分区表的联接。评估联接谓词的子句，通常需要从某些表的所有分区中读取数据。如果该查询的WHERE子句中引用的分区键列，impala现在经常可以跳过阅读许多的分区在评估条款。动态分区修剪优化减少了在查询过程中的网络存储和传输的I / O和中间数据量的量。
当溢出到磁盘功能是一个连接节点在查询激活，impala不产生任何运行过滤器，主机上的连接操作。查询中的其他连接节点不受影响。
动态分区修剪是运行时过滤功能的一部分，它适用于其他类型的查询，除了对分区表的查询。看到运行的impala查询有关此功能的详细的过滤。

1.1.6 分区键列
您选择的列作为分区键应该是经常用于筛选查询结果的重要的大型查询。流行的例子是一些组合的一年，一个月，和一天的数据有相关的时间值，和地理区域的数据时，与一些地方。
基于时间的数据，分离出独立的部分纳入自己的栏目，因为impala不能划分一个时间戳列。
该分区列的数据类型不具有对存储要求的效果显著，因为从这些列的值不存储在数据文件中，而他们是在HDFS目录名称的字符串。
在CDH 5.7 /impala2.5及更高版本，可以使optimize_partition_key_scans查询选项来加快查询的速度，仅指分区键列，如选择最大（年）。默认情况下，此设置没有启用，因为如果表中包含没有实际数据的分区目录，则查询的行为将略有不同。看到optimize_partition_key_scans查询详情。
分区表可以包含复杂的类型列。所有分区键列必须为标量类型。
记住，当impala查询存储在HDFS的数据，它是最有效的使用多字节的文件利用HDFS块大小。实木复合地板表，块的大小（和数据文件大小是理想）2 256 MB，后来impala。因此，避免指定太多的分区键列，这可能会导致单个分区只包含少量的数据。例如，如果你每天收到1个数据，你可能会被一年一个月，一天一天；而如果你每分钟收到5个数据，你可能会被一年、一个月、一天、一小时、一分钟划分。如果你与一个地理成分的数据，你可能会划分邮政编码，如果您有许多兆字节的每个邮政编码数据，但如果没有的话，你可能会被一些大的区域，如城市、州或国家划分。状态
如果你经常运行汇总等功能min()，max()，计数（不同的）分区键列，考虑启用optimize_partition_key_scans查询优化查询。这一特征在CDH 5.7 /impala2.5及更高版本可用。看到optimize_partition_key_scans查询选项，这个选项适用于查询的种类，和轻微的差异如何分区进行评估时，该查询选项启用。
1.1.7 设置分区的不同的文件格式
分区表有灵活性，使用不同的分区使用不同的文件格式。（关于不同的文件格式支持背景信息看，impala、impala和Hadoop文件格式。）例如，如果你在文本格式最初收到数据，然后接收新的数据格式，并最终开始RCFile，拼花格式接收数据，这些数据可以驻留在同一个表的查询。您只需要确保表的结构，以便使用不同的文件格式的数据文件驻留在单独的分区中。
例如，这里是你如何可以从文本到地板的数据你不同年接收数据：
[localhost:21000]> create table census (name string) partitioned by (year smallint);
[localhost:21000]> alter table census add partition (year=2012); -- Text format;

[localhost:21000]> alter table census add partition (year=2013); -- Text format switches toParquet before data loaded;
[localhost:21000]> alter table census partition (year=2013) set fileformat parquet;

[localhost:21000]> insert into census partition (year=2012) values ('Smith'),('Jones'),('Lee'),('Singh');
[localhost:21000]> insert into census partition (year=2013) values('Flores'),('Bogomolov'),('Cooper'),('Appiah');
在这一点上，HDFS目录 year=2012包含一个文本格式的数据文件，而HDFS目录 year=2013包含一个复合数据文件。和总是一样，当加载不平凡的数据时，您将使用插入…选择或加载数据以大批量导入数据，而不是插入…值，产生小的文件，是低效的现实世界的查询。
对于其他类型的文件，impala不能创造本身，你可以切换到蜂巢的问题修改表…设置文件格式报表和报表数据插入或负载有。切换回Impala后，发出声明，刷新table_nameImpala承认任何分区或新添加的数据通过hive。
1.1.8 管理分区
你可以添加，删除，设定预期的文件格式，或一组数据文件HDFS位置个别分区impala表内。有关语法细节的更改表语句，并在包含分区的分区的管理表上设置不同的文件格式的不同的文件格式。
注：如果您正在创建一个分区，并指定它的位置，为最大效率，使用一个单一的更改表语句，包括添加分区和位置子句，而不是单独的语句与添加分区和设置位置子句。
当一个分区被删除时，数据文件会发生什么，取决于分区表是否被指定为内部或外部的。对于内部（托管）表，数据文件已被删除。例如，如果分区表中的数据是存储在其他地方的原始数据文件的副本，则可以通过删除不再需要的旧分区来保存磁盘空间，知道原始数据在需要时仍然可用。对于一个外部表，数据文件将被单独留下。例如，删除一个分区没有删除相关的文件让impala考虑更小的分区，提高查询效率和减少表的DDL操作的开销；如果数据再次需要后，你可以再添加分区。看到的细节和例子的impala表概述。

1.2 Hadoop-impala十大优化之（2）—impala连接查询的性能优化
涉及连接操作的查询通常需要更多的调整，而不是仅指一个表的查询。从联接查询集合查询的结果集的最大大小是所有联接表中的行数的乘积。当加入数个表有数以百万计或数十亿的行，任何错过的机会过滤结果集，或其他低效的查询，可能导致一个操作，不完成在一个实际的时间，必须被取消。
调整Impala的最简单的方法连接查询是收集统计每个表参与联接的计算统计表，然后让Impala自动优化基于每个表的大小的查询，对每一列的不同值的数量，等等。计算统计表和连接优化了Impala1.2.2新特点。对于每个表的精确统计，在将数据加载到该表中后，发出计算统计报表，如果数据量大幅度的改变，加载数据，添加一个分区，等等。
如果没有可用的统计信息在连接查询所有表，或者如果Impala选择连接顺序，是不是最有效的，你可以重写自动连接顺序优化通过指定straight_join关键词后立即选择关键词。在这种情况下，Impala用出现的查询指导顺序处理。
当你使用straight_join技术，你必须手动而不是依靠Impala优化器查询表的连接。该优化使用复杂的技术来估计连接的每个阶段的结果集的大小。对于手动排序，采用这种启发式的方法开始，然后实验来微调顺序：
指定最大的表。这个表是由每个Impala节点从磁盘读取，其规模不是很大的内存使用情况的查询。
下一步，指定最小的表。第二、第三、等表的内容都在网络上传输。要将连接查询的每个后续阶段的结果集的大小减到最小。最有可能的方法是先加入一个小的表，这样结果集仍然很小，即使随后的较大的表被处理。
加入下一个最小的表，然后是下一个最小的，等等。
例如，如果你有表大，中，小，微小，逻辑连接顺序尝试将是大，微小，小，中。
术语“最大”和“最小”是指基于每个表中的行和列的数量的中间结果集的大小，是结果集的一部分。例如，如果你加入一个表的销售与另一个表的客户，查询可能会发现从100个不同的客户，共有5000采购的结果。在这种情况下，您将指定选择…从销售连接客户……，把客户放在右边，因为它在这个查询的上下文中是小的。
impala的查询计划选择不同的技术之间进行连接查询，根据表的绝对和相对大小。广播连接是默认的，在右边的表被认为是小于左边的表，它的内容被发送到查询中涉及的所有其他节点上。另一种技术被称为一个分区的连接（不涉及到一个分区表），这是更适合于大表的大小大致相等。使用这种技术，每个表的一部分被发送到适当的其他节点，其中的行的子集可以被并行处理。广播或分区连接的选择也取决于在联接中的所有表可用的统计数据，由计算统计报表所收集的数据中的所有表。
要查看哪些连接策略用于某个特定的查询，为查询发出一个解释语句。如果你发现一个查询使用广播连接，当你知道通过基准，一个分区的连接将是更有效的，或反之亦然，向查询添加一个提示，以指定使用精确的连接机制。在Impala的SELECT语句详见查询提示。
1.1.1 当统计数字不可用时如何处理
如果表或列统计信息不可用，在加入一些表，impala还是重新排序表使用信息是可用的。表统计放在连接顺序的左侧，在成本递减的顺序，基于整体规模和基数。没有统计的表被视为零大小，也就是说，它们总是放在连接顺序的右边。

1.1.2 straight_join连接顺序大于其他
如果Impala连接查询是没有效率的，过时的统计数据或意外的数据分布，你可以把impala从排序连接表采用straight_join关键词后立即选择关键词。的straight_join关键词关闭重新加入条款，impala是内部，并产生一个依赖于加入条款被有序的优化查询文本中的计划。在这种情况下，重写查询，以便最大的表在左边，其次是下一个最大的，等等，直到最小的表在右边。
在这个例子中，从大表的子查询产生一个非常小的结果集，但表可能仍然被视为最大的连接顺序放在第一。使用straight_join最后加入条款阻止最终的表被重新排序，使其在最右边的表的连接顺序。
selectstraight_join x from medium join small join (select * from big where c1 <10) as big
where medium.id = small.id and small.id =big.id;
1.1.3 连接顺序优化实例
这里的实际例子从侧面证明：调整Impala的最简单的方法连接查询是收集统计每个表参与联接的计算统计表。
这里有示例显示在表之间有10亿、2亿和100万行的连接。（在这种情况下，表没有分区和使用Parquet 格式。）小表包含从最大的一个数据子集，对加入的唯一ID列方便。最小的表只包含从其他表中的列的子集。
[localhost:21000]> create table big stored as parquet as select * from raw_data;
+----------------------------+
|summary |
+----------------------------+
| Inserted1000000000 row(s) |
+----------------------------+
|||Returned1 row(s) in 671.56s
[localhost:21000]> desc big;
+-----------+---------+---------+
| name | type | comment |
+-----------+---------+---------+
| id | int | |
| val | int | |
|zfill | string | |
| name | string | |
| assertion| boolean | |
+-----------+---------+---------+
Returned 5row(s) in 0.01s
[localhost:21000] > create table mediumstored as parquet as select from big limit 200 floor(1e6);
+---------------------------+
|summary |
+---------------------------+
| Inserted200000000 row(s) |
+---------------------------+
|Returned 1row(s) in 138.31s
[localhost:21000]> create table small stored as parquet as select id,val,name from big whereassertion = true limit 1 * floor(1e6);
+-------------------------+
|summary |
+-------------------------+
| Inserted1000000 row(s) |
+-------------------------+
|Returned 1row(s) in 6.32s
对于任何一种性能试验，使用EXPLAIN语句看到任何昂贵的查询将不进行实际运行，使冗长的解释计划包含更注重性能的细节：最有趣的计划线路以粗体突出显示，显示没有连接表统计，impala不能在处理各阶段涉及的行数的一个很好的估计，并可能坚持广播加入机制，将一张表完全复制到每个节点。
[localhost:21000]> set explain_level=verbose;
EXPLAIN_LEVELset to verbose
[localhost:21000]> explain select count(*) from big join medium where big.id = medium.id;
+----------------------------------------------------------+
| ExplainString |
+----------------------------------------------------------+
| EstimatedPer-Host Requirements: Memory=2.10GB VCores=2 |
| |
| PLANFRAGMENT 0 |
| PARTITION: UNPARTITIONED |
| |
| 6:AGGREGATE (merge finalize) |
| | output: SUM(COUNT(*)) |
| | cardinality: 1 |
| | per-host memory: unavailable |
| | tuple ids: 2 |
| | |
| 5:EXCHANGE |
| cardinality: 1 |
| per-host memory: unavailable |
| tuple ids: 2 |
| |
| PLANFRAGMENT 1 |
| PARTITION: RANDOM |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 5 |
| UNPARTITIONED |
| |
| 3:AGGREGATE |
| | output: COUNT(*) |
| | cardinality: 1 |
| | per-host memory: 10.00MB |
| | tuple ids: 2 |
| | |
| 2:HASH JOIN |
| | joinop: INNER JOIN (BROADCAST) |
| | hash predicates: |
| | big.id = medium.id |
| | cardinality: unavailable |
| | per-host memory: 2.00GB |
| | tuple ids: 0 1 |
| | |
| |----4:EXCHANGE |
| | cardinality: unavailable |
| | per-host memory: 0B |
| | tuple ids: 1 |
| | |
| 0:SCAN HDFS |
| table=join_order.big #partitions=1/1 size=23.12GB |
| table stats: unavailable |
| column stats: unavailable |
| cardinality: unavailable |
| per-host memory: 88.00MB |
| tuple ids: 0 |
| |
| PLANFRAGMENT 2 |
| PARTITION: RANDOM |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 4 |
| UNPARTITIONED |
| |
| 1:SCAN HDFS |
| table=join_order.medium #partitions=1/1 size=4.62GB |
| table stats: unavailable |
| column stats: unavailable |
| cardinality:unavailable |
| per-host memory: 88.00MB |
| tuple ids: 1 |
+----------------------------------------------------------+
Returned 64row(s) in 0.04s
收集所有表的统计数据是简单的，一个计算每表的计算统计语句：
[localhost:21000]> compute stats small;
+-----------------------------------------+
|summary |
+-----------------------------------------+
| Updated 1partition(s) and 3 column(s). |
+-----------------------------------------+
|Returned 1row(s) in 4.26s
[localhost:21000]> compute stats medium;
+-----------------------------------------+
|summary |
+-----------------------------------------+
| Updated 1partition(s) and 5 column(s). |
+-----------------------------------------+
|Returned 1row(s) in 42.11s
[localhost:21000]> compute stats big;
+-----------------------------------------+
|summary |
+-----------------------------------------+
| Updated 1partition(s) and 5 column(s). |
+-----------------------------------------+
|Returned 1row(s) in 165.44s
使用统计信息，Impala可以选择更有效的连接顺序而不是从左到右的顺序查询中的表，并可选择广播或分区的基础上加入整体尺寸和表中的行数的策略：
[localhost:21000]> explain select count(*) from medium join big where big.id = medium.id;
Query:explain select count(*) from medium join big where big.id = medium.id
+-----------------------------------------------------------+
| ExplainString |
+-----------------------------------------------------------+
| EstimatedPer-Host Requirements: Memory=937.23MB VCores=2 |
| |
| PLANFRAGMENT 0 |
| PARTITION: UNPARTITIONED |
| |
| 6:AGGREGATE (merge finalize) |
| | output: SUM(COUNT(*)) |
| | cardinality: 1 |
| | per-host memory: unavailable |
| | tuple ids: 2 |
| | |
| 5:EXCHANGE |
| cardinality: 1 |
| per-host memory: unavailable |
| tuple ids: 2 |
| |
| PLANFRAGMENT 1 |
| PARTITION: RANDOM |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 5 |
| UNPARTITIONED |
| |
| 3:AGGREGATE |
| | output: COUNT(*) |
| | cardinality: 1 |
| | per-host memory: 10.00MB |
| | tuple ids: 2 |
| | |
| 2:HASH JOIN |
| | join op: INNER JOIN (BROADCAST) |
| | hash predicates: |
| | big.id = medium.id |
| | cardinality: 1443004441 |
| | per-host memory: 839.23MB |
| | tuple ids: 1 0 |
| | |
| |----4:EXCHANGE |
| | cardinality: 200000000 |
| | per-host memory: 0B |
| | tuple ids: 0 |
| | |
| 1:SCAN HDFS |
| table=join_order.big #partitions=1/1size=23.12GB |
| table stats: 1000000000 rows total |
| column stats: all |
| cardinality: 1000000000 |
| per-host memory: 88.00MB |
| tuple ids: 1 |
| |
| PLANFRAGMENT 2 |
| PARTITION: RANDOM |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 4 |
| UNPARTITIONED |
| |

compute stats parquet_snappy;
+-----------------------------------------+
| summary |
+-----------------------------------------+
| Updated 1 partition(s) and 6 column(s). |
+-----------------------------------------+

show column stats parquet_snappy;
+-------------+----------+------------------+--------+----------+----------+
| Column | Type | #Distinct Values | #Nulls | Max Size | Avg Size |
+-------------+----------+------------------+--------+----------+----------+
| id | BIGINT | -1 | -1 | 8 | 8 |
| val | INT | -1 | -1 | 4 | 4 |
| zerofill | STRING | -1 | -1 | -1 | -1 |
| name | STRING | -1 | -1 | -1 | -1 |
| assertion | BOOLEAN | -1 | -1 | 1 | 1 |
| location_id | SMALLINT | -1 | -1 | 2 | 2 |
+-------------+----------+------------------+--------+----------+----------+

show column stats parquet_snappy;
+-------------+----------+------------------+--------+----------+-------------------+
| Column | Type | #Distinct Values | #Nulls | Max Size | Avg Size |
+-------------+----------+------------------+--------+----------+-------------------+
| id | BIGINT | 183861280 | -1 | 8 | 8 |
| val | INT | 139017 | -1 | 4 | 4 |
| zerofill | STRING | 101761 | -1 | 6 | 6 |
| name | STRING | 145636240 | -1 | 22 | 13.00020027160645 |
| assertion | BOOLEAN | 2 | -1 | 1 | 1 |
| location_id | SMALLINT | 339 | -1 | 2 | 2 |
+-------------+----------+------------------+--------+----------+-------------------+
1.1.3 有关分区表的信息统计
show partitions year_month_day;
+-------+-------+-----+-------+--------+---------+--------------+-------------------+---------+...
| year | month | day | #Rows | #Files | Size | Bytes Cached | Cache Replication | Format |...
+-------+-------+-----+-------+--------+---------+--------------+-------------------+---------+...
| 2013 | 12 | 1 | -1 | 1 | 2.51MB | NOT CACHED | NOT CACHED | PARQUET |...
| 2013 | 12 | 2 | -1 | 1 | 2.53MB | NOT CACHED | NOT CACHED | PARQUET |...
| 2013 | 12 | 3 | -1 | 1 | 2.52MB | NOT CACHED | NOT CACHED | PARQUET |...
| 2013 | 12 | 4 | -1 | 1 | 2.51MB | NOT CACHED | NOT CACHED | PARQUET |...
| 2013 | 12 | 5 | -1 | 1 | 2.52MB | NOT CACHED | NOT CACHED | PARQUET |...
| Total | | | -1 | 5 | 12.58MB | 0B | | |...
+-------+-------+-----+-------+--------+---------+--------------+-------------------+---------+...

show table stats year_month_day;
+-------+-------+-----+-------+--------+---------+--------------+-------------------+---------+...
| year | month | day | #Rows | #Files | Size | Bytes Cached | Cache Replication | Format |...
+-------+-------+-----+-------+--------+---------+--------------+-------------------+---------+...
| 2013 | 12 | 1 | -1 | 1 | 2.51MB | NOT CACHED | NOT CACHED | PARQUET |...
| 2013 | 12 | 2 | -1 | 1 | 2.53MB | NOT CACHED | NOT CACHED | PARQUET |...
| 2013 | 12 | 3 | -1 | 1 | 2.52MB | NOT CACHED | NOT CACHED | PARQUET |...
| 2013 | 12 | 4 | -1 | 1 | 2.51MB | NOT CACHED | NOT CACHED | PARQUET |...
| 2013 | 12 | 5 | -1 | 1 | 2.52MB | NOT CACHED | NOT CACHED | PARQUET |...
| Total | | | -1 | 5 | 12.58MB | 0B | | |...
+-------+-------+-----+-------+--------+---------+--------------+-------------------+---------+...

show column stats year_month_day;
+-----------+---------+------------------+--------+----------+----------+
| Column | Type | #Distinct Values | #Nulls | Max Size | Avg Size |
+-----------+---------+------------------+--------+----------+----------+
| id | INT | -1 | -1 | 4 | 4 |
| val | INT | -1 | -1 | 4 | 4 |
| zfill | STRING | -1 | -1 | -1 | -1 |
| name | STRING | -1 | -1 | -1 | -1 |
| assertion | BOOLEAN | -1 | -1 | 1 | 1 |
| year | INT | 1 | 0 | 4 | 4 |
| month | INT | 1 | 0 | 4 | 4 |
| day | INT | 5 | 0 | 4 | 4 |
+-----------+---------+------------------+--------+----------+----------+

compute stats year_month_day;
+-----------------------------------------+
| summary |
+-----------------------------------------+
| Updated 5 partition(s) and 5 column(s). |
+-----------------------------------------+

show table stats year_month_day;
+-------+-------+-----+--------+--------+---------+--------------+-------------------+---------+...
| year | month | day | #Rows | #Files | Size | Bytes Cached | Cache Replication | Format |...
+-------+-------+-----+--------+--------+---------+--------------+-------------------+---------+...
| 2013 | 12 | 1 | 93606 | 1 | 2.51MB | NOT CACHED | NOT CACHED | PARQUET |...
| 2013 | 12 | 2 | 94158 | 1 | 2.53MB | NOT CACHED | NOT CACHED | PARQUET |...
| 2013 | 12 | 3 | 94122 | 1 | 2.52MB | NOT CACHED | NOT CACHED | PARQUET |...
| 2013 | 12 | 4 | 93559 | 1 | 2.51MB | NOT CACHED | NOT CACHED | PARQUET |...
| 2013 | 12 | 5 | 93845 | 1 | 2.52MB | NOT CACHED | NOT CACHED | PARQUET |...
| Total | | | 469290 | 5 | 12.58MB | 0B | | |...
+-------+-------+-----+--------+--------+---------+--------------+-------------------+---------+...

show column stats year_month_day;
+-----------+---------+------------------+--------+----------+-------------------+
| Column | Type | #Distinct Values | #Nulls | Max Size | Avg Size |
+-----------+---------+------------------+--------+----------+-------------------+
| id | INT | 511129 | -1 | 4 | 4 |
| val | INT | 364853 | -1 | 4 | 4 |
| zfill | STRING | 311430 | -1 | 6 | 6 |
| name | STRING | 471975 | -1 | 22 | 13.00160026550293 |
| assertion | BOOLEAN | 2 | -1 | 1 | 1 |
| year | INT | 1 | 0 | 4 | 4 |
| month | INT | 1 | 0 | 4 | 4 |
| day | INT | 5 | 0 | 4 | 4 |
+-----------+---------+------------------+--------+----------+-------------------+
1.1.4 增量信息统计
在2.1.0高，你可以使用语法计算增量数据和增量数据下降。增量子句与增量统计工作，是一个专门的功能分区表，是大或经常更新新的分区。
INCREMENTAL STATS or DROP INCREMENTAL STATS statement.
1.1.5 什么时候需要重新统计信息
当一个内容表或分区明显变化，重新计算统计相关数据表或分区。
变化是“重大”的程度不同，根据表的绝对和相对大小。
通常，如果你添加了30%多个数据表，这是值得重新计算统计，因为行和不同值的数量差异可能导致impala选择不同的连接顺序时，表中使用的查询。这个指南对于最大的表是最重要的。
例如，增加30%个新的数据表中含有1 TB的具有更大的影响比加入顺序加30%表只包含几兆字节，而较大的表对查询性能有较大的影响如果impala选择一个次优顺序连接由于过时的统计数据。
如果你加载一个完整的数据表中的数据的新的集合，而每一列的行数和不同值的数量是相对不变的，你不需要重新计算统计表。
如果一个表的数据是过时的，和表的大小使它重新计算新的数据立即不切实际，你可以使用下拉数据声明删除过时的数据，使其更容易识别，需要一个新的计算统计操作表。
对于一个大的分区表，请考虑使用增量统计特征在Impala 2.1.0高可用，在增量统计概要说明。如果你添加一个新的分区表，这是值得重新计算增量数据，因为操作只需扫描数据，一个新的分区。
1.1.6 查看表和列的统计信息样例
[localhost:21000] > show table stats store;
+-------+--------+--------+--------+
| #Rows | #Files | Size | Format |
+-------+--------+--------+--------+
| -1 | 1 | 3.08KB | TEXT |
+-------+--------+--------+--------+
|Returned 1 row(s) in 0.03s
[localhost:21000] > show column stats store;
+--------------------+-----------+------------------+--------+----------+----------+
| Column | Type | #Distinct Values | #Nulls | Max Size | Avg Size |
+--------------------+-----------+------------------+--------+----------+----------+
| s_store_sk | INT | -1 | -1 | 4 | 4 |
| s_store_id | STRING | -1 | -1 | -1 | -1 |
| s_rec_start_date | TIMESTAMP | -1 | -1 | 16 | 16 |
| s_rec_end_date | TIMESTAMP | -1 | -1 | 16 | 16 |
| s_closed_date_sk | INT | -1 | -1 | 4 | 4 |
| s_store_name | STRING | -1 | -1 | -1 | -1 |
| s_number_employees | INT | -1 | -1 | 4 | 4 |
| s_floor_space | INT | -1 | -1 | 4 | 4 |
| s_hours | STRING | -1 | -1 | -1 | -1 |
| s_manager | STRING | -1 | -1 | -1 | -1 |
| s_market_id | INT | -1 | -1 | 4 | 4 |
| s_geography_class | STRING | -1 | -1 | -1 | -1 |
| s_market_desc | STRING | -1 | -1 | -1 | -1 |
| s_market_manager | STRING | -1 | -1 | -1 | -1 |
| s_division_id | INT | -1 | -1 | 4 | 4 |
| s_division_name | STRING | -1 | -1 | -1 | -1 |
| s_company_id | INT | -1 | -1 | 4 | 4 |
| s_company_name | STRING | -1 | -1 | -1 | -1 |
| s_street_number | STRING | -1 | -1 | -1 | -1 |
| s_street_name | STRING | -1 | -1 | -1 | -1 |
| s_street_type | STRING | -1 | -1 | -1 | -1 |
| s_suite_number | STRING | -1 | -1 | -1 | -1 |
| s_city | STRING | -1 | -1 | -1 | -1 |
| s_county | STRING | -1 | -1 | -1 | -1 |
| s_state | STRING | -1 | -1 | -1 | -1 |
| s_zip | STRING | -1 | -1 | -1 | -1 |
| s_country | STRING | -1 | -1 | -1 | -1 |
| s_gmt_offset | FLOAT | -1 | -1 | 4 | 4 |
| s_tax_percentage | FLOAT | -1 | -1 | 4 | 4 |
+--------------------+-----------+------------------+--------+----------+----------+
Returned 29 row(s) in 0.04s
在分析列统计表的表报表时，您必须指定用于收集统计数据的每个列。impala计算统计报表自动汇总所有列的统计，因为它读取整个表比较快，可以有效地计算所有列的值。这个例子显示了运行后的计算统计报表，统计数据被填充在表和它的所有列中：
[localhost:21000] > compute stats store;
+------------------------------------------+
| summary |
+------------------------------------------+
| Updated 1 partition(s) and 29 column(s). |
+------------------------------------------+
|Returned 1 row(s) in 1.88s
[localhost:21000] > show table stats store;
+-------+--------+--------+--------+
| #Rows | #Files | Size | Format |
+-------+--------+--------+--------+
| 12 | 1 | 3.08KB | TEXT |
+-------+--------+--------+--------+
|Returned 1 row(s) in 0.02s
[localhost:21000] > show column stats store;
+--------------------+-----------+------------------+--------+----------+-------------------+
| Column | Type | #Distinct Values | #Nulls | Max Size | Avg Size |
+--------------------+-----------+------------------+--------+----------+-------------------+
| s_store_sk | INT | 12 | -1 | 4 | 4 |
| s_store_id | STRING | 6 | -1 | 16 | 16 |
| s_rec_start_date | TIMESTAMP | 4 | -1 | 16 | 16 |
| s_rec_end_date | TIMESTAMP | 3 | -1 | 16 | 16 |
| s_closed_date_sk | INT | 3 | -1 | 4 | 4 |
| s_store_name | STRING | 8 | -1 | 5 | 4.25 |
| s_number_employees | INT | 9 | -1 | 4 | 4 |
| s_floor_space | INT | 10 | -1 | 4 | 4 |
| s_hours | STRING | 2 | -1 | 8 | 7.083300113677979 |
| s_manager | STRING | 7 | -1 | 15 | 12 |
| s_market_id | INT | 7 | -1 | 4 | 4 |
| s_geography_class | STRING | 1 | -1 | 7 | 7 |
| s_market_desc | STRING | 10 | -1 | 94 | 55.5 |
| s_market_manager | STRING | 7 | -1 | 16 | 14 |
| s_division_id | INT | 1 | -1 | 4 | 4 |
| s_division_name | STRING | 1 | -1 | 7 | 7 |
| s_company_id | INT | 1 | -1 | 4 | 4 |
| s_company_name | STRING | 1 | -1 | 7 | 7 |
| s_street_number | STRING | 9 | -1 | 3 | 2.833300113677979 |
| s_street_name | STRING | 12 | -1 | 11 | 6.583300113677979 |
| s_street_type | STRING | 8 | -1 | 9 | 4.833300113677979 |
| s_suite_number | STRING | 11 | -1 | 9 | 8.25 |
| s_city | STRING | 2 | -1 | 8 | 6.5 |
| s_county | STRING | 1 | -1 | 17 | 17 |
| s_state | STRING | 1 | -1 | 2 | 2 |
| s_zip | STRING | 2 | -1 | 5 | 5 |
| s_country | STRING | 1 | -1 | 13 | 13 |
| s_gmt_offset | FLOAT | 1 | -1 | 4 | 4 |
| s_tax_percentage | FLOAT | 5 | -1 | 4 | 4 |
+--------------------+-----------+------------------+--------+----------+-------------------+
Returned 29 row(s) in 0.04s

下面的示例显示了如何将统计数据表示为一个分区表。在这种情况下，我们已经建立了一个表，以保持世界上最琐碎的人口普查数据，一个单一的字符串字段，按一年的列分区。表统计包括每个分区的单独的条目，以及数字字段的最终总计。列数据包括分区列一些容易推断出来的事实，如不同值的数量（划分子目录的数量）。

localhost:21000] > describe census;
+------+----------+---------+
| name | type | comment |
+------+----------+---------+
| name | string | |
| year | smallint | |
+------+----------+---------+
Returned 2 row(s) in 0.02s
[localhost:21000] > show table stats census;
+-------+-------+--------+------+---------+
| year | #Rows | #Files | Size | Format |
+-------+-------+--------+------+---------+
| 2000 | -1 | 0 | 0B | TEXT |
| 2004 | -1 | 0 | 0B | TEXT |
| 2008 | -1 | 0 | 0B | TEXT |
| 2010 | -1 | 0 | 0B | TEXT |
| 2011 | 0 | 1 | 22B | TEXT |
| 2012 | -1 | 1 | 22B | TEXT |
| 2013 | -1 | 1 | 231B | PARQUET |
| Total | 0 | 3 | 275B | |
+-------+-------+--------+------+---------+
Returned 8 row(s) in 0.02s
[localhost:21000] > show column stats census;
+--------+----------+------------------+--------+----------+----------+
| Column | Type | #Distinct Values | #Nulls | Max Size | Avg Size |
+--------+----------+------------------+--------+----------+----------+
| name | STRING | -1 | -1 | -1 | -1 |
| year | SMALLINT | 7 | -1 | 2 | 2 |
+--------+----------+------------------+--------+----------+----------+
Returned 2 row(s) in 0.02s
The following example shows how the statistics are filled in by a COMPUTE STATS statement in Impala.
[localhost:21000] > compute stats census;
+-----------------------------------------+
| summary |
+-----------------------------------------+
| Updated 3 partition(s) and 1 column(s). |
+-----------------------------------------+
|Returned 1 row(s) in 2.16s
[localhost:21000] > show table stats census;
+-------+-------+--------+------+---------+
| year | #Rows | #Files | Size | Format |
+-------+-------+--------+------+---------+
| 2000 | -1 | 0 | 0B | TEXT |
| 2004 | -1 | 0 | 0B | TEXT |
| 2008 | -1 | 0 | 0B | TEXT |
| 2010 | -1 | 0 | 0B | TEXT |
| 2011 | 4 | 1 | 22B | TEXT |
| 2012 | 4 | 1 | 22B | TEXT |
| 2013 | 1 | 1 | 231B | PARQUET |
| Total | 9 | 3 | 275B | |
+-------+-------+--------+------+---------+
Returned 8 row(s) in 0.02s
[localhost:21000] > show column stats census;
+--------+----------+------------------+--------+----------+----------+
| Column | Type | #Distinct Values | #Nulls | Max Size | Avg Size |
+--------+----------+------------------+--------+----------+----------+
| name | STRING | 4 | -1 | 5 | 4.5 |
| year | SMALLINT | 7 | -1 | 2 | 2 |
+--------+----------+------------------+--------+----------+----------+
Returned 2 row(s) in 0.02s

1.4 Hadoop-impala十大优化之（4）—根据执行计划进行性能优化及最佳实践

1.1.1 使用解释计划进行性能调整
解释语句为您提供了一个查询将执行的逻辑步骤的概要，例如，如何将工作分配在节点

之间，以及如何将中间结果合并到生成最终结果集。在实际运行查询之前，您可以看到这些详细信息。您可以使用此信息来检查查询将不会在一些非常意想不到的或低效的方式操作。
[impalad-host:21000]> explain select count(*) from customer_address;
+----------------------------------------------------------+
| ExplainString |
+----------------------------------------------------------+
| EstimatedPer-Host Requirements: Memory=42.00MB VCores=1 |
| |
|03:AGGREGATE [MERGE FINALIZE] |
| | output: sum(count(*)) |
| | |
|02:EXCHANGE [PARTITION=UNPARTITIONED] |
| | |
|01:AGGREGATE |
| | output: count(*) |
| | |
| 00:SCANHDFS [default.customer_address] |
| partitions=1/1 size=5.25MB |
+----------------------------------------------------------+
从下到上阅读解释计划：
该计划的最后一部分显示了低级别的细节，如预期的数据量，将被读取，在那里你可以判断你的分区策略的有效性，并估计将需要多长时间扫描一个表的基础上总的数据大小和大小的集群。
然后你看到的操作，将每个节点执行并行的impala。
在更高的层次，您可以看到当中间结果集合并和从一个节点发送到另一个节点时，数据流如何。
看到关于explain_level查询选项的详细信息explain_level查询选项，它允许您自定义显示解释计划取决于你正在做的高级或低级调谐多少细节，处理查询的逻辑或物理方面。
解释计划还打印在使用性能调整的查询配置文件中所描述的查询配置文件的开始处，以便于检查并排的查询的逻辑和物理方面的便利性。
在解释输出的explain_level查询选项控制显示细节的数量。你通常会增加这个设置从正常的冗长（或从0到1）时，仔细检查表和列数据时性能调优，或当估计查询资源使用与CDH 5资源管理功能的结合。
1.1.1 使用性能调整的总结报告
在impala-shell解释器摘要命令给你一个容易消化的时间概述用于查询执行的不同阶段。像解释计划一样，很容易看到潜在的性能瓶颈。像配置文件输出，它是可用的查询后运行，所以显示实际的时间数。
摘要报告还打印在使用性能调整的查询配置文件中所描述的查询概要报告的开始处，以便于检查并排的查询的高级和低级方面的问题。
例如，这里是一个包含聚合函数的查询，在一个单一的节点上的虚拟机。的查询和他们的时间的不同阶段表现（卷起所有节点），以及估计值与实际值用于规划查询。在这种情况下，该avg()功能为每个节点上的数据的一个子集计算（01级）然后汇总结果，从所有节点结合在年底（03期）。你可以看到哪个阶段花了最多的时间，以及是否有任何估计值与实际的数据分布有明显的不同。（在检查的时间值，可以考虑后缀如我们毫秒、微秒和毫秒而不是寻找最大的数字。）

[localhost:21000] > select avg(ss_sales_price) from store_sales wheress_coupon_amt = 0;
+---------------------+
|avg(ss_sales_price) |
+---------------------+
|37.80770926328327 |
+---------------------+
[localhost:21000]> summary;
+--------------+--------+----------+----------+-------+------------+----------+---------------+-----------------+
|Operator | #Hosts | Avg Time | MaxTime | #Rows | Est. #Rows | Peak Mem | Est. Peak Mem | Detail |
+--------------+--------+----------+----------+-------+------------+----------+---------------+-----------------+
|03:AGGREGATE | 1 | 1.03ms | 1.03ms | 1 | 1 | 48.00 KB | -1 B | MERGE FINALIZE |
|02:EXCHANGE | 1 | 0ns | 0ns | 1 | 1 | 0 B | -1 B | UNPARTITIONED |
|01:AGGREGATE | 1 | 30.79ms | 30.79ms | 1 | 1 | 80.00 KB | 10.00 MB | |
| 00:SCANHDFS | 1 | 5.45s | 5.45s | 2.21M | -1 | 64.05 MB |432.00 MB | tpc.store_sales |
+--------------+--------+----------+----------+-------+------------+----------+---------------+-----------------+

请注意查询最长的初始相位的测量单位是秒（s），而后期工作在较小的中间结果进行测量毫秒（ms）甚至纳秒（ns）。
这里有一个例子，从一个更复杂的查询，因为它会出现在配置文件输出：

Operator #Hosts Avg Time Max Time #Rows Est. #Rows Peak Mem Est. Peak Mem Detail

09:MERGING-EXCHANGE 1 79.738us 79.738us 5 5 0 -1.00 B UNPARTITIONED
05:TOP-N 3 84.693us 88.810us 5 5 12.00 KB 120.00 B
04:AGGREGATE 3 5.263ms 6.432ms 5 5 44.00 KB 10.00 MB MERGE FINALIZE
08:AGGREGATE 3 16.659ms 27.444ms 52.52K 600.12K 3.20 MB 15.11 MB MERGE
07:EXCHANGE 3 2.644ms 5.1ms 52.52K 600.12K 0 0 HASH(o_orderpriority)
03:AGGREGATE 3 342.913ms 966.291ms 52.52K 600.12K 10.80 MB 15.11 MB
02:HASHJOIN 3 2s165ms 2s171ms 144.87K 600.12K 13.63 MB 941.01 KB INNER JOIN, BROADCAST
|--06:EXCHANGE 3 8.296ms 8.692ms 57.22K 15.00K 0 0 BROADCAST
| 01:SCAN HDFS 2 1s412ms 1s978ms 57.22K 15.00K 24.21 MB 176.00 MB tpch.orders o
00:SCANHDFS 3 8s032ms 8s558ms 3.79M 600.12K 32.29 MB 264.00 MB tpch.lineitem l

1.1.2 使用性能调整的查询配置文件
profile语句，在impala-shell解释器，产生一个详细的报告显示低水平的最新查询被执行。不同于使用解释计划进行性能调整的解释计划，此信息仅在查询完成后才可用。它显示物理细节，如读取字节数、最大内存使用量等每个节点的物理细节。您可以使用此信息来确定如果查询是I/O密集型或CPU绑定的，是否有网络条件实施的瓶颈，是否放缓是影响而不是其他的一些节点，并检查推荐配置设置，如短路本地读取效果。
默认情况下，配置文件输出的时间值反映了操作所采取的墙上时钟时间。指示系统的时间或用户的时间值，测量单位是反映在指标的名字，如scannerthreadssystime或scannerthreadsusertime。例如，一个多线程的I / O操作可能会显示一个小的数字墙上的时钟时间，而相应的系统时间是较大的，代表的总和所采取的每一个线程的中央处理器时间。或是一个墙时钟的时间可能会更大，因为它计算时间等待时间，而相应的系统和用户的时间数字只测量时间，而操作正在积极使用的处理器周期。
该解释计划也打印在查询简要表报告的开始处，以便于检查并排的查询的逻辑和物理方面的便利性。的explain_level查询选项的解释也控制输出的打印命令的详细资料。
这里是一个查询配置文件的例子，从一个相对简单的查询一个单一的节点的伪分布式集群保持输出相对较短。
[localhost:21000]> profile;
QueryRuntime Profile:
Query(id=6540a03d4bee0691:4963d6269b210ebd):
Summary:
Session ID:ea4a197f1c7bf858:c74e66f72e3a33ba
Session Type: BEESWAX
Start Time: 2013-12-02 17:10:30.263067000
End Time: 2013-12-02 17:10:50.932044000
Query Type: QUERY
Query State: FINISHED
Query Status: OK
Impala Version: impalad version 1.2.1RELEASE (build edb5af1bcad63d410bc5d47cc203df3a880e9324)
User: cloudera
Network Address: 127.0.0.1:49161
Default Db: stats_testing
Sql Statement: select t1.s, t2.s from t1join t2 on (t1.id = t2.parent)

Plan:

EstimatedPer-Host Requirements: Memory=2.09GB VCores=2

PLANFRAGMENT 0
PARTITION: UNPARTITIONED

4:EXCHANGE
cardinality: unavailable
per-host memory: unavailable
tuple ids: 0 1

PLANFRAGMENT 1
PARTITION: RANDOM

STREAM DATA SINK
EXCHANGE ID: 4
UNPARTITIONED

PLANFRAGMENT 2
PARTITION: RANDOM

STREAM DATA SINK
EXCHANGE ID: 3
UNPARTITIONED

1:SCAN HDFS
table=stats_testing.t2 #partitions=1/1size=960.00KB
table stats: unavailable
column stats: unavailable
cardinality: unavailable
per-host memory: 96.00MB

tuple ids: 1

Query Timeline: 20s670ms

Start execution: 2.559ms (2.559ms)
Planning finished: 23.587ms (21.27ms)
Rows available: 666.199ms (642.612ms)
First row fetched: 668.919ms (2.719ms)
Unregister query: 20s668ms (20s000ms)
ImpalaServer:
ClientFetchWaitTimer: 19s637ms
RowMaterializationTimer: 167.121ms
Execution Profile6540a03d4bee0691:4963d6269b210ebd:(Active: 837.815ms, % non-child: 0.00%)
Per Node Peak Memory Usage: impala-1.example.com:22000(7.42MB)
FinalizationTimer: 0ns
Coordinator Fragment:(Active: 195.198ms, %non-child: 0.00%)
MemoryUsage(500.0ms): 16.00 KB, 7.42 MB,7.33 MB, 7.10 MB, 6.94 MB, 6.71 MB, 6.56 MB, 6.40 MB, 6.17 MB, 6.02 MB, 5.79MB, 5.63 MB, 5.48 MB, 5.25 MB, 5.09 MB, 4.86 MB, 4.71 MB, 4.47 MB, 4.32 MB,4.09 MB, 3.93 MB, 3.78 MB, 3.55 MB, 3.39 MB, 3.16 MB, 3.01 MB, 2.78 MB, 2.62MB, 2.39 MB, 2.24 MB, 2.08 MB, 1.85 MB, 1.70 MB, 1.54 MB, 1.31 MB, 1.16 MB,948.00 KB, 790.00 KB, 553.00 KB, 395.00 KB, 237.00 KB
ThreadUsage(500.0ms): 1
AverageThreadTokens: 1.00
PeakMemoryUsage: 7.42 MB
-PrepareTime: 36.144us
RowsProduced: 98.30K (98304)
TotalCpuTime: 20s449ms
TotalNetworkWaitTime: 191.630ms
TotalStorageWaitTime: 0ns
CodeGen:(Active: 150.679ms, % non-child:77.19%)
CodegenTime: 0ns
CompileTime: 139.503ms
LoadTime: 10.7ms
ModuleFileSize: 95.27 KB
EXCHANGE_NODE (id=4):(Active: 194.858ms,% non-child: 99.83%)
BytesReceived: 2.33 MB
ConvertRowBatchTime: 2.732ms
DataArrivalWaitTime: 191.118ms
DeserializeRowBatchTimer: 14.943ms
FirstBatchArrivalWaitTime: 191.117ms
PeakMemoryUsage: 7.41 MB
RowsReturned: 98.30K (98304)
RowsReturnedRate: 504.49 K/sec
SendersBlockedTimer: 0ns
SendersBlockedTotalTimer(*): 0ns
Averaged Fragment 1:(Active: 442.360ms, %non-child: 0.00%)
split sizes: min: 33.00 B, max: 33.00 B, avg: 33.00 B,stddev: 0.00
completion times: min:443.720ms max:443.720ms mean: 443.720ms stddev:0ns
execution rates: min:74.00 B/sec max:74.00 B/sec mean:74.00 B/sec stddev:0.00 /sec
num instances: 1
AverageThreadTokens: 1.00
PeakMemoryUsage: 6.06 MB
PrepareTime: 7.291ms
RowsProduced: 98.30K (98304)
TotalCpuTime: 784.259ms
TotalNetworkWaitTime: 388.818ms
TotalStorageWaitTime: 3.934ms
CodeGen:(Active: 312.862ms, % non-child:70.73%)
CodegenTime: 2.669ms
CompileTime: 302.467ms
LoadTime: 9.231ms
ModuleFileSize: 95.27 KB
DataStreamSender (dst_id=4):(Active:80.63ms, % non-child: 18.10%)
BytesSent: 2.33 MB
NetworkThroughput(*): 35.89 MB/sec
OverallThroughput: 29.06 MB/sec
PeakMemoryUsage: 5.33 KB
SerializeBatchTime: 26.487ms
ThriftTransmitTime(*): 64.814ms
UncompressedRowBatchSize: 6.66 MB
HASH_JOIN_NODE (id=2):(Active: 362.25ms,% non-child: 3.92%)
BuildBuckets: 1.02K (1024)
BuildRows: 98.30K (98304)
BuildTime: 12.622ms
LoadFactor: 0.00
PeakMemoryUsage: 6.02 MB
ProbeRows: 3
ProbeTime: 3.579ms
RowsReturned: 98.30K (98304)
RowsReturnedRate: 271.54 K/sec
EXCHANGE_NODE (id=3):(Active:344.680ms, % non-child: 77.92%)
BytesReceived: 1.15 MB
ConvertRowBatchTime: 2.792ms
DataArrivalWaitTime: 339.936ms
DeserializeRowBatchTimer: 9.910ms
FirstBatchArrivalWaitTime:199.474ms
PeakMemoryUsage: 156.00 KB
RowsReturned: 98.30K (98304)
RowsReturnedRate: 285.20 K/sec
SendersBlockedTimer: 0ns
SendersBlockedTotalTimer(*): 0ns
HDFS_SCAN_NODE (id=0):(Active: 13.616us,% non-child: 0.00%)
AverageHdfsReadThreadConcurrency:0.00
AverageScannerThreadConcurrency:0.00
BytesRead: 33.00 B
BytesReadLocal: 33.00 B
BytesReadShortCircuit: 33.00 B
NumDisksAccessed: 1
NumScannerThreadsStarted: 1
PeakMemoryUsage: 46.00 KB
PerReadThreadRawHdfsThroughput:287.52 KB/sec
RowsRead: 3
RowsReturned: 3
RowsReturnedRate: 220.33 K/sec
ScanRangesComplete: 1
-ScannerThreadsInvoluntaryContextSwitches: 26
ScannerThreadsTotalWallClockTime:55.199ms
DelimiterParseTime: 2.463us
MaterializeTupleTime(*): 1.226us
ScannerThreadsSysTime: 0ns
ScannerThreadsUserTime: 42.993ms
-ScannerThreadsVoluntaryContextSwitches: 1
TotalRawHdfsReadTime(*): 112.86us
TotalReadThroughput: 0.00 /sec
Averaged Fragment 2:(Active: 190.120ms, %non-child: 0.00%)
split sizes: min: 960.00 KB, max: 960.00 KB, avg: 960.00KB, stddev: 0.00
completion times: min:191.736ms max:191.736ms mean: 191.736ms stddev:0ns
execution rates: min:4.89 MB/sec max:4.89 MB/sec mean:4.89 MB/sec stddev:0.00 /sec
num instances: 1
AverageThreadTokens: 0.00
PeakMemoryUsage: 906.33 KB
PrepareTime: 3.67ms
RowsProduced: 98.30K (98304)
TotalCpuTime: 403.351ms
TotalNetworkWaitTime: 34.999ms
TotalStorageWaitTime: 108.675ms
CodeGen:(Active: 162.57ms, % non-child:85.24%)
CodegenTime: 3.133ms
CompileTime: 148.316ms
LoadTime: 12.317ms
ModuleFileSize: 95.27 KB
DataStreamSender (dst_id=3):(Active:70.620ms, % non-child: 37.14%)
BytesSent: 1.15 MB
NetworkThroughput(*): 23.30 MB/sec
OverallThroughput: 16.23 MB/sec
PeakMemoryUsage: 5.33 KB
SerializeBatchTime: 22.69ms
ThriftTransmitTime(*): 49.178ms
UncompressedRowBatchSize: 3.28 MB
HDFS_SCAN_NODE (id=1):(Active: 118.839ms,% non-child: 62.51%)
AverageHdfsReadThreadConcurrency:0.00
AverageScannerThreadConcurrency:0.00
BytesRead: 960.00 KB
BytesReadLocal: 960.00 KB
BytesReadShortCircuit: 960.00 KB
NumDisksAccessed: 1
NumScannerThreadsStarted: 1
PeakMemoryUsage: 869.00 KB
PerReadThreadRawHdfsThroughput:130.21 MB/sec
RowsRead: 98.30K (98304)
RowsReturned: 98.30K (98304)
RowsReturnedRate: 827.20 K/sec
ScanRangesComplete: 15
-ScannerThreadsInvoluntaryContextSwitches: 34
ScannerThreadsTotalWallClockTime:189.774ms
DelimiterParseTime: 15.703ms
MaterializeTupleTime(*): 3.419ms
ScannerThreadsSysTime: 1.999ms
ScannerThreadsUserTime: 44.993ms
-ScannerThreadsVoluntaryContextSwitches: 118
TotalRawHdfsReadTime(*): 7.199ms
TotalReadThroughput: 0.00 /sec
Fragment 1:
Instance6540a03d4bee0691:4963d6269b210ebf (host=impala-1.example.com:22000):(Active:442.360ms, % non-child: 0.00%)
Hdfs split stats (:<# splits>/): 0:1/33.00 B
MemoryUsage(500.0ms): 69.33 KB
ThreadUsage(500.0ms): 1
AverageThreadTokens: 1.00
PeakMemoryUsage: 6.06 MB
PrepareTime: 7.291ms
RowsProduced: 98.30K (98304)
TotalCpuTime: 784.259ms
TotalNetworkWaitTime: 388.818ms
TotalStorageWaitTime: 3.934ms
CodeGen:(Active: 312.862ms, %non-child: 70.73%)
CodegenTime: 2.669ms
CompileTime: 302.467ms
LoadTime: 9.231ms
ModuleFileSize: 95.27 KB
DataStreamSender (dst_id=4):(Active:80.63ms, % non-child: 18.10%)
BytesSent: 2.33 MB
NetworkThroughput(*): 35.89 MB/sec
OverallThroughput: 29.06 MB/sec
PeakMemoryUsage: 5.33 KB
SerializeBatchTime: 26.487ms
ThriftTransmitTime(*): 64.814ms
UncompressedRowBatchSize: 6.66 MB
HASH_JOIN_NODE (id=2):(Active:362.25ms, % non-child: 3.92%)
ExecOption: Build Side Codegen Enabled,Probe Side Codegen Enabled, Hash Table Built Asynchronously
BuildBuckets: 1.02K (1024)
BuildRows: 98.30K (98304)
BuildTime: 12.622ms
LoadFactor: 0.00
PeakMemoryUsage: 6.02 MB
ProbeRows: 3
ProbeTime: 3.579ms
RowsReturned: 98.30K (98304)
RowsReturnedRate: 271.54 K/sec
EXCHANGE_NODE (id=3):(Active:344.680ms, % non-child: 77.92%)
BytesReceived: 1.15 MB
ConvertRowBatchTime: 2.792ms
DataArrivalWaitTime: 339.936ms
DeserializeRowBatchTimer:9.910ms
FirstBatchArrivalWaitTime:199.474ms
PeakMemoryUsage: 156.00 KB
RowsReturned: 98.30K (98304)
RowsReturnedRate: 285.20 K/sec
SendersBlockedTimer: 0ns
SendersBlockedTotalTimer(*): 0ns
HDFS_SCAN_NODE (id=0):(Active:13.616us, % non-child: 0.00%)
Hdfs split stats (:<# splits>/): 0:1/33.00 B
Hdfs Read Thread Concurrency Bucket:0:0% 1:0%
File Formats: TEXT/NONE:1
ExecOption: Codegen enabled: 1 out of1
AverageHdfsReadThreadConcurrency:0.00
AverageScannerThreadConcurrency: 0.00
BytesRead: 33.00 B
BytesReadLocal: 33.00 B
BytesReadShortCircuit: 33.00 B
NumDisksAccessed: 1
NumScannerThreadsStarted: 1
PeakMemoryUsage: 46.00 KB
PerReadThreadRawHdfsThroughput:287.52 KB/sec
RowsRead: 3
RowsReturned: 3
RowsReturnedRate: 220.33 K/sec
ScanRangesComplete: 1
-ScannerThreadsInvoluntaryContextSwitches: 26
ScannerThreadsTotalWallClockTime:55.199ms
DelimiterParseTime: 2.463us
MaterializeTupleTime(*): 1.226us
ScannerThreadsSysTime: 0ns
ScannerThreadsUserTime: 42.993ms
-ScannerThreadsVoluntaryContextSwitches: 1
TotalRawHdfsReadTime(*): 112.86us
TotalReadThroughput: 0.00 /sec
Fragment 2:
Instance6540a03d4bee0691:4963d6269b210ec0 (host=impala-1.example.com:22000):(Active: 190.120ms,% non-child: 0.00%)
Hdfs split stats (:<# splits>/): 0:15/960.00 KB
AverageThreadTokens: 0.00
PeakMemoryUsage: 906.33 KB
PrepareTime: 3.67ms
RowsProduced: 98.30K (98304)
TotalCpuTime: 403.351ms
TotalNetworkWaitTime: 34.999ms
TotalStorageWaitTime: 108.675ms
CodeGen:(Active: 162.57ms, % non-child:85.24%)
CodegenTime: 3.133ms
CompileTime: 148.316ms
LoadTime: 12.317ms
ModuleFileSize: 95.27 KB
DataStreamSender (dst_id=3):(Active:70.620ms, % non-child: 37.14%)
BytesSent: 1.15 MB
NetworkThroughput(*): 23.30 MB/sec
OverallThroughput: 16.23 MB/sec
PeakMemoryUsage: 5.33 KB
SerializeBatchTime: 22.69ms
ThriftTransmitTime(*): 49.178ms
UncompressedRowBatchSize: 3.28 MB
HDFS_SCAN_NODE (id=1):(Active:118.839ms, % non-child: 62.51%)
Hdfs split stats (:<# splits>/): 0:15/960.00 KB
Hdfs Read Thread Concurrency Bucket:0:0% 1:0%
File Formats: TEXT/NONE:15
ExecOption: Codegen enabled: 15 outof 15
AverageHdfsReadThreadConcurrency:0.00
AverageScannerThreadConcurrency:0.00
BytesRead: 960.00 KB
BytesReadLocal: 960.00 KB
BytesReadShortCircuit: 960.00 KB
NumDisksAccessed: 1
NumScannerThreadsStarted: 1
PeakMemoryUsage: 869.00 KB
PerReadThreadRawHdfsThroughput:130.21 MB/sec
RowsRead: 98.30K (98304)
RowsReturned: 98.30K (98304)
RowsReturnedRate: 827.20 K/sec
ScanRangesComplete: 15
-ScannerThreadsInvoluntaryContextSwitches: 34
ScannerThreadsTotalWallClockTime:189.774ms
DelimiterParseTime: 15.703ms
MaterializeTupleTime(*): 3.419ms
ScannerThreadsSysTime: 1.999ms
ScannerThreadsUserTime: 44.993ms
-ScannerThreadsVoluntaryContextSwitches: 118
TotalRawHdfsReadTime(*): 7.199ms
TotalReadThroughput: 0.00 /sec

1.5 hadoop-impala十大优化之（5）—基准Impala查询最佳实践
Impala，像其他的Hadoop组件，目的是在分布式环境中处理大量的数据，进行性能测试，使用真实的数据和集群配置。使用一个多节点的集群，而不是一个单一的节点；对运行中包含数据而不是数十GB百万兆字节表查询。用Impala的并行处理技术是最适合的工作负载，超出单个服务器的能力。
当您运行查询返回大量的行时，该处理器的时间花费到漂亮的打印输出是实质性的，给一个不准确的测量的实际查询时间。考虑使用-B选项的Impala-shell命令关掉漂亮的打印输出，和任选的-o选项来存储查询结果文件中而不是打印到屏幕上。看到Impala-shell配置选项的详细信息。

1.6 hadoop-impala十大优化之（6）—控制资源使用最佳实践
有时，平衡原始查询性能对可扩展性需要限制的资源量，如内存或中央处理器，使用一个单一的查询或组查询。Impala可以使用多种机制，有助于消除负荷重的同时使用时，产生更快的整体查询时间和资源在Impala查询，MapReduce工作共享，以及其他在CDH集群工作负载：
Impala的接纳控制功能使用快速、分布式机制来阻止超过并行查询或使用的内存量的限制查询。查询是排队的，并执行其他查询完成和资源可用。您可以控制并发限制，并为不同的用户组指定不同的限制，根据不同类别的用户的优先级来划分群集资源。这个功能是新的Impala1.3，并与CDH 4和CDH5。查看接纳控制和查询队列的详细信息。
你可以限制内存Impala的储备量在查询执行过程中通过指定的impalad守护的mem_limit选项。看到修改细节Impala的启动选项。此限制仅适用于内存的查询直接引用；Impala储备额外的内存在启动时，例如举行缓存元数据。
生产部署，Cloudera的建议你实现资源隔离使用机制如C组，您可以使用Cloudera管理。详情在Cloudera管理文档查看静态资源池。

1.7 Impala查询运行时过滤最佳实践

1.1.1 运行时过滤
runtime_filter_mode=GLOBAL.
运行时过滤是一种广泛的优化在CDH 5.7 / Impala 2.5及更高版本可用特性。只有当表中数据的一小部分是查询分区表或评价一个连接条件的需要， Impala 确定合适的条件在查询运行时，和广播信息的所有impalad节点，读表，可以避免不必要的I/O读取分区数据，并通过发送只有符合加入跨网络的键的行子集避免不必要的网络传输。
此功能主要用于优化对大分区表（在名称动态分区修剪）和联接大表中的查询。本节中的信息，包括概念、内部，并为整个运行时故障排除信息过滤功能。对于分区表的特定调整步骤，参见动态分区修剪。
注：目前，此功能是随相应的设置设置为“medium”值（查询选项runtime_filter_mode=LOCAL）。这种保守的设置是为了避免回归现有的工作负载，由于潜在的更高的内存需求时，运行时过滤是完全启用。当你读到这一段，做一些性能和可扩展性的实验，通常你应该能够切换到“high”的runtime_filter_mode=GLOBAL。
1.1.2 运行时过滤的背景信息
要了解运行时过滤如何在一个详细的水平工作，您必须熟悉分布式数据库技术领域的一些术语：
什么是计划分段。Impala的每一个查询分解成更小的工作单元，分布在集群。在可能的情况下，通过对同一主机上执行的计划分段进行读取、过滤和聚合的数据块。对于某些操作，如连接结合中间结果为最终结果，数据传输从一个节点在网络上的另一个。
什么是扫描和哈希连接计划节点，以及它们在计算查询结果中的作用：
在Impala的查询计划，扫描节点执行I/O从底层数据文件读取。虽然这是从传统的数据库来说一个昂贵的操作，Hadoop集群和Impala进行优化，在一个高度并行的方式做这种I/O。主要的潜在的成本节约来自使用柱状Parquet格式（如Impala可以避免不必要的列读取数据）和分区表（在Impala可以避免不必要的分区读取数据）。
大多Impala联接使用哈希连接机制。（只是到最近的Impala开始使用嵌套循环连接技术，对非等值连接查询。某些种）在哈希联接，当评估加入条件从两个表，Impala和所有不同的列的值从表上加入一侧建有一内存中的哈希表。然后，为每一行从桌子上连接的另一边，Impala测试相关的列的值在这个哈希表或不。
一个哈希连接节点构建这样一个内存哈希表，然后进行比较，以确定哪些行匹配相关的连接条件，并应包括在结果集（或至少发送到随后的中间阶段的查询处理）。因为一个哈希连接的输入可能会在网络上传输到另一个主机，它是特别重要的，从性能的角度来看，修剪提前任何数据是不相关的。
更明显的值是在用作联接键的列中，在内存中的哈希表中较大的值，因此处理查询所需的内存越多。
广播连接和洗牌连接之间的区别。（一个洗牌加入Hadoop的概念有时被称为Impala的分区加入。）在一个广播连接，从连接一侧的表（通常是较小的表）是发送所有的所有查询中所涉及的主机。然后每个主机可以比较它的数据的一部分，从其他（更大）表对全套可能的连接键。在一个混洗连接中，没有明显的“更小”的表，所以这两个表的内容都被划分了，并且数据的相应部分被传送给涉及查询的每个主机。在Impala的选择有关不同种类的连接处理报表看到查询提示。
在构建阶段和探索阶段时，Impala过程联接查询的概念。生成阶段是包含连接键列的行，通常为较小的表，在网络上传输，并内置到一个或多个目标节点上的内存哈希表数据结构。探测阶段是在本地读取数据（通常来自较大的表），并将连接键列与内存哈希表中的值进行比较。相应的输入源（表，子查询，等等）这些阶段称为建设方和探头侧。
如何设置查询选项：Impala在一个Impala交互式shell会话通过设置命令，一个JDBC或ODBC应用程序通过SET语句，或用于所有的impalad守护进程通过default_query_options配置设置。
1.1.3 运行时过滤组件
在计划分段之间传输的过滤器基本上是联接键列的值的列表。当这个列表值实时传送到扫描节点，Impala可以过滤掉非匹配值后立即阅读它们，而不是发送数据到另一台主机进行比较，对内存中的哈希表的主机上。该数据结构被实现为一个盛开的过滤器，它使用一个基于概率的算法，以确定所有可能的匹配值。（基于概率的方面意味着过滤器可能包括一些非匹配的值，但如果是的话，这不会导致在最终结果中的任何不准确。）
有不同种类的过滤器来匹配不同类型的连接（分区和广播）。广播滤波器是一个完整的列表，可以立即通过扫描节点进行评估。分区的过滤器是一个相关值的部分列表（基于集群中的一个主机处理的数据）；所有分区的过滤器必须合并成一个（由协调器节点）在扫描节点可以使用的结果，以准确地过滤数据，因为它是从存储。
广播过滤器也被归类为本地或全球。与本地广播过滤器，过滤器中的信息是由一个后续的查询片段，运行在同一主机上产生的过滤器。非本地广播筛选器必须在网络上传输到正在运行在不同主机上的查询片段。Impala指定了3个主机每个生产非本地广播的过滤器，以防止一个太长的单慢主机的可能性。根据不同的runtime_filter_mode查询选项的设置（本地或全球），Impala或用一个保守的优化策略筛选器只消耗在产生相同的主机，或者更激进的策略，过滤器可以通过网络传输。
1.1.4 运行时过滤的文件格式考虑
运行时过滤的文件格式考虑
Parquet表最受益于运行时过滤优化。运行时过滤可以加快对分区或分区加入Parquet表的查询，和单表查询与Parquet表分区。请参阅使用Parquet格式的有关使用Parquet表Impala表信息。
对于其他的文件格式（文本，Avro，RCFile，并通过），运行时过滤速度对分区表查询。因为分区表可以使用混合的格式，Impala在所有的情况下产生的过滤器，即使他们不是最终用于优化查询。
1.1.5 运行时过滤器的等待间隔
因为它需要时间来生产运行的过滤器，特别是分区的过滤器，必须由协调器节点的组合，有一个以上的时间间隔，它是更有效的扫描节点去构建自己的中间结果集，即使中间数据大于最优。如果只需要几秒钟产生的过滤器，它是值得的额外的时间，如果修剪不必要的数据，可以节省分钟，在整个查询时间。您可以指定最大等待使用runtime_filter_wait_time_ms查询选项，以毫秒为单位的时间。
默认情况下，每个扫描节点等待高达1秒（1000毫秒）的过滤器到达。如果所有的过滤器都没有到达指定的时间间隔内，扫描节点进行，使用任何过滤器的到达，以帮助避免读取不必要的数据。如果扫描节点开始读取数据后，如果一个过滤器到达，扫描节点将该过滤器应用到过滤器到达后读取的数据，但不适用于已经读过的数据。
如果群集相对繁忙，您的工作负载包含许多资源密集型或长时间运行的查询，可以考虑增加等待时间，以便复杂的查询不会错过优化的机会。如果群集是轻负载，您的工作负载包含了许多小的查询只花了几秒钟，考虑减少等待时间，以避免每个查询的1秒延迟。
1.1.6 运行时过滤的查询选项
有关查询选项，控制运行时过滤的查询选项的以下部分：
第一个查询选项调整此功能的灵敏度-sensitivity。目前，默认情况下，它被设置为一个中等水平（本地-LOCAL）。验证后，更高的设置（全局-GLOBAL）不会导致任何与你现有的工作负载的回归，你通常应该使用全局设置为您的默认。
runtime_filter_mode查询选项（CDH 5.7或更高）
其他查询选项调整旋钮，通常只有调整后做性能测试，你可能想改变只有一个昂贵的查询时间：
max_num_runtime_filters查询选项（CDH 5.7或更高）
runtime_bloom_filter_size查询选项
disable_row_runtime_filtering查询选项（CDH 5.7或更高）
1.1.7 运行时过滤和查询计划
运行时过滤和查询计划
以相同的方式显示由解释语句所显示的查询计划包括每个计划片段使用的谓词的信息，它还包括说明是否一个计划片段产生或消耗一个运行时过滤器的注释。计划的片段产生滤波器包含注释如运行过滤器：filter_id <- table.column，而计划的片段，消耗了滤波器包含注释如运行过滤器：filter_id -> table.column。
下面的示例显示了一个查询，使用一个单一的运行时过滤（标记rf00）修剪是一个阶段的查询扫描分区，以查询结果的评价：
createtable yy (s string) partitioned by (year int) stored as parquet;
insert intoyy partition (year) values ('1999', 1999), ('2000', 2000),
('2001', 2001), ('2010',2010);
computestats yy;

createtable yy2 (s string) partitioned by (year int) stored as parquet;
insert intoyy2 partition (year) values ('1999', 1999), ('2000', 2000),
('2001', 2001);
computestats yy2;

runtime filters: RF000 -> year

查询文件概要（在 impala-shel命令显示概要）包含解释计划和查询的内部运作，更详细的信息。该配置文件输出包括一个标记的“过滤器路由表”，关于每个过滤器的信息的基础上它的身份。
1.1.8 从运行时过滤中获益的查询示例
在这个例子中，Impala通常会做额外的工作来解释列C1，C2，C3，和我在huge_t1每一行，在检查ID值在内存中的哈希表构造的所有tiny_t2.id值。通过产生一个过滤器包含所有tiny_t2.id值甚至在查询开始扫描huge_t1表，Impala可以跳过不必要的工作来解析列信息尽快确定一个ID值不匹配任何值从其他表。
实例表明，计算统计报表的表（尽管这是一次操作后将数据加载到表）因为Impala依靠最新的统计数据来确定哪一个更具有独特的ID值比其他。这些信息让Impala做出有效的决定哪些表使用构建在内存中的哈希表，并从磁盘中读取并比较对哈希表中的表项。
setruntime_filter_mode=global;
COMPUTESTATS huge_t1;
COMPUTESTATS tiny_t2;
SELECT c1,c2, c3 FROM huge_t1 JOIN tiny_t2 WHERE huge_t1.id = tiny_t2.id;
在这个例子中，T1是一个表分区的年。在T2的子查询产生的多个值，并将这些值作为过滤器，阅读从T1计划片段。任何不匹配的分区在T1被跳过。
setruntime_filter_mode=global;
select c1from t1 where year in (select distinct year from t2);
现在，其中包含一个不适用于分区键列的附加测试。在不是一个分区键的列上的一个过滤器被称为每行筛选器。因为每行筛选器仅适用于Parquet，Parquet表T1必须。
在两个过滤器被传送到扫描节点读取T1的子查询结果。一年的过滤器有助于查询消除基于非匹配年的整个分区。在C2的过滤让Impala丢弃不匹配的C2值后立即阅读他们的行。没有运行时过滤，Impala必须保持非匹配值在内存中，C1 C2和C3，组装，成排的中间结果集，并发送所有的中间排到协调器节点，在那里他们将只在查询末尾淘汰。
setruntime_filter_mode=global;
select c1,c2, c3 from t1
where year in (select distinct year from t2)
and c2 in (select other_column from t3);
这个例子涉及一个广播连接。事实上，在条款会返回一小部分匹配的行（因为没有在tiny_t2很多行）意味着相应的滤波器是非常有选择性的。因此，运行时过滤可能是有效的优化这个查询。
setruntime_filter_mode=global;
select c1from huge_t1 join [broadcast] tiny_t2
on huge_t1.id = tiny_t2.id
where huge_t1.year in (select distinct yearfrom tiny_t2)
and c2 in (select other_column from t3);
这个例子涉及shuffle 或 partitioned连接。假设在huge_t1最行有huge_t2相应的行。事实上，在子句可以返回一个大量的匹配行意味着相应的过滤器将不会是非常有选择性的。因此，运行时过滤可能会在优化此查询时效果较差。
setruntime_filter_mode=global;
select c1from huge_t1 join [shuffle] huge_t2
on huge_t1.id = huge_t2.id
where huge_t1.year in (select distinct yearfrom huge_t2)
and c2 in (select other_column from t3);

1.1.9 调整和排除使用运行时过滤的查询
这些调整和故障排除程序适用于资源密集型的查询，运行足够长的时间，以及足够频繁的，你可以特别注意优化它们。
使用解释语句并检查运行时筛选器：确定运行时筛选器是否被应用到您所期望的谓词和连接子句中。例如，运行时过滤不适用于查询使用嵌套循环连接由于非等值连接运营商的机制。
确保所有表中涉及的所有表都是最新的。在将数据加载到非分区表后使用计算统计报表，并在将新分区添加到分区表后计算增量属性。
如果加入涉及大表查询使用独特的柱作为连接键，例如加入一个主键列和外键列，生产和发射滤波器的开销可能会超过履行利益因为没有太多的数据可以被修剪在查询的早期阶段。对于这样的疑问，考虑设置查询选项runtime_filter_mode =OFF。
1.1.10 运行时过滤的限制和限制
运行时过滤功能是最有效的Parquet 文件格式。对于其他文件格式，只适用于分区表。请参见运行时过滤的文件格式考虑。
当溢出到磁盘机制被激活时，在一个特定的主机在查询过程中，主机不产生任何过滤器，而处理该查询。此限制不影响结果的正确性，它只减少了可以应用于查询的优化量。

1.8 impala优化之HDFS缓存最佳实践
1) HDFS缓存的Impala的概述
2) 设置缓存为HDFS的Impala
3) 使用HDFS的Impala表和分区缓存
4) 加载和HDFS启用缓存删除数据
5) HDFS的缓存管理和Impala
6) HDFS的缓存与Impala性能考虑
背景资料：如何建立和管理一个CDH HDFS集群缓存，看CDH文档。
1.1.1 HDFS缓存的impala的概述
CDH 5.1高，Impala可以使用缓存功能更有效的利用内存的HDFS，这样反复查询可以利用数据“钉”在记忆中无论多少数据进行整体。HDFS的缓存功能允许您指定的一个子集的频繁访问的数据被永久的记忆，其余的在多个查询缓存不被驱逐。该技术适用于表或分区是经常访问的，小到可以完全在HDFS存储缓存。例如，您可以指定要在缓存中固定的几个维度表，以加快引用它们的许多不同的联接查询。或在一个分区表，你可能销分区保存数据，从最近一段时间因为数据将查询集中；然后下一组数据时，你可以脱离以前的分区和分区的新数据持销。
因为这辆车的性能特征依赖于HDFS的基础设施，它只适用于Impala表使用HDFS的数据文件。HDFS缓存Impala不适用于Hbase表，S3表、Kudu表，或 Isilon 表。
1.1.2 设置缓存为HDFS的Impala
使用HDFS的缓存与Impala，首先建立你的CDH聚类特征：
决定把每个主机上的HDFS的缓存内存的多少。请记住，可用的缓存数据的总内存是所有主机上的缓存大小的总和。默认情况下，任何数据块只缓存在一个主机上，虽然您可以通过增加复制因子来缓存一个跨多个主机的块。
问题cacheadmin HDFS命令来设置一个或多个缓冲池，由同一用户为impalad守护进程（通常是Impala）。例如:
hdfs cacheadmin -addPool four_gig_pool -owner impala -limit 4000000000
关于HDFS cacheadmin命令的详细信息，参见CDH文档。
一旦HDFS启用高速缓存和一个或多个池，看到使HDFS的Impala表和分区缓存如何选择Impala的数据加载到HDFS的缓存。在Impala的一面，你指定的缓冲池的名字在Impala的DDL语句使HDFS为表或分区缓存HDFScacheadmin命令定义，如创建表…在池或更改表中缓存…集合缓存池。

1.1.3 使用HDFS的Impala表和分区缓存
首先通过选择要缓存的表或分区。例如，这些可能是由许多不同的连接查询访问的查找表，或对应于由不同的报告或临时查询分析的最新的时间段的分区。
在你的SQL语句，您指定的逻辑分区如表和分区缓存。Impala将这些请求到HDFS级指令适用于特定的目录和文件。例如，给定一个分区键列的分区表普查，您可以选择缓存所有或部分数据如下：
在Impala 2.2 /CDH5.4高，可选复制条款创建表和修改表允许您指定一个复制因子，缓存相同的数据块上的主机的数量。当Impala过程缓存的数据块，其中缓存复制因子大于1，Impala随机选择一个主机，一个数据块的缓存副本。这种优化避免过多的在同一个主机上的多个处理器的使用，当相同的缓存数据块被处理的倍数。Cloudera建议指定一个值大于或等于HDFS块复制因子。
-- Cachethe entire table (all partitions).
alter tablecensus set cached in 'pool_name';

-- Removethe entire table from the cache.
alter tablecensus set uncached;

-- Cache aportion of the table (a single partition).
-- If thetable is partitioned by multiple columns (such as year, month, day),
-- theALTER TABLE command must specify values for all those columns.
alter tablecensus partition (year=1960) set cached in 'pool_name';

-- Cache the data from one partition on up to 4 hosts, tominimize CPU load on any
-- single host when the same data block is processedmultiple times.
alter table census partition (year=1970)
set cached in 'pool_name'with replication = 4;

-- At eachstage, check the volume of cached data.
-- Forlarge tables or partitions, the background loading might take some time,
-- so youmight have to wait and reissue the statement until all the data
-- hasfinished being loaded into the cache.
show tablestats census;
+-------+-------+--------+------+--------------+--------+
| year | #Rows | #Files | Size | Bytes Cached |Format |
+-------+-------+--------+------+--------------+--------+
| 1900 | -1 | 1 | 11B | NOT CACHED | TEXT |
| 1940 | -1 | 1 | 11B | NOT CACHED | TEXT |
| 1960 | -1 | 1 | 11B | 11B | TEXT |
| 1970 | -1 | 1 | 11B | NOT CACHED | TEXT |
| Total |-1 | 4 | 44B | 11B | |
+-------+-------+--------+------+--------------+--------+
创建表的考虑：
HDFS缓存功能影响Impala创建表的语句如下：
你可以把一个缓存的pool_name”条款和可选的复制= number_of_hosts条款在CREATE TABLE语句自动缓存表的全部内容，包括任何分区的后面添加。是的pool_name池以前设置了HDFS cacheadmin命令。
一旦一个表指定缓存通过HDFS创建表的语句，如果新分区添加后通过修改表…添加分区语句，将这些新分区中的数据自动缓存在同一个池中。
如果你想在从一个大的表格数据的子集进行重复查询，而不是对HDFS缓存指定整个表或特定的分区实用，你可以创建一个新的缓存表是数据的一个子集，利用创建表…缓存在pool_name”选择…哪里....当您完成从这个子集的数据生成报告，删除表和数据文件和缓存在内存中的数据被自动删除。
其他内存考虑：
某些DDL操作，如修改表…设置位置，而底层的HDFS的目录包含缓存文件受阻。你必须uncache文件第一，改变位置之前，删除表，等等。
当请求被固定在内存中时，该进程发生在后台，而不阻塞访问数据，而缓存正在进行中。从磁盘加载数据可能需要一段时间。ImpalaHDFS数据块从内存中读取每一个如果已经把已经，或从磁盘如果没有寄托呢。当文件被添加到一个表或分区的内容进行缓存，impala自动检测这些变化和执行自动刷新一次相关数据缓存。
你可以销每个节点通过缓存机制是受配额是由底层的HDFS服务执行HDFS的数据量。在请求一个内存中的impala表或分区销，检查它的大小不超过此限额。
注：由于HDFS缓存由组合的记忆从集群中所有的数据节点，缓存表或分区可以大于HDFS缓存在任何单一主机的数量。
1.1.4 加载和HDFS启用缓存删除数据
当HDFS缓存启用，额外的处理发生在的背景，当你添加或删除数据通过报表，如插入和删除表。
插入或加载数据：
Impala执行表或分区缓存插入或加载数据表时，新的数据文件自动缓存和Impala自动承认事实。
如果你执行插入或加载数据通过Hive，一如既往，Impala只承认新的数据文件后刷新在Impala table_name声明。
如果缓存池完全是满的，或已满之前，所有请求的数据可以缓存，Impala的DDL语句将返回一个错误。这是为了避免情况下，只有一些所请求的数据可以被缓存。
当HDFS缓存是一个表或分区启用，新的数据文件缓存时自动添加到HDFS相应的目录，无需刷新语句在Impala的需要。Impala自动执行刷新一次新的数据加载到HDFS的缓存。
丢弃表、分区或缓存池：
HDFS缓存功能的Impala表相互作用并改变表…删除分区语句如下：
当你发出了一个表，完全缓存表，或有一些分区缓存，删除表成功，所有的缓存指令提交表Impala从HDFS系统缓存删除。
同样适用于修改表…删除分区。操作成功，并删除任何缓存指令。
和总是一样，如果删除表是一个内部表，或者删除的分区在其内部表的默认位置，则删除基本的数据文件。如果删除表是一个外部表，或如果丢弃的分区在非默认位置，则单独留下数据文件。
如果你指定的数据文件缓存通过HDFS cacheadmin命令和数据文件在以前的项目描述留守，保持缓存数据文件。Impala只删除提交的Impala通过创建表的缓存指令或ALTER TABLE语句。可以有多个冗余的高速缓存指令属于同一个文件；指令都有独特的身份标识和所有者，使系统可以告诉他们分开。
如果你把一个HDFS的缓存池通过HDFScacheadmin命令，所有的Impala的数据文件保存，只是不再缓存。随后刷新后，显示表的统计报告0字节缓存每个相关的Impala表或分区。
将一个表或分区：
HDFS缓存功能与Impala的交互修改表…设置位置语句如下：
如果您指定了一个表或分区，通过创建表或更改表语句缓存，随后试图通过一个更改表重新定位表或分区…设置位置语句将失败。您必须发出一个更改表…设置被声明为表或分区第一。否则，会失去一些Impala缓存数据文件，没有办法uncache以后。
1.1.5 HDFS的缓存管理和Impala
HDFS的缓存管理和Impala
这是指导方针和步骤来检查或更改HDFS数据缓存状态的Impala：
HDFScacheadmin命令：
如果你把一个缓冲池与HDFS cacheadmin命令，对相关的数据文件的Impala查询仍然会工作，通过落回从磁盘中读取文件。执行刷新后放在桌上，Impala报道字节缓存0所有相关表和分区数。
你可以使用HDFS cacheadmin得到一个现有的缓存池，该池或详细信息，如下：
hdfs cacheadmin -listDirectives #Basic info
Found 122entries
ID POOL REPL EXPIRY PATH
123 testPool 1 never /user/hive/warehouse/tpcds.store_sales
124 testPool 1 never /user/hive/warehouse/tpcds.store_sales/ss_date=1998-01-15
125 testPool 1 never /user/hive/warehouse/tpcds.store_sales/ss_date=1998-02-01
...

hdfscacheadmin -listDirectives -stats # Moredetails
Found 122entries
ID POOL REPL EXPIRY PATH BYTES_NEEDED BYTES_CACHED FILES_NEEDED FILES_CACHED
123 testPool 1 never /user/hive/warehouse/tpcds.store_sales 0 0 0 0
124 testPool 1 never /user/hive/warehouse/tpcds.store_sales/ss_date=1998-01-15 143169 143169 1 1
125 testPool 1 never /user/hive/warehouse/tpcds.store_sales/ss_date=1998-02-01 112447 112447 1 1
...
ImpalaSHOW 语句：
每个表或分区，显示表数据或显示分区表显示当前缓存的字节缓存功能的HDFS的数量。如果没有为该表或分区放置的缓存指令，则不会缓存结果集显示的结果集。一个值为0，或一个较小的数字比表或分区的整体大小，表明缓存请求已提交，但数据还没有完全加载到内存中。查看显示详细信息。
Cloudera管理：
您可以启用或禁用缓存通过HDFS Cloudera管理，使用配置设置最大内存用于HDFS的缓存服务。这种控制集dfs_datanode_max_locked_memoryHDFS配置参数，它指定缓存大小对HDFS的每个节点的上限。
所有的缓存设置HDFS的其他操作，如文件的缓存，通过命令行完成，无论是Impala的DDL语句或Linux HDFS cacheadmin命令。
Impala的内存限制：
Impala HDFS缓存功能与Impala的内存限制为相互作用如下：
每个HDFS的缓存池的最大大小是指定外部的Impala，通过HDFScacheadmin命令。
所有的内存用于缓存从HDFS impalad守护进程地址空间的分离与不计入的mem_limit启动选项的限制，mem_limit查询选项，或进一步限制通过纱线资源管理或Linux cgroups机制。
因为访问HDFS的缓存数据避免了内存到内存复制操作，包括缓存数据的查询需要在Impala边记忆比缓存数据的等效查询不。除了在一个单一的用户环境中的任何性能优势，减少内存有助于提高高并发工作负载下的可扩展性。
1.1.6 HDFS的缓存与Impala性能考虑
在 Impala 1.4.0及更高的版本， Impala 支持高效的读取，被固定在内存中缓存数据通过HDFS。 Impala 利用HDFS API和从存储器读取数据而不是从磁盘的数据文件是否在使用Impala DDL语句，或使用命令行机制您指定HDFS路径。
当你检查impala-shell 汇总命令的输出，或期待中的impalad守护进程的报告，你看到多少字节从HDFS缓存读取。例如，这是从查询资料说明，所有的数据读取一个特定的查询阶段来自HDFS的缓存，因为bytesread和bytesreaddatanodecache值是相同的。
HDFS_SCAN_NODE(id=0):(Total: 11s114ms, non-child: 11s114ms, % non-child: 100.00%)

AverageHdfsReadThreadConcurrency:0.00
AverageScannerThreadConcurrency:32.75
BytesRead: 10.47 GB (11240756479)
BytesReadDataNodeCache: 10.47 GB (11240756479)
BytesReadLocal: 10.47 GB(11240756479)
BytesReadShortCircuit: 10.47 GB(11240756479)
DecompressionTime: 27s572ms
对于涉及较小的数据查询，或在单用户的工作负载，您可能没有注意到一个与或查询的响应时间差异没有HDFS缓存。即使HDFS缓存关闭，对于查询的数据可能仍然在Linux操作系统的缓存。的好处变得更清晰的数据量的增加，特别是随着系统处理更多的并发查询。HDFS的缓存可以提高整体系统的可扩展性。那就是，它可以防止查询性能下降时的工作量超过了Linux操作系统的缓存容量。
由于HDFS的局限，零拷贝读取不支持加密。不建议使用HDFS Cloudera在加密区Impala数据文件缓存。查询在查询执行过程中返回到正常的读取路径，这可能会导致一些性能开销。
选择的考虑：
ImpalaHDFS缓存功能与SELECT语句和查询性能如下：
Impala自动从内存读取任何数据，已被指定为缓存和实际加载到HDFS的缓存。（它可能需要一段时间后，初始请求完全填充缓存的表与大尺寸或多个分区）的加速比来自两个方面：从内存读取，而不是磁盘，并访问数据直接从高速缓存区，而不是从一个内存区复制到另一个。这第二个方面产生进一步的性能改进的标准的操作系统缓存机制，这仍然会导致内存复制缓存数据的内存。
对于少量的数据，查询加速可能不明显，在墙上的时钟时间。的性能可能与HDFS的缓存打开或关闭大致相同，由于最近使用的数据是在Linux操作系统的缓存举行。差异更为明显：
数据卷（对于同时运行的所有查询）超过了超高速缓存的大小。
一个繁忙的集群运行许多并发查询，其中在内存中的复制和整体内存使用的内存减少在查询结果中更大的可扩展性和吞吐量。
因此，要真正在开发环境中练习和基准此功能，您可能需要模拟现实的工作负载和与您的生产环境相匹配的并发查询。
在轻负载模拟系统的工作量的方法之一是冲洗操作系统缓冲区高速缓存（每个DataNode）对相同的表或分区之间的迭代查询：
$ sync
$ echo 1> /proc/sys/vm/drop_caches
Impala的查询利用HDFS的缓存数据无论是否缓存指令是由Impala或外部通过HDFS cacheadmin发出的命令，例如外部表的缓存数据文件可能是由几个不同的Hadoop组件访问。
如果您的查询返回一个大的结果集，则报告查询的时间可能会被打印在屏幕上的结果所需的时间所占。为了衡量标的查询时间，查询的结果集的count()大，不一样的处理只能打印一条直线到屏幕。

impala 分区表

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

impala的优化--分区表优化-8个方法让分区最优化

Operator #Hosts Avg Time Max Time #Rows Est. #Rows Peak Mem Est. Peak Mem Detail

Plan:

tuple ids: 1

添加新评论0 条评论

作者其他文章

相关文章

相关问题