Убедитесь, что запрос Impala стал материализованным.

Есть ли какой-либо надежный и эффективный способ гарантировать, что результаты запроса impala полностью материализуются без результатов печати на консоль? В качестве примера я буду использовать запрос INNER JOIN.Убедитесь, что запрос Impala стал материализованным.

Очевидным способом материализовать результаты запроса является create table as select.

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;

Но все-таки мне нужно обеспечить подзапрос материализуется, который не является очевидным, если оптимизатор запросов обнаруживает, что я заинтересован только в общем количестве. Может быть, есть какие-то намеки для обеспечения того или иного трюка?

источник

2016-07-15 jangorecki

Вы хотите, чтобы запрос был материализован, но вы не хотите, чтобы запрос был материализован (т. Е. Данные сохранялись на диске). Я вижу там какое-то противоречие. Или, может быть, вы просто хотите подчеркнуть - протестировать демонов Impala, просто чтобы посмотреть, в какой момент они сдаются с OOM? –

Иными словами: Impala - это механизм выполнения SQL, а не структура обработки данных (* à la * Spark), а не распределенный кеш (* à la * Redis). Когда запрос был выполнен, ничего не остается. За исключением нескольких журналов. –

@SamsonScharfrichter спасибо за комментарий, во многих sql db вы можете сохранять результаты запроса в переменную на разовой основе и повторно использовать ее дальше. Если бы у импалы была такая особенность, это решило бы мое дело. Я хочу материализовать запрос, но я не хочу иметь накладные расходы на передачу/печать, поэтому 'select count (*)' внешний запрос - намного лучше, чем * create table as select *. Я не думаю, что есть противоречие. Просто точное время выполнения запроса на стороне сервера. – jangorecki

AFAIK вы не можете сделать это с помощью Impala, и он никогда не сможет.
Cloudera разработал этот инструмент специально для поддержки инструментов BI, таких как Tableau, Qlik, MicroStrategy и т. Д. - но не для поддержки ad hoc ETL-скрипты.

С другой стороны Улей теперь поставляется с процедурной оболочкой «HPL-SQL», которая может соответствовать вашим потребностям. Предостережения:

требует улей 2.0+
требует запуска весь скрипт внутри интерпретатор HPL-SQL, а не базовый улей клиента (ни стандартное соединение JDBC)

и что Инструмент HPL-SQL утверждает, что он также поддерживает запросы Impala, но я никогда не исследовал это требование. Мог решить вашу проблему, как своего рода неуклюжие обходные пути.

Ссылка:
HIVE-11055 (PL/HQL инструмент способствовал коде улей)
HPL/SQL website

Говоря о обходных, почему бы не использовать Спарк, как Вы предложили себя ? Вы можете прочитать таблицы Impala/Hive, либо с родными библиотеками Parquet Spark, либо с помощью специального JDBC-соединения с демоном Impala.По сути, он будет похож на решение HPL/SQL.

источник

2016-07-20 20:41:40

Спасибо. Хорошо ответил. в тесте, хотел бы более точно отразить Impala. Похоже, что лучший способ - проверить два разных запроса: «select count (*)» и «create table as select», чтобы читатель мог использовать желаемую меру для своего использования. – jangorecki

Убедитесь, что запрос Impala стал материализованным.

ответ

Смежные вопросы