Mise en cache des fragments de résultats Spark

Amazon EMR 6.6.0 et versions ultérieures incluent la fonctionnalité optionnelle de mise en cache des fragments de résultats de Spark qui met automatiquement en cache les fragments de résultats. Ces fragments de résultats font partie des résultats issus de sous-arborescences de requêtes stockées dans un compartiment Amazon S3 de votre choix. Les fragments de résultats de requête stockés sont réutilisés lors des exécutions de requêtes suivantes, ce qui permet d'accélérer les requêtes.

La mise en cache des fragments de résultats analyse vos requêtes SQL Spark et met en cache les fragments de résultats éligibles à l’emplacement S3 que vous avez spécifié. Lors des exécutions de requête suivantes, les fragments de résultats de requête utilisables sont automatiquement détectés et extraits depuis S3. La mise en cache des fragments de résultats est différente de la mise en cache des ensembles de résultats, dans laquelle les requêtes suivantes doivent correspondre exactement à la requête d'origine pour renvoyer des résultats depuis le cache. Lorsqu'elle est utilisée pour des requêtes qui ciblent de manière répétée un sous-ensemble statique de vos données, la mise en cache des fragments de résultats accélère considérablement les performances.

Considérez la requête suivante, qui compte les commandes jusqu'en 2022 :

select
    l_returnflag,
    l_linestatus,
    count(*) as count_order
from
    lineitem
where
    l_shipdate <= current_date
    and year(l_shipdate) == '2022'
group by
    l_returnflag,
    l_linestatus

Au fil du temps, cette requête doit être exécutée tous les jours pour indiquer le total des ventes de l'année. Sans la mise en cache des fragments de résultats, les résultats pour tous les jours de l'année devront être recalculés chaque jour. La requête deviendra plus lente au fil du temps et sera plus lente à la fin de l'année, lorsque les 365 jours de résultats devront être recalculés.

Lorsque vous activez la mise en cache des fragments de résultats, vous utilisez les résultats de tous les jours précédents de l'année à partir du cache. Chaque jour, la fonctionnalité ne doit recalculer qu'un seul jour de résultats. Une fois que la fonctionnalité a calculé le fragment de résultat, elle met le fragment en cache. Par conséquent, les temps de requête activés par le cache sont rapides et restent constants pour chaque requête suivante.

Activation de la mise en cache des fragments de résultats Spark

Pour activer la mise en cache des fragments de résultats, veuillez suivre les étapes ci-dessous :

1. Créez un compartiment de cache dans Amazon S3 et autorisez l'accès en lecture/écriture à EMRFS. Pour plus d’informations, consultez Autorisation d'accès aux données EMRFS dans Amazon S3.

2. Configurez Amazon EMR Spark pour activer la fonctionnalité.

   spark.subResultCache.enabled = true
   spark.subResultCache.fs.root.path = s3://DOC-EXAMPLE-BUCKET/cache_dir/

3. Activez la gestion du cycle de vie S3 pour que le compartiment nettoie automatiquement les fichiers de cache.

4. Configurez éventuellement les maxBufferSize propriétés reductionRationThreshold et pour affiner la fonctionnalité.

   spark.sql.subResultCache.reductionRatioThreshold
   spark.sql.subResultCache.maxBufferSize

Considérations relatives à l'utilisation de la mise en cache des fragments de résultats

