Como conectar o Looker ao seu banco de dados

Depois de proteger e configurar seu banco de dados, você poderá conectá-lo ao Looker.

Crie uma conexão de banco de dados no Looker na página Conectar seu banco de dados ao Looker. Há duas opções para abrir a página Conectar seu banco de dados ao Looker:

  • Clique no ícone Menu principal, selecione Administrador e, em seguida, selecione Conexões na seção Banco de dados do painel de admin Administrador. Na página Conexões, clique no botão Adicionar conexão.
  • Clique no botão Criar no menu de navegação principal e selecione o item de menu Conexão.

Nesta página, descrevemos os campos comuns que o Looker mostra na página Conectar seu banco de dados ao Looker. Os campos exatos exibidos na página dependem da configuração do dialeto.

Para saber como aplicar atributos de usuário às configurações de conexão, consulte a seção Conexões da página de documentação Atributos de usuário.

A configuração da conexão do banco de dados tem as quatro seções a seguir:

Configurações gerais

Nome

O nome da conexão que você quer usar. Você precisa desse nome de conexão de banco de dados para usar no parâmetro connection do seu modelo do LookML. O nome da conexão do banco de dados também é como a conexão é identificada na página Administrador de Conexões do Looker. Não use o nome de nenhuma pasta para essa configuração. Esse valor não precisa corresponder a nada no banco de dados. Name é um rótulo que identifica essa conexão na interface do Looker.

Dialeto SQL

O dialeto SQL correspondente à sua conexão. É importante escolher o valor correto para receber as opções de conexão adequadas e para que o Looker possa converter o LookML corretamente em SQL.

Usar a versão mais recente do driver

Por padrão, o Looker sempre se conecta ao banco de dados usando a versão mais recente do driver JDBC para o dialeto do banco de dados. Se o dialeto do banco de dados selecionado tiver mais de uma versão do driver JDBC compatível com o Looker, desative a opção Usar a versão mais recente do driver para selecionar uma versão anterior do driver JDBC para a conexão. Se você quiser selecionar uma versão anterior do driver JDBC, desative a opção Usar a versão mais recente do driver para sua conexão e selecione a versão do driver no menu suspenso Versão do driver.

Se você selecionar uma versão anterior do driver JDBC, o Looker vai continuar usando essa versão enquanto ela for compatível.

O Looker vai deixar de oferecer suporte a uma versão de driver nos dois cenários a seguir:

  • A versão do driver foi removida do suporte do Looker. Nesse caso, a conexão vai usar a versão mais antiga do driver que o Looker aceita para o dialeto.
  • A versão do driver ainda não existe devido a uma reversão do Looker. Nesse caso, a conexão vai usar a versão mais recente do driver compatível com a versão revertida.

Se a versão do driver selecionada não for mais compatível com o Looker, um alerta será exibido no campo Versão do driver na página Editar conexão do banco de dados para informar que a versão do driver selecionada não é mais compatível. O alerta também informa qual versão do driver o Looker está usando para a conexão. Para limpar esse alerta, selecione uma versão compatível do driver JDBC no menu suspenso Versão do driver ou ative a opção Usar a versão mais recente do driver.

Escopo do projeto

Selecione se a conexão pode ser usada com todos os projetos ou apenas com um:

  • Todos os projetos: todos os projetos do LookML na instância podem ter acesso à conexão. Assim, o nome da conexão pode ser especificado no parâmetro connection dos arquivos de modelo nesse projeto.
  • Projeto selecionado: apenas um projeto do LookML na instância pode ter acesso à conexão. Quando você seleciona essa opção, a tela "Conexão" mostra um menu suspenso dos projetos na instância. Selecione o projeto que pode ter acesso a essa conexão.

Use essa opção com as seguintes permissões para delegar o gerenciamento de conexões e a configuração de modelos:

Detalhes do status

Abra a seção Detalhes do status para testar as configurações da conexão.

Configurações do banco de dados

Ativar o servidor SSH

A opção Servidor SSH estará disponível somente se a instância for implantada na infraestrutura do Kubernetes e se a opção de adicionar informações de configuração do servidor SSH à sua instância do Looker estiver ativada. Se essa opção não estiver ativada na sua instância do Looker e você quiser ativá-la, entre em contato com um especialista de vendas do Google Cloud ou abra uma solicitação de suporte. Se você ativar a opção Ativar servidor SSH, o Looker vai mostrar os campos Servidor SSH e Túnel SSH.

Servidor SSH

Não é possível especificar a porta do host local. O servidor SSH escolhe automaticamente a porta do host local para você. Se você precisar criar uma conexão SSH que exija a especificação de uma porta localhost, abra uma solicitação de suporte.

Selecione uma configuração de servidor SSH na lista suspensa. Um servidor SSH é necessário para selecionar ou criar um túnel SSH adequado. É possível criar um novo servidor SSH na guia Servidores SSH no painel Conexões.

Túnel SSH

Selecione um túnel SSH na lista suspensa ou clique no ícone Criar novo túnel se quiser criar um novo túnel SSH com um nome do host e uma porta ou uma porta local.

Nome do host

O nome do host do banco de dados que o Looker deve usar para estabelecer conexão.

Se você trabalhou com um analista do Looker para configurar um túnel SSH para seu banco de dados, no campo Host, digite "localhost". Se você aplicar um atributo de usuário ao campo Host, o atributo não poderá ter um nível de acesso do usuário definido como Editável. Se você configurou um túnel SSH para se conectar ao banco de dados, não é possível aplicar um atributo de usuário ao campo Host remoto:porta.

Porta

A porta do banco de dados que o Looker deve usar para se conectar ao host.

Se você trabalhou com um analista do Looker para configurar um túnel SSH para seu banco de dados, no campo Porta, insira o número da porta que redireciona para seu banco de dados, que deve ter sido fornecido pelo analista do Looker.

Porta local

Por padrão, o Looker seleciona automaticamente uma porta local disponível para o túnel SSH. Para escolher uma porta local manualmente, selecione Entrada manual e insira um número no campo Porta local personalizada. Verifique se a porta local está disponível na sua instância.

ID do projeto de faturamento (somente Google BigQuery)

O ID do projeto de faturamento é o ID do projeto do Google Cloud . Para mais informações, consulte a página de documentação do Google BigQuery.

ID do projeto de armazenamento (somente Google BigQuery)

O nome do ID do projeto de armazenamento, se você separar a computação e o armazenamento em projetos diferentes. É possível consultar conjuntos de dados em um projeto do Google Cloud diferente se os desenvolvedores do LookML especificarem nomes de tabela com escopo completo no parâmetro sql_table_name das visualizações, Análises ou mesclagens do LookML. Para mais informações, consulte a página de documentação do Google BigQuery.

Conjunto de dados principal (somente Google BigQuery)

O nome do conjunto de dados que o Looker deve usar como padrão ao consultar seu banco de dados. Para mais informações, consulte a página de documentação do Google BigQuery.

Nome do banco de dados

O nome do banco de dados no seu host. Por exemplo, você pode ter um nome de host de my-instance.us-east-1.redshift.amazonaws.com em que há um banco de dados chamado sales_info. Você digitaria sales_info nesse campo. Se você tiver vários bancos de dados no mesmo host, talvez seja necessário criar várias conexões para usá-los (com exceção do MySQL, em que a palavra banco de dados significa algo um pouco diferente da maioria dos dialetos SQL).

Esquema padrão

O esquema padrão que o Looker usa quando um esquema não é especificado. Isso se aplica ao usar o SQL Runner, durante a geração do projeto do LookML e ao consultar tabelas.

Configurações de autenticação

Para conexões do Google BigQuery, Snowflake, Trino e Databricks, selecione o tipo de autenticação que você quer que o Looker use para acessar seu banco de dados:

  • Para conexões do Google BigQuery, é possível configurar o OAuth ou uma conta de serviço para o Looker usar na autenticação no banco de dados.
  • Para conexões do Snowflake, do Trino e do Databricks, é possível configurar o OAuth ou uma conta de banco de dados para o Looker usar na autenticação do seu banco de dados.

