E-MapReduce:Troubleshoot and resolve Hive job failures

Erreurs d'épuisement de la mémoire (OOM) dues à une mémoire insuffisante du conteneur

Journaux d'erreur : java.lang.OutOfMemoryError: GC overhead limit exceeded ou java.lang.OutOfMemoryError: Java heap space.

Conteneur arrêté par YARN en raison d'une utilisation excessive de la mémoire

Journal d'erreur : Container killed by YARN for exceeding memory limits

Cause racine : la tâche Hive consomme plus de mémoire (y compris le tas JVM, la mémoire hors tas et les processus enfants) que la quantité demandée à YARN. Par exemple, dans Hive on MR, si la taille du tas JVM de la tâche Map (mapreduce.map.java.opts=-Xmx4g) dépasse l'allocation de mémoire YARN (mapreduce.map.memory.mb=3072, soit 3 Go), le NodeManager YARN arrête le conteneur.

OOM causé par un SortBuffer trop volumineux

• Journal d'erreur :

  Error running child: java.lang.OutOfMemoryError: Java heap space
  at org.apache.hadoop.mapred.MapTask$MapOutputBuffer.init(MapTask.java:986)

• Cause racine : la taille du tampon de tri (Sort Buffer) dépasse la taille du conteneur de tâche Hive. Par exemple, la mémoire du conteneur est définie sur 1 300 Mo, mais le SortBuffer est configuré sur 1 024 Mo.

• Solution : augmentez la mémoire du conteneur ou réduisez la taille du SortBuffer.

  tez.runtime.io.sort.mb (Hive on Tez)
  mapreduce.task.io.sort.mb (Hive on MR)

OOM causé par certaines instructions GroupBy

• Journal d'erreur :

  22/11/28 08:24:43 ERROR Executor: Exception in task 1.0 in stage 0.0 (TID 0)
  java.lang.OutOfMemoryError: GC overhead limit exceeded
      at org.apache.hadoop.hive.ql.exec.GroupByOperator.updateAggregations(GroupByOperator.java:611)
      at org.apache.hadoop.hive.ql.exec.GroupByOperator.processHashAggr(GroupByOperator.java:813)
      at org.apache.hadoop.hive.ql.exec.GroupByOperator.processKey(GroupByOperator.java:719)
      at org.apache.hadoop.hive.ql.exec.GroupByOperator.process(GroupByOperator.java:787)
      at org.apache.hadoop.hive.ql.exec.Operator.forward(Operator.java:897)
      at org.apache.hadoop.hive.ql.exec.SelectOperator.process(SelectOperator.java:95)
      at org.apache.hadoop.hive.ql.exec.Operator.forward(Operator.java:897)
      at org.apache.hadoop.hive.ql.exec.TableScanOperator.process(TableScanOperator.java:130)
      at org.apache.hadoop.hive.ql.exec.MapOperator$MapOpCtx.forward(MapOperator.java:148)
      at org.apache.hadoop.hive.ql.exec.MapOperator.process(MapOperator.java:547)

• Cause racine : la table de hachage GroupBy consomme trop de mémoire, provoquant une erreur OOM.

• Solution :

  1. Réduisez la taille des partitions (split size) à 128 Mo, 64 Mo ou moins afin d'accroître la concurrence du job : mapreduce.input.fileinputformat.split.maxsize=134217728 ou mapreduce.input.fileinputformat.split.maxsize=67108864.

  2. Augmentez la concurrence des mappeurs et des réducteurs.

  3. Augmentez la mémoire du conteneur. Pour plus de détails, consultez la section Erreurs d'épuisement de la mémoire (OOM) dues à une mémoire insuffisante du conteneur.

OOM lors de la lecture de fichiers Snappy

• Cause racine : les fichiers Snappy standard produits par des services tels que LogService utilisent un format différent de celui des fichiers Snappy de l'écosystème Hadoop. EMR utilise par défaut le format Snappy modifié pour Hadoop et génère une erreur OutOfMemoryError lorsqu'il rencontre des fichiers Snappy standard.

• Solution : configurez le paramètre suivant pour les jobs Hive.

  set io.compression.codec.snappy.native=true;

Délai d'expiration lors de la suppression de grandes tables partitionnées

• Journal d'erreur :

  FAILED: Execution ERROR, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. org.apache.thrift.transport.TTransportException: java.net.SocketTimeoutException: Read timeout

• Cause racine : la table comporte trop de partitions. L'opération de suppression prend plus de temps que le délai d'expiration réseau autorisé par le client Hive Metastore.

• Solution :

  1. Sur la page de configuration du service Hive dans la console EMR, cliquez sur l'onglet hive-site.xml et augmentez le délai d'expiration du socket du client metastore.

     hive.metastore.client.socket.timeout=1200s

  2. Supprimez les partitions par lots, par exemple en exécutant plusieurs fois des commandes de suppression conditionnelles.

     alter table [TableName] DROP IF EXISTS PARTITION (ds<='20220720')

insert overwrite avec des partitions dynamiques provoque l'échec du job

• Message d'erreur : lors de l'utilisation d'opérations insert overwrite sur des partitions dynamiques ou lors de l'exécution de jobs similaires incluant des opérations insert overwrite, l'erreur Exception when loading xxx in table se produit et le message d'erreur suivant apparaît dans les journaux HiveServer.

  Error in query: org.apache.hadoop.hive.ql.metadata.HiveException: Directory oss://xxxx could not be cleaned up.;

• Cause racine : désynchronisation entre les métadonnées et les données. Les métadonnées contiennent un enregistrement de partition, mais le chemin correspondant n'existe pas dans le système de stockage des données, ce qui entraîne une erreur « chemin introuvable » lors du nettoyage.

• Solution : corrigez l'incohérence des métadonnées avant de relancer le job.

Hive génère java.lang.IllegalArgumentException: java.net.UnknownHostException: emr-header-1.xxx lors de la lecture ou de la suppression de tables

• Cause racine : lorsqu'un cluster EMR utilise les métadonnées unifiées DLF ou une base de métadonnées unifiée (fonctionnalité héritée), le chemin de la base de données par défaut pointe vers le chemin HDFS du cluster EMR d'origine (par exemple, hdfs://master-1-1.xxx:9000/user/hive/warehouse/test.db ou hdfs://emr-header-1.cluster-xxx:9000/user/hive/warehouse/test.db). Les chemins des tables Hive héritent du chemin de la base de données et utilisent également le chemin HDFS de ce cluster (par exemple, hdfs://master-1-1.xxx:9000/user/hive/warehouse/test.db/test_tbl). Si vous utilisez Hive dans un nouveau cluster EMR pour accéder à une table ou une base de données créée par l'ancien cluster, le nouveau cluster peut ne pas pouvoir se connecter. Si l'ancien cluster a été libéré, l'erreur « java.net.UnknownHostException » est renvoyée.

• Solution :

  • Méthode 1 : si les données de la table Hive sont temporaires ou destinées à des tests, modifiez l'emplacement de la table Hive vers un chemin OSS et exécutez drop table ou drop database.

    -- Hive SQL
    alter table test_tbl set location 'oss://bucket/not/exists'
    drop table test_tbl;
    alter table test_pt_tbl partition (pt=xxx) set location 'oss://bucket/not/exists';
    alter table test_pt_tbl drop partition pt=xxx);
    alter database test_db set location 'oss://bucket/not/exists'
    drop datatabase test_db

  • Méthode 2 : si les données de la table Hive sont valides mais inaccessibles depuis le nouveau cluster, transférez les données HDFS de l'ancien cluster EMR vers OSS et créez une nouvelle table.

    hadoop fs -cp hdfs://emr-header-1.xxx/old/path oss://bucket/new/path
    hive -e "create table new_tbl like old_tbl location 'oss://bucket/new/path'"

Conflits causés par le placement de packages tiers dans le répertoire lib de Hive

• Cause racine : le placement de packages tiers ou le remplacement des fichiers JAR Hive dans le répertoire lib de Hive ($HIVE_HOME/lib ) provoque fréquemment des conflits de classpath. Évitez cette pratique.

• Solution : supprimez les packages tiers de $HIVE_HOME/lib et restaurez les fichiers JAR Hive d'origine.

Hive ne peut pas utiliser la fonction reflect

• Cause racine : la fonction reflect peut être indisponible lorsque l'authentification Ranger est activée.

• Solution : retirez reflect de la liste noire en configurant hive-site.xml.

  hive.server2.builtin.udf.blacklist=empty_blacklist