Les économies réalisées lorsque vous utilisez des résultats déjà mis en cache dans Amazon S3 plutôt que de les recalculer augmentent avec le nombre de fois où les mêmes résultats mis en cache peuvent être utilisés. Les requêtes comportant des analyses de grandes tables suivies de filtres ou d'agrégations de hachage qui réduisent la taille du résultat d'au moins 8 (c'est-à-dire un ratio d'au moins 8:1 dans la taille d'entrée:résultats) bénéficieront le plus de cette fonctionnalité. Plus le rapport de réduction entre l'entrée et les résultats est élevé, plus le rapport coût-bénéfice est important. Les requêtes présentant des taux de réduction inférieurs, mais comportant des étapes de calcul coûteuses entre l'analyse des tables et le filtrage ou les agrégations, en bénéficieront également, à condition que le coût de production des résultats soit supérieur à celui de leur extraction sur Amazon S3. Par défaut, la mise en cache des fragments de résultats ne prend effet que lorsqu'elle détecte qu'un taux de réduction sera d'au moins 8:1.

Lorsque vos requêtes réutilisent à plusieurs reprises les résultats mis en cache, les avantages de cette fonctionnalité sont les plus importants. Les requêtes de fenêtre progressives et incrémentielles en sont de bons exemples. Par exemple, une requête à fenêtre continue de 30 jours qui s'exécute déjà depuis 29 jours ne devrait extraire que 1/30e des données cibles de sa source d'entrée d'origine et utiliserait des fragments de résultats mis en cache pour les 29 jours précédents. Une requête de fenêtre incrémentielle en bénéficierait encore plus, car le début de la fenêtre reste fixe : à chaque invocation de la requête, un faible pourcentage du traitement nécessitera une lecture depuis la source d'entrée.

Voici d'autres considérations à prendre en compte lors de l'utilisation de la mise en cache des fragments de résultats :

• Les requêtes qui ne ciblent pas les mêmes données avec les mêmes fragments de requête auront un faible taux d'accès au cache et ne bénéficieront donc pas de cette fonctionnalité.

• Les requêtes présentant de faibles ratios de réduction qui ne contiennent pas d'étapes de calcul coûteuses produiront des résultats mis en cache à peu près aussi coûteux à lire qu'à traiter initialement.

• La première requête démontrera toujours une régression mineure en raison du coût d'écriture dans le cache.

• La fonctionnalité de mise en cache des fragments de résultats fonctionne exclusivement avec les fichiers Parquet. Les autres formats de fichiers ne sont pas pris en charge.

• Les tampons de la fonctionnalité de mise en cache des fragments de résultats essaieront uniquement de mettre en cache les scans dont la taille de fractionnement des fichiers est supérieure ou égale à 128 Mo. Avec la configuration par défaut de Spark, la mise en cache des fragments de résultats est désactivée si la taille de numérisation (taille totale de tous les fichiers analysés) divisée par le nombre de cœurs d'exécuteurs est inférieure à 128 Mo. Lorsque l'une des configurations Spark répertoriées ci-dessous est définie, la taille du fichier fractionné sera la suivante :

  min(maxPartitionBytes, max(openCostInBytes, scan size / minPartitionNum))

  • spark.sql. leafNodeDefaultParallélisme (la valeur par défaut est spark.default.parallelism)

  • fichiers spark.sql. minPartitionNum (la valeur par défaut est spark.sql. leafNodeDefaultParallélisme)

  • fichiers spark.sql. openCostInOctets

  • fichiers spark.sql. maxPartitionBytes

• La fonction de mise en cache des fragments de résultats est mise en cache au niveau de la granularité de la partition RDD. Le ratio de réduction décrit précédemment, qui est par défaut de 8:1, est évalué par partition RDD. Les charges de travail présentant des ratios de réduction par RDD supérieurs ou inférieurs à 8:1 peuvent présenter des avantages en termes de performances moindres que les charges de travail présentant des ratios de réduction par RDD constamment inférieurs à 8:1.

• La fonctionnalité de mise en cache des fragments de résultats utilise une mémoire tampon d'écriture de 16 Mo par défaut pour chaque partition RDD mise en cache. Si plus de 16 Mo sont mis en cache par partition RDD, le coût lié à la détermination de l'impossibilité d'une écriture peut entraîner une régression des performances.

• Bien que, par défaut, la mise en cache des fragments de résultats ne tente pas de mettre en cache les résultats des partitions RDD avec un ratio de réduction inférieur à 8:1 et plafonne sa mémoire tampon d'écriture à 16 Mo, ces deux valeurs sont réglables selon les configurations suivantes :

  spark.sql.subResultCache.reductionRatioThreshold (default: 8.0)
  spark.sql.subResultCache.maxBufferSize (default: 16MB, max: 64MB)

• Plusieurs clusters utilisant la même version d’Amazon EMR peuvent partager le même emplacement de cache. Pour garantir l'exactitude des résultats, la mise en cache des fragments de résultats n'utilisera pas les résultats du cache écrits par différentes versions d'Amazon EMR.

• La mise en cache des fragments de résultats sera automatiquement désactivée pour les cas d'utilisation de Spark Streaming ou en cas d'utilisation d'Apache Ranger ou AWS Lake Formation d'Apache Ranger. RecordServer

• La lecture/écriture de la mise en cache des fragments de résultats utilise les compartiments EMRFS et Amazon S3. Le chiffrement CSE/ SSE S3/ SSE KMS est pris en charge.