admin管理员组文章数量:1660217
在上一篇文章中(带你走进Impala query profile第一篇_Allenzyg的博客-CSDN博客),我们介绍了Impala query profie的概要部分,在本篇文章我们介绍Profile的查询计划(Query Plan)和执行概要(Execution Summary)部分。
Profile的查询计划和执行概要如下所示:
Query Runtime Profile: Query (id=2945a77ff619defe:b658730000000000): Summary: Session ID: 24abae22c723db5:2c0a25a81814e8a8 Session Type: BEESWAX Start Time: 2020-07-03 11:58:47.317039000 End Time: 2020-07-03 12:12:56.216137000 Query Type: QUERY Query State: FINISHED Query Status: OK Impala Version: impalad version 2.10.0-cdh5.13.3 RELEASE (build 15a453e15865344e75ce0fc6c4c760696d50f626) User: root Connected User: root Delegated User: Network Address: 10.138.232.87:36237 Default Db: default Sql Statement: select count(*) from bms_ldgdb.ldg_690marketization_ledger t where check_flag in (4,-1) and ledger_status = 2 and is_delete = 0 and module in (1,2) and account_date >= '2020-06-01' and industry_code != '' Coordinator: rrs-hdp-dn04:22000 Query Options (set by configuration): Query Options (set by configuration and planner): MT_DOP=0 Plan: ---------------- Max Per-Host Resource Reservation: Memory=0B Per-Host Resource Estimates: Memory=20.00MB WARNING: The following tables are missing relevant table and/or column statistics. bms_ldgdb.ldg_690marketization_ledger F01:PLAN FRAGMENT [UNPARTITIONED] hosts=1 instances=1 | Per-Host Resources: mem-estimate=10.00MB mem-reservation=0B PLAN-ROOT SINK | mem-estimate=0B mem-reservation=0B | 03:AGGREGATE [FINALIZE] | output: count:merge(*) | mem-estimate=10.00MB mem-reservation=0B spill-buffer=2.00MB | tuple-ids=1 row-size=8B cardinality=1 | 02:EXCHANGE [UNPARTITIONED] | mem-estimate=0B mem-reservation=0B | tuple-ids=1 row-size=8B cardinality=1 | F00:PLAN FRAGMENT [RANDOM] hosts=16 instances=16 Per-Host Resources: mem-estimate=10.00MB mem-reservation=0B 01:AGGREGATE | output: count(*) | mem-estimate=10.00MB mem-reservation=0B spill-buffer=2.00MB | tuple-ids=1 row-size=8B cardinality=1 | 00:SCAN KUDU [bms_ldgdb.ldg_690marketization_ledger t] predicates: industry_code != '' kudu predicates: is_delete = 0, ledger_status = 2, check_flag IN (4, -1), module IN (1, 2), account_date >= '2020-06-01' mem-estimate=0B mem-reservation=0B tuple-ids=0 row-size=15B cardinality=unavailable ---------------- Estimated Per-Host Mem: 20971520 Tables Missing Stats: bms_ldgdb.ldg_690marketization_ledger Per Host Min Reservation: rrs-hdp-dn03:22000(0) rrs-hdp-dn04:22000(0) rrs-hdp-dn05:22000(0) rrs-hdp-dn08:22000(0) rrs-hdp-dn11:22000(0) rrs-hdp-dn13:22000(0) Request Pool: root.default Admission result: Admitted immediately ExecSummary: Operator #Hosts Avg Time Max Time #Rows Est. #Rows Peak Mem Est. Peak Mem Detail ---------------------------------------------------------------------------------------------------------------------------------- 03:AGGREGATE 1 316.053us 316.053us 1 1 40.00 KB 10.00 MB FINALIZE 02:EXCHANGE 1 14m8s 14m8s 6 1 0 0 UNPARTITIONED 01:AGGREGATE 6 2.746ms 5.205ms 6 1 67.00 KB 10.00 MB 00:SCAN KUDU 6 2m33s 14m8s 6.10M -1 299.00 KB 0 bms_ldgdb.ldg_690marketization_ledger t |
接下来我们来逐一提取和介绍上面Profile片段中的信息:
1、表/列统计信息:
Max Per-Host Resource Reservation: Memory=0B
Per-Host Resource Estimates: Memory=20.00MB
WARNING: The following tables are missing relevant table and/or column statistics.
bms_ldgdb.ldg_690marketization_ledger
前两行仅说明资源信息,它们不是很重要,也不经常使用。
但是,下一行非常重要,因为Impala告诉我们是否检测到查询所涉及的表具有最新的统计信息,这一点非常关键,因为Impala使用表/列统计信息(table/column statistics information)来进行资源预估(resource estimation),并执行查询计划来确定运行查询的最佳策略,如果统计信息不是最新的,Impala最终将使用错误的查询计划,从而影响整体查询性能。
在上面的示例中,我们可以看到bms_ldgdb.ldg_690marketization_ledger表缺少统计信息,Impala在查询计划中给出了警告来提示用户需要在该表上执行COMPUTE STATS来消除这个警告信息。关于表统计的更多信息,请参阅Table and Column Statistics(Table and Column Statistics | 6.3.x | Cloudera Documentation)。
2、查询计划详情:
F01:PLAN FRAGMENT [UNPARTITIONED] hosts=1 instances=1 | Per-Host Resources: mem-estimate=10.00MB mem-reservation=0B PLAN-ROOT SINK | mem-estimate=0B mem-reservation=0B | 03:AGGREGATE [FINALIZE] | output: count:merge(*) | mem-estimate=10.00MB mem-reservation=0B spill-buffer=2.00MB | tuple-ids=1 row-size=8B cardinality=1 | 02:EXCHANGE [UNPARTITIONED] | mem-estimate=0B mem-reservation=0B | tuple-ids=1 row-size=8B cardinality=1 | F00:PLAN FRAGMENT [RANDOM] hosts=16 instances=16 Per-Host Resources: mem-estimate=10.00MB mem-reservation=0B 01:AGGREGATE | output: count(*) | mem-estimate=10.00MB mem-reservation=0B spill-buffer=2.00MB | tuple-ids=1 row-size=8B cardinality=1 | 00:SCAN KUDU [bms_ldgdb.ldg_690marketization_ledger t] predicates: industry_code != '' kudu predicates: is_delete = 0, ledger_status = 2, check_flag IN (4, -1), module IN (1, 2), account_date >= '2020-06-01' mem-estimate=0B mem-reservation=0B tuple-ids=0 row-size=15B cardinality=unavailable ---------------- |
查询计划(Query plan)是Impala profile中最重要的部分之一,我们需要知道如何读取它,因为它告诉我们如何扫描(scan)表、交换数据(data exchange)和连接(join)以获得最终结果。
如果查询很复杂,查询计划也可能会变得非常复杂,让我们从这个简单的查询开始,以了解它的基本信息。需要记住的一件事是,我们需要反向阅读这些信息,来理解Impala的执行计划。
注意:执行计划是从下往下读的。
2.1、KUDU 扫描:
第一步从KUDU扫描(KUDU Scan)开始:
00:SCAN KUDU [bms_ldgdb.ldg_690marketization_ledger t] predicates: industry_code != '' kudu predicates: is_delete = 0, ledger_status = 2, check_flag IN (4, -1), module IN (1, 2), account_date >= '2020-06-01' mem-estimate=0B mem-reservation=0B tuple-ids=0 row-size=15B cardinality=unavailable |
从上面的片段中我们可以获取下面这些有用的信息:
运行查询所需的内存估计值为0,没有内存被预留
补充:如果是HDFS扫描
2.2、Aggregation操作:
HDFS扫描完成后,Impala需要做聚合(Aggregation),因为我们的SQL语句中使用了COUNT(*):
01:AGGREGATE
| output: count(*)
| mem-estimate=10.00MB mem-reservation=0B spill-buffer=2.00MB
| tuple-ids=1 row-size=8B cardinality=1
|
这里没有太多要解释的,这个步骤执行的是聚合操作。
2.3、Fragment信息:
F00:PLAN FRAGMENT [RANDOM] hosts=16 instances=16
Per-Host Resources: mem-estimate=10.00MB mem-reservation=0B
00:SCAN KUDU和01:AGGREGATE片段上的SCAN和Aggregation操作都属于片段(FRAGMENT)F00,它在16个主机和16个实例上运行。F00这个片段ID可以用来在Profile的后面部分找到实际的片段统计信息,它可以告诉我们这个片段在运行时如何运行的详细信息。我们还将在本系列的后面部分讨论这个问题。
2.4、Exchange操作:
02:EXCHANGE [UNPARTITIONED]
| mem-estimate=0B mem-reservation=0B
| tuple-ids=1 row-size=8B cardinality=1
|
在每个工作节点(worker node)上完成聚合之后,需要将每个工作节点的结果交换给协调器节点(coordinator),这个步骤主要做的是这个操作,之后,协调器节点需要对这些结果进行最后的汇总/合并(aggregation/merger):
03:AGGREGATE [FINALIZE]
| output: count:merge(*)
| mem-estimate=10.00MB mem-reservation=0B spill-buffer=2.00MB
| tuple-ids=1 row-size=8B cardinality=1
|
以上两个操作都属于同一个片段01,该片段又可以用来引用Profile数据的其余部分,以获取关于查询的更详细的统计信息:
F01:PLAN FRAGMENT [UNPARTITIONED] hosts=1 instances=1
现在,让我们来看看Profile的执行概要部分:
Operator #Hosts Avg Time Max Time #Rows Est. #Rows Peak Mem Est. Peak Mem Detail ---------------------------------------------------------------------------------------------------------------------------------- 03:AGGREGATE 1 316.053us 316.053us 1 1 40.00 KB 10.00 MB FINALIZE 02:EXCHANGE 1 14m8s 14m8s 6 1 0 0 UNPARTITIONED 01:AGGREGATE 6 2.746ms 5.205ms 6 1 67.00 KB 10.00 MB 00:SCAN KUDU 6 2m33s 14m8s 6.10M -1 299.00 KB 0 bms_ldgdb.ldg_690marketization_ledger t |
在这里你可以找到这些有用的信息:
1)每个操作花费的平均时间(Avg Time)和最大时间(Max Time):如果两者相差较大,我们就会知道每个worker节点运行作业时存在不平衡/倾斜(in-balance/skew)情况,从理论上讲,它们应该处理相同数量的数据,所有节点应该在相同的时间范围内完成任务
2)实际行数和估计行数:#Row表示运行查询后实际返回的行数,Est. #Rows表示Impala根据表统计数据计算出的估计行数。如果#Row和Est. #Rows相差较大,就表明Impala中的表统计信息已经过时。在案例中,SCAN KUDU操作的Est. #Rows值为-1,#Rows的值为6.10M,就我们的测试表而言,我们没有表统计信息,因此Impala报告了-1的估算值。如果估计值(estimated value)是正数,但仍与实际返回的行数不同,我们就需要对该表运行COMPUTE STATS以更新统计信息
3)参与查询操作的节点数量:#Hosts列告诉我们,有多少工作节点参与了查询中的相关操作。在我的例子中,由于数据很小,我们只有一个主机来运行查询
4)实际内存和估计内存:Peak Mem和Est. Peak Mem是不言自明的,它们表示实际使用的内存与Impala根据表统计数据计算出的估计内存
如果查询中有连接(join)操作,Profile的总结信息中还将向我们展示连接操作中使用了什么连接策略:广播连接(Broadcast Join)还是随机连接(Shuffle Join)。
版权声明:本文标题:带你走进Impala query profile第二篇 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://m.elefans.com/dianzi/1729850551a1215351.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论