Otimizar dados

A performance não depende apenas das consultas, mas também, principalmente, de como seu conjunto de dados está organizado e do formato de arquivo e da compactação que ele usa.

Particionar dados

O particionamento divide a tabela em partes e mantém os dados relacionados juntos com base em propriedades como data, país ou região. As chaves de partição atuam como colunas virtuais. Você define as chaves de partição na criação da tabela e as utiliza para filtrar consultas. Quando você filtra as colunas das chaves de partição, somente os dados das partições correspondentes são lidos. Por exemplo, se o conjunto de dados estiver particionado por data e a consulta tiver um filtro que corresponda somente à última semana, somente os dados da última semana serão lidos. Para obter mais informações sobre particionamento, consulte Particionar dados.

Escolher chaves de partição que oferecerão suporte às suas consultas

Como o particionamento tem um impacto significativo na performance da consulta, pense com atenção em como você particionará ao criar seu conjunto de dados e tabelas. Ter muitas chaves de partição pode resultar em conjuntos de dados fragmentados com excesso de arquivos e arquivos muito pequenos. Por outro lado, ter poucas chaves de partição ou não ter particionamento leva a consultas que examinam mais dados do que o necessário.

Evitar otimização de consultas raras

Uma boa estratégia é otimizar as consultas mais comuns e evitar a otimização de consultas raras. Por exemplo, se as consultas analisarem períodos de dias, não particione por hora, mesmo que algumas consultas sejam filtradas até esse nível. Se seus dados tiverem uma coluna de timestamp granular, as consultas raras que filtram por hora poderão usar a coluna de timestamp. Mesmo que casos raros verifiquem um pouco mais de dados do que o necessário, reduzir a performance geral em prol de casos raros geralmente não é vantajoso.

Para reduzir a quantidade de dados que as consultas precisam verificar e, assim, melhorar a performance, use um formato de arquivo colunar e mantenha os registros ordenados. Em vez de particionar por hora, mantenha os registros classificados por carimbo de data e hora. Para consultas em janelas de tempo mais curtas, a classificação por carimbo de data e hora é quase tão eficiente quanto a partição por hora. Além disso, a classificação por carimbo de data e hora normalmente não prejudica a performance das consultas nas janelas de tempo contadas em dias. Para ter mais informações, consulte Usar formatos de arquivo colunares.

As consultas em tabelas com dezenas de milhares de partições terão melhor performance se houver predicados em todas as chaves de partição. Esse é outro motivo para criar um esquema de particionamento para as consultas mais comuns. Para ter mais informações, consulte Consultar partições por igualdade.

Usar projeção de partições

A projeção de partição é um atributo do Athena que armazena informações de partição não no AWS Glue Data Catalog, mas como regras nas propriedades da tabela no AWS Glue. Ao planejar uma consulta em uma tabela configurada com projeção de partição, o Athena lê as regras de projeção de partição da tabela. O Athena calcula as partições a serem lidas na memória com base na consulta e nas regras, em vez de procurar partições no AWS Glue Data Catalog.

Além de simplificar o gerenciamento de partições, a projeção de partições pode melhorar a performance de conjuntos de dados que têm um grande número de partições. Quando a consulta contém intervalos em vez de valores específicos para chaves de partição, a busca por partições correspondentes no catálogo demora mais quanto mais partições houver. Com a projeção de partição, o filtro pode ser computado na memória sem acessar o catálogo e pode ser muito mais rápido.

Em determinadas circunstâncias, a projeção de partições pode resultar em pior performance. Um exemplo ocorre quando uma tabela é “avulsa”. Uma tabela avulsa não tem dados para cada permutação dos valores da chave de partição descritos pela configuração da projeção da partição. Com uma tabela avulsa, o conjunto de partições calculado com base na consulta e a configuração da projeção da partição são listados no Amazon S3, mesmo quando não contêm dados.

Ao usar a projeção de partição, verifique se incluiu predicados em todas as chaves de partição. Limite o escopo dos valores possíveis para evitar listas desnecessárias do Amazon S3. Imagine uma chave de partição que contenha um intervalo de um milhão de valores e uma consulta que não tenha nenhum filtro nessa chave de partição. Para executar a consulta, o Athena deverá realizar pelo menos um milhão de operações de lista do Amazon S3. As consultas são mais rápidas quando você consulta valores específicos, independentemente de usar a projeção de partição ou armazenar informações de partição no catálogo. Para ter mais informações, consulte Consultar partições por igualdade.

Ao configurar uma tabela para projeção de partições, verifique se os intervalos especificados são razoáveis. Se a consulta não incluir um predicado em uma chave de partição, todos os valores no intervalo dessa chave serão usados. Se o conjunto de dados foi criado em uma data específica, use essa data como ponto de partida para qualquer intervalo de datas. Use NOW como fim de intervalos de datas. Evite intervalos numéricos que tenham um grande número de valores e considere usar o tipo injected em vez disso.

Para obter mais informações sobre projeção de partições, consulte Usar projeção de partições com o Amazon Athena.

Usar índices de partição

Os índices de partição são um atributo do AWS Glue Data Catalog que melhoram a performance da pesquisa de partições para tabelas que têm um grande número de partições.

A lista de partições do catálogo é como uma tabela em um banco de dados relacional. A tabela contém colunas para as chaves de partição e uma coluna adicional para o local da partição. Quando você consulta uma tabela particionada, os locais das partições são pesquisados por meio da verificação dessa tabela.

Assim como nos bancos de dados relacionais, é possível aumentar a performance das consultas adicionando índices. É possível adicionar vários índices para oferecer suporte a diferentes padrões de consulta. O índice de partição do AWS Glue Data Catalog é compatível com operadores de igualdade e comparação, como >, >= e < combinados com o operador AND. Para obter mais informações, consulte Working with partition indexes in AWS Glue no Guia do desenvolvedor do AWS Glue e Improve Amazon Athena query performance using AWS Glue Data Catalog partition indexes no blog de big data da AWS.

Use sempre STRING como o tipo para chaves de partição

Ao consultar chaves de partição, lembre-se de que o Athena exige que as chaves de partição sejam do tipo STRING para inserir a filtragem de partição no AWS Glue. Se o número de partições não for pequeno, usar outros tipos poderá reduzir a performance. Se os valores da chave de partição forem semelhantes a uma data ou a um número, converta-os ao tipo apropriado em sua consulta.

Remover partições antigas e vazias

Se você remover dados de uma partição no Amazon S3 (por exemplo, usando o ciclo de vida do Amazon S3), também deverá remover a entrada da partição do AWS Glue Data Catalog. Durante o planejamento da consulta, toda partição correspondente à consulta é listada no Amazon S3. Se houver muitas partições vazias, a sobrecarga de listar essas partições poderá ser prejudicial.

Além disso, se houver milhares de partições, considere remover os metadados da partição de dados antigos que não são mais relevantes. Por exemplo, se as consultas nunca buscarem dados com mais de um ano, você poderá remover periodicamente os metadados das partições mais antigas. Se o número de partições aumentar para dezenas de milhares, remover partições não utilizadas pode acelerar as consultas que não incluem predicados em todas as chaves de partição. Para obter informações sobre como incluir predicados em todas as chaves de partição de suas consultas, consulte Consultar partições por igualdade.

Consultar partições por igualdade

As consultas que contêm predicados de igualdade em todas as chaves de partição são executadas mais rapidamente porque os metadados da partição podem ser carregados diretamente. Evite consultas nas quais uma ou mais chaves de partição não tenham um predicado, ou o predicado seleciona uma faixa de valores. Para essas consultas, a lista de todas as partições deverá ser filtrada para encontrar valores correspondentes. Para a maioria das tabelas, a sobrecarga é mínima, mas para tabelas com dezenas de milhares de partições ou mais, a sobrecarga pode ser considerável.

Se não for possível gravar novamente suas consultas para filtrar partições por igualdade, você pode tentar a projeção de partições. Para ter mais informações, consulte Usar projeção de partições.

Evitar usar MSCK REPAIR TABLE para manutenção de partições

Como MSCK REPAIR TABLE pode levar muito tempo para ser executado, apenas adiciona novas partições e não remove partições antigas, não é uma forma eficiente de gerenciar partições (consulte Considerações e limitações).

É melhor gerenciar partições manualmente usando as APIs do AWS Glue Data Catalog, ALTER TABLE ADD PARTITION ou crawlers do AWS Glue. Se preferir, você pode usar a projeção de partições, que elimina totalmente a necessidade de gerenciar as partições. Para ter mais informações, consulte Usar projeção de partições com o Amazon Athena.

Verifique se suas consultas são compatíveis com o esquema de particionamento

É possível verificar com antecedência quais partições uma consulta examinará usando a instrução EXPLAIN. Prefixe sua consulta com a palavra-chave EXPLAIN e procure o fragmento de origem (por exemplo Fragment 2 [SOURCE]) para cada tabela na parte inferior da saída de EXPLAIN. Procure atribuições em que o lado direito esteja definido como chave de partição. A linha abaixo contém uma lista de todos os valores dessa chave de partição que serão verificados quando a consulta for executada.

Por exemplo, digamos que você tenha uma consulta em uma tabela com uma chave de partição dt e prefixe a consulta com EXPLAIN. Se os valores da consulta forem datas e um filtro selecionar um intervalo de três dias, a saída de EXPLAIN poderá ser mais ou menos assim:

dt := dt:string:PARTITION_KEY
    :: [[2023-06-11], [2023-06-12], [2023-06-13]]

A saída de EXPLAIN mostra que o planejador encontrou três valores para essa chave de partição que corresponderam à consulta. Ela também mostra quais são esses valores. Para obter mais informações sobre o uso de EXPLAIN, consulte Usar EXPLAIN e EXPLAIN ANALYZE no Athena e Noções básicas dos resultados da instrução EXPLAIN do Athena.

Usar formatos de arquivo colunares

Formatos de arquivo colunar, como Parquet e ORC, foram criados para workloads de analytics distribuídas. Eles organizam os dados por coluna, não por linha. Organizar os dados em formato colunar oferece as seguintes vantagens:

Como exemplo de como podemos usar os metadados do arquivo, os metadados do arquivo podem conter informações sobre os valores mínimo e máximo em uma página de dados. Se os valores consultados não estiverem no intervalo indicado nos metadados, a página poderá ser ignorada.

Uma forma de usar esses metadados para melhorar a performance é garantir que os dados dos arquivos sejam classificados. Por exemplo, digamos que você tenha consultas que buscam registros em que a entrada created_at esteja em um curto espaço de tempo. Se seus dados forem classificados pela coluna created_at, o Athena poderá usar os valores mínimo e máximo dos metadados do arquivo para ignorar as partes desnecessárias dos arquivos de dados.

Ao usar formatos de arquivo colunar, verifique se seus arquivos não são pequenos demais. Conforme observado em Evite ter uma quantidade muito grande de arquivos, conjuntos de dados com muitos arquivos pequenos causam problemas de performance. Isso ocorre especialmente com formatos de arquivo colunar. Em arquivos pequenos, a sobrecarga do formato de arquivo colunar supera os benefícios.

O Parquet e o ORC são organizados internamente por grupos de linhas (Parquet) e faixas (ORC). O tamanho padrão para grupos de linhas é 128 MB, e para faixas, 64 MB. Se houver muitas colunas, você poderá aumentar o grupo de linhas e o tamanho da faixa para melhorar a performance. Não é recomendável diminuir o tamanho do grupo de linhas ou da faixa para um valor inferior ao padrão.

Para converter outros formatos de dados em Parquet ou ORC, você pode usar o AWS Glue ETL ou o Athena. Para ter mais informações, consulte Converter em formatos colunares.

Compactar dados

O Athena é compatível com uma ampla variedade de formatos de compactação. Consultar dados compactados é mais rápido e mais barato, pois você paga pelo número de bytes verificados antes da descompactação.

O formato gzip fornece boas taxas de compactação e oferece amplo suporte a outras ferramentas e serviços. O formato zstd (Zstandard) é um formato de compactação mais recente com um bom equilíbrio entre performance e taxa de compactação.

Ao compactar arquivos de texto, como dados JSON e CSV, tente chegar a um equilíbrio entre o número de arquivos e o tamanho dos arquivos. A maioria dos formatos de compactação exige que o leitor leia os arquivos desde o início. Isso significa que, em geral, os arquivos de texto compactados não podem ser processados em paralelo. Arquivos grandes não compactados muitas vezes são divididos entre operadores para obter maior paralelismo durante o processamento da consulta, mas isso não é possível com a maioria dos formatos de compactação.

Conforme discutido em Evite ter uma quantidade muito grande de arquivos, é melhor não ter uma quantidade muito grande nem muito pequena de arquivos. Como o número de arquivos é o limite de quantos operadores podem processar a consulta, essa regra se aplica principalmente a arquivos compactados.

Para obter mais informações sobre uso de compactação no Athena, consulte Usar compactação no Athena.

Usar bucketing para pesquisas em chaves com alta cardinalidade

O bucketing é uma técnica para distribuir registros em arquivos separados com base no valor de uma das colunas. Isso garante que todos os registros com o mesmo valor estejam no mesmo arquivo. O bucketing é útil quando você tem uma chave com alta cardinalidade e muitas de suas consultas buscam valores específicos da chave.

Por exemplo, digamos que você consulte um conjunto de registros de um usuário específico. Se os dados forem agrupados em bucket por ID de usuário, o Athena saberá com antecedência quais arquivos contêm registros para um ID específico e quais não. Isso permite que o Athena leia somente os arquivos que possam conter o ID, reduzindo consideravelmente a quantidade de dados lidos. Também reduz o tempo de computação que, de outra forma, seria necessário para pesquisar os dados em busca do ID específico.

