A camada de modelagem semântica LookML do Looker permite que um analista de dados defina dimensões, agregações, cálculos e relações de dados em um banco de dados SQL. Os modelos da LookML oferecem reutilização de código e integração com o Git. Um modelo LookML bem estruturado permite que os usuários façam a própria exploração e geração de relatórios de dados de autoatendimento.
O modelo LookML é a base de todos os dados solicitados ao Looker, seja pela interface de visualização do Looker na interface do usuário do Looker, uma visualização incorporada no portal da sua empresa ou outro aplicativo de terceiros, ou um aplicativo personalizado desenvolvido com a API do Looker. A interface Open SQL oferece acesso aos modelos da LookML para qualquer aplicativo de terceiros que seja compatível com a conectividade de banco de dados Java (JDBC). Os aplicativos podem se conectar a um modelo do LookML como se fosse um banco de dados. Assim, os usuários aproveitam todo o trabalho feito pelos analistas de dados no modelo do LookML, usando as ferramentas com que têm mais familiaridade.
Como a interface Open SQL mostra elementos do projeto LookML
Para entender como a interface Open SQL mostra os elementos de um projeto do LookML, é importante entender como os projetos do LookML são estruturados.
Um projeto do LookML é uma coleção de arquivos que descrevem os objetos, as conexões de banco de dados e os elementos da interface do usuário usados para realizar consultas SQL no Looker. Consulte Termos e conceitos do LookML para mais informações. Os seguintes conceitos do projeto LookML estão relacionados à interface Open SQL:
- Um modelo do LookML especifica uma conexão de banco de dados e uma ou mais análises. A interface Open SQL mostra modelos como esquemas de banco de dados.
- Uma Análise é um agrupamento lógico de uma ou mais visualizações e as relações de junção entre elas. A interface Open SQL mostra as análises detalhadas como tabelas de banco de dados.
- Uma visualização define uma coleção de campos (dimensões e métricas). Uma visualização geralmente é baseada em uma tabela no seu banco de dados ou em uma tabela derivada. As visualizações podem conter as colunas da tabela de banco de dados subjacente, bem como as dimensões ou métricas personalizadas que os usuários finais podem precisar. A interface Open SQL mostra a combinação de um nome de visualização e um nome de campo como um nome de coluna de banco de dados. Por exemplo, a dimensão
id
na visualizaçãoorder_items
é apresentada pela interface Open SQL como uma coluna de banco de dados chamadaorder_items.id
.
Uma Análise do Looker pode definir relações de junção entre várias visualizações. Como é possível que uma visualização tenha um campo com o mesmo nome de um campo em outra visualização, a interface Open SQL inclui o nome da visualização e o nome do campo ao fazer referência a uma coluna. Portanto, use este formato para se referir a um nome de coluna ao enviar consultas para a interface Open SQL:
`<view_name>.<field_name>`
Por exemplo, se houver uma Análise chamada order_items
que une uma visualização chamada customer
com uma chamada product
, e ambas tiverem uma dimensão id
, você se referirá aos dois campos id
como `customer.id`
e `product.id`
, respectivamente. Para usar o nome totalmente qualificado com o nome da Análise, consulte os dois campos como `order_items`.`customer.id`
e `order_items`.`product.id`
. Consulte Usar acento grave em torno de identificadores de banco de dados para saber onde colocar os acentos graves ao se referir a identificadores de banco de dados.
Como configurar a interface Open SQL
Para usar a interface Open SQL, siga estas etapas:
- Verifique se os requisitos foram atendidos.
- Faça o download do arquivo de driver JDBC da interface Open SQL.
As seções a seguir descrevem essas etapas.
Requisitos
Os seguintes componentes são necessários para usar a interface Open SQL:
- O aplicativo de terceiros que você quer usar (como Tableau, ThoughtSpot ou um aplicativo personalizado) precisa se conectar à sua instância do Looker. A interface Open SQL pode ser usada com instâncias do Looker hospedadas pelo cliente, desde que a instância do Looker esteja em rede de forma que permita que o aplicativo de terceiros acesse a instância do Looker.
- Um projeto do LookML que usa dados de uma conexão do Google BigQuery. O projeto da LookML precisa ter um arquivo model que especifique uma conexão do Google BigQuery no parâmetro
connection
. - Uma função de usuário do Looker que inclui a permissão
explore
no modelo LookML que você quer acessar com a interface SQL aberta.
Baixar o driver JDBC da interface Open SQL
O driver JDBC da interface SQL aberta do Looker é chamado de avatica-<release_number>-looker.jar
. Faça o download da versão mais recente no GitHub em https://github.com/looker-open-source/calcite-avatica/releases.
O driver JDBC espera o seguinte formato de URL:
jdbc:looker:url=https://Looker instance URL
Exemplo:
jdbc:looker:url=https://myInstance.cloud.looker.com
A classe do driver JDBC é:
org.apache.calcite.avatica.remote.looker.LookerDriver
Como autenticar na interface Open SQL
A interface Open SQL é compatível com três métodos de autenticação:
OAuth
Os clientes JDBC que oferecem suporte ao OAuth podem ser configurados para usar o servidor OAuth de uma instância do Looker. Siga as etapas para configurar a autenticação OAuth:
- Use a extensão da API Explorer para registrar o cliente OAuth do JDBC com sua instância do Looker. Assim, ela poderá reconhecer solicitações do OAuth. Consulte Como registrar um aplicativo cliente OAuth para instruções.
- Faça login no Looker com o OAuth para solicitar um token de acesso. Consulte Como fazer login do usuário usando o OAuth para ver um exemplo.
- Use um objeto Properties para transmitir as credenciais do OAuth ao abrir a conexão JDBC com a interface Open SQL.
Confira um exemplo usando DriverManager#getConnection(<String>, <Properties>
`):
String access_token = getAccessToken() //uses the Looker OAuth flow to get a token
String URL = "jdbc:looker:url=https://myInstance.cloud.looker.com"
Properties info = new Properties( );
info.put("token", access_token);
Connection conn = DriverManager.getConnection(URL, info);
Gerar um token de acesso usando chaves de API
Em vez de usar o fluxo OAuth padrão para gerar um token de acesso, siga estas etapas para usar a API Looker e gerar um token de acesso que pode ser transmitido ao driver JDBC da interface Open SQL:
- Gere chaves de API para seu usuário do Looker, conforme descrito na página Configurações de administrador - Usuários.
Use o endpoint da API
login
para sua instância do Looker. A resposta inclui um token de acesso no formatoAuthorization: token <access_token>
. Confira abaixo um exemplo do comando curl que pode ser usado para fazer essa solicitação:curl -k -d "client_id=<client_id>&client_secret=<client_secret>" https://<looker_host>/login\
Transmita o valor
<access_token>
da resposta como o token no objeto de propriedades para transmitir as credenciais do OAuth ao abrir a conexão JDBC com a interface Open SQL.
Chaves de API
Também é possível usar chaves de API para autenticar em vez de um nome de usuário e senha. As chaves de API são consideradas menos seguras do que o OAuth e podem estar disponíveis apenas durante a prévia da interface Open SQL. Consulte Chaves de API para informações sobre como criar chaves de API para sua instância do Looker.
Use a parte ID do cliente da chave de API do Looker como nome de usuário. Use a parte Chave secreta do cliente para a senha.
Executar consultas com a interface Open SQL
Observe as seguintes diretrizes ao executar consultas com a interface Open SQL:
- A interface Open SQL aceita consultas SQL que seguem a sintaxe do GoogleSQL.
- A interface Open SQL exige crases (`) em torno dos identificadores de modelo, análise detalhada e campo. Consulte Usar crases em identificadores de banco de dados para mais informações e exemplos.
- A interface Open SQL é compatível com a maioria dos operadores do BigQuery.
- Com a interface Open SQL, é necessário designar todas as medidas da LookML incluídas em uma consulta envolvendo a medida (incluindo crases) na função especial
AGGREGATE()
. Consulte a seção Especificar medidas do LookML comAGGREGATE()
.
Limitações do SQL
Observe as seguintes limitações do SQL ao enviar consultas para a interface Open SQL:
- A interface Open SQL oferece suporte apenas a consultas
SELECT
. A interface Open SQL não oferece suporte a instruçõesUPDATE
eDELETE
nem a outras instruções de linguagem de definição de dados (DDL), linguagem de manipulação de dados (DML) ou linguagem de controle de dados (DCL). - A interface Open SQL não é compatível com o operador
JOIN
.- Não é possível enviar uma consulta com o operador
JOIN
para a interface Open SQL e criar junções na mesma Análise ou em duas diferentes. - Se você quiser criar uma junção entre duas tabelas no banco de dados, faça isso no modelo do LookML criando junções com uma ou mais visualizações em uma definição de Análise em um arquivo de modelo no projeto do LookML.
- Não é possível enviar uma consulta com o operador
- A interface Open SQL não é compatível com chamadas de função de janela.
- A interface Open SQL não é compatível com subconsultas.
- A interface Open SQL não é compatível com a conversão de fuso horário. Os carimbos de data/hora no modelo do LookML terão o tipo
DATETIME
no fuso horário definido nas suas configurações (fuso horário do usuário, fuso horário do aplicativo ou fuso horário do banco de dados). - A interface Open SQL não é compatível com os tipos de dados do BigQuery geography, JSON e time.
Use crase em identificadores de banco de dados
Ao enviar consultas para a interface Open SQL, use crases em torno dos identificadores de esquema, tabela e coluna. Veja como especificar elementos de banco de dados usando crases com termos do Looker:
- schema:
`<model_name>`
. - table:
`<explore_name>`
coluna:
`<view_name>.<field_name>`
Confira um exemplo de formato de instrução SELECT
usando esses elementos:
SELECT `view.field`
FROM `model`.`explore`
LIMIT 10;
Especificar medidas do LookML com AGGREGATE()
As tabelas de banco de dados geralmente contêm apenas dimensões, dados que descrevem um único atributo sobre uma linha na tabela. No entanto, os projetos do LookML podem definir dimensões e medidas. Uma medida é uma agregação de dados em várias linhas, como SUM
, AVG
, MIN
ou MAX
. Outros tipos de medidas também são aceitos. Consulte a página Tipos de medidas para ver a lista completa de tipos de medidas do LookML compatíveis.
Com a interface Open SQL, é necessário designar todas as medidas da LookML incluídas em uma consulta envolvendo a medida (incluindo crases) na função especial AGGREGATE()
. Por exemplo, use isso para especificar a métrica count da visualização orders:
AGGREGATE(`orders.count`)
É necessário incluir as medidas do LookML na função AGGREGATE()
, seja na cláusula SELECT
, HAVING
ou ORDER BY
.
Se você não tiver certeza se um campo é uma métrica do LookML, use o método DatabaseMetaData.getColumns
para acessar os metadados do projeto do LookML. A coluna IS_GENERATEDCOLUMN
vai indicar YES
para todas as medidas do LookML e NO
para as dimensões do LookML. Consulte a seção Como acessar metadados do banco de dados para mais informações.
Especifique campos e parâmetros somente para filtros com JSON_OBJECT
A interface SQL aberta é compatível com parâmetros e campos somente para filtros.
Ao executar consultas com a interface Open SQL, é possível aplicar parâmetros e campos somente de filtro à consulta incluindo uma chamada de construtor JSON_OBJECT
com o seguinte formato:
JSON_OBJECT(
'<view>.<parameter name>', '<parameter value>',
'<view>.<filter name>', '<Looker filter expression>'
)
O objeto JSON pode conter zero ou mais pares de chave-valor de filtro e zero ou mais pares de chave-valor de parâmetro.
- A chave no construtor
JSON_OBJECT
precisa ser o nome de um campo ou parâmetro somente para filtros. - Para campos somente para filtros, o valor de cada chave precisa ser uma expressão de filtro de string do Looker.
- Para parâmetros, o valor de cada chave precisa ser um valor simples definido na definição
parameter
.
Consulte as seções a seguir para ver exemplos de como usar parâmetros e campos somente para filtro com a interface Open SQL.
Exemplo de parâmetro
Como exemplo de uso de um parameter
com a interface Open SQL, se a visualização customers
tivesse um parâmetro definido no Looker da seguinte forma:
parameter: segment {
type: string
allowed_value: {
label: "Small (less than 500)"
value: "small_customers"
}
allowed_value: {
label: "Larger (greater than 10,000)"
value: "large_customers"
}
allowed_value: {
label: "Medium customers (Between 500 and 10,000)"
value: "medium_customers"
}
}
É possível enviar esta consulta à interface Open SQL para aplicar o valor do parâmetro segment
de medium_customers
à consulta:
SELECT `customers.segment_size`,
AGGREGATE(`orders.total_amount`)
FROM `ecommerce`.`orders`(JSON_OBJECT(
'customers.segment', 'medium_customers'
))
GROUP BY `customers.state`, `customers.city`
HAVING AGGREGATE(`orders.count`) > 10
ORDER BY 3 DESC LIMIT 5;
A interface SQL vai transmitir esse valor de parâmetro para a consulta no Looker, e o Looker vai aplicar o valor medium_customers
a todos os campos na Análise que estiverem configurados para usar o parâmetro segment
. Consulte a documentação parameter
para saber como os parâmetros funcionam no Looker.
Exemplo de campo somente para filtros
É possível usar um campo filter
com a interface Open SQL. Por exemplo, se uma visualização products
tiver uma dimensão e um campo somente para filtros definidos no Looker da seguinte maneira:
filter: brand_select {
type: string
}
dimension: brand_comparitor {
sql:
CASE
WHEN {% condition brand_select %} ${products.brand_name} {% endcondition %}
THEN ${products.brand_name}
ELSE "All Other Brands"
END ;;
}
É possível usar o filtro brand_select
com a interface Open SQL enviando uma consulta como esta:
SELECT `products.brand_comparator`, `products.number_of_brands`,
AGGREGATE(`products.total_revenue`)
FROM `ecommerce`.`orders`(JSON_OBJECT(
'products.brand_select', '%Santa Cruz%'
))
GROUP BY `products.brand_comparator`
ORDER BY 3 DESC LIMIT 5;
A interface SQL vai aplicar a expressão de filtro de string do Looker %Santa Cruz%
à consulta no Looker. Consulte a documentação filter
para saber como os campos somente para filtro funcionam no Looker.
Forneça valores always_filter
ou conditionally_filter
em uma cláusula WHERE
ou HAVING
A interface Open SQL pode ser compatível com uma análise detalhada que tenha always_filter
ou conditionally_filter
, mas não os dois.
Se você definiu a análise do LookML com always_filter
ou conditionally_filter
, transmita os valores dos campos de filtro na sua consulta SQL para a interface do SQL aberto:
- Se a definição de filtro especificar uma ou mais dimensões, inclua uma cláusula
WHERE
na consulta SQL para cada uma delas. - Se a definição de filtro especificar uma ou mais métricas, inclua uma cláusula
HAVING
na consulta SQL para cada uma delas.
Por exemplo, há um modelo faa
em que você definiu uma Análise do LookML flights
com um parâmetro always_filter
que especifica as dimensões country
e aircraft_category
e a métrica count
, da seguinte forma:
explore: flights {
view_name: flights
always_filter: {
filters: [country : "Peru" , aircraft_category : "Airplane", count : ">1"]
}
}
Na sua consulta à interface Open SQL, use uma cláusula WHERE
para transmitir valores para as dimensões de filtro e uma cláusula HAVING
para transmitir um valor para o filtro de métrica ao seu modelo do LookML, como este:
SELECT
`flights.make`
FROM
`faa`.`flights`
WHERE `flights.country` = 'Ecuador' AND `flights.aircraft_category` = 'Airplane'
GROUP BY
1
HAVING `flights.count` > 2)
LIMIT 5
Se você não transmitir valores de filtro para cada uma das dimensões e métricas especificadas no parâmetro always_filter
, a consulta vai retornar um erro. O mesmo vale para dimensões e medidas especificadas em um parâmetro conditionally_filter
, exceto que você pode definir um parâmetro conditionally_filter
com um subparâmetro unless
, assim:
explore: flights {
view_name: flights
conditionally_filter: {
filters: [country : "Peru" , aircraft_category : "Airplane"]
unless: [count]
}
}
Nesse caso, transmita um valor de filtro para cada uma das dimensões e métricas especificadas no subparâmetro filters
de conditionally_filter
, a menos que você especifique um filtro em um campo no subparâmetro unless
. Consulte a página de documentação do conditionally_filter
para saber como usar o subparâmetro unless
.
Por exemplo, qualquer uma das seguintes consultas à interface Open SQL seria aceita. A primeira consulta fornece valores de filtro para os campos especificados no subparâmetro filters
, e a segunda consulta fornece um valor de filtro para o campo especificado no subparâmetro unless
:
SELECT
`flights.make`
FROM
`faa`.`flights`
WHERE `flights.country` = 'Ecuador' AND `flights.aircraft_category` = 'Airplane'
LIMIT 5
SELECT
`flights.make`
FROM
`faa`.`flights`
GROUP BY
1
HAVING `flights.count` > 2
Exemplo
Confira um exemplo de consulta usando dimensões e métricas. Essa consulta recupera as dimensões estado e cidade da visualização clientes e a métrica valor total da visualização pedidos. As duas visualizações são unidas na análise detalhada pedidos do modelo e-commerce. Para as cidades com mais de 10 pedidos, essa resposta de consulta mostra as cinco principais cidades por valor do pedido:
SELECT `customers.state`, `customers.city`,
AGGREGATE(`orders.total_amount`)
FROM `ecommerce`.`orders`
GROUP BY `customers.state`, `customers.city`
HAVING AGGREGATE(`orders.count`) > 10
ORDER BY 3 DESC LIMIT 5;
Como acessar metadados do banco de dados
A interface Open SQL é compatível com um subconjunto da interface DatabaseMetaData padrão do JDBC, que é usada para receber informações sobre o banco de dados subjacente. É possível usar os seguintes métodos da interface DatabaseMetaData para receber informações sobre seu modelo LookML:
A interface SQL retorna resultados apenas para modelos, análises detalhadas e campos a que você tem acesso.
DatabaseMetadata.getSchemas
A tabela a seguir descreve como um modelo da LookML se relaciona com as estruturas de banco de dados padrão na resposta do método de interface DatabaseMetadata.getSchemas
.
getSchemas coluna de resposta |
Descrição |
---|---|
TABLE_SCHEM |
Nome do modelo do LookML |
TABLE_CATALOG |
(null) |
DatabaseMetadata.getTables
A tabela a seguir descreve como um modelo da LookML se relaciona com as estruturas de banco de dados na resposta do método de interface DatabaseMetaData.getTables
. A resposta inclui metadados JDBC padrão e metadados específicos do Looker:
getTables coluna de resposta |
Descrição |
---|---|
Metadados padrão do JDBC | |
TABLE_CAT |
(null) |
TABLE_SCHEM |
Nome do modelo do LookML |
TABLE_NAME |
Nome da análise detalhada do LookML |
TABLE_TYPE |
Sempre retorna o valor TABLE_TYPE |
REMARKS |
(null) |
TYPE_CAT |
(null) |
TYPE_SCHEM |
(null) |
TYPE_NAME |
String que representa o tipo de tabela. Os tipos possíveis são TABLE , VIEW , SYSTEM TABLE , GLOBAL TEMPORARY , LOCAL TEMPORARY , ALIAS , SYNONYM . |
SELF_REFERENCING_COL_NAME |
(null) |
REF_GENERATION |
(null) |
Metadados específicos do Looker | |
DESCRIPTION |
Confira a descrição |
LABEL |
Conheça o rótulo |
TAGS |
Conheça as tags |
CONDITIONALLY_FILTER_UNLESS |
A lista de campos no subparâmetro unless do parâmetro conditionally_filter da Análise detalhada. Se não houver campos especificados no subparâmetro unless ou se não houver um parâmetro conditionally_filter definido para a análise detalhada, esse valor será nulo. |
DatabaseMetadata.getColumns
A tabela a seguir descreve como um modelo da LookML se relaciona com as estruturas de banco de dados na resposta do método de interface DatabaseMetaData.getColumns
. A resposta inclui metadados JDBC padrão e metadados específicos do Looker:
getColumns coluna de resposta |
Descrição |
---|---|
Metadados padrão do JDBC | |
TABLE_CAT |
(null) |
TABLE_SCHEM |
Nome do modelo do LookML |
TABLE_NAME |
Nome da análise do LookML |
COLUMN_NAME |
Nome do campo LookML no formato `<view_name>.<field_name>` . Por exemplo, `orders.amount` . |
DATA_TYPE |
O código java.sql.Types da coluna. Por exemplo, os campos yesno do Looker são o código de tipo SQL 16 (BOOLEAN). |
TYPE_NAME |
String que representa o tipo de dados da coluna. Para um tipo definido pelo usuário (UDT), o nome do tipo é totalmente qualificado. |
COLUMN_SIZE |
Número inteiro que representa o número máximo de caracteres ou bytes que podem ser armazenados na coluna. |
BUFFER_LENGTH |
(null) |
DECIMAL_DIGITS |
Número inteiro que representa a escala dos dados: o número de dígitos à direita do decimal, para tipos de dados aplicáveis, ou o número de dígitos fracionários. Nulo é retornado para tipos de dados em que DECIMAL_DIGITS não é aplicável. |
NUM_PREC_RADIX |
Número inteiro que representa a base ou raiz (normalmente 10 ou 2) dos dados. |
NULLABLE |
Número inteiro que indica se valores nulos são permitidos:
|
REMARKS |
(null) |
COLUMN_DEF |
(null) |
SQL_DATA_TYPE |
(null) |
SQL_DATETIME_SUB |
(null) |
CHAR_OCTET_LENGTH |
Para tipos de dados de caracteres, um número inteiro que representa o número máximo de bytes na coluna. |
ORDINAL_POSITION |
O ordinal de base 1 do campo na Análise (misturando dimensões e medidas em ordem alfabética por nome da visualização e, em seguida, nome do campo) |
IS_NULLABLE |
Sempre retorna o valor YES |
SCOPE_CATALOG |
(null) |
SCOPE_SCHEMA |
(null) |
SCOPE_TABLE |
(null) |
SOURCE_DATA_TYPE |
(null) |
IS_AUTOINCREMENT |
(null) |
IS_GENERATEDCOLUMN |
YES para medidas, NO para dimensões |
Metadados específicos do Looker | |
DIMENSION_GROUP |
Nome do grupo de dimensões se o campo fizer parte de um grupo de dimensões. Se o campo não fizer parte de um grupo de dimensões, esse valor será nulo. |
DRILL_FIELDS |
Lista de campos de detalhamento definidos para a dimensão ou métrica, se houver |
FIELD_ALIAS |
Alias do campo, se houver |
FIELD_CATEGORY |
Se o campo é um dimension ou um measure |
FIELD_DESCRIPTION |
Campo description |
FIELD_GROUP_VARIANT |
Se o campo for apresentado em um rótulo do grupo, o FIELD_GROUP_VARIANT vai especificar o nome mais curto do campo que aparece no rótulo do grupo. |
FIELD_LABEL |
Campo label |
FIELD_NAME |
Nome da dimensão ou métrica |
LOOKER_TYPE |
Tipo de campo do LookML para a dimensão ou medida |
REQUIRES_REFRESH_ON_SORT |
Se a consulta SQL precisa ser atualizada para reordenar os valores do campo (TRUE ) ou se os valores do campo podem ser reordenados sem precisar de uma atualização da consulta SQL (FALSE ). |
SORTABLE |
Se o campo pode ser classificado (TRUE ) ou não (FALSE ) |
TAGS |
Campo tags |
USE_STRICT_VALUE_FORMAT |
Se o campo usa formato de valor estrito (TRUE ) ou não (FALSE ) |
VALUE_FORMAT |
String formato do valor para o campo |
VIEW_LABEL |
Conferir marcador do campo |
VIEW_NAME |
Nome da visualização em que o campo é definido no projeto do LookML |
HIDDEN |
Se o campo está oculto do seletor de campo nas Análises (TRUE ) ou se ele está visível no seletor de campo nas Análises (FALSE ). |
ALWAYS_FILTER |
O valor padrão do parâmetro always_filter definido no campo. Se o campo não fizer parte de um parâmetro always_filter , esse valor será nulo. |
CONDITIONALLY_FILTER |
O valor padrão do parâmetro conditionally_filter definido no campo. Se o campo não fizer parte de um parâmetro conditionally_filter , esse valor será nulo. |
Identificar consultas da interface Open SQL na interface do Looker
Os administradores do Looker podem usar a interface do Looker para identificar quais consultas foram originadas da interface Open SQL:
- Na página de administração Consultas, as consultas da interface SQL aberta têm um valor Origem de "Interface SQL". O valor Usuário mostra o nome do usuário do Looker que executou a consulta. Clique no botão Detalhes de uma consulta para acessar mais informações sobre ela. Na caixa de diálogo Detalhes, clique em Consulta da interface SQL para ver a consulta SQL enviada ao Looker pela interface SQL aberta.
Na Análise detalhada do histórico de atividades do sistema, as consultas da interface SQL aberta têm um valor Origem de "sql_interface". O valor E-mail do usuário mostra o endereço de e-mail do usuário do Looker que executou a consulta. Acesse diretamente a análise detalhada do Histórico filtrada em "sql_interface" inserindo o endereço da sua instância do Looker no início deste URL:
https://Looker instance URL/explore/system__activity/history?fields=history.source,history.completed_date&f[history.source]=%22sql_interface%22
Repositório para dependências de terceiros
O link a seguir dá acesso ao repositório hospedado pelo Google para dependências de terceiros usadas pelo driver JDBC do Looker:
https://third-party-mirror.googlesource.com/looker_sql_interface/+/refs/heads/master/third_party/