Migration de tâches AWS Glue pour Spark vers AWS Glue version 4.0

Elle est basée sur Apache Spark 3.3.0, mais propose des optimisations dans AWS Glue et Amazon EMR, telles que les exécutions adaptatives de requêtes, les lecteurs vectorisés, les remaniements optimisées et la fusion de partitions.

Pilotes JDBC mis à niveau pour toutes les sources natives de AWS Glue, y compris MySQL, Microsoft SQL Server, Oracle, PostgreSQL, MongoDB, ainsi que les dépendances et les bibliothèques Spark mises à niveau, introduites par Spark 3.3.0.

Utilisation d'un nouveau connecteur Amazon Redshift et d'un nouveau pilote JDBC.

Accès optimisé à Amazon S3 avec EMRFS (système de fichiers EMR) mis à niveau et validateurs de sortie optimisés Amazon S3 activés par défaut.

Accès optimisé au catalogue de données avec des index de partition, le déploiement des prédicats, une liste de partitions et un client de métastore Hive mis à niveau.

Intégration à Lake Formation pour les tables de catalogue régies avec filtrage au niveau des cellules et transactions de lac de données.

Réduction de la latence au démarrage afin d'améliorer les temps globaux de réalisation de tâche et l'interactivité.

Les tâches Spark sont facturées par incréments d'une seconde avec une durée de facturation minimale 10 fois inférieure, allant d'un minimum de 10 minutes à un minimum de 1 minute.

Prise en charge native des infrastructures de lacs de données ouverts avec Apache Hudi, Delta Lake et Apache Iceberg.

Prise en charge native du plug-in Cloud Shuffle Storage basé sur Amazon S3 (un plug-in Apache Spark) permettant d'utiliser Amazon S3 pour la réorganisation et la capacité de stockage élastique.

Filtrage d'exécution au niveau des lignes (SPARK-32268).

Améliorations ANSI (SPARK-38860).

Améliorations des messages d'erreur (SPARK-38781).

Prise en charge des types complexes pour le lecteur vectorisé Parquet (SPARK-34863).

Prise en charge des métadonnées de fichiers masqués pour Spark SQL (SPARK-37273).

Profileur pour les UDF Python/Pandas (SPARK-37443).

Introduction de Trigger.AvailableNow pour exécuter des requêtes de streaming telles que Trigger.Once dans plusieurs lots (SPARK-36533).

Fonctionnalités pushdown de Datasource V2 plus complètes (SPARK-38788).

Migration de log4j 1 vers log4j 2 (SPARK-37814).

Évolutions

Dans AWS Glue Studio, choisissez Glue 4.0 - Supports Spark 3.3, Scala 2, Python 3 dans Glue version.

Dans l'API, choisissez 4.0 dans le paramètre GlueVersion de l'opération d'API UpdateJob.

Dans la console, choisissez Spark 3.3, Python 3 (Glue Version 4.0) or Spark 3.3, Scala 2 (Glue Version 3.0) dans Glue version.

Dans AWS Glue Studio, choisissez Glue 4.0 - Supports Spark 3.3, Scala 2, Python 3 dans Glue version.

Dans l'API, choisissez 4.0 dans le paramètre GlueVersion de l'opération d'API CreateJob.

Les bibliothèques Python externes de votre tâche dépendent-elles de Python 2.7/3.6 ?

Tous les paramètres de tâche existants et les principales fonctions qui existent dans AWS Glue 3.0 existeront dans AWS Glue4.0.

AWS Glue 3.0 utilise Spark 3.1.1 optimisé pour Amazon EMR, et AWS Glue 4.0 utilise Spark 3.3.0 optimisé pour Amazon EMR.

Plusieurs modifications Spark pourraient à elles seules nécessiter une révision de vos scripts pour s'assurer que les fonctions supprimées ne sont pas référencées.

AWS Glue 4.0 propose également une mise à jour d'EMRFS et de Hadoop. Pour en savoir plus sur cette version spécifique, consultez Annexe A : Mises à niveau notables des dépendances.

Le kit SDK AWS fourni dans les tâches ETL est passé de la version 1.11 à la version 1.12.

Toutes les tâches Python utiliseront la version 3.10 de Python. Auparavant, Python 3.7 était utilisé dans AWS Glue 3.0.

Par conséquent, certains pymodules prêts à l'emploi avec AWS Glue sont mis à niveau.

Log4j a été mis à niveau vers Log4j2.

Pour la migration de certains connecteurs, consultez Migration du connecteur et du pilote JDBC pour AWS Glue 4.0.

Le kit SDK de chiffrement AWS passe de la version 1.x à la version 2.x. Les tâches AWS Glue utilisant des configurations de sécurité AWS Glue et celles liées à la dépendance du SDK de chiffrement AWS fournie dans l'environnement d'exécution sont impactées. Consultez les instructions relatives à la migration des tâches AWS Glue.

Vous pouvez mettre à niveau en toute sécurité une tâche AWS Glue 2.0/3.0 vers une tâcheAWS Glue 4.0, car AWS Glue 2.0/3.0 contient déjà la version bridge du kit SDK de chiffrement AWS.

Upgrading from Spark SQL 3.1 to 3.2

Upgrading from Spark SQL 3.2 to 3.3

Tous les paramètres de tâche existants et les principales fonctions qui existent dans AWS Glue 2.0 existeront dans AWS Glue 4.0.

Le validateur EMRFS optimisé pour S3 pour l'écriture de données Parquet dans Amazon S3 est activé par défaut depuis la version 3.0 de AWS Glue. Cependant, vous pouvez toujours le désactiver en définissant --enable-s3-parquet-optimized-committer sur false.

AWS Glue 2.0 utilise Spark 2.4 open source et AWS Glue 4.0 utilise Spark 3.3.0 optimisé pour Amazon EMR.

Le kit SDK AWS fourni dans les tâches ETL est passé de la version 1.11 à la version 1.12.

AWS Glue 4.0 propose également une mise à jour vers EMRFS, des pilotes JDBC mis à jour et des inclusions d'optimisations supplémentaires sur Spark lui-même fournies par AWS Glue.

Scala est mis à jour depuis la version 2.11 vers la version 2.12, et Scala 2.12 n'est pas rétrocompatible avec Scala 2.11.

Python 3.10 est la version utilisée par défaut pour les scripts Python, comme AWS Glue 2.0 utilisait uniquement Python 3.7 et 2.7.

Plusieurs mises à jour de dépendance, mises en évidence dans Annexe A : Mises à niveau notables des dépendances.

Tous les fichiers JAR supplémentaires fournis dans les tâches AWS Glue 2.0 existantes peuvent entraîner des dépendances conflictuelles, en raison des mises à niveau dans plusieurs dépendances dans 4.0 à partir de 2.0. Vous pouvez éviter les conflits de chemin de classe dans AWS Glue 4.0 avec le paramètre de tâche AWS Glue --user-jars-first.

AWS Glue 4.0 utilise Spark 3.3. À partir de Spark 3.1, le comportement du chargement/de l'enregistrement des horodatages depuis/vers des fichiers Parquet a changé. Pour plus de détails, veuillez consulter Mise à niveau de Spark SQL 3.0 vers 3.1.

Nous vous recommandons de définir les paramètres suivants lors de la lecture/écriture de données Parquet contenant des colonnes d'horodatage. La configuration de ces paramètres peut résoudre le problème d'incompatibilité du calendrier qui se produit pendant la mise à niveau de Spark 2 vers Spark 3, à la fois pour AWS Glue Dynamic Frame et Spark Data Frame. Utilisez l'option CORRECTED pour lire la valeur datetime telle quelle, et l'option LEGACY pour rebaser les valeurs datetime par rapport à la différence de calendrier pendant la lecture.

- Key: --conf
- Value: spark.sql.legacy.parquet.int96RebaseModeInRead=[CORRECTED|LEGACY] --conf spark.sql.legacy.parquet.int96RebaseModeInWrite=[CORRECTED|LEGACY] --conf spark.sql.legacy.parquet.datetimeRebaseModeInRead=[CORRECTED|LEGACY]

Pour la migration de certains connecteurs, consultez Migration du connecteur et du pilote JDBC pour AWS Glue 4.0.

Le kit SDK de chiffrement AWS passe de la version 1.x à la version 2.x. Les tâches AWS Glue utilisant des configurations de sécurité AWS Glue et celles liées à la dépendance du SDK de chiffrement AWS fournie dans l'environnement d'exécution sont impactées. Pour effectuer la migration des tâches AWS Glue, consultez les instructions suivantes :

Upgrading from Spark SQL 2.4 to 3.0

Upgrading from Spark SQL 3.1 to 3.2

Upgrading from Spark SQL 3.2 to 3.3

Changes in Datetime behavior to be expected since Spark 3.0.

AWS Glue 1.0 utilise Spark 2.4 open source et AWS Glue 4.0 utilise Spark 3.3.0 optimisé pour Amazon EMR.

Dans AWS Glue 4.0, toutes les tâches seront exécutées avec des temps de démarrage considérablement améliorés. Les tâches Spark seront facturées par incréments d'une seconde avec une durée de facturation minimale 10 fois plus faible, puisque la latence de démarrage passera de 10 minutes maximum à 1 minute maximum.

Le comportement de journalisation a considérablement évolué dans AWS Glue 4.0. Spark 3.3.0 requiert au minimum Log4j2.

Plusieurs mises à jour de dépendance, mises en évidence dans l'annexe.

Scala est également mis à jour depuis la version 2.11 vers la version 2.12, et Scala 2.12 n'est pas rétrocompatible avec Scala 2.11.

Python 3.10 est également la version utilisée par défaut pour les scripts Python, comme AWS Glue 0.9 utilisait uniquement Python 2.

Python 2.7 n'est pas pris en charge avec Spark 3.3.0. Toute tâche demandant Python 2 dans la configuration de la tâche échoue en générant une exception IllegalArgumentException.

Un nouveau mécanisme d'installation de modules Python supplémentaires est disponible via pip à partir de AWS Glue 2.0. Pour plus d'informations, consultez Installing additional Python modules with pip in AWS Glue 2.0+.

AWS Glue 4.0 ne fonctionne pas sur Apache YARN, et les paramètres YARN ne s'appliquent donc pas.

AWS Glue 4.0 ne possède pas de système de fichiers distribué Hadoop (HDFS).

Tous les fichiers JAR supplémentaires fournis dans les tâches AWS Glue 1.0 existantes peuvent entraîner des dépendances conflictuelles, en raison des mises à niveau dans plusieurs dépendances dans 4.0 à partir de 1.0. Pour éviter ce problème, nous activons AWS Glue 4.0 avec le paramètre de tâche --user-jars-first AWS Glue par défaut.

AWS Glue 4.0 prend en charge la mise à l'échelle automatique. Par conséquent, la métrique ExecutorAllocationManager est disponible lorsque la mise à l'échelle automatique est activée.

Dans les tâches AWS Glue version 4.0, vous spécifiez le nombre et le type d'employés, mais pas de maxCapacity.

AWS Glue 4.0 ne prend pas en charge les transformations de machine learning.

Pour la migration de certains connecteurs, consultez Migration du connecteur et du pilote JDBC pour AWS Glue 4.0.

Le kit SDK de chiffrement AWS passe de la version 1.x à la version 2.x. Les tâches AWS Glue utilisant des configurations de sécurité AWS Glue et celles liées à la dépendance du SDK de chiffrement AWS fournie dans l'environnement d'exécution sont impactées. Pour effectuer la migration des tâches AWS Glue, consultez les instructions suivantes :

Upgrading from Spark SQL 2.4 to 3.0

Upgrading from Spark SQL 3.0 to 3.1

Upgrading from Spark SQL 3.1 to 3.2

Upgrading from Spark SQL 3.2 to 3.3

Changes in Datetime behavior to be expected since Spark 3.0.

AWS Glue 0.9 utilise Spark 2.2.1 open source et AWS Glue 4.0 utilise Spark 3.3.0 optimisé pour Amazon EMR.

Dans AWS Glue 4.0, toutes les tâches seront exécutées avec des temps de démarrage considérablement améliorés. Les tâches Spark seront facturées par incréments d'une seconde avec une durée de facturation minimale 10 fois plus faible, car la latence de démarrage passera de 10 minutes maximum à 1 minute maximum.

Le comportement de journalisation a considérablement évolué depuis AWS Glue version 4.0. Spark 3.3.0 nécessite au minimum Log4j2, comme indiqué ici (https://spark.apache.org/docs/latest/core-migration-guide.html#upgrading-from-core-32-to-33).

Plusieurs mises à jour de dépendance, mises en évidence dans l'annexe.

Scala est également mis à jour depuis la version 2.11 vers la version 2.12, et Scala 2.12 n'est pas rétrocompatible avec Scala 2.11.

Python 3.10 est également la version utilisée par défaut pour les scripts Python, comme AWS Glue 0.9 utilisait uniquement Python 2.

AWS Glue 4.0 ne fonctionne pas sur Apache YARN, et les paramètres YARN ne s'appliquent donc pas.

AWS Glue 4.0 ne possède pas de système de fichiers distribué Hadoop (HDFS).

Tous les fichiers JAR supplémentaires fournis dans les tâches AWS Glue 0.9 existantes peuvent entraîner des dépendances conflictuelles, en raison des mises à niveau dans plusieurs dépendances dans 3.0 à partir de 0.9. Vous pouvez éviter les conflits de chemin de classe dans AWS Glue 3.0 avec le paramètre de tâche --user-jars-first AWS Glue .

AWS Glue 4.0 prend en charge la mise à l'échelle automatique. Par conséquent, la métrique ExecutorAllocationManager est disponible lorsque la mise à l'échelle automatique est activée.

Dans les tâches AWS Glue version 4.0, vous spécifiez le nombre et le type d'employés, mais pas de maxCapacity.

AWS Glue 4.0 ne prend pas en charge les transformations de machine learning.

Pour la migration de certains connecteurs, consultez Migration du connecteur et du pilote JDBC pour AWS Glue 4.0.

Le kit SDK de chiffrement AWS passe de la version 1.x à la version 2.x. Les tâches AWS Glue utilisant des configurations de sécurité AWS Glue et celles liées à la dépendance du SDK de chiffrement AWS fournie dans l'environnement d'exécution sont impactées. Pour effectuer la migration des tâches AWS Glue, consultez les instructions suivantes :

Upgrading from Spark SQL 2.2 to 2.3

Upgrading from Spark SQL 2.3 to 2.4

Upgrading from Spark SQL 2.4 to 3.0

Upgrading from Spark SQL 3.0 to 3.1

Upgrading from Spark SQL 3.1 to 3.2

Upgrading from Spark SQL 3.2 to 3.3

Changes in Datetime behavior to be expected since Spark 3,0.

Annexe B : Mises à niveau du pilote JDBC

Annexe C : Mises à niveau des connecteurs

Améliorations de la prise en charge de Spark SQL :

Toute table Hudi créée avant la version 0.10.0 sans avoir besoin de recréer un primaryKey avec un champ primaryKey depuis la version 0.10.0.

Plusieurs vulnérabilités (CVE) ont été corrigées.

Java 8 est pris en charge en mode natif.

Si la tâche utilise des tableaux de tableaux, à l'exception des tableaux d'octets, ce scénario peut être traité sous forme de tableaux multidimensionnels.

Le connecteur MongoDB actuel prend en charge Spark version 3.1 ou ultérieure et MongoDB version 4.0 ou ultérieure.

En raison de la mise à niveau du connecteur, quelques noms de propriétés ont été modifiés. Par exemple, le nom de la propriété URI a été remplacé par connection.uri. Pour plus d'informations sur les options actuelles, consultez le blog MongoDB Spark Connector.

L'utilisation de MongoDB 4.0 hébergé par Amazon DocumentDB présente certaines différences fonctionnelles. Pour en savoir plus, consultez les rubriques suivantes :

L'option « partitionneur » est limitée à ShardedPartitioner, PaginateIntoPartitionsPartitioner, et SinglePartitionPartitioner. Elle ne peut pas utiliser les valeurs SamplePartitioner et PaginateBySizePartitioner par défaut pour Amazon DocumentDB, car l'opérateur de l'étape ne prend pas en charge l'API MongoDB. Pour plus d'informations, consultez API, opérations et types de données MongoDB pris en charge.

Désormais, Delta Lake prend en charge les requêtes Time Travel dans SQL pour interroger facilement les données plus anciennes. Grâce à cette mise à jour, Time Travel est désormais disponible dans Spark SQL et via l'API DataFrame. La prise en charge de la version actuelle de TIMESTAMP dans SQL a été ajoutée.

Spark 3.3 introduit Trigger.AvailableNow pour exécuter des requêtes de streaming de la même manière que Trigger.Once pour les requêtes par lots. Cette prise en charge est également disponible en cas d'utilisation des tables Delta comme source de streaming.

Prise en charge de la fonction SHOW COLUMNS pour renvoyer la liste des colonnes d'une table.

Prise en charge de DESCRIBE DETAIL dans l'API DeltaTable de Scala et Python. Elle extrait des informations détaillées sur une table Delta à l'aide de l'API DeltaTable ou de Spark SQL.

Prise en charge du renvoi de métriques d'opération à partir des commandes SQL Delete, Merge et Update. Auparavant, ces commandes SQL renvoyaient un DataFrame vide. Désormais, elles renvoient un DataFrame avec des métriques utiles relatives à l'opération effectuée.

Pour optimiser les améliorations de performances :

Autres changements notables :

Ajout de plusieurs améliorations des performances pour la planification des scans et les requêtes Spark.

Ajout d'un client de catalogue REST commun qui utilise des validations basées sur les modifications pour résoudre les conflits de validation côté service.

La syntaxe AS OF des requêtes SQL Time Travel est prise en charge.

Ajout de la prise en charge de la fusion en lecture pour les requêtes MERGE et UPDATE.

Ajout de la prise en charge de la réécriture des partitions à l'aide de Z-order.

Ajout d'une spécification et d'une implémentation pour Puffin, un format adapté aux statistiques volumineuses et aux blobs d'index, tels que les esquisses Theta ou les filtres Bloom.

Ajout de nouvelles interfaces permettant de consommer les données par incréments (analyses des ajouts et du journal des modifications).

Ajout de la prise en charge des opérations en bloc et des lectures par plage sur les interfaces FileIO.

Ajout de tables de métadonnées supplémentaires pour afficher les fichiers supprimés dans l'arborescence des métadonnées.

Le comportement de suppression de la table a changé. Dans Iceberg 0.13.1, l'exécution de DROP TABLE supprime la table du catalogue ainsi que le contenu de la table. Dans Iceberg 1.0.0, DROP TABLE supprime uniquement la table du catalogue. Pour supprimer le contenu de la table, utilisez DROP TABLE PURGE.

Les lectures vectorisés Parquet sont activées par défaut dans Iceberg 1.0.0. Pour désactiver les lectures vectorisées, définissez read.parquet.vectorization.enabled sur false.