Otimizar consultas do CloudTrail Lake

Esta página oferece orientação sobre como otimizar as consultas do CloudTrail Lake para melhorar a performance e a confiabilidade. Aborda técnicas de otimização específicas, bem como soluções alternativas para falhas comuns em consultas.

Recomendações para otimizar consultas

Siga as recomendações nesta seção para otimizar suas consultas.

Otimizar agregações

A exclusão de colunas redundantes nas cláusulas GROUP BY pode melhorar a performance, pois um número menor de colunas requer menos memória. Por exemplo, na consulta a seguir, podemos usar a função arbitraryem uma coluna redundante, como eventType para melhorar a performance. A função arbitrary em eventType é usada para escolher aleatoriamente o valor do campo no grupo, pois o valor é o mesmo e não precisa ser incluído na cláusula GROUP BY.

SELECT eventName, eventSource, arbitrary(eventType), count(*) 
FROM $EDS_ID 
GROUP BY eventName, eventSource

É possível melhorar a performance da função GROUP BY ordenando a lista dos campos em GROUP BY em ordem decrescente da contagem dos seus valores específicos (cardinalidade). Por exemplo, ao obter o número de eventos de um tipo em cada Região da AWS, a performance pode ser aprimorada usando o eventName, a ordem awsRegion na função GROUP BY em vez de awsRegion, eventName pois há mais valores específicos de eventName do que de awsRegion.

SELECT eventName, awsRegion, count(*) 
FROM $EDS_ID 
GROUP BY eventName, awsRegion

Usar técnicas de aproximação

Sempre que valores exatos não forem necessários para contar valores distintos, use funções agregadas aproximadas para encontrar os valores mais frequentes. Por exemplo, approx_distinct usa muito menos memória e é executado mais rapidamente que a operação COUNT(DISTINCT fieldName).

Limitar resultados de consultas

Se apenas um exemplo de resposta for necessário para uma consulta, restrinja os resultados a um pequeno número de linhas usando a condição LIMIT. Caso contrário, a consulta retornará resultados grandes e levará mais tempo para ser executada.

O uso de LIMIT junto com ORDER BY pode fornecer resultados para os N primeiros ou últimos registros com mais rapidez, pois reduz a quantidade de memória necessária e o tempo gasto para classificar.

SELECT * FROM $EDS_ID
ORDER BY eventTime 
LIMIT 100;

Otimizar consultas LIKE

É possível usar LIKE para encontrar strings correspondentes, mas com strings longas, demanda uso intensivo de computação. Na maioria dos casos, a função regexp_like é uma alternativa mais rápida.

Muitas vezes, é possível otimizar uma pesquisa ancorando a substring que você está procurando. Por exemplo, se estiver procurando por um prefixo, é melhor usar 'substr%' em vez de '% substr %' com o operador LIKE e '^substr' com a função. regexp_like.

Use UNION ALL em vez de UNION

UNION ALL e UNION são duas maneiras de combinar os resultados de duas consultas em um único resultado, mas UNION remove as duplicatas. UNION precisa processar todos os registros e encontrar as duplicatas, o que requer uso intensivo de memória e computação, mas UNION ALL é uma operação relativamente rápida. A menos que você precise desduplicar registros, use UNION ALL para obter a melhor performance.

Incluir somente as colunas obrigatórias

Se não precisar de uma coluna, não a inclua na consulta. Quanto menos dados a consulta precisar processar, mais rápido ela será executada. Se você tiver consultas que executam SELECT * na consulta mais externa, deverá alterar * para uma lista das colunas necessárias.

A cláusula ORDER BY retorna os resultados de uma consulta em ordem de classificação. Ao classificar uma grande quantidade de dados, se a memória necessária não estiver disponível, os resultados intermediários da classificação serão gravados no disco, o que pode retardar a execução da consulta. Se você não precisar estritamente que seu resultado seja classificado, evite adicionar uma cláusula ORDER BY. Além disso, evite adicionar ORDER BY a consultas internas se não for estritamente necessário.

Reduzir o escopo da função de janela

As funções de janela mantêm todos os registros em que operam na memória para calcular seu resultado. Quando a janela é muito grande, a função de janela pode ficar sem memória. Para garantir que suas consultas sejam executadas dentro dos limites de memória disponíveis, reduza o tamanho das janelas durante as quais as funções de janela operam, adicionando a cláusula PARTITION BY.

Às vezes, consultas com funções de janela podem ser gravadas sem funções de janela. Por exemplo, em vez de usar row_number ou rank, você pode usar funções agregadas como max_by ou min_by.

A consulta a seguir encontra o alias atribuído mais recentemente a cada chave do KMS usando max_by.

SELECT element_at(requestParameters, 'targetKeyId') as keyId, 
max_by(element_at(requestParameters, 'aliasName'), eventTime) as mostRecentAlias 
FROM $EDS_ID 
WHERE eventsource = 'kms.amazonaws.com' 
AND eventName in ('CreateAlias', 'UpdateAlias') 
AND eventTime > DATE_ADD('week', -1, CURRENT_TIMESTAMP) 
GROUP BY element_at(requestParameters, 'targetKeyId')

Nesse caso, a função max_by retorna o alias do registro com a hora de evento mais recente do grupo. Essa consulta é executada mais rapidamente e usa menos memória do que uma consulta equivalente com função de janela.

Soluções alternativas para falhas de consulta

Esta seção fornece soluções alternativas para falhas comuns de consulta.

Ocorre uma falha na consulta porque a resposta é muito grande

Poderá ocorrer falha em uma consulta se a resposta for muito grande, resultando na mensagem Query response is too large. Se isso ocorrer, você poderá reduzir o escopo da agregação.

Funções de agregação como array_agg podem gerar pelo menos uma linha na resposta da consulta muito grande, causando a falha da consulta. Por exemplo, usar array_agg(eventName) em vez de array_agg(DISTINCT eventName) aumentará muito o tamanho da resposta devido aos nomes de eventos duplicados de eventos selecionados do CloudTrail.

Ocorre falha na consulta devido à exaustão de recursos

Se não houver memória suficiente disponível durante a execução de operações que consomem muita memória, como junções, agregações e funções de janela, os resultados intermediários o excesso vai para o disco, mas isso retarda a execução da consulta e pode ser insuficiente para evitar que ocorra falha na consulta com Query exhausted resources at this scale factor. Isso pode ser corrigido ao tentar novamente a consulta.

Se os erros acima persistirem mesmo após a otimização da consulta, você poderá definir o escopo da consulta usando o eventTime dos eventos e executar a consulta várias vezes em intervalos menores do intervalo de tempo da consulta original.