Introduction
Une application par lots utile doit s’exécuter depuis un programme enregistré avec des entrées et sorties explicites, sans dépendre d’un DataFrame ou d’une vue temporaire laissé dans une session précédente. Vous soumettrez un programme préparé de ventes quotidiennes dans des processus séparés et vérifierez ses résultats enregistrés ainsi que ses preuves d’exécution.
spark-submit est le lanceur d’applications Spark. Vous lui donnerez le master d’exécution, le programme Python et les arguments d’entrée et de sortie du programme. Le script laisse volontairement ce paramètre master externe contrôler l’exécution. Sa logique de rapport reprend la lecture typée, le filtre payé, le montant décimal et le regroupement déjà appris ; l’analyse des arguments est fournie pour vous permettre de vous concentrer sur la soumission et les relances sans risque.
Ce lab indépendant fournit deux livraisons CSV valides et le programme complet. Vous examinerez les journaux et codes de sortie, changerez le chemin d’entrée et distinguerez une entrée manquante d’un conflit de sortie existante. Aucun cluster distant, empaquetage, ordonnanceur, Hive ou état de processus précédent n’est nécessaire. Utilisez le Terminal.
Soumettre un programme préparé avec des arguments explicites
Dans cette étape, vous traiterez la première livraison avec une application autonome. Examinez la source et le programme fourni :
cd /home/labex/project
cat /home/labex/project/data/orders.csv
cat /home/labex/project/sales_batch.py
L’analyseur accepte déjà input_path, output_path et l’option --overwrite. Vous n’avez pas besoin de mettre en œuvre argparse. Le premier chemin positionnel est toujours l’entrée et le second la sortie. Le générateur SparkSession n’appelle pas master ; le paramètre --master du lanceur contrôle donc l’exécution.
Lisez la commande de gauche à droite : les options de spark-submit précèdent le nom de fichier Python ; les arguments après ce nom vont à l’application. Entourez local[2] d’apostrophes pour que le shell traite ses crochets littéralement. > enregistre la sortie ordinaire et 2>&1 envoie la sortie d’erreur au même journal :
spark-submit --master 'local[2]' /home/labex/project/sales_batch.py /home/labex/project/data/orders.csv /home/labex/project/output/run-1 > /home/labex/project/output/run-1-job.log 2>&1
Recueillez immédiatement le code de sortie avant d’exécuter une autre commande du terminal. $? est le statut de la commande précédente : zéro signifie réussite, et une valeur non nulle échec. printf écrit cette valeur et un saut de ligne dans un fichier local de statut :
printf '%s\n' "$?" > /home/labex/project/output/run-1-exit-status.txt
cat /home/labex/project/output/run-1-exit-status.txt
Vous devez obtenir 0. Lisez la fin du journal du pilote :
tail -n 30 /home/labex/project/output/run-1-job.log
Trouvez Master: local[2], le véritable identifiant d’application, les chemins d’entrée et de sortie sélectionnés et les dates du rapport. L’identifiant varie. Le rapport doit montrer 14 octobre / 2 / 45.00 et 15 octobre / 2 / 80.00. Un code de sortie zéro accompagné d’un véritable résultat Parquet correct est une preuve plus solide qu’une ligne de journal rassurante.
Le programme crée et arrête sa propre session. Il n’a réutilisé ni les vues ni les variables Python de la leçon précédente.
Changer l’entrée dans un nouveau processus
Dans cette étape, vous prouverez que le programme produit son résultat à partir du chemin fourni. Examinez la seconde livraison :
cat /home/labex/project/data/new-orders.csv
Elle contient deux commandes payées le 16 octobre, de montants 30.00 et 25.00, ainsi qu’une commande en attente. Prévoyez une ligne de rapport : nombre 2 et revenu 55.00. Conservez la première sortie et soumettez ce nouveau fichier vers une destination séparée :
spark-submit --master 'local[2]' /home/labex/project/sales_batch.py /home/labex/project/data/new-orders.csv /home/labex/project/output/run-2 > /home/labex/project/output/run-2-job.log 2>&1
printf '%s\n' "$?" > /home/labex/project/output/run-2-exit-status.txt
cat /home/labex/project/output/run-2-exit-status.txt
tail -n 30 /home/labex/project/output/run-2-job.log
Vous devez obtenir le statut 0 et le résultat prévu du 16 octobre. Son véritable identifiant d’application diffère de celui du premier processus. Le programme a chargé le nouveau chemin et créé sa propre session ; aucune vue restante n’était requise.
run-1 et run-2 restent tous deux disponibles, ce qui rend vérifiable la relation entre chaque entrée et son résultat. Ne modifiez pas le fichier source simplement pour faire apparaître une réponse mémorisée.
Diagnostiquer séparément une entrée manquante et une sortie existante
Dans cette étape, vous enregistrerez deux échecs de chemins distincts sans supprimer de données. Soumettez d’abord une entrée inexistante. La commande suivante doit échouer.
spark-submit --master 'local[2]' /home/labex/project/sales_batch.py /home/labex/project/data/missing-orders.csv /home/labex/project/output/unused-missing-input > /home/labex/project/output/missing-input.log 2>&1
Recueillez son statut immédiatement, avant d’examiner le journal :
printf '%s\n' "$?" > /home/labex/project/output/missing-input-exit-status.txt
cat /home/labex/project/output/missing-input-exit-status.txt
tail -n 25 /home/labex/project/output/missing-input.log
Vous devez obtenir un statut non nul et un diagnostic de chemin introuvable nommant missing-orders.csv. Corriger le chemin d’entrée résout ce problème ; changer le master ou recréer un cluster ne le résout pas.
Le mode par défaut errorifexists du script protège aussi une destination existante. Essayez l’entrée connue avec le chemin run-1 déjà terminé. La commande suivante doit échouer.
spark-submit --master 'local[2]' /home/labex/project/sales_batch.py /home/labex/project/data/orders.csv /home/labex/project/output/run-1 > /home/labex/project/output/existing-output.log 2>&1
printf '%s\n' "$?" > /home/labex/project/output/existing-output-exit-status.txt
cat /home/labex/project/output/existing-output-exit-status.txt
tail -n 25 /home/labex/project/output/existing-output.log
Vous devez obtenir un statut non nul et un diagnostic de sortie déjà existante. Cela diffère d’une entrée manquante, et le rapport précédent réussi doit rester intact.
Effectuez une réparation qui préserve les résultats en utilisant la bonne source et un nouveau répertoire de sortie :
spark-submit --master 'local[2]' /home/labex/project/sales_batch.py /home/labex/project/data/orders.csv /home/labex/project/output/run-3 > /home/labex/project/output/run-3-job.log 2>&1
printf '%s\n' "$?" > /home/labex/project/output/run-3-exit-status.txt
cat /home/labex/project/output/run-3-exit-status.txt
tail -n 25 /home/labex/project/output/run-3-job.log
Vous devez obtenir une réussite et les deux totaux quotidiens originaux. Une nouvelle destination conserve les deux livraisons précédentes et les preuves d’échec, sans retirer les fichiers bruts ni de grandes arborescences de sortie.
Reconstruire explicitement un instantané dérivé prévu
Dans cette étape, vous choisirez délibérément le remplacement pour un instantané complet connu. L’argument facultatif --overwrite est déjà mis en œuvre : il change uniquement le mode d’écriture de destination de ce programme en overwrite. Il ne modifie ni l’entrée, ni les autres chemins de résultats, ni le master externe de Spark.
Utilisez-le lorsque votre intention est de reconstruire tout le résultat dérivé indiqué à partir de la même source. Ici, run-1 est cet instantané connu ; les autres exécutions et les entrées brutes restent séparées :
spark-submit --master 'local[2]' /home/labex/project/sales_batch.py /home/labex/project/data/orders.csv /home/labex/project/output/run-1 --overwrite > /home/labex/project/output/overwrite-job.log 2>&1
printf '%s\n' "$?" > /home/labex/project/output/overwrite-exit-status.txt
cat /home/labex/project/output/overwrite-exit-status.txt
tail -n 30 /home/labex/project/output/overwrite-job.log
Vous devez obtenir le statut 0, Write mode: overwrite et les deux mêmes lignes de rapport. Ce nouveau processus remplace l’instantané au lieu d’ajouter des dates en double. Son identifiant d’application diffère de celui de la première exécution, et son journal possède son propre nom de fichier.
Vous avez pratiqué deux réponses valides à une sortie existante : choisir un nouveau chemin lorsque conserver les deux versions compte, ou reconstruire explicitement un instantané dérivé connu lorsque le remplacement est prévu. Les erreurs de chemin d’entrée exigent toujours une entrée correcte ; l’écrasement ne répare pas des données manquantes. Ces habitudes de soumission et de relance vous préparent au défi final de pipeline de ventes réutilisable.
Résumé
Vous avez lancé une application Spark paramétrée dans des processus indépendants, recueilli les véritables statuts et journaux et vérifié les résultats pour différentes entrées. Vous avez distingué une entrée manquante d’un conflit de sortie existante et choisi soit une nouvelle destination, soit un remplacement explicite d’instantané. Le défi final combine maintenant ces habitudes de soumission avec nettoyage, enrichissement, agrégation et sortie partitionnée.
