Konvertieren externer oder fremder Delta Lake-Tabellen in verwaltete Tabellen im Unity-Katalog

Important

Das Konvertieren einer externen Tabelle in eine verwaltete Tabelle ist allgemein verfügbar.

Das Konvertieren einer Fremdtabelle in eine verwaltete Tabelle befindet sich in der öffentlichen Vorschau. Nur mit Hive metastore und Glue Federation föderierte Fremdtabellen werden unterstützt.

Um eine externe oder fremde Delta Lake-Tabelle in eine verwaltete Unity-Katalog-Tabelle in Azure Databricks zu konvertieren, verwenden Sie den ALTER TABLE ... SET MANAGED Befehl oder für externe Tabellen, Katalog-Explorer. Die Konvertierung behält Tabellenkonfigurationen, einschließlich Name, Einstellungen, Berechtigungen und Ansichten, und behält den Tabellenverlauf bei.

Für externe Tabellenkonvertierungen SET MANAGED auch:

• Minimiert die Ausfallzeit von Lesern und Autoren.
• Behandelt gleichzeitige Schreibvorgänge während der Konvertierung.
• Ermöglicht das Zurücksetzen einer konvertierten verwalteten Tabelle auf eine externe Tabelle.
• Leitet pfadbasierte Lese- und Schreibvorgänge um, damit Legacycode nach der Konvertierung funktioniert.

Obwohl Sie auch CREATE TABLE AS SELECT (CTAS) zum Konvertieren einer externen Tabelle verwenden können, empfiehlt Databricks SET MANAGED aufgrund dieser Vorteile.

Bei Konvertierungen von Fremdtabellen setzt Databricks die prädiktive Optimierung für die konvertierte Tabelle auf INHERIT, anstatt sie automatisch zu aktivieren. Siehe Fremdtabellen mit SQL.

Informationen zum Konvertieren fremder Tabellen in externe Tabellen finden Sie unter Konvertieren einer Fremdtabelle in eine externe Unity-Katalogtabelle.

Voraussetzungen

Die Voraussetzungen unterscheiden sich je nachdem, ob Sie eine externe Tabelle oder eine Fremdtabelle konvertieren.

Externe Tabellen

Das Konvertieren externer Tabellen in verwaltete Tabellen hat die folgenden Voraussetzungen:

• Format: Die Tabelle muss das Delta Lake-Format verwenden.
• Runtime: Sie müssen Databricks Runtime 17.3 LTS oder höher oder serverloses Compute verwenden, um SET MANAGED, UNSET MANAGED oder TRUNCATE UNIFORM HISTORY zu verwenden.
• Leser und Autoren: Azure Databricks Leser und Autoren für Ihre Quelltabellen müssen Databricks Runtime 15.4 LTS oder höher verwenden. Wenn Ihre Leser oder Autoren 14.3 LTS oder niedriger verwenden, siehe Legacy-Leser und -Autoren.
• Externe Clients: Externe (nicht zu Databricks gehörende) Clients müssen Lesezugriffe auf von Unity Catalog verwaltete Tabellen unterstützen. Siehe Zugriffstabellen mit Delta-Clients.
  • Verwenden Sie das Access Insights-Dashboard , um festzustellen, ob Leser und Autoren, die auf Ihre Tabellen zugreifen, Databricks Runtime oder externe Nicht-Databricks sind.
• Feature-Kompatibilität: Wenn Ihre Tabelle minReaderVersion=2, minWriterVersion=7 und tableFeatures={..., columnMapping} aufweist, schlägt der Befehl SET MANAGED mit dem Fehler DELTA_TRUNCATED_TRANSACTION_LOG fehl. Überprüfen Sie mithilfe von DESCRIBE DETAIL, ob Ihre Tabelle diese Eigenschaften aufweist. Siehe Delta Lake Featurekompatibilität und Protokolle.

Nach der Konvertierung werden pfadbasierte Lese- und Schreibvorgänge automatisch an den neuen verwalteten Speicherort mit geringem Leistungsaufwand umgeleitet. Databricks empfiehlt, den gesamten pfadbasierten Zugriff auf den namenbasierten Zugriff zu migrieren, um den Leistungsaufwand zu vermeiden. Siehe pfadbasierte Umleitung.

Important

Um Konflikte zu vermeiden, brechen Sie alle vorhandenen OPTIMIZE Befehlsjobs (Liquid Clustering, Komprimierung, ZORDER) ab, die für Ihre externe Tabelle ausgeführt werden, und planen Sie keine Jobs, während Sie Ihre externen Tabellen in verwaltete Tabellen umwandeln.

