Dopo aver protetto e configurato il database, puoi connetterlo a Looker.
Creazione di una nuova connessione al database
Seleziona Connessioni nella sezione Database del riquadro Amministrazione. Nella pagina Connections (Connessioni), fai clic sul pulsante Add Connection (Aggiungi connessione). Looker visualizza la pagina Connection Settings (Impostazioni connessione).
Per ulteriori informazioni sull'applicazione degli attributi utente alle impostazioni di connessione, consulta la sezione Connessioni della pagina della documentazione Attributi utente.
Questa pagina descrive i campi comuni che Looker visualizza nella pagina Connection Settings (Impostazioni connessione). I campi esatti che viene visualizzata nella pagina Impostazioni di connessione dipendono dall'impostazione del dialetto.
Fai clic qui per visualizzare i link alle istruzioni specifiche per il dialetto nella documentazione di Looker.
- Actian Avalanche
- AlloyDB per PostgreSQL
- Amazon Aurora PostgreSQL
- Amazon Athena
- Amazon Aurora MySQL
- Amazon RDS per MySQL
- Amazon RDS per PostgreSQL
- Amazon Redshift
- Apache Druid
- Hive
- Stimolante Apache
- ClickHouse
- Cloudera Impala
- Clustrix
- Databricks
- DataVirtuality
- Denodo
- Dremio
- Exasol
- Firebolt
- SQL precedente di Google BigQuery
- SQL standard di Google BigQuery
- Cloud SQL per PostgreSQL
- Google Cloud SQL
- Google Cloud Spanner
- Greenplum
- IBM DB2 su AS400
- IBM DB2 su LUW
- MariaDB
- Microsoft Azure Synapse Analytics
- Database SQL di Microsoft Azure
- Microsoft Azure PostgreSQL
- Microsoft SQL Server (MSSQL)
- Connettore MongoDB per BI
- MySQL
- Oracle
- Oracle ADWC
- PostgreSQL
- PrestoDB
- Qubole Presto
- Quantile Qubole
- SAP HANA
- SingleStore (in precedenza MemSQL)
- Snowflake
- Teradata
- Trino
- Vector
- Vertica
Nome
Il nome della connessione a cui vuoi fare riferimento. Non utilizzare il nome di nessuna cartella. Questo valore non deve corrispondere necessariamente ai contenuti del database, è solo un'etichetta assegnata da te. Lo utilizzerai nel parametro connection
del tuo modello LookML.
Dialetto
Il dialetto SQL corrispondente alla tua connessione. È importante scegliere il valore corretto, in modo da visualizzare le opzioni di connessione appropriate e consentire a Looker di convertire correttamente il codice LookML in codice SQL.
ID progetto di fatturazione
Solo per le connessioni a Google BigQuery, l'ID progetto di fatturazione è l'ID progetto Google Cloud.
Server SSH
L'opzione SSH Server (Server SSH) è disponibile solo se è stato eseguito il deployment dell'istanza nell'infrastruttura Kubernetes e solo se è stata concessa la possibilità di aggiungere informazioni di configurazione del server SSH alla tua istanza di Looker. Se questa opzione non è abilitata per la tua istanza di Looker e vuoi abilitarla, contatta un esperto delle vendite di Google Cloud o apri una richiesta di assistenza.
Il server SSH sceglie automaticamente la porta localhost e non è possibile specificare la porta localhost. Se devi creare una connessione SSH che richiede la specifica una porta localhost, apri una richiesta di assistenza.
Per connetterti al tuo database utilizzando un tunnel SSH, attiva il pulsante di attivazione/disattivazione e seleziona una configurazione server SSH dall'elenco a discesa.
Porta locale
Per impostazione predefinita, Looker seleziona automaticamente una porta locale disponibile per il tunnel SSH. Per scegliere manualmente una porta locale, seleziona Inserimento manuale e inserisci un numero di porta nel campo Porta locale personalizzata. Assicurati che la porta locale sia disponibile sulla tua istanza.
Host remoto:Porta
Il nome host del tuo database e la porta che deve essere utilizzata da Looker per la connessione all'host del tuo database.
Se hai lavorato con un analista Looker per configurare un tunnel SSH al tuo database, nel campo Host inserisci "localhost"
, mentre nel campo Porta inserisci il numero di porta che reindirizza al tuo database, che l'analista Looker dovrebbe aver fornito.
Database
Il nome del database sul tuo host. Ad esempio, potresti avere un nome host di my-instance.us-east-1.redshift.amazonaws.com
su un database di nome sales_info
. In tal caso, inserisci sales_info
in questo campo. Se hai più database sullo stesso host, potrebbe essere necessario creare più connessioni per utilizzarli (tranne che per MySQL, in cui il termine database ha un significato un po' diverso dalla maggior parte dei dialetti SQL).
Utilizza OAuth
Per le connessioni a Snowflake e Google BigQuery, puoi scegliere di utilizzare OAuth. Di conseguenza i tuoi utenti devono accedere, rispettivamente, a Snowflake o Google, per eseguire query da Looker.
Quando selezioni Utilizza OAuth, vengono visualizzati i campi ID client OAuth e Secret client OAuth.
Questi valori vengono generati dal database Snowflake o da Google. Per la procedura completa, consulta la pagina della documentazione che descrive la configurazione di Snowflake OAuth o la configurazione di Google BigQuery OAuth.
Nome utente
Il nome utente che deve essere utilizzato da Looker per la connessione al tuo database. L'utente deve essere configurato preventivamente, attenendosi alle istruzioni per la configurazione del database.
Password
La password che Looker deve utilizzare per connettersi al tuo database. La password deve essere configurata preventivamente, attenendosi alle istruzioni per la configurazione del database.
Email account di servizio
L'indirizzo email dell'account di servizio utilizzato per accedere al tuo database. L'account di servizio viene amministrato tramite il database. Per informazioni su come connetterti a BigQuery con un account di servizio, consulta la documentazione di Looker relativa a Google BigQuery.
File JSON/P12 dell'account di servizio
Il file del certificato per l'account di servizio. Scarica questo file dal tuo database. Per informazioni su come connetterti a BigQuery con un account di servizio, consulta la documentazione di Looker relativa a Google BigQuery.
Schema
Lo schema predefinito utilizzato da Looker quando non è specificato alcuno schema. Questo vale quando utilizzi SQL Runner, durante la generazione di progetti LookML e quando esegui query su tabelle.
Tabelle derivate permanenti
Seleziona questa casella per abilitare le tabelle derivate permanenti. Vengono visualizzati ulteriori campi PDT e la colonna PDT Overrides (Override PDT). Looker visualizza questa opzione solo se il dialetto del database supporta l'uso di PDT.
Tieni presente quanto segue sulle PDT:
- Le PDT non sono supportate per le connessioni a Snowflake che utilizzano OAuth.
- La disabilitazione delle PDT su una connessione non disattiva i gruppi di dati associati alle tue PDT. Anche se disabiliti le PDT, i gruppi di dati esistenti continuano a eseguire le proprie query
sql_trigger
sul database. Se vuoi impedire a un gruppo di dati di eseguire la querysql_trigger
sul tuo database, devi eliminare o commentare il parametrodatagroup
dal tuo progetto LookML oppure puoi aggiornare l'impostazione PDT and Datagroup Maintenance Schedule (Pianificazione manutenzione PDT e gruppi di dati) per la connessione in modo che Looker controlli le PDT e i gruppi di dati molto raramente o mai. - Per le connessioni Snowflake, Looker imposta il valore del parametro
AUTOCOMMIT
suTRUE
(valore predefinito di Snowflake).AUTOCOMMIT
è necessario per i comandi SQL eseguiti da Looker per mantenere il proprio sistema di registrazione delle PDT.
Database temporaneo
Anche se questo campo è denominato Temp Database (Database temporaneo), devi inserire il nome del database o dello schema, in base al tuo dialetto SQL, che deve essere utilizzato da Looker per creare le tabelle derivate permanenti. Il database o lo schema deve essere configurato preventivamente, con le autorizzazioni di scrittura adeguate. Nella pagina della documentazione Istruzioni di configurazione del database, seleziona il dialetto del tuo database per le istruzioni di configurazione.
Ogni connessione deve avere il proprio database temporaneo o schema; non possono essere condivise tra più connessioni.
Numero massimo di connessioni del generatore di PDT
L'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT) permette di specificare il numero delle operazioni di creazione di tabelle che possono essere avviate contemporaneamente dal rigeneratore Looker sulla connessione al tuo database. L'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT) si applica solo ai tipi di tabelle per cui il rigeneratore Looker avvia la ricostruzione,
- Tabelle persistenti per trigger (tabelle derivate persistenti e tabelle aggregate che utilizzano la strategia di persistenza
datagroup_trigger
osql_trigger_value
). - Tabelle persistenti che utilizzano la strategia
persist_for
, ma solo quando la tabellapersist_for
fa parte di una cascata di tabelle derivate da cui dipende da una tabella che utilizza la strategia di persistenzadatagroup_trigger
osql_trigger_value
. In questo caso, il rigeneratore Looker ricostruisce una tabellapersist_for
, poiché è necessaria per la ricostruzione di un'altra tabella nella cascata. In caso contrario, il rigeneratore non avvia alcuna operazione di creazione per le tabellepersist_for
.
L'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT) è 1, ma può essere impostata su un valore pari a 10. Tuttavia, il valore non può essere maggiore di quello impostato nel campo Max Connections (Numero massimo di connessioni) o in per-user-query-limit
impostato nelle opzioni di avvio di Looker.
Imposta questo valore con attenzione. Un valore troppo elevato può sovraccaricare il database. Se il valore è troppo basso, le PDT a esecuzione prolungata o le tabelle aggregate possono ritardare la creazione di altre tabelle permanenti o rallentare le altre query sulla connessione. I database che supportano la multitenancy, come BigQuery, Snowflake e Redshift, possono gestire più efficacemente la generazione delle query parallele.
Se vuoi aumentare il valore dell'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT), come regola generale è consigliabile procedere per incrementi di 1. Se si verifica un comportamento imprevisto, ripristina il valore predefinito 1. Se invece le prestazioni delle query non ne risentono, puoi continuare a incrementare il valore di 1 e a verificare le prestazioni dopo ogni incremento, prima di aumentare ulteriormente l'impostazione.
Tieni presente le seguenti informazioni sull'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT):
- L'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT) si applica solo alle connessioni necessarie per la ricostruzione delle tabelle, non a quelle necessarie per i controlli trigger. Un controllo trigger è una query che verifica se la strategia di permanenza della tabella è stata attivata. Poiché tali query vengono sempre eseguite in sequenza, l'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT) non viene applicata.
- In un'istanza Looker in cluster, il rigeneratore viene eseguito solo sul nodo principale. L'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT) viene applicata solamente al nodo principale, pertanto imposta il limite per l'intero cluster.
- L'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT) non si applica ai tipi di tabelle seguenti. Questi tipi di tabelle vengono creati in sequenza:
- Tabelle persistenti tramite il parametro
persist_for
(a meno che la tabella non sia basata sulle tabelle che utilizzano le strategiedatagroup_trigger
osql_trigger_value
). - Tabelle in modalità Development (Sviluppo).
- Tabelle ricostruite con l'opzione Rebuild Derived Tables & Run.
- Tabelle in cui una dipende dall'altra in una cascata di dipendenza. Non è possibile creare una tabella contemporaneamente alla tabella da cui dipende. Ad esempio, se
table_B
dipende datable_A
,table_A
deve completare la ricostruzione prima chetable_B
possa iniziare a ricostruire.
- Tabelle persistenti tramite il parametro
Riprova sempre le operazioni di creazione di PDT non riuscite
L'impostazione Always Retry Failed PDT Builds (Ritenta sempre le ricostruzioni PDT non riuscite) configura il modo in cui il rigeneratore Looker tenta di ricostruire le tabelle permanenti trigger non riuscite nel ciclo di rigenerazione precedente. Il rigeneratore Looker è il processo che ricostruisce le tabelle permanenti (PDT e tabelle aggregate) in base all'intervallo configurato nell'impostazione di connessione PDT and Datagroup Maintenance Schedule (Pianificazione manutenzione PDT e gruppi di dati). Quando l'impostazione Always Retry Failed PDT Builds (Ritenta sempre le ricostruzioni PDT non riuscite) è abilitata, il rigeneratore Looker tenta di ricostruire le PDT non riuscite nel ciclo precedente del rigeneratore, anche se la relativa condizione trigger non è soddisfatta. Se viene disattivata, il rigeneratore Looker tenta di ricostruire le PDT non riuscite nel ciclo precedente solo se la relativa condizione trigger è soddisfatta. L'impostazione Always Retry Failed PDT Builds (Ritenta sempre le ricostruzioni PDT non riuscite) è disabilitata per impostazione predefinita.
Per ulteriori informazioni sul rigeneratore Looker, consulta la pagina della documentazione sulle tabelle derivate in Looker.
Abilita controllo API PDT
L'impostazione Abilita controllo API PDT determina se le chiamate API start_pdt_build
, check_pdt_build
e stop_pdt_build
possono essere utilizzate per questa connessione. Se viene disattivata, queste chiamate API non vanno a buon fine quando fanno riferimento a PDT su questa connessione. L'opzione Abilita controllo API PDT è disabilitata per impostazione predefinita.
Parametri aggiuntivi
Se necessario, qui puoi aggiungere ulteriori parametri JDBC (Java Database Connectivity) per le tue query.
Per fare riferimento a un attributo utente in un parametro JDBC, utilizza la sintassi di linguaggio Liquid: _user_attributes['name_of_attribute']
. Ecco alcuni esempi:
my_jdbc_param={{ _user_attributes['name_of_attribute'] }}
Pianificazione della manutenzione di PDT e gruppi di dati
Questa impostazione accetta un'espressione cron
che indica quando il rigeneratore Looker deve controllare i gruppi di dati e le tabelle permanenti (sia tabelle aggregate che tabelle derivate permanenti) basate su sql_trigger_value
. In base a questi controlli, il rigeneratore Looker ricostruisce o elimina le tabelle permanenti dallo schema temporaneo del database.
Il valore PDT and Datagroup Maintenance Schedule (Pianificazione manutenzione PDT e gruppi di dati) imposta l'intervallo cron
per il rigeneratore Looker. Il rigeneratore Looker avvia un ciclo rigeneratore per controllare i gruppi di dati e le tabelle permanenti nell'intervallo cron
. Se un ciclo del rigeneratore Looker è ancora in corso all'intervallo cron
successivo, verrà completato il ciclo del rigeneratore Looker in corso, quindi attenderà l'intervallo cron
successivo per iniziare il ciclo rigeneratore successivo.
L'impostazione Pianificazione della manutenzione di PDT e gruppi di dati accetta un'espressione cron
. Il valore predefinito è */5 * * * *
, il che significa che il ciclo del rigeneratore Looker avvia un ciclo ogni 5 minuti, se il ciclo del rigeneratore precedente è stato completato. Se il ciclo del rigeneratore precedente non è stato completato, il rigeneratore Looker si avvierà a intervalli di cinque minuti successivi al termine del relativo ciclo.
L'impostazione predefinita di cinque minuti è anche l'intervallo più frequente supportato per la pianificazione della manutenzione di PDT e gruppi di dati. Looker non applica un intervallo massimo per la pianificazione di manutenzione di PDT e di gruppi di dati, il che significa che puoi estendere l'intervallo tra i cicli di rigeneratore Looker finché è specificato da un'espressione cron
. Tieni presente che cicli di rigenerazione Looker più lunghi possono influire negativamente sull'aggiornamento dei dati nella cache e nelle tabelle persistenti.
Una volta completati tutti i controlli e le ricostruzioni PDT in un ciclo, il rigeneratore Looker attende il successivo intervallo cron
per avviare il ciclo successivo. Se disponi di build PDT a lunga esecuzione, tra periodi di rigenerazione Looker potrebbero esistere periodi lunghi. Altri fattori possono influire sul tempo necessario per ricreare le tabelle, come descritto nella sezione Considerazioni importanti per l'implementazione delle tabelle permanenti nella pagina Tabelle derivate in Looker.
Se il tuo database non è in funzione 24 ore su 24, 7 giorni su 7, puoi limitare i controlli ai soli orari in cui è attivo. Di seguito sono riportate alcune espressioni cron
aggiuntive:
Espressione cron |
Definizione |
---|---|
*/5 8-17 * * MON-FRI |
Controlla i gruppi di dati e le PDT ogni 5 minuti durante l'orario di lavoro, dal lunedì al venerdì |
*/5 8-17 * * * |
Controlla i gruppi di dati e le PDT ogni 5 minuti, tutti i giorni durante l'orario di apertura |
0 8-17 * * MON-FRI |
Controlla i gruppi di dati e le PDT ogni ora, dal lunedì al venerdì durante l'orario lavorativo |
1 3 * * * |
Controlla i gruppi di dati e le PDT ogni giorno alle 03:01 |
Quando crei un'espressione cron
, tieni presente quanto segue:
- Looker utilizza parse-cron v0.1.3, che non supporta
?
nelle espressioni dicron
. - L'espressione
cron
utilizza il fuso orario dell'applicazione Looker per determinare quando vengono effettuati i controlli. - Se le PDT non vengono create, ripristina il valore predefinito
*/5 * * * *
per la stringa cron.
Di seguito sono riportate alcune risorse utili per la creazione delle stringhe cron
:
- https://crontab.guru: guida alla modifica e al test delle stringhe
cron
. - http://www.crontab-generator.org: seleziona le impostazioni dell'ora e il generatore crea la stringa
cron
corrispondente.
SSL
Scegli se utilizzare o meno la crittografia SSL per proteggere i dati scambiati fra Looker e il tuo database. SSL è solo una delle opzioni disponibili per proteggere i tuoi dati. Le altre opzioni di sicurezza sono illustrate nella pagina della documentazione relativa all'attivazione dell'accesso sicuro ai database.
Verifica certificato SSL
Scegli se richiedere la verifica del certificato SSL utilizzato dalla connessione. Se è richiesta la verifica, l'autorità di certificazione (CA) SSL che ha firmato il certificato SSL deve essere inclusa nell'elenco delle origini attendibili del client. Se la CA non è un'origine attendibile, la connessione al database non viene stabilita.
Se questa casella non è selezionata, la crittografia SSL viene comunque utilizzata per la connessione, ma non viene richiesta la verifica della connessione SSL, che può quindi essere stabilita anche se la CA non è inclusa nell'elenco delle origini attendibili del client.
Numero massimo di connessioni
Qui puoi impostare il numero massimo di connessioni che Looker può stabilire con il tuo database. Nella maggior parte dei casi, si tratta del numero di query simultanee eseguibili da Looker sul database in questione. Looker riserva inoltre fino a un massimo di tre connessioni per l'interruzione delle query. Se il pool di connessioni è molto piccolo, Looker prenoterà meno connessioni.
Imposta questo valore con attenzione. Se il valore è troppo alto, il database potrebbe sovraccaricare. Se il valore è troppo basso, le query devono condividere un numero limitato di connessioni. Di conseguenza, molte query possono apparire lente agli utenti perché devono attendere la fine di quelle precedenti.
Il valore predefinito (che varia a seconda del dialetto SQL) è solitamente un punto di partenza ragionevole. La maggior parte dei database prevede anche una propria impostazione per il numero massimo di connessioni accettate. Se la configurazione del tuo database limita le connessioni, assicurati che il valore di Max Connections (Numero massimo di connessioni) sia uguale o inferiore al limite del database.
Timeout del pool di connessioni
Se gli utenti richiedono più connessioni rispetto all'impostazione Max Connections (Numero massimo di connessioni), le richieste in eccesso possono essere eseguite solo quando terminano quelle precedenti. Questa impostazione specifica il tempo massimo di attesa delle richieste. Questo valore deve essere impostato con attenzione. Se è troppo basso, le query di alcuni utenti rischiano di essere annullate perché il tempo disponibile non è sufficiente per completare le query di altri utenti. Se è troppo elevato, le numerose query rischiano di accumularsi costringendo gli utenti ad attendere molto tempo. Il valore predefinito è solitamente un punto di partenza ragionevole.
Stima dei costi
La casella di controllo Stima dei costi si applica solo alle seguenti connessioni al database:
- Snowflake
- Amazon Redshift
- Aurora amazzonica
- PostgreSQL, Cloud SQL per PostgreSQL e Microsoft Azure PostgreSQL
La casella di controllo Stima dei costi attiva le seguenti funzionalità per la connessione:
- Stime dei costi per le query di esplorazione
- Stime dei costi per le query SQL Runner
- Stime di calcolo per le query di awareness aggregate
Per ulteriori informazioni, consulta la pagina Esplorazione dei dati in Looker della documentazione.
Pre-memorizzazione nella cache di SQL Runner
In SQL Runner, tutte le informazioni relative alle tabelle vengono precaricate appena selezioni una connessione e uno schema. Questo permette a SQL Runner di visualizzare rapidamente le colonne di una tabella appena fai clic sul suo nome. Tuttavia, per le connessioni e gli schemi associati a tabelle numerose o molto grandi non è consigliabile precaricare tutte le informazioni richieste da SQL Runner.
Se preferisci che SQL Runner carichi le informazioni sulle singole tabelle solo quando vengono selezionate, puoi deselezionare l'opzione SQL Runner Precache (Pre-cache SQL Runner) per disabilitare il precaricamento per la connessione.
Recupera lo schema di informazioni per la scrittura SQL
Per alcune funzionalità di scrittura SQL, come l'awareness aggregata, Looker utilizza lo schema di informazioni del database per ottimizzare la scrittura SQL. Se lo schema di informazioni non viene memorizzato nella cache, di tanto in tanto Looker potrebbe avere l'esigenza di bloccare la scrittura del codice SQL nel database al fine di recuperare lo schema di informazioni. Per i dialetti che utilizzano HDFS (Hadoop Distributed File System), il tempo necessario per recuperare lo schema di informazioni può influire notevolmente sulle prestazioni delle query di Looker. Se sai che il tuo schema di informazioni è lento, puoi disabilitare l'opzione Ottieni lo schema di informazioni per la scrittura SQL per la tua connessione. La disattivazione di questa funzionalità impedisce in parte l'ottimizzazione SQL di Looker per determinate caratteristiche, quindi è necessario abilitare l'opzione Ottieni lo schema di informazioni per la scrittura SQL, a meno che lo schema di informazioni della tua connessione non sia particolarmente lento.
Disattiva commento contestuale
L'opzione Disabilita commento contestuale si applica solo alle connessioni BigQuery. I commenti di contesto sulle connessioni a Google BigQuery sono disattivati per impostazione predefinita perché i commenti contestuali non consentono a Google BigQuery di utilizzare la cache e influiscono negativamente sulle prestazioni di quest'ultima. Puoi abilitare i commenti contestuali per una connessione BigQuery deselezionando l'impostazione Disabilita contesto commento nella pagina Impostazioni di connessione per la connessione. Per ulteriori informazioni, consulta la pagina della documentazione di Google BigQuery.
Fuso orario database
Il fuso orario utilizzato dal database per memorizzare le informazioni basate sul tempo. Looker utilizza queste impostazioni al fine di convertire i valori di data/ora per gli utenti, semplificando la comprensione e l'utilizzo dei dati basati sul tempo. Per ulteriori informazioni, consulta la pagina Documentazione relativa alle impostazioni del fuso orario.
Fuso orario query
L'opzione Fuso orario query è visibile solo se hai disattivato i fusi orari specifici degli utenti.
Quando Fusi orari specifici degli utenti è disabilitato, il fuso orario delle query è il fuso orario che viene mostrato agli utenti quando eseguono query su dati basati sul tempo e il fuso orario in cui Looker converte i dati basati sul tempo dal fuso orario del database.
Per ulteriori informazioni, consulta la pagina Documentazione relativa alle impostazioni del fuso orario.
Configurazione di credenziali di accesso separate per i processi PDT
Se il tuo database supporta le tabelle derivate permanenti e hai selezionato la casella Persistent Derived Tables (Tabelle derivate permanenti) nelle impostazioni di connessione, Looker mostra la sezione PDT Overrides (Override PDT). Nella sezione PDT Overrides (Override PDT), puoi inserire parametri JDBC separati (host, porta, database, nome utente, password, schema e parametri aggiuntivi) specifici dei processi PDT. Questo può essere utile per diversi motivi:
- Creando un utente di database separato per i processi PDT, puoi utilizzare le PDT nel tuo progetto Looker anche se assegni gli attributi utente alle credenziali di accesso al database oppure utilizzi OAuth per la connessione al database.
- I processi PDT possono autenticarsi mediante un utente dedicato del database, dotato di una priorità superiore. In questo modo, il database può privilegiare i job PDT rispetto alle query utente meno critiche.
- L'accesso in scrittura può essere revocato per la connessione al database Looker standard e concesso solo a un utente speciale che i processi PDT utilizzeranno per l'autenticazione. Si tratta di una strategia di sicurezza più efficace per la maggior parte delle organizzazioni.
- Per database come Snowflake, i processi PDT possono essere instradati verso componenti hardware più potenti, che non vengono condivisi con gli altri utenti di Looker. In questo modo, le PDT vengono create più rapidamente, senza dover sostenere i costi dell'esecuzione a tempo pieno di risorse hardware più costose.
Ad esempio, puoi configurare una connessione e impostare i campi nome utente e password su attributi utente. In questo modo, ogni utente può accedere al database utilizzando le proprie credenziali individuali. La sezione Override PDT crea un utente separato (pdt_user
) con la sua password. L'account pdt_user
verrà utilizzato per tutti i processi PDT, con livelli di accesso adeguati alla creazione e all'aggiornamento delle PDT.
Test delle impostazioni di connessione
Una volta inserite le credenziali, fai clic su Test These Settings (Prova queste impostazioni) per verificare che le informazioni siano corrette e che sia possibile stabilire la connessione al database.
Se la connessione non supera uno o più test:
- Prova alcuni dei passaggi per la risoluzione dei problemi illustrati nella pagina della documentazione Testare la connettività dei database.
- Se utilizzi Mongo versione 3.6 o precedente su Atlas e ricevi un errore del collegamento di comunicazione, consulta la pagina della documentazione relativa al connettore Mongo.
- Per ricevere un messaggio di connessione riuscita per le PDT e lo schema temp, devi abilitare questa funzionalità durante la configurazione del database Looker. Per sapere come eseguire questa operazione, consulta la pagina della documentazione delle istruzioni per la configurazione del database.
Se i problemi persistono, contatta l'assistenza Looker.
Verifica come utente
Se hai impostato uno o più valori dei parametri di connessione a un attributo utente, sopra il pulsante Prova queste impostazioni verrà visualizzata l'opzione Testa come utente. Seleziona un utente e fai clic su Test These Settings (Prova queste impostazioni) per verificare che il database sia in grado di connettersi ed eseguire query in qualità di utente.
Aggiunta della connessione al database
Dopo aver configurato e testato le impostazioni di connessione del database, fai clic su Aggiungi connessione. La connessione al tuo database viene aggiunta all'elenco della pagina Connections (Connessioni).
Passaggi successivi
Dopo aver connesso il database a Looker, puoi configurare le opzioni di accesso per i tuoi utenti.