Conectar o Looker ao seu banco de dados

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

Selecione Conexões na seção Banco de dados no painel Administrador. Na página Conexões, clique no botão Adicionar conexão. O Looker mostra a página Configurações de conexão.

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

Nesta página, descrevemos os campos comuns que o Looker mostra na página Configurações de conexão. Os campos exatos que a página Configurações de conexão exibe dependem de sua configuração de dialeto.

Depois de inserir as configurações de conexão do banco de dados, é possível selecionar o botão Testar na página Configurações de conexão para testar a conexão e verificar se ela está configurada corretamente. Clique em Testar para verificar se a conexão foi estabelecida. Consulte a página de documentação Como testar a conectividade do banco de dados para ver informações sobre solução de problemas. Se o Looker mostrar Pode se conectar, pressione Conectar para criar a conexão. A conexão do banco de dados é adicionada à lista na página de administração Conexões do Looker.

Configurações gerais

Nome

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

Escopo da conexão

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

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

Dialeto

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.

ID do projeto de faturamento

Apenas para conexões do Google BigQuery, o ID do projeto de faturamento é o ID do projeto do Google Cloud.

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".

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, digite o número da porta que redireciona para seu banco de dados, que seu analista do Looker deveria ter fornecido.

Banco de dados

O nome do banco de dados no seu host. Por exemplo, você pode ter o nome do host my-instance.us-east-1.redshift.amazonaws.com em que há um banco de dados chamado sales_info. Insira 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 de MySQL, em que a palavra banco de dados significa algo um pouco diferente do que na maioria dos dialetos SQL).

Esquema

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

Autenticação

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

  • Nas conexões do Google BigQuery, você tem a opção de configurar o OAuth ou uma conta de serviço para o Looker fazer a autenticação no seu banco de dados.
  • Para conexões do Snowflake, você tem a opção de configurar o OAuth ou uma conta de banco de dados para a autenticação do Looker no seu banco de dados.

Quando você usa o OAuth, seus usuários precisam fazer login no banco de dados para emitir consultas do Looker. Consulte a página do Google BigQuery ou do Snowflake para ver o procedimento completo de configuração do OAuth.

Nome do usuário

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

Senha

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

Configurações opcionais

Servidor SSH

A opção Servidor SSH só vai estar disponível se a instância for implantada na infraestrutura do Kubernetes e somente se a capacidade de adicionar informações de configuração do servidor SSH à instância do Looker tiver sido 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 em vendas do Google Cloud ou abra uma solicitação de suporte.

O servidor SSH escolhe automaticamente a porta localhost para você, e não é possível especificar a porta localhost. Se for preciso criar uma conexão SSH que exija a especificação de uma porta localhost, abra uma solicitação de suporte.

Para se conectar ao banco de dados usando um túnel SSH, ative a opção e selecione uma Configuração do servidor SSH na lista suspensa.

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 digite um número de porta no campo Porta local personalizada. Verifique se a porta local está disponível na instância.

Tabelas derivadas persistentes (TDPs)

Ativar TDPs

Ative a opção Ativar TDPs para ativar tabelas derivadas persistentes. Quando as TDPs estão ativadas, a janela Conexão revela campos adicionais da TDP e a seção Substituições de TDP. O Looker exibe a opção Ativar TDPs somente se o dialeto do banco de dados permitir o uso de TDPs.

Observe o seguinte sobre TDPs:

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

Banco de dados temporário

Embora o rótulo seja Temp Database, digite o nome do banco de dados ou do esquema (conforme apropriado para o dialeto SQL) que o Looker deve usar para criar tabelas derivadas persistentes. Configure esse banco de dados ou esquema antecipadamente, com as permissões de gravação adequadas. Na página de documentação Instruções de configuração do banco de dados, selecione o dialeto do banco de dados para ver as instruções para esse dialeto.

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

Número máximo de conexões do criador da TDP

A configuração Número máximo de conexões do criador de TDP permite especificar quantas builds de tabela simultâneas o regenerador do Looker pode iniciar na conexão do banco de dados. A configuração Número máximo de conexões do criador de TDP se aplica apenas aos tipos de tabelas em que o regenerador do Looker inicia recriações:

  • Tabelas mantidas em acionador (tabelas derivadas persistentes e tabelas agregadas que usam a estratégia de persistência datagroup_trigger ou sql_trigger_value).
  • Tabelas mantidas que usam a estratégia persist_for, mas apenas 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 recriará uma tabela persist_for, já que a tabela é necessária para recriar outra tabela na cascata. Caso contrário, o regenerador não iniciará builds para tabelas persist_for.

A configuração Número máximo de conexões do criador da TDP é padronizada como 1, mas pode ser definida até 10. 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, seu banco de dados pode sobrecarregar. Se o valor for baixo, TDPs ou tabelas de agregação de longa duração poderão atrasar a criação de outras tabelas persistentes ou atrasar outras consultas na conexão. Bancos de dados compatíveis com multilocação, como BigQuery, Snowflake e Redshift, podem ter um desempenho melhor ao processar builds de consultas paralelas.

Se você quiser aumentar a configuração Número máximo de conexões do criador da TDP, uma boa regra prática é aumentar esse valor em um incremento de 1. Se ocorrer algum comportamento inesperado, defina o padrão como 1. Caso contrário, se o desempenho da consulta não for afetado, continue aumentando-o incrementalmente em 1 e verificando o desempenho a 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 criador da TDP:

  • A configuração Número máximo de conexões do criador de TDPs 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 acionador é uma consulta que confere se a estratégia de persistência da tabela é acionada. Como essas consultas de verificação do acionador são sempre executadas em sequência, a configuração Número máximo de conexões do criador de TDP não se aplica.
  • Em uma instância em cluster do Looker, o regerador é executado apenas no nó principal. A configuração Número máximo de conexões do criador 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 criador de TDPs não se aplica aos tipos de tabelas a seguir. Esses tipos de tabela são criados em sequência:
    • Tabelas mantidas pelo parâmetro persist_for (a menos que dependam 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 dependência em cascata. Uma tabela não pode ser criada ao mesmo tempo que uma tabela da qual depende. Por exemplo, se a table_B depender de table_A, a recriação da table_A vai precisar ser concluída antes que a table_B possa começar a ser recriada.

Programação de manutenção de TDP e grupo de dados

O regerador do Looker verifica datagroups e tabelas persistentes (tabelas agregadas e tabelas derivadas persistentes) que são baseadas em sql_trigger_value. Com base nessas verificações, o regenerador do Looker recria ou remove tabelas mantidas do esquema do zero do banco de dados.

O valor de datagroup e programação de manutenção de TDP define o intervalo cron para o regenerador do Looker. O regenerador do Looker inicia um ciclo de regeneração para verificar grupos de dados e tabelas persistentes no intervalo cron. Se um ciclo de regenerador do Looker ainda estiver em andamento no próximo intervalo de cron, ele vai concluir o ciclo em andamento e aguardar até o intervalo de cron subsequente para iniciar o próximo ciclo.

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

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

Depois que o regenerador do Looker concluir todas as verificações e recriações da TDP em um ciclo, ele aguardará o próximo intervalo cron para iniciar o próximo. Se você tiver builds de TDP de longa duração, talvez tenha períodos longos entre os ciclos de regeneração 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 da página Tabelas derivadas no Looker.

Se o banco de dados não estiver disponível 24 horas, você pode limitar as verificações aos horários em que ele fica ativo. Confira mais algumas expressões cron:

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

Alguns pontos a serem observados ao criar uma expressão cron:

  • O Looker usa 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 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 */5 * * * *.

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

Repetir builds de TDP com falha

O botão Repetir builds de TDP com falha configura como o regenerador do Looker tenta recriar tabelas persistentes no acionador que falharam no ciclo anterior. O regenerador do Looker é o processo que recria tabelas persistentes com acionadores (TDPs e tabelas agregadas) de acordo com o intervalo definido na configuração de conexão Programação de manutenção de TDP e grupo de dados. Quando a opção Repetir builds de TDP com falha está ativada, o regenerador do Looker tenta recriar uma TDP que falhou no ciclo de regeneração 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 que já tinha falhado somente quando a condição de acionamento da TDP for 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 de alternância Controle da API TDP 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 Controle da API de TDP estiver desativado, essas chamadas de API falharão quando fizerem referência a TDPs na conexão. O botão Controle da API de TDP fica desativado por padrão.

Substituições de TDP

Se o banco de dados oferecer suporte a tabelas derivadas persistentes e você tiver ativado a opção Ativar TDPs nas configurações de conexão, o Looker vai mostrar a seção Substituições de TDP. Na seção Substituições de TDP, é possível inserir parâmetros JDBC separados (host, porta, banco de dados, nome de usuário, senha, esquema, parâmetros adicionais e instruções após conexão) específicos dos processos de TDP. Isso pode ser valioso por vários motivos:

  • Ao criar um usuário do banco de dados separado para processos de TDP, é possível usar as TDPs no seu projeto do Looker mesmo que você atribua atributos de usuário às credenciais de login no banco de dados ou use o OAuth para a conexão do banco de dados.
  • Os processos de TDP podem ser autenticados por meio de um usuário separado do banco de dados que tem uma prioridade mais alta. Dessa forma, o banco de dados pode priorizar os jobs de TDP em vez de consultas menos críticas do usuário.
  • 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 vão usar 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 o restante dos usuários do Looker. Dessa forma, as TDPs podem ser criadas rapidamente sem incorrer no custo de execução de hardware caro em tempo integral.

Por exemplo, a configuração a seguir mostra uma conexão em que os campos de nome de usuário e senha são definidos como atributos do usuário. Dessa forma, cada usuário pode acessar o banco de dados usando suas próprias credenciais. A seção Substituições de TDP cria um usuário separado (pdt_user) com uma senha própria. A conta pdt_user será usada para todos os processos de TDP, com níveis de acesso apropriados para a criação e atualização de TDPs.

Fuso horário

fuso horário do banco de dados

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

fuso horário de consultas

A opção Fuso horário da consulta só ficará visível se você tiver desativado os Fusos horários específicos do usuário.

Quando os fusos horários específicos do usuário estão desativados, o fuso horário da consulta é mostrado aos usuários quando eles consultam dados com base no tempo, e é o fuso horário em que o Looker vai converter os dados baseados em tempo do fuso horário do banco de dados.

Para mais informações, consulte a página de documentação Como usar configurações de fuso horário.

Mais configurações

Parâmetros JDBC adicionais

É possível incluir outros parâmetros de Java Database Connectivity (JDBC) para suas consultas aqui, se precisar.

Para fazer referência a um atributo do usuário em um parâmetro JDBC, use a sintaxe Liquid modeling (em inglês): _user_attributes['name_of_attribute']. Exemplo:

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

Máximo de conexões por nó

Aqui é possível definir o número máximo de conexões que o Looker pode estabelecer com seu banco de dados. Na maioria das vezes, você está definindo 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 encerramento de 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, seu banco de dados poderá sobrecarregar. Se o valor for muito baixo, as consultas precisarão compartilhar um pequeno número de conexões. Assim, muitas consultas podem parecer lentas para os usuários, pois precisam aguardar o retorno de outras consultas anteriores.

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

Tempo limite do pool de conexão

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

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

SSL

Escolha se você quer ou não usar a criptografia SSL para proteger os dados transmitidos 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 Como 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 de certificação (CA, na sigla em inglês) 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 selecionada, a criptografia SSL ainda será usada na conexão, mas a verificação 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.

Custo estimado

O botão de alternância Estimativa de custo se aplica apenas às seguintes conexões de banco de dados:

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

Saiba mais na página de documentação Como analisar dados no Looker.

Pré-cache do SQL Runner

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 quando você clica no nome de uma tabela. 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 informações apenas quando uma tabela estiver selecionada, desmarque a opção SQL Runner Precache para desativar o pré-carregamento do SQL Runner na conexão.

Buscar esquema de informações para gravação em SQL

Para alguns recursos de gravação em SQL, como reconhecimento agregado, o Looker usa o esquema de informações do banco de dados para otimizar a gravação em SQL. Se o esquema de informações não for armazenado em cache, o Looker poderá ter que bloquear a gravação de SQL no banco de dados para conseguir buscar o esquema. Para 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ê souber que o esquema de informações está lento, desative a opção Fetch Information Schema for SQL write na sua conexão. Desativar esse recurso vai impedir a otimização de alguns recursos do Looker SQL. Por isso, ative a opção Buscar esquema de informações para gravação em SQL, a menos que você saiba que o esquema de informações da sua conexão está muito lento.

Como testar suas configurações de conexão

É possível testar as configurações de conexão em alguns lugares na interface do Looker:

  • Selecione o botão Testar na parte inferior da página Configurações de conexão.
  • Selecione o botão Testar ao lado da listagem da conexão na página do administrador Conexões, conforme descrito na página de documentação Conexões.

Depois de inserir as configurações de conexão, clique em Test para verificar se as informações estão corretas e se o banco de dados pode se conectar.

Se sua conexão não passar em um ou mais testes:

  • Siga algumas das etapas de solução de problemas na página de documentação Como testar a conectividade do banco de dados.
  • Se você estiver executando o Mongo versão 3.6 ou anterior no Atlas e ocorrer uma falha no link de comunicação, consulte a página de documentação do Mongo Connector.
  • Para receber mensagens de conexão bem-sucedidas relacionadas ao esquema temporário e às TDPs, você precisa permitir essa funcionalidade ao configurar o banco de dados do Looker. As instruções para fazer isso podem ser encontradas na página de documentação Instruções de configuração do banco de dados.

Se ainda tiver problemas, entre em contato com o suporte do Looker para receber ajuda.

Testar como usuário

Se você tiver definido um ou mais valores de parâmetro de conexão para um atributo do usuário, a opção Testar como usuário aparecerá acima do botão Testar. 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.

Próximas etapas

Depois de conectar seu banco de dados ao Looker, você estará pronto para configurar as opções de login para seus usuários.