Datenbankobjekte im Legacy-Hive-Metastore

Die Dokumentation zu Azure Databricks konzentriert sich auf die Arbeit mit Datenobjekten mithilfe von Unity Catalog aber die meisten Anweisungen gelten auch für das Arbeiten mit Objekten, die im Legacy-Hive-Metastore registriert sind.

Dieser Artikel konzentriert sich auf die Arbeit mit Datenbankobjekten, die im Legacy-Hive-Metastore registriert sind. Insbesondere wird in diesem Artikel erläutert, inwiefern sich das Arbeiten mit Hive-Metastoreobjekten von der Arbeit mit Unity Catalog-Objekten unterscheidet. Außerdem werden andere Verhaltensweisen beschrieben, die möglicherweise unerwartet sind.

Databricks empfiehlt, alle Tabellen aus dem Legacy-Hive-Metastore zu Unity Catalog zu migrieren. Weitere Informationen finden Sie unter Upgrade von Hive-Tabellen und Sichten für Unity Catalog.

Wie funktioniert Hive-Metastore-Datengovernance?

Obwohl Azure Databricks-Arbeitsbereiche weiterhin den integrierten Hive-Metastore enthalten, ist die Datengovernance unter Verwendung des Hive-Metastores veraltet. Databricks empfiehlt die Verwendung von Unity Catalog für die Datengovernance. Weitere Informationen finden Sie unter Arbeiten mit Unity Catalog und dem Legacy-Hive-Metastore.

Durch das Aktivieren eines Arbeitsbereichs für Unity Catalog können Sie nicht mit Daten arbeiten, die bereits im Hive-Metastore registriert sind. Alle im Legacy-Hive-Metastore registrierten Datenobjekte werden in Unity Catalog-Schnittstellen im hive_metastore-Katalog angezeigt. Ein Hybrid-Hive-Metastore- und Unity Catalog-Arbeitsbereich kann ein nützliches Modell für den Übergang eines langjährigen Hive-Metastore-Arbeitsbereichs sein. Die Vorteile der Datengovernance und Leistung von Unity Catalog sind jedoch enorm, und Sie sollten Ihre Arbeitsbereiche so schnell wie möglich vollständig übertragen.

Der Hive-Metastore verwendet die Tabellenzugriffssteuerung (Tabellen-ACL), um den Zugriff auf Datenbankobjekte zu verwalten. Ein Teil der Unterstützung bleibt für die Tabellenzugriffssteuerung, wenn Sie die Berechnung im Modus für gemeinsam genutzten Zugriff verwenden. Siehe Hive-Metastore-Tabellenzugriffssteuerung (Legacy).

Passthrough für Anmeldeinformationen ist ein veraltetes Muster für die Datengovernance in Datenbankobjekten des Hive-Metastores. In diesem Artikel wird der Passthrough für Anmeldeinformationen nicht behandelt. Siehe Passthrough für Anmeldedaten (Legacy).

Was ist der hive_metastore-Katalog?

In einem Arbeitsbereich, der für Unity Catalog aktiviert ist, werden alle Schemas im Hive-Metastore als untergeordnete Elemente des hive_metastore-Katalogs im Namespace mit drei Ebenen von Unity Catalog angezeigt. Der Hive-Metastore verwendet keine Kataloge, und dieses Konstrukt stellt einen Einstiegspunkt für Tabellen im Legacy-Hive-Metastore für Benutzer von Unity Catalog bereit. Verwenden Sie die folgende Syntax, um Tabellen im Legacy-Hive-Metasstore abzufragen:

SELECT * FROM hive_metastore.schema_name.table_name

Schemas im Hive-Metastore

Im Legacy-Hive-Metastore ist ein Schema die höchste Ebene in der Datenobjekthierarchie.

Es gibt einige wichtige Unterschiede zwischen Unity Catalog und Hive-Metastore, darunter die folgenden:

• Sie können keine Schemas im Hive-Metastore mithilfe des Katalog-Explorers erstellen. Sie können Berechtigungen für Schemas anzeigen und bearbeiten.
• Im Hive-Metastore erstellte Schemas können nur alphanumerische ASCII-Zeichen und Unterstriche in ihren Namen verwenden.
• Mit dem Hive-Metastore können Sie ein LOCATION-Schema während der Erstellung deklarieren. Dies funktioniert ähnlich wie die verwalteten Speicherorte von Unity Catalog mit den folgenden Verhaltensunterschieden:
  • Wenn Sie keinen Speicherort angeben, wird der Standardspeicherort /user/hive/warehouse/<schema-name> verwendet. Dieser Speicherort befindet sich im DBFS-Stamm, der nicht zum Speichern von Produktionsdaten empfohlen wird.
  • Der bereitgestellte Pfad kann ein beliebiger Cloudspeicherort sein, der für den Benutzer verfügbar ist, der das Schema erstellt, einschließlich Cloud-URIs, DBFS-Stamm- und DBFS-Bereitstellungen.
  • Der Zugriff auf den Speicherort wird nicht vom Hive-Metastore verwaltet.
  • Das Löschen eines Schemas im Hive-Metastore verursacht, dass alle Dateien an diesem Schemaspeicherort rekursiv gelöscht werden, unabhängig vom Tabellentyp (verwaltet oder extern).

Um versehentlichen Datenverlust zu vermeiden, empfiehlt Databricks Folgendes, wenn Sie mit Hive-Metastore-Schemaspeicherorten arbeiten:

• Weisen Sie keinen Schemaspeicherort zu, der bereits Daten enthält.
• Erstellen Sie keine externe Tabelle an einem Schemaspeicherort.
• Verwenden Sie keinen Speicherort für mehrere Schemas.
• Weisen Sie keinen Schemaspeicherort zu, der mit einem anderen Schemaspeicherort überlappt. Verwenden Sie also keinen Pfad, der ein untergeordnetes Element eines anderen Schemaspeicherorts ist.
• Weisen Sie keinen Schemaspeicherort zu, der mit der Position einer externen Tabelle überlappt.

Verwaltete Tabellen im Hive-Metastore

Verwaltete Tabellen im Hive-Metastore weisen keine der Leistungsvorteile verwalteter Tabellen in Unity Catalog auf. Wie bei verwalteten Tabellen in Unity Catalog verwenden verwaltete Hive-Metastore-Tabellen standardmäßig Delta Lake. Im Hive-Metastore können Sie im Gegensatz zu Unity Catalog auch eine verwaltete Tabelle mit den meisten anderen Datenformaten erstellen, die von Azure Databricks unterstützt werden.

Verwaltete Tabellen im Hive-Metastore werden immer am Speicherort des enthaltenden Schemas erstellt. Die Berechnung, die Sie zum Abfragen einer verwalteten Tabelle verwenden, muss Zugriff auf den Speicherort haben.

Der Hive-Metastore verwaltet das Datenlayout verwalteter Tabellen nicht wie Unity Catalog. Wenn Sie eine verwaltete Tabelle im Hive-Metastore ablegen, werden alle zugrunde liegenden Datendateien sofort gelöscht. In Unity Catalog können Sie dagegen eine verwaltete Tabelle 7 Tage lang UNDROP, und Daten werden innerhalb von 30 Tagen endgültig gelöscht.

Sie können pfadbasierten Zugriff verwenden, um Daten in verwalteten Tabellen des Hive-Metastores zu lesen oder zu schreiben, während Sie in Unity Catalog keine Daten lesen oder schreiben müssen.

Externe Tabellen im Hive-Metastore

Die meisten Tabellen, die in Azure Databricks erstellt wurden, bevor die Einführung von Unity Catalog als externe Tabellen im Hive-Metastore konfiguriert wurde. Legacyempfehlungen, bei denen externe Tabellen bevorzugt wurden, konzentrierten sich in der Regel auf einige wichtige Aspekte:

• Sie können eine externe Tabelle über vorhandenen Daten im Cloudobjektspeicher registrieren.
• Sie können direkt auf Datendateien in externen Tabellen aus externen Systemen zugreifen, um Lese- oder Schreibvorgänge zu erhalten.
• Datendateien wurden nicht gelöscht, wenn die Tabelle versehentlich gelöscht wurde.
• Da für externe Tabellen ein LOCATION erforderlich ist, war die Wahrscheinlichkeit geringer, dass Produktionsdaten versehentlich im DBFS-Stammverzeichnis gespeichert werden.

Azure Databricks empfiehlt jetzt verwaltete Unity Catalog-Tabellen für die meisten Tabellendatenspeicher. Weitere Informationen finden Sie unter Arbeiten mit verwaltetern Tabellen.

Sichten im Hive-Metastore

Sie können eine Ansicht im Hive-Metasstore deklarieren, die von jeder Datenquelle unterstützt wird, die von Azure Databricks unterstützt wird. In Unity Catalog können Sie Ansichten nur für Unity Catalog-Tabellen und -ansichten deklarieren, einschließlich Fremdtabellen, materialisierter Sichten und Delta-Freigabetabellen.

Aufgrund der Möglichkeit, Sichten für nicht tabellarische Datenquellen zu deklarieren, können Sichten im Hive-Metastore unerwarteten oder unbeabsichtigten Zugriff auf Daten in Kombination mit anderen Zugriffskonfigurationen in der Benutzerumgebung gewähren.

Berücksichtigen Sie beispielsweise Folgendes:

• Eine Tabelle my_table wird mithilfe des DBFS-Bereitstellungspfads /mnt/my_table definiert.
  • DBFS-Bereitstellungsanmeldeinformationen werden im Arbeitsbereich gespeichert, sodass alle Benutzer standardmäßig Zugriff auf diesen Pfad haben.
• Tabellen-ACLs werden verwendet, um den Zugriff auf my_table für eine Gruppe von Benutzern einzuschränken.
  • Legacy-Tabellen-ACLs gelten nur für Compute, das mit dem Modus für gemeinsam genutzte Zugriffe oder SQL-Warehouses konfiguriert wurde.
• Eine Sicht my_view wird direkt für den Cloud-URI definiert, der die gleichen Datendateien 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table' sichert.
  • URI-Anmeldeinformationen basieren auf Zugriffsrichtlinien, die in der Spark-Sitzung oder Computekonfiguration definiert sind.

Die Sicht my_view verfügt über folgende Eigenschaften:

• Sie verwendet nicht die DBFS-Bereitstellungsanmeldeinformationen, die zum Bereitstellen des Cloudobjektspeichers in /mnt/my_table verwendet werden.
• Unabhängig von den Computekonfigurationen werden die für my_table festgelegten Tabelle-ACLs nicht berücksichtigt.
• Es ist einee Datenzugriffsrichtlinie erforderlich, die für das Compute konfiguriert ist, das Lesezugriff auf 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table' hat.

Legacy-Hive-Tabellen und HiveQL-Unterstützung

Azure Databricks enthält Vorversionsunterstützung für Hive-Tabellen und HiveQL-Funktionen. Diese Funktionalität ist ein Relikt von früheren Versionen von Azure Databricks und dem Apache Hadoop-Ökosystem von Tools. Databricks empfiehlt nicht die Verwendung von Hive-Tabellen oder anderen Hive-Funktionen, da diese Funktionalität nicht optimiert ist und in einigen Computekonfigurationen keine Unterstützung bietet.

In den folgenden Artikeln werden ältere Hive-Funktionen beschrieben:

• Apache Hive-Kompatibilität
• CREATE TABLE im Hive-Format
• INSERT OVERWRITE DIRECTORY mit Hive-Format
• LOAD DATA
• Integration in Hive-UDFs, -UDAFs und -UDTFs