Comprendere il ciclo di vita delle query

Si esaminerà ora il modo in cui Il catalogo unity gestisce l'esecuzione delle query, con particolare attenzione ai controlli di sicurezza e amministrativi. Verrà illustrato dettagliatamente cosa accade quando una query viene inviata su una tabella del catalogo Unity, che copre le interazioni tra calcolo, piano di controllo, piano dati e archiviazione cloud.

Ciclo di vita delle query nel catalogo unity

Il diagramma seguente illustra il flusso complessivo di una query durante lo spostamento tra componenti diversi in Unity Catalog.

Passaggio 1: Invio di query

Il ciclo di vita inizia quando un'entità (un utente o un'identità del servizio) esegue una query. Le query possono avere origine in modi diversi:

• Un data scientist può usare un cluster all-purpose per carichi di lavoro Python o SQL interattivi.
• Un Principal di Servizio potrebbe eseguire una pipeline o un processo pianificato in un cluster di lavoro.
• Un analista di dati potrebbe inviare una query tramite Databricks SQL usando un'istanza di SQL Warehouse.
• Uno strumento di business intelligence (BI) connesso a un'istanza di SQL Warehouse può anche generare la richiesta.

In ogni caso, la risorsa di calcolo, cluster o warehouse, riceve la query e inizia l'esecuzione.

Passaggio 2: Richiedere la convalida nel catalogo unity

La risorsa di calcolo inoltra la richiesta al catalogo unity. Unity Catalog funge da piano di controllo per la sicurezza e la governance. Registra la richiesta nel registro di audit e verifica se il principale dispone delle autorizzazioni necessarie per accedere agli oggetti menzionati nella query. Se le autorizzazioni vengono negate, la query viene bloccata e viene registrata la negazione. Se viene concesso l'accesso, la richiesta viene spostata in avanti.

Passaggio 3: Utilizzo delle credenziali cloud

Per ogni oggetto a cui viene fatto riferimento nella query, Unity Catalog presuppone le credenziali cloud appropriate associate a tale oggetto. Queste credenziali vengono configurate da un amministratore cloud.

• Per le tabelle gestite, le credenziali in genere puntano all'archiviazione nel cloud collegata al metastore dell'Unity Catalog
• Per tabelle o file esterni, le credenziali corrispondono a un percorso esterno regolato da una credenziale di archiviazione definita.

Fase 4: Emissione di token a ambito definito

Dopo la convalida delle credenziali, Unity Catalog genera un token di accesso temporaneo con portata specifica per ogni oggetto. Insieme al token, fornisce un URL di accesso sicuro. Ciò consente alla risorsa di calcolo di leggere direttamente dall'archiviazione senza esporre credenziali di lunga durata.

Passaggio 5: Accesso ai dati dall'archiviazione

La risorsa di calcolo (cluster o SQL Warehouse) usa il token e l'URL forniti da Unity Catalog per richiedere i dati direttamente dagli endpoint ADLS Gen2 sottostanti (tramite abfss:// o dfs.core.windows.net URL)

Passaggio 6: Trasferimento dei dati

Archiviazione cloud restituisce i dati richiesti alla risorsa di calcolo. Questo processo viene ripetuto per ogni oggetto a cui viene fatto riferimento nella query.

Passaggio 7: Filtro con granularità fine

Il catalogo di Unity applica filtri a livello di riga e colonna nella risorsa di calcolo stessa. Ciò garantisce che le entità visualizzino solo il sottoinsieme esatto di dati a cui hanno diritto di accedere.

• Il filtro a livello di riga introduce condizioni valutate in fase di esecuzione delle query all'interno del motore di calcolo. Anche se il sistema di archiviazione sottostante può restituire un set di dati più ampio, Il catalogo unity garantisce che solo le righe corrispondenti alle condizioni definite vengano rese visibili all'entità richiedente. Ciò consente a più utenti di eseguire query sulla stessa tabella, ma ognuno riceve una visualizzazione personalizzata e limitata dei dati. Una funzione di filtro di riga è fondamentalmente un predicato (un'espressione SQL o una funzione definita dall'utente) che viene valutata durante l'esecuzione della query.

• Il filtro a livello di colonna funziona in modo analogo, ma a livello di attributo. È possibile mascherare o trasformare colonne specifiche in modo che le informazioni riservate siano nascoste o anonime, a seconda dei privilegi dell'entità. In questo modo è possibile condividere i set di dati su larga scala, garantendo al contempo che i campi riservati siano completamente visibili solo a quelli con autorizzazione appropriata.

Passaggio 8: Restituzione del risultato

Il risultato della query filtrata viene restituito dalla risorsa di calcolo all'utente chiamante, al processo o all'applicazione chiamante.

Funzionamento delle query con Apache Hive

Unity Catalog è stato progettato per semplificare la governance, ma mantiene anche la compatibilità con il metastore Hive legacy. Quando un'area di lavoro viene assegnata a un metastore del catalogo Unity, Hive viene visualizzato come un catalogo speciale denominato hive_metastore. Le tabelle archiviate lì possono comunque essere interrogate tramite query facendo riferimento a questo catalogo nel namespace.

Il ciclo di vita di una query su una tabella Hive differisce da Unity Catalog in diversi modi:

• Hive non offre governance centralizzata e granulare. Gli amministratori devono invece gestire spesso account di servizio, segreti o profili di istanza per l'autenticazione e l'autorizzazione.
• L'accesso ai dati può comportare la configurazione dei punti di montaggio, l'autenticazione pass-through o i criteri di archiviazione, ognuno dei quali richiede una configurazione aggiuntiva.
• La registrazione di controllo e i controlli di accesso sono meno integrati rispetto a Unity Catalog, che possono causare incoerenze nell'applicazione della sicurezza.

Passaggio 1: Invio di query

Un'entità (utente o servizio) invia una query a un cluster o a un endpoint SQL. Questo è il punto di partenza per tutte le query Hive.

Passaggio 2: Controllo di accesso

Il cluster controlla la query sugli elenchi di controllo di accesso alle tabelle (ACL). Queste ACL determinano se il principale richiedente ha il diritto di accedere alla tabella specificata.

Passaggio 3: Ricerca della posizione

Se viene concesso l'accesso, il cluster consulta il metastore Hive per trovare il percorso di archiviazione della tabella. Il metastore contiene i metadati relativi alle tabelle, inclusi i relativi schemi e percorsi di archiviazione.

Passaggio 4: Percorso restituito

Il metastore Hive restituisce il percorso di archiviazione del cluster, in genere come URI , ad esempio abfss://.... Questo percorso punta alla posizione fisica dei dati della tabella nell'archiviazione cloud.

Passaggio 5: Richiesta di dati

Il cluster tenta di leggere i dati dall'archiviazione cloud. In questa fase, deve eseguire l'autenticazione usando uno dei diversi meccanismi, ad esempio un'entità servizio , l'autenticazione pass-through o un profilo di istanza. Gli amministratori devono spesso configurare queste credenziali in anticipo, insieme ai segreti e ai punti di montaggio.

Passaggio 6: Dati restituiti

Il servizio di archiviazione cloud invia i dati richiesti al cluster.

Passaggio 7: Applicazione dei criteri

Il cluster applica qualsiasi filtro dell'ultimo miglio per rimuovere i dati che l'entità non deve visualizzare. Ciò può comportare l'applicazione di restrizioni a livello di riga o colonna al momento della query.

Passaggio 8: Recapito dei risultati

Il risultato finale della query viene inviato all'entità che ha emesso la richiesta.

In pratica, ciò significa che l'esecuzione di query su Hive comporta passaggi amministrativi più manuali e manutenzione in corso. Il catalogo Unity riduce questo sovraccarico automatizzando la gestione delle credenziali, fornendo token con ambito e applicando i criteri in modo coerente in tutti gli oggetti.