Apri interfaccia SQL

Il livello di modellazione semantica LookML di Looker consente a un analista di dati di definire dimensioni, aggregazioni, calcoli e relazioni tra i dati in un database SQL. I modelli LookML forniscono riusabilità del codice e integrazione Git. Un modello LookML ben strutturato consente agli utenti di eseguire autonomamente l'esplorazione e la generazione di report self-service.

Il modello LookML è la base di tutti i dati richiesti a Looker, indipendentemente dal fatto che la richiesta provenga dall'interfaccia Esplora di Looker nell'interfaccia utente di Looker, da una visualizzazione incorporata nel portale aziendale o in un'altra applicazione di terze parti oppure da un'applicazione personalizzata sviluppata con l'API Looker. L'interfaccia SQL aperta fornisce l'accesso ai modelli LookML a qualsiasi applicazione di terze parti che supporti Java Database Connectivity (JDBC). Le applicazioni possono connettersi a un modello LookML come se fosse un database, consentendo agli utenti di sfruttare tutto il lavoro svolto dagli analisti dei dati nel modello LookML, utilizzando gli strumenti con cui si trovano più a loro agio.

Come l'interfaccia SQL aperta mostra gli elementi del progetto LookML

Per capire in che modo l'interfaccia Open SQL mostra gli elementi di un progetto LookML, è importante comprendere la struttura dei progetti LookML.

Un progetto LookML è una raccolta di file che descrivono gli oggetti, le connessioni al database e gli elementi dell'interfaccia utente utilizzati per eseguire query SQL in Looker (per ulteriori informazioni, consulta Termini e concetti di LookML). I seguenti concetti del progetto LookML sono correlati all'interfaccia SQL aperta:

  • Un modello LookML specifica una connessione al database e una o più esplorazioni. L'interfaccia SQL aperta mostra i modelli come schemi di database.
  • Un'esplorazione è un raggruppamento logico di una o più viste e delle relazioni di unione tra queste viste. L'interfaccia SQL aperta mostra le esplorazioni come tabelle di database.
  • Una visualizzazione definisce una raccolta di campi (dimensioni e misure). Una vista si basa in genere su una tabella del database o su una tabella derivata. Le visualizzazioni possono contenere le colonne della tabella del database sottostante, nonché eventuali dimensioni o misure personalizzate che gli utenti finali potrebbero richiedere. L'interfaccia SQL aperta mostra la combinazione di un nome di visualizzazione e di un nome di campo come nome di colonna del database. Ad esempio, la dimensione id nella visualizzazione order_items viene visualizzata da Open SQL Interface come colonna del database denominata order_items.id.

Un'esplorazione di Looker può definire le relazioni di unione tra più viste. Poiché è possibile che una vista abbia un campo con lo stesso nome di un campo in un'altra vista, l'interfaccia SQL aperta include sia il nome della vista sia il nome del campo quando fa riferimento a una colonna. Pertanto, utilizza questo formato per fare riferimento a un nome di colonna quando invii query all'interfaccia Open SQL:

`<view_name>.<field_name>`

Ad esempio, se esiste un'esplorazione denominata order_items che unisce una visualizzazione chiamata customer a una visualizzazione chiamata product ed entrambe queste visualizzazioni hanno una dimensione id, i due campi id vengono chiamati rispettivamente `customer.id` e `product.id`. Per utilizzare il nome completo anche con il nome dell'esplorazione, fai riferimento ai due campi come `order_items`.`customer.id` e `order_items`.`product.id`. Per informazioni su dove inserire gli apici inversi quando fai riferimento agli identificatori di database, consulta la sezione Utilizzare gli apici inversi intorno agli identificatori di database.

Configurazione dell'interfaccia Open SQL

Per utilizzare l'interfaccia SQL aperta:

  1. Verifica che i requisiti siano soddisfatti.
  2. Scarica il file del driver JDBC dell'interfaccia Open SQL.

Le sezioni seguenti descrivono questi passaggi.

Requisiti

Per utilizzare l'interfaccia Open SQL sono necessari i seguenti componenti:

  • L'applicazione di terze parti che vuoi utilizzare (ad esempio Tableau, ThoughtSpot o un'applicazione personalizzata) deve essere in grado di connettersi alla tua istanza di Looker. L'interfaccia SQL aperta può essere utilizzata con le istanze Looker ospitate dal cliente, a condizione che l'istanza Looker sia collegata in rete in modo da consentire all'applicazione di terze parti di accedervi.
  • Un progetto LookML che utilizza i dati di una connessione Google BigQuery. Il progetto LookML deve avere un file model che specifica una connessione Google BigQuery nel parametro connection.
  • Un ruolo utente di Looker che include l'autorizzazione explore sul modello LookML a cui vuoi accedere con l'interfaccia SQL aperta.

Scarica il driver JDBC dell'interfaccia Open SQL

Il driver JDBC dell'interfaccia SQL aperta di Looker si chiama avatica-<release_number>-looker.jar. Scarica l'ultima versione da GitHub all'indirizzo https://github.com/looker-open-source/calcite-avatica/releases.

Il driver JDBC prevede il seguente formato dell'URL:

jdbc:looker:url=https://Looker instance URL

Ad esempio:

jdbc:looker:url=https://myInstance.cloud.looker.com

La classe del driver JDBC è:

org.apache.calcite.avatica.remote.looker.LookerDriver

Autenticazione nell'interfaccia Open SQL

L'interfaccia Open SQL supporta tre metodi di autenticazione:

OAuth

I client JDBC che supportano OAuth possono essere configurati per utilizzare il server OAuth di un'istanza di Looker. Segui i passaggi per configurare l'autenticazione OAuth:

  1. Utilizza l'estensione Explorer API per registrare il client JDBC OAuth con la tua istanza Looker in modo che possa riconoscere le richieste OAuth. Per istruzioni, consulta Registrazione di un'applicazione client OAuth.
  2. Accedi a Looker con OAuth per richiedere un token di accesso. Per un esempio, consulta la sezione Eseguire l'accesso dell'utente utilizzando OAuth.
  3. Utilizza un oggetto Properties per trasmettere le credenziali OAuth quando apri la connessione JDBC all'interfaccia Open SQL.

Di seguito è riportato un esempio che utilizza 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);

Generare un token di accesso utilizzando le chiavi API

Anziché utilizzare il flusso OAuth standard per generare un token di accesso, puoi seguire questi passaggi per utilizzare l'API Looker per generare un token di accesso che può essere passato al driver JDBC dell'interfaccia SQL aperta:

  1. Genera chiavi API per l'utente Looker come descritto nella pagina Impostazioni di amministrazione - Utenti.

  2. Utilizza l'endpoint API login per la tua istanza di Looker. La risposta include un token di accesso nel formato Authorization: token <access_token>. Di seguito è riportato un esempio del comando curl che puoi utilizzare per effettuare questa richiesta:

      curl -k -d "client_id=<client_id>&client_secret=<client_secret>" https://<looker_host>/login\

  3. Passa il valore <access_token> della risposta come token nell'oggetto Properties per passare le credenziali OAuth quando apri la connessione JDBC all'interfaccia Open SQL.

Chiavi API

Puoi anche utilizzare le chiavi API per l'autenticazione al posto di un nome utente e una password. Le chiavi API sono considerate meno sicure di OAuth e potrebbero essere disponibili solo durante l'anteprima dell'interfaccia Open SQL. Consulta Chiavi API per informazioni sulla creazione di chiavi API per la tua istanza di Looker.

Utilizza la parte ID client della chiave API di Looker come nome utente. Utilizza la parte Client Secret per la password.

Esecuzione di query con l'interfaccia SQL aperta

Tieni presente le seguenti linee guida quando esegui query con l'interfaccia SQL aperta:

Limitazioni di SQL

Tieni presente le seguenti limitazioni SQL quando invii query all'interfaccia Open SQL:

Utilizza gli apici inversi intorno agli identificatori di database

Quando invii query all'interfaccia SQL aperta, utilizza gli apici inversi per delimitare gli identificatori di schema, tabella e colonna. Ecco come specificare gli elementi del database utilizzando i backtick con i termini di Looker:

  • schema: `<model_name>`
  • tabella: `<explore_name>`

  • colonna: `<view_name>.<field_name>`

Ecco un esempio di formato dell'istruzione SELECT che utilizza questi elementi:

SELECT `view.field`
  FROM `model`.`explore`
  LIMIT 10;

Specificare le misure LookML con AGGREGATE()

Le tabelle di database in genere contengono solo dimensioni, ovvero dati che descrivono un singolo attributo di una riga della tabella. I progetti LookML, tuttavia, possono definire sia dimensioni che misure. Una misura è un'aggregazione di dati su più righe, ad esempio SUM, AVG, MIN o MAX. Sono supportati anche altri tipi di misure. Consulta la pagina Tipi di misure per l'elenco completo dei tipi di misure LookML supportati.

Con l'interfaccia SQL aperta, devi designare tutte le misure LookML incluse in una query racchiudendo la misura (inclusi i backtick) nella funzione speciale AGGREGATE(). Ad esempio, utilizzalo per specificare la misura Conteggio dalla visualizzazione Ordini:

AGGREGATE(`orders.count`)

Devi racchiudere le misure LookML nella funzione AGGREGATE() indipendentemente dal fatto che la misura si trovi in una clausola SELECT, HAVING o ORDER BY.

Se non sai se un campo è una misura LookML, puoi utilizzare il metodo DatabaseMetaData.getColumns per accedere ai metadati del progetto LookML. La colonna IS_GENERATEDCOLUMN indicherà YES per tutte le misure LookML e NO per le dimensioni LookML. Per saperne di più, consulta la sezione Accesso ai metadati del database.

Specificare i campi con solo filtri e i parametri con JSON_OBJECT

L'interfaccia SQL aperta supporta i parametri e i campi con solo filtri.

Quando esegui query con l'interfaccia SQL aperta, puoi applicare parametri e campi solo filtro alla query includendo una chiamata al costruttore JSON_OBJECT con il seguente formato:

JSON_OBJECT(
    '<view>.<parameter name>', '<parameter value>',
    '<view>.<filter name>', '<Looker filter expression>'
)

L'oggetto JSON può contenere zero o più coppie chiave-valore di filtri e zero o più coppie chiave-valore di parametri.

  • La chiave nel costruttore JSON_OBJECT deve essere il nome di un campo o parametro con solo filtri.
  • Per i campi solo con filtri, il valore di ogni chiave deve essere un'espressione di filtro stringa di Looker.
  • Per i parametri, il valore di ogni chiave deve essere un valore semplice definito nella definizione parameter.

Consulta le sezioni seguenti per esempi di utilizzo di parametri e campi solo con filtri con l'interfaccia SQL aperta.

Esempio di parametro

Come esempio di utilizzo di un parameter con l'interfaccia SQL aperta, se la visualizzazione customers avesse un parametro definito in Looker come segue:

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

Puoi inviare questa query all'interfaccia SQL aperta per applicare il valore parametro segment di medium_customers alla query:

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;

L'interfaccia SQL aperta trasmetterà questo valore parametro alla query in Looker e Looker applicherà il valore medium_customers a tutti i campi dell'esplorazione configurati per utilizzare il parametro segment. Per informazioni sul funzionamento dei parametri in Looker, consulta la documentazione parameter.

Esempio di campo solo con filtri

Puoi utilizzare un campo filter con l'interfaccia SQL aperta. Ad esempio, se una vista products aveva una dimensione e un campo solo con filtri definiti in Looker nel seguente modo:

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 ;;
    }

Puoi utilizzare il filtro brand_select con Open SQL Interface inviando una query come la seguente:

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;

L'interfaccia SQL aperta applicherà l'espressione di filtro delle stringhe di Looker %Santa Cruz% alla query in Looker. Per informazioni su come funzionano i campi solo con filtri in Looker, consulta la documentazione filter.

Fornisci valori always_filter o conditionally_filter in una clausola WHERE o HAVING

L'interfaccia SQL aperta può supportare un'esplorazione che contiene always_filter o conditionally_filter, ma non entrambi.

Se hai definito l'Explore LookML con always_filter o conditionally_filter, devi trasmettere i valori per i campi filtro nella query SQL all'interfaccia SQL aperta:

  • Se la definizione del filtro specifica una o più dimensioni, devi includere una clausola WHERE nella query SQL per ciascuna delle dimensioni del filtro.
  • Se la definizione del filtro specifica una o più misure, devi includere una clausola HAVING nella query SQL per ciascuna delle misure del filtro.

Ad esempio, esiste un modello faa in cui hai definito un'esplorazione LookML flights con un parametro always_filter che specifica le dimensioni country e aircraft_category e la misura count, come segue: 

explore: flights {
  view_name: flights
  always_filter: {
    filters: [country : "Peru" , aircraft_category : "Airplane", count : ">1"]
  }
}

Nella query all'interfaccia SQL aperta, devi utilizzare una clausola WHERE per passare i valori per le dimensioni del filtro e una clausola HAVING per passare un valore per il filtro della misura al tuo modello LookML, ad esempio:

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 non trasmetti i valori dei filtri per ciascuna delle dimensioni e delle metriche specificate nel parametro always_filter, la query restituirà un errore. Lo stesso vale per le dimensioni e le misure specificate in un parametro conditionally_filter, ad eccezione del fatto che puoi definire un parametro conditionally_filter con un parametro secondario unless, come segue:

explore: flights {
  view_name: flights
  conditionally_filter: {
    filters: [country : "Peru" , aircraft_category : "Airplane"]
    unless: [count]
  }
}

In questo caso, devi passare un valore di filtro per ciascuna delle dimensioni e delle misure specificate nel parametro secondario filters di conditionally_filter, a meno che tu non specifichi un filtro su un campo nel parametro secondario unless. Per informazioni dettagliate sull'utilizzo del parametro secondario unless, consulta la pagina della documentazione relativa a conditionally_filter.

Ad esempio, una delle seguenti query all'interfaccia SQL aperta sarebbe accettabile. La prima query fornisce i valori del filtro per i campi specificati nel parametro secondario filters, mentre la seconda query fornisce un valore del filtro per il campo specificato nel parametro secondario 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

Esempio

Ecco una query di esempio che utilizza sia dimensioni che misure. Questa query recupera le dimensioni Stato e Città dalla visualizzazione clienti e la metrica Importo totale dalla visualizzazione ordini. Entrambe le visualizzazioni sono unite in Esplora ordini nel modello e-commerce. Per le città con più di 10 ordini, questa risposta alla query mostra le prime 5 città in base all'importo dell'ordine:

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;

Accesso ai metadati del database

L'interfaccia Open SQL supporta un sottoinsieme dell'interfaccia DatabaseMetaData JDBC standard, che viene utilizzata per ottenere informazioni sul database sottostante. Puoi utilizzare i seguenti metodi dell'interfaccia DatabaseMetaData per ottenere informazioni sul tuo modello LookML:

L'interfaccia SQL restituisce risultati solo per i modelli, le esplorazioni e i campi a cui hai accesso.

DatabaseMetadata.getSchemas

La seguente tabella descrive la relazione tra un modello LookML e le strutture di database standard nella risposta del metodo di interfaccia DatabaseMetadata.getSchemas.

getSchemas colonna delle risposte Descrizione
TABLE_SCHEM Nome del modello LookML
TABLE_CATALOG (nullo)

DatabaseMetadata.getTables

La seguente tabella descrive la relazione tra un modello LookML e le strutture del database nella risposta del metodo di interfaccia DatabaseMetaData.getTables. La risposta include metadati JDBC standard e metadati specifici di Looker:

getTables colonna delle risposte Descrizione
Metadati standard JDBC
TABLE_CAT (nullo)
TABLE_SCHEM Nome del modello LookML
TABLE_NAME Nome dell'esplorazione LookML
TABLE_TYPE Restituisce sempre il valore TABLE_TYPE
REMARKS (nullo)
TYPE_CAT (nullo)
TYPE_SCHEM (nullo)
TYPE_NAME Stringa che rappresenta il tipo di tabella. I tipi possibili sono TABLE, VIEW, SYSTEM TABLE, GLOBAL TEMPORARY, LOCAL TEMPORARY, ALIAS, SYNONYM.
SELF_REFERENCING_COL_NAME (nullo)
REF_GENERATION (nullo)
Metadati specifici di Looker
DESCRIPTION Esplora la descrizione
LABEL Esplora l'etichetta
TAGS Esplorare i tag
CONDITIONALLY_FILTER_UNLESS L'elenco dei campi nel parametro secondario unless del parametro conditionally_filter di Esplora. Se non sono specificati campi nel parametro secondario unless o se non è definito alcun parametro conditionally_filter per l'esplorazione, questo valore è nullo.

DatabaseMetadata.getColumns

La seguente tabella descrive la relazione tra un modello LookML e le strutture del database nella risposta del metodo di interfaccia DatabaseMetaData.getColumns. La risposta include metadati JDBC standard e metadati specifici di Looker:

getColumns colonna delle risposte Descrizione
Metadati standard JDBC
TABLE_CAT (nullo)
TABLE_SCHEM Nome del modello LookML
TABLE_NAME Nome dell'esplorazione LookML
COLUMN_NAME Nome del campo LookML nel formato `<view_name>.<field_name>`. Ad esempio, `orders.amount`.
DATA_TYPE Il codice java.sql.Types della colonna. Ad esempio, i campi yesno di Looker sono di tipo SQL 16 (BOOLEAN).
TYPE_NAME Stringa che rappresenta il tipo di dati della colonna. Per un tipo definito dall'utente (UDT), il nome del tipo è completo.
COLUMN_SIZE Numero intero che rappresenta il numero massimo di caratteri o byte che possono essere memorizzati nella colonna.
BUFFER_LENGTH (nullo)
DECIMAL_DIGITS Numero intero che rappresenta la scala dei dati: il numero di cifre a destra della virgola decimale, per i tipi di dati applicabili, o il numero di cifre frazionarie. Viene restituito il valore Null per i tipi di dati in cui DECIMAL_DIGITS non è applicabile.
NUM_PREC_RADIX Numero intero che rappresenta la base o la radice (in genere 10 o 2) per i dati.
NULLABLE

Numero intero che indica se sono consentiti valori null:

  • 0: columnNoNulls - potrebbe non consentire valori NULL
  • 1: columnNullable - consente sicuramente valori NULL
  • 2: columnNullableUnknown - nullabilità sconosciuta
REMARKS (nullo)
COLUMN_DEF (nullo)
SQL_DATA_TYPE (nullo)
SQL_DATETIME_SUB (nullo)
CHAR_OCTET_LENGTH Per i tipi di dati carattere, un numero intero che rappresenta il numero massimo di byte nella colonna.
ORDINAL_POSITION Il numero ordinale basato su 1 del campo all'interno dell'esplorazione (combinando dimensioni e misure in ordine alfabetico in base al nome della visualizzazione, poi al nome del campo)
IS_NULLABLE Restituisce sempre il valore YES
SCOPE_CATALOG (nullo)
SCOPE_SCHEMA (nullo)
SCOPE_TABLE (nullo)
SOURCE_DATA_TYPE (nullo)
IS_AUTOINCREMENT (nullo)
IS_GENERATEDCOLUMN YES per le misure, NO per le dimensioni
Metadati specifici di Looker
DIMENSION_GROUP Nome del gruppo di dimensioni se il campo fa parte di un gruppo di dimensioni. Se il campo non fa parte di un gruppo di dimensioni, questo valore è null.
DRILL_FIELDS Elenco dei campi di visualizzazione in dettaglio impostati per la dimensione o la misura, se presenti
FIELD_ALIAS Alias per il campo, se presente
FIELD_CATEGORY Se il campo è un dimension o un measure
FIELD_DESCRIPTION Campo description
FIELD_GROUP_VARIANT Se il campo viene visualizzato sotto un'etichetta di gruppo, FIELD_GROUP_VARIANT specifica il nome più breve del campo visualizzato sotto l'etichetta di gruppo.
FIELD_LABEL Etichetta del campo label
FIELD_NAME Nome della dimensione o della misura
LOOKER_TYPE Tipo di campo LookML per la dimensione o la misura
REQUIRES_REFRESH_ON_SORT Indica se la query SQL deve essere aggiornata per riordinare i valori del campo (TRUE) o se i valori del campo possono essere riordinati senza richiedere un aggiornamento della query SQL (FALSE).
SORTABLE Indica se il campo può essere ordinato (TRUE) o meno (FALSE).
TAGS Campo tag
USE_STRICT_VALUE_FORMAT Indica se il campo utilizza il formato valori rigoroso (TRUE) o meno (FALSE).
VALUE_FORMAT Stringa Formato valore per il campo
VIEW_LABEL Visualizza etichetta per il campo
VIEW_NAME Nome della visualizzazione in cui il campo è definito nel progetto LookML
HIDDEN Se il campo è nascosto nel selettore campi delle esplorazioni (TRUE) o se è visibile nel selettore campi delle esplorazioni (FALSE).
ALWAYS_FILTER Il valore predefinito del parametro always_filter impostato nel campo. Se il campo non fa parte di un parametro always_filter, questo valore è null.
CONDITIONALLY_FILTER Il valore predefinito del parametro conditionally_filter impostato nel campo. Se il campo non fa parte di un parametro conditionally_filter, questo valore è null.

Identificazione delle query dell'interfaccia SQL aperta nella UI di Looker

Gli amministratori di Looker possono utilizzare l'interfaccia utente di Looker per identificare le query originate dall'interfaccia SQL aperta:

  • Nella pagina di amministrazione Query, le query dell'interfaccia SQL aperta hanno un valore Origine pari a "Interfaccia SQL". Il valore Utente mostrerà il nome dell'utente Looker che ha eseguito la query. Puoi fare clic sul pulsante Dettagli per una query per visualizzare ulteriori informazioni. Nella finestra di dialogo Dettagli, puoi fare clic su Query dell'interfaccia SQL per visualizzare la query SQL inviata a Looker dall'interfaccia SQL aperta.

  • Nell'esplorazione della cronologia attività di sistema, le query dell'interfaccia SQL aperta hanno un valore Origine pari a "sql_interface". Il valore Email utente mostrerà l'indirizzo email dell'utente Looker che ha eseguito la query. Puoi andare direttamente alla sezione Cronologia di Esplora filtrata su "sql_interface" inserendo l'indirizzo dell'istanza di Looker all'inizio di questo URL:

    https://Looker instance URL/explore/system__activity/history?fields=history.source,history.completed_date&f[history.source]=%22sql_interface%22

Repository per le dipendenze di terze parti

Il seguente link fornisce l'accesso al repository ospitato da Google per le dipendenze di terze parti utilizzate dal driver JDBC di Looker:

https://third-party-mirror.googlesource.com/looker_sql_interface/+/refs/heads/master/third_party/