Federazione del metastore Hive: abilitare Unity Catalog per governare tables registrati in un metastore Hive
Importante
Questa funzionalità si trova in anteprima pubblica.
Questo articolo presenta la federazione del metastore Hive, una funzionalità che consente a Unity Catalog di regolare i tables archiviati in un metastore Hive. È possibile federare un metastore Hive esterno o un metastore Hive legacy interno di Azure Databricks.
La federazione del metastore Hive può essere usata per i seguenti casi d'uso:
Come passaggio nel percorso di migrazione verso Unity Catalog, consentendo una migrazione incrementale senza bisogno di adattamenti al codice, alcuni dei vostri carichi di lavoro continueranno a utilizzare i dati registrati nel metastore Hive mentre altri verranno migrati.
Questo caso d'uso è più adatto alle organizzazioni che oggi utilizzano un metastore legacy di Azure Databricks Hive, perché il sistema federato interno Hive metastores consente operazioni sia di lettura che di scrittura.
Per fornire un modello ibrido a lungo termine per le organizzazioni che devono mantenere alcuni dati in un metastore Hive insieme ai dati registrati in Unity Catalog.
Questo caso d'uso è più adatto per le organizzazioni che usano un metastore Hive esterno, perché i catalogs federati per questi metastores Hive sono di sola lettura.
Diagramma
Panoramica della federazione del metastore Hive
Nella federazione del metastore Hive, si crea una connessione dall'area di lavoro di Azure Databricks al metastore Hive, e Unity Catalog esegue lo scraping del metastore Hive per popolare un federato catalog che consente all'organizzazione di lavorare con il metastore Hive tables in Unity Catalog, fornendo controlli di accesso centralizzati, tracciabilità, ricerca e altro ancora.
Gli Hive federati metastores esterni all'area di lavoro di Azure Databricks consentono la lettura usando Unity Catalog. I Hive interni metastores consentono operazioni di lettura e scrittura, aggiornando i metadati del metastore di Hive e i metadati di Unity Catalog durante la scrittura.
Quando si eseguono query su asset del metastore Hive federato, Unity Catalog fornisce il livello di governance, svolgendo funzioni come i controlli di accesso e l'audit, mentre le query vengono eseguite utilizzando la semantica del metastore Hive. Ad esempio, se un utente interroga un table archiviato in formato Parquet in un catalogfederato, allora:
- Unity Catalog controlla se l'utente ha accesso al table e deduce la derivazione per la query.
- La query stessa viene eseguita sul metastore Hive sottostante, sfruttando i metadati più recenti e le informazioni partition archiviate lì.
Come si confronta la federazione del metastore Hive con l'uso di Unity Catalog external tables?
Unity Catalog ha la possibilità di creare tablesesterni, prendendo i dati già esistenti in un'ubicazione arbitraria in archiviazione nel cloud e registrandoli in Unity Catalog come table. Questa sezione esplora le differenze tra un metastore Hive esterno e uno federato tables.
Entrambi i tipi table hanno le proprietà seguenti:
- Può essere usato per registrare una posizione arbitraria nel cloud storage come table.
- Può applicare le autorizzazioni Unity Catalog e i controlli di accesso dettagliati.
- Può essere visualizzato in derivazione per le query che vi fanno riferimento.
Solo i tables federati hanno le proprietà seguenti:
- Vengono individuati automaticamente tramite la scansione di un metastore Hive. Non appena tables vengono creati nel metastore Hive, vengono visualizzati e resi disponibili per l'interrogazione nel sistema federato Unity Catalogcatalog.
- Consentire di definire tables con semantica Hive, ad esempio Hive SerDes e partizioni.
- Consentire a tables di avere percorsi sovrapposti con altri tables in catalogsfederate.
- Consenti a tables di essere collocato nelle posizioni radice DBFS .
- Includere views definiti nel metastore Hive.
In questo modo puoi considerare il metastore Hive federato tables come un'offerta di compatibilità retroattiva con il metastore Hive, consentendo ai carichi di lavoro di utilizzare le sole semantiche di Hive, ma con la governance fornita da Unity Catalog.
Tuttavia, alcune funzionalità di Unity Catalog non sono disponibili sulle federazioni tables, ad esempio:
- Funzionalità disponibili solo per Unity Catalog gestito tables, ad esempio l'ottimizzazione predittiva.
- Ricerca vettoriale, condivisione delta, monitoraggio lakehouse e tablesonline .
- Alcune funzionalità dell'archivio funzionalità, tra cui la creazione dell'archivio funzionalità, la creazione di modelli, la creazione delle specifiche di funzionalità, la registrazione dei modelli e l'assegnazione dei punteggi batch.
Le prestazioni possono essere marginalmente peggiori dei carichi di lavoro in Unity Catalog o nel metastore Hive perché sia il metastore Hive che Unity Catalog si trovano nel percorso di interrogazione di un tablefederato.
Per altre informazioni sulle funzionalità supportate, vedere requisiti , funzionalità supportate e limitazioni.
Cosa significa scrivere in un metastore Hive federato catalog in Azure Databricks?
Le scritture sono supportate solo per l'Hive federato interno metastores, non per l'Hive esterno metastores.
Le scritture in metastores federate sono di due tipi:
operazioni DDL come
CREATE TABLE
,ALTER TABLE
eDROP TABLE
.Le operazioni DDL vengono riflesse in modo sincrono nel metastore Hive sottostante. Ad esempio, l'esecuzione di un'istruzione
CREATE TABLE
crea il table sia nel metastore Hive che nel catalogfederato.Avvertimento
Ciò significa anche che i comandi
DROP
si riflettono nel metastore Hive. Ad esempio,DROP SCHEMA mySchema CASCADE
elimina tutte le tables nel metastore Hive sottostante schema, senza l'opzione diUNDROP
, perché il metastore Hive non supportaUNDROP
.Operazioni DML come
INSERT
,UPDATE
eDELETE
.Anche le operazioni DML vengono riflesse in modo sincrono nel metastore Hive sottostante table. Ad esempio, l'esecuzione di
INSERT INTO
aggiunge record al table nel metastore Hive.Il supporto di scrittura è fondamentale per abilitare una transizione senza intoppi durante la migrazione dal metastore Hive a Unity Catalog. Consulta Come si usa la federazione del metastore Hive durante la migrazione a Unity Catalog?.
Come si set la federazione del metastore Hive?
Per impostare la federazione del metastore Hive per set, esegui le operazioni seguenti:
Creare una connessione in Unity Catalog che specifichi il percorso e credentials per l'accesso al metastore di Hive.
La federazione del metastore Hive utilizza questa connessione per scandire il metastore Hive. Per la maggior parte dei sistemi di database, è necessario specificare un nome utente e una password. Per una connessione a un metastore Hive dell'area di lavoro di Azure Databricks legacy, la federazione del metastore Hive si occupa dell'autorizzazione.
Creare una credenziale di archiviazione e e una posizione esterna in Unity Catalog per i percorsi tables registrati nel metastore Hive.
Le posizioni esterne contengono percorsi e il di archiviazione credentials necessario per accedere ai percorsi. Gli oggetti di archiviazione credentials sono elementi securizzabili di Unity Catalog che specificano credentials, come le identità gestite di Azure, per l'accesso all'archiviazione cloud. A seconda del flusso di lavoro scelto per la creazione di posizioni esterne, potrebbe essere necessario creare l'archiviazione credentials prima di creare la posizione esterna.
Crea un federato catalog in Unity Catalog, usando la connessione che hai creato nel passaggio 1.
Questo è il catalog che gli utenti dell'area di lavoro e i flussi di lavoro usano per interagire con il metastore Hive tables tramite Unity Catalog. Dopo aver creato il catalogfederato, Unity Catalog lo riempie con il tables registrato nel metastore Hive.
Grant privilegi al tables nel catalog federato usando Unity Catalog.
È possibile anche utilizzare i filtri Unity Catalog riga e column per un controllo di accesso a grana fine.
Iniziare a interrogare i dati.
L'accesso ai dati federati tramite Unity Catalog è di sola lettura per l'Hive esterno metastores e di lettura e scrittura per l'Hive interno metastores.
Per gli Hive interni metastores e gli Hive esterni metastores, Unity Catalog aggiorna continuamente i metadati table man mano che essi cambiano nel metastore Hive. Per gli metastoresHive interni, i nuovi aggiornamenti di tables e table che sono stati eseguiti dal catalog federato vengono riscritti nel metastore di Hive, mantenendo l'interoperabilità completa tra il metastore di Unity Catalog e il metastore di Hive catalogs.
Per istruzioni dettagliate, vedere:
- Abilitare la federazione del metastore Hive per un metastore Hive dell'area di lavoro legacy
- Abilitare la federazione del metastore Hive per un metastore Hive esterno
Come si usa la federazione del metastore Hive durante la migrazione a Unity Catalog?
La federazione del metastore Hive consente di eseguire la migrazione a Unity Catalog in modo incrementale riducendo la necessità di coordinamento tra team e carichi di lavoro. In particolare, se stai migrando dal metastore Hive interno dell'area di lavoro di Azure Databricks, la possibilità di leggere e scrivere sia nel metastore Hive che nel metastore di Unity Catalog significa che è possibile mantenere metastores "rispecchiati" durante la migrazione, offrendo i seguenti vantaggi:
- I carichi di lavoro eseguiti su catalogs federati vengono eseguiti in modalità di compatibilità metastore Hive, riducendo il costo dell'adattamento del codice durante la migrazione.
- Ogni carico di lavoro può scegliere di eseguire la migrazione indipendentemente da altri, sapendo che, durante il periodo di migrazione, i dati saranno disponibili sia nel metastore Hive che in Unity Catalog, riducendo la necessità di coordinare tra carichi di lavoro con dipendenze l'una dall'altra.
Questa sezione descrive un flusso di lavoro tipico per la migrazione del metastore Hive interno di un'area di lavoro di Azure Databricks verso Unity Catalog, facilitata dalla federazione del metastore Hive che semplifica la transizione. Non si applica alla migrazione di un metastore Hive esterno. Le catalogs federate per Hive esterni metastores non supportano operazioni di scrittura.
Passo 1: Federa il metastore Hive interno
In questo passaggio, crei un catalog federato che replica il metastore Hive in Unity Catalog. Chiamiamolo hms_in_uc
.
Nota
Come parte del processo di federazione, è set posizioni esterne per fornire l'accesso ai dati nell'archiviazione cloud. Negli scenari di migrazione in cui alcuni carichi di lavoro eseguono query sui dati utilizzando meccanismi di accesso legacy e altri carichi di lavoro eseguono query sugli stessi dati in Unity Catalog, i controlli di accesso gestiti da Unity Catalogin posizioni esterne possono impedire ai carichi di lavoro legacy di accedere ai percorsi di archiviazione dai sistemi di calcolo abilitati per Unity Catalog. È possibile abilitare la "modalità di fallback" in queste posizioni esterne per eseguire il fallback su qualsiasi credentials con ambito di cluster o notebook che siano stati definiti per il carico di lavoro legacy. Al termine della migrazione, si disattiva la modalità di fallback. Vedi Che cos'è la modalità di fallback?.
Per ulteriori dettagli, vedere Abilitare la federazione del Metastore Hive per il metastore Hive dell'area di lavoro legacy.
Passaggio 2. Eseguire nuove attività contro il catalog federato in Unity Catalog
Quando si dispone di un catalog federato, è possibile grant gli analisti SQL e i consumer di data science accedervi e iniziare a sviluppare nuovi carichi di lavoro che puntano a esso. I nuovi carichi di lavoro traggono vantaggio dalla funzionalità aggiuntiva set in Unity Catalog, inclusi i controlli di accesso, la ricerca e la derivazione.
diagramma
In questo passaggio vengono in genere eseguite le operazioni seguenti:
- Scegliere il calcolo compatibile con Unity Catalog(ovvero modalità di accesso a utente singolo o a cluster condiviso, warehouse SQL o calcolo serverless). Consulta Requisiti, funzionalità supportate e limitazioni.
- Rendere il catalog federato il catalog predefinito nella risorsa di calcolo o aggiungere
USE CATALOG hms_in_uc
all'inizio del codice. Poiché gli schemi e i nomi di table nel catalog federato sono specchi esatti di quelli nel metastore Hive, il codice inizierà a fare riferimento al catalogfederato.
passaggio 3. Eseguire la migrazione di processi esistenti per operare contro il catalog federato
Per eseguire la migrazione di processi esistenti per eseguire una query sul catalogfederato:
- Modificare il catalog predefinito nel cluster di processi in modo che sia
hms_in_uc
impostando una proprietà nel cluster stesso o aggiungendoUSE CATALOG hms_in_uc
all'inizio del codice. - Passare il lavoro al calcolo in modalità utente singolo o modalità di accesso condiviso e aggiornare a una delle versioni di Databricks Runtime che supportano la federazione del metastore Hive. Consulta Requisiti, funzionalità supportate e limitazioni.
- Chiedere a un amministratore di Azure Databricks di grant i privilegi corretti di Unity Catalog sugli oggetti dati in
hms_in_uc
e su qualsiasi percorso di archiviazione cloud (incluso in Unity Catalog percorsi esterni) a cui accede il processo. Consultare Gestire i privilegi in Unity Catalog.
Passaggio 4. Deny l'accesso al metastore Hive
Dopo aver migrato tutti i carichi di lavoro per interrogare il catalogfederato, non è più necessario il metastore Hive. È possibile usare i controlli di accesso legacy table e le autorizzazioni di calcolo per bloccare l'accesso diretto dall'area di lavoro di Azure Databricks al metastore Hive. Ad esempio, è possibile:
Revoke tutti i privilegi per gli oggetti nel metastore Hive catalog.
Il comando
MSCK REPAIR PRIVILEGES
è utile a questo scopo. Vedere MSCK REPAIR PRIVILEGES e i privilegi del metastore Hive e gli oggetti a protezione diretta (legacy).Impedire agli utenti di creare e usare cluster che bypassano il controllo di accesso table (cluster che utilizzano modalità di accesso condiviso senza isolamento o un tipo di cluster personalizzato legacy) utilizzando le politiche di calcolo.
Impostare la federata catalog come la area di lavoro predefinita catalog.
Consulta per gestire il catalogpredefinito.
Domande frequenti
Le sezioni seguenti offrono informazioni più dettagliate sulla federazione del metastore Hive.
Che cos'è la modalità di fallback?
modalità di fallback è un'impostazione in posizioni esterne che è possibile usare per ignorare i controlli delle autorizzazioni di Unity Catalog durante la migrazione a Unity Catalog. L'impostazione garantisce che i carichi di lavoro di cui non è ancora stata eseguita la migrazione non siano interessati durante la fase di installazione.
Unity Catalog ottiene l'accesso all'archiviazione cloud usando posizioni esterne, ovvero oggetti sicurabili che definiscono un percorso e una credenziale per accedere all'account di archiviazione cloud. È possibile rilasciare autorizzazioni su di essi, ad esempio READ FILES
, per gestire chi può usare il percorso. Una delle difficoltà durante il processo di migrazione è che potresti non voler che Unity Catalog inizi subito a governare tutto l'accesso al percorso, ad esempio quando ci sono carichi di lavoro esistenti non migrati che fanno riferimento al percorso.
La modalità di fallback consente di ritardare l'imposizione rigorosa del controllo di accesso di Unity Catalog su posizioni esterne. Quando la modalità di fallback è abilitata, i carichi di lavoro che accedono a un percorso vengono prima controllati in base alle autorizzazioni di Unity Catalog e, in caso di esito negativo, viene effettuato il fallback all'uso di ambito di cluster o notebook credentials, ad esempio profili di istanza o proprietà di configurazione di Apache Spark. Ciò consente ai carichi di lavoro esistenti di continuare a usare le credenziali correnti.
La modalità di fallback è destinata solo all'uso durante la migrazione. Dovresti spegnerla quando tutti i carichi di lavoro sono stati migrati e sei pronto a far rispettare i controlli di accesso di Unity Catalog.
Eseguire query nel log di controllo per l'utilizzo del fallback
Usare la query seguente per verificare se un accesso alla posizione esterna usa la modalità di fallback negli ultimi 30 giorni.Use the following query to check if any access to the external location used fallback mode in the last 30 days. Se non è presente alcun accesso in modalità di fallback nell'account, Databricks consiglia di disattivare la modalità di fallback.
SELECT event_time, user_identity, action_name, request_params, response, identity_metadata
FROM system.access.audit
WHERE
request_params.fallback_enabled = 'true' AND
request_params.path LIKE '%some-path%' AND
event_time >= current_date() - INTERVAL 30 DAYS
LIMIT 10
Quali sono i percorsi autorizzati?
Quando si crea un catalogfederato, si richiede di fornire percorsi autorizzati all'archiviazione cloud where dove vengono archiviati i metastore Hive tables. Qualsiasi table a cui si vuole accedere tramite la federazione del metastore Hive deve essere coperto da questi percorsi. Databricks consiglia che i percorsi autorizzati siano percorsi secondari comuni in un numero elevato di tables. Ad esempio, se si dispone di tables in abfss://container@storageaccount.dfs.core.windows.net/bucket/table1
, ./bucket/table2
e ./bucket/table3
, è necessario fornire abfss://container@storageaccount.dfs.core.windows.net/bucket/
come percorso autorizzato.
È possibile utilizzare UCX per aiutarvi a identificare i percorsi presenti nel metastore Hive.
I percorsi autorizzati aggiungono un ulteriore livello di sicurezza nei catalogs federati consentendo al proprietario catalog di applicare protezioni ai dati a cui gli utenti possono accedere tramite la federazione. Ciò è utile se il metastore di Hive consente agli utenti di update i metadati e di modificare arbitrariamente i percorsi di table, ovvero aggiornamenti che altrimenti verrebbero sincronizzati nel catalogfederato. In questo scenario, gli utenti potrebbero potenzialmente ridefinire tables a cui hanno già accesso in modo che puntino a nuove posizioni a cui altrimenti non avrebbero accesso.
Posso federare Hive metastores usando UCX?
UCX, il progetto Databricks Labs per la migrazione delle aree di lavoro di Azure Databricks a Unity Catalog, include strumenti per consentire la federazione del metastore Hive.
enable-hms-federation
create-federated-catalog
Consulta il file Leggimi del progetto su GitHub. Per un'introduzione a UCX, vedere Usare le utilità UCX per aggiornare l'area di lavoro a Unity Catalog.
Requisiti, funzionalità supportate e limitazioni
Di seguito table sono elencati i servizi e le funzionalità supportati dalla federazione del metastore Hive. In alcuni casi sono elencati anche servizi o funzionalità non supportati. In questi tables, "HMS" è l'acronimo di Hive metastore.
Categoria | Sostenuto | Non supportato |
---|---|---|
Metastores | - metastores Hive dell'area di lavoro legacy (interna a Databricks) - metastores esterni in Apache Hive versione 0.13 o 2.3 utilizzando MySQL |
- metastores esterni nei database che non sono mySQL - Hive 3.1 |
Operazioni | - HMS di Databricks interno: letture e scritture - HMS esterno: sola lettura |
|
Dati degli asset del metastore Hive | - tables gestito ed esterno nel metastore Hive - Schemi - Views - Hive SerDe tables |
- Funzioni Hive e UDF - Definizione di nuovi cloni superficiali nel catalog federato - tables supportata da JDBC - Delta Sharing condiviso tables - Accesso a cloni superficiali registrati nel metastore Hive tramite il catalog federato |
Immagazzinamento | - Azure Data Lake Storage Gen2 - Tables che fanno riferimento a punti di montaggio DBFS, inclusa la radice DBFS - Tables i cui percorsi si sovrappongono ad altri percorsi table HMS definiti in posizioni esterne |
- HMS tables i cui percorsi si sovrappongono ai percorsi di oggetti nativi di Unity Catalog - Accesso a tables nella radice o nelle posizioni di montaggio DBFS registrate in un HMS esterno - Accesso a tables nella radice o nei percorsi di montaggio DBFS da qualsiasi area di lavoro diversa da quella in cui è definita HMS interna - supporto del firewall per l'account di archiviazione dell'area di lavoro |
Tipi di calcolo | - Cluster condivisi Cluster assegnati a un singolo utente - Serverless (tutti) - SQL magazzini (tutti) |
Nessun gruppo di isolamento |
Versioni di calcolo | - Tutti i canali SQL di Databricks - Tutti i canali Delta Live Tables - Databricks Runtime 13.3 LTS - Databricks Runtime 14.3 LTS - Databricks Runtime 15.1 e versioni successive |
|
Caratteristiche di Unity Catalog | - Modello di privilegio Unity Catalog - Filtri di riga e maschere di column - Revisione contabile - Linea discendente - ricerca Table - Accesso tra diversi spazi di lavoro (ad eccezione della radice di DBFS e dei punti di montaggio) - Accesso ai dati limitato a posizioni esterne definite |
- Delta Sharing - Monitoraggio di Lakehouse - Ricerca vettoriale - tables online - Alcune funzionalità dell'archivio funzionalità, tra cui la creazione dell'archivio funzionalità, la creazione di modelli, la creazione di specifiche di funzionalità, la registrazione dei modelli e l'assegnazione dei punteggi batch - Non è possibile scrivere Tables Delta Live materializzate views e tables di streaming in un catalogfederato, ma è possibile usare asset federati come origine per delta Live Tables materializzati views e streaming tables. - Migrazione automatica degli elenchi di controllo di accesso legacy table in privilegi Unity Catalog per il catalogfederato. UCX può essere utile. |