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?.

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?

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 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.

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.

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.

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.

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.

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:

Para obter mais informações sobre o Apache Iceberg, consulte Apache Iceberg. Para obter mais informações sobre como usar tabelas Apache Iceberg no Athena, consulte Usar tabelas Iceberg.