Quando você usa o OAuth, os usuários precisam fazer login no banco de dados para emitir consultas do Looker. Quando os usuários iniciam um fluxo de autorização do OAuth no Looker, o Looker exibe uma caixa de diálogo Autorizar conexão do OAuth notificando que a autorização da conexão permite que a instância do Looker acesse dados em nome deles e que os usuários privilegiados do Looker, como administradores ou desenvolvedores, podem ter visibilidade dos dados deles. Os usuários precisam selecionar Autorizar para continuar na página de login do OAuth. As informações de consentimento são armazenadas no armazenamento local do navegador. Se o armazenamento local for limpo, a caixa de diálogo vai aparecer novamente na próxima vez que o usuário iniciar um fluxo de autorização do OAuth. Para mais informações sobre como configurar o OAuth em uma conexão com o Looker, consulte os procedimentos de conexão do Google BigQuery, Snowflake, Trino ou Databricks.

Nome de usuário

O nome de usuário de uma conta no seu banco de dados que o Looker pode usar para se conectar ao banco de dados.

Senha

A senha de uma conta de usuário no banco de dados que o Looker pode usar para se conectar ao banco de dados.

Abra a seção Detalhes do status para testar as configurações da conexão.

Configurações opcionais

Máximo de conexões por nó

Aqui, você pode definir o número máximo de conexões que o Looker pode estabelecer com seu banco de dados. Na maioria das vezes, você define o número de consultas simultâneas que o Looker pode executar no banco de dados. O Looker também reserva até três conexões para encerrar consultas. Se o pool de conexões for muito pequeno, o Looker vai reservar menos conexões.

Defina esse valor com cuidado. Se o valor for muito alto, o banco de dados poderá ficar sobrecarregado. Se o valor for muito baixo, as consultas precisarão compartilhar um número pequeno de conexões, o que pode fazer com que muitas consultas pareçam lentas para os usuários, porque elas precisam esperar o retorno de outras consultas anteriores.

O valor padrão (que varia de acordo com o dialeto SQL) costuma ser um ponto de partida razoável. A maioria dos bancos de dados também tem as próprias configurações para o número máximo de conexões que aceitam. Se a configuração do banco de dados limitar as conexões, verifique se o valor de Máximo de conexões por nó é igual ou menor que o limite do banco de dados.

Tempo limite do pool de conexões

Se os usuários solicitarem mais conexões do que o configurado na opção Máximo de conexões por nó, as solicitações vão aguardar a conclusão de outras antes de serem executadas. O tempo máximo que uma solicitação vai esperar é configurado aqui. A configuração padrão é 120 segundos.

Defina esse valor com cuidado. Se o valor for muito baixo, as consultas dos usuários poderão ser canceladas porque não há tempo suficiente para que as consultas de outros usuários sejam concluídas. Se o valor for muito alto, um grande número de consultas pode se acumular, fazendo com que os usuários esperem por muito tempo. O valor padrão geralmente é um ponto de partida razoável.

Número máximo de consultas simultâneas para esta conexão

Esse valor opcional limita o número de consultas simultâneas que o Looker vai enviar para essa conexão de banco de dados de uma vez. As demais solicitações simultâneas que chegarem exigindo a mesma conexão serão colocadas em fila internamente, e o Looker vai fazer o processamento delas em ordem. Definir esse valor substitui um valor de Máximo de conexões por nó.

Número máximo de consultas simultâneas por usuário para esta conexão

Esse valor opcional limita o número de consultas simultâneas por usuário que o Looker vai enviar para essa conexão de banco de dados de uma vez. As demais solicitações simultâneas que chegarem exigindo a mesma conexão serão colocadas em fila internamente, e o Looker vai fazer o processamento delas em ordem. O valor padrão é definido pelo dialeto do banco de dados e geralmente é 25.

A configuração Número máximo de consultas simultâneas por usuário para esta conexão se aplica à conexão individual para a qual está definida. Essa configuração substitui a opção de inicialização per-user-query-limit no nível da instância para a conexão.

Como a configuração Máximo de consultas simultâneas por usuário para esta conexão substitui a configuração per-user-query-limit, é importante entender como elas são diferentes:

  • A configuração Número máximo de consultas simultâneas por usuário para esta conexão se aplica por usuário e por conexão, mas NÃO por nó. A configuração Número máximo de consultas simultâneas por usuário para esta conexão se aplica às consultas simultâneas do usuário para a conexão em toda a instância do Looker. Para instâncias em cluster do Looker, o valor definido para Número máximo de consultas simultâneas por usuário para esta conexão é dividido pelo número de nós no cluster do Looker para determinar o número de consultas simultâneas que um usuário pode executar em cada nó.

    Por exemplo, se você tiver um cluster de 5 nós e definir esse valor como 15, cada nó vai permitir 3 consultas simultâneas por usuário para essa conexão (15 / 5 = 3), totalizando 15 consultas em todos os nós.

  • A opção de inicialização per-user-query-limit se aplica por usuário, por conexão e por nó.

    Por exemplo, se você tiver um cluster de cinco nós com um per-user-query-limit de 15, cada nó vai permitir 15 consultas simultâneas por usuário para essa conexão, totalizando 75 consultas em todos os nós (15 * 5 = 75).

