Otimizar a performance do Looker

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

Otimizar o desempenho da consulta

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

• Crie análises detalhadas usando mesclagens 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 para 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 armazenamento em cache nomeadas 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 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. Também é possível aproveitar o reconhecimento de agregados para melhorar drasticamente o desempenho de painéis inteiros. Consulte o tutorial sobre reconhecimento agregado para mais informações.
• Use TDPs para acelerar as consultas. Converta as análises detalhadas com muitas mesclagens complexas ou de baixo desempenho, ou dimensões com subconsultas ou subseleções, em TDPs para que as visualizações sejam pré-mescladas e estejam prontas antes do ambiente de 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 gasta recriando TDPs.
• Evite mesclar visualizações em Análises em chaves primárias concatenadas que são definidas no Looker. Em vez disso, faça a mesclagem nos campos de 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, em vez de no LookML de uma visualização.
• Use a ferramenta Explicar no SQL Runner para fazer comparativos de mercado. EXPLAIN produz uma visão geral do plano de execução de consulta do seu banco de dados para uma determinada consulta SQL, permitindo detectar componentes de consulta que podem ser otimizados. Saiba mais no post na Comunidade Como otimizar o SQL com o EXPLAIN.
• Declarar índices. Você pode conferir os índices de cada tabela diretamente no Looker no SQL Runner. Para isso, 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 externas. Adicionar índices a essas colunas vai melhorar o desempenho de quase todas as consultas. Isso também se aplica às 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 recursos provisionados necessários (como a AWS) para processar grandes conjuntos de dados, aumentando 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 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 ele não é atualizado mais rápido do que os processos de ETL em execução em segundo plano.
• Use as tabelas dinâmicas de forma estratégica e evite o uso excessivo delas em blocos de painel e Looks. As consultas com dimensões dinâmicas consomem mais memória. Quanto mais dimensões forem dinamizadas, mais memória será consumida quando o conteúdo (uma Análise, um Look ou um dashboard) for carregado.
• Use recursos como campos personalizados e cálculos de tabela com moderação. Esses recursos são destinados ao uso como provas de conceito para ajudar a projetar seu modelo. É uma prática recomendada codificar permanentemente todos os cálculos e funções usados com frequência no LookML, o que vai gerar o SQL a ser processado no banco de dados. Cálculos excessivos podem competir pela memória Java na instância do Looker, fazendo com que ela responda mais lentamente.
• Para consultas de resultados combinados, use consultas de combinação no banco de dados sempre que possível. As consultas de mesclagem no banco de dados são processadas no seu banco de dados, e não na memória do Looker.
• Limitar o número de visualizações incluídas em um modelo quando há um grande número de arquivos de visualização. Incluir todas as visualizações em um único modelo pode reduzir o desempenho. Quando houver um grande número de visualizações em um projeto, inclua 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ção, para permitir 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 de painel e 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 Análises, e no nível do LookML com os parâmetros required filters, conditionally_filter e sql_always_where.
• Baixe ou envie 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.
• Entender 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 consulta 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 do desempenho, investigue a integridade de todas as conexões de banco de dados, não apenas aquelas diretamente relacionadas aos painéis ou análises lentas.
• Distribua as entregas programadas e evite a execução simultânea de jobs. Quando vários Looks ou dashboards são programados para serem executados no mesmo minuto (especialmente no início da hora), o aumento repentino de solicitações de consulta simultâneas pode sobrecarregar os recursos da instância, aumentar a profundidade da fila e esgotar os pools de conexão do banco de dados. Esse gargalo de simultaneidade pode fazer com que as entregas programadas e as consultas interativas da Análise sejam interrompidas durante a fase de inicialização da consulta. Use as estratégias a seguir para evitar gargalos de simultaneidade:
  • Distribua os jobs programados em intervalos de 15 ou 30 minutos (ou minutos que não sejam o início da hora, como :15, :30 ou :45) em vez de programar todas as entregas para o início da hora.
  • Sempre que possível, use datagroups para acionar entregas com base na conclusão do ETL, em vez de programações baseadas em tempo, evitando consultas desnecessárias em dados não atualizados.
  • Agrupe em lote ou limite scripts externos e chamadas de API automatizadas que executam consultas ou acionam entregas.
  • Se uma explosão repentina de consultas fizer com que a instância pare de responder ou as consultas fiquem em execução indefinidamente, você poderá limpar as tarefas em andamento reiniciando a instância (consulte Reiniciar uma instância do Looker (Google Cloud Core) para instâncias do Looker (Google Cloud Core)).

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