Réduisez le volume de données numérisées

Taille du fichier — Nous recommandons de maintenir la taille du fichier des entrées et des sorties dans une fourchette modérée (par exemple, 128 Mo). Les fichiers trop petits ou trop volumineux peuvent entraîner des problèmes.

Un grand nombre de petits fichiers sont à l'origine des problèmes suivants :

En revanche, si le type de fichier n'est pas divisible (par exemple gzip) et que les fichiers sont trop volumineux, l'application Spark doit attendre qu'une seule tâche ait terminé de lire le fichier dans son intégralité.

Pour réduire le parallélisme excessif lié à la création d'une tâche Apache Spark pour chaque petit fichier, utilisez le regroupement de fichiers pour. DynamicFrames Cette approche réduit le risque d'une OOM exception de la part du pilote Spark. Pour configurer le regroupement de fichiers, définissez les groupSize paramètres groupFiles et. L'exemple de code suivant utilise le AWS Glue DynamicFrame API dans un ETL script avec ces paramètres.

dyf = glueContext.create_dynamic_frame_from_options("s3",
    {'paths': ["s3://input-s3-path/"],
    'recurse':True,
    'groupFiles': 'inPartition',
    'groupSize': '1048576'},
    format="json")

Compression — Si vos objets S3 se chiffrent en centaines de mégaoctets, pensez à les compresser. Il existe différents formats de compression, que l'on peut globalement classer en deux types :

Pour Spark (et les autres moteurs de traitement distribué courants), vous allez diviser votre fichier de données source en fragments que votre moteur peut traiter en parallèle. Ces unités sont souvent appelées divisions. Une fois que vos données sont dans un format séparable, les AWS Glue lecteurs optimisés peuvent récupérer les divisions d'un objet S3 en offrant la Range possibilité de ne GetObject API récupérer que des blocs spécifiques. Examinez le schéma suivant pour voir comment cela fonctionnerait dans la pratique.

Les données compressées peuvent accélérer considérablement votre application, à condition que les fichiers soient d'une taille optimale ou qu'ils soient séparables. Les petites tailles de données réduisent les données numérisées depuis Amazon S3 et le trafic réseau d'Amazon S3 vers votre cluster Spark. D'autre part, il en faut davantage CPU pour compresser et décompresser les données. La quantité de calcul requise varie en fonction du taux de compression de votre algorithme de compression. Tenez compte de ce compromis lorsque vous choisissez votre format de compression fractionnable.

Format de fichier — Utilisez un format en colonnes. Apache Parquet et Apache ORC sont des formats de données en colonnes populaires. Parcourez et ORC stockez les données de manière efficace en utilisant la compression basée sur les colonnes, en encodant et en compressant chaque colonne en fonction de son type de données. Pour plus d'informations sur les codages Parquet, consultez la section Définitions de codage Parquet. Les fichiers de parquet sont également séparables.

Les formats en colonnes regroupent les valeurs par colonne et les stockent ensemble dans des blocs. Lorsque vous utilisez des formats en colonnes, vous pouvez ignorer les blocs de données correspondant à des colonnes que vous n'avez pas l'intention d'utiliser. Les applications Spark ne peuvent récupérer que les colonnes dont vous avez besoin. En général, de meilleurs taux de compression ou le fait de sauter des blocs de données permettent de lire moins d'octets depuis Amazon S3, ce qui améliore les performances. Les deux formats prennent également en charge les approches pushdown suivantes pour réduire les E/S :

Disposition des fichiers — En stockant vos données S3 dans des objets dans différents chemins en fonction de la façon dont les données seront utilisées, vous pouvez récupérer efficacement les données pertinentes. Pour plus d'informations, consultez la section Organisation des objets à l'aide de préfixes dans la documentation Amazon S3. AWS Glue prend en charge le stockage des clés et des valeurs des préfixes Amazon S3 au formatkey=value, en partitionnant vos données selon le chemin Amazon S3. En partitionnant vos données, vous pouvez limiter la quantité de données numérisées par chaque application d'analyse en aval, ce qui améliore les performances et réduit les coûts. Pour plus d'informations, consultez la section Gestion des partitions pour ETL la sortie dans AWS Glue.