Portanto, para instâncias em cluster do Looker, aplicar um valor para Número máximo de consultas simultâneas por usuário para esta conexão pode afetar o desempenho das consultas para os usuários.

Parâmetros JDBC adicionais

Um driver Java Database Connectivity (JDBC) é um componente de software que gerencia a conexão entre o Looker e seu banco de dados.

Quando o driver JDBC do seu banco de dados inicia uma conexão do Looker com o banco de dados, ele cria um URL com um conjunto de parâmetros, como host, porta, banco de dados ou warehouse, além de outros parâmetros específicos do dialeto. Ao configurar a conexão do banco de dados, é possível especificar outros parâmetros JDBC que o Looker deve incluir ao se comunicar com o driver do banco de dados. Dependendo do dialeto e do parâmetro específico, os parâmetros JDBC podem ser processados pelo driver JDBC ou transmitidos ao banco de dados.

Para manter sua conexão segura, o Looker tem uma lista de permissões para os parâmetros JDBC compatíveis com cada dialeto de banco de dados.

  • Se você tentar criar ou atualizar uma conexão usando parâmetros JDBC incompatíveis, o Looker vai mostrar uma mensagem de erro com os parâmetros não permitidos.
  • Se você tiver uma conexão com parâmetros JDBC incompatíveis, o Looker vai remover os parâmetros e se conectar ao banco de dados.

Para ver uma lista dos parâmetros JDBC compatíveis com seu dialeto, consulte a seção "Parâmetros JDBC compatíveis" da página de instruções de configuração do banco de dados do seu dialeto.

Para referenciar um atributo de usuário em um parâmetro JDBC, use a sintaxe de modelos do Liquid: _user_attributes['name_of_attribute']. Veja o exemplo a seguir:

my_jdbc_param={{ _user_attributes['name_of_attribute'] }}

Cronograma de manutenção

O regenerador do Looker verifica datagroups e tabelas persistentes (tabelas de agregação e tabelas derivadas persistentes) baseadas em sql_trigger_value. Com base nessas verificações, o regenerador do Looker recria ou descarta tabelas persistentes do esquema de rascunho do banco de dados.

O valor da Programação de manutenção define o intervalo cron para o regenerador do Looker. O regenerador do Looker inicia um ciclo de regeneração para verificar datagroups e tabelas persistentes no intervalo cron. Se um ciclo do regenerador do Looker ainda estiver em andamento no próximo intervalo de cron, o regenerador do Looker vai concluir o ciclo em andamento e aguardar até o próximo intervalo de cron para iniciar o próximo ciclo.

A configuração Programação de manutenção aceita uma expressão cron. O valor padrão é */5 * * * *, o que significa que o ciclo do regenerador do Looker vai iniciar um ciclo no intervalo de cinco minutos, se o ciclo anterior tiver sido concluído. Se o ciclo anterior não tiver sido concluído, o regenerador do Looker será iniciado no próximo intervalo de cinco minutos após a conclusão do ciclo.

O intervalo padrão de cinco minutos também é o mais frequente com suporte para a Programação de manutenção. O Looker não impõe um intervalo máximo para a Programação de manutenção, o que significa que é possível estender o intervalo entre os ciclos do regenerador do Looker pelo tempo que puder ser especificado por uma expressão cron. Lembre-se de que ciclos mais longos do regenerador do Looker podem afetar negativamente a atualização dos dados no cache e nas tabelas persistentes.

Depois que o regenerador do Looker concluir todas as verificações e recriações de TDP em um ciclo, ele vai aguardar o próximo intervalo de cron para iniciar o próximo ciclo. Se você tiver builds de TDP de longa duração, poderá ter longos períodos entre os ciclos do regenerador do Looker. Outros fatores podem afetar o tempo necessário para recriar as tabelas, conforme descrito na seção Considerações importantes para implementar tabelas persistentes na página Tabelas derivadas no Looker.

Se o banco de dados não estiver ativo 24 horas por dia, limite as verificações aos momentos em que ele estiver ativo. Confira outras expressões de cron:

Expressão cron Definição
*/5 8-17 * * MON-FRI Verificar datagroups e TDPs a cada 5 minutos durante o horário de funcionamento, de segunda a sexta-feira
*/5 8-17 * * * Verificar datagroups e TDPs a cada 5 minutos durante o horário de funcionamento, todos os dias
0 8-17 * * MON-FRI Verificar datagroups e TDPs a cada hora durante o horário de funcionamento, de segunda a sexta-feira
1 3 * * * Verificar datagroups e TDPs todos os dias às 3h01

Algumas observações sobre a criação de uma expressão cron:

  • O Looker usa o parse-cron v0.1.3, que não é compatível com ? em expressões cron.
  • A expressão cron usa o fuso horário do aplicativo do Looker para determinar quando as verificações são feitas.
  • Se as TDPs não estiverem sendo criadas, redefina a string cron para o padrão de */5 * * * *.

Confira alguns recursos para ajudar na criação de strings cron:

Desativar conexão

A opção Desativar conexão permite que os administradores do Looker encerrem temporariamente uma conexão em casos de problemas downstream com o banco de dados, em vez de encerrar as consultas manualmente ou permitir que elas permaneçam na fila.

Quando a opção Desativar conexão está ativada, o Looker não envia consultas ao banco de dados, mas retorna uma mensagem de erro ao usuário informando que a conexão está desativada.

Depois que os problemas do banco de dados forem resolvidos, um administrador do Looker poderá desativar a opção Desativar conexão. Depois que a conexão for reativada, todas as consultas vão voltar a funcionar como esperado.

SSL

Escolha se você quer usar a criptografia SSL para proteger os dados que passam entre o Looker e seu banco de dados. O SSL é apenas uma opção que pode ser usada para proteger seus dados. Outras opções seguras são descritas na página de documentação Ativar o acesso seguro ao banco de dados.

Verificar SSL

Escolha se você quer exigir a verificação do certificado SSL usado pela conexão. Se a verificação for necessária, a autoridade certificadora (CA) SSL que assinou o certificado SSL precisa vir da lista de fontes confiáveis do cliente. Se a AC não for uma fonte confiável, a conexão com o banco de dados não será estabelecida.

Se essa caixa não estiver marcada, a criptografia SSL ainda será usada na conexão, mas a verificação da conexão SSL não será necessária. Assim, uma conexão poderá ser estabelecida quando a CA não estiver na lista de fontes confiáveis do cliente.

Pré-cache de tabelas e colunas

No SQL Runner, todas as informações da tabela são pré-carregadas assim que você seleciona uma conexão e um esquema. Isso permite que o SQL Runner mostre rapidamente as colunas da tabela assim que você clica no nome dela. No entanto, para conexões e esquemas com muitas tabelas ou com tabelas muito grandes, talvez você não queira que o SQL Runner pré-carregue todas as informações.

Se você preferir que o SQL Runner carregue as informações da tabela somente quando uma tabela for selecionada, desmarque a opção Pré-cache de tabelas e colunas para desativar o pré-carregamento do SQL Runner para a conexão.

O esquema para buscar e armazenar em cache

Para alguns recursos de escrita SQL, como reconhecimento de agregados, o Looker usa o esquema de informações do banco de dados para otimizar a escrita SQL. Se o esquema de informações não estiver armazenado em cache, o Looker poderá bloquear ocasionalmente a gravação de SQL no banco de dados para buscar o esquema de informações. Para dialetos do Denodo ou dialetos que usam o Hadoop Distributed File System (HDFS), a busca do esquema de informações pode levar tempo suficiente para afetar significativamente o desempenho das consultas do Looker. Se você sabe que seu esquema de informações é lento, desative a opção Buscar e armazenar esquema em cache para sua conexão. Desativar esse recurso impede parte da otimização de SQL do Looker para determinados recursos. Portanto, ative a opção Buscar e armazenar esquema em cache, a menos que você saiba que o esquema de informações da sua conexão é particularmente lento.

Custo estimado

A opção Estimativa de custo se aplica apenas às seguintes conexões de banco de dados:

O botão de alternância Estimativa de custo ativa os seguintes recursos na conexão:

Para mais informações, consulte a página de documentação Analisar dados no Looker.

Pooling de conexão com o banco de dados

Para dialetos que oferecem suporte ao pool de conexões de banco de dados, esse recurso permite que o Looker use pools de conexões pelo driver JDBC. O pool de conexões de banco de dados permite um desempenho de consulta mais rápido. Uma nova consulta não precisa criar uma nova conexão de banco de dados, mas pode usar uma conexão atual do pool de conexões. O recurso de pool de conexões garante que uma conexão seja limpa após a execução de uma consulta e esteja disponível para reutilização após o término da execução da consulta. Consulte a página de documentação Pool de conexões de banco de dados para mais informações.

Configurações de tabelas derivadas persistentes (TDPs)

As configurações a seguir vão aparecer se as TDPs estiverem ativadas.

Ativar TDPs

Ative a opção Ativar TDPs para ativar as tabelas derivadas persistentes. Quando as TDPs estão ativadas, a janela Conexão mostra outros campos de TDP e a seção Substituições de TDP. O Looker só vai mostrar o botão Ativar TDPs se o dialeto do banco de dados for compatível com o uso de TDPs.

Observe o seguinte sobre as TDPs:

  • As TDPs não são compatíveis com conexões do Snowflake que usam o OAuth.
  • Desativar as TDPs em uma conexão não desativa os datagroups associados a elas. Mesmo que você desative as TDPs, os datagroups atuais ainda vão executar as consultas sql_trigger no banco de dados. Se você quiser impedir que um datagroup execute a consulta sql_trigger no banco de dados, exclua ou comente o parâmetro datagroup do projeto do LookML ou atualize a configuração Cronograma de manutenção da conexão para que o Looker verifique as TDPs e os datagroups com pouca frequência ou nunca.
  • Para conexões do Snowflake, o Looker define o valor do parâmetro AUTOCOMMIT como TRUE (o valor padrão do Snowflake). AUTOCOMMIT é necessário para os comandos SQL que o Looker executa para manter o sistema de registro de TDPs.

Banco de dados temporário

Embora seja chamado de banco de dados temporário, você digita o nome do banco de dados ou do esquema apropriado para seu dialeto SQL que o Looker usa na criação de tabelas derivadas persistentes. Configure esse banco de dados ou esquema com antecedência, com as permissões de gravação apropriadas. Na página de documentação Instruções de configuração do banco de dados, selecione o dialeto do banco de dados para conferir as instruções.

Cada conexão precisa ter o próprio esquema ou banco de dados temporário. Eles não podem ser compartilhados entre conexões distintas.

O número máximo de conexões do builder da TDP

Com a configuração Número máximo de conexões do builder da TDP, é possível especificar quantas versões simultâneas de tabelas o regenerador do Looker pode iniciar em uma conexão de banco de dados. A configuração Número máximo de conexões do builder da TDP se aplica apenas aos tipos de tabelas para os quais o regenerador do Looker inicia recriações:

  • Tabelas com gatilho permanente (tabelas derivadas persistentes e tabelas de agregação que usam a estratégia de persistência datagroup_trigger ou sql_trigger_value).
  • Tabelas persistentes que usam a estratégia persist_for, mas somente quando a tabela persist_for faz parte de uma cascata de tabelas derivadas em que ela depende de uma tabela que usa a estratégia de persistência datagroup_trigger ou sql_trigger_value. Nesse caso, o regenerador do Looker vai recriar uma tabela persist_for, já que ela é necessária para recriar outra tabela na cascata. Caso contrário, o regenerador não vai iniciar builds para tabelas persist_for.

A configuração Número máximo de conexões do builder da TDP é definida como 1 por padrão, mas pode ser definida como até 100. No entanto, o valor não pode ser maior do que o definido no campo Máximo de conexões por nó ou no per-user-query-limit definido nas opções de inicialização do Looker.

Defina esse valor com cuidado. Se o valor for muito alto, você poderá sobrecarregar o banco de dados. Se o valor for baixo, as TDPs ou tabelas de agregação de longa duração poderão atrasar a criação de outras tabelas persistentes ou desacelerar outras consultas na conexão. Os bancos de dados que oferecem suporte à multilocação, como BigQuery, Snowflake e Redshift, podem ter um desempenho melhor ao lidar com builds de consulta paralelos.

Se você quiser aumentar a configuração Número máximo de conexões do builder da TDP, recomendamos aumentar em 1. Se ocorrer algum comportamento inesperado, defina-o de volta para o padrão de 1. Caso contrário, se o desempenho da consulta não for afetado, continue aumentando o valor de forma incremental em 1 e verificando o desempenho em cada incremento antes de aumentar ainda mais a configuração.

Observe o seguinte sobre a configuração Número máximo de conexões do builder da TDP:

  • A configuração Número máximo de conexões do builder da TDP se aplica apenas às conexões necessárias para a recriação de tabelas, não às conexões necessárias para verificações de acionadores. Uma verificação de gatilho é uma consulta que verifica se a estratégia de persistência da tabela é acionada. Como essas consultas de verificação de gatilho são sempre executadas sequencialmente, a configuração Número máximo de conexões do builder da TDP não se aplica.
  • Em uma instância em cluster do Looker, o regenerador é executado apenas no nó principal. A configuração Número máximo de conexões do builder da TDP se aplica apenas ao nó principal e, portanto, define o limite para todo o cluster.
  • A configuração Número máximo de conexões do builder da TDP não se aplica aos seguintes tipos de tabelas. Esses tipos de tabelas são criados consecutivamente:
    • Tabelas mantidas pelo parâmetro persist_for (a menos que a tabela seja dependente de tabelas que usam as estratégias datagroup_trigger ou sql_trigger_value).
    • Tabelas no Modo de Desenvolvimento.
    • Tabelas recriadas com a opção Recriar tabelas derivadas e executar.
    • Tabelas em que uma depende da outra em uma cascata de dependência. Uma tabela não pode ser criada ao mesmo tempo que uma tabela de que ela depende. Por exemplo, se table_B depender de table_A, table_A precisará concluir a recriação antes que table_B possa começar a ser recriado.

Repetir builds de TDP com falha

A opção Repetir builds de TDP com falha configura como o regenerador do Looker tenta recriar tabelas com gatilho permanente que falharam no ciclo anterior do regenerador. O regenerador do Looker é o processo que recria tabelas com gatilho permanente (TDPs e tabelas de agregação) de acordo com o intervalo configurado na configuração de conexão Programação de manutenção. Quando a opção Repetir builds de TDP com falha está ativada, o regenerador do Looker tenta recriar uma TDP que falhou no ciclo anterior, mesmo que a condição de acionamento da TDP não seja atendida. Quando essa configuração está desativada, o regenerador do Looker tenta recriar uma TDP com falha anterior apenas quando a condição de acionamento da TDP é atendida. A opção Repetir builds de TDP com falha está desativada por padrão.

Consulte a página de documentação Tabelas derivadas no Looker para mais informações sobre o regenerador do Looker.

Controle da API de TDPs

O botão Controle da API de TDPs determina se as chamadas de API start_pdt_build, check_pdt_build e stop_pdt_build podem ser usadas para essa conexão. Quando o botão de alternância Controle da API de TDPs está desativado, essas chamadas de API falham ao referenciar TDPs nessa conexão. A opção Controle da API de TDPs fica desativada por padrão.

Ativar substituições de TDP

Se o banco de dados for compatível com tabelas derivadas persistentes e você tiver ativado a opção Ativar TDPs nas configurações de conexão, o Looker vai mostrar a opção Substituições de TDP. Ative a opção Substituições de TDP para exibir a seção Substituições de TDP, em que é possível inserir parâmetros JDBC separados (host, porta, banco de dados, nome de usuário, senha, esquema, parâmetros adicionais e instruções de conexão) específicos para processos de TDP. Isso pode ser útil por vários motivos:

  • Ao criar um usuário de banco de dados separado para processos de TDP, é possível usar TDPs no projeto do Looker mesmo que você atribua atributos de usuário às credenciais de login do banco de dados ou use o OAuth para a conexão do banco de dados.
  • Os processos de TDP podem ser autenticados por um usuário de banco de dados separado que tenha uma prioridade mais alta. Dessa forma, o banco de dados pode priorizar os jobs de TDP em relação a consultas de usuários menos críticas.
  • O acesso de gravação pode ser revogado para a conexão padrão do banco de dados do Looker e concedido apenas a um usuário especial que os processos de TDP usarão para autenticação. Essa é uma estratégia de segurança melhor para a maioria das organizações.
  • Para bancos de dados como o Snowflake, os processos de TDP podem ser roteados para um hardware mais potente que não é compartilhado com os outros usuários do Looker. Dessa forma, as TDPs podem ser criadas rapidamente sem o custo de executar hardware caro em tempo integral.

Por exemplo, em uma conexão em que os campos de nome de usuário e senha são definidos como atributos do usuário, a seção Substituições de TDP pode criar um usuário separado (pdt_user) com a própria senha. Com essa configuração, o seguinte vai acontecer:

  • Cada usuário pode acessar o banco de dados usando as credenciais individuais atribuídas pelos atributos de usuário.
  • A conta pdt_user será usada para todos os processos de TDP, com níveis de acesso adequados para a criação e atualização de TDPs.
  • O tráfego de consultas do usuário e o tráfego do processo de TDP podem ser diferenciados rapidamente para fins como monitoramento com a Atividade do sistema.

fuso horário do banco de dados

O fuso horário em que o banco de dados armazena informações baseadas em tempo. O Looker precisa saber disso para converter valores de tempo para os usuários, facilitando a compreensão e o uso de dados baseados em tempo. Consulte a página de documentação Como usar as configurações de fuso horário para mais informações.

fuso horário de consultas

A opção Fuso horário de consultas só fica visível se você desativar os fusos horários específicos dos usuários.

Quando os fusos horários específicos dos usuários estão desativados, o fuso horário de consultas é o fuso horário exibido para os usuários quando eles consultam dados baseados em tempo, e o fuso horário para o qual o Looker converterá os dados baseados em tempo do fuso horário do banco de dados.

Consulte a página de documentação Como usar as configurações de fuso horário para mais informações.

Abra a seção Detalhes do status para testar as configurações da conexão.

Revisar

Depois de inserir todas as configurações de conexão do banco de dados, você pode revisar e testar a conexão para garantir que ela esteja configurada corretamente.

Como testar as configurações de conexão

Para testar as configurações de conexão, clique no botão Testar conexão na seção Detalhes do status na parte de baixo da página Configurações de conexão.

Se o Looker exibir Pode se conectar, pressione Conectar para criar a conexão. A conexão do banco de dados é adicionada à lista na página Administrador de Conexões do Looker.

Os administradores podem testar a conexão a qualquer momento clicando no botão Testar ao lado da listagem da conexão na página Administrador de conexões, conforme descrito na página de documentação Conexões.

Se você tiver definido um ou mais valores de parâmetro de conexão como um atributo de usuário, a opção Testar como usuário vai aparecer. Selecione um usuário e clique em Testar para verificar se o banco de dados pode se conectar e executar consultas como esse usuário.

Solução de problemas

Se a conexão não passar em um ou mais testes, observe o seguinte:

  • Se você estiver executando a versão 3.6 ou anterior do Mongo no Atlas e receber uma falha no link de comunicação, consulte a página de documentação do conector do Mongo.
  • Para receber mensagens de conexão bem-sucedida sobre o esquema temporário e as TDPs, você precisa permitir essa funcionalidade ao configurar o banco de dados do Looker. As instruções para fazer isso estão na página de documentação Instruções de configuração do banco de dados.
  • As conexões de banco de dados que usam OAuth, como Snowflake, Google BigQuery, Trino e Databricks, exigem um login de usuário. Se você não tiver feito login na sua conta de usuário do OAuth ao testar uma dessas conexões, o Looker vai mostrar um aviso com um link Fazer login. Clique no link, selecione Autorizar na caixa de diálogo Autorizar conexão OAuth, se solicitado, e insira suas credenciais do OAuth para permitir que o Looker acesse as informações da sua conta do OAuth.
  • Para instâncias do Looker hospedadas pelo cliente, consulte a página de documentação Como testar a conectividade do banco de dados para instâncias hospedadas pelo cliente para ver dicas de solução de problemas.

Próximas etapas

Depois de conectar o banco de dados ao Looker, você poderá configurar as opções de login para os usuários.