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

Cette rubrique décrit les modifications entre AWS Glue versions 0.9, 1.0, 2.0 et 3.0 pour vous permettre de migrer vos applications Spark et vos tâches ETL vers AWS Glue 4.0. Elle décrit également les fonctionnalités de AWS Glue version 4.0 et les avantages liés à son utilisation.

Pour utiliser cette fonction avec vos tâches ETL AWS Glue, sélectionnez 4.0 pour la Glue version lors de la création de vos tâches.

Nouvelles fonctionnalités prises en charge

Cette section décrit les nouvelles fonctions et les avantages de 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.

Améliorations majeures de Spark 3.1.1 à Spark 3.3.0

Notez les améliorations suivantes :

• 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).

Autres changements notables

Notez les modifications suivantes :

• Évolutions

  • Abandon des références à la prise en charge de Python 3.6 dans les documentations et Python/docs (SPARK-36977).

  • Suppression du tuple hack nommé en remplaçant le pickle intégré par cloudpickle (SPARK-32079).

  • Passage de la version minimale de Pandas à 1.0.5 (SPARK-37465).

Actions relatives à la migration vers AWS Glue 4.0

Pour les tâches existantes, modifiez la Glue version depuis la version précédente vers Glue 4.0 dans la configuration de la tâche.

• 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.

Pour les nouvelles tâches, choisissez Glue 4.0 lorsque vous créez une tâche.

• 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.

Pour afficher les journaux des événements Spark de AWS Glue 4.0 issus de AWS Glue 2.0 ou d'une version précédente, lancez un serveur d'historique Spark mis à niveau pour AWS Glue 4.0 à l'aide de AWS CloudFormation ou de Docker.

Liste de contrôle de migration

Consultez cette liste de contrôle pour la migration :

Note

Pour en savoir plus sur les éléments de la liste de contrôle liés à AWS Glue version 3.0, consultez Liste de contrôle de la migration.

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

  • Mettez à jour les bibliothèques dépendantes de Python 2.7/3.6 vers Python 3.10, car Spark 3.3.0 a supprimé la prise en charge de Python 2.7 et 3.6.

Migration de AWS Glue 3.0 vers AWS Glue 4.0

Notez les modifications suivantes lors de la migration :

• 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 plus d'informations sur le chemin de migration Log4j2, consultez la documentation de Log4j.

  • Vous devez plutôt renommer tout fichier log4j.properties personnalisé comme fichier log4j2.properties, avec les propriétés log4j2 appropriées.

• 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.

Reportez-vous à la documentation sur la migration de Spark :

• Upgrading from Spark SQL 3.1 to 3.2

• Upgrading from Spark SQL 3.2 to 3.3

Migration de AWS Glue 2.0 vers AWS Glue 4.0

Notez les modifications suivantes lors de la migration :

Note

Pour la procédure de migration liée à AWS Glue 3.0, consultez Migration de AWS Glue 3.0 vers AWS Glue 4.0.

• 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.

  • Plusieurs modifications Spark peuvent à 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.

  • Par exemple, Spark 3.3.0 n'active pas les UDF Scala non typés, mais Spark 2.4 les autorise.

• 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.

  • 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 depuis AWS Glue 2.0.

• 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 :

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

Reportez-vous à la documentation sur la migration de Spark :

• 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.

Migration de AWS Glue 1.0 vers AWS Glue 4.0

Notez les modifications suivantes lors de la migration :

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

  • Plusieurs modifications Spark peuvent à 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.

  • Par exemple, Spark 3.3.0 n'active pas les UDF Scala non typés, mais Spark 2.4 les autorise.

• 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 :

  • Il est impossible de migrer directement une tâche AWS Glue 0.9/1.0 vers une tâche AWS Glue 4.0. En effet, lors de la mise à niveau directe vers la version 2.x ou ultérieure et de l'activation immédiate de toutes les nouvelles fonctionnalités, le kit SDK de chiffrement AWS ne sera pas en mesure de déchiffrer le texte chiffré dans les versions antérieures du kit SDK de chiffrement AWS.

  • Pour effectuer une mise à niveau en toute sécurité, nous recommandons d'abord de migrer vers une tâche AWS Glue 2.0/3.0 contenant la version bridge du kit SDK de chiffrement AWS. Exécutez la tâche une seule fois pour utiliser la version bridge du kit SDK de chiffrement AWS.

  • Une fois la tâche terminée, vous pouvez migrer en toute sécurité la tâche AWS Glue 2.0/3.0 vers AWS Glue 4.0.

Reportez-vous à la documentation sur la migration de Spark :

• 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.

Migration de AWS Glue 0.9 vers AWS Glue 4.0

Notez les modifications suivantes lors de la migration :

• 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.

  • 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.

  • Par exemple, Spark 3.3.0 n'active pas les UDF Scala non typés, mais Spark 2.2 les autorise.

• 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.

  • 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 via pip est disponible.

• 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 :

  • Il est impossible de migrer directement une tâche AWS Glue 0.9/1.0 vers une tâche AWS Glue 4.0. En effet, lors de la mise à niveau directe vers la version 2.x ou ultérieure et de l'activation immédiate de toutes les nouvelles fonctionnalités, le kit SDK de chiffrement AWS ne sera pas en mesure de déchiffrer le texte chiffré dans les versions antérieures du kit SDK de chiffrement AWS.

  • Pour effectuer une mise à niveau en toute sécurité, nous recommandons d'abord de migrer vers une tâche AWS Glue 2.0/3.0 contenant la version bridge du kit SDK de chiffrement AWS. Exécutez la tâche une seule fois pour utiliser la version bridge du kit SDK de chiffrement AWS.

  • Une fois la tâche terminée, vous pouvez migrer en toute sécurité la tâche AWS Glue 2.0/3.0 vers AWS Glue 4.0.

Reportez-vous à la documentation sur la migration de Spark :

• 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.

Migration du connecteur et du pilote JDBC pour AWS Glue 4.0

Pour en savoir plus sur les versions des connecteurs JDBC et de lac de données qui ont été mises à niveau, consultez :

• Annexe B : Mises à niveau du pilote JDBC

• Annexe C : Mises à niveau des connecteurs

Hudi

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

  • Cette commande Call Procedure permet de renforcer la prise en charge pour la mise à niveau, la rétrogradation, le démarrage, le nettoyage et la réparation. La syntaxe Create/Drop/Show/Refresh Index est autorisée dans Spark SQL.

  • Un écart de performances a été comblé entre l'utilisation via Spark DataSource et Spark SQL. Dans le passé, les écritures Datasource étaient plus rapides qu'avec SQL.

  • Tous les générateurs de clés intégrés implémentent des opérations d'API spécifiques à Spark plus performantes.

  • Remplacement de la transformation UDF lors de l'opération en bloc insert par des transformations RDD afin de réduire les coûts d'utilisation de SerDe.

  • Spark SQL avec Hudi nécessite une primaryKey devant être spécifiée par tblproperites ou des options dans l'instruction SQL. Pour les opérations de mise à jour et de suppression, preCombineField est également obligatoire.

• 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.

PostgreSQL

• 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.

MongoDB

• 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 :

  • Différences fonctionnelles : Amazon DocumentDB et MongoDB

  • API, opérations et types de données MongoDB pris en charge.

• 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.

Delta Lake

• 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 :

  • Définissez l'option de configuration spark.databricks.delta.optimize.repartition.enabled=true de manière à utiliser repartition(1) plutôt que coalesce(1) dans la commande Optimize afin de bénéficier de meilleures performances lors du compactage de nombreux petits fichiers.

  • Performances améliorées grâce à une approche basée sur la file d'attente afin d'exécuter en parallèle les tâches de compactage.

• Autres changements notables :

  • Prise en charge de l'utilisation de variables dans les commandes SQL VACUUM et OPTIMIZE.

  • Améliorations apportées à CONVERT TO DELTA avec des tables de catalogue, notamment :

    • Remplissez automatiquement le schéma de partition à partir du catalogue s'il n'est pas fourni.

    • Utilisez les informations de partition du catalogue pour rechercher les fichiers de données à valider au lieu d'effectuer une analyse complète du répertoire. Plutôt que de valider tous les fichiers de données du répertoire des tables, seuls les fichiers de données figurant dans les répertoires des partitions actives seront validés.

  • Prise en charge de la lecture par lots du flux CDF sur les tables permettant le mappage de colonnes lorsque DROP COLUMN et RENAME COLUMN n'ont pas été utilisés. Pour plus d'informations, consultez la documentation de Delta Lake.

  • Améliorez les performances de la commande Update en activant le nettoyage du schéma dès le premier passage.

Apache Iceberg

• 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.

Oracle

Les modifications sont mineures.

MySQL

Les modifications sont mineures.

Amazon Redshift

AWS Glue 4.0 intègre un nouveau connecteur Amazon Redshift doté d'un nouveau pilote JDBC. Pour plus d'informations sur les améliorations et la procédure de migration depuis des versions AWS Glue précédentes, consultez Connexions Redshift.

Annexe A : Mises à niveau notables des dépendances

Voici les mises à niveau des dépendances :

Dépendance	Version dans AWS Glue 4.0	Version dans AWS Glue 3.0	Version dans AWS Glue 2.0	Version dans AWS Glue 1.0
Spark	3.3.0-amzn-1	3.1.1-amzn-0	2.4.3	2.4.3
Hadoop	3.3.3-amzn-0	3.2.1-amzn-3	2.8.5-amzn-5	2.8.5-amzn-1
Scala	2.12	2.12	2.11	2.11
Jackson	2.13.3	2.10.x	2.7.x	2.7.x
Hive	2.3.9-amzn-2	2.3.7-amzn-4	1.2	1.2
EMRFS	2.54.0	2.46.0	2.38.0	2.30.0
Json4s	3.7.0-M11	3.6.6	3.5.x	3.5.x
Flèche	7.0.0	2.0.0	0.10.0	0.10.0
Client de catalogue de données AWS Glue	3.7.0	3.0.0	1.10.0	N/A
Python	3.10	3.7	2.7 et 3.6	2.7 et 3.6
Boto	1.26	1.18	1.12	N/A

Annexe B : Mises à niveau du pilote JDBC

Voici les mises à niveau du pilote JDBC :

Pilote	Version du pilote JDBC dans les versions AWS Glue antérieures	Version du pilote JDBC dans AWS Glue 3.0	Version du pilote JDBC dans AWS Glue 4.0
MySQL	5.1	8.0.23	8.0.23
Microsoft SQL Server	6.1.0	7.0.0	9.4.0
Oracle Databases	11.2	21.1	21.7
PostgreSQL	42.1.0	42.2.18	42.3.6
MongoDB	2.0.0	4.0.0	4.7.2
Amazon Redshift	redshift-jdbc41-1.2.12.1017	redshift-jdbc41-1.2.12.1017	redshift-jdbc42-2.1.0.16

Annexe C : Mises à niveau des connecteurs

Les mises à niveau des connecteurs sont les suivantes :

Pilote	Version du connecteur dans AWS Glue 3.0	Version du connecteur dans AWS Glue 4.0
MongoDB	3.0.0	10.0.4
Hudi	0.10.1	0.12.1
Delta Lake	1.0.0	2.1.0
Iceberg	0.13.1	1.0.0
DynamoDB	1.11	1.12