Ma requête Amazon EMR Hive échoue avec une exception FileNotFoundException

Date de la dernière mise à jour : 2020-08-28

Lorsque j'essaie d'écrire des données dans des tables Apache Hive situées dans un compartiment Amazon Simple Storage Service (Amazon S3) à l'aide d'un cluster Amazon EMR, la requête échoue avec l'une des erreurs suivantes :

  • java.io.FileNotFoundException File s3://awsdoc-example-bucket/.hive-staging_hive_xxx_xxxx n'existe pas.
  • java.io.IOException : renommer pour le chemin src ERROR

Brève description

Lorsque vous exécutez INSERT INTO, INSERT OVERWRITE ou d'autres commandes PARTITION, Hive crée des répertoires intermédiaires dans le même compartiment S3 que la table. Pour écrire les données de requête intermédiaire dans ce compartiment S3, Hive exécute une opération RENAME.

L'opération RENAME inclut des appels d'API S3 de bas niveau tels que HEAD, GET et PUT. Si Hive envoie une requête HEAD ou GET à un nom de clé avant de créer ce fichier, Amazon S3 fournit une cohérence éventuelle pour la lecture après écriture. Lorsque cela se produit, Hive ne peut pas renommer le répertoire temporaire en répertoire de sortie final. Cela provoque une erreur de type java.io.IOException ou java.io.FileNotFoundException. Pour plus d'informations, consultez le Modèle de cohérence des données d'Amazon S3.

Résolution

Remarque : les étapes suivantes s'appliquent à Amazon EMR version 3.2.1 et ultérieure. Si votre cluster utilise Amazon EMR version 5.7.0 ou antérieure, nous vous recommandons de mettre à niveau vers la version 5.8.0 ou ultérieure. Les versions 5.8.0 et ultérieures incluent Hive 2.3.x. Les erreurs java.io.IOException et java.io.FileNotFoundException peuvent toujours se produire dans Hive 2.3.x, mais uniquement avec les tables stockées dans Amazon S3. Ces erreurs ne se produisent pas avec les tables HDFS, car Hive crée le répertoire intermédiaire dans un emplacement HDFS fortement cohérent, plutôt que dans le même répertoire que la table que vous interrogez.

1.    Connectez-vous au nœud principal en utilisant SSH.

2.    Recherchez le journal des erreurs Hive dans le répertoire /mnt/var/log/hive/user/hadoop/hive.log ou le journal du conteneur d'application YARN sous votre URI de journal Amazon S3, comme illustré dans l'exemple suivant. Pour plus d'informations, consultez Afficher les fichiers journaux.

s3://awsdoc-example-bucket/elasticmapreduce/j-3ABCDEF2BALUG5/Containers/application_11234567890654_0001/

3.    Recherchez des messages d'erreur comme ceci :

2020-08-27T11:53:28,837 ERROR [HiveServer2-Background-Pool: Thread-64([])]: ql.Driver (SessionState.java:printError(1097)) - FAILED: Execution Error, return code 2 from org.apache.hadoop.hive.ql.exec.tez.TezTask. Vertex failed, vertexName=Map 6, vertexId=vertex_1525862550243_0001_1_03, diagnostics=[Vertex vertex_1525862550243_0001_1_03 [Map 6] killed/failed due to:ROOT_INPUT_INIT_FAILURE, Vertex Input: r initializer failed, vertex=vertex_1525862550243_0001_1_03 [Map 6], java.io.FileNotFoundException: File s3://awsdoc-example-bucket/folder/subfolder/subfolder/.hive-staging_hive_2020-08-25_09-36-30_835_6368934499747071892-1 does not exist. at com.amazon.ws.emr.hadoop.fs.s3n.S3NativeFileSystem.listStatus(S3NativeFileSystem.java:972)
Caused by: org.apache.hadoop.hive.ql.metadata.HiveException: Unable to rename output from: s3://awsdoc-example-bucket/demo.db/folder/ingestion_date=20200827/.hive-staging_hive_2020-08-27_13-52-51_942_3098569974412217069-5/_task_tmp.-ext-10000/_tmp.000000_2 to: s3://awsdoc-example-bucket/demo.db/folder/ingestion_date=20200827/.hive-staging_hive_2019-10-27_13-52-51_942_3098569974412217069-5/_tmp.-ext-10000/000000_2  at org.apache.hadoop.hive.ql.exec.FileSinkOperator$FSPaths.commit(FileSinkOperator.java:247)

4.    Si l'une de ces erreurs se trouve dans vos journaux, cela signifie que Hive a effectué une requête HEAD pendant l'opération RENAME avant la création du fichier. Pour résoudre ces erreurs, activez la vue cohérente EMRFS. Pour plus d'informations, consultez Vue cohérente.

Si aucune de ces erreurs ne figure dans vos journaux, consultez Comment utiliser les journaux pour résoudre les problèmes liés aux requêtes Hive dans Amazon EMR ?

5.    Si vous obtenez toujours ces erreurs après avoir activé l'affichage cohérent, configurez des paramètres supplémentaires pour une vue cohérente. Par exemple, si Amazon DynamoDB bloque la table EMRFS, modifiez les paramètres suivants dans emrfs-site.xml pour augmenter les unités de capacité de lecture et d'écriture de la table :

fs.s3.consistent.metadata.read.capacity

fs.s3.consistent.metadata.write.capacity

Lorsqu'une requête échoue en raison de java.io.FileNotFoundException ou java.io.IOException, EMRFS tente de nouveau la requête en utilisant les valeurs par défaut dans emrfs-site.xml. EMRFS continue de réessayer la demande jusqu'à ce qu'Amazon S3 soit cohérent ou jusqu'à l'atteinte de la valeur définie dans fs.s3.consistent.retryCount. Si EMRFS atteint le nombre de nouvelles tentatives avant que l'opération ne réussisse, vous obtenez une Exception_cohérence. Pour résoudre ce problème, augmentez fs.s3.consistent.retryCount.