S4 Scan
Redutor de custo de scan do Athena
Reduza sua conta de scan do AWS Athena e Redshift Spectrum em 30–70% reotimizando o Parquet do seu data lake S3 para o layout que suas consultas realmente leem — pruning de partições e row groups, dictionary encoding, zstd e compactação de arquivos pequenos — aplicado por um shadow-then-swap seguro que nunca altera os resultados das consultas.
S4 Scan aprende com o histórico de consultas do Athena quais colunas são lidas e quais predicados filtram suas tabelas, depois reescreve o Parquet S3 subjacente no layout físico que essas consultas precisam: colunas quentes primeiro, ordenado pelas colunas usadas em filtros para que estatísticas de row group façam pruning, colunas de baixa cardinalidade com dictionary encoding, arquivos compactados para um tamanho eficiente e comprimidos com zstd. Athena e Redshift Spectrum cobram por terabyte escaneado do S3, então um layout menor e mais fácil de podar reduz diretamente a conta de forma recorrente. Segurança é o núcleo do produto — sua fonte nunca é sobrescrita.
O problema
O Athena e o Redshift Spectrum cobram com base nos bytes realmente lidos do S3 (padrão de $5/TB, dependendo da região). Quando o layout físico do seu Parquet não corresponde à forma como as consultas o acessam, cada consulta escaneia muito mais do S3 do que retorna — e você paga por essa diferença todo mês. Como a fatura é baseada nos bytes escaneados, o próprio layout define o seu custo.
Como funciona
- 1
Aprenda com o histórico de consultas
Ele lê seu catálogo do Glue e o histórico de consultas do Athena (métricas de workgroup, CloudTrail) para aprender quais colunas cada tabela realmente lê e quais predicados a filtram.
- 2
Escreva em shadow e depois verifique
Ele grava o Parquet otimizado em um local shadow separado e verifica se os resultados da consulta são idênticos até nos valores, NULLs, escala decimal e fuso horário do timestamp.
- 3
Swap via Glue, com rollback
Apenas após a verificação ser aprovada, ele redireciona o local da tabela do Glue — uma movimentação de ponteiro do catálogo, não uma movimentação de dados — reversível com um único comando de rollback.
Destaques
Seguro por construção: os dados otimizados são gravados em uma localização shadow, verificados como idênticos nos resultados de consulta (valores, nulls, escala decimal, timestamp tz) e então trocados via Glue catalog — com rollback em um comando. Os dados de origem nunca são modificados in-place.
Veja a economia antes de confirmar: um dry-run projeta a redução mensal em dólares nas suas tabelas reais e a atribui de forma honesta a pruning, dictionary + zstd e compactação de arquivos pequenos.
Sem lock-in, sem babysitting: a saída é Parquet padrão legível pelo Athena, e a AMI reotimiza em uma programação do EventBridge para que a economia se acumule automaticamente.
O que está incluído
- Análise do histórico de consultas: deriva colunas quentes, predicados frequentes e candidatos a chaves de partição/ordenação a partir de suas consultas anteriores em um plano de otimização.
- Poda de partição e de row-group: realiza uma nova partição com base em suas chaves de predicado para que arquivos inteiros sejam ignorados, e ordena pelas colunas de filtro para que as estatísticas de mínimo/máximo permitam pular a leitura de row-groups não correspondentes.
- Codificação por dicionário/RLE + zstd: colunas de baixa cardinalidade são codificadas por dicionário e recompactadas com zstd padrão compatível com o Athena para reduzir os bytes de leitura projetados.
- Compactação de pequenos arquivos: mescla muitos objetos minúsculos em menos arquivos com o tamanho ideal para eficiência de I/O e melhores estatísticas.
- Shadow → verificação → swap com rollback de um comando: a origem nunca é modificada no local, e a transição é apenas uma movimentação de ponteiro do Glue.
- Projeção de economia com dry-run: sem realizar gravações, ele informa os bytes escaneados atuais vs. otimizados e a diferença mensal em dólares, atribuindo honestamente a economia à poda de partição / poda de row-group / dicionário+zstd / compactação.
- Reotimização agendada via EventBridge, com saída em Parquet padrão compatível com o Athena — sem lock-in.
Casos de uso
Custos altos de escaneamento do Athena/Redshift Spectrum que você deseja reduzir sem reescrever nenhum SQL.
Tabelas largas onde as consultas leem apenas algumas colunas e filtram por poucos predicados, mas ainda assim escaneiam o arquivo inteiro.
Data lakes fragmentados em muitos objetos Parquet pequenos, prejudicando a eficiência de I/O e as estatísticas.
Conjuntos de dados em crescimento que se beneficiam de reotimização recorrente agendada via EventBridge.
FAQ
Isso pode corromper meus dados ou alterar os resultados das minhas consultas?
A origem nunca é modificada no local. Os dados otimizados são gravados em um local shadow separado e verificados como idênticos — valores, NULLs, escala decimal, fuso horário do timestamp, tipos aninhados — antes que apenas o ponteiro do Glue seja movido. Se a verificação falhar, o swap não ocorre; o local shadow é descartado e a origem permanece intacta. Após o swap, um único comando restaura o local original.
Ficarei preso a um formato proprietário?
Não. A saída é apenas Parquet padrão legível pelo Athena (zstd padrão, dicionário/RLE) sem nenhum codec proprietário. Você pode fazer rollback a qualquer momento, e os dados otimizados podem ser lidos com as ferramentas normais do Athena.
Como o S4 Scan sabe o que otimizar?
Ele aprende com o histórico de consultas do Athena — quais colunas são lidas e quais predicados filtram suas tabelas — e deriva a recomendação de ordenação de colunas, chaves de partição e chaves de ordenação. Ele é baseado em padrões de acesso reais, e não em suposições.
Posso ver quanto vou economizar antes de me comprometer?
Sim. Um dry-run informa os bytes escaneados atuais vs. otimizados e a diferença mensal em dólares sem gravar nada, atribuindo honestamente a redução à poda de partição/row-group, dicionário+zstd e compactação. O valor de destaque de 30–70% é uma faixa que depende de quão desalinhado está o seu layout — não uma garantia —, por isso comece com um dry-run na sua própria tabela.
Onde ele é executado e os meus dados saem da minha conta?
Ele é executado como uma AMI dentro da sua própria conta AWS e VPC, acessando apenas o seu S3, Glue e Athena — seus dados nunca saem. Ele opera sem intervenção manual em um agendamento do EventBridge sob uma função IAM de privilégio mínimo.
Modelo de precificação
Taxa horária de software + EC2 (classe t3 / m5), com oferta pay-per-GB-processed também disponível. Opção anual disponível.
Outros produtos S4
S4 — Squished S3
Gateway transparente de compressão S3 com GPU
S4 Logs
Arquive CloudWatch Logs em S3 com zstd
S4 Metrics
Controle a cardinalidade de métricas do CloudWatch