Le partitionnement divise votre table en différentes parties et conserve les données associées dans des fichiers groupés en fonction de valeurs de colonne telles que l'année, le mois et le jour, comme indiqué dans l'exemple suivant.

# Partitioning by /YYYY/MM/DD
s3://<YourBucket>/year=2023/month=03/day=31/0000.gz
s3://<YourBucket>/year=2023/month=03/day=01/0000.gz
s3://<YourBucket>/year=2023/month=03/day=02/0000.gz
s3://<YourBucket>/year=2023/month=03/day=03/0000.gz
...

Vous pouvez définir des partitions pour votre jeu de données en le modélisant à l'aide d'une table dans le AWS Glue Data Catalog. Vous pouvez ensuite limiter la quantité de données numérisées en utilisant l'élagage des partitions comme suit :

Trop de partitions Amazon S3 : évitez de partitionner vos données Amazon S3 sur des colonnes contenant un large éventail de valeurs, comme une colonne d'ID contenant des milliers de valeurs. Cela peut augmenter considérablement le nombre de partitions dans votre bucket, car le nombre de partitions possibles est le produit de tous les champs que vous avez partitionnés. Un trop grand nombre de partitions peut provoquer les effets suivants :

Par exemple, lorsque vous définissez un type de date dans partitionBy oupartitionKeys, un partitionnement au niveau de la date yyyy/mm/dd est adapté à de nombreux cas d'utilisation. Cependant, yyyy/mm/dd/<ID> cela peut générer tellement de partitions que cela aurait un impact négatif sur les performances dans leur ensemble.

D'autre part, certains cas d'utilisation, tels que les applications de traitement en temps réel, nécessitent de nombreuses partitions telles queyyyy/mm/dd/hh. Si votre cas d'utilisation nécessite des partitions importantes, pensez à utiliser des index de AWS Glue partition pour réduire le temps de latence lors de la récupération des métadonnées de partition à partir du catalogue de données.

Pour DynamicFrame, utilisez l'sampleQueryoption. Lors de l'utilisationcreate_dynamic_frame.from_catalog, configurez l'additional_optionsargument comme suit.

query = "SELECT * FROM <TableName> where id = 'XX' AND"
datasource0 = glueContext.create_dynamic_frame.from_catalog(
  database = db,
  table_name = table,
  additional_options={
      "sampleQuery": query,
      "hashexpression": key,
      "hashpartitions": 10,
      "enablePartitioningForSampleQuery": True
    },
  transformation_ctx = "datasource0"
)

Quandusing create_dynamic_frame.from_options, configurez l'connection_optionsargument comme suit.

query = "SELECT * FROM <TableName> where id = 'XX' AND"
datasource0 = glueContext.create_dynamic_frame.from_options(
    connection_type = connection, 
    connection_options={
        "url": url,
        "user": user,
        "password": password,
        "dbtable": table,
        "sampleQuery": query,
        "hashexpression": key,
        "hashpartitions": 10,
        "enablePartitioningForSampleQuery": True
    }
)

Pour DataFrame, utilisez l'option de requête.

query = "SELECT * FROM <TableName> where id = 'XX'"
jdbcDF = spark.read \
.format('jdbc') \
.option('url', url) \
.option('user', user) \
.option('password', pwd) \
.option('query', query) \
.load()

Pour Amazon Redshift, utilisez la AWS Glue version 4.0 ou une version ultérieure pour bénéficier de la prise en charge du pushdown dans le connecteur Amazon Redshift Spark.

dyf = glueContext.create_dynamic_frame.from_catalog(
    database = "redshift-dc-database-name", 
    table_name = "redshift-table-name", 
    redshift_tmp_dir = args["temp-s3-dir"], 
    additional_options = {"aws_iam_role": "arn:aws:iam::role-account-id:role/rs-role-name"}
)

Pour les autres bases de données, consultez la documentation de cette base de données.

Pour éviter une analyse complète de toutes les exécutions de tâches en continu et ne traiter que les données absentes lors de la dernière exécution de tâches, activez les signets de tâches.

Pour limiter la quantité de données d'entrée à traiter, activez l'exécution limitée avec des signets de tâches. Cela permet de réduire la quantité de données numérisées pour chaque exécution de tâche.