Delen via

Databaseobjecten in de verouderde Hive-metastore

  • Artikel

De Documentatie van Azure Databricks is gericht op het werken met gegevensobjecten met behulp van Unity Catalog, maar de meeste instructies zijn ook van toepassing op het werken met objecten die zijn geregistreerd in de verouderde Hive-metastore.

Dit artikel is gericht op het werken met databaseobjecten die zijn geregistreerd in de verouderde Hive-metastore. In dit artikel wordt beschreven waar het werken met Hive-metastore-objecten verschilt van het werken met Unity Catalog-objecten. Ook worden andere gedragingen beschreven die onverwacht kunnen zijn.

Databricks raadt u aan alle gegevens van de verouderde Hive-metastore te migreren naar Unity Catalog. Zie Hive-tabellen en -weergaven upgraden naar Unity Catalog.

Hoe werkt het gegevensbeheer van Hive-metastore?

Hoewel Azure Databricks-werkruimten de ingebouwde Hive-metastore blijven opnemen, wordt gegevensbeheer met behulp van Hive-metastore afgeschaft. Databricks raadt u aan Unity Catalog te gebruiken voor alle gegevensbeheer. Zie Werken met Unity Catalog en de verouderde Hive-metastore.

Het inschakelen van een werkruimte voor Unity Catalog vermindert niet de mogelijkheid om te werken met gegevens die al zijn geregistreerd in hive-metastore. Alle gegevensobjecten die zijn geregistreerd in de verouderde Hive-metastore, worden weergegeven in Unity Catalog-interfaces in de hive_metastore catalogus. Een hybride Hive-metastore- en Unity Catalog-werkruimte kan een nuttig model zijn voor het overzetten van een langdurige Hive-metastore-werkruimte. De voordelen van gegevensbeheer en prestaties van Unity Catalog zijn echter hoog en u moet uw werkruimten zo snel mogelijk volledig overschakelen.

Hive-metastore maakt gebruik van toegangsbeheer voor tabellen (tabel-ACL's) om de toegang tot databaseobjecten te beheren. Er blijft enige ondersteuning voor toegangsbeheer voor tabellen wanneer u rekenkracht gebruikt in de modus voor gedeelde toegang. Zie Toegangsbeheer voor Hive-metastore-tabellen (verouderd).

Referentiepassthrough is een afgeschaft patroon voor gegevensbeheer op Hive-metastore-databaseobjecten. Dit artikel heeft geen betrekking op referentiepassthrough. Zie Referentiepassthrough (verouderd).

Notitie

Waar dit artikel verwijst naar gegevenstoegangsbeheer in hive-metastore, verwijst dit naar verouderd toegangsbeheer voor tabellen.

Wat is de hive_metastore catalogus?

In een werkruimte die is ingeschakeld voor Unity Catalog, worden alle schema's in de Hive-metastore weergegeven als onderliggende elementen van de hive_metastore catalogus in de naamruimte op drie niveaus van de Unity Catalog. Hive-metastore gebruikt geen catalogi en deze constructie biedt een ingangspunt voor tabellen in de verouderde Hive-metastore voor Unity Catalog-gebruikers. Gebruik de volgende syntaxis om query's uit te voeren op tabellen in de verouderde Hive-metastore:

SELECT * FROM hive_metastore.schema_name.table_name

Notitie

U kunt de hive_metastore catalogus desgewenst instellen als de standaardwerkruimte in werkruimten met Unity Catalog. Zie De standaardcatalogus beheren.

Schema's in Hive-metastore

In de verouderde Hive-metastore is een schema het hoogste niveau in de gegevensobjecthiërarchie.

Er zijn enkele belangrijke verschillen tussen Unity Catalog en Hive-metastore, waaronder de volgende:

  • U kunt geen schema's maken in de Hive-metastore met behulp van Catalog Explorer. U kunt machtigingen voor schema's weergeven en bewerken.
  • Schema's die zijn gemaakt in de Hive-metastore kunnen alleen alfanumerieke ASCII-tekens en onderstrepingstekens in hun namen gebruiken.
  • Met Hive-metastore kunt u een LOCATION voor een schema declareren tijdens het maken. Dit werkt op dezelfde manier als beheerde opslaglocaties van Unity Catalog, met de volgende gedragsverschillen:
    • Als u geen locatie opgeeft, wordt de standaardlocatie /user/hive/warehouse/<schema-name> gebruikt. Deze locatie bevindt zich in de DBFS-hoofdmap, die niet wordt aanbevolen voor het opslaan van productiegegevens.
    • Het opgegeven pad kan elke cloudopslaglocatie zijn die beschikbaar is voor de gebruiker die het schema maakt, inclusief cloud-URI's, DBFS-hoofd- en DBFS-koppelingen.
    • Toegang tot de locatie wordt niet beheerd door Hive-metastore.
    • Als u een schema verwijdert in de Hive-metastore, worden alle bestanden op die schemalocatie recursief verwijderd, ongeacht het tabeltype (beheerd of extern).

Om onbedoeld gegevensverlies te voorkomen, raadt Databricks het volgende aan wanneer u met Hive-metastoreschemalocaties werkt:

  • Wijs geen schemalocatie toe die al gegevens bevat.
  • Maak geen externe tabel op een schemalocatie.
  • Deel geen locatie tussen meerdere schema's.
  • Wijs geen schemalocatie toe die een andere schemalocatie overlapt. Met andere woorden, gebruik geen pad dat een onderliggend element van een andere schemalocatie is.
  • Wijs geen schemalocatie toe die de locatie van een externe tabel overlapt.

Beheerde tabellen in Hive-metastore

Beheerde tabellen in Hive-metastore hebben geen van de prestatievoordelen van beheerde tabellen in Unity Catalog. Net als beheerde tabellen in Unity Catalog maken beheerde Hive-metastore-tabellen standaard gebruik van Delta Lake. In hive-metastore, in tegenstelling tot Unity Catalog, kunt u echter ook een beheerde tabel maken met behulp van de meeste andere gegevensindelingen die worden ondersteund door Azure Databricks.

Beheerde tabellen in Hive-metastore worden altijd gemaakt op de opslaglocatie van het met het schema. De berekening die u gebruikt om een query uit te voeren op een beheerde tabel, moet toegang hebben tot de opslaglocatie.

De Hive-metastore beheert de gegevensindeling van beheerde tabellen niet zoals Unity Catalog dat doet. Wanneer u een beheerde tabel in hive-metastore verwijdert, worden alle onderliggende gegevensbestanden onmiddellijk verwijderd. In Unity Catalog kunt UNDROP u daarentegen 7 dagen lang een beheerde tabel maken en gegevens binnen 30 dagen definitief worden verwijderd.

U kunt op pad gebaseerde toegang gebruiken voor het lezen of schrijven van gegevens in beheerde Hive-metastore-tabellen, terwijl u in Unity Catalog dat niet kunt en niet hoeft te doen.

Externe tabellen in Hive-metastore

De meeste tabellen die in Azure Databricks zijn gemaakt voordat de introductie van Unity Catalog is geconfigureerd als externe tabellen in de Hive-metastore. Verouderde aanbevelingen die de voorkeur geven aan externe tabellen, zijn meestal gericht op een aantal belangrijke aspecten:

  • U kunt een externe tabel registreren boven op bestaande gegevens in de opslag van cloudobjecten.
  • U kunt rechtstreeks toegang krijgen tot gegevensbestanden in externe tabellen vanuit externe systemen voor lees- of schrijfbewerkingen.
  • Gegevensbestanden zijn niet verwijderd als de tabel per ongeluk is verwijderd.
  • Omdat voor externe tabellen een LOCATIONproductiegegevens nodig zijn, is de kans kleiner dat ze per ongeluk in de DBFS-hoofdmap terechtkomen.

Azure Databricks raadt nu beheerde tabellen van Unity Catalog aan voor de meeste tabellaire gegevensopslag. Zie Werken met beheerde tabellen.

Weergaven in Hive-metastore

U kunt een weergave declareren in hive-metastore die wordt ondersteund door elke gegevensbron die wordt ondersteund door Azure Databricks. In Unity Catalog kunt u alleen weergaven declareren voor Unity Catalog-tabellen en -weergaven, waaronder refererende tabellen, gerealiseerde weergaven en Delta Sharing-tabellen.

Vanwege de mogelijkheid om weergaven te declareren voor niet-tabellaire gegevensbronnen, kunnen weergaven in hive-metastore onverwachte of onbedoelde toegang krijgen tot gegevens in combinatie met andere toegangsconfiguraties in de gebruikersomgeving.

Denk bijvoorbeeld aan het volgende:

  • Er wordt een tabel my_table gedefinieerd met behulp van het DBFS-koppelingspad /mnt/my_table.
    • DBFS-koppelingsreferenties worden opgeslagen in de werkruimte, zodat alle gebruikers standaard toegang hebben tot dit pad.
  • Tabel-ACL's worden gebruikt om de toegang tot een groep gebruikers te my_table beperken.
    • Verouderde tabel-ACL's zijn alleen van toepassing op rekenprocessen die zijn geconfigureerd met de modus voor gedeelde toegang of SQL-warehouses.
  • Een weergave my_view wordt rechtstreeks gedefinieerd op basis van de cloud-URI die dezelfde gegevensbestanden 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'back-ups maakt.
    • URI-referenties zijn afhankelijk van toegangsbeleid dat is gedefinieerd in de Spark-sessie of rekenconfiguratie.

De weergave my_view heeft de volgende eigenschappen:

  • Er worden geen DBFS-koppelingsreferenties gebruikt voor het koppelen van cloudobjectopslag aan /mnt/my_table.
  • De tabel-ACL's die zijn ingesteld my_table, worden niet gerespecteerd, ongeacht de rekenconfiguraties.
  • Hiervoor is een beleid voor gegevenstoegang vereist dat is geconfigureerd voor berekeningen die leestoegang bieden tot 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'.

Notitie

Dit is een voorbeeld van onverwacht gedrag dat u kunt tegenkomen en niet volledig van alle mogelijke valkuilen die worden gepresenteerd door weergaven in de verouderde Hive-metastore. Databricks raadt het gebruik van Unity Catalog aan voor alle weergavedefinities.

Verouderde Hive-tabellen en HiveQL-ondersteuning

Azure Databricks bevat een aantal verouderde ondersteuning voor Hive-tabellen en HiveQL-functionaliteit. Deze functionaliteit is een overblijfsel van vroege versies van Azure Databricks en het Apache Hadoop-ecosysteem van hulpprogramma's. Databricks raadt het gebruik van Hive-tabellen of andere Hive-functionaliteit niet aan, omdat deze functionaliteit niet is geoptimaliseerd en geen ondersteuning biedt in sommige rekenconfiguraties.

In de volgende artikelen wordt de verouderde Hive-functionaliteit beschreven: