S4 Scan
Réducteur de coût de scan Athena
Réduisez votre facture de scan AWS Athena et Redshift Spectrum de 30–70% en réoptimisant le Parquet de votre data lake S3 selon le layout réellement lu par vos requêtes — pruning des partitions et row groups, encodage dictionnaire, zstd et compaction des petits fichiers — appliqués via un shadow-then-swap sûr qui ne change jamais les résultats de requête.
S4 Scan apprend de votre historique de requêtes Athena quelles colonnes sont lues et quels prédicats filtrent vos tables, puis réécrit le Parquet S3 sous-jacent dans le layout physique attendu par ces requêtes : colonnes chaudes en premier, tri sur les colonnes de filtre pour que les statistiques de row group puissent pruner, colonnes à faible cardinalité encodées par dictionnaire, fichiers compactés à une taille efficace et compression zstd. Athena et Redshift Spectrum facturent par téraoctet scanné depuis S3 ; un layout plus petit et plus facile à pruner réduit donc directement et durablement la facture. La sécurité est au cœur du produit — votre source n’est jamais écrasée.
Le problème
Athena et Redshift Spectrum facturent sur les octets réellement lus depuis S3 (par défaut $5/TB, variable selon la région). Quand la disposition physique de votre Parquet ne correspond pas à la façon dont les requêtes y accèdent, chaque requête scanne bien plus de S3 qu'elle ne retourne — et vous payez pour cet écart chaque mois. La facture étant fonction des octets scannés, la disposition elle-même définit votre coût.
Fonctionnement
- 1
Apprendre de l'historique des requêtes
Il lit votre catalogue Glue et l'historique des requêtes Athena (métriques de workgroup, CloudTrail) pour identifier les colonnes que chaque table lit réellement et les prédicats qui la filtrent.
- 2
Écrire dans le shadow, puis valider
Il écrit le Parquet optimisé dans un emplacement shadow distinct et vérifie que les résultats de la requête sont identiques jusqu'aux valeurs, NULL, échelle décimale et fuseau horaire de l'horodatage.
- 3
Swap via Glue, avec rollback
Ce n'est qu'après la réussite de la vérification qu'il redirige l'emplacement de la table Glue — un déplacement de pointeur de catalogue, et non de données — réversible avec une seule commande de rollback.
Points forts
Sûr par conception : les données optimisées sont écrites dans un emplacement shadow, vérifiées comme identiques dans les résultats de requête (valeurs, nulls, échelle décimale, timestamp tz), puis échangées via le Glue catalog — avec rollback en une commande. Les données source ne sont jamais modifiées in place.
Visualisez les économies avant de vous engager : un dry-run projette la réduction mensuelle en dollars sur vos tables réelles et l’attribue honnêtement au pruning, au dictionnaire + zstd et à la compaction des petits fichiers.
Pas de lock-in, pas de surveillance manuelle : la sortie est du Parquet standard lisible par Athena, et l’AMI réoptimise selon un planning EventBridge afin que les économies s’accumulent automatiquement.
Ce qui est inclus
- Analyse de l'historique des requêtes : dérive les colonnes hot, les prédicats fréquents et les candidats de clés de partition/tri à partir de vos requêtes passées dans un plan d'optimisation.
- Pruning de partitions et de row groups : repartitionne sur vos clés de prédicat pour ignorer des fichiers entiers, et trie sur les colonnes de filtrage pour que les statistiques min/max évitent de lire les row groups non correspondants.
- Encodage dictionnaire/RLE + zstd : les colonnes à faible cardinalité sont encodées par dictionnaire et recompressées avec du zstd standard, lisible par Athena, afin de réduire les octets de lecture projetés.
- Compaction de petits fichiers : fusionne de nombreux petits objets en un nombre réduit de fichiers de taille appropriée pour l'efficacité des I/O et de meilleures statistiques.
- Shadow → vérification → swap avec rollback en une seule commande : la source n'est jamais modifiée sur place, et la bascule n'est qu'un déplacement de pointeur Glue.
- Projection financière en dry-run : sans aucune écriture, il indique les octets scannés actuels vs optimisés ainsi que la différence mensuelle, en attribuant honnêtement les économies au pruning de partitions / pruning de row groups / dictionnaire+zstd / compaction.
- Ré-optimisation planifiée via EventBridge, avec une sortie Parquet standard lisible par Athena — sans lock-in.
Cas d'usage
Factures de scan Athena/Redshift Spectrum élevées que vous souhaitez réduire sans réécrire de SQL.
Tables larges où les requêtes ne lisent que quelques colonnes et ne filtrent que sur quelques prédicats, mais scannent tout de même le fichier entier.
Data lakes fragmentés en de nombreux petits objets Parquet, ce qui nuit à l'efficacité des I/O et aux statistiques.
Jeux de données en croissance continue qui bénéficient d'une ré-optimisation récurrente et planifiée par EventBridge.
FAQ
Cela pourrait-il corrompre mes données ou modifier les résultats de mes requêtes ?
La source n'est jamais modifiée sur place. Les données optimisées sont écrites dans un emplacement shadow distinct et validées comme ayant des résultats identiques — valeurs, NULL, échelle décimale, fuseau horaire de l'horodatage, types imbriqués — avant que seul le pointeur Glue ne soit déplacé. Si la vérification échoue, aucun swap n'est effectué ; le shadow est abandonné et la source reste inchangée. Après un swap, une seule commande permet de restaurer l'emplacement d'origine.
Suis-je dépendant d'un format propriétaire ?
Non. La sortie est uniquement du Parquet standard lisible par Athena (zstd standard, dictionnaire/RLE) sans codec propriétaire. Vous pouvez effectuer un rollback à tout moment, et les données optimisées se lisent avec les outils Athena habituels.
Comment S4 Scan sait-il quoi optimiser ?
Il apprend de l'historique de vos requêtes Athena — quelles colonnes sont lues et quels prédicats filtrent vos tables — et en déduit l'ordre des colonnes, les clés de partition et les clés de tri à recommander. Cela repose sur des modèles d'accès réels, pas sur des suppositions.
Puis-je voir combien je vais économiser avant de m'engager ?
Oui. Un dry-run indique les octets scannés actuels vs optimisés et l'écart financier mensuel sans rien écrire, en attribuant honnêtement la réduction au pruning de partitions/row groups, au dictionnaire+zstd et à la compaction. Le taux de 30–70% est une fourchette qui dépend du degré d'inadaptation de votre structure — ce n'est pas une garantie — commencez donc par effectuer un dry-run sur votre propre table.
Où s'exécute-t-il et mes données quittent-elles mon compte ?
Il s'exécute en tant qu'AMI au sein de votre propre compte AWS et VPC, accédant uniquement à vos ressources S3, Glue et Athena — vos données ne s'échappent jamais. Il fonctionne de manière totalement autonome selon un calendrier EventBridge, sous un rôle IAM de moindre privilège.
Modèle de tarification
Frais logiciels horaires + EC2 (classe t3 / m5), avec une offre au GB traité également disponible. Option annuelle disponible.
Autres produits S4
S4 — Squished S3
Gateway transparent de compression S3 par GPU
S4 Logs
Archiver CloudWatch Logs vers S3 zstd
S4 Metrics
Gouverner la cardinalité des métriques CloudWatch