Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Optimisation des lectures avec pushdown dans AWS Glue ETL Le pushdown est une technique d’optimisation qui rapproche la logique de récupération des données de la source de vos données. La source peut être une base de données ou un système de fichiers tel qu’Amazon S3. Lorsque vous exécutez certaines opérations directement sur la source, vous pouvez économiser du temps et de la puissance de traitement en ne transférant pas toutes les données via le réseau vers le moteur Spark géré par AWS Glue. Autrement dit, la poussée réduit l’analyse des données. Pour plus d'informations sur le processus permettant d'identifier le moment où cette technique est appropriée, consultez la section [Réduire la quantité de données analysées dans le guide](https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-aws-glue-for-apache-spark/reduce-data-scan.html) des *meilleures pratiques pour le réglage des performances de AWS Glue pour les tâches Apache Spark* sur le guide AWS prescriptif. ## Pushdown de prédicat sur les fichiers stockés dans Amazon S3 Lorsque vous travaillez sur des fichiers organisés par préfixe sur Amazon S3, vous pouvez filtrer vos chemins Amazon S3 cibles en définissant un pushdown de prédicat. Plutôt que de lire le jeu de données complet et d’appliquer des filtres dans un `DynamicFrame`, vous pouvez appliquer directement le filtre aux métadonnées de partition stockées dans le catalogue de données AWS . Cette approche vous permet de lister et de lire de manière sélective uniquement les données nécessaires. Pour plus d’informations sur ce processus, y compris l’écriture dans un compartiment par partitions, consultez [Gestion des partitions pour la sortie ETL dans AWS Glue](aws-glue-programming-etl-partitions.md). Le pushdown de prédicats dans Amazon S3 s’effectue à l’aide du paramètre `push_down_predicate`. Prenons l’exemple d’un compartiment dans Amazon S3 que vous avez partitionné par année, mois et jour. Si vous souhaitez récupérer les données clients pour juin 2022, vous pouvez demander à AWS Glue de ne lire que les chemins Amazon S3 pertinents. Dans ce cas, le `push_down_predicate` est `year='2022' and month='06'`. En mettant tout cela ensemble, l’opération de lecture peut être réalisée comme suit : ------ #### [ Python ] ``` customer_records = glueContext.create_dynamic_frame.from_catalog( database = "customer_db", table_name = "customer_tbl", push_down_predicate = "year='2022' and month='06'" ) ``` ------ #### [ Scala ] ``` val customer_records = glueContext.getCatalogSource( database="customer_db", tableName="customer_tbl", pushDownPredicate="year='2022' and month='06'" ).getDynamicFrame() ``` ------ Dans le scénario précédent, `push_down_predicate` récupère une liste de toutes les partitions du catalogue de données AWS Glue et les filtre avant de lire les fichiers Amazon S3 sous-jacents. Bien que cela soit utile dans la plupart des cas, lorsque vous travaillez avec des jeux de données contenant des millions de partitions, le processus de liste des partitions peut prendre beaucoup de temps. Pour résoudre ce problème, le nettoyage des partitions côté serveur peut être utilisé pour améliorer les performances. Cela se fait en créant un **index de partition** pour vos données dans le catalogue de données AWS Glue. Pour plus d’informations sur les index de partition, consultez [Création d’index de partition](partition-indexes.md). Vous pouvez ensuite utiliser l’option `catalogPartitionPredicate` pour référencer l’index. Pour un exemple de récupération de partitions avec `catalogPartitionPredicate`, consultez [Filtrage côté serveur à l'aide de prédicats de partition de catalogue](aws-glue-programming-etl-partitions.md#aws-glue-programming-etl-partitions-cat-predicates). ## Pushdown lors de l’utilisation de sources JDBC Le lecteur JDBC AWS Glue utilisé dans le pushdown prend en `GlueContext` charge les bases de données prises en charge en fournissant des requêtes SQL personnalisées qui peuvent être exécutées directement sur la source. Cela peut être réalisé en configurant le paramètre `sampleQuery`. Votre exemple de requête peut spécifier les colonnes à sélectionner et fournir un pushdown de prédicat pour limiter les données transférées vers le moteur Spark. Par défaut, les exemples de requêtes fonctionnent sur un seul nœud, ce qui peut entraîner des échecs lors du traitement de volumes de données importants. Pour utiliser cette fonctionnalité afin d’interroger des données à grande échelle, vous devez configurer le partitionnement des requêtes en définissant `enablePartitioningForSampleQuery` sur true, ce qui distribue la requête à plusieurs nœuds via une clé de votre choix. Le partitionnement des requêtes nécessite également quelques autres paramètres de configuration. Pour plus d’informations sur le partitionnement des requêtes, consultez [Lecture en parallèle à partir de tables JDBC](run-jdbc-parallel-read-job.md). Lors de la configuration`enablePartitioningForSampleQuery`, AWS Glue combinera votre prédicat pushdown avec un prédicat de partitionnement lors de l'interrogation de votre base de données. Vous `sampleQuery` devez terminer par un `AND` for AWS Glue pour ajouter des conditions de partitionnement. (Si vous ne fournissez pas de pushdown de prédicat, `sampleQuery` doit se terminer par un `WHERE`). Vous trouverez ci-dessous un exemple dans lequel nous poussons un prédicat vers le bas pour récupérer uniquement les lignes dont `id` est supérieur à 1 000. Cette `sampleQuery` ne renvoie que les colonnes de nom et d’emplacement pour les lignes où `id` est supérieur à la valeur spécifiée : ------ #### [ Python ] ``` sample_query = "select name, location from customer_tbl WHERE id>=1000 AND" customer_records = glueContext.create_dynamic_frame.from_catalog( database="customer_db", table_name="customer_tbl", sample_query = "select name, location from customer_tbl WHERE id>=1000 AND", additional_options = { "hashpartitions": 36 , "hashfield":"id", "enablePartitioningForSampleQuery":True, "sampleQuery":sample_query } ) ``` ------ #### [ Scala ] ``` val additionalOptions = Map( "hashpartitions" -> "36", "hashfield" -> "id", "enablePartitioningForSampleQuery" -> "true", "sampleQuery" -> "select name, location from customer_tbl WHERE id >= 1000 AND" ) val customer_records = glueContext.getCatalogSource( database="customer_db", tableName="customer_tbl").getDynamicFrame() ``` ------ **Note** Si `customer_tbl` porte un nom différent dans votre catalogue de données et votre entrepôt de données sous-jacent, vous devez fournir le nom de la table sous-jacente dans sample\$1query, car la requête est transmise à l’entrepôt de données sous-jacent. Vous pouvez également effectuer des requêtes sur des tables JDBC sans intégrer le AWS Glue Data Catalog. Au lieu de fournir un nom d’utilisateur et le mot de passe comme paramètres de la méthode, vous pouvez réutiliser les informations d’identification d’une connexion préexistante en fournissant `useConnectionProperties` et `connectionName`. Dans cet exemple, nous récupérons les informations d’identification à partir d’une connexion appelée `my_postgre_connection`. ------ #### [ Python ] ``` connection_options_dict = { "useConnectionProperties": True, "connectionName": "my_postgre_connection", "dbtable":"customer_tbl", "sampleQuery":"select name, location from customer_tbl WHERE id>=1000 AND", "enablePartitioningForSampleQuery":True, "hashfield":"id", "hashpartitions":36 } customer_records = glueContext.create_dynamic_frame.from_options( connection_type="postgresql", connection_options=connection_options_dict ) ``` ------ #### [ Scala ] ``` val connectionOptionsJson = """ { "useConnectionProperties": true, "connectionName": "my_postgre_connection", "dbtable": "customer_tbl", "sampleQuery": "select name, location from customer_tbl WHERE id>=1000 AND", "enablePartitioningForSampleQuery" : true, "hashfield" : "id", "hashpartitions" : 36 } """ val connectionOptions = new JsonOptions(connectionOptionsJson) val dyf = glueContext.getSource("postgresql", connectionOptions).getDynamicFrame() ``` ------ ## Remarques et limites relatives au pushdown dans Glue AWS Le Pushdown, en tant que concept, est applicable lors de la lecture à partir de sources autres que le streaming. AWS Glue prend en charge une variété de sources. La capacité à appuyer vers le bas dépend de la source et du connecteur. + Lorsque vous vous connectez à Snowflake, vous pouvez utiliser l’option `query`. Des fonctionnalités similaires existent dans le connecteur Redshift de AWS Glue 4.0 et des versions ultérieures. Pour de plus amples informations sur la lecture à partir de Snowflake avec `query`, consultez [Lecture à partir de tables Snowflake](aws-glue-programming-etl-connect-snowflake-home.md#aws-glue-programming-etl-connect-snowflake-read). + Le lecteur ETL DynamoDB ne prend pas en charge les filtres ou les prédicats pushdown. MongoDB et DocumentDB ne prennent pas non plus en charge ce type de fonctionnalité. + Lors de la lecture de données stockées dans Amazon S3 dans des formats de table ouverts, la méthode de partitionnement des fichiers dans Amazon S3 n’est plus suffisante. Pour lire et écrire à partir de partitions utilisant des formats de table ouverts, consultez la documentation relative au format. + DynamicFrame les méthodes n'exécutent pas le pushdown de la projection Amazon S3. Toutes les colonnes seront lues à partir des fichiers qui satisfont au filtre du prédicat. + Lorsque vous travaillez avec des `custom.jdbc` connecteurs dans AWS Glue, la possibilité d'appuyer vers le bas dépend de la source et du connecteur. Consultez la documentation du connecteur approprié pour vérifier si et comment il prend en charge le pushdown dans AWS Glue.