Сначала немного фона. У меня есть тестовый CDH-кластер с двумя узлами. Я пытаюсь выполнить работу Oozie, загрузить файл, обработать его с помощью SPARK, а затем проиндексировать его в Solr.Проблема с работой Oozie, работающей на Hadoop - Разрешения on/user/history/done_intermediate
Кластер настроен на использование аутентификации Kerberos. версия CDH является 5.7.1
Когда я пытаюсь запустить работу с Oozie, используя следующую команду:
oozie job --oozie https://host:11443/oozie/ -run --config oozieExample/job.properties
Он терпит неудачу за исключением следующего:
2016-08-12 12:29:40,415 WARN org.apache.oozie.action.hadoop.JavaActionExecutor: SERVER[it4364-cdh01.novalocal] USER[centos] GROUP[-] TOKEN[] APP[stackOverflow] JOB[0000012-160808110839555-oozie-clou-W] ACTION[[email protected]_Current_Data] Exception in check(). Message[JA017: Could not lookup launched hadoop Job ID [job_1470672690566_0027] which was associated with action [[email protected]_Current_Data]. Failing this action!]
org.apache.oozie.action.ActionExecutorException: JA017: Could not lookup launched hadoop Job ID [job_1470672690566_0027] which was associated with action [[email protected]_Current_Data]. Failing this action!
at org.apache.oozie.action.hadoop.JavaActionExecutor.check(JavaActionExecutor.java:1277)
at org.apache.oozie.command.wf.ActionCheckXCommand.execute(ActionCheckXCommand.java:182)
at org.apache.oozie.command.wf.ActionCheckXCommand.execute(ActionCheckXCommand.java:56)
at org.apache.oozie.command.XCommand.call(XCommand.java:286)
at org.apache.oozie.service.CallableQueueService$CallableWrapper.run(CallableQueueService.java:175)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
С быстрый поиск Google, кажется, что это происходит, когда сервер истории заданий не запущен или не может обнаружить промежуточную директорию для заданий.
При выполнении команды ls на каталог истории, я получил следующее:
[[email protected] ~]$ hadoop fs -ls /user/history
Found 2 items
drwxrwx--- - mapred hadoop 0 2016-08-12 10:36 /user/history/done
drwxrwxrwt - mapred hadoop 0 2016-08-12 12:29 /user/history/done_intermediate
Что хорошо, я думаю. Теоретически, пользователь mapred должен быть владельцем папки с историей, основанной на документации CDH.
Однако, когда я проверяю содержимое done_intermediate:
[[email protected] ~]$ hadoop fs -ls /user/history/done_intermediate
Found 1 items
drwxrwx--- - centos hadoop 0 2016-08-12 12:29 /user/history/done_intermediate/centos
Это означает, что пользователь centos (один выполняет задание Oozie) является владельцем этого каталога. Это предотвращает чтение файла журнала заданий, чтобы отметить задание как завершенное, а затем Оози пометить его как потерпевшее неудачу. Бревна утверждают именно это:
<ommited for brevity>
...
Caused by: org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException): Permission denied: user=mapred, access=READ_EXECUTE, inode="/user/history/done_intermediate/centos":centos:hadoop:drwxrwx---
at org.apache.hadoop.hdfs.server.namenode.DefaultAuthorizationProvider.checkFsPermission(DefaultAuthorizationProvider.java:281)
at org.apache.hadoop.hdfs.server.namenode.DefaultAuthorizationProvider.check(DefaultAuthorizationProvider.java:262)
...
<ommited for brevity>
Если изменить право собственности на все содержимое на папке журнала, с hadoop fs -ls -R /user/history сервер истории признает работу и пометить его как завершенный.
Я попытался запустить задание в качестве отображаемого пользователя, изменив файл .properties для задания, однако это также не удается, теперь, поскольку у наведенного пользователя нет разрешений на запись в папкувнутри HDFS, так что кажется что это не правильное решение.
Есть ли какая-то конфигурация, чтобы избежать конфликта пользователей между centos и mapred, в папке с историей?
Заранее спасибо
Эта настройка должна работать - если пользователь 'mapred' действительно является членом группы' hadoop'. Можете ли вы попытаться создать билет Kerberos для «mapred @ YOUR.REALM», а затем запустить «hdfs groups», чтобы быть уверенным? –
Спасибо @SamsonScharfrichter. У меня было два вопроса. Во-первых, наведенный пользователь не существовал в Active Directory, который используется для Kerberos. Во-вторых, пользователь не был в правильной группе. После исправления, что работа выполняется без проблем. Можете ли вы опубликовать этот комментарий в качестве ответа, чтобы я мог его принять? –