Condividi tramite

Oggetti di database nel metastore Hive legacy

  • Articolo

La documentazione di Azure Databricks è incentrata sull'uso di oggetti dati con Unity Catalog, ma la maggior parte delle istruzioni si applica anche all'uso di oggetti registrati nel metastore Hive legacy.

Questo articolo illustra come usare gli oggetti di database registrati nel metastore Hive legacy. In particolare, questo articolo descrive dove l'uso degli oggetti metastore Hive differisce dall'uso degli oggetti del catalogo Unity. Descrive anche altri comportamenti che potrebbero essere imprevisti.

Databricks consiglia di eseguire la migrazione di tutti i dati dal metastore Hive legacy a Unity Catalog. Vedere Aggiornare tabelle e viste Hive a Unity Catalog.

Come funziona la governance dei dati del metastore Hive?

Anche se le aree di lavoro di Azure Databricks continuano a includere il metastore Hive predefinito, la governance dei dati con il metastore Hive è deprecata. Databricks consiglia di usare Unity Catalog per tutta la governance dei dati. Vedere Usare il catalogo unity e il metastore Hive legacy.

L'abilitazione di un'area di lavoro per Unity Catalog non riduce la possibilità di usare i dati già registrati nel metastore Hive. Tutti gli oggetti dati registrati nel metastore Hive legacy vengono visualizzati nelle interfacce del catalogo Unity nel hive_metastore catalogo. Un metastore Hive ibrido e un'area di lavoro catalogo unity possono essere un modello utile per la transizione di un'area di lavoro metastore Hive di lunga durata. Tuttavia, i vantaggi della governance dei dati e delle prestazioni di Unity Catalog sono elevati ed è consigliabile eseguire la transizione completa delle aree di lavoro non appena possibile.

Il metastore Hive usa il controllo di accesso alle tabelle (ACL di tabella) per gestire l'accesso agli oggetti di database. Alcune funzionalità di supporto rimangono per il controllo di accesso alle tabelle quando si usa il calcolo in modalità di accesso condiviso. Vedere Controllo di accesso alle tabelle metastore Hive (legacy).

Il pass-through delle credenziali è un modello deprecato per la governance dei dati in oggetti di database metastore Hive. Questo articolo non risolve il pass-through delle credenziali. Vedere Pass-through delle credenziali (legacy).

Nota

Dove questo articolo si riferisce al controllo di accesso ai dati nel metastore Hive, si riferisce al controllo di accesso alle tabelle legacy.

Che cos'è il hive_metastore catalogo?

In un'area di lavoro abilitata per Il catalogo Unity, tutti gli schemi nel metastore Hive vengono visualizzati come elementi figlio del hive_metastore catalogo nello spazio dei nomi a tre livelli di Unity Catalog. Il metastore Hive non usa effettivamente i cataloghi e questo costrutto fornisce un punto di ingresso alle tabelle nel metastore Hive legacy per gli utenti del catalogo Unity. Usare la sintassi seguente per eseguire query sulle tabelle nel metastore Hive legacy:

SELECT * FROM hive_metastore.schema_name.table_name

Nota

Facoltativamente, è possibile impostare il hive_metastore catalogo come predefinito per l'area di lavoro nelle aree di lavoro abilitate per Unity Catalog. Vedere Gestire il catalogo predefinito.

Schemi nel metastore Hive

Nel metastore Hive legacy, uno schema è il livello più alto nella gerarchia degli oggetti dati.

Esistono alcune differenze importanti tra il catalogo di Unity e il metastore Hive, tra cui:

  • Non è possibile creare schemi nel metastore Hive usando Esplora cataloghi. È possibile visualizzare e modificare le autorizzazioni per gli schemi.
  • Gli schemi creati nel metastore Hive possono usare solo caratteri ASCII alfanumerici e caratteri di sottolineatura nei nomi.
  • Il metastore Hive consente di dichiarare un LOCATION oggetto per uno schema durante la creazione. Questa funzione funziona in modo analogo alle posizioni di archiviazione gestite del catalogo Unity, con le differenze comportamentali seguenti:
    • Se non si specifica un percorso, viene usata la posizione /user/hive/warehouse/<schema-name> predefinita. Questo percorso si trova nella radice DBFS, che non è consigliata per l'archiviazione di dati di produzione.
    • Il percorso specificato può essere qualsiasi percorso di archiviazione cloud disponibile per l'utente che crea lo schema, inclusi gli URI cloud, la radice DBFS e i montaggi DBFS.
    • L'accesso alla posizione non è gestito dal metastore Hive.
    • L'eliminazione di uno schema nel metastore Hive causa l'eliminazione ricorsiva di tutti i file in tale percorso dello schema, indipendentemente dal tipo di tabella (gestito o esterno).

Per evitare perdite accidentali di dati, Databricks consiglia quanto segue quando si lavora con i percorsi dello schema del metastore Hive:

  • Non assegnare un percorso dello schema che contiene già dati.
  • Non creare una tabella esterna in un percorso dello schema.
  • Non condividere una posizione tra più schemi.
  • Non assegnare un percorso dello schema che si sovrappone a un altro percorso dello schema. In altre parole, non usare un percorso figlio di un'altra posizione dello schema.
  • Non assegnare una posizione dello schema che si sovrappone alla posizione di una tabella esterna.

Tabelle gestite nel metastore Hive

Le tabelle gestite nel metastore Hive non presentano alcun vantaggio in termini di prestazioni delle tabelle gestite in Unity Catalog. Come le tabelle gestite di Unity Catalog, le tabelle gestite del metastore Hive usano Delta Lake per impostazione predefinita. Tuttavia, nel metastore Hive, a differenza di Unity Catalog, è anche possibile creare una tabella gestita usando la maggior parte degli altri formati di dati supportati da Azure Databricks.

Le tabelle gestite nel metastore Hive vengono sempre create nel percorso di archiviazione dello schema contenitore. Il calcolo usato per eseguire query su una tabella gestita deve avere accesso al percorso di archiviazione.

Il metastore Hive non gestisce il layout dei dati delle tabelle gestite nel modo in cui il catalogo Unity esegue. Quando si elimina una tabella gestita nel metastore Hive, tutti i file di dati sottostanti vengono eliminati immediatamente. In Unity Catalog, invece, è possibile UNDROP gestire una tabella per 7 giorni e i dati vengono eliminati definitivamente entro 30 giorni.

È possibile usare l'accesso basato sul percorso per leggere o scrivere dati nelle tabelle gestite del metastore Hive, mentre in Unity Catalog non è possibile e non è necessario.

Tabelle esterne nel metastore Hive

La maggior parte delle tabelle create in Azure Databricks prima dell'introduzione di Unity Catalog è stata configurata come tabelle esterne nel metastore Hive. Le raccomandazioni legacy che hanno favorito le tabelle esterne sono in genere incentrate su alcuni aspetti chiave:

  • È possibile registrare una tabella esterna sopra i dati esistenti nell'archiviazione di oggetti cloud.
  • È possibile accedere direttamente ai file di dati in tabelle esterne da sistemi esterni per letture o scritture.
  • I file di dati non sono stati eliminati se la tabella è stata eliminata accidentalmente.
  • Poiché le tabelle esterne richiedono un LOCATION, è meno probabile che i dati di produzione vengano accidentalmente inseriti nella radice DBFS.

Azure Databricks consiglia ora tabelle gestite di Unity Catalog per la maggior parte dell'archiviazione dei dati tabulari. Vedere Usare tabelle gestite.

Viste nel metastore Hive

È possibile dichiarare una vista nel metastore Hive supportata da qualsiasi origine dati supportata da Azure Databricks. In Unity Catalog è possibile dichiarare visualizzazioni solo per tabelle e viste del catalogo Unity, incluse tabelle esterne, viste materializzate e tabelle di condivisione differenziale.

A causa della possibilità di dichiarare visualizzazioni su origini dati non tabulari, le viste nel metastore Hive possono concedere l'accesso imprevisto o imprevisto ai dati in combinazione con altre configurazioni di accesso nell'ambiente utente.

Considera l'esempio seguente:

  • Una tabella my_table viene definita usando il percorso di montaggio /mnt/my_tableDBFS .
    • Le credenziali di montaggio DBFS vengono archiviate nell'area di lavoro, quindi tutti gli utenti hanno accesso a questo percorso per impostazione predefinita.
  • Gli ACL di tabella vengono usati per limitare l'accesso a my_table un gruppo di utenti.
    • Gli ACL di tabella legacy si applicano solo alle risorse di calcolo congfigured con modalità di accesso condiviso o sql warehouse.
  • Una vista my_view viene definita direttamente sull'URI cloud che esegue il backup degli stessi file di 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'dati.
    • Le credenziali URI si basano sui criteri di accesso definiti nella configurazione di calcolo o sessione Spark.

La vista my_view ha le proprietà seguenti:

  • Non usa le credenziali di montaggio DBFS usate per montare l'archiviazione di oggetti cloud in /mnt/my_table.
  • Non rispetta gli ACL di tabella impostati in my_table, indipendentemente dalle configurazioni di calcolo.
  • Richiede un criterio di accesso ai dati configurato per il calcolo che fornisce l'accesso in lettura a 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'.

Nota

Questo è un esempio di comportamento imprevisto che potresti incontrare e non completo di tutti i potenziali problemi presentati dalle visualizzazioni nel metastore Hive legacy. Databricks consiglia di usare Unity Catalog per tutte le definizioni di visualizzazione.

Tabelle Hive legacy e supporto HiveQL

Azure Databricks include il supporto legacy per le tabelle Hive e la funzionalità HiveQL. Questa funzionalità è una parte rimanente delle versioni precedenti di Azure Databricks e dell'ecosistema di strumenti Apache Hadoop. Databricks non consiglia di usare tabelle Hive o altre funzionalità Hive, perché questa funzionalità non è ottimizzata e non supporta alcune configurazioni di calcolo.

Gli articoli seguenti descrivono le funzionalità legacy di Hive: