Otimizar a performance do Looker

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

Otimizar o desempenho da consulta

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

• Crie análises detalhadas usando junções many_to_one sempre que possível. Unir visualizações do nível mais granular ao nível mais alto de detalhes (many_to_one) geralmente 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 de banco de dados. Por padrão, o Looker armazena consultas em cache por uma hora. Você pode controlar a política de armazenamento em cache e sincronizar as atualizações de dados do Looker com seu processo de ETL aplicando datagroups nas análises detalhadas usando o parâmetro persist_with. Isso permite que o Looker se integre mais de perto ao pipeline de dados de back-end para que o uso do cache possa ser maximizado sem o risco de analisar dados desatualizados. As políticas de cache nomeadas podem ser aplicadas a um modelo inteiro e/ou a Análises e tabelas derivadas permanentes (TDPs) individuais.
• Use a funcionalidade de reconhecimento agregado do Looker para criar resumos ou tabelas de resumo que o Looker pode usar para consultas sempre que possível, especialmente para consultas comuns de bancos de dados grandes. Você também pode aproveitar o reconhecimento de agregação para melhorar drasticamente a performance de painéis inteiros. Consulte o tutorial sobre agregação de reconhecimento para mais informações.
• Use PDTs para consultas mais rápidas. Converta análises detalhadas com muitas junções complexas ou de baixo desempenho ou dimensões com subconsultas ou subseleções em PDTs para que as visualizações sejam pré-combinadas e fiquem prontas antes da execução.
• Se o dialeto do banco de dados for compatível com TDPs incrementais, configure TDPs incrementais para reduzir o tempo que o Looker leva para recriar TDPs.
• Evite mesclar visualizações em análises com chaves primárias concatenadas definidas no Looker. Em vez disso, faça a junção nos campos de base que compõem a chave primária concatenada da visualização. Como alternativa, recrie a visualização como uma PDT com a chave primária concatenada predefinida na definição SQL da tabela, em vez de em uma LookML de visualização.
• Use a ferramenta "Explicar no SQL Runner" para fazer comparativos de mercado. O EXPLAIN produz uma visão geral do plano de execução de consultas do seu banco de dados para uma determinada consulta SQL, permitindo detectar componentes de consulta que podem ser otimizados. Saiba mais na postagem da Comunidade Como otimizar o SQL com EXPLAIN.
• Declare os í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 de índices são datas importantes e chaves estrangeiras. Adicionar índices a essas colunas aumenta o desempenho de quase todas as consultas. Isso também se aplica às PDTs. 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 recursos provisionados necessários (como a AWS) para processar grandes conjuntos de dados e melhorar o desempenho das consultas.

Otimizar a performance do servidor do Looker

Você também pode tomar medidas para garantir que o servidor e o aplicativo do Looker estejam funcionando de 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 vários fatores. No entanto, painéis com 25 ou mais blocos tendem a ser problemáticos em termos de desempenho.
• Use o recurso de atualização automática do painel de forma estratégica. Se um painel usar a atualização automática, verifique se ela não é mais rápida do que os processos de ETL em execução nos bastidores.
• Use as tabelas dinâmicas de forma estratégica e evite o uso excessivo delas em blocos de painel e Looks. Consultas com dimensões de pivô consomem mais memória. Quanto mais dimensões forem usadas, mais memória será consumida quando o conteúdo (uma análise detalhada, um Look ou um painel) for carregado.
• Use recursos como mesclar resultados, campos personalizados e cálculos de tabela com moderação. Esses recursos são destinados a ser usados como provas de conceito para ajudar a projetar seu modelo. A prática recomendada é codificar cálculos e funções usados com frequência em LookML, o que vai gerar SQL para ser processado no seu banco de dados. Cálculos excessivos podem competir pela memória Java na instância do Looker, fazendo com que ela responda mais lentamente.
• Limite o número de visualizações incluídas em um modelo quando houver muitos arquivos de visualização. Incluir todas as visualizações em um único modelo pode prejudicar a performance. Quando um grande número de visualizações está presente em um projeto, considere incluir apenas os arquivos de visualização necessários em cada modelo. Use convenções de nomenclatura estratégicas para nomes de arquivos de visualização, permitindo a inclusão de grupos de visualizações em um modelo. Um exemplo é descrito na documentação do parâmetro includes.
• Evite retornar um grande número de pontos de dados por padrão nos blocos do painel e nas análises. Consultas que retornam milhares de pontos de dados consomem mais memória. Limite os dados sempre que possível aplicando filtros de front-end a dashboards, Looks e Análises, e no nível da LookML com os parâmetros required filters, conditionally_filter e sql_always_where.
• Baixe ou entregue consultas usando a opção Todos os resultados com moderação, já que algumas consultas podem ser muito grandes e sobrecarregar o servidor do Looker quando processadas.
• Entenda o impacto da performance da conexão em toda a instância do Looker. O Looker usa recursos compartilhados para processar consultas de todas as conexões de banco de dados. Esses recursos incluem pods do Kubernetes, filas de consultas e pools de linhas de execução. Devido a essa infraestrutura compartilhada, uma única conexão de banco de dados lenta ou sobrecarregada pode afetar negativamente o desempenho das consultas em todas as outras conexões. Se você notar uma degradação generalizada da performance, investigue a integridade de todas as conexões de banco de dados, não apenas as que estão diretamente relacionadas aos painéis ou análises detalhadas lentos.

Para mais ajuda na identificação da origem dos problemas de performance, confira a página de práticas recomendadas Visão geral da performance.