Les UDF personnalisées ralentissent l'exécution des jobs

• Cause racine : les jobs Hive s'exécutent lentement sans journaux d'erreur explicites. Cela est souvent dû à de mauvaises performances des UDF personnalisées.

• Solution : effectuez un vidage de threads (thread dump) sur la tâche Hive pour identifier les goulots d'étranglement et optimiser l'UDF personnalisée en conséquence.

Échec de la fonction grouping()

• Symptôme : l'utilisation de la fonction grouping() génère l'erreur suivante :

  grouping() requires at least 2 argument, got 1

  Cette erreur indique un problème d'analyse syntaxique lors de l'appel de la fonction grouping().

• Cause racine : il s'agit d'un bogue connu dans la version open source de Hive. L'analyseur de Hive respecte la casse pour la fonction grouping(). L'utilisation de grouping() en minuscules amène Hive à mal identifier la fonction, ce qui entraîne une analyse incorrecte des arguments.

• Solution : remplacez la fonction grouping() dans votre requête SQL par GROUPING() en majuscules.

Résultats incohérents dus aux différences de fuseau horaire entre Hive et Spark

• Symptôme : la fonction from_unix_time de Hive utilise le temps universel coordonné (UTC), tandis que Spark utilise le fuseau horaire local. Cette divergence produit des résultats différents pour la même requête.

• Solution : définissez le fuseau horaire de Spark sur UTC en ajoutant ce code dans Spark SQL :

  set spark.sql.session.timeZone=UTC;

  Ou ajoutez ce paramètre au fichier de configuration Spark :

  spark.sql.session.timeZone=UTC

Hive on Spark avec partitionnement dynamique s'exécute lentement (bug connu)

• Cause racine : un bogue dans la version open source de Hive amène Beeline à activer spark.dynamicAllocation.enabled, ce qui force Hive à définir le nombre de partitions de shuffle sur 1.

• Solution : désactivez l'allocation dynamique des ressources pour les jobs Hive on Spark ou utilisez plutôt Hive on Tez.

  spark.dynamicAllocation.enabled=false

Tez échoue lorsque hive.optimize.dynamic.partition.hashjoin est activé (bug connu)

• Journal d'erreur :

  Vertex failed, vertexName=Reducer 2, vertexId=vertex_1536275581088_0001_5_02, diagnostics=[Task failed, taskId=task_1536275581088_0001_5_02_000009, diagnostics=[TaskAttempt 0 failed, info=[Error: Error while running task ( failure ) : attempt_1536275581088_0001_5_02_000009_0:java.lang.RuntimeException: java.lang.RuntimeException: cannot find field _col1 from [0:key, 1:value]
      at org.apache.hadoop.hive.ql.exec.tez.TezProcessor.initializeAndRunProcessor(TezProcessor.java:296)
      at org.apache.hadoop.hive.ql.exec.tez.TezProcessor.run(TezProcessor.java:250)
  ]]]

• Cause racine : un bogue dans la version open source de Hive.

• Solution : comme solution de contournement, désactivez ce paramètre.

  hive.optimize.dynamic.partition.hashjoin=false

MapJoinOperator génère une NullPointerException (bug connu)

• Journal d'erreur.

  2022-05-06 18:37:26,664 ERROR [main] org.apache.hadoop.hive.ql.exec.mr.ExecMapper: java.lang.NullPointerException
          at org.apache.hadoop.hive.ql.exec.MapJoinOperator.loadHashTable(MapJoinOperator.java:313)
          at org.apache.hadoop.hive.ql.exec.MapJoinOperator.cleanUpInputFileChangedOp(MapJoinOperator.java:345)
          at org.apache.hadoop.hive.ql.exec.Operator.cleanUpInputFileChanged(Operator.java:1124)
          at org.apache.hadoop.hive.ql.exec.Operator.cleanUpInputFileChanged(Operator.java:1128)
          at org.apache.hadoop.hive.ql.exec.Operator.cleanUpInputFileChanged(Operator.java:1128)
          at org.apache.hadoop.hive.ql.exec.MapOperator.process(MapOperator.java:540)
          at org.apache.hadoop.hive.ql.exec.mr.ExecMapper.map(ExecMapper.java:148)
          at org.apache.hadoop.mapred.MapRunner.run(MapRunner.java:54)
          at org.apache.hadoop.mapred.MapTask.runOldMapper(MapTask.java:453)
          at org.apache.hadoop.mapred.MapTask.run(MapTask.java:343)
          at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:175)
          at java.security.AccessController.doPrivileged(Native Method)
          at javax.security.auth.Subject.doAs(Subject.java:422)
          at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1911)
          at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:169)

• Cause racine : l'activation de hive.auto.convert.join.noconditionaltask déclenche cette NullPointerException.

• Solution : désactivez le paramètre associé.

  hive.auto.convert.join.noconditionaltask=false

Hive on Tez génère une IllegalStateException (bug connu)

• Journal d'erreur :

  java.lang.RuntimeException: java.lang.IllegalStateException: Was expecting dummy store operator but found: FS[17]
          at org.apache.hadoop.hive.ql.exec.tez.TezProcessor.initializeAndRunProcessor(TezProcessor.java:296)
          at org.apache.hadoop.hive.ql.exec.tez.TezProcessor.run(TezProcessor.java:250)
          at org.apache.tez.runtime.LogicalIOProcessorRuntimeTask.run(LogicalIOProcessorRuntimeTask.java:374)
          at org.apache.tez.runtime.task.TaskRunner2Callable$1.run(TaskRunner2Callable.java:73)
          at org.apache.tez.runtime.task.TaskRunner2Callable$1.run(TaskRunner2Callable.java:61)
          at java.security.AccessController.doPrivileged(Native Method)
          at javax.security.auth.Subject.doAs(Subject.java:422)
          at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1730)
          at org.apache.tez.runtime.task.TaskRunner2Callable.callInternal(TaskRunner2Callable.java:61)
          at org.apache.tez.runtime.task.TaskRunner2Callable.callInternal(TaskRunner2Callable.java:37)
          at org.apache.tez.common.CallableWithNdc.call(CallableWithNdc.java:36)

• Cause racine : un bogue dans la version open source de Hive qui se produit lorsque la réutilisation de l'AM Tez est activée. Ce problème n'est pas encore corrigé dans EMR Hive.

• Solution : désactivez la réutilisation de l'ApplicationMaster Tez pour des jobs individuels.

  set tez.am.container.reuse.enabled=false;

select count(1) renvoie 0

• Cause racine : select count(1) s'appuie sur les statistiques de la table Hive, mais celles-ci sont obsolètes ou inexactes.

• Solution : désactivez l'utilisation des statistiques.

  hive.compute.query.using.stats=false

  Ou recalculez les statistiques de la table à l'aide de la commande analyze.

  analyze table <table_name> compute statistics;

Échec de la soumission de jobs Hive sur des instances ECS gérées par l'utilisateur

La soumission de jobs Hive depuis des instances ECS gérées par l'utilisateur en dehors du cluster EMR entraîne des erreurs imprévisibles. Utilisez plutôt un cluster Gateway EMR ou déployez un environnement Gateway à l'aide d'EMR-CLI. Pour plus d'informations, consultez la rubrique Déployer un environnement Gateway à l'aide d'EMR-CLI.

Échecs de jobs dus à un déséquilibre des données (data skew)

• Comportement anormal :

  • Les données de shuffle remplissent l'espace disque.

  • Certaines tâches prennent beaucoup plus de temps à s'exécuter.

  • Certaines tâches ou conteneurs rencontrent des erreurs OOM.

• Solution :

  1. Activez l'optimisation des jointures asymétriques (skew join) de Hive.

     set hive.optimize.skewjoin=true;

  2. Augmentez la concurrence des mappeurs et des réducteurs.

  3. Augmentez la mémoire du conteneur. Pour plus de détails, consultez la section Erreurs d'épuisement de la mémoire (OOM) dues à une mémoire insuffisante du conteneur.

Comment gérer l'erreur « Too many counters: 121 max=120 » ?

• Description : cette erreur survient lors de l'exécution de jobs SQL Hive avec les moteurs Tez ou MR.

• Analyse : le job dépasse la limite par défaut de compteurs.

• Solution : dans l'onglet Configure du service YARN sur la console EMR, recherchez le paramètre mapreduce.job.counters.max et augmentez sa valeur. Après la mise à jour, resoumettez le job Hive. Si vous soumettez des jobs via Beeline ou JDBC, redémarrez le service HiveServer.