S4 Scan
Athena Scan-Kosten senken
Athena- und Redshift Spectrum-Scan-Rechnung um 30–70% senken, indem Ihr S3 Data Lake-Parquet auf das Layout re-optimiert wird, das Ihre Abfragen tatsächlich lesen — Partition- und Row-Group-Pruning, Dictionary Encoding, zstd und Small-File-Compaction — angewendet über ein sicheres Shadow-then-Swap-Verfahren, das Abfrageergebnisse nie verändert.
S4 Scan lernt aus Ihrer Athena-Abfragehistorie, welche Spalten gelesen werden und welche Prädikate Ihre Tabellen filtern, und schreibt das zugrunde liegende S3 Parquet dann in das physische Layout um, das diese Abfragen benötigen: Hot Columns zuerst, nach den gefilterten Spalten sortiert, damit Row-Group-Statistiken prunen können, Low-Cardinality-Spalten mit Dictionary Encoding, Dateien auf eine effiziente Größe kompaktiert und mit zstd komprimiert. Athena und Redshift Spectrum rechnen pro aus S3 gescanntem Terabyte ab, daher ist ein kleineres, besser prune-bares Layout eine direkte, wiederkehrende Rechnungssenkung. Sicherheit ist der Kern des Produkts — Ihre Quelle wird nie überschrieben.
Das Problem
Athena und Redshift Spectrum rechnen basierend auf den tatsächlich aus S3 gelesenen Bytes ab (standardmäßig $5/TB, regionsabhängig). Wenn das physische Layout Ihres Parquet nicht zu den Zugriffsmustern der Abfragen passt, scannt jede Abfrage weitaus mehr S3-Daten, als sie tatsächlich zurückgibt — und diese Lücke bezahlen Sie jeden Monat. Da die Rechnung von den gescannten Bytes abhängt, bestimmt das Layout selbst Ihre Kosten.
Funktionsweise
- 1
Aus dem Abfrageverlauf lernen
Es liest Ihren Glue-Katalog und den Athena-Abfrageverlauf (Workgroup-Metriken, CloudTrail), um zu lernen, welche Spalten jede Tabelle tatsächlich liest und welche Prädikate zur Filterung verwendet werden.
- 2
In Shadow schreiben, dann verifizieren
Es schreibt das optimierte Parquet in einen separaten Shadow-Speicherort und verifiziert, dass die Abfrageergebnisse bis hin zu Werten, NULLs, der Decimal-Skalierung und der Zeitstempel-Zeitzone identisch sind.
- 3
Swap über Glue, mit Rollback
Erst nach erfolgreicher Verifizierung wird der Speicherort der Glue-Tabelle neu zugewiesen — eine Katalog-Pointer-Verschiebung, keine Datenverschiebung — und kann mit einem einzigen Rollback-Befehl rückgängig gemacht werden.
Highlights
Sicher durch Konstruktion: Optimierte Daten werden an einen Shadow-Speicherort geschrieben, auf identische Query-Ergebnisse geprüft (Werte, NULLs, Dezimalskala, Timestamp-tz) und dann über den Glue-Katalog geswappt — mit Rollback per Ein-Befehl. Quelldaten werden nie in-place geändert.
Einsparungen vor dem Commit sehen: Ein dry-run prognostiziert die monatliche Dollar-Reduktion auf Ihren echten Tabellen und ordnet sie ehrlich Pruning, Dictionary + zstd und Small-File-Compaction zu.
Kein Lock-in, kein Babysitting: Die Ausgabe ist standardmäßiges, von Athena lesbares Parquet, und die AMI optimiert nach einem EventBridge-Zeitplan neu, sodass sich Einsparungen automatisch summieren.
Lieferumfang
- Abfrageverlaufsanalyse: leitet Hot-Spalten, häufige Prädikate und Partitionierungs-/Sortierschlüssel-Kandidaten aus Ihren vergangenen Abfragen in einen Optimierungsplan ab.
- Partitions- und Zeilengruppen-Pruning: partitioniert nach Ihren Prädikatschlüsseln neu, sodass ganze Dateien übersprungen werden, und sortiert nach Filterspalten, sodass nicht übereinstimmende Zeilengruppen dank Min/Max-Statistiken beim Lesen übersprungen werden.
- Dictionary-/RLE-Codierung + zstd: Spalten mit niedriger Kardinalität werden wörterbuchcodiert und mit standardmäßigem, von Athena lesbarem zstd rekomprimiert, um die projizierten gelesenen Bytes zu reduzieren.
- Kompaktierung kleiner Dateien: führt viele winzige Objekte in weniger Dateien mit optimaler Größe zusammen, um die I/O-Effizienz und die Statistiken zu verbessern.
- Shadow → Verifizieren → Swap mit Rollback per Einzelbefehl: die Quelle wird niemals an Ort und Stelle geändert, und die Umstellung ist lediglich eine Verschiebung des Glue-Pointers.
- Dry-Run-Prognose: Ohne Schreibvorgänge werden die aktuellen den optimierten Scan-Bytes sowie die monatliche Differenz gegenübergestellt. Die Einsparungen werden transparent dem Partitions-Pruning, Zeilengruppen-Pruning, Dictionary+zstd und der Kompaktierung zugeschrieben.
- Über EventBridge geplante Re-Optimierung mit Ausgabe als standardmäßiges, von Athena lesbares Parquet — kein Lock-in.
Anwendungsfälle
Hohe Scan-Gebühren für Athena/Redshift Spectrum, die Sie ohne Umschreiben von SQL-Code senken möchten.
Breite Tabellen, bei denen Abfragen nur wenige Spalten lesen und nach einigen Prädikaten filtern, aber dennoch die gesamte Datei scannen.
Data Lakes, die in viele kleine Parquet-Objekte fragmentiert sind, was die I/O-Effizienz und die Statistiken beeinträchtigt.
Wachsende Datensätze, die von einer wiederkehrenden, über EventBridge geplanten Re-Optimierung profitieren.
FAQ
Könnte dies meine Daten beschädigen oder meine Abfrageergebnisse verändern?
Die Quelle wird niemals an Ort und Stelle geändert. Die optimierten Daten werden in einen separaten Shadow-Speicherort geschrieben und auf Ergebnisidentität verifiziert — Werte, NULLs, Decimal-Skalierung, Zeitstempel-Zeitzone, verschachtelte Typen —, bevor lediglich der Glue-Pointer verschoben wird. Wenn die Verifizierung fehlschlägt, findet kein Swap statt; der Shadow wird verworfen und die Quelle bleibt unberührt. Nach einem Swap stellt ein einziger Befehl den ursprünglichen Speicherort wieder her.
Bin ich an ein proprietäres Format gebunden?
Nein. Die Ausgabe erfolgt ausschließlich im standardmäßigen, von Athena lesbaren Parquet-Format (Standard-zstd, Dictionary/RLE) ohne proprietären Codec. Sie können jederzeit ein Rollback durchführen, und die optimierten Daten lassen sich mit normalen Athena-Tools lesen.
Wie weiß S4 Scan, was optimiert werden muss?
Es lernt aus Ihrem Athena-Abfrageverlauf — welche Spalten gelesen und welche Tabellen durch welche Prädikate gefiltert werden — und leitet daraus Empfehlungen für die Spaltenreihenfolge, Partitionsschlüssel und Sortierschlüssel ab. Dies basiert auf echten Zugriffsmustern, nicht auf Vermutungen.
Kann ich vorab sehen, wie viel ich einsparen werde?
Ja. Ein Dry-Run stellt die aktuellen den optimierten Scan-Bytes sowie der monatlichen Dollar-Differenz gegenüber, ohne etwas zu schreiben, und ordnet die Reduzierung transparent dem Partitions-/Zeilengruppen-Pruning, Dictionary+zstd und der Kompaktierung zu. Der Richtwert von 30–70% ist eine Spanne, die davon abhängt, wie unpassend Ihr Layout strukturiert ist — keine Garantie —, führen Sie also zunächst einen Dry-Run auf Ihrer eigenen Tabelle durch.
Wo wird es ausgeführt und verlassen meine Daten mein Konto?
Es läuft als AMI in Ihrem eigenen AWS-Konto und Ihrer VPC und greift nur auf Ihre S3-, Glue- und Athena-Ressourcen zu — Ihre Daten verlassen Ihre Umgebung niemals. Es arbeitet vollautomatisch nach einem EventBridge-Zeitplan unter einer IAM-Rolle mit minimalen Berechtigungen.
Preismodell
Stündliche Softwaregebühr + EC2 (t3- / m5-Klasse), zusätzlich ist ein Angebot mit Abrechnung pro verarbeitetem GB verfügbar. Jahresoption verfügbar.
Weitere S4-Produkte
S4 — Squished S3
Transparenter GPU S3-Komprimierungs-Gateway
S4 Logs
CloudWatch Logs nach zstd S3 archivieren
S4 Metrics
CloudWatch Metric-Cardinality steuern