确保 Impala 查询实现答案

【问题标题】：Ensure that Impala query gets materialized确保 Impala 查询实现
【发布时间】：2016-07-15 18:32:21
【问题描述】：

是否有任何可靠且有效的方法来确保 impala 查询结果完全实现而不将结果打印到控制台？例如，我将使用 INNER JOIN 查询。

实现查询结果的明显方法是将表创建为选择。

CREATE TABLE t3 STORED AS PARQUET AS SELECT t1.* FROM t1 INNER JOIN t2 ON t1.id=t2.id;

它的问题是它写入磁盘因此效率低下。我正在寻找最有效的方式来执行查询并确保实现结果。

例如，在 Spark 中，我可以使用 .cache 方法，然后使用 .count 来确保查询被具体化。

val t3 = t1.join(t2, "id")
t3.cache
t3.count

我可以尝试使用子查询的解决方法。

SELECT COUNT(*) FROM (SELECT t1.* FROM t1 INNER JOIN t2 ON t1.id=t2.id) t3;

但我仍然需要确保子查询被具体化，如果查询优化器发现我只对总数感兴趣，这并不明显。也许有一些提示可以强制执行该技巧或其他技巧？

【问题讨论】：

您希望查询具体化，但您不希望查询具体化（即数据持久化到磁盘）。我在那里看到了一种矛盾。或者您可能只是想对 Impala 守护进程进行压力测试，看看它们在什么时候放弃 OOM？
换句话说：Impala 是 SQL 执行引擎，不是数据处理框架（à la Spark），也不是分布式缓存（à la 雷迪斯）。执行查询后，什么都没有。除了一些日志。
@SamsonScharfrichter 感谢您的评论，在许多 sql 数据库中，您可以将查询结果临时保存到变量中并进一步重复使用。如果 impala 有这样的功能，它会解决我的问题。我想实现查询，但我不想有结果传输/打印开销，所以select count(*) 外部查询 - 比create table as select 好得多。我不认为有矛盾。只是在服务器端执行查询的精确时间。
“我想要的只是精确测量查询执行时间” -- 你为什么不一开始就说出来？跨度>
旁注 - 上面的示例查询是“令人尴尬的并行”，直到你得到最终的部分计数总和，所以它应该代表现实生活中的 Impala 吞吐量。尽管 HDFS 文件块位置与 Impala 守护进程位置、并发性等存在随机影响。

【解决方案1】：

AFAIK 你不能用 Impala 做到这一点，而且永远也做不到。
Cloudera 专门设计该工具来支持 BI 工具，例如 Tableau、Qlik、MicroStrategy 等，但不支持 ad hoc ETL 脚本。

另一方面，Hive 现在附带了一个“HPL-SQL”过程语言包装器，可能适合您的需求。注意事项：

并且那个 HPL-SQL 工具 声称它也支持 Impala 查询，但我从未调查过这种说法。作为一种笨拙的解决方法，可以解决您的问题。

参考：
HIVE-11055（为 Hive 代码库贡献的 PL/HQL 工具）
HPL/SQL website

说到变通方法，为什么不按照您自己的建议使用 Spark？您可以使用 Spark 原生 Parquet 库或自定义 JDBC 连接到 Impala 守护程序来读取 Impala/Hive 表。本质上，它类似于 HPL/SQL 解决方案。

【讨论】：

谢谢。很好回答。我会等待一段时间的赏金。我已经在基准测试中使用 Spark，希望更准确地反映 Impala。看起来最好的方法是测试两个不同的查询select count(*) 和create table as select，以便读者可以针对他/她的用例使用所需的度量。