确保 Impala 查询实现
Posted
技术标签:
【中文标题】确保 Impala 查询实现【英文标题】:Ensure that Impala query gets materialized 【发布时间】: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”过程语言包装器,可能适合您的需求。注意事项:
需要 Hive 2.0+ 需要在 HPL-SQL 解释器中运行整个脚本,而不是基本 Hive 客户端(也不是标准 JDBC 连接)并且那个 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
,以便读者可以针对他/她的用例使用所需的度量。以上是关于确保 Impala 查询实现的主要内容,如果未能解决你的问题,请参考以下文章