Introduction
Un lieu associatif conserve ses visites confirmées dans une archive Hive. Une correction approuvée remplace l’ensemble complet des visites confirmées d’une date. Ce n’est pas un correctif à ajouter aux lignes d’hier. Une date approuvée compte désormais deux visites confirmées ; une autre n’en compte aucune. Les autres dates, y compris une visite ajoutée plus tard, doivent rester intactes.
Vous comparerez l’ajout et le remplacement dans des tables d’essai jetables, puis enregistrerez et exécuterez un fichier SQL au périmètre précis sur la véritable archive ORC. Vous répéterez aussi ce fichier et relirez le résultat. L’environnement exécute déjà Hive et HDFS et contient des données brutes, des corrections candidates et une archive indépendantes.
Vous devez déjà connaître les tables externes Hive, SELECT avec WHERE, les colonnes de partition, ORC et les chemins HDFS de base. Ce laboratoire présente les partitions de destination statiques et le remplacement complet d’une date. Tout se déroule dans l’onglet Terminal. Les 65 minutes sont une estimation de l’auteur incluant la lecture et les erreurs courantes.
Comparez sans risque l’ajout et le remplacement
Dans cette étape, vous lirez une journée normale de l’archive, puis comparerez trois périmètres d’écriture dans des tables d’essai jetables. Ne modifiez pas la véritable archive pendant cette comparaison.
Ouvrez Terminal. Utilisez l’espace de travail préparé tout au long du laboratoire :
cd /home/labex/project
Le répertoire local venue contient des fichiers CSV de référence et une liste d’approbation. cat affiche un fichier sans le modifier :
cat venue/approved-days.txt
2026-10-02
2026-10-03
Ce sont les seules dates de la véritable archive que vous pouvez remplacer. Lisez d’abord une journée normale. Beeline envoie du SQL à HiveServer2. Dans la commande ci-dessous, -u fournit l’adresse de connexion JDBC, -n labex le nom d’utilisateur du client et -e le texte SQL. Les guillemets doubles regroupent ce texte en un seul argument du shell ; les apostrophes à l’intérieur délimitent les valeurs SQL. DATE '...' rend le type de date explicite.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT * FROM venue_archive.archive WHERE visit_date=DATE '2026-10-04' ORDER BY visit_id;"
Lisez les lignes de données sous les éventuels messages de démarrage. La date contient v4 / Music / 4 et v5 / LateWalk / 2. La visite ajoutée plus tard, v5, est valide et doit rester. L’image peut afficher des messages SLF4J concernant plusieurs liaisons de journalisation ; ils sont distincts des erreurs SQL. Attendez le retour de l’invite avant de continuer.
Inspectez maintenant toute la source candidate, y compris les enregistrements annulés :
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT * FROM venue_archive.candidate ORDER BY visit_date,visit_id;"
Le 2 octobre contient c21 / PrintWorkshop / 5 et c22 / Bookbinding / 2, tous deux confirmed. Le 3 octobre contient une ligne cancelled. L’archive ne conserve que les lignes confirmed ; le remplacement du 3 octobre est donc légitimement un ensemble vide. L’absence d’une date dans un résultat filtré ne signifie pas « laisser intacte l’ancienne date de l’archive ». L’approbation et le filtre des lignes confirmées répondent à deux questions différentes.
Vérifiez où les trois tables réelles lisent et écrivent. DESCRIBE FORMATTED ajoute les métadonnées de stockage aux définitions de colonnes : repérez Table Type, Location et InputFormat dans chaque résultat. La longue sortie contient aussi des détails du moteur ; concentrez-vous sur ces champs avant toute écriture.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "DESCRIBE FORMATTED venue_archive.raw; DESCRIBE FORMATTED venue_archive.candidate; DESCRIBE FORMATTED venue_archive.archive;"
Les trois sont des objets EXTERNAL_TABLE. L’emplacement brut est hdfs://localhost:9000/user/labex/venue-archive/raw ; l’emplacement candidat se termine par /user/labex/venue-archive/candidate. Tous deux utilisent une entrée texte. L’archive se trouve à hdfs://localhost:9000/warehouse/external/venue_archive.db/archive et son format d’entrée se termine par OrcInputFormat. Les fichiers locaux venue/*.csv sont des copies de référence, pas l’archive. Conservez les correspondances et les fichiers sources fournis.
Avant de modifier la véritable archive, utilisez deux tables jetables : practice_days possède des partitions par date ; practice_whole stocke la date dans une colonne ordinaire. Elles contiennent au départ les visites confirmées brutes. Les commandes suivantes montrent volontairement des résultats incorrects uniquement sur ces tables d’essai.
INSERT INTO ajoute des lignes. PARTITION(visit_date='2026-10-02') désigne une partition de destination statique : la date littérale choisit où vont toutes les lignes sélectionnées. Le SELECT doit donc renvoyer uniquement les trois colonnes hors partition. Sa condition WHERE, distincte, choisit les lignes sources. Nommer la destination ne filtre pas automatiquement la source.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT INTO TABLE venue_archive.practice_days PARTITION(visit_date='2026-10-02') SELECT visit_id,activity,visitors FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed'; SELECT * FROM venue_archive.practice_days WHERE visit_date=DATE '2026-10-02' ORDER BY visit_id;"
Le résultat contient c21, c22 et l’ancien v2. Le SQL a réussi, mais le contrat de remplacement n’est pas respecté. Ajouter encore la même correction créerait davantage de doublons.
INSERT OVERWRITE remplace les lignes existantes de la destination. Dans la table non partitionnée practice_whole, la destination est la table entière. Observez la disparition des autres dates :
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT OVERWRITE TABLE venue_archive.practice_whole SELECT visit_id,activity,visitors,visit_date FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed'; SELECT * FROM venue_archive.practice_whole ORDER BY visit_date,visit_id;"
Il ne reste que les deux lignes du 2 octobre. Une écriture réussie sur toute une table peut perdre discrètement des dates sans rapport. Restaurez cette table jetable depuis sa source brute complète :
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT OVERWRITE TABLE venue_archive.practice_whole SELECT visit_id,activity,visitors,visit_date FROM venue_archive.raw WHERE record_status='confirmed'; SELECT * FROM venue_archive.practice_whole ORDER BY visit_date,visit_id;"
Les cinq lignes originales reviennent. Combinez enfin OVERWRITE avec une partition de date statique sur practice_days :
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT OVERWRITE TABLE venue_archive.practice_days PARTITION(visit_date='2026-10-02') SELECT visit_id,activity,visitors FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed'; SELECT * FROM venue_archive.practice_days ORDER BY visit_date,visit_id;"
Il y a six lignes : le 1er octobre original, les deux lignes corrigées du 2 octobre, le 3 octobre original et les deux visites du 4 octobre. L’ancien v2 a disparu. C’est le périmètre d’écriture nécessaire pour la véritable archive.
Si Beeline signale un nom de table invalide, le SQL n’a pas trouvé l’objet prévu. Vérifiez l’orthographe avec la commande en lecture seule déjà connue ci-dessous, puis relancez votre commande corrigée. Pour une erreur de chemin, utilisez pwd et ls venue ; revenez avec la commande cd ci-dessus. Ne recréez pas les tables et ne relancez pas la préparation de l’environnement pour corriger une faute de frappe.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SHOW TABLES IN venue_archive;"
Avant de vérifier cette étape, assurez-vous que la partition d’essai contient exactement c21 et c22 le 2 octobre, que la table d’essai complète a retrouvé ses cinq lignes originales et que la véritable archive conserve ses données initiales.
Remplacez la date approuvée contenant des visites confirmées
Dans cette étape, vous enregistrerez et exécuterez le véritable remplacement du 2 octobre. Continuez dans Terminal, depuis /home/labex/project.
La table réelle venue_archive.archive est une table ORC externe et non transactionnelle, partitionnée par visit_date DATE. Ses sources brute et candidate sont des tables externes indépendantes de texte délimité par des virgules. Vous pouvez remplacer uniquement les dates approuvées de l’archive : ne modifiez pas les fichiers sources, les définitions ou emplacements des tables, ne réaffectez pas les partitions, ne créez pas de dates supplémentaires et ne reconstruisez pas toute l’archive. Les 1er et 4 octobre doivent conserver leurs données originales et leurs fichiers HDFS existants. Réécrire des lignes identiques dépasse également le périmètre approuvé.
Inspectez la liste des partitions et la disposition des colonnes avant d’écrire. SHOW PARTITIONS liste les partitions de date enregistrées ; DESCRIBE affiche les colonnes ordinaires, puis les informations de partition :
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SHOW PARTITIONS venue_archive.archive; DESCRIBE venue_archive.archive;"
Les quatre dates vont du 1er au 4 octobre. Les colonnes ordinaires sont visit_id STRING, activity STRING et visitors INT ; visit_date DATE est la colonne de partition. Gardez cette correspondance et le format ORC intacts.
Enregistrez votre SQL dans un fichier modifiable pour pouvoir inspecter, corriger et répéter la même opération. nano est un éditeur de texte dans Terminal. La commande suivante ouvre replace-approved-days.sql dans l’espace de travail courant ; comme il s’agit d’un nouveau fichier, sa zone de modification est initialement vide :
nano replace-approved-days.sql
Saisissez les cinq lignes SQL suivantes dans nano, et non à l’invite du shell. Les apostrophes délimitent les valeurs SQL et le point-virgule termine l’instruction. Arrêtez-vous après le dernier point-virgule sans ajouter de ligne vide ; nano fournit le saut de ligne final lors de l’enregistrement :
INSERT OVERWRITE TABLE venue_archive.archive
PARTITION(visit_date='2026-10-02')
SELECT visit_id,activity,visitors
FROM venue_archive.candidate
WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed';
Utilisez les flèches pour atteindre un caractère à corriger ; Home et End vont au début et à la fin de la ligne courante. Backspace supprime le caractère à gauche du curseur ; Delete supprime celui sous le curseur. Saisissez le texte corrigé à sa place. Le pied de page de nano utilise ^ pour désigner Ctrl. Appuyez sur Ctrl+O pour enregistrer : à File Name to Write, gardez le nom affiché et appuyez sur Enter. Appuyez ensuite sur Ctrl+X pour quitter. Attendez le retour de l’invite du shell ; le SQL se saisit dans l’éditeur, tandis que les commandes suivantes se saisissent à cette invite.
Lisez le contenu enregistré avant de l’exécuter :
cat replace-approved-days.sql
Vérifiez les deux dates de l’instruction : la destination statique et le filtre source sont tous deux le 2 octobre. La correction représente l’ensemble confirmé complet, avec c21 et c22. Il n’est pas nécessaire de rechercher les anciens identifiants ni de mettre à jour chaque ligne.
L’option -f de Beeline lit le SQL depuis un fichier. Exécutez le fichier enregistré :
beeline -u jdbc:hive2://localhost:10000/default -n labex -f replace-approved-days.sql
Lisez ensuite les quatre dates comme le ferait un utilisateur des données :
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT visit_date,visit_id,activity,visitors FROM venue_archive.archive ORDER BY visit_date,visit_id;"
Vous devez obtenir six lignes. Le 2 octobre contient c21 / PrintWorkshop / 5 et c22 / Bookbinding / 2, sans v2. Le 3 octobre conserve encore l’ancien v3. Le v1 du 1er octobre ainsi que v4 et v5 du 4 octobre restent inchangés.
La connexion Beeline vous identifie comme labex. HiveServer2 effectue les écritures de stockage avec son utilisateur de service hive ; les nouveaux fichiers ORC peuvent donc appartenir à hive:bigdata. Vous n’avez pas à modifier leurs propriétaires ou permissions. Le NameNode HDFS utilise sa propre identité de service hdfs.
Si une instruction SQL comporte une erreur de syntaxe, inspectez le fichier enregistré avec cat, puis rouvrez-le avec nano replace-approved-days.sql. Utilisez les flèches pour repérer l’instruction nommée dans l’erreur Beeline. Corrigez au besoin le nom de table, les dates, les apostrophes ou le point-virgule, en conservant les autres lignes SQL. Enregistrez avec Ctrl+O, Enter, puis quittez avec Ctrl+X. Relisez le fichier avant de relancer -f. Si vous avez ajouté des lignes par erreur à cette date approuvée, la même réécriture correcte de partition supprime les lignes obsolètes et les doublons. Cette récupération concerne la date approuvée ; elle n’autorise pas à reconstruire une date protégée.
Appliquez un remplacement par un ensemble vide et répétez le fichier
Dans cette étape, vous viderez la partition approuvée du 3 octobre, puis exécuterez deux fois le fichier de correction complet pour vérifier que l’archive n’accumule pas de lignes. Continuez dans Terminal, depuis /home/labex/project.
Une annulation constitue aussi une correction. La liste d’approbation inclut le 3 octobre, mais son candidat ne contient aucune visite confirmée. Exécutez d’abord la sélection source :
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT visit_id,activity,visitors FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-03' AND record_status='confirmed';"
Aucune ligne de données n’est renvoyée. L’archive finale correcte ne doit pas non plus avoir de lignes pour cette date. Omettre l’écriture laisserait l’ancien v3.
Rouvrez le même fichier. Conservez l’instruction du 2 octobre existante ; vous ajouterez une instruction, sans recopier la première :
nano replace-approved-days.sql
Utilisez la flèche vers le bas pour atteindre la ligne vide après le point-virgule de la première instruction, et End si nécessaire pour atteindre la fin de cette ligne. Sur cette ligne vide, appuyez une fois sur Enter pour laisser une ligne vide entre les instructions. Saisissez ensuite uniquement les cinq nouvelles lignes ci-dessous. Arrêtez-vous après le dernier point-virgule sans ajouter de ligne vide. Si vous reprenez une modification interrompue, vérifiez d’abord si l’instruction du 3 octobre est déjà présente ; corrigez-la au lieu d’ajouter un doublon.
INSERT OVERWRITE TABLE venue_archive.archive
PARTITION(visit_date='2026-10-03')
SELECT visit_id,activity,visitors
FROM venue_archive.candidate
WHERE visit_date=DATE '2026-10-03' AND record_status='confirmed';
Enregistrez avec Ctrl+O, Enter, puis quittez avec Ctrl+X. Lisez le fichier enregistré complet à l’invite du shell :
cat replace-approved-days.sql
Vérifiez qu’il contient exactement deux instructions : celle du 2 octobre d’origine, suivie de la nouvelle instruction du 3 octobre. Dans chacune, la destination statique et le filtre source doivent tous deux désigner la date approuvée de cette instruction. En cas d’erreur, rouvrez le même fichier dans nano, corrigez uniquement les lignes concernées, puis enregistrez et inspectez-le à nouveau.
Exécutez une première fois ce fichier complet enregistré :
beeline -u jdbc:hive2://localhost:10000/default -n labex -f replace-approved-days.sql
Une réécriture statique dont la sélection est vide supprime les anciennes lignes de la partition de destination. La date reste enregistrée. Le moteur de stockage décide si une partition vide contient des fichiers physiques ; ne créez pas vous-même de fichiers CSV ou ORC de remplissage.
Lisez les dates enregistrées et le résultat complet :
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SHOW PARTITIONS venue_archive.archive; SELECT visit_date,visit_id,activity,visitors FROM venue_archive.archive ORDER BY visit_date,visit_id; SELECT COUNT(*) FROM venue_archive.archive WHERE visit_date=DATE '2026-10-03';"
Les quatre partitions figurent toujours dans la liste. Le résultat complet comprend cinq lignes : v1, c21, c22, v4 et v5. Le nombre de lignes du 3 octobre vaut 0. Deux dates dans une liste d’approbation n’impliquent pas deux partitions contenant des données.
Exécutez maintenant à nouveau le même fichier enregistré, sans le modifier :
beeline -u jdbc:hive2://localhost:10000/default -n labex -f replace-approved-days.sql
Répétez la lecture des données :
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT visit_date,visit_id,activity,visitors FROM venue_archive.archive ORDER BY visit_date,visit_id; SELECT COUNT(*) FROM venue_archive.archive;"
Les mêmes cinq lignes restent présentes et le total vaut 5. Ce remplacement est répétable pour les sources fournies : il n’ajoute pas de doublons. Une répétition peut recréer les fichiers des partitions approuvées, tandis que les fichiers originaux des autres dates doivent rester intacts.
Vous pouvez inspecter la source brute avec les commandes HDFS déjà connues. Ici, -cat lit le fichier source exact, pas l’archive ORC dérivée :
hdfs dfs -cat /user/labex/venue-archive/raw/raw.csv
Il contient encore les originaux v2 et v3. Modifier une archive dérivée ne réécrit pas son historique brut. Le candidat et la liste d’approbation doivent également rester tels qu’ils ont été fournis. Conservez votre fichier SQL dans l’espace de travail. Les vérifications observent les données Hive, les définitions, le périmètre et les fichiers protégés actuels ; elles n’exécutent pas n’importe quel SQL enregistré. Votre répétition réelle et vos lectures du résultat constituent l’autovérification de l’opération enregistrée.
Résumé
Vous avez comparé l’ajout, le remplacement d’une table entière et le remplacement d’une partition statique. Vous avez ensuite remplacé l’ensemble complet d’une journée approuvée, appliqué un remplacement légitime par un ensemble vide et répété le même SQL enregistré sans accumuler de lignes. L’historique brut indépendant et les autres dates de l’archive sont restés intacts.
