Apache Hive не возвращает результаты YARN правильно - PullRequest
2 голосов
/ 06 ноября 2019

Я использую кластер с нуля на AWS EC2. У меня есть внешняя таблица (разделенная), определенная с данными на S3. Я могу запросить эту таблицу и получить результаты на консоль с помощью простого оператора select *:

hive> set hive.execution.engine=tez;
hive> select * from external_table where partition_1='1' and partition_2='2';
<correct results returned>

Выполнение запроса, требующего Tez, не возвращает результаты на консоль:

hive> set hive.execution.engine=tez;
hive> select count(*) from external_table where partition_1='1' and partition_2='2';
Status: Running (Executing on YARN cluster with App id application_1572972524483_0012)

OK
+------+
| _c0  |
+------+
+------+
No rows selected (8.902 seconds)

Однако, если я покопаюсь в журналах и в файловой системе, я смогу найти результаты этого запроса:

(yarn.resourcemanager.log) org.apache.hadoop.yarn.server.resourcemanager.RMAuditLogger: USER=root     OPERATION=AM Released Container TARGET=SchedulerApp     RESULT=SUCCESS  APPID=application_1572972524483_0022      CONTAINERID=container_1572972524483_0022_01_000002      RESOURCE=<memory:1024, vCores:1>        QUEUENAME=default
(container_folder/syslog_attempt) [TezChild] |exec.FileSinkOperator|: New Final Path: FS file:/tmp/<REALLY LONG FILE PATH>/000000_0
[root #] cat /tmp/<REALLY LONG FILE PATH>/000000_0
SEQ"org.apache.hadoop.io.BytesWritableorg.apache.hadoop.io.Textl▒ꩇ1som}▒▒j¹▒    2060

2060 - это правильный счет для раздела.

Теперь, как ни странно, я могу получить результаты из приложения, если я вставлю каталог перезаписи в HDFS:

hive> set hive.execution.engine=tez;
hive> INSERT OVERWRITE DIRECTORY '/tmp/local_out' select count(*) from external_table where partition_1='1' and partition_2='2';
[root #] hdfs dfs -cat /tmp/local_out/000000_0
2060

Однако попытка вставить локальный каталог перезаписи не удалась:

hive> set hive.execution.engine=tez;
hive> INSERT OVERWRITE LOCAL DIRECTORY '/tmp/local_out' select count(*) from external_table where partition_1='1' and partition_2='2';
[root #] cat /tmp/local_out/000000_0
cat: /tmp/local_out/000000_0: No such file or directory

Если я присваиваю файл результатов контейнера для этого запроса, то это всего лишь число, имя класса или специальные символы не отображаются:

[root #] cat /tmp/<REALLY LONG FILE PATH>/000000_0
2060

Единственное сообщение журнала о месте, которое я могу найти, приходит изЖурнал YARN ResourceManager:

(yarn.resourcemanager.log) INFO org.apache.hadoop.yarn.server.resourcemanager.RMAuditLogger: USER=root     OPERATION=AM Released Container TARGET=SchedulerApp     RESULT=SUCCESS  APPID=application_1572972524483_0023      CONTAINERID=container_1572972524483_0023_01_000004      RESOURCE=<memory:1024, vCores:1>        QUEUENAME=default
(yarn.resourcemanager.log) WARN org.apache.hadoop.yarn.server.resourcemanager.RMAuditLogger: USER=root     IP=NMIP   OPERATION=AM Released Container TARGET=Scheduler        RESULT=FAILURE    DESCRIPTION=Trying to release container not owned by app or with invalid id.    PERMISSIONS=Unauthorized access or invalid container    APPID=application_1572972524483_0023    CONTAINERID=container_1572972524483_0023_01_000004

По самым смутным впечатлениям я думаю, что при записи результатов в локальную файловую систему возникает проблема с кодировкой символов (отсюда и специальные символы вфайл результатов контейнера), но на самом деле это всего лишь предположение, и я понятия не имею, как проверить / решить эту проблему. Любая помощь с благодарностью!

Ответы [ 2 ]

0 голосов
/ 08 ноября 2019

Кто-то из списка рассылки Apache Hive предположил, что это вызвано тем, что контейнер YARN записывает свои файлы результатов на локальный компьютер, на котором он работает, вместо HDFS. Я покопался в исходном коде и обнаружил, что проблема вызывает

mapreduce.framework.name=local

, которая по умолчанию используется в Hadoop 3.2.1.

Решено с:

set mapreduce.framework.name=yarn
0 голосов
/ 06 ноября 2019

как вы вставили данные в таблицу улья? Hive выдает результат подсчета (*) из metastore вместо выполнения задания подсчета для оптимизации производительности. Попробуйте сначала восстановить MSCK на этой таблице, чтобы улей узнал о новых внешних файлах, и соответственно измените метасторье улей.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...