在子选择中使用“SELECT *”的 Hive 星型模式查询答案

【问题标题】：Hive star schema query with 'SELECT *' in sub-selects在子选择中使用“SELECT *”的 Hive 星型模式查询
【发布时间】：2016-01-04 17:43:37
【问题描述】：

我在 Hive 中遇到了一个之前实现的查询，我想了解它，并且想知道是否有人可以解释所使用的查询模式的优点（或不足）。查询结构是星型模式，以这种方式子选择连接表：

SELECT
  a.key
  a.field1
  b.field2
  c.field3
  d.field4
FROM first a
JOIN ( SELECT * FROM second ) b ON a.key = b.key
JOIN ( SELECT * from third ) c ON a.key = c.key
JOIN ( SELECT * from fourth ) d ON a.kay = d.key
SORT BY a.key DESC;

让我感到困惑的是，为什么要子选择连接表（注意 SELECT * 没有 WHERE）而不是直接加入它们。在我更改遗留代码查询（出于其他原因）之前，我想了解这种方法的目标可能是什么。该查询是在 Hive 0.10 时编写的，但我们现在已经到 Hive 0.13。这可能是一项遗留问题吗？

【问题讨论】：

有趣的是，直接连接也会给出类似的结果。我真的很想知道该查询是如何以及为什么存在的。我正在考虑糟糕的 API 实现。从多个表加载数据可能是一个底层逻辑。因为这个（hive）绝对不是 SQL。可以说，API 或库可以生成与其中的查询类似的查询。另一种解释是美国和英国的英语有什么不同，他们可能想要与标准 SQL 不同的查询定义

标签： hive hiveql

【解决方案1】：

使用全选且没有 WHERE 子句的子查询没有任何优势。但如果适用于限制子查询中的列和行，这样它们的数据集将适合内存并且仅映射连接将起作用，它可能很有用。如果 hive.exec.parallel=true，则可以并行预先计算示例中的三个子查询。 SORT BY a.key DESC 在这个查询中似乎也没用。

【讨论】：

【解决方案2】：

我最好的猜测是它在测试阶段仍然存在。将 where 子句保留在自己的空间中。性能方面没有任何改进。

【讨论】：