Condividi tramite

Oggetti di database nel legacy metastore Hive

  • 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 evidenzia che lavorare con gli oggetti del metastore Hive where è diverso dal lavoro con gli oggetti Unity Catalog. 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. Consulta l'aggiornamento di Hive tables e views 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. Consultare Lavorare con Unity Catalog 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 di dati registrati nel metastore Hive legacy vengono esposti nelle interfacce di Unity Catalog nel hive_metastorecatalog. Un metastore Hive ibrido e un'area di lavoro di Unity Catalog possono essere un modello utile per la transizione di un'area di lavoro metastore Hive di lunga durata. Tuttavia, i vantaggi di governance e prestazioni dei dati di Unity Catalog sono elevati ed è consigliabile eseguire completamente la transizione delle aree di lavoro non appena possibile.

Il metastore Hive utilizza il controllo degli accessi table (ACLtable) per gestire l'accesso agli oggetti del database. Rimane un certo supporto per il controllo degli accessi table quando si utilizza l'elaborazione in modalità di accesso condiviso. Vedere metastore Hive table controllo di accesso (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

Where Questo articolo si riferisce al controllo di accesso ai dati nel metastore Hive, riferendosi al controllo di accesso legacy table.

Che cos'è il hive_metastorecatalog?

In un'area di lavoro abilitata per Unity Catalog, tutti gli schemi nel metastore Hive vengono visualizzati come elementi figlio del hive_metastorecatalog nello spazio dei nomi Unity Catalog suddiviso in tre livelli. Il metastore Hive non utilizza realmente catalogse questo costrutto offre un punto di ingresso a tables nel metastore Hive legacy per gli utenti di Unity Catalog. Usare la sintassi seguente per eseguire l'interrogazione tables nel metastore Hive di legacy:

SELECT * FROM hive_metastore.schema_name.table_name

Nota

Facoltativamente, è possibile impostare set il hive_metastorecatalog come predefinito nelle aree di lavoro abilitate da Unity Catalog. Visualizza Gestisci il catalogpredefinito.

Schemi nel metastore Hive

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

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

  • Non è possibile creare schemi nel metastore Hive usando Catalog Explorer. È 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 per un schema durante la creazione. Questa funzionalità opera in modo analogo ai percorsi di archiviazione gestiti di Unity Catalog, con le seguenti differenze comportamentali:
    • 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 posizione di archiviazione cloud disponibile per l'utente che crea il schema, inclusi gli URI cloud, le directory principali di DBFS e i montaggi DBFS.
    • L'accesso alla posizione non è gestito dal metastore Hive.
    • L'eliminazione di un schema nel metastore Hive comporta l'eliminazione ricorsiva di tutti i file in quel percorso schema, indipendentemente dal fatto che sia di tipo table (gestito o esterno).

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

  • Non assegnare l'indirizzo schema se contiene già dati.
  • Non creare un table esterno in un percorso di schema.
  • Non condividere una posizione tra più schemi.
  • Non assegnare una posizione schema che si sovrappone a un'altra posizione schema. In altre parole, non usare un percorso figlio di un'altra posizione schema.
  • Non assegnare una posizione schema che si sovrapponga alla posizione di un tableesterno.

tables gestito nel metastore Hive

Le tables gestite nel metastore Hive non hanno alcun vantaggio prestazionale rispetto alle tables gestite in Unity Catalog. Come il sistema gestito Unity Catalogtables, i metastore gestiti di Hive tables utilizzano Delta Lake per impostazione predefinita. Tuttavia, nel metastore Hive, a differenza di Unity Catalog, è anche possibile creare un table gestito usando la maggior parte degli altri formati di dati supportati da Azure Databricks.

tables gestiti nel metastore Hive vengono sempre creati nella posizione di archiviazione del contenitore schema. Il calcolo usato per eseguire query su un table gestito deve avere accesso alla posizione di archiviazione.

Il metastore Hive non gestisce il layout dei dati di tables gestito allo stesso modo di come fa Unity Catalog. Quando si elimina un table gestito nel metastore Hive, tutti i file di dati sottostanti vengono eliminati immediatamente. In Unity Catalog, invece, è possibile UNDROP un table gestito per 7 giorni e i dati vengono eliminati definitivamente entro 30 giorni.

È possibile usare l'accesso basato su percorso per leggere o scrivere dati nel metastore Hive gestito tables, mentre invece in Unity Catalog non è possibile né necessario.

Elementi tables esterni nel metastore Hive

La maggior parte delle tables create in Azure Databricks prima dell'introduzione di Unity Catalog sono state configurate come tables esterne nel metastore Hive. Raccomandazioni legacy che hanno favorito tables esterni erano generalmente incentrate su alcuni aspetti chiave:

  • È possibile registrare un table esterno sopra i dati esistenti nell'archiviazione di oggetti cloud.
  • È possibile accedere direttamente ai file di dati esterni tables da sistemi esterni per letture o scritture.
  • I file di dati non sono stati eliminati se il table è stato eliminato accidentalmente.
  • Poiché i tables esterni richiedono un LOCATION, è meno probabile che i dati di produzione finiscano accidentalmente nella radice del DBFS.

Azure Databricks ora consiglia Unity Catalog gestito tables per la maggior parte delle soluzioni di archiviazione dati tabulari. Vedere Lavorare con tablesgestito.

Views nel metastore Hive

È possibile dichiarare una vista nel metastore Hive supportata da qualsiasi origine dati supportata da Azure Databricks. In Unity Catalog, è possibile dichiarare views solo contro Unity Catalogtables e views, inclusi tablesstraniere, materializzate viewse Condivisione Delta tables.

A causa della possibilità di dichiarare views su origini dati non tabulari, views nel metastore Hive può concedere un accesso imprevisto o non intenzionale ai dati, in combinazione con un insieme di configurazioni di accesso nell'ambiente utente.

Considera l'esempio seguente:

  • Un tablemy_table viene definito usando il percorso di montaggio DBFS /mnt/my_table.
    • I montaggi DBFS credentials vengono archiviati direttamente nell'area di lavoro, quindi tutti gli utenti possono accedere a questo percorso per impostazione predefinita.
  • Table ACL vengono usati per limitare l'accesso a my_table a un gruppo di utenti.
    • Gli elenchi di controllo di accesso legacy table si applicano solo alle risorse di calcolo configurate 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.
    • Gli URI credentials si basano sui criteri di accesso definiti nella sessione Spark o configurazione di calcolo.

La vista my_view ha le proprietà seguenti:

  • Non utilizza il montaggio DBFS credentials per il montaggio di archiviazione di oggetti nel cloud su /mnt/my_table.
  • Non rispetta le ACL tableset su my_table, indipendentemente dalle configurazioni computazionali.
  • 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 si potrebbe incontrare e non è completo di tutti i potenziali problemi presentati da views nel metastore Hive legacy. Databricks consiglia di usare unity Catalog per tutte le definizioni di visualizzazione.

Supporto di Hive tables legacy e HiveQL

Azure Databricks include del supporto legacy per la funzionalità di Hive tables e di HiveQL. Questa funzionalità è una parte rimanente delle versioni precedenti di Azure Databricks e dell'ecosistema di strumenti Apache Hadoop. Databricks non consiglia di usare hive tables 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: