Otimizar a performance do Looker

Essas práticas recomendadas são recomendações compartilhadas por uma equipe multifuncional de Lookers experientes. Esses insights são provenientes de anos de experiência trabalhando com clientes do Looker, desde a implementação até o sucesso em longo prazo. As práticas foram escritas para funcionar na maioria dos usuários e situações, mas use o bom senso ao implementar.

Otimizar o desempenho da consulta

Para garantir que as consultas sejam criadas e executadas da maneira ideal no seu banco de dados, siga estas dicas de front-end e back-end:

• Crie Análises detalhadas usando mesclagens de many_to_one sempre que possível. A combinação de visualizações do nível mais granular ao mais alto (many_to_one) normalmente oferece o melhor desempenho de consulta.
• Maximize o armazenamento em cache para sincronizar com suas políticas de ETL sempre que possível e reduzir o tráfego de consultas do banco de dados. Por padrão, o Looker armazena as consultas em cache por uma hora. É possível controlar a política de armazenamento em cache e sincronizar as atualizações de dados do Looker com o processo de ETL aplicando datagroups nas Análises, usando o parâmetro persist_with. Assim, o Looker se integra mais ao pipeline de dados de back-end e maximiza o uso do cache sem o risco de analisar dados desatualizados. As políticas de armazenamento em cache nomeados podem ser aplicadas a um modelo inteiro e/ou a Análises individuais e tabelas derivadas persistentes (TDPs).
• Use a funcionalidade de reconhecimento agregado do Looker para criar visualizações completas ou tabelas de resumo que o Looker possa usar para consultas sempre que possível, especialmente para consultas comuns em grandes bancos de dados. Você também pode aproveitar o reconhecimento agregado para melhorar significativamente a performance de painéis inteiros. Consulte o Tutorial de reconhecimento agregado para mais informações.
• Use TDPs para consultas mais rápidas. Converta Explores com muitas mesclagens complexas ou de baixo desempenho, ou dimensões com subconsultas ou subconsultas, em TDPs. Assim, as visualizações serão pré-mescladas e prontas antes do ambiente de execução.
• Se o dialeto do banco de dados oferecer suporte a TDPs incrementais, configure TDPs incrementais para reduzir o tempo que o Looker gasta recriando tabelas de TDPs.
• Evite mesclar visualizações em "Explores" com chaves primárias concatenadas definidas no Looker. Em vez disso, mescle os campos base que compõem a chave primária concatenada da visualização. Como alternativa, recrie a visualização como uma TDP com a chave primária concatenada predefinida na definição de SQL da tabela, e não no LookML de uma visualização.
• Use a ferramenta Explain in SQL Runner para comparações. EXPLAIN produz uma visão geral do plano de execução de consultas do seu banco de dados para determinada consulta SQL, permitindo que você detecte componentes de consulta que podem ser otimizados. Saiba mais na postagem na Comunidade Como otimizar o SQL com o EXPLAIN.
• Declarar índices. Para conferir os índices de cada tabela diretamente no Looker pelo SQL Runner, clique no ícone de engrenagem em uma tabela e selecione Mostrar índices.
  As colunas mais comuns que podem se beneficiar dos índices são datas importantes e chaves estrangeiras. Adicionar índices a essas colunas aumentará o desempenho de quase todas as consultas. Isso também se aplica a TDPs. Os parâmetros do LookML, como indexes, sort keys e distribution, podem ser aplicados adequadamente.
• Aumente a memória, os núcleos e a E/S (entrada/saída) de bancos de dados com hardware insuficiente ou os recursos provisionados necessários (como AWS) para processar grandes conjuntos de dados e melhorar o desempenho das consultas.

Otimizar o desempenho do servidor do Looker

Também é possível tomar medidas para garantir que o servidor e o aplicativo do Looker estejam funcionando da maneira ideal:

• Limite o número de elementos em um painel individual. Não há uma regra precisa para definir o número, porque o design de cada elemento afeta o consumo de memória com base em diversos fatores. No entanto, painéis com 25 ou mais blocos tendem a ser problemáticos quando se trata de desempenho.
• Usar o recurso de atualização automática do painel estrategicamente. Se um painel usar a atualização automática, certifique-se de que a atualização não seja mais rápida do que os processos ETL que estão sendo executados em segundo plano.
• Use eixos estrategicamente e evite o uso excessivo de eixos dentro de blocos do dashboard e Looks. Consultas com dimensões dinâmicas vão consumir mais memória. Quanto mais dimensões forem dinamizadas, mais memória vai ser consumida quando conteúdo (uma exploração, um Look ou um dashboard) é carregado.
• Use com moderação os recursos de processamento pós-consulta, como resultados de combinação, campos personalizados e cálculos de tabelas. Esses atributos devem ser usados como provas de conceito para ajudar a projetar seu modelo. Uma prática recomendada é fixar no código os cálculos e funções usados com frequência no LookML, que vai gerar o SQL para ser processado no banco de dados. Cálculos excessivos podem competir pela memória Java na instância do Looker, fazendo com que a instância do Looker responda mais lentamente.
• Limite o número de visualizações incluídas em um modelo quando um grande número de arquivos de visualização estiver presente. Incluir todas as visualizações em um único modelo pode prejudicar o desempenho. Quando um grande número de visualizações estiver presente em um projeto, considere incluir apenas os arquivos de visualização necessários em cada modelo. Considere usar convenções de nomenclatura estratégicas para nomes de arquivos de visualizações, para permitir a inclusão fácil de grupos de visualizações em um modelo. Confira um exemplo na documentação do parâmetro includes.
• Evite retornar um grande número de pontos de dados por padrão nos blocos do dashboard e nos Looks. Consultas que retornam milhares de pontos de dados consomem mais memória. Para garantir que os dados sejam limitados sempre que possível, aplique filtros de front-end a dashboards, Looks e Explores (Explores) e no nível LookML com os parâmetros required filters, conditionally_filter e sql_always_where.
• Faça o download ou envie consultas usando a opção Todos os resultados com moderação, porque algumas consultas podem ser muito grandes e sobrecarregar o servidor do Looker quando processadas.

Para mais ajuda com a identificação da origem dos problemas de desempenho, consulte a página de práticas recomendadas em Visão geral do desempenho.