# Prevenir o controle de utilização do Amazon S3
O controle de utilização é o processo de limitar sua taxa de uso de um serviço, uma aplicação ou um sistema. Na AWS, você pode usar o controle de utilização para evitar o uso excessivo do serviço Amazon S3 e aumentar a disponibilidade e a capacidade de resposta do Amazon S3 para todos os usuários. Porém, como o controle de utilização limita a taxa de transferências de dados de entrada e saída do Amazon S3, é importante tentar evitar que suas interações sejam limitadas.
Conforme apontado no capítulo de [ajuste de performance](performance-tuning.md), as otimizações podem depender de suas decisões de nível de serviço, de como você estrutura suas tabelas e dados e de como você escreve suas consultas.
**Topics**
+ [Reduzir o controle de utilização no nível de serviço](performance-tuning-s3-throttling-reduce-throttling-at-the-service-level.md)
+ [Otimizar suas tabelas](performance-tuning-s3-throttling-optimizing-your-tables.md)
+ [Otimizar suas consultas](performance-tuning-s3-throttling-optimizing-queries.md)
# Reduzir o controle de utilização no nível de serviço
Para evitar o controle de utilização do Amazon S3 no nível do serviço, é possível monitorar o uso e ajustar as [cotas de serviço](https://docs.aws.amazon.com/general/latest/gr/s3.html#limits_s3) ou usar certas técnicas, como particionamento. Estas são algumas das condições que podem levar ao controle de utilização:
+ **Exceder os limites de solicitação de API da conta**: o Amazon S3 tem limites de solicitação de API padrão baseados no tipo e no uso da conta. Se você exceder o número máximo de solicitações por segundo para um único prefixo, as solicitações poderão ser limitadas para evitar a sobrecarga do serviço Amazon S3.
+ **Particionamento de dados insuficiente**: se você não particionar os dados corretamente e transferir uma grande quantidade de dados, o Amazon S3 poderá limitar as solicitações. Para obter mais informações sobre particionamento, consulte a seção [Usar particionamento](performance-tuning-s3-throttling-optimizing-your-tables.md#performance-tuning-s3-throttling-use-partitioning) deste documento.
+ **Grande quantidade de objetos pequenos**: se possível, evite uma grande quantidade de arquivos pequenos. O Amazon S3 tem um limite de [5500 solicitações GET](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) por segundo por prefixo particionado, e suas consultas do Athena compartilham esse mesmo limite. Se você verificar milhões de objetos pequenos em uma única consulta, provavelmente o Amazon S3 limitará a consulta.
Para evitar verificação em excesso, você pode usar o recurso ETL do AWS Glue para compactar periodicamente os arquivos ou particionar a tabela e adicionar filtros de chave de partição. Para obter mais informações, consulte os recursos a seguir.
+ [Como posso configurar um trabalho de ETL do AWS Glue para gerar arquivos maiores?](https://aws.amazon.com/premiumsupport/knowledge-center/glue-job-output-large-files/) (*AWS Central de conhecimento da*)
+ [Ler arquivos de entrada em grupos maiores](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) (*Guia do desenvolvedor do AWS Glue*)
# Otimizar suas tabelas
Caso você encontre problemas de controle de utilização, é importante estruturar os dados. Embora o Amazon S3 consiga lidar com grandes quantidades de dados, às vezes o controle de utilização ocorre devido à forma como os dados são estruturados.
As seções a seguir oferecem algumas sugestões sobre como estruturar dados no Amazon S3 para evitar problemas de controle de utilização.
## Usar particionamento
É possível usar o particionamento para reduzir o controle de utilização limitando a quantidade de dados que precisam ser acessados a qualquer momento. Ao particionar dados em colunas específicas, você pode distribuir as solicitações de maneira uniforme entre vários objetos e reduzir o número de solicitações para um único objeto. Reduzir a quantidade de dados que devem ser verificados melhora a performance da consulta e reduz os custos.
Ao criar uma tabela, você pode definir partições que atuam como colunas virtuais. Para criar uma tabela com partições em uma instrução `CREATE TABLE`, use a cláusula `PARTITIONED BY (column_name data_type)` para definir as chaves para particionar dados.
Para restringir as partições verificadas por uma consulta, é possível especificá-las como predicados em uma cláusula `WHERE` da consulta. Portanto, colunas usadas como filtros com frequência são boas candidatas para particionamento. Uma prática comum é particionar os dados com base na hora, o que pode acarretar um esquema de particionamento em vários níveis.
O particionamento também tem um custo. Quando você aumenta o número de partições na tabela, o tempo necessário para recuperar e processar os metadados da partição também aumenta. Assim, o particionamento excessivo pode remover os benefícios obtidos ao particionar de forma mais criteriosa. Se os dados estiverem muito distorcidos para um valor de partição e a maioria das consultas usar esse valor, você poderá incorrer em aumento de sobrecarga.
Para obter mais informações sobre particionamento no Athena, consulte [O que é particionamento?](ctas-partitioning-and-bucketing-what-is-partitioning.md).
## Classificar dados em bucket
Outra forma de particionar dados é classificá-los em buckets dentro de uma única partição. Com o bucketing, você especifica uma ou mais colunas que contêm linhas que deseja agrupar. Em seguida, você coloca essas linhas em vários buckets. Dessa forma, você consulta somente o bucket que deve ser lido, reduzindo o número de linhas de dados que devem ser verificados.
Ao selecionar uma coluna que será usada para bucketing, selecione a coluna que tenha alta cardinalidade (ou seja, que tenha muitos valores distintos), esteja uniformemente distribuída e seja usada com frequência para filtrar os dados. Um exemplo de uma boa coluna a ser usada para bucketing é uma chave primária, como uma coluna de ID.
Para obter mais informações sobre bucketing no Athena, consulte [O que é bucketing?](ctas-partitioning-and-bucketing-what-is-bucketing.md)
## Usar índices de partição do AWS Glue
Você pode usar índices de partição do AWS Glue para organizar dados em uma tabela com base nos valores de uma ou mais partições. Os índices de partição do AWS Glue podem reduzir o número de transferências de dados, a quantidade de processamento de dados e o tempo de processamento das consultas.
Um índice de partição do AWS Glue é um arquivo de metadados que contém informações sobre as partições da tabela, inclusive as chaves da partição e seus valores. O índice da partição é armazenado em um bucket do Amazon S3 e atualizado automaticamente pelo AWS Glue à medida que novas partições são adicionadas à tabela.
Quando há um índice de partição do AWS Glue presente, as consultas tentam buscar um subconjunto das partições em vez de carregar todas as partições na tabela. As consultas são executadas somente no subconjunto de dados relevante para a consulta.
Ao criar uma tabela no AWS Glue, é possível criar um índice de partição em qualquer combinação de chaves de partição definidas na tabela. Depois de criar um ou mais índices de partição em uma tabela, é necessário adicionar uma propriedade à tabela que habilite a filtragem de partições. Em seguida, você pode consultar a tabela no Athena.
Para obter informações sobre como criar índices de partição no AWS Glue, consulte [Trabalhar com índices de partição no AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) no *Guia do desenvolvedor do AWS Glue*. Para obter informações sobre como adicionar uma propriedade de tabela para habilitar a filtragem de partições, consulte [Otimizar consultas com indexação e filtragem de partições do AWS Glue](glue-best-practices-partition-index.md).
## Usar compactação de dados e divisão de arquivos
A compactação de dados pode acelerar consideravelmente as consultas se os arquivos estiverem no tamanho ideal ou se puderem ser divididos em grupos lógicos. Geralmente, taxas de compactação mais altas necessitam de mais ciclos de CPU para compactar e descompactar os dados. Para o Athena, recomendamos usar o Apache Parquet ou o Apache ORC, que compactam dados por padrão. Para obter mais informações sobre compactação de dados no Athena, consulte [Usar compactação no Athena](compression-formats.md).
A divisão de arquivos aumenta o paralelismo ao permitir que o Athena distribua a tarefa de ler um único arquivo entre vários leitores. Se um único arquivo não foi divisível, somente um único leitor poderá ler o arquivo enquanto outros leitores estiverem ociosos. O Apache Parquet e o Apache ORC também são compatíveis com arquivos divisíveis.
## Use armazenamentos de dados em colunas otimizados
A performance da consulta do Athena melhorará consideravelmente se você converter os dados para um formato em colunas. Ao gerar arquivos em colunas, uma técnica de otimização a ser considerada é ordenar os dados com base na chave de partição.
O Apache Parquet e o Apache ORC são armazenamentos de dados em colunas de código aberto bastante usados. Para obter informações sobre como converter a fonte de dados existente do Amazon S3 para um desses formatos, consulte [Converter em formatos colunares](columnar-storage.md#convert-to-columnar).
### Usar um tamanho de bloco do Parquet ou tamanho de faixa ORC maior
O Parquet e o ORC têm parâmetros de armazenamento de dados que podem ser ajustados para otimização. No Parquet, é possível otimizar o tamanho do bloco. No ORC, é possível otimizar o tamanho da faixa. Quanto maior o bloco ou a faixa, mais linhas você poderá armazenar em cada um deles. Por padrão, o tamanho do bloco Parquet é 128 MB, e o tamanho da faixa ORC é 64 MB.
Se uma faixa ORC for menor que 8 MB (o valor padrão de `hive.orc.max_buffer_size`), o Athena lerá toda a faixa ORC. É a compensação que o Athena faz entre a seletividade da coluna e as operações de entrada e saída por segundo para faixas menores.
Se houver tabelas com um número muito grande de colunas, um tamanho pequeno de bloco ou de faixa pode fazer com que sejam verificados mais dados do que o necessário. Nesses casos, um tamanho maior de bloco pode ser mais eficiente.
### Usar ORC para tipos complexos
Atualmente, ao consultar colunas armazenadas em Parquet que tenham tipos de dados complexos (por exemplo, `array`, `map` ou `struct`), o Athena lê a linha de dados inteira em vez de somente as colunas especificadas seletivamente. Este é um problema conhecido do Athena. Como solução alternativa, considere usar o ORC.
### Escolher um algoritmo de compactação
Outro parâmetro que pode ser configurado é o algoritmo de compactação nos blocos de dados. Para obter informações sobre os algoritmos de compactação compatíveis com Parquet e ORC no Athena, consulte [Suporte a compactação no Athena](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html).
Para obter mais informações sobre a otimização de formatos de armazenamento em colunas no Athena, consulte a seção “Otimizar a geração de armazenamento de dados em colunas” na publicação do AWS Big Data Blog [As dez melhores dicas de ajuste de performance para o Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/).
## Usar tabelas Iceberg
Apache Iceberg é um formato de tabela aberta para conjuntos de dados analíticos muito grandes, criado para otimizar o uso do Amazon S3. Você pode usar as tabelas Iceberg para ajudar a reduzir o controle de utilização no Amazon S3.
As tabelas Iceberg oferecem as seguintes vantagens:
+ É possível dividir as tabelas Iceberg em partições de uma ou mais colunas. Isso otimiza o acesso aos dados e reduz a quantidade de dados que deverão ser verificados por meio de consultas.
+ Como o modo de armazenamento de objetos do Iceberg otimiza as tabelas Iceberg para funcionar com o Amazon S3, ele pode processar grandes volumes de dados e workloads de consultas pesadas.
+ As tabelas Iceberg no modo de armazenamento de objetos são escaláveis, tolerantes a falhas e duráveis, o que pode ajudar a reduzir o controle de utilização.
+ Com o suporte à transação ACID, vários usuários podem adicionar e excluir objetos do Amazon S3 de forma atômica.
Para obter mais informações sobre o Apache Iceberg, consulte [Apache Iceberg](https://iceberg.apache.org/). Para obter mais informações sobre como usar tabelas Apache Iceberg no Athena, consulte [Usar tabelas Iceberg](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg.html).
# Otimizar suas consultas
Use as sugestões desta seção para otimizar as consultas SQL no Athena.
## Usar LIMIT com a cláusula ORDER BY
A cláusula `ORDER BY` retorna dados em uma ordem classificada. Isso exige que o Athena envie todas as linhas de dados para um único nó de processamento e classifique as linhas. Esse tipo de consulta pode ser executado por muito tempo ou pode até falhar.
Para aumentar a eficiência das consultas, observe os valores *N* superiores ou inferiores e use também uma cláusula `LIMIT`. Isso reduz significativamente o custo de classificação, inserindo tanto a classificação como a limitação em nós de processamento individuais, e não em um único operador.
## Otimizar cláusulas JOIN
Quando você une duas tabelas, o Athena distribui a tabela à direita para os nós de processamento e transmite a tabela à esquerda para realizar a junção.
Por isso, especifique a tabela maior no lado esquerdo da junção e a tabela menor no lado direito da junção. Assim, o Athena usa menos memória e executa a consulta com menor latência.
Observe também os seguintes pontos:
+ Ao usar vários comandos `JOIN`, especifique as tabelas da maior para a menor.
+ Evite junções cruzadas, a menos que sejam exigidas pela consulta.
## Otimizar cláusulas GROUP BY
O operador `GROUP BY` distribui as linhas com base nas colunas `GROUP BY` para os nós de processamento. Essas colunas são referenciadas na memória, e os valores são comparados à medida que as linhas são ingeridas. Os valores são agregados quando a coluna `GROUP BY` coincide. Considerando a forma como o processo funciona, é aconselhável ordenar as colunas da maior cardinalidade para a menor.
## Usar números em vez de strings
Como os números exigem menos memória e são mais rápidos de processar em comparação com as strings, use números em vez de strings quando possível.
## Limitar o número de colunas
Para reduzir a quantidade total de memória necessária para armazenar os dados, limite o número de colunas especificado na instrução `SELECT`.
## Usar expressões regulares em vez de LIKE
Consultas que incluem cláusulas como `LIKE '%string%'` em strings grandes podem fazer uso muito intensivo de computação. Ao filtrar por vários valores em uma coluna de string, use a função [regexp\$1like()](https://trino.io/docs/current/functions/regexp.html#regexp_like) e uma expressão regular. Isso é útil especialmente ao comparar uma longa lista de valores.
## Usar a cláusula LIMIT
Em vez de selecionar todas as colunas ao executar uma consulta, use a cláusula `LIMIT` para retornar somente as colunas necessárias. Essa ação reduz o tamanho do conjunto de dados que é processado pelo pipeline de execução da consulta. As cláusulas `LIMIT` são mais úteis ao consultar tabelas que têm um grande número de colunas baseadas em strings. As cláusulas `LIMIT` também são úteis ao executar várias junções ou agregações em qualquer consulta.