Como conectar o Looker ao banco de dados

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

Você cria 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:

  • Selecione Conexões na seção Banco de dados do painel Administrador. Na página Conexões, clique no botão Adicionar conexão.
  • Clique no botão Criar no painel de navegação à esquerda e selecione o item de menu Conexão.

Para mais informações sobre 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 do usuário.

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

Depois de inserir as configurações de conexão do banco de dados, selecione o botão Testar na página Conectar seu banco de dados ao Looker para testar a conexão e garantir que ela esteja configurada corretamente. Clique em Testar para verificar se a conexão foi estabelecida. Consulte a página de documentação Teste de conectividade do banco de dados para informações sobre solução de problemas. Se o Looker mostrar Can Connect, pressione Connect para criar a conexão. Sua conexão de banco de dados é adicionada à lista na página do administrador Conexões do Looker.

Configurações gerais

Nome

O nome da conexão como você quer se referir a ela. 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 Conexões Administrador 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.

Escopo da conexão

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. Portanto, o nome da conexão pode ser especificado no parâmetro connection dos arquivos de modelo do projeto.
  • Projeto selecionado: apenas um projeto do LookML na instância pode ter acesso à conexão. Quando você seleciona essa opção, a tela de conexão mostra um menu suspenso com os projetos na instância. Selecione o projeto que pode ter acesso a essa conexão.

Use esta 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

Para conexões apenas com o 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 no seu banco de dados, insira "localhost" no campo Host.

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

Banco de dados

O nome do banco de dados no seu host. Por exemplo, é possível ter o nome do host my-instance.us-east-1.redshift.amazonaws.com em que há um banco de dados chamado sales_info. Você deve inserir sales_info neste campo. Se você tem vários bancos de dados no mesmo host, pode ser necessário criar várias conexões para usá-los (exceto o 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 de projetos do LookML e quando está consultando tabelas.

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, você tem a opção de configurar o OAuth ou uma conta de serviço para que o Looker use para autenticação no seu banco de dados.
  • Para conexões do Snowflake, Trino e Databricks, você tem a opção de configurar o OAuth ou uma conta de banco de dados para que o Looker use para autenticação no seu banco de dados.

Quando você usa o OAuth, os usuários precisam fazer login no seu banco de dados para emitir consultas do Looker. 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 de usuário no banco de dados que o Looker pode usar para se conectar.

Senha

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

Configurações opcionais

Servidor SSH

A opção Servidor SSH só está disponível se a instância for implantada na infraestrutura do Kubernetes e se a capacidade de adicionar informações de configuração do servidor SSH à instância do Looker estiver ativada. Se essa opção não estiver ativada na sua instância do Looker e você quiser ativar, 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 do localhost para você, e não é possível especificar essa porta. Se precisar 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 de 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 manualmente uma porta local, selecione Entrada manual e insira o número da porta no campo Porta local personalizada. Verifique se a porta local está disponível na sua instância.

Tabelas derivadas persistentes (TDPs)

Ativar TDPs

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

Observe o seguinte sobre as PDTs:

  • As TDPs não são compatíveis com conexões Snowflake que usam OAuth.
  • Desativar as TDPs em uma conexão não desativa os grupos de dados associados a elas. Mesmo que você desative as PDTs, os grupos de dados 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 seu projeto do LookML. Também é possível atualizar a configuração Datagroup and PDT Maintenance Schedule da conexão para que o Looker verifique as PDTs 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 executados pelo Looker para manter o sistema de registro de TDP.

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

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

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

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

  • Tabelas com gatilho permanente (tabelas derivadas persistentes e tabelas agregadas 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 gerador não inicia builds para tabelas persist_for.

A configuração Número máximo de conexões do criador de TDP é padrão 1, mas pode ser definida como 10. No entanto, o valor não pode ser maior do que o definido no campo Conexões máximas 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 poderá ficar sobrecarregado. Se o valor for baixo, as PDTs de execução longa ou as tabelas agregadas podem atrasar a criação de outras tabelas persistentes ou diminuir a velocidade de outras consultas na conexão. Os bancos de dados que oferecem suporte à multitenência, como BigQuery, Snowflake e Redshift, podem ter melhor desempenho no processamento de builds de consulta paralela.

Se você quiser aumentar a configuração Número máximo de conexões do builder de PDT, uma boa regra prática é aumentá-la em um incremento de 1. Se ocorrer um comportamento inesperado, volte ao padrão 1. Caso contrário, se o desempenho da consulta não for afetado, continue aumentá-la incrementalmente em 1 e verificar 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 de PDT:

  • A configuração Número máximo de conexões do criador de TDP se aplica apenas às conexões necessárias para a reconstrução de tabelas, não às conexões necessárias para verificações de acionadores. Uma verificação de acionador é uma consulta que verifica se a estratégia de persistência da tabela foi acionada. Como essas consultas de verificação de acionador são sempre executadas sequencialmente, a configuração Número máximo de conexões do construtor de PDT não se aplica.
  • Em uma instância do Looker em cluster, o regenerador é 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 TDP não se aplica aos tipos de tabela a seguir. Estes tipos de tabelas são criados de forma consecutiva:
    • tabelas mantidas por meio do parâmetro persist_for (a menos que elas dependam de tabelas que usam as estratégias datagroup_trigger ou sql_trigger_value).
    • Tabelas no Modo de Desenvolvimento.
    • Tabelas reconstruídas com a função Reconstruir tabelas derivadas e Run.
    • 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 da qual depende. Por exemplo, se table_B depende de table_A, table_A precisa concluir a recriação antes que table_B possa iniciar a recriação.

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

O regenerador do Looker verifica grupos de dados e tabelas persistidas (tabelas agregadas e tabelas derivadas persistentes) com base em sql_trigger_value. Com base nessas verificações, o regenerador do Looker recria ou exclui tabelas persistidas do esquema inicial do banco de dados.

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

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

O padrão de cinco minutos também é o intervalo mais frequente compatível com a Programação de manutenção de PDT e grupo de dados. O Looker não impõe um intervalo máximo para a programação de manutenção de PDT e grupo de dados. Isso significa que é possível estender o intervalo entre os ciclos de regenerador do Looker pelo tempo que puder ser especificado por uma expressão cron. 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 recriar a PDT em um ciclo, ele vai aguardar o próximo intervalo cron para iniciar o próximo ciclo. Se você tiver builds de TDP de longa duração, talvez tenham longos períodos entre os ciclos de regenerador do Looker. Outros fatores podem afetar o tempo necessário para recriar as tabelas, conforme descrito na seção Considerações importantes para a implementação de tabelas persistentes na página Tabelas derivadas no Looker.

Se seu banco de dados não estiver ativo 24 horas por dia, 7 dias por semana, é recomendável limitar as verificações aos horários em que ele está ativo. Confira outras expressões cron:

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

Algumas observações ao criar uma expressão cron:

  • O Looker usa parse-cron v0.1.3, que não oferece suporte a ? 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 de cron para o padrão */5 * * * *.

Confira 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 as tabelas com acionamento persistente que falharam no ciclo anterior do regenerador. O regenerador do Looker é o processo que recria tabelas com acionamento persistente (PDTs e tabelas agregadas) de acordo com o intervalo configurado na configuração de conexão Programação de manutenção de grupos de dados e PDTs. 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 PDT 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 fica 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 Controle da API de TDP estiver desativado, essas chamadas de API vão falhar quando fizerem referência a TDPs nessa conexão. A opção Controle da API de TDPs fica desativada 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 PDTs nas configurações de conexão, o Looker vai mostrar a seção Substituições de PDT. 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 pós-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 os processos de TDP, é possível usá-las no seu 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 com o banco de dados.
  • Os processos de PDT podem ser autenticados por um usuário de banco de dados separado com prioridade mais alta. Dessa forma, o banco de dados pode priorizar os jobs de TDP em vez de 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 PDT podem ser roteados para hardwares mais poderosos que não são compartilhados com os demais usuários do Looker. Dessa forma, os PDTs podem ser criados rapidamente sem incorrer no custo de executar hardwares caros o tempo todo.

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 as 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 adequados para criação e atualização de TDP.

Seção "Substituições de TDP" da página "Conectar seu banco de dados ao Looker".

Fuso horário

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 os 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 da consulta só ficará visível se você tiver desativado Fusos horários específicos do usuário.

Quando a opção Fusos horários específicos do usuário está desativada, o fuso horário da consulta é o fuso horário mostrado aos usuários quando eles consultam dados baseados em tempo, e o fuso horário em que o Looker vai converter os dados desse tipo 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.

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 referenciar um atributo do usuário em um parâmetro JDBC, use a sintaxe de modelagem de modelos Liquid: _user_attributes['name_of_attribute']. Exemplo:

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

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ê está definindo o número de consultas simultâneas que o Looker pode executar no seu banco de dados. O Looker também reserva até três conexões para matar 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á ficar sobrecarregado. Se o valor for muito baixo, as consultas vão precisar compartilhar um número pequeno de conexões. Assim, muitas consultas podem parecer lentas para os usuários, porque precisam esperar o retorno de outras consultas anteriores.

O valor padrão (que varia de acordo com o dialeto SQL) geralmente é 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 aceitas. Se a configuração do banco de dados limitar as conexões, verifique se o valor de Conexões máximas 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 a configuração Conexões máximas por nó, as solicitações vão esperar que as outras 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 o valor for muito baixo, as consultas dos usuários podem ser canceladas porque não há tempo suficiente para consultas sejam concluídas. Se ele for muito alto, um grande número de consultas poderá se acumular, fazendo com que os usuários esperem por muito tempo. O valor padrão costuma ser 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 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 (AC) 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 do banco de dados não será estabelecida.

Se a caixa não estiver selecionada, a criptografia SSL ainda será usada na conexão, mas a verificação da conexão SSL não será necessária. Portanto, uma conexão poderá ser estabelecida quando a AC não estiver na lista de origens confiáveis do cliente.

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 exiba rapidamente as colunas da tabela assim que você clicar no nome de uma tabela. No entanto, para conexões e esquemas com muitas tabelas ou 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 da tabela somente quando uma tabela for selecionada, desmarque a opção SQL Runner Precache para desativar o pré-carregamento do SQL Runner para a conexão.

Buscar esquema de informações para escrita em SQL

Para alguns recursos de programação SQL, como awareness agregado, o Looker usa o esquema de informações do seu banco de dados para otimizar a programação 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 buscar o esquema de informações. 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 é lento, desative a opção Buscar esquema de informações para gravação SQL na conexão. Desativar esse recurso vai impedir a otimização de alguns recursos do SQL do Looker. Por isso, ative a opção Buscar esquema de informações para gravação de SQL, a menos que você saiba que o esquema de informações da sua conexão é particularmente lento.

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:

Consulte a página de documentação Analisar dados no Looker para mais informações.

Pool de conexão de banco de dados

Para dialetos compatíveis com 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 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 fique disponível para reutilização após o término da execução. Consulte a página de documentação Agrupamento de conexões de banco de dados para mais informações.

Como testar as 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 de baixo da página Configurações de conexões.
  • Selecione o botão Testar ao lado da lista de conexões na página de administrador Conexões, conforme descrito na página de documentação Conexões.

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

Se a conexão não passar em um ou mais testes, confira estas opções de solução de problemas:

  • 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ções, 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 PDTs, permita essa funcionalidade ao configurar seu banco de dados do Looker. As instruções para isso podem ser encontradas na página de documentação Instruções de configuração do banco de dados.

Se você ainda tiver problemas, entre em contato com o suporte do Looker.

Testar como usuário

Se você definiu um ou mais valores de parâmetro de conexão para um atributo do 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.

Próximas etapas

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