Como evitar bucketing quando as consultas frequentemente pesquisam vários valores em uma coluna

O bucketing é menos vantajoso quando as consultas frequentemente pesquisam vários valores na coluna pela qual os dados são agrupados em bucket. Quanto mais valores forem consultados, maior será a probabilidade de que seja necessário ler todos ou a maioria dos arquivos. Por exemplo, se você tiver três buckets e uma consulta procurar três valores diferentes, talvez seja necessário ler todos os arquivos. O bucketing funciona melhor quando as consultas pesquisam valores únicos.

Para ter mais informações, consulte Usar particionamento e bucketing.

Evite ter uma quantidade muito grande de arquivos

Conjuntos de dados que consistem em muitos arquivos pequenos resultam em baixo desempenho geral da consulta. Ao planejar uma consulta, o Athena lista todos os locais das partições, o que leva tempo. O tratamento e a solicitação de cada arquivo também geram uma sobrecarga computacional. Portanto, é mais rápido carregar um único arquivo maior do Amazon S3 do que carregar os mesmos registros de muitos arquivos menores.

Em casos extremos, é possível encontrar limites de serviço do Amazon S3. O Amazon S3 é compatível com até 5.500 solicitações por segundo para uma única partição de índice. Inicialmente, o bucket é tratado como uma única partição de índice, mas à medida que as cargas de solicitações aumentam, ele pode ser dividido em várias partições de índice.

O Amazon S3 analisa os padrões de solicitação e as divisões com base nos prefixos de chave. Se seu conjunto de dados consistir em muitos milhares de arquivos, as solicitações provenientes do Athena poderão exceder a cota de solicitações. Mesmo com menos arquivos, a cota poderá ser excedida se forem feitas várias consultas simultâneas no mesmo conjunto de dados. Outras aplicações que acessam os mesmos arquivos podem contribuir para o número total de solicitações.

Quando o limit da taxa de solicitação é excedido, o Amazon S3 retorna o erro a seguir. Esse erro está incluído nas informações de status da consulta no Athena.

SlowDown: Please reduce your request rate

Para solucionar problemas, comece determinando se o erro foi causado por uma única consulta ou por várias consultas que leem os mesmos arquivos. No último caso, coordene a execução das consultas de modo que não sejam executadas ao mesmo tempo. Para obter isso, adicione um mecanismo de enfileiramento ou até mesmo novas tentativas em sua aplicação.

Se a execução de uma única consulta acionar o erro, tente combinar arquivos de dados ou modificar a consulta para ler menos arquivos. O melhor momento para combinar arquivos pequenos é antes de serem gravados. Para isso, considere as seguintes técnicas:

Evitar hierarquias de armazenamento adicionais além da partição

Para evitar a sobrecarga do planejamento de consultas, armazene os arquivos em uma estrutura plana em cada local da partição. Não use hierarquias de diretório adicionais.

Ao planejar uma consulta, o Athena lista todos os arquivos em todas as partições correspondentes à consulta. Embora o Amazon S3 não tenha diretórios em si, a convenção é interpretar a barra direta / como separador de diretório. Ao listar os locais das partições, o Athena lista recursivamente qualquer diretório que encontrar. Quando os arquivos de uma partição são organizados em hierarquia, ocorrem várias rodadas de listagens.

Quando todos os arquivos estão diretamente no local da partição, na maioria das vezes, apenas uma operação de lista precisa ser executada. Porém, várias operações de lista sequencial serão necessárias se você tiver mais de mil arquivos em uma partição porque o Amazon S3 retorna somente mil objetos por operação de lista. Ter mais de mil arquivos em uma partição também pode criar outros problemas de performance mais graves. Para ter mais informações, consulte Evite ter uma quantidade muito grande de arquivos.

Use SymlinkTextInputFormat somente quando necessário

Usar a técnica SymlinkTextInputFormat pode ser uma forma de resolver situações em que os arquivos da tabela não estão bem organizados em partições. Por exemplo, links simbólicos podem ser úteis quando todos os arquivos estão no mesmo prefixo ou quando há arquivos com esquemas diferentes no mesmo local.

Porém, usar links simbólicos adiciona níveis de indireção à execução da consulta. Esses níveis de indireção afetam a performance geral. Os arquivos de links simbólicos precisam ser lidos, e os locais que eles definem devem ser listados. Isso adiciona muitas viagens de ida e volta ao Amazon S3 que as tabelas habituais do Hive não exigem. Concluindo, você deverá usar SymlinkTextInputFormat somente quando não houver opções melhores disponíveis, como reorganizar arquivos.