Позвольте мне ответить на мой собственный вопрос.Первое, что очень важно отметить при выполнении заданий HIVE на EMR, это то, что ошибка STEP вводит в заблуждение.Это не скажет вам точную причину, почему работа терпит неудачу.Таким образом, мы можем посмотреть, но мы ищем журналы HIVE.Теперь, если наш экземпляр завершен, мы не можем войти в главный экземпляр, в этом случае нам нужно искать журналы приложений узлов.Вот как мы можем найти это.Получите идентификатор экземпляра мастера примерно так (i-04d04d9a8f7d28fd1) и с этим поиском в узлах.Затем откройте путь ниже
/applications/hive/user/hive/hive.log.gz
Здесь вы можете найти ожидаемую ошибку.
Кроме того, мы должны искать журналы контейнеров для отказавших узлов, подробности сбойных узлов можно найти в главном экземпляре.node.
hadooplogs/j-25RSD7FFOL5JB/node/i-03f8a646a7ae97aae/daemons/
Журналы узлов демонов можно найти только в том случае, если кластер еще работает после завершения кластера. emr не помещает журналы в журнал S3 URI.
Когда я смотрел на негоУ меня есть реальная причина, почему это не удалось.Для меня это стало причиной сбоя
При проверке журналов контроллера экземпляра главного экземпляра я обнаружил, что несколько основных экземпляров перешли в нерабочее состояние:
2019-02-27 07:50:03,905 INFO Poller: InstanceJointStatusMap contains 21 entries (R:21):
i-0131b7a6abd0fb8e7 1541s R 1500s ig-28 ip-10-97-51-145.tr-fr-nonprod.aws-int.thomsonreuters.com I: 18s Y:U 81s c: 0 am: 0 H:R 0.6%Yarn unhealthy Reason : 1/1 local-dirs are bad: /mnt/yarn; 1/1 log-dirs are bad: /var/log/hadoop-yarn/containers
i-01672279d170dafd3 1539s R 1500s ig-28 ip-10-97-54-69.tr-fr-nonprod.aws-int.thomsonreuters.com I: 16s Y:R 79s c: 0 am:241664 H:R 0.7%
i-0227ac0f0932bd0b3 1539s R 1500s ig-28 ip-10-97-51-197.tr-fr-nonprod.aws-int.thomsonreuters.com I: 16s Y:R 79s c: 0 am:241664 H:R 4.1%
i-02355f335c190be40 1544s R 1500s ig-28 ip-10-97-52-150.tr-fr-nonprod.aws-int.thomsonreuters.com I: 22s Y:R 84s c: 0 am:241664 H:R 0.2%
i-024ed22b6affdd5ec 1540s R 1500s ig-28 ip-10-97-55-123.tr-fr-nonprod.aws-int.thomsonreuters.com I: 16s Y:U 79s c: 0 am: 0 H:R 0.6%Yarn unhealthy Reason : 1/1 local-dirs are bad: /mnt/yarn; 1/1 log-dirs are bad: /var/log/hadoop-yarn/containers
Также после некоторогоtime пряжа занесена в черный список экземпляров Core:
2019-02-27 07:46:39,676 INFO Poller: Determining health status for App Monitor: aws157.instancecontroller.apphealth.monitor.YarnMonitor
2019-02-27 07:46:39,688 INFO Poller: SlaveRecord i-0ac26bd7886fec338 changed state from RUNNING to BLACKLISTED
2019-02-27 07:47:13,695 INFO Poller: SlaveRecord i-0131b7a6abd0fb8e7 changed state from RUNNING to BLACKLISTED
2019-02-27 07:47:13,695 INFO Poller: Update SlaveRecordDbRow for i-0131b7a6abd0fb8e7 ip-10-97-51-145.tr-fr-nonprod.aws-int.thomsonreuters.com
2019-02-27 07:47:13,696 INFO Poller: SlaveRecord i-024ed22b6affdd5ec changed state from RUNNING to BLACKLISTED
2019-02-27 07:47:13,696 INFO Poller: Update SlaveRecordDbRow for i-024ed22b6affdd5ec ip-10-97-55-123.tr-fr-nonprod.aws-int.thomsonreuters.com
При проверке журналов экземпляра контроллера экземпляров узлов я вижу, что / mnt заполнился из-за кэширования задания и использования превысило пороговое значение, т.е. по умолчанию 90%.
Из-за этой пряжи:
2019-02-27 07:40:52,231 INFO dsm-1: /mnt total 27633 MB free 2068 MB used 25565 MB
2019-02-27 07:40:52,231 INFO dsm-1: / total 100663 MB free 97932 MB used 2731 MB
2019-02-27 07:40:52,231 INFO dsm-1: cycle 17 /mnt/var/log freeSpaceMb: 2068/27633 MB freeRatio:0.07
2019-02-27 07:40:52,248 INFO dsm-1: /mnt/var/log stats :
-> Как и в моем наборе данных, исходная таблица имеет сжатие .gz.Поскольку сжатые файлы .gz являются неразделимыми из-за этого 1 файлу назначено 1 задание карты.И поскольку задача map распаковывает файл в / mnt, это также может привести к этой проблеме.
-> Обработка большого количества данных в EMR требует некоторых свойств улья для оптимизации.Ниже приведены несколько свойств оптимизации, которые можно установить в кластере, чтобы сделать запрос более эффективным.
VVVVVI
Increase the EBS volume size for Core instances
Важно то, что мы должныувеличьте объем EBS для каждого ядра, а не только для главного, потому что том EBS находится там, где / mnt монтируется не на маршруте.
Это само по себе решило мою проблему, но приведенная ниже конфигурация также помогла мне оптимизировать задания HIVE
hive-site.xml
-------------
"hive.exec.compress.intermediate" : "true",
"hive.intermediate.compression.codec" : "org.apache.hadoop.io.compress.SnappyCodec",
"hive.intermediate.compression.type" : "BLOCK"
yarn-site.xml
-------------
"max-disk-utilization-per-disk-percentage" : "99"
И это навсегда решило мою проблему.
Надеюсь, кто-нибудь получит пользу от моего ответа