S4 Scan
Reductor de coste de scan de Athena
Reduce tu factura de scan de AWS Athena y Redshift Spectrum un 30–70% reoptimizando el Parquet de tu data lake S3 al layout que tus consultas leen realmente — pruning de particiones y row-groups, dictionary encoding, zstd y compactación de archivos pequeños — aplicado mediante un shadow-then-swap seguro que nunca cambia los resultados de las consultas.
S4 Scan aprende de tu historial de consultas de Athena qué columnas se leen y qué predicados filtran tus tablas, y después reescribe el Parquet S3 subyacente en el layout físico que esas consultas necesitan: columnas calientes primero, ordenación por las columnas por las que filtras para que las estadísticas de row-group puedan hacer pruning, columnas de baja cardinalidad con dictionary encoding, archivos compactados a un tamaño eficiente y compresión con zstd. Athena y Redshift Spectrum facturan por terabyte escaneado desde S3, por lo que un layout más pequeño y con mejor pruning reduce la factura de forma directa y recurrente. La seguridad es el núcleo del producto — tu origen nunca se sobrescribe.
El problema
Athena y Redshift Spectrum facturan según los bytes leídos de S3 (por defecto $5/TB, dependiendo de la región). Cuando la distribución física de tu Parquet no coincide con la forma en que las consultas acceden a él, cada consulta escanea mucho más S3 de lo que devuelve — y pagas por esa diferencia todos los meses. Dado que la factura depende de los bytes escaneados, la propia distribución determina tu coste.
Cómo funciona
- 1
Aprender del historial de consultas
Lee tu catálogo de Glue y el historial de consultas de Athena (métricas de grupos de trabajo, CloudTrail) para aprender qué columnas lee realmente cada tabla y qué predicados las filtran.
- 2
Escribir en shadow, luego verificar
Escribe el Parquet optimizado en una ubicación shadow independiente y verifica que los resultados de las consultas sean idénticos hasta el nivel de valores, NULL, escala decimal y zona horaria del timestamp.
- 3
Swap a través de Glue, con rollback
Solo después de superar la verificación se redirige la ubicación de la tabla de Glue —un movimiento de puntero de catálogo, no de datos—, reversible con un único comando de rollback.
Características destacadas
Seguro por diseño: los datos optimizados se escriben en una ubicación shadow, se verifica que los resultados de consulta sean idénticos (valores, nulls, escala decimal, zona horaria de timestamp) y después se intercambian mediante el catálogo Glue, con rollback en un solo comando. Los datos de origen nunca se modifican in-place.
Vea el ahorro antes de comprometerse: un dry-run proyecta la reducción mensual en dólares sobre sus tablas reales y la atribuye de forma honesta a pruning, diccionario + zstd y compactación de archivos pequeños.
Sin lock-in ni supervisión constante: la salida es Parquet estándar legible por Athena, y la AMI reoptimiza según una programación de EventBridge para que el ahorro se acumule automáticamente.
Qué incluye
- Análisis del historial de consultas: extrae columnas calientes, predicados frecuentes y candidatos a partition/sort-key de sus consultas anteriores para definir un plan de optimización.
- Pruning de particiones y row-groups: vuelve a particionar según las claves de sus predicados para omitir archivos completos, y ordena según las columnas de filtrado para que las estadísticas de min/max permitan ignorar los grupos de filas que no coincidan.
- Codificación por diccionario/RLE + zstd: las columnas de baja cardinalidad se codifican mediante diccionario y se vuelven a comprimir con zstd estándar legible por Athena para reducir los bytes de lectura proyectados.
- Compactación de archivos pequeños: fusiona muchos objetos diminutos en menos archivos con el tamaño adecuado para lograr eficiencia de I/O y mejores estadísticas.
- Shadow → verificación → swap con rollback de un solo comando: el origen nunca se modifica in situ y la transición consiste únicamente en un movimiento de puntero de Glue.
- Proyección económica con dry-run: sin realizar escrituras, reporta los bytes de escaneo actuales frente a los optimizados y la diferencia mensual en dólares, atribuyendo honestamente el ahorro al pruning de particiones / pruning de row-groups / dictionary+zstd / compactación.
- Reoptimización programada con EventBridge, con una salida en Parquet estándar legible por Athena —sin lock-in.
Casos de uso
Facturas elevadas por escaneo en Athena / Redshift Spectrum que desea reducir sin reescribir ninguna consulta SQL.
Tablas anchas en las que las consultas leen solo unas pocas columnas y filtran por unos pocos predicados, pero aun así escanean todo el archivo.
Data lakes fragmentados en muchos pequeños objetos Parquet, lo que perjudica la eficiencia de I/O y las estadísticas.
Conjuntos de datos en crecimiento que se benefician de una reoptimización periódica programada con EventBridge.
Preguntas frecuentes
¿Podría esto corromper mis datos o cambiar los resultados de mis consultas?
El origen nunca se modifica in situ. Los datos optimizados se escriben en una ubicación shadow independiente y se verifica que los resultados sean idénticos —valores, NULL, escala decimal, zona horaria del timestamp y tipos anidados— antes de proceder únicamente a mover el puntero de Glue. Si la verificación falla, no se realiza el swap; se descarta la ubicación shadow y el origen permanece intacto. Después de un swap, un solo comando restaura la ubicación original.
¿Quedaré cautivo en un formato propietario?
No. La salida es únicamente Parquet estándar legible por Athena (zstd estándar, diccionario/RLE) sin ningún codec propietario. Puede realizar un rollback en cualquier momento, y los datos optimizados se leen con las herramientas habituales de Athena.
¿Cómo sabe S4 Scan qué optimizar?
Aprende del historial de consultas de Athena —qué columnas se leen y qué predicados filtran sus tablas— y obtiene el orden de las columnas, las partition keys y las sort keys recomendadas. Se basa en patrones de acceso reales, sin suposiciones.
¿Puedo ver cuánto ahorraré antes de confirmar?
Sí. Un dry-run reporta los bytes escaneados actuales frente a los optimizados y la diferencia mensual en dólares sin escribir nada, atribuyendo honestamente la reducción al pruning de particiones / pruning de row-groups, dictionary+zstd y la compactación. El titular del 30–70% es un rango que depende de qué tan desalineada esté la distribución de sus datos —no es una garantía—, por lo que le sugerimos comenzar con un dry-run en su propia tabla.
¿Dónde se ejecuta y salen mis datos de mi cuenta?
Se ejecuta como una AMI dentro de su propia cuenta de AWS y VPC, accediendo únicamente a sus recursos de S3, Glue y Athena —sus datos nunca salen. Funciona de forma automatizada mediante una programación de EventBridge bajo un rol de IAM con privilegios mínimos.
Modelo de precios
Tarifa horaria de software + EC2 (clase t3 / m5), con una oferta de pago por GB procesado también disponible. Opción anual disponible.
Otros productos S4
S4 — Squished S3
Gateway transparente de compresión S3 con GPU
S4 Logs
Archiva CloudWatch Logs en S3 con zstd
S4 Metrics
Gobierna la cardinalidad de métricas de CloudWatch