Associar o Looker à sua base de dados

Depois de proteger e configurar a base de dados, pode associá-la ao Looker. Esta página descreve o novo fluxo de trabalho de ligação do Looker.

Cria uma ligação à base de dados no Looker na página Associe a sua base de dados ao Looker. Existem duas opções para abrir a página Associe a sua base de dados ao Looker:

  • Clique no ícone Menu principal, selecione Administração e, de seguida, selecione Ligações na secção Base de dados no painel Administração. Na página Ligações, clique no botão Adicionar ligação.
  • Clique no botão Criar no menu de navegação principal e, de seguida, selecione o item de menu Associação.

Esta página descreve os campos comuns que o Looker apresenta na página Associe a sua base de dados ao Looker. Os campos exatos que a página apresenta dependem da sua definição de variante.

Para obter informações sobre a aplicação de atributos do utilizador às definições de associação, consulte a secção Associações da página de documentação Atributos do utilizador.

A configuração da ligação à base de dados inclui as seguintes quatro secções:

Definições gerais

Nome

O nome da associação como quer referir-se a ela. Precisa deste nome de ligação à base de dados para usar no parâmetro connection do seu modelo LookML. O nome da associação à base de dados também é a forma como a associação é identificada na página Associações Administração do Looker. Não use o nome de nenhuma pasta para esta definição. Este valor não tem de corresponder a nada na sua base de dados. Name é uma etiqueta que identifica esta ligação na IU do Looker.

Dialeto SQL

O dialeto de SQL que corresponde à ligação. É importante escolher o valor correto para ver as opções de ligação adequadas e para o Looker poder converter corretamente o seu LookML em SQL.

Use a versão mais recente do controlador

Por predefinição, o Looker liga-se sempre à sua base de dados através da versão mais recente do controlador JDBC para o dialeto da base de dados. Se o dialeto da base de dados selecionado tiver mais do que uma versão do controlador JDBC suportada pelo Looker, pode desativar o botão Usar a versão mais recente do controlador para selecionar uma versão anterior do controlador JDBC para a ligação. Se quiser selecionar uma versão anterior do controlador JDBC, pode desativar o botão Usar a versão mais recente do controlador para a sua ligação e, em seguida, selecionar a versão do controlador no menu pendente Versão do controlador.

Se selecionar uma versão anterior do controlador JDBC, o Looker continua a usar essa versão anterior enquanto o Looker a suportar.

O Looker vai deixar de suportar uma versão do controlador nos dois cenários seguintes:

  • A versão do controlador foi removida do apoio técnico do Looker. Neste caso, a ligação usa a versão do controlador mais antiga que o Looker suporta para o dialeto.
  • A versão do controlador ainda não existe devido a uma reversão do Looker. Neste caso, a ligação usa a versão mais recente do controlador suportada pela versão revertida.

Se a versão do controlador selecionada já não for suportada pelo Looker, o Looker apresenta um alerta no campo Versão do controlador na página Edite a ligação à base de dados para informar que a versão do controlador selecionada já não é suportada. O alerta também informa sobre a versão do controlador que o Looker está a usar para a ligação. Para limpar este alerta, selecione uma versão do controlador JDBC suportada no menu pendente Versão do controlador ou ative o botão Usar a versão mais recente do controlador para usar a versão mais recente do controlador.

Âmbito do projeto

Selecione se a associação deve poder ser usada com todos os projetos ou apenas com um projeto:

  • Todos os projetos: todos os projetos do LookML na instância podem ter acesso à ligação, pelo que o nome da ligação pode ser especificado no parâmetro connection dos ficheiros de modelo nesse projeto.
  • Projeto selecionado: apenas um projeto do LookML na instância pode ter acesso à ligação. Quando seleciona esta opção, o ecrã de associação apresenta um menu pendente dos projetos na instância. Selecione o projeto que pode ter acesso a esta associação.

Use esta opção juntamente com as seguintes autorizações para delegar a gestão de associações e a configuração de modelos:

Detalhes do estado

Expanda a secção Detalhes do estado para testar as definições da sua associação.

Definições da base de dados

Ative o servidor SSH

A opção Servidor SSH só está disponível se a instância estiver implementada na infraestrutura do Kubernetes e a capacidade de adicionar informações de configuração do servidor SSH à sua instância do Looker tiver sido ativada. Se esta opção não estiver ativada na sua instância do Looker e quiser ativá-la, contacte um Google Cloud especialista de vendas ou abra um pedido de apoio técnico. Se ativar a opção Ativar servidor SSH, o Looker apresenta os campos Servidor SSH e Túnel SSH.

Servidor SSH

Não pode especificar a porta de anfitrião local. O servidor SSH escolhe automaticamente a porta de anfitrião local por si. Se precisar de criar uma ligação SSH que exija que especifique uma porta localhost, abra um pedido de apoio técnico.

Selecione uma configuração do servidor SSH na lista pendente. É necessário um servidor SSH para selecionar ou criar um túnel SSH adequado. Pode criar um novo servidor SSH no separador Servidores SSH no painel Ligações.

Túnel SSH

Selecione um túnel SSH existente na lista pendente ou clique no ícone Criar novo túnel se quiser criar um novo túnel SSH com um nome do anfitrião e uma porta ou uma porta local.

Nome do anfitrião

O nome de anfitrião da base de dados que o Looker deve usar para estabelecer ligação ao anfitrião da base de dados.

Se trabalhou com um analista do Looker para configurar um túnel SSH para a sua base de dados, no campo Anfitrião, introduza "localhost". Se aplicar um atributo do utilizador ao campo Anfitrião, o atributo do utilizador não pode ter um nível de acesso do utilizador definido como Editável. Se configurou um túnel SSH para estabelecer ligação à sua base de dados, não pode aplicar um atributo do utilizador ao campo Anfitrião remoto:Porta.

Porta

A porta da base de dados que o Looker deve usar para estabelecer ligação ao anfitrião da base de dados.

Se trabalhou com um analista do Looker para configurar um túnel SSH para a sua base de dados, no campo Porta, introduza o número da porta que redireciona para a sua base de dados, que o analista do Looker lhe deve ter fornecido.

Porta local

Por predefiniçã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 introduza um número de porta no campo Porta local personalizada. Certifique-se de que a porta local está disponível na sua instância.

ID do projeto de faturação (apenas no Google BigQuery)

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

ID do projeto de armazenamento (apenas no Google BigQuery)

O nome do ID do projeto de armazenamento, se separar a computação e o armazenamento em projetos separados. Pode consultar conjuntos de dados num Google Cloud projeto diferente Google Cloud se os programadores do LookML especificarem nomes de tabelas totalmente abrangentes no parâmetro sql_table_name das visualizações, dos Explores ou das junções do LookML. Para mais informações, consulte a página de documentação do Google BigQuery.

Conjunto de dados principal (apenas no Google BigQuery)

O nome do conjunto de dados que quer que o Looker use por predefinição quando consulta a sua base de dados. Para mais informações, consulte a página de documentação do Google BigQuery.

Nome da base de dados

O nome da base de dados no anfitrião. Por exemplo, pode ter um nome do anfitrião de my-instance.us-east-1.redshift.amazonaws.com no qual existe uma base de dados denominada sales_info. Introduziria sales_info neste campo. Se tiver várias bases de dados no mesmo anfitrião, pode ter de criar várias ligações para as usar (com exceção do MySQL, em que a palavra base de dados significa algo ligeiramente diferente do que na maioria dos dialetos SQL).

Esquema predefinido

O esquema predefinido que o Looker usa quando não é especificado um esquema. Isto aplica-se quando usa a execução de SQL, durante a geração do projeto do LookML e quando consulta tabelas.

Definições de autenticação

Para as ligações Google BigQuery, Snowflake, Trino e Databricks, selecione o tipo de autenticação que quer que o Looker use para aceder à sua base de dados:

  • Para associações do Google BigQuery, tem a opção de configurar o OAuth ou uma conta de serviço para o Looker usar para autenticar na sua base de dados.
  • Para as ligações do Snowflake, Trino e Databricks, tem a opção de configurar o OAuth ou uma conta de base de dados para o Looker usar na autenticação na sua base de dados.

Quando usa o OAuth, os utilizadores têm de iniciar sessão na base de dados para emitir consultas do Looker. Para mais informações sobre a configuração do OAuth numa associação ao Looker, consulte os procedimentos de associação do Google BigQuery, Snowflake, Trino ou Databricks.

Nome de utilizador

O nome de utilizador de uma conta de utilizador na sua base de dados que o Looker pode usar para estabelecer ligação à base de dados.

Palavra-passe

A palavra-passe de uma conta de utilizador na sua base de dados que o Looker pode usar para estabelecer ligação à base de dados.

Expanda a secção Detalhes do estado para testar as definições da sua associação.

Definições opcionais

Máximo de ligações por nó

Aqui, pode definir o número máximo de ligações que o Looker pode estabelecer com a sua base de dados. Na maioria dos casos, está a definir o número de consultas simultâneas que o Looker pode executar na sua base de dados. O Looker também reserva até três ligações para a eliminação de consultas. Se o conjunto de ligações for muito pequeno, o Looker reserva menos ligações.

Defina este valor com cuidado. Se o valor for demasiado elevado, pode sobrecarregar a base de dados. Se o valor for demasiado baixo, as consultas têm de partilhar um pequeno número de ligações, o que pode fazer com que muitas consultas pareçam lentas aos utilizadores, uma vez que têm de aguardar a devolução de outras consultas anteriores.

O valor predefinido (que varia consoante o seu dialeto de SQL) é normalmente um ponto de partida razoável. A maioria das bases de dados também tem as suas próprias definições para o número máximo de ligações que aceitam. Se a configuração da base de dados limitar as ligações, certifique-se de que o valor de Ligações máximas por nó é igual ou inferior ao limite da base de dados.

Limite de tempo do conjunto de ligações

Se os seus utilizadores pedirem mais ligações do que a definição Máximo de ligações por nó está configurada, os pedidos aguardam que outros terminem antes de serem executados. Aqui, configura o período máximo de tempo que um pedido vai esperar. A predefinição é de 120 segundos.

Defina este valor com cuidado. Se estiver definido como demasiado baixo, os utilizadores podem descobrir que as respetivas consultas são canceladas porque não existe tempo suficiente para que as consultas de outros utilizadores terminem. Se for definido um valor demasiado elevado, podem acumular-se grandes números de consultas, o que faz com que os utilizadores esperem muito tempo. Normalmente, o valor predefinido é um ponto de partida razoável.

Máximo de consultas simultâneas para esta ligação

Este valor opcional limita o número de consultas simultâneas que o Looker envia para esta ligação da base de dados de uma só vez. Se chegarem mais pedidos simultâneos que exijam a mesma ligação, o Looker coloca-os em fila internamente e processa-os por ordem. A definição deste valor substitui um valor Max connections per node existente.

Máximo de consultas simultâneas por utilizador para esta ligação

Este valor opcional limita o número de consultas simultâneas de um utilizador que o Looker envia para esta ligação à base de dados de uma só vez. Se chegarem mais pedidos simultâneos que exijam a mesma ligação, o Looker coloca-os em fila internamente e processa-os por ordem.

Parâmetros JDBC adicionais

Se necessário, pode incluir aqui outros parâmetros Java Database Connectivity (JDBC) para as suas consultas.

Para fazer referência a um atributo do utilizador num parâmetro JDBC, use a sintaxe de modelos Liquid: _user_attributes['name_of_attribute']. Veja o exemplo seguinte:

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

Agendamento da manutenção

O regenerador do Looker verifica os grupos de dados e as tabelas persistentes (tabelas agregadas e tabelas derivadas persistentes) baseadas em sql_trigger_value. Com base nestas verificações, o regenerador do Looker recompila ou elimina tabelas persistentes do esquema de rascunho da sua base de dados.

O valor de Maintenance Schedule define o intervalo de cron para o regenerador do Looker. O regenerador do Looker inicia um ciclo de regeneração para verificar os grupos de dados e as tabelas persistentes no intervalo cron. Se um ciclo do regenerador do Looker ainda estiver em curso no intervalo de cron seguinte, o regenerador do Looker conclui o ciclo do regenerador em curso e, em seguida, aguarda até ao intervalo de cron subsequente para iniciar o ciclo do regenerador seguinte.

A definição Agendamento da manutenção aceita uma expressão cron. O valor predefinido é */5 * * * *, o que significa que o ciclo do regenerador do Looker inicia um ciclo no intervalo de cinco minutos, se o ciclo do regenerador anterior tiver sido concluído. Se o ciclo do regenerador anterior não tiver sido concluído, o regenerador do Looker é iniciado no intervalo de cinco minutos seguinte à conclusão do respetivo ciclo.

O intervalo predefinido de cinco minutos também é o intervalo mais frequente suportado para o Agendamento da manutenção. O Looker não aplica um intervalo máximo para a Programação de manutenção, o que significa que pode prolongar o intervalo entre os ciclos do regenerador do Looker durante o tempo que puder ser especificado por uma expressão cron. Tenha em atenção que os ciclos de regeneração do Looker mais longos podem afetar negativamente a atualização dos dados na cache e nas tabelas persistentes.

Depois de o regenerador do Looker concluir todas as verificações e as reconstruções de PDT num ciclo, aguarda o intervalo cron seguinte para iniciar o ciclo seguinte. Se tiver compilações de PDTs de longa duração, pode ter longos períodos entre ciclos de regeneração do Looker. Outros fatores podem afetar o tempo necessário para reconstruir as tabelas, conforme descrito na secção Considerações importantes para implementar tabelas persistentes na página Tabelas derivadas no Looker.

Se a sua base de dados não estiver disponível 24 horas por dia, 7 dias por semana, é recomendável limitar as verificações aos momentos em que a base de dados está disponível. Seguem-se algumas expressões cron adicionais:

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

Alguns aspetos a ter em conta quando cria uma expressão cron:

  • O Looker usa o parse-cron v0.1.3, que não suporta ? em expressões cron.
  • A expressão cron usa o fuso horário da aplicação do Looker para determinar quando são feitas as verificações.
  • Se as PDTs não estiverem a ser criadas, reponha a string cron para a predefinição de */5 * * * *.

Seguem-se alguns recursos que ajudam a criar strings cron:

SSL

Escolha se quer usar a encriptação SSL para proteger os dados à medida que são transferidos entre o Looker e a sua base de dados. O SSL é apenas uma opção que pode ser usada para proteger os seus dados. Outras opções seguras são descritas na página de documentação Ativar o acesso seguro à base de dados.

Validar SSL

Escolha se quer exigir a validação do certificado SSL usado pela ligação. Se for necessária a validação, a autoridade de certificação (AC) SSL que assinou o certificado SSL tem de constar da lista de origens fidedignas do cliente. Se a AC não for uma origem fidedigna, a ligação à base de dados não é estabelecida.

Se esta caixa não estiver selecionada, a encriptação SSL continua a ser usada na ligação, mas a validação da ligação SSL não é necessária. Por isso, é possível estabelecer uma ligação quando a AC não está na lista de origens fidedignas do cliente.

Coloque tabelas e colunas em pré-cache

Na execução de SQL, todas as informações das tabelas são pré-carregadas assim que seleciona uma ligação e um esquema. Isto permite que o SQL Runner apresente rapidamente as colunas da tabela assim que clicar no nome de uma tabela. No entanto, para associações e esquemas com muitas tabelas ou tabelas muito grandes, pode não querer que o SQL Runner pré-carregue todas as informações.

Se preferir que o SQL Runner carregue as informações da tabela apenas quando uma tabela é selecionada, pode desmarcar a opção Pré-armazenar tabelas e colunas em cache para desativar o pré-carregamento do SQL Runner para a ligação.

Obtenha e coloque em cache o esquema

Para algumas funcionalidades de escrita de SQL, como a consciência de agregação, o Looker usa o esquema de informações da sua base de dados para otimizar a escrita de SQL. Se o esquema de informações não estiver em cache, o Looker pode ter de bloquear ocasionalmente a escrita de SQL na base de dados para poder obter o esquema de informações. Para dialetos que usam o Hadoop Distributed File System (HDFS), a obtenção do esquema de informações pode demorar o suficiente para afetar significativamente o desempenho das suas consultas do Looker. Se souber que o seu esquema de informações é lento, pode desativar a opção Obter e colocar em cache o esquema para a sua ligação. Se desativar esta funcionalidade, impede alguma da otimização de SQL do Looker para determinadas funcionalidades. Por isso, deve ativar a opção Obter e colocar em cache o esquema, a menos que saiba que o esquema de informações da sua ligação é particularmente lento.

Estimativa de custos

O botão Estimativa de custos aplica-se apenas às seguintes ligações à base de dados:

O botão Estimativa de custos ativa as seguintes funcionalidades na associação:

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

Agrupamento de ligações da base de dados

Para dialetos que suportam o agrupamento de ligações à base de dados, esta funcionalidade permite que o Looker use conjuntos de ligações através do controlador JDBC. A partilha de ligações à base de dados permite um desempenho mais rápido das consultas. Uma nova consulta não precisa de criar uma nova ligação à base de dados, mas pode usar uma ligação existente da partilha de ligações. A capacidade de agrupamento de ligações garante que uma ligação é limpa após a execução de uma consulta e está disponível para reutilização após o fim da execução da consulta. Consulte a página de documentação Pool de ligações à base de dados para mais informações.

Definições das tabelas derivadas persistentes (PDTs)

As seguintes definições são apresentadas se as PDTs estiverem ativadas.

Ativar PDTs

Ative o botão Ativar PDTs para ativar as tabelas derivadas persistentes. Quando as PDTs estão ativadas, a janela Associação revela campos de PDTs adicionais e a secção Substituições de PDTs. O Looker apresenta o botão Ativar PDTs apenas se o dialeto da base de dados suportar a utilização de PDTs.

Tenha em atenção o seguinte acerca das PDTs:

  • As PDTs não são suportadas para associações ao Snowflake que usam o OAuth.
  • A desativação dos PDTs numa associação não desativa os grupos de dados associados aos seus PDTs. Mesmo que desative os PDTs, os grupos de dados existentes continuam a executar as respetivas consultas sql_trigger na base de dados. Se quiser impedir que um grupo de dados execute a respetiva consulta sql_trigger na sua base de dados, tem de eliminar ou comentar o parâmetro datagroup do seu projeto LookML. Em alternativa, pode atualizar a definição Agenda de manutenção da ligação para que o Looker verifique os PDTs e os grupos de dados com pouca frequência ou nunca.
  • Para as ligações do Snowflake, o Looker define o valor do parâmetro AUTOCOMMIT como TRUE (o valor predefinido do Snowflake). AUTOCOMMIT é necessário para os comandos SQL que o Looker executa para manter o respetivo sistema de registo de PDT.

Base de dados temporária

Embora tenha a etiqueta de Base de dados temporária, vai introduzir o nome da base de dados ou o nome do esquema, conforme adequado para o dialeto SQL, que o Looker deve usar para criar tabelas derivadas persistentes. Deve configurar esta base de dados ou esquema antecipadamente, com as autorizações de escrita adequadas. Na página de documentação Instruções de configuração da base de dados, selecione o dialeto da base de dados para ver as instruções desse dialeto.

Cada ligação tem de ter um esquema ou uma base de dados temporária próprios, uma vez que não podem ser partilhados entre ligações.

Número máximo de ligações do compilador de PDTs

A definição Número máximo de ligações do compilador de PDTs permite-lhe especificar quantas compilações de tabelas simultâneas o gerador do Looker pode iniciar na ligação da base de dados. A definição Número máximo de ligações do compilador de PDTs aplica-se apenas aos tipos de tabelas para os quais o regenerador do Looker inicia reconstruções:

  • Tabelas de acionador persistentes (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 apenas quando a tabela persist_for faz parte de uma cascata de tabelas derivadas em que depende de uma tabela que usa a estratégia de persistência datagroup_trigger ou sql_trigger_value. Neste caso, o regenerador do Looker vai reconstruir uma tabela persist_for, uma vez que a tabela é necessária para reconstruir outra tabela na cascata. Caso contrário, o regenerador não inicia compilações para tabelas persist_for.

A predefinição da definição Número máximo de ligações do compilador de PDTs é 1, mas pode ser definida até 10. No entanto, o valor não pode ser superior ao valor definido no campo Máximo de ligações por nó ou no per-user-query-limit definido nas opções de arranque do Looker.

Defina este valor com cuidado. Se o valor for demasiado elevado, pode sobrecarregar a base de dados. Se o valor for baixo, as PDTs de execução prolongada ou as tabelas agregadas podem atrasar a criação de outras tabelas persistentes ou tornar outras consultas na ligação mais lentas. As bases de dados que suportam a multi-posse, como o BigQuery, o Snowflake e o Redshift, podem ter um melhor desempenho no processamento de compilações de consultas paralelas.

Se quiser aumentar a definição Número máximo de ligações de compilador de PDTs, é uma prática recomendada aumentá-la primeiro em 1. Se ocorrer algum comportamento inesperado, defina-o novamente para o valor predefinido de 1. Caso contrário, se o desempenho das consultas não for afetado, pode continuar a aumentá-lo gradualmente em 1 e verificar o desempenho em cada incremento antes de aumentar ainda mais a definição.

Tenha em atenção o seguinte acerca da definição Número máximo de ligações do compilador de PDTs:

  • A definição Número máximo de ligações do compilador de PDTs aplica-se apenas às ligações necessárias para a reconstrução de tabelas e não às ligaçõ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 é acionada. Uma vez que estas consultas de verificação de acionador são sempre executadas sequencialmente, a definição Número máximo de ligações do criador de PDTs não se aplica.
  • Numa instância do Looker agrupada, o regenerador é executado apenas no nó principal. A definição Número máximo de ligações do compilador de PDTs aplica-se apenas ao nó principal e, por conseguinte, define o limite para todo o cluster.
  • A definição Número máximo de ligações do compilador de PDTs não se aplica aos seguintes tipos de tabelas. Estes tipos de tabelas são criados consecutivamente:
    • Tabelas mantidas através do parâmetro persist_for (a menos que a tabela dependa de tabelas que usam as estratégias datagroup_trigger ou sql_trigger_value).
    • Tabelas no modo de programação.
    • Tabelas recompiladas com a opção Recompilar tabelas derivadas e executar.
    • Tabelas em que uma depende da outra numa cascata de dependências. Não é possível criar uma tabela ao mesmo tempo que uma tabela da qual depende. Por exemplo, se table_B depender de table_A, table_A tem de terminar a recriação antes de table_B poder começar a recriação.

Repetir compilações de PDTs falhadas

O botão Repetir compilações de PDTs falhadas configura a forma como o regenerador do Looker tenta recompilar tabelas persistentes acionadas que falharam no ciclo do regenerador anterior. O regenerador do Looker é o processo que recompila tabelas persistentes acionadas (PDTs e tabelas agregadas) de acordo com o intervalo configurado na definição de ligação Programação de manutenção. Quando o botão Repetir compilações de PDTs falhadas está ativado, o regenerador do Looker tenta recompilar uma PDT que falhou no ciclo do regenerador anterior, mesmo que a condição de acionamento da PDT não seja cumprida. Quando esta definição está desativada, o regenerador do Looker tenta recompilar uma PDT com falhas anteriores apenas quando a condição de acionamento da PDT é cumprida. A opção Repetir compilações de PDTs falhadas está desativada por predefinição.

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

Controlo da API PDT

O botão Controlo da API PDT determina se as chamadas API start_pdt_build, check_pdt_build e stop_pdt_build podem ser usadas para esta associação. Quando o botão Controlo da API PDT está desativado, estas chamadas API falham quando fazem referência a PDTs nesta ligação. O botão Controlo da API PDT está desativado por predefinição.

Ativar substituições de PDTs

Se a sua base de dados suportar tabelas derivadas persistentes e tiver ativado o botão Ativar PDTs nas definições de ligação, o Looker apresenta o botão Substituições de PDTs. Ative o botão Substituições de PDTs para apresentar a secção Substituições de PDTs, onde pode introduzir parâmetros JDBC separados (anfitrião, porta, base de dados, nome de utilizador, palavra-passe, esquema, parâmetros adicionais e declarações de associação) específicos dos processos de PDT. Isto pode ser valioso por vários motivos:

  • Ao criar um utilizador da base de dados separado para processos PDT, pode usar PDTs no seu projeto do Looker, mesmo que atribua atributos de utilizador às suas credenciais de início de sessão na base de dados ou use o OAuth para a ligação à base de dados.
  • Os processos PDT podem ser autenticados através de um utilizador da base de dados separado com uma prioridade mais elevada. Desta forma, a base de dados pode dar prioridade às tarefas PDT em detrimento das consultas de utilizadores menos críticas.
  • O acesso de escrita pode ser revogado para a associação padrão da base de dados do Looker e concedido apenas a um utilizador especial que os processos de PDT vão usar para autenticação. Esta é uma melhor estratégia de segurança para a maioria das organizações.
  • Para bases de dados como o Snowflake, os processos de PDT podem ser encaminhados para hardware mais potente que não é partilhado com os restantes utilizadores do Looker. Desta forma, os PDTs podem ser criados rapidamente sem incorrer no custo de execução de hardware dispendioso a tempo inteiro.

Por exemplo, numa ligação em que os campos de nome de utilizador e palavra-passe estão definidos como atributos do utilizador, a secção Substituições do PDT pode criar um utilizador separado (pdt_user) com a sua própria palavra-passe. Com esta configuração, ocorre o seguinte:

  • Cada utilizador pode aceder à base de dados através das respetivas credenciais individuais, conforme atribuídas pelos respetivos atributos do utilizador.
  • A conta pdt_user vai ser usada para todos os processos da PDT, com níveis de acesso adequados à criação e atualização da PDT.
  • O tráfego de consultas de utilizadores e o tráfego de processos de PDT podem ser rapidamente diferenciados para fins como a monitorização com a Atividade do sistema.

Fuso horário da base de dados

O fuso horário no qual a base de dados armazena informações baseadas no tempo. O Looker precisa de saber isto para poder converter valores de tempo para os utilizadores, o que facilita a compreensão e a utilização de dados baseados no tempo. Consulte a página de documentação Usar definições de fuso horário para mais informações.

Fuso horário da consulta

A opção Fuso horário da consulta só é visível se tiver desativado os fusos horários específicos do utilizador.

Quando os fusos horários específicos do utilizador estão desativados, o fuso horário da consulta é o fuso horário apresentado aos utilizadores quando consultam dados baseados na hora, e o fuso horário para o qual o Looker converte dados baseados na hora do fuso horário da base de dados.

Consulte a página de documentação Usar definições de fuso horário para mais informações.

Expanda a secção Detalhes do estado para testar as definições da sua associação.

Reveja

Depois de introduzir todas as definições de ligação à base de dados, pode rever e testar a ligação para se certificar de que está configurada corretamente.

Pode testar as definições de ligação a partir de alguns locais na IU do Looker:

  • Selecione o botão Testar na secção Detalhes do estado na parte inferior da página Definições de associações.
  • Selecione o botão Testar junto à ficha da associação na página Administração de associações, conforme descrito na página de documentação Associações.

Se o Looker apresentar a mensagem Can Connect (É possível estabelecer ligação), prima Connect (Estabelecer ligação) para criar a ligação. A ligação à base de dados é adicionada à lista na página Ligações Administração do Looker.

Se tiver definido um ou mais valores de parâmetros de ligação para um atributo do utilizador, é apresentada a opção Testar como utilizador. Selecione um utilizador e, em seguida, clique em Testar para verificar se a base de dados consegue estabelecer ligação e executar consultas como este utilizador.

Resolução de problemas

Se a sua ligação não passar num ou mais testes, tenha em atenção o seguinte:

  • Se estiver a executar a versão 3.6 ou anterior do Mongo no Atlas e receber uma falha de ligação de comunicações, consulte a página de documentação do conector do Mongo.
  • Para receber mensagens de ligação bem-sucedida relativamente ao esquema temporário e aos PDTs, tem de permitir essa funcionalidade quando configurar a base de dados do Looker. Pode encontrar instruções para o fazer na página de documentação Instruções de configuração da base de dados.
  • As ligações à base de dados que usam o OAuth, como o Snowflake e o Google BigQuery, requerem o início de sessão de um utilizador. Se não tiver sessão iniciada na sua conta de utilizador do OAuth quando testar uma destas associações, o Looker apresenta um aviso com um link Iniciar sessão. Clique no link para introduzir as suas credenciais do OAuth ou para permitir que o Looker aceda às informações da sua conta do OAuth.
  • Para instâncias do Looker alojadas pelo cliente, consulte a página de documentação Testar a conetividade da base de dados para instâncias alojadas pelo cliente para ver sugestões de resolução de problemas.

Passos seguintes

Depois de associar a base de dados ao Looker, está tudo pronto para configurar as opções de início de sessão para os utilizadores.