Edmilson Prata Escritor

Data Science | Agentic AI | Data Engeneering | AWS Athena

🛑 O problema

Já passou por situações em que seu componente AWS (um Lambda, por exemplo) começou a dar timeout ou situações em que você começou a receber timeout direto do Athena devido a queries pesadas? Esse tipo de coisa acontece porque os profissionais de desenvolvimento, com certa frequência, se esquecem de algo muito importante em operações envolvendo bancos de dados: o custo das operações. É desse cenário específico que vamos tratar aqui.

Além de ocasionar erros de execução como timeout, por exemplo, isso causa um aumento no valor da fatura a ser paga no fim do mês — um problema de Finops. Muitas vezes os desenvolvedores criam soluções onde as queries SQL são geradas de forma dinâmica e isso é um grande perigo. O problema é que essas queries não foram testadas previamente e, sem um mecanismo de controle, os resultados acabam sendo imprevisíveis.

Esse tipo de coisa têm se tornado frequente, por exemplo, em soluções agênticas, onde as queries são criadas por um modelo de LLM hipercontextualizado. Em tempos onde se deseja automatizar processos, trabalhar com componentes inteligentes e eliminar trabalhos repetitivos, a previsibilidade é o primeito elemento oferecido em sacrifício com o intuito de se alcançar, em troca, a tão sonhada automação de alto nível.

💡DryRun — uma solução simples e viável

A boa notícia é que, se você está trabalhando em ambiente AWS com o Athena, existe um recurso chamado DryRun. Ele serve para verificar o custo de uma query antes de executá-la, evitando erros (como timeout) e retornos muito pesados.

Além disso, uma verificação com o DryRun têm potencial de proteger sua solução de acabar provocando um descontrole financeiro repentino. Isso pode ocorrer se o produto, por ação própria (no caso de Agentes) ou ação do usuário final, começar a consumir muitos recursos demais com queries pesadas que a equipe não previu.

O DryRun é um recurso simples que executa muito rápido e retorna em bytes o quanto determinada query consumiria se fosse executada. Isso dá a você a oportunidade de evitar acidentes.

🛠️ Exemplo de implementação

A seguir, um exemplo básico de implementação em Python para você usar como base na sua POC.

import boto3

client = boto3.client('athena')

response = client.start_query_execution(
    QueryString="SELECT * FROM my_table WHERE condition = 'value'",
    WorkGroup="primary",
    QueryExecutionContext={
        'Database': 'my_database'
    },
    ResultConfiguration={
        'OutputLocation': 's3://my-output-bucket/'
    },
    DryRun=True
)

print(response)

Exemplo de retorno do DryRun:

{
    "QueryExecutionId": "12345678-90ab-cdef-1234-567890abcdef",
    "QueryExecution": {
        "Status": {
            "State": "SUCCEEDED"
        },
        "Statistics": {
            "DataScannedInBytes": 10485760,  // Volume de dados processado (em bytes)
            "EngineExecutionTimeInMillis": 0
        }
    }
}

Como você pode observar, o campo DataScannedInBytes é o que retorna o volume de dados que seria processado e dá uma boa ideia do custo da query. Com essa informação você pode estabelecer um limite até onde considera saudável (ou o bolso permite) executar a query no seu produto.

Você pode buscar a média de custo das queries bem sucedidas, por meio de logs, por meio de dados em sua camada RAW/Bronze ou outras fontes de dados históricos. Dessa maneira, é possível estabelecer um limite ótimo até onde a query pode ser executada com segurança. Ultrapassado o limite de segurança, você têm a chance de dar ao usuário final uma mensagem amigável que o oriente a refinar a solicitação para gerar uma query menos custosa.

🎯 Conclusão

É muito bom trabalhar com limites e mecanismos de segurança para garantir o bom funcionamento dos seus produtos. Lembre-se que tudo o que não for controlado tende a se tornar uma fonte de problemas. Limites são importantes porque recursos computacionais não são infinitos (e custam caro). Por isso, sempre estabeleça limites e crie mecanismos para garanti-los.

#dataScience #dataEngeneering #agenticAI #aws #athena