Migrer des charges de travail Azure HDInsight 3.6 Hive vers HDInsight 4.0

  • Article

HDInsight 4.0 a plusieurs avantages par rapport à HDInsight 3.6. Voici une vue d’ensemble des nouveautés dans HDInsight 4.0.

Cet article décrit les étapes à suivre pour migrer des charges de travail Hive de HDInsight 3.6 vers 4.0, notamment

  • Mettre à niveau le schéma et copier le metastore Hive
  • Migration sécurisée pour la compatibilité ACID
  • Préservation des stratégies de sécurité Hive

Les nouveaux et anciens clusters HDInsight doivent avoir accès aux mêmes comptes de stockage.

La migration des tables Hive vers un nouveau compte de stockage doit être effectuée dans le cadre d’une étape distincte. Consultez Migration Hive entre des comptes de stockage.

Modifications apportées à Hive 3 et nouveautés :

Modifications du client Hive

Hive 3 prend uniquement en charge le client léger, Beeline pour l’exécution des requêtes et les commandes d’administration Hive à partir de la ligne de commande. Beeline utilise une connexion JDBC à HiveServer pour exécuter toutes les commandes. Les opérations d’analyse, de compilation et d’exécution se produisent dans HiveServer.

Vous entrez les commandes CLI Hive prises en charge en appelant Beeline à l’aide du mot clé Hive en tant qu’utilisateur Hive ou en appelant un Beeline à l’aide de beeline -u <JDBC URL>. Vous pouvez obtenir l’URL JDBC à partir de la page Ambari Hive.

Screenshot showing JDBC URL output.

L’utilisation de Beeline (au lieu de l’interface CLI Hive, qui n’est plus prise en charge) présente plusieurs avantages, notamment :

  • Au lieu de conserver l’intégralité de la base de code Hive, vous pouvez gérer uniquement le client JDBC.
  • La surcharge de démarrage est plus faible à l’aide de Beeline, car la base de code Hive entière n’est pas impliquée.

Vous pouvez également exécuter le script Hive, qui se trouve sous le répertoire « /usr/bin », qui appelle une connexion Beeline à l’aide de l’URL JDBC.

Screenshot showing beeline connection output.

Une architecture de client léger facilite la sécurisation des données

  • L’état de session, les structures de données internes, les mots de passe, etc., résident sur le client plutôt que sur le serveur.
  • Le petit nombre de démons requis pour exécuter des requêtes simplifie la surveillance et le débogage.

HiveServer applique les paramètres de liste d’autorisation et de liste de blocage que vous pouvez modifier à l’aide des commandes SET. À l’aide des listes de blocage, vous pouvez restreindre la configuration de la mémoire pour empêcher l’instabilité du serveur Hive. Vous pouvez configurer plusieurs instances HiveServer avec des listes d’autorisation et des listes de blocage différentes pour établir différents niveaux de stabilité.

Modifications du Metastore Hive

Hive prend désormais en charge uniquement un metastore distant au lieu d’un metastore incorporé (dans HS2 JVM). Le metastore Hive réside sur un nœud d’un cluster géré par Ambari dans le cadre de la pile HDInsight. Un serveur autonome en dehors du cluster n’est pas pris en charge. Vous ne définissez plus les commandes key=value sur la ligne de commande pour configurer le Metastore Hive. En fonction de la valeur configurée dans « hive.metastore.uris=' ' » le service HMS a été utilisé et la connexion établie.

Modification du moteur d’exécution

Apache Tez remplace MapReduce comme moteur d’exécution Hive par défaut. MapReduce est déconseillé à partir de Hive 2.0 Reportez-vous à HIVE-12300. Avec des expressions de graphiques acycliques dirigés (DAG) et de primitives de transfert de données, l’exécution de requêtes Hive sous Tez améliore les performances. Les requêtes SQL que vous envoyez à Hive sont exécutées comme suit

  1. Hive compile la requête.
  2. Tez exécute la requête.
  3. YARN alloue des ressources pour les applications sur le cluster et active l’autorisation pour les travaux Hive dans les files d’attente YARN.
  4. Hive met à jour les données dans ABFS ou WASB.
  5. Hive retourne les résultats de la requête via une connexion JDBC.

Si un script ou une application héritée spécifie MapReduce pour l’exécution, une exception se produit comme suit

Screenshot showing map reducer exception output.

Remarque

La plupart des fonctions définies par l’utilisateur (UDF) ne nécessitent aucune modification pour s’exécuter sur Tez au lieu de MapReduce.

Modifications relatives à la transaction ACID et à la CBO :

  • Les tables ACID sont le type de table par défaut dans HDInsight 4.x sans surcharge opérationnelle ni performances.

  • Développement d’applications simplifié, opérations avec des garanties transactionnelles plus fortes et sémantique plus simple pour les commandes SQL

  • Hive internal prend en charge le compartimentage des tables ACID dans HDInsight 4.1, ce qui supprime la surcharge de maintenance.

  • Optimisations avancées – Mise à niveau dans CBO

  • Cache automatique des requêtes. La propriété utilisée pour activer la mise en cache des requêtes est hive.query.results.cache.enabled. Vous devez définir cette propriété sur true. Hive stocke le cache des résultats de requête dans /tmp/hive/__resultcache__/. Par défaut, Hive alloue 2 Go au cache des résultats de la requête. Vous pouvez changer ce paramètre en configurant le paramètre suivant en octets : hive.query.results.cache.max.size.

    Pour plus d'informations, Avantages de la migration vers Azure HDInsight 4.0.

Réécritures de vue matérialisée

Pour plus d’informations, consultez Hive - Affichages matérialisés

Modifications après la mise à niveau vers Apache Hive 3

Pour localiser et utiliser vos tables Apache Hive 3 après une mise à niveau, vous devez comprendre les modifications qui se produisent pendant le processus de mise à niveau. Modifications apportées à la gestion et à l’emplacement des tables, autorisations sur les répertoires de tables, types de tables et problèmes de conformité ACID.

Gestion Hive des tables

Hive 3 prend plus de contrôle sur les tables que Hive 2 et exige que les tables managées respectent une définition stricte. Le niveau de contrôle que Hive prend sur les tables est homogène par rapport aux bases de données traditionnelles. Hive est consciente des modifications delta apportées aux données ; cette infrastructure de contrôle améliore les performances.

Par exemple, si Hive sait que la résolution d’une requête ne nécessite pas d’analyse des tables pour de nouvelles données, Hive retourne les résultats du cache des résultats de la requête Hive. Lorsque les données sous-jacentes d’une vue matérialisée changent, Hive doit reconstruire la vue matérialisée. Les propriétés ACID révèlent exactement quelles lignes ont été modifiées et doivent être traitées et ajoutées à la vue matérialisée.

Modifications apportées aux propriétés ACID par Hive

Hive 2.x et 3.x ont à la fois des tables transactionnelles (managées) et non transactionnelles (externes). Les tables transactionnelles ont des propriétés atomiques, cohérentes, d’isolation et durables (ACID). Dans Hive 2.x, la version initiale du traitement des transactions ACID est ACID v1. Dans Hive 3.x, les tables par défaut sont avec ACID v2.

Formats de stockage natifs et non natifs

Les formats de stockage sont un facteur de mise à niveau des types de tables. Hive 2.x et 3.x prennent en charge les formats de stockage Hadoop natifs et non natifs suivants

Natif : Tables avec prise en charge intégrée dans Hive, dans les formats de fichier suivants

  • Texte
  • Fichier de séquence
  • Fichier RC
  • Fichier AVRO
  • Fichier ORC
  • Fichier Parquet

Non natif : Tables qui utilisent un gestionnaire de stockage, tel que DruidStorageHandler ou HBaseStorageHandler

Modifications apportées à la mise à niveau HDInsight 4.x vers les types de tables

Le tableau suivant compare les types de tables Hive et les opérations ACID avant une mise à niveau à partir de HDInsight 3.x et après une mise à niveau vers HDInsight 4.x. La propriété du fichier de table Hive est un facteur dans la détermination des types de tables et des opérations ACID après la mise à niveau

Comparaison des types de table HDInsight 3.x et HDInsight 4.x

HDInsight 3.x - - - HDInsight 4.x -
Type de la table ACID v1 Format Propriétaire (utilisateur) du fichier de table Hive Type de la table ACID v2
Externe Non Natif ou non natif Hive ou non-Hive Externe Non
Adresses IP gérées Oui ORC Hive ou non-Hive Managé, pouvant être mis à jour Oui
Adresses IP gérées Non ORC Hive Managé, pouvant être mis à jour Oui
Adresses IP gérées Non ORC non-Hive Externe, avec suppression de données Non
Adresses IP gérées Non Natif (mais non-ORC) Hive Managé, insertion uniquement Oui
Adresses IP gérées Non Natif (mais non-ORC) non-Hive Externe, avec suppression de données Non
Adresses IP gérées Non Non natif Hive ou non-Hive Externe, avec suppression de données Non

Emprunt d’identité Hive

L’emprunt d’identité Hive a été activé par défaut dans Hive 2 (doAs=true) et désactivé par défaut dans Hive 3. L’emprunt d’identité Hive exécute Hive en tant qu’utilisateur final ou non.

Autres modifications de mise à niveau HDInsight 4.x

  1. Les tables ACID managées qui ne sont pas détenues par l’utilisateur Hive restent managées après la mise à niveau, mais Hive devient propriétaire.
  2. Après la mise à niveau, le format d’une table Hive est le même qu’avant la mise à niveau. Par exemple, les tables natives ou non natives restent natives ou non natives, respectivement.

Changements d’emplacement

Après la mise à niveau, l’emplacement des tables ou partitions managées ne change pas dans l’une des conditions suivantes :

  • L’ancien répertoire de table ou de partition n’était pas à son emplacement par défaut /apps/hive/warehouse avant la mise à niveau.
  • L’ancienne table ou partition se trouve dans un système de fichiers différent du nouveau répertoire d’entrepôt.
  • L’ancien répertoire de table ou de partition se trouve dans une autre zone de chiffrement que le nouveau répertoire d’entrepôt.

Sinon, l’emplacement des tables ou partitions managées change. Le processus de mise à niveau déplace les fichiers managés vers /hive/warehouse/managed. Par défaut, Hive place toutes les nouvelles tables externes que vous créez dans HDInsight 4.x dans /hive/warehouse/external

/apps/hive directory, qui est l’ancien emplacement de l’entrepôt Hive 2.x, peut exister ou non dans HDInsight 4.x

Les scénarios suivants sont présents pour les modifications d’emplacement

Scénario 1

Si la table est une table managée dans HDInsight-3.x et si elle est présente à l’emplacement /apps/hive/warehouse et convertie en tant que table externe dans HDInsight-4.x, l’emplacement est également le même /apps/hive/warehouse dans HDInsight 4.x. Il n'y a pas de changement d'emplacement. Après cette étape, si vous effectuez la commande alter table pour la convertir en table managée (acid) à ce moment-là présente au même emplacement /apps/hive/warehouse.

Scénario 2

Si la table est une table managée dans HDInsight-3.x et si elle est présente à l’emplacement /apps/hive/warehouse et convertie en table managée (ACID) dans HDInsight 4.x, l’emplacement est /hive/warehouse/managed.

Scénario 3 Si vous créez une table externe, dans HDInsight-4.x sans spécifier d’emplacement, elle se présente à l’emplacement /hive/warehouse/external.

Conversion de table

Après la mise à niveau, pour convertir une table non transactionnelle en table transactionnelle ACID v2, vous utilisez la commande ALTER TABLE et définissez les propriétés de la table sur

transaction'='true' and 'EXTERNAL'='false
  • La table managée, le format ORC non ACID et appartenant à un utilisateur non Hive dans HDInsight-3.x sera converti en table externe non ACID dans HDInsight-4.x.
  • Si l’utilisateur souhaite remplacer la table externe (non ACID) par ACID, il doit également remplacer la table externe par une version managée et ACID. Dans HDInsight-4.x, toutes les tables managées sont strictement ACID par défaut. Vous ne pouvez pas convertir les tables externes (non ACID) en table ACID.

Notes

La table doit être une table ORC.

Pour convertir une table externe (non ACID) en table managée (ACID),

  1. Convertissez la table externe en managée et acid égale à true à l’aide de la commande suivante : 
    alter table <table name> set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');
  2. Si vous essayez d’exécuter la commande suivante pour la table externe, vous obtenez l’erreur ci-dessous.

Scénario 1

Considérez que la table rt est une table externe (non ACID). Si la table n’est pas une table ORC,

alter table rt set TBLPROPERTIES ('transactional'='true');
ERROR : FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. The table must be stored using an ACID compliant format (such as ORC): work.rt
The table must be ORC format

Scénario 2

>>>> alter table rt set TBLPROPERTIES ('transactional'='true'); If the table is ORC table.
ERROR:
Error: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. work.rt can't be declared transactional because it's an external table (state=08S01,code=1)

Cette erreur se produit parce que la table rt est une table externe et que vous ne pouvez pas convertir la table externe en ACID.

Scénario 3

>>>> alter table rt set TBLPROPERTIES ('EXTERNAL'='false');
ERROR:
Error: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. Table work.rt failed strict managed table checks due to the following reason: Table is marked as a managed table but isn't transactional. (state=08S01,code=1)

Ici, nous essayons de remplacer d’abord la table externe par une table managée. Dans HDInsight 4.x, il doit s’agir d’une table strictement managée (ce qui signifie qu’elle doit être ACID). Vous obtenez donc un blocage. Pour convertir la table externe (NON_ACID) en managée (ACID) vous devez suivre la commande :

alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');

Syntaxe et sémantique

  • Création d’une table pour améliorer l’utilisation et les fonctionnalités, Hive 3 a modifié la création de table. Hive a modifié la création de table des manières suivantes

    • Crée une table conforme ACID, qui est la valeur par défaut dans HDP
    • Prend en charge les écritures et les insertions simples
    • Écrit dans plusieurs partitions
    • Insère plusieurs mises à jour de données dans une seule instruction SELECT
    • Ne nécessite pas de création de compartiments.

    Si vous avez un pipeline ETL qui crée des tables dans Hive, les tables sont créées en tant que ACID. Hive contrôle désormais étroitement l’accès et effectue un compactage périodique sur les tables

    Avant la mise à niveau Dans HDInsight 3.x, par défaut CREATE TABLE a créé une table non ACID.

    Après la mise à niveau Par défaut, CREATE TABLE crée une table transactionnelle ACID complète au format ORC.

    Action requise Pour accéder aux tables Hive ACID à partir de Spark, vous vous connectez à Hive à l’aide de Hive Warehouse Connector (HWC). Pour écrire des tables ACID dans Hive à partir de Spark, vous utilisez l’API HWC et HWC

  • Échapper aux références db.table

    Vous devez modifier les requêtes qui utilisent des références db.table pour empêcher Hive d’interpréter l’intégralité de la chaîne db.table comme nom de table. Hive 3.x rejette db.table dans les requêtes SQL. Un point (.) n’est pas autorisé dans les noms de table. Vous placez le nom de la base de données et le nom de la table dans des backticks. Recherchez une table contenant la référence de table problématique. math.students qui apparaît dans une instruction CREATE TABLE. Placez le nom de la base de données et le nom de la table dans des backticks.

    TABLE `math`.`students` (name VARCHAR(64), age INT, gpa DECIMAL(3,2));

  • CAST TIMESTAMPS Les résultats des applications qui castent des chiffres en horodatages diffèrent de Hive 2 à Hive 3. Apache Hive a modifié le comportement de CAST pour qu’il soit conforme à la norme SQL, qui n’associe pas de fuseau horaire au type TIMESTAMP.

    Avant la mise à niveau La conversion d’une valeur de type numérique en horodatage peut être utilisée pour produire un résultat qui reflète le fuseau horaire du cluster. Par exemple, 1597217764557 est 2020-08-12 00:36:04 PDT. L’exécution de la requête suivante convertit le numérique en horodatage dans PDT : SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 00:36:04 |

    Après la mise à niveau La conversion d’une valeur de type numérique dans un horodatage produit un résultat qui reflète l’UTC au lieu du fuseau horaire du cluster. L’exécution de la requête convertit le numérique en horodatage UTC. SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 07:36:04.557 |

    Action requise Modifier les applications. Ne pas effectuer de conversion à partir d’un chiffre pour obtenir un fuseau horaire local. Les fonctions intégrées from_utc_timestamp et to_utc_timestamp peuvent être utilisées pour imiter le comportement avant la mise à niveau.

  • VÉRIFICATION DE LA COMPATIBILITÉ DES MODIFICATIONS DE COLONNE Une modification de configuration par défaut peut entraîner l’échec des applications qui modifient les types de colonnes.

    Avant la mise à niveau Dans HDInsight 3.x Hive.metastore.disallow.incompatible.col.type.changes est false par défaut pour autoriser les modifications apportées aux types de colonnes incompatibles. Par exemple, vous pouvez remplacer une colonne STRING par une colonne d’un type incompatible, tel que MAP<STRING, STRING>. Aucune erreur ne se produit.

    Après la mise à niveau Hive.metastore.disallow.incompatible.col.type.changes a la valeur true par défaut. Hive empêche les modifications apportées aux types de colonnes incompatibles. Les modifications de type de colonne compatibles, telles que INT, STRING, BIGINT, ne sont pas bloquées.

    Action requise Modifiez les applications pour interdire les modifications de type de colonne incompatibles afin d’éviter toute altération possible des données.

  • SUPPRESSION DE PARTITIONS

    Les mots clés OFFLINE et NO_DROP dans la clause CASCADE pour la suppression de partitions entraînent des problèmes de performances et ne sont plus pris en charge.

    Avant la mise à niveau Vous pouvez utiliser des mots clés OFFLINE et NO_DROP dans la clause CASCADE pour empêcher la lecture ou la suppression de partitions.

    Après la mise à niveau OFFLINE et NO_DROP ne sont pas pris en charge dans la clause CASCADE.

    Action requise Modifiez les applications pour supprimer OFFLINE et NO_DROP de la clause CASCADE. Utilisez un schéma d’autorisation, tel que Ranger, pour empêcher la suppression ou la lecture de partitions.

  • RENOMMAGE D’UNE TABLE Après la mise à niveau Renommer une table managée déplace son emplacement uniquement si la table est créée sans clause LOCATION et se trouve sous son répertoire de base de données.

Limitations relatives à CBO

  • Nous constatons que la sortie de sélection donne des zéros de fin dans quelques colonnes. Par exemple, si nous avons une colonne de table avec le type de données décimal(38,4) et si nous insérons des données sous la forme 38, elle ajoute les zéros de fin et fournit le résultat sous la forme 38,0000 En fonction de https://issues.apache.org/jira/browse/HIVE-12063 et https://issues.apache.org/jira/browse/HIVE-24389, l’idée est conservée l’échelle et la précision au lieu d’exécuter un wrapper dans des colonnes décimales. Il s’agit du comportement par défaut de Hive 2. Pour résoudre ce problème, vous pouvez suivre l’option ci-dessous.

    1. Modifiez le type de données au niveau de la source pour ajuster la précision comme col1(decimal(38,0)). Cette valeur fournit le résultat 38 sans zéro de fin. Mais si vous insérez les données sous la forme 35.0005, il s’agit de .0005 et fournit uniquement la valeur 38 1.Supprimez les zéros de fin pour les colonnes présentant un problème, puis castez en chaîne,
      1. Utilisez select TRIM(cast(<column_name> AS STRING))+0 FROM <table_name>;
      2. Utiliser regex.

  1. La requête Hive échoue avec « Expression de sous-requête non prise en charge » lorsque nous utilisons UNIX_TIMESTAMP dans la requête. Par exemple, si nous exécutons une requête, elle génère une erreur « Expression de sous-requête non prise en charge »

    select * from
(SELECT col_1 from table1 where col_2 >= unix_timestamp('2020-03-07','yyyy-MM-dd'));

    Le cas racine de ce problème est que le codebase Hive actuel lève une exception qui analyse les UNIX_TIMESTAMP, car il n’existe aucun mappage de précision dans HiveTypeSystemImpl.java code pour la précision de UNIX_TIMESTAMP que Calcite reconnaît comme BIGINT. Mais la requête ci-dessous fonctionne correctement select * from (SELECT col_1 from table1 where col_2 >= 1);

    Cette commande s’exécute correctement, car col_2 est un entier. Le problème ci-dessus a été résolu dans hdi-3.1.2-4.1.12(4.1 stack) and hdi-3.1.2-5.0.8(5.0 stack)

Procédure de mise à niveau

1. Préparer les données

  • Par défaut, HDInsight 3.6 ne prend pas en charge les tables ACID. Toutefois, si des tables ACID sont présentes, exécutez la compression « MAJOR » dessus. Pour plus d’informations sur le compactage, consultez le Manuel d’utilisation du langage Hive.

  • Si vous utilisez Azure Data Lake Storage Gen1, les emplacements des tables Hive dépendent probablement des configurations HDFS du cluster. Exécutez l’action de script suivante pour rendre ces emplacements portables vers d’autres clusters. Consultez Action de script sur un cluster en cours d’exécution.

    Propriété Valeur
    URI de script bash https://hdiconfigactions.blob.core.windows.net/linuxhivemigrationv01/hive-adl-expand-location-v01.sh
    Type(s) de nœud Head
    Paramètres

2. Copier la base de données SQL

  • Si le cluster utilise un metastore Hive par défaut, suivez ce guide pour exporter des métadonnées vers un metastore externe. Ensuite, créez une copie du metastore externe pour la mise à niveau.

  • Si le cluster utilise un metastore Hive externe, créez-en une copie. Les options incluent l’exportation/importation et la limite de restauration dans le temps.

3. Mettre à niveau le schéma du metastore

Cette étape utilise Hive Schema Tool partir de HDInsight 4.0 pour mettre à niveau le schéma du metastore.

Avertissement

Cette étape est irréversible. Exécutez-la uniquement sur une copie du metastore.

  1. Créez un cluster HDInsight 4.0 temporaire pour accéder à Hive 4.0 schematool. Vous pouvez utiliser le metastore Hive par défaut pour cette étape.

  2. À partir du cluster HDInsight 4.0, exécutez schematool pour mettre à niveau le metastore HDInsight 3.6 cible. Modifiez le script d’interpréteur de commandes suivant pour ajouter votre nom de serveur SQL, le nom de la base de données, le nom d’utilisateur et le mot de passe. Ouvrez une session SSH sur le nœud principal et exécutez-la.

    SERVER='servername.database.windows.net'  # replace with your SQL Server
DATABASE='database'  # replace with your 3.6 metastore SQL Database
USERNAME='username'  # replace with your 3.6 metastore username
PASSWORD='password'  # replace with your 3.6 metastore password
STACK_VERSION=$(hdp-select status hive-server2 | awk '{ print $3; }')
/usr/hdp/$STACK_VERSION/hive/bin/schematool -upgradeSchema -url "jdbc:sqlserver://$SERVER;databaseName=$DATABASE;trustServerCertificate=false;encrypt=true;hostNameInCertificate=*.database.windows.net;" -userName "$USERNAME" -passWord "$PASSWORD" -dbType "mssql" --verbose

    Notes

    Cet utilitaire utilise le client beeline pour exécuter des scripts SQL dans /usr/hdp/$STACK_VERSION/hive/scripts/metastore/upgrade/mssql/upgrade-*.mssql.sql.

    La syntaxe SQL dans ces scripts n’est pas nécessairement compatible avec d’autres outils clients. Par exemple, SSMS et l’éditeur de requêtes sur le portail Azure requièrent le mot clé GO après chaque commande.

    Si un script échoue en raison de la capacité des ressources ou des délais d’expiration des transactions, effectuez un scale-up de SQL Database.

  3. Vérifiez la version finale avec la requête select schema_version from dbo.version.

    La sortie doit correspondre à celle de la commande bash suivante à partir du cluster HDInsight 4.0.

    grep . /usr/hdp/$(hdp-select --version)/hive/scripts/metastore/upgrade/mssql/upgrade.order.mssql | tail -n1 | rev | cut -d'-' -f1 | rev

  4. Supprimez le cluster HDInsight 4.0 temporaire.

4. Déployer un nouveau cluster HDInsight 4.0

Créez un nouveau cluster HDInsight 4.0, en sélectionnant le metastore Hive mis à niveau et les mêmes comptes de stockage.

  • Le nouveau cluster ne doit pas nécessairement avoir le même système de fichiers par défaut.

  • Si le metastore contient des tables résidant dans plusieurs comptes de stockage, vous devez ajouter ces comptes de stockage au nouveau cluster pour accéder à ces tables. Consultez Ajouter des comptes de stockage supplémentaires à HDInsight.

  • Si les travaux Hive échouent en raison d’une inaccessibilité du stockage, vérifiez que l’emplacement de la table se trouve dans un compte de stockage ajouté au cluster.

    Utilisez la commande Hive suivante pour identifier l’emplacement de la table :

    SHOW CREATE TABLE ([db_name.]table_name|view_name);

5. Convertir les tables pour la conformité ACID

Les tables managées doivent être compatibles ACID sur HDInsight 4.0. Exécutez strictmanagedmigration sur HDInsight 4.0 pour convertir toutes les tables managées non ACID en tables externes avec la propriété 'external.table.purge'='true'. Exécutez depuis le nœud principal :

sudo su - hive
STACK_VERSION=$(hdp-select status hive-server2 | awk '{ print $3; }')
/usr/hdp/$STACK_VERSION/hive/bin/hive --config /etc/hive/conf --service strictmanagedmigration --hiveconf hive.strict.managed.tables=true -m automatic --modifyManagedTables

6. Erreur de classe introuvable avec MultiDelimitSerDe

Problème

Au moment d’exécuter une requête Hive, il peut arriver que java.lang.ClassNotFoundException s’affiche, ce qui indique que la classe org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe est introuvable. Cette erreur se produit quand le client migre de HDInsight 3.6 vers HDInsight 4.0. La classe SerDe org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe, qui fait partie de hive-contrib-1.2.1000.2.6.5.3033-1.jar dans HDInsight 3.6, a été supprimée et nous utilisons désormais la classe org.apache.hadoop.hive.serde2.MultiDelimitSerDe, qui fait partie de hive-exec jar dans HDI-4.0. hive-exec jar se charge par défaut dans HS2 au moment où nous démarrons le service.

ÉTAPES DE RÉSOLUTION DES PROBLÈMES

  1. Vérifiez s’il existe un fichier JAR sous un dossier (il se trouve probablement sous le dossier des bibliothèques Hive, c’est-à-dire /usr/hdp/current/hive/lib dans HDInsight) qui contient ou non cette classe.
  2. Recherchez la classe org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe et org.apache.hadoop.hive.serde2.MultiDelimitSerDe comme indiqué dans la solution.

Solution

  1. Même si un fichier JAR est un fichier binaire, vous pouvez quand même utiliser la commande grep avec des commutateurs -Hrni comme ci-dessous pour rechercher un nom de classe déterminé

    grep -Hrni "org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe" /usr/hdp/current/hive/lib

  2. Si la classe est introuvable, aucune sortie n’est retournée. Si la classe est trouvée dans un fichier JAR, une sortie est retournée

  3. Voici l’exemple extrait du cluster HDInsight 4.x

    sshuser@hn0-alters:~$ grep -Hrni "org.apache.hadoop.hive.serde2.MultiDelimitSerDe" /usr/hdp/4.1.9.7/hive/lib/
Binary file /usr/hdp/4.1.9.7/hive/lib/hive-exec-3.1.0.4.1-SNAPSHOT.jar matches

  4. Au vu de la sortie ci-dessus, nous pouvons confirmer qu’aucun fichier jar ne contient la classe org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe et que le fichier jar hive-exec contient org.apache.hadoop.hive.serde2.MultiDelimitSerDe.

  5. Essayez de créer la table avec le format de ligne DerDe ROW FORMAT SERDE org.apache.hadoop.hive.serde2.MultiDelimitSerDe

  6. Cette commande corrige le problème. Si vous avez déjà créé la table, vous pouvez la renommer en utilisant les commandes ci-dessous

    Hive => ALTER TABLE TABLE_NAME SET SERDE 'org.apache.hadoop.hive.serde2.MultiDelimitSerDe'
Backend DB => UPDATE SERDES SET SLIB='org.apache.hadoop.hive.serde2.MultiDelimitSerDe' where SLIB='org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe';

La commande update vise à mettre à jour les détails manuellement dans la base de données back-end et la commande alter sert à modifier la table avec la nouvelle classe SerDe de beeline ou Hive.

Script de comparaison de schéma de base de données back-end Hive

Vous pouvez exécuter le script suivant une fois la migration terminée.

Il est possible qu’il manque quelques colonnes dans la base de données back-end, ce qui provoque des échecs de requête. Si la mise à niveau du schéma n’a pas eu lieu correctement, il est possible que nous puissions rencontrer le problème de nom de colonne non valide. Le script ci-dessous extrait le nom de colonne et le type de données de la base de données back-end du client et fournit la sortie en cas de colonne manquante ou de type de données incorrect.

Le chemin d’accès suivant contient le fichier schemacompare_final.py et test.csv. Le script est présent dans le fichier « schemacompare_final.py », et le fichier « test.csv » contient tout le nom de colonne et le type de données de toutes les tables, qui doivent être présents dans la base de données principale Hive.

https://hdiconfigactions2.blob.core.windows.net/hiveschemacompare/schemacompare_final.py

https://hdiconfigactions2.blob.core.windows.net/hiveschemacompare/test.csv

Téléchargez ces deux fichiers à partir du lien. Et copiez ces fichiers sur l’un des nœuds principaux où le service Hive est en cours d’exécution.

Étapes d’exécution du script :

Créez un répertoire appelé « schemacompare » sous le répertoire « /tmp ».

Placez « schemacompare_final.py » et « test.csv » dans le dossier « /tmp/schemacompare ». Effectuez « ls -ltrh /tmp/schemacompare/ » et vérifiez si les fichiers sont présents.

Pour exécuter le script Python, utilisez la commande « python schemacompare_final.py ». Ce script commence à exécuter le script et son exécution prend moins de cinq minutes. Le script ci-dessus se connecte automatiquement à votre base de données back-end et extrait les détails de chaque table, que Hive utilise et met à jour les détails dans le nouveau fichier csv appelé « return.csv ». Après avoir créé le fichier return.csv, il compare les données avec le fichier « test.csv » et imprime le nom de colonne ou le type de données s’il manque quelque chose sous le nom de la table.

Une fois après l’exécution du script, vous pouvez voir les lignes suivantes, qui indiquent que les détails sont extraits pour les tables et que le script est en cours

KEY_CONSTRAINTS
Details Fetched
DELEGATION_TOKENS
Details Fetched
WRITE_SET
Details Fetched
SERDES
Details Fetched

Et vous pouvez voir les détails de la différence sous la ligne « DÉTAILS DE LA DIFFÉRENCE : ». S'il y a une différence, elle se traduit par une impression

PART_COL_STATS;
('difference', ['BIT_VECTOR', 'varbinary'])
The line with semicolon PART_COL_STATS; is the table name. And under the table name you can find the differences as ('difference', ['BIT_VECTOR', 'varbinary']) if there are any difference in column or datatype.

S’il n’y a aucune différence dans la table, la sortie est

BUCKETING_COLS;
('difference', [])
PARTITIONS;
('difference', [])

À partir de cette sortie, vous pouvez trouver les noms de colonnes manquants ou incorrects. Vous pouvez exécuter la requête suivante dans votre base de données back-end pour vérifier une fois si la colonne est manquante ou non.

SELECT * FROM INFORMATION_SCHEMA.columns WHERE TABLE_NAME = 'PART_COL_STATS';

Dans le cas où l’une des colonnes est manquée dans la table, par exemple, si nous exécutons les requêtes comme insérer ou insérer un remplacement, les statistiques sont calculées automatiquement et il tente de mettre à jour la table des statistiques comme PART_COL_STATS et TAB_COL_STATS. Et si la colonne telle que « BIT_VECTOR » est manquante dans les tables, elle échoue avec l’erreur « Nom de colonne non valide ». Vous pouvez ajouter la colonne comme indiqué dans les commandes suivantes. En guise de solution de contournement, vous pouvez désactiver les statistiques en définissant les propriétés suivantes, qui ne peuvent pas mettre à jour les statistiques dans la base de données principale.

hive.stats.autogather=false;
hive.stats.column.autogather=false;
To Fix this issue, run the following two queries on backend SQL server (Hive metastore DB):

ALTER TABLE PART_COL_STATS ADD BIT_VECTOR VARBINARY(MAX);
ALTER TABLE TAB_COL_STATS ADD BIT_VECTOR VARBINARY(MAX);

Cette étape évite les échecs de requête, qui échouent avec « Nom de colonne non valide » une fois après la migration.

Sécuriser Hive sur les versions HDInsight

HDInsight s’intègre de manière facultative avec Microsoft Entra ID à l’aide du Pack Sécurité Entreprise (ESP) HDInsight. ESP utilise Kerberos et Apache Ranger à gérer les autorisations de ressources spécifiques au sein du cluster. Les stratégies Ranger déployées sur Hive dans HDInsight 3.6 peuvent être migrées vers HDInsight 4.0 en procédant comme suit :

  1. Accédez au panneau Ranger Service Manager dans votre cluster HDInsight 3.6.
  2. Accédez à la stratégie nommée HIVE et exportez la stratégie vers un fichier json.
  3. Assurez-vous que tous les utilisateurs référencés dans le fichier json de stratégie exporté existent dans le nouveau cluster. Si un utilisateur est référencé dans le fichier json de stratégie, mais n’existe pas dans le nouveau cluster, ajoutez l’utilisateur dans le nouveau cluster ou supprimez la référence de la stratégie.
  4. Accédez au panneau Ranger Service Manager de votre cluster HDInsight 4.0.
  5. Accédez à la stratégie nommée HIVE et importez le fichier json de stratégie Ranger de l’étape 2.

Modifications Hive dans HDInsight 4.0 qui peuvent nécessiter des modifications d’application

Consultez Annonce HDInsight 4.0 pour connaître les autres modifications.

Publiez la migration

Veillez à suivre ces étapes une fois la migration terminée.

Intégrité de la table

  1. Recréez des tables dans Hive 3.1 à l’aide de CTAS ou IOW pour modifier le type de table au lieu de modifier les propriétés de la table.
  2. Conservez la valeur doAs comme false.
  3. Vérifiez que la propriété de la table/des données managées est avec l’utilisateur « hive ».
  4. Utilisez des tables ACID managées si le format de table est ORC et managé non ACID pour les types non ORC.
  5. Régénérez les statistiques sur les tables recréées, car la migration aurait provoqué des statistiques incorrectes.

Intégrité des clusters

Si plusieurs clusters partagent le même stockage et la même base de données HMS, nous ne devons activer les threads de compactage/compactage automatique que dans un seul cluster et les désactiver partout ailleurs.

Paramétrez Metastore pour réduire son utilisation du processeur.

  1. Désactivez les écouteurs d’événements transactionnels.

    Notes

    Effectuez les étapes suivantes, uniquement si la fonctionnalité de réplication Hive n’est pas utilisée.

    1. À partir de l’interface utilisateur Ambari, supprimez la valeur de hive.metastore.transactional.event.listeners.
    2. Valeur par défaut : org.apache.hive.hcatalog.listener.DbNotificationListener
    3. Nouvelle valeur : <Empty>

  2. Désactiver Hive PrivilegeSynchronizer

    1. À partir de l’interface utilisateur Ambari, définissez hive.privilege.synchronizer = false.
    2. Valeur par défaut : true
    3. Nouvelle valeur : false

  3. Optimiser la fonctionnalité de réparation de partition

  4. Désactiver la réparation de partition : cette fonctionnalité est utilisée pour synchroniser les partitions des tables Hive à l’emplacement de stockage avec le metastore Hive. Vous pouvez désactiver cette fonctionnalité si « réparation msck » est utilisée après l’ingestion des données.

  5. Pour désactiver la fonctionnalité, ajoutez « discover.partitions=false » sous propriétés de table à l’aide de ALTER TABLE. OU (si la fonctionnalité ne peut pas être désactivée)

  6. Augmentez la fréquence de réparation de partition.

  7. À partir de l’interface utilisateur Ambari, augmentez la valeur de « metastore.partition.management.task.frequency » (en secondes).

    Notes

    Cette modification peut retarder la visibilité de certaines partitions ingérées dans le stockage.

    1. Valeur par défaut : 60
    2. Valeur proposée : 3600

  8. Optimisations avancées : Les options suivantes doivent être testées dans un environnement inférieur (non-production) avant d’être appliquées à la production.

    1. Supprimez l’écouteur lié à la vue matérialisée si la vue matérialisée n’est pas utilisée.
    2. À partir de l’interface utilisateur Ambari, ajoutez une propriété personnalisée (dans les hive-site.xml personnalisés) et supprimez les threads de metastore d’arrière-plan indésirables.
    3. Nom de la propriété : metastore.task.threads.remote
    4. Valeur par défaut : N/A (it uses few class names internally)
    5. Nouvelle valeur : org.apache.hadoop.hive.metastore.txn.AcidHouseKeeperService,org.apache.hadoop.hive.metastore.txn.AcidOpenTxnsCounterService,org.apache.hadoop.hive.metastore.txn.AcidCompactionHistoryService,org.apache.hadoop.hive.metastore.txn.AcidWriteSetService,org.apache.hadoop.hive.metastore.PartitionManagementTask

  9. Désactivez les threads d’arrière-plan si la réplication est désactivée.

    1. À partir de l’interface utilisateur Ambari, ajoutez une propriété personnalisée (dans les hive-site.xml personnalisées) et supprimez les threads indésirables.
    2. Nom de la propriété : metastore.task.threads.always
    3. Valeur par défaut : N/A (it uses few class names internally)
    4. Nouvelle valeur : org.apache.hadoop.hive.metastore.RuntimeStatsCleanerTask

Analyse de requêtes

  1. Conservez les configurations par défaut de Hive pour exécuter les requêtes à mesure qu’elles sont réglées pour les charges de travail TPC-DS. Besoin d’un réglage au niveau de la requête uniquement en cas d’échec ou d’exécution lente.
  2. Vérifiez que les statistiques sont à jour pour éviter un mauvais plan ou des résultats incorrects.
  3. Évitez de mélanger des tables ACID externes et managées dans le type de jointure de requêtes. Dans ce cas, essayez de convertir une table externe en table non ACID gérée par le biais d’une récréation.
  4. Dans Hive-3, beaucoup de travail s’est produit sur la vectorisation, le CBO, l’horodatage avec zone, etc., qui peut avoir des bogues de produit. Par conséquent, si une requête donne des résultats incorrects, essayez de désactiver la vectorisation, le CBO, la jonction de carte, etc., pour voir si cela vous aide.

Autres étapes à suivre pour corriger les résultats incorrects et les performances médiocres après la migration

  1. Problème La requête Hive donne le résultat incorrect. Même la requête select count(*) donne le résultat incorrect.

    Cause Par défaut, la propriété « hive.compute.query.using.stats » a la valeur true. Si nous lui affectons la valeur true, elle utilise les statistiques, qui sont stockées dans le metastore pour exécuter la requête. Si les statistiques ne sont pas à jour, cela entraîne des résultats incorrects.

    Résolution Collectez les statistiques des tables managées à l’aide de la commande alter table <table_name> compute statics; au niveau de la table et de la colonne. Lien de référence : https://cwiki.apache.org/confluence/display/hive/statsdev#StatsDev-TableandPartitionStatistics

  2. Problème L’exécution des requêtes Hive prend beaucoup de temps.

    Cause Si la requête a une condition de jointure, Hive crée un plan pour utiliser la jointure de mappage ou la jointure de fusion en fonction de la taille de la table et de la condition de jointure. Si l’une des tables contient une petite taille, elle charge cette table dans la mémoire et effectue l’opération de jointure. De cette façon, l’exécution de la requête est plus rapide par rapport à la jointure de fusion.

    Résolution Veillez à définir la propriété « hive.auto.convert.join=true », qui est la valeur par défaut. La définition de la valeur false utilise la jointure de fusion et peut entraîner des performances médiocres. Hive décide d’utiliser ou non la jointure de carte en fonction des propriétés suivantes, qui sont définies dans le cluster

    set hive.auto.convert.join=true;
set hive.auto.convert.join.noconditionaltask=true;
set hive.auto.convert.join.noconditionaltask.size=<value>;
set hive.mapjoin.smalltable.filesize = <value>;

    La jointure commune peut être convertie automatiquement en jointure de carte, lorsque hive.auto.convert.join.noconditionaltask=true, si la taille estimée de la ou des petites tables est inférieure à Hive.auto.convert.join.noconditionaltask.size (La valeur par défaut est 10000000 Mo).

    Si vous rencontrez un problème lié à OOM en définissant la propriété hive.auto.convert.join sur true, il est recommandé de la définir sur false uniquement pour cette requête particulière au niveau de la session et non au niveau du cluster. Ce problème peut se produire si les statistiques sont incorrectes et Hive décide d’utiliser la jonction de carte en fonction des statistiques.

  • Problème La requête Hive donne le résultat incorrect si la requête a une condition de jointure et que les tables impliquées ont des valeurs null ou vides.

    Cause Parfois, nous pouvons rencontrer un problème lié aux valeurs Null si les tables impliquées dans la requête ont beaucoup de valeurs Null. Hive effectue l’optimisation de la requête de manière incorrecte avec les valeurs Null impliquées, ce qui entraîne des résultats incorrects.

    Résolution Nous vous recommandons de définir la propriété set hive.cbo.returnpath.hiveop=true au niveau de la session si vous obtenez des résultats incorrects. Cette configuration introduit un filtrage non null sur les clés de jointure. Si les tables avaient de nombreuses valeurs Null, pour optimiser l’opération de jointure entre plusieurs tables, nous pouvons activer cette configuration afin qu’elle ne considère que les valeurs non null.

  • Problème La requête Hive donne le résultat incorrect si la requête a plusieurs conditions de jointure.

    Cause Parfois, Tez produit des plans d’exécution incorrects chaque fois qu’il y a des jointures identiques plusieurs fois avec des jointures de carte.

    Résolution Il existe un risque d’obtenir des résultats incorrects lorsque nous définissons hive.merge.nway.joins sur false. Essayez de la définir sur true uniquement pour la requête qui a été affectée. Cela permet d’interroger plusieurs jointures dans la même condition, de fusionner les jointures en un seul opérateur de jointure. Cette méthode est utile si des jointures aléatoires volumineuses évitent une phase de remaniement.

  • Problème Le temps d’exécution de la requête augmente jour après jour par rapport aux exécutions précédentes.

    Cause Ce problème peut se produire en cas d’augmentation du nombre de petits fichiers. Hive prend donc du temps à lire tous les fichiers pour traiter les données, ce qui entraîne une augmentation du temps d’exécution.

    Résolution Veillez à exécuter le compactage fréquemment pour les tables, qui sont gérées. Cette étape évite les petits fichiers et améliore les performances.

    Lien de référence : Transactions Hive - Apache Hive - Apache Software Foundation.

  • Problème La requête Hive donne un résultat incorrect lorsque le client utilise une condition de jointure sur une table orc acide managée et une table orc non ACID managée.

    Cause À partir de HIVE 3, il est strictement demandé de conserver toutes les tables gérées sous forme de table acide. Et si nous voulons le conserver sous forme de table acide, le format de la table doit être orc et c’est le critère main. Toutefois, si nous désactivons la propriété de table managée stricte « hive.strict.managed.tables » sur false, nous pouvons créer une table managée non ACID. Dans certains cas, le client crée une table ORC externe ou, après la migration, la table est convertie en table externe et désactive la propriété de table managée stricte et la convertit en table managée. À ce stade, la table a été convertie au format orc non géré par ACID.

    Résolution L’optimisation Hive se produit mal si vous joignez une table avec une table ORC non managée ACID à une table ORC managée ACID.

    Si vous convertissez une table externe en table managée,

    1. Ne définissez pas la propriété « hive.strict.managed.tables » sur false. Si vous définissez, vous pouvez créer une table managée non ACID, mais elle n’est pas demandée dans HIVE-3
    2. Convertir la table externe en table managée à l’aide de la commande alter suivante au lieu de alter table <table_name> set TBLPROPERTIES ('EXTERNAL'='false');
    alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');

Guide de résolution des problèmes

Le Guide de dépannage de HDInsight 3.6 à 4.0 pour les charges de travail Hive fournit des réponses aux problèmes courants rencontrés lors de la migration de charges de travail Hive de HDInsight 3.6 vers HDInsight 4.0.

Pour aller plus loin