gpt4 book ai didi

hadoop - 子查询中的 Hive 'limit' 在完整查询后执行

转载 作者:可可西里 更新时间:2023-11-01 14:25:57 29 4
gpt4 key购买 nike

我正在配置单元查询中测试一个相当费力的 rlike 函数。我想我会先针对一个子集进行测试,然后再将其应用于我的 TB+ 数据。 完整查询是:

create table proxy_parsed_clean as
select
a.*,
case
when domainname rlike '.*:443$' then 1
else 0
end as used_https
from proxy_parsed a;

因为有这么多数据,我写了一个查询(表面上)会针对一个子集进行操作:

select
case
when a.domainname rlike '.*:443$' then 1
else 0
end as used_https
from (select domainname from proxy_parsed limit 10) a;

但是,这似乎只需要 与第一个查询一样长的时间。与其将外部查询应用于子集,不如将 case 语句应用于整个数据集,然后然后限制。运行 explain 证实了我的怀疑(注意 limit 子句被移到了查询的末尾):

> explain select case when a.domainname rlike '.*:443$' then 1 else 0 end from (select domainname from proxy_parsed limit 10) a;

+---------------------------------------------------------------------------------------------------------------------+--+
| Explain |
+---------------------------------------------------------------------------------------------------------------------+--+
| STAGE DEPENDENCIES: |
| Stage-1 is a root stage |
| Stage-0 depends on stages: Stage-1 |
| |
| STAGE PLANS: |
| Stage: Stage-1 |
| Map Reduce |
| Map Operator Tree: |
| TableScan |
| alias: proxy_parsed |
| Statistics: Num rows: 157462377267 Data size: 6298495090688 Basic stats: COMPLETE Column stats: NONE |
| Select Operator |
| expressions: domainname (type: varchar(40)) |
| outputColumnNames: _col0 |
| Statistics: Num rows: 157462377267 Data size: 6298495090688 Basic stats: COMPLETE Column stats: NONE |
| Limit |
| Number of rows: 10 |
| Statistics: Num rows: 10 Data size: 400 Basic stats: COMPLETE Column stats: NONE |
| Reduce Output Operator |
| sort order: |
| Statistics: Num rows: 10 Data size: 400 Basic stats: COMPLETE Column stats: NONE |
| TopN Hash Memory Usage: 0.1 |
| value expressions: _col0 (type: varchar(40)) |
| Reduce Operator Tree: |
| Select Operator |
| expressions: VALUE._col0 (type: varchar(40)) |
| outputColumnNames: _col0 |
| Statistics: Num rows: 10 Data size: 400 Basic stats: COMPLETE Column stats: NONE |
| Limit |
| Number of rows: 10 |
| Statistics: Num rows: 10 Data size: 400 Basic stats: COMPLETE Column stats: NONE |
| Select Operator |
| expressions: CASE WHEN ((_col0 rlike '.*:443$')) THEN (1) ELSE (0) END (type: int) |
| outputColumnNames: _col0 |
| Statistics: Num rows: 10 Data size: 400 Basic stats: COMPLETE Column stats: NONE |
| File Output Operator |
| compressed: false |
| Statistics: Num rows: 10 Data size: 400 Basic stats: COMPLETE Column stats: NONE |
| table: |
| input format: org.apache.hadoop.mapred.TextInputFormat |
| output format: org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat |
| serde: org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe |
| |
| Stage: Stage-0 |
| Fetch Operator |
| limit: -1 |
| Processor Tree: |
| ListSink |
| |
+---------------------------------------------------------------------------------------------------------------------+--+

如果我只是运行 select * from proxy_parsed limit 10;,查询的执行速度非常快。有人可以解释A),为什么查询没有在子集上执行,以及B)如何让它这样做?

我可以只创建一个临时表,在其中选择 10 条记录,然后执行查询,但这看起来很草率。另外,在那之后我会有一个临时表来清理。这种行为看起来像是一个 Hive 错误,即 limit 行为在这种情况下显然没有表现得像它应该的那样。

最佳答案

limit 不是在 case 之后应用,而是在处理 case 之前和期间应用 - 它实际上应用了两次。虽然是巧合,但在本例中,limit 的两次应用分别对应于内部查询和外部查询。

在查询计划中,您可以看到 Map 阶段仅选择单个列(“expressions: domainname”)并将结果数减少到 10(从 157462377267)。这对应于内部查询。然后 Reduce 阶段应用大小写 ("expressions: CASE WHEN ((_col0 rlike '.*:443$')) THEN (1) ELSE (0) END") 并减少行到 10,但是你可以看到在这个阶段预期的输入行数已经是 10。 Reduce 阶段对应于外部查询。

两次应用限制的原因是分布式执行。由于在 Map 阶段结束时您希望最小化发送到 Reducer 的数据量,因此在此处应用限制是有意义的。达到限制后,Mapper 将不再处理任何输入。然而,这还不够,因为每个 Mapper 可能会产生多达 10 个结果,加起来是 Mapper 数量的十倍,因此 Reduce 阶段必须再次应用限制。由于这种机制,通常您应该直接应用限制,而不是为此唯一目的创建子查询。

总而言之,在我的解释中查询计划看起来不错——limit 在它应该处理的地方被处理。这回答了关于为什么在 case 之前应用 limit 的问题。遗憾的是,它并没有解释为什么要花这么多时间。

更新:请参阅 ozw1z5rd's answer关于为什么尽管使用了 limit 这个查询还是很慢。它解释了使用子查询会导致启动 MapReduce 作业,而直接查询则避免了这种情况。

关于hadoop - 子查询中的 Hive 'limit' 在完整查询后执行,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/39372330/

29 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com