Fremdtabellen

Important

Das Konvertieren einer Fremdtabelle in eine verwaltete Tabelle befindet sich in der öffentlichen Vorschau.

Das Konvertieren von Fremdtabellen in verwaltete Tabellen hat die folgenden Voraussetzungen:

• Datenformat: Die Fremdtabelle muss das Delta Lake-Format verwenden. Um eine einmalige Konvertierung für Parquet auszuführen, sehen Sie Convert to Delta Lake.
• Laufzeit: Databricks Runtime 17.3 oder höher.
• Tabellentyp: Der Tabellentyp der Hive-Metastore-Tabelle muss eine externe HMS-Tabelle sein. Der Befehl schlägt fehl, wenn die Tabelle eine verwaltete HMS-Tabelle ist.
• Berechtigungen: OWNER- oder MANAGE-Berechtigungen für die Tabelle und die CREATE-Berechtigung für EXTERNAL LOCATION.

Ausfallzeiten und Datenkopiezeiten

Der Befehl SET MANAGED verringert oder vermeidet Ausfallzeiten im Vergleich zu alternativen Ansätzen, beispielsweise DEEP CLONE.

Externe Tabellen

Der Konvertierungsprozess für externe Tabellen verwendet einen zweistufigen Ansatz:

1. Ursprüngliche Datenkopie (keine Ausfallzeiten): Der Befehl kopiert Tabellendaten und Delta-Transaktionsprotokoll vom externen Speicherort an den verwalteten Speicherort. Aktive Lese- und Schreibvorgänge auf die externe Tabelle werden ohne Unterbrechung weiter ausgeführt.
2. Zu verwaltetem Speicherort wechseln (kurze Ausfallzeit): Commits, die während des ersten Schritts am externen Speicherort vorgenommen werden, werden in den verwalteten Speicherort verschoben, und die Tabellenmetadaten werden aktualisiert, um den neuen verwalteten Speicherort einzutragen. Während dieses Schritts werden alle Schreibvorgänge an den externen Speicherort vorübergehend blockiert, was zu Ausfallzeiten des Autors führt. Leser mit Databricks Runtime 16.4 LTS oder höher haben keine Ausfallzeiten, aber Leser mit Databricks Runtime 15.4 LTS und älter könnten Ausfallzeiten erleben.

Die folgende Tabelle zeigt geschätzte Ausfallzeiten basierend auf der Größe der Quelltabelle und einer geschätzten Durchsatzrate von 0,5-2 GB/CPU-Kern/Minute:

Tabellengröße	Empfohlene Clustergröße	Geschätzte Datenkopiezeit	Geschätzte Lese- und Schreibausfallzeit
100 GB oder weniger	32-Kern / X-Large SQL-Warehouse	~6 Min. oder weniger	~1-2 Min. oder weniger
1 TB (Terabyte)	64-Core / 2X-Large SQL Warehouse	~30 Min.	~1-2 Min.
10 TB	256-core / 4X-Groß SQL-Lagerhaus	~1,5 Stunden	~1-5 Min.

Note

Ausfallzeiten können je nach Faktoren wie Dateigröße, Anzahl von Dateien und Anzahl von Commits variieren.

Fremdtabellen

Ausfallzeiten bei der Konvertierung von Fremdtabellen hängen davon ab, ob Sie folgendes verwenden MOVE oder COPY:

• Bei MOVE kann es wie für externe Tabellen beschrieben zu Ausfallzeiten kommen. Siehe externe Tabellen.
• Für COPY sind Sie für die Ausfallzeiten verantwortlich, da der Konvertierungsprozess die Quelltabelle an den verwalteten Speicherort kopiert und dadurch zwei separate Kopien der Daten erstellt. Sie sind dafür verantwortlich, Lese- und Schreibvorgänge in die Quelltabelle im externen Katalog zu deaktivieren und Arbeitslasten zur Verwendung der neuen verwalteten Tabelle zu migrieren.

In eine verwaltete Tabelle konvertieren

Konvertieren Sie eine externe Tabelle mit Dem Katalog-Explorer oder SQL, oder konvertieren Sie eine Fremdtabelle mit SQL.

Externe Tabellen mit dem Katalog-Explorer (Beta)

Important

Das Konvertieren externer zu verwalteten Tabellen mithilfe des Katalog-Explorers befindet sich in der Betaversion.

Mithilfe des Katalog-Explorers können Sie jeweils eine oder mehrere externe Tabellen in einem Schema konvertieren.

1. Wechseln Sie zu der Tabelle oder dem Schema, die Sie im Katalog-Explorer konvertieren möchten.

2. Klicken Sie unter "Über diese Tabelle " (Tabellendetailseite) oder " Über dieses Schema " (Schemadetailseite) auf "Optimierungen erkunden".

3. Klicken Sie im Dialogfeld "Warum zu verwalteten Tabellen im Unity-Katalog migrieren" auf "Weiter".

   

4. Wählen Sie die externen Tabellen aus, die Sie konvertieren möchten. Wenn Sie das Dialogfeld über eine Tabellendetailseite geöffnet haben, wählt der Katalog-Explorer Ihre Tabelle vor. Verwenden Sie die Suchleiste, um weitere Tabellen zu finden. Verwaltete Tabellen können nicht ausgewählt werden.

   

5. Klicken Sie auf " Konvertierungsnotizbuch erstellen".

6. Geben Sie optional einen Namen für das Notizbuch ein. Dadurch wird das Notizbuch standardmäßig in Ihrem Startordner gespeichert. Klicken Sie auf "Durchsuchen ", um sie an einem anderen Speicherort zu speichern.

   

7. Überprüfen Sie im Notizbuch die bewährten Methoden, und stellen Sie sicher, dass Sie alle Voraussetzungen erfüllen.

8. Führen Sie die SET Zelle verwalteter Abfragen aus.

Nachdem die Zelle ausgeführt wurde, wird der Tabellentyp im Katalog-Explorer als VERWALTET anstelle von "EXTERN " angezeigt. Aktualisieren Sie die Seite, wenn der Status nicht sofort aktualisiert wird.

Externe Tabellen mit SQL

Je nachdem, ob Ihre externe Tabelle Apache Iceberg -Lesevorgänge (UniForm) aktiviert hat, führen Sie einen der folgenden Befehle aus. Um zu überprüfen, ob für Ihre Tabelle Iceberg-Lesevorgänge aktiviert sind, siehe Überprüfen, ob Iceberg-Lesevorgänge aktiviert sind.

• Führen Sie für externe Tabellen in Unity Catalog, für die Iceberg-Lesezugriffe nicht aktiviert sind, den folgenden Befehl aus:

  ALTER TABLE catalog.schema.my_external_table SET MANAGED;
  

  Nach der Konvertierung können Sie Iceberg-Lesevorgänge in Ihrer verwalteten Tabelle ohne Kompatibilitätsprobleme aktivieren.

• Führen Sie für externe Tabellen im Unity-Katalog mit bereits aktivierten Iceberg-Lesevorgängen den folgenden Befehl aus:

  ALTER TABLE catalog.schema.my_external_table SET MANAGED TRUNCATE UNIFORM HISTORY;
  

  Fügen Sie TRUNCATE UNIFORM HISTORY ein, um die optimale Leistung und Kompatibilität von Tabellen aufrechtzuerhalten. TRUNCATE UNIFORM HISTORY schneidet nur die Geschichte von UniForm Iceberg ab und entfernt die Delta-Geschichte nicht. Dieser Befehl führt nach der Verkürzung zu einer kurzen Lese- und Schreibausfallzeit für Iceberg.

Nach der Tabellenkonvertierung schlagen vorhandene Lese- und Schreibdatenströme fehl. Starten Sie Datenströme mit den gleichen Konfigurationen neu, um die pfadbasierte Umleitung automatisch zu verwenden. Überprüfen Sie, ob Ihre Leser und Autoren mit der verwalteten Tabelle arbeiten. Siehe Streamingverhalten.

Die Predictive Optimization wird nach der Konvertierung automatisch aktiviert, es sei denn, Sie haben sie manuell deaktiviert. Überprüfen Sie, ob die Vorhersageoptimierung aktiviert ist.

Azure Databricks die Daten an Ihrem externen Speicherort des Unity-Katalogs 14 Tage aufbewahrt, um ein Rollback zu ermöglichen. Siehe Zurücksetzen der Konvertierung einer verwalteten Tabelle. Nach 14 Tagen, mit aktivierter Vorhersageoptimierung, Azure Databricks diese Daten automatisch löscht, um Speicher zurückzufordern und Kosten zu sparen. Wenn Sie die prädiktive Optimierung deaktivieren, führen Sie nach 14 Tagen VACUUM für die neu konvertierte verwaltete Tabelle aus (erfordert Databricks Runtime 17.3 LTS oder höher oder Serverless Compute), um den Speicherplatz selbst freizugeben.

VACUUM my_converted_table

Note

Auch wenn die Vorhersageoptimierung aktiviert ist, werden Die Daten am externen Speicherort Ihres Unity-Katalogs nach 14 Tagen möglicherweise nicht gelöscht. Dies kann beispielsweise auftreten, wenn die verwaltete Tabelle selten oder klein ist. Wenn die vorherigen Daten noch vorhanden sind, führen Sie VACUUM manuell aus, um diese zu entfernen.

Azure Databricks löscht nur die Daten am externen Speicherort. Das Delta-Transaktionsprotokoll und der Verweis auf die Tabelle im Unity-Katalog werden beibehalten.

Fremdtabellen mit SQL

Important

Das Konvertieren einer Fremdtabelle in eine verwaltete Tabelle befindet sich in der öffentlichen Vorschau.

Führen Sie den folgenden Befehl aus, um ihre Fremdtabelle im Unity-Katalog in eine verwaltete Unity-Katalogtabelle zu konvertieren:

ALTER TABLE source_table SET MANAGED {MOVE | COPY}

• source_table

  Eine vorhandene Fremdtabelle, die im Unity Catalog federiert ist.

• MOVE

  Konvertiert die Tabelle in eine verwaltete Tabelle und deaktiviert den Zugriff auf die Quelltabelle des externen Katalogs.

  • Der Zugriff über den externen Katalog oder pfadbasierten Zugriff schlägt fehl, nachdem Sie die Tabelle konvertiert haben. Alle Leser und Autoren in der Tabelle müssen den Unity Catalog-Namespace für den Zugriff verwenden. Beispiel:

    SELECT * FROM catalog_name.schema_name.table_name;
    

  • Der pfadbasierte Zugriff wird nicht unterstützt und schlägt fehl, nachdem Sie die Tabelle konvertiert haben. Beispiel:

    SELECT * FROM delta.`protocol://path/to/table`;
    

  • Die Anforderungen an die Reader-/Writer-Version und die Client-Kompatibilität entsprechen den in Voraussetzungen und Legacy-Reader und -Writer beschriebenen.

  • Die Vorhersageoptimierung wird auf INHERIT gesetzt, es sei denn, Sie haben sie manuell konfiguriert. Um zu überprüfen, ob die Vorhersageoptimierung aktiviert ist, sehen Sie nach, ob die Vorhersageoptimierung aktiviert ist.

• COPY

  Konvertiert die Tabelle in verwaltet, ohne den Zugriff auf die Quelltabelle im externen Katalog zu ändern oder zu deaktivieren.

  • Während der Konvertierung in "verwaltet" kopiert der Konvertierungsprozess Daten aus der Quelltabelle in den für die Fremdtabelle definierten verwalteten Speicherort, wobei zwei separate Kopien erstellt werden: die neue verwaltete Tabelle und die Quelltabelle im externen Katalog.
  • Im Gegensatz zu MOVE, wo Lese- und Schreibvorgänge fehlschlagen, sind Sie bei der Verwendung von COPY dafür verantwortlich, Lese- und Schreibvorgänge ordnungsgemäß für die Quelltabelle im externen Katalog zu deaktivieren und sicherzustellen, dass Workloads in den neuen Katalog migriert wurden.

Nach der Tabellenkonvertierung müssen Sie alle Streamingaufträge (Lesen oder Schreiben) mithilfe der Fremdtabelle neu starten und überprüfen, ob Ihre Leser und Autoren mit der verwalteten Tabelle arbeiten.

Wenn Sie vor der Konvertierung die Quelltabelle im externen Katalog ablegen, legt Unity Catalog auch die Fremdtabelle ab. Nachdem Sie die Tabelle in eine verwaltete Tabelle umgewandelt haben, wirkt sich das Löschen der Quelltabelle im externen Katalog nicht auf die von Unity Catalog verwaltete Tabelle aus.

Wenn der Befehl beim Kopieren von Daten unterbrochen wird, starten Sie ihn neu. Der Befehl wird an der Stelle fortgesetzt, an der er aufgehört hat.

Warning

Databricks empfiehlt, mehrere SET MANAGED-Befehle nicht gleichzeitig auf derselben Tabelle auszuführen, da dies zu einem inkonsistenten Tabellenzustand führen kann.

Überprüfen der Konvertierung

Überprüfen Sie, ob die Tabelle Type erfolgreich in eine verwaltete Tabelle konvertiert wurde MANAGED. Sie können eine der folgenden Aktionen ausführen:

• Öffnen Sie eine neue Registerkarte, und wechseln Sie zum Katalog-Explorer. Auf der Registerkarte "Details " unter " Über diese Tabelle" wird der Tabellentyp als verwaltet angezeigt.

• Überprüfen Sie die Tabelle Type , indem Sie den folgenden SQL-Befehl ausführen:

  DESCRIBE EXTENDED catalog_name.schema_name.table_name
  

  Um mehrere Tabellen gleichzeitig zu überprüfen oder die Überprüfung zu skripten, fragen information_schema.tables Sie stattdessen Folgendes ab:

  SELECT table_type FROM system.information_schema.tables
  WHERE table_catalog = 'catalog_name' AND table_schema = 'schema_name' AND table_name = 'table_name';
  

Legacy-Leser und -Schreiber

Databricks empfiehlt, alle Reader und Writer auf Databricks Runtime 15.4 LTS oder höher zu aktualisieren, um den vollen Funktionsumfang von SET MANAGED zu nutzen, einschließlich der Aufbewahrung des Tabellenverlaufs.

Sie können weiterhin verwenden SET MANAGED , wenn Sie Leser oder Autoren auf Databricks Runtime 15.3 oder darunter haben. Nach der Konvertierung in eine verwaltete Tabelle können Sie jedoch nur per Version und nicht per Zeitstempel eine Zeitreise zu historischen Commits durchführen.

Wenn Sie innerhalb von 14 Tagen auf eine externe Tabelle zurückgreifen, wird die Möglichkeit, zu früheren Commits vor der Konvertierung zurückzukehren, wieder aktiviert. Zeitreisen mit Zeitstempeln werden für Commits, die an der konvertierten verwalteten Tabelle zwischen Konvertierung und Rollback vorgenommen wurden, nicht unterstützt. Siehe Zurücksetzen der Konvertierung einer verwalteten Tabelle.

Das Schreiben in eine Tabelle nach der Konvertierung mit Databricks Runtime 15.3 oder niedriger erfordert das Entfernen des Features inCommitTimestamp:

ALTER TABLE <table_name> DROP FEATURE inCommitTimestamp;

Pfadbasierte Umleitung

Nachdem Sie in Databricks Runtime 18.1 und höher eine externe Tabelle in eine verwaltete Unity-Katalog-Tabelle konvertiert haben, werden pfadbasierte Lese- und Schreibvorgänge an den vorherigen externen Speicherort automatisch an den neuen verwalteten Speicherort umgeleitet. Ein pfadbasierter Lesevorgang ist ein Code wie SELECT * FROM delta.`/path/to/my_table`. Die pfadbasierte Weiterleitung reduziert den Zeit- und Arbeitsaufwand für die Migration zu verwalteten Tabellen, da Legacy-Code, der Speicherpfade verwendet, ohne Refactoring weiterhin funktioniert.

Konvertierungen von Fremdtabellen lenken den pfadbasierten Zugriff nicht um.

Bei Anwendungsfällen mit geringer Latenz empfiehlt Azure Databricks, pfadbasierten Zugriff auf namenbasierten Zugriff zu migrieren. Pfadbasierte Umleitung fügt mehrere hundert Millisekunden Mehraufwand für jeden pfadbasierten Lese- oder Schreibzugriff hinzu und erfordert, dass alte Delta-Protokolle am externen Speicherort des Unity-Katalogs aktiv bleiben. Namebasierte Lese- und Schreibvorgänge haben keinen zusätzlichen Leistungsaufwand. Siehe Migrieren von pfadbasiertem Code zu namebasiert.

Migrieren von pfadbasiertem Code zu namebasiert

Wenn Sie sich gegen die Verwendung einer pfadbasierten Weiterleitung entscheiden, können Sie Legacy-Code migrieren. Ersetzen Sie zum Migrieren pfadbasierte Verweise durch namenbasierte Verweise.

Das folgende Codebeispiel enthält einen pfadbasierten Tabellenverweis auf Dateien:

SELECT * FROM delta.`/path/to/customers_table`;

Ersetzen Sie den pfadbasierten Verweis durch einen namenbasierten Verweis auf eine externe Tabelle, wie im folgenden Code dargestellt:

SELECT * FROM catalog_name.schema_name.customers_table;

Streamingverhalten

Streaming mit pfadbasierter Umleitung unterstützt Lese- und Schreibvorgänge in den folgenden Databricks-Runtime-Versionen:

• Lesevorgänge werden in Databricks Runtime 18.1 und höher unterstützt.
• Schreibvorgänge werden in Databricks Runtime 18.2 und höher unterstützt.

Nach der Konvertierung müssen Sie alle Streamingeinzelvorgänge neu starten, um das Lesen oder Schreiben an den vorherigen Tabellenspeicherort zu vermeiden.

Pfadbasierte Streaminglesevorgänge und -schreibvorgänge schlagen fehl und beenden den nächsten Prüfpunkt mit einer Migrationsnachricht:

• Bei Lesevorgängen löst der Datenstrom einen Fehler aus: DELTA_STREAMING_INTERRUPTED_BY_MANAGED_TABLE_CONVERSION: The table at <path> has been converted to a Unity Catalog managed table. The stream has been stopped to ensure data consistency. Restart the stream and it will automatically resume from the last committed offset using the converted table.
• Bei Schreibvorgängen löst der erste Mikrobatch nach der Konvertierung einen Fehler aus: Operation not allowed: STREAMING WRITE cannot be performed on a table with redirect feature. The no redirect rules are not satisfied [].

Um Fehler zu beheben, starten Sie Datenströme mit den gleichen Konfigurationen neu. Der pfadbasierte Zugriff wird automatisch an die verwaltete Tabelle umgeleitet.

Informationen zu pfadbasierten Umleitungseinschränkungen finden Sie unter "Einschränkungen".

Problembehandlung bei Konvertierungsfehlern

In diesem Abschnitt wird beschrieben, wie häufige Probleme bei der Konvertierung externer Tabellen in von Unity Catalog verwaltete Tabellen mithilfe von SET MANAGED behoben werden.

VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED

Wenn die Konvertierung fehlschlägt, versuchen Sie immer, dieselbe Databricks-Runtime-Version zu verwenden. Metadaten können in allen Versionen unterschiedlich serialisiert werden, was zu einem VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED Fehler führt, wenn Sie eine Konvertierung in einer anderen Databricks-Runtime-Version wiederholen.

Cluster-Abschaltung während der Konvertierung

Wenn Ihr Cluster während der Konvertierung heruntergefahren wird, kann der Befehl möglicherweise fehlschlagen mit DELTA_ALTER_TABLE_SET_MANAGED_INTERNAL_ERROR. Wiederholen Sie den Befehl, um die Konvertierung fortzusetzen.

Beschädigte externe Tabelle

Wenn die externe Tabelle bereits beschädigt ist (z. B. ungültiger Tabellenzustand), schlägt die Konvertierung möglicherweise mit Fehlern wie DELTA_TRUNCATED_TRANSACTION_LOG, DELTA_TXN_LOG_FAILED_INTEGRITY oder DELTA_STATE_RECOVER_ERRORS fehl. Stellen Sie vor dem Versuch der Konvertierung sicher, dass Sie grundlegende Vorgänge für die externe Tabelle ausführen können, z. B. DESCRIBE DETAIL.

Dateiüberprüfungsfehler

Der SET MANAGED Befehl überprüft, ob alle Dateien in der neuesten Momentaufnahme der Tabelle in den neuen Speicherort der verwalteten Tabelle kopiert wurden. Wenn Dateien fehlen, schlägt der Befehl mit einem DELTA_ALTER_TABLE_SET_MANAGED_FAILED.FILE_VALIDATION_FAILED Fehler fehl.

So lösen Sie das Problem:

1. Überprüfen Sie die Spark-Treiberprotokolle, um zu ermitteln, welche Dateien nicht migriert werden konnten.
2. Stellen Sie sicher, dass diese Dateien am Speicherort der externen Quelltabelle vorhanden sind und darauf zugegriffen werden kann.
3. Wiederholen Sie den ALTER TABLE ... SET MANAGED Befehl.

Wenn das Problem weiterhin besteht, wenden Sie sich an den Databricks-Support.

Zurücksetzen einer Verwalteten Tabellenkonvertierung

Important

Rollback-Befehle erfordern Serverless Compute oder Databricks Runtime 17.3 LTS oder höher.

Externe Tabelle

Nachdem Sie eine externe Tabelle in eine verwaltete Tabelle konvertiert haben, können Sie einen Rollback innerhalb von 14 Tagen mithilfe des UNSET MANAGED Befehls ausführen. Dadurch werden die Tabellenmetadaten so aktualisiert, dass sie auf den ursprünglichen externen Speicherort verweisen. Databricks behält alle Schreibvorgänge am verwalteten Speicherort nach der Konvertierung bei.

Führen Sie zum Zurücksetzen auf eine externe Tabelle den folgenden Befehl aus:

ALTER TABLE catalog.schema.my_managed_table UNSET MANAGED;

Beachten Sie Folgendes:

• Wenn der Rollback-Befehl unterbrochen wird oder fehlschlägt, führen Sie ihn erneut aus, um den Vorgang zu wiederholen.
• Sie müssen Ihre Streamingeinzelvorgänge nach dem Zurücksetzen neu starten, ähnlich wie bei der Konvertierung.
• Commits, die zwischen der Konvertierung und dem Rollback am verwalteten Speicherort vorgenommen wurden, ermöglichen eine Zeitreise anhand der Version, jedoch nicht anhand eines Zeitstempels.
• Sieben Tage nach dem Rollback löscht Azure Databricks automatisch Daten am verwalteten Speicherort.

Externe Tabelle: MOVE

Warning

Sie MÜSSEN UNSET MANAGED ausführen, bevor Sie die verwaltete Tabelle löschen. Das Löschen der Tabelle, ohne UNSET MANAGED zuerst auszuführen, kann zu Datenverlust oder Inkonsistenzen führen.

Sie können die Tabellenmigration zurücksetzen und mithilfe des UNSET MANAGED Befehls wieder auf die Quelltabelle im externen Katalog zugreifen. Ein Rollback erfordert zwei Schritte: Zunächst müssen Sie die Tabelle in eine externe Tabelle zurückführen und anschließend die externe Tabelle löschen, um die Tabelle erneut als Fremdtabelle zu föderieren.

1. Führen Sie zum Zurücksetzen auf eine externe Tabelle den folgenden Befehl aus:

ALTER TABLE catalog.schema.my_managed_table UNSET MANAGED

1. Um die Tabelle erneut mit einer Fremdtabelle zu verknüpfen, löschen Sie die externe Tabelle mit dem folgenden Befehl:

DROP TABLE catalog.schema.my_managed_table

Die Fremdtabelle ist nach der nächsten Katalogsynchronisierung verfügbar.

Beachten Sie Folgendes:

• Bei Commits, die Sie zwischen der Konvertierung und dem Rollback am externen Speicherort vorgenommen haben, können Sie sie zwar nach Version, jedoch nicht nach Zeitstempel rückverfolgen.
• Sieben Tage nach dem Rollback löscht Databricks Daten am verwalteten Speicherort.

Externe Tabelle: COPY

Zum Zurücksetzen der Tabellenmigration müssen Sie den UNSET MANAGED Befehl nicht ausführen, da die Quelltabelle im externen Katalog nicht geändert wurde. Löschen Sie die verwaltete Tabelle, und Databricks bindet sie nach der nächsten Katalogsynchronisierung erneut als Fremdtabelle ein.

Überprüfen des Rollbacks

Überprüfen Sie Rollbacks für externe und fremde Tabellen unterschiedlich.

Externe Tabellen

Um zu überprüfen, ob Ihre verwaltete Tabelle erfolgreich in eine externe Tabelle zurückgesetzt wurde, prüfen Sie, ob die Tabelle TypeEXTERNAL ist. Sie können eine der folgenden Aktionen ausführen:

• Öffnen Sie eine neue Registerkarte, und wechseln Sie zum Katalog-Explorer. Auf der Registerkarte "Details " unter " Über diese Tabelle" wird der Tabellentyp als "Extern" angezeigt.

• Überprüfen Sie die Tabelle Type , indem Sie den folgenden SQL-Befehl ausführen:

  DESCRIBE EXTENDED catalog_name.schema_name.table_name
  

  Um mehrere Tabellen gleichzeitig zu überprüfen oder die Überprüfung zu skripten, fragen information_schema.tables Sie stattdessen Folgendes ab:

  SELECT table_type FROM system.information_schema.tables
  WHERE table_catalog = 'catalog_name' AND table_schema = 'schema_name' AND table_name = 'table_name';
  

Fremdtabellen

Um zu überprüfen, ob Ihre verwaltete Tabelle erfolgreich in eine Fremdtabelle zurückgerollt wurde, prüfen Sie, ob die Tabelle TypeFOREIGN ist. Sie können eine der folgenden Aktionen ausführen:

• Öffnen Sie eine neue Registerkarte, und wechseln Sie zum Katalog-Explorer. Auf der Registerkarte "Details " unter " Über diese Tabelle" wird der Tabellentyp als "Fremd" angezeigt.

• Überprüfen Sie den Tabellentyp, indem Sie den folgenden SQL-Befehl ausführen:

  SELECT table_type FROM system.information_schema.tables
  WHERE table_catalog = 'catalog_name' AND table_schema = 'schema_name' AND table_name = 'table_name';
  

  Die table_type Spalte wird als FOREIGN angezeigt.

Note

Verwenden Sie DESCRIBE EXTENDED nicht, um Konvertierungen von Fremdtabellen oder Rollbacks zu überprüfen. Federation verwendet für diesen Befehl das Katalogverhalten von hive_metastore, sodass die Tabelle Type ungeachtet ihres tatsächlichen Zustands als EXTERNAL angezeigt wird.

Weiterführende Themen

Dieser Abschnitt enthält erweiterte Themen zum Konvertieren fremder und externer Tabellen in verwaltete Tabellen.

Konvertieren auf Schema- oder Katalogebene

Sie haben die folgenden beiden Optionen, um das Konvertieren von Tabellen auf Schema- oder Katalogebene zu automatisieren:

• Durchlaufen Sie die Tabellen in Ihren Schemata, um jede Tabelle einzeln zu konvertieren.

• Verwenden Sie das Discoverx Labs-Projekt, um ganze Schemas oder Kataloge gleichzeitig zu konvertieren:

  df = (dx.from_tables("prod.*.*")
  .with_sql("ALTER TABLE {full_table_name} SET MANAGED;")
  .apply())
  

Siehe Databricks Labs und discoverx.

Erstellen von Tabellen in einem fremden Katalog

Sie können externe oder verwaltete Tabellen in einem fremden Katalog erstellen. Das Verhalten hängt von der Schemakonfiguration ab:

• Für Glue- oder eHMS-Schemas oder für Schemas mit einem verwalteten Speicherort im Unity-Katalog: Wenn Sie ausführen CREATE TABLE foreign_catalog.schema.table, erstellt dies eine verwaltete oder externe Tabelle im Unity-Katalog. Databricks pusht oder synchronisiert die Tabelle nicht mit dem externen Katalog.
• Für Schemas aus internen Hive-Metaspeicherverbindungen: Wenn Sie versuchen, eine Tabelle in einem fremdschema zu erstellen, erstellt sie weiterhin eine Fremdtabelle und erstellt auch eine Tabelle in hive_metastore.
• Veralteter Arbeitsbereichs-Hive-Metastore: Da es sich um einen Lese- und Schreibverbund handelt, wird, wenn Sie eine Tabelle im fremden Katalog erstellen, auch eine Tabelle im internen Hive-Metastore erstellt.

DBFS-gestützte Fremdtabellen

Beim Konvertieren einer von DBFS gestützten Tabelle speichert Databricks die aktuelle Zuordnung des DBFS-Pfads als Cloud-Pfad-Standort der externen Tabelle.

Einschränkungen

Das Konvertieren externer oder fremder Tabellen in verwaltete Tabellen hat die folgenden Einschränkungen:

• Die Tabellenhistorie für Commits, die nach der Konvertierung, aber vor dem Rollback durchgeführt wurden, ermöglicht Zeitreisen anhand der Version, jedoch nicht anhand des Zeitstempels.

• OpenSharing ist nicht vollständig mit dem SET MANAGED Befehl kompatibel. OpenSharing wird unterstützt, die Datenbricks-zu-Databricks-Freigabe aktualisiert jedoch nicht automatisch den verwalteten Speicherort der Empfängertabelle. Der Empfänger liest weiterhin vom alten Standort aus, bis Sie die Tabelle erneut freigeben. Führen Sie die folgenden Befehle aus, um die Tabelle erneut zu teilen:

  ALTER SHARE <share_name> REMOVE TABLE <table_name>;
  ALTER SHARE <share_name> ADD TABLE <table_name> AS <table_share_name> WITH HISTORY;
  

• Wenn sich der standardmäßig verwaltete Speicherort Ihres Unity-Katalogmetastores, -Katalogs oder -Schemas in einer anderen Cloudregion befindet als der Speicherort der Quelltabelle, können zusätzliche regionsübergreifende Datenübertragungskosten von Ihrem Cloudanbieter entstehen.

  Führen Sie die folgenden Befehle aus, um den Speicherort Ihres Schemas und Katalogs zu überprüfen:

  DESC SCHEMA EXTENDED <catalog_name>.<schema_name>;
  
  DESC CATALOG EXTENDED <catalog_name>;
  

  Führen Sie einen der folgenden Befehle aus, um den Speicherort Ihres Metastores zu überprüfen:

  DESC METASTORE; -- Option 1
  SELECT * FROM system.information_schema.metastores; -- Option 2
  

Pfadbasierte Umleitungseinschränkungen:

• Sie müssen alle Streamingaufträge nach der Konvertierung neu starten. Siehe Streamingverhalten.
• Pfadbasierte Umleitung verfügt nur über Abwärtskompatibilität für den Migrationsprozess und ermöglicht keinen neuen pfadbasierten Zugriff auf verwaltete Tabellen im Unity-Katalog.

Einschränkungen für Fremdtabellen:

• Für die Konvertierung werden nur fremdtabellen, die mit hive metastore und Glue Federation verbunden sind, unterstützt.