Konvertera externa eller utländska Delta Lake-tabeller till hanterade Unity Catalog-tabeller

Important

Det är allmänt tillgängligt att konvertera en extern tabell till en hanterad tabell.

Konvertering av en sekundär tabell till en hanterad tabell finns i offentlig förhandsversion. Endast främmande tabeller som federeras med Hive metastore och Glue Federation stöds.

Om du vill konvertera en extern eller extern Delta Lake-tabell till en hanterad Unity Catalog-tabell i Azure Databricks använder du ALTER TABLE ... SET MANAGED kommandot eller, för externa tabeller, Katalogutforskaren. Konverteringen behåller tabellkonfigurationer, inklusive namn, inställningar, behörigheter och vyer, och behåller tabellhistoriken.

För konverteringar av externa tabeller, se även: SET MANAGED

  • Minimerar läs- och skrivaravbrott.
  • Hanterar samtidiga skrivningar under konverteringen.
  • Gör att du kan återställa en konverterad hanterad tabell till en extern tabell.
  • Omdirigerar sökvägsbaserade läsningar och skrivningar så att äldre kod kan fungera efter konverteringen.

Även om du kan använda CREATE TABLE AS SELECT (CTAS) för att konvertera en extern tabell, rekommenderar Databricks SET MANAGED av följande skäl.

För konverteringar av externa tabeller ställer Databricks in prediktiv optimering på den konverterade tabellen till INHERIT snarare än att automatiskt aktivera den. Se främmande tabeller med SQL.

Information om hur du konverterar externa tabeller till externa tabeller finns i Konvertera en sekundär tabell till en extern Unity Catalog-tabell.

Prerequisites

Förutsättningarna varierar beroende på om du konverterar en extern tabell eller en främmande tabell.

Externa tabeller

Konvertering av externa tabeller till hanterade tabeller har följande förutsättningar:

  • Format: Tabellen måste använda Delta Lake-formatet.
  • Runtime: Du måste använda Databricks Runtime 17.3 LTS eller högre, eller serverlös beräkning för att använda SET MANAGED, UNSET MANAGED eller TRUNCATE UNIFORM HISTORY.
  • Läsare och författare: Azure Databricks läsare och författare för dina källtabeller måste använda Databricks Runtime 15.4 LTS eller senare. Om dina läsare eller skrivare använder 14.3 LTS eller tidigare, se Äldre läsare och skrivare.
  • Externa klienter: Externa klienter (icke-Databricks) måste ha stöd för läsningar till hanterade Unity Catalog-tabeller. Se Åtkomsttabeller med Delta-klienter.
    • Använd Instrumentpanelen för Access Insights för att avgöra om de användare som har tillgång till dina tabeller använder Databricks Runtime eller externa system som inte är Databricks.
  • Funktionskompatibilitet: Om tabellen har minReaderVersion=2, minWriterVersion=7och tableFeatures={..., columnMapping}, SET MANAGED misslyckas kommandot med ett DELTA_TRUNCATED_TRANSACTION_LOG fel. Kontrollera om tabellen har dessa egenskaper med hjälp av DESCRIBE DETAIL. Se Delta Lake-funktionskompatibilitet och protokoll.

Efter konverteringen omdirigeras sökvägsbaserade läsningar och skrivningar automatiskt till den nya hanterade platsen med mindre prestandakostnader. Databricks rekommenderar att du migrerar all sökvägsbaserad åtkomst till namnbaserad åtkomst för att undvika prestandakostnader. Se Sökvägsbaserad omdirigering.

Important

Undvik konflikter genom att avbryta alla befintliga OPTIMIZE kommandojobb (flytande klustring, komprimering, ZORDER) som körs i den externa tabellen och inte schemalägga några jobb när du konverterar dina externa tabeller till hanterade tabeller.

Externa tabeller

Important

Konvertering av en sekundär tabell till en hanterad tabell finns i offentlig förhandsversion.

Att konvertera externa tabeller till hanterade tabeller har följande förutsättningar:

  • Dataformat: Den externa tabellen måste använda Delta Lake-formatet. Information om hur du utför en engångskonvertering för Parquet finns i Konvertera till Delta Lake.
  • Runtime: Databricks Runtime 17.3 eller senare.
  • Tabelltyp: Tabelltypen Hive-metaarkiv (HMS) måste vara en extern HMS-tabell. Kommandot misslyckas om tabellen är en hanterad HMS-tabell.
  • Behörigheter: OWNER eller MANAGE behörigheter i tabellen och CREATE behörighet för EXTERNAL LOCATION.

Stilleståndstid och datakopieringstider

Kommandot SET MANAGED minimerar eller eliminerar stilleståndstid jämfört med alternativa metoder, till exempel DEEP CLONE.

Externa tabeller

Konverteringsprocessen för externa tabeller använder en tvåstegsmetod:

  1. Inledande datakopiering (ingen stilleståndstid): Kommandot kopierar tabelldata och Delta-transaktionsloggen från den externa platsen till den hanterade platsen. Aktiva läs- och skrivprocesser till den externa tabellen fortsätter utan avbrott.
  2. Växla till hanterad plats (kort stilleståndstid): Incheckningar som görs till den externa platsen under det första steget flyttas till den hanterade platsen och tabellmetadata uppdateras för att registrera den nya hanterade platsen. Under det här steget blockeras alla skrivningar till den externa platsen tillfälligt, vilket resulterar i skrivaravbrott. Läsare på Databricks Runtime 16.4 LTS eller senare upplever ingen stilleståndstid, men läsare på Databricks Runtime 15.4 LTS och nedan kan uppleva driftstopp.

I följande tabell visas uppskattad stilleståndstid baserat på källtabellens storlek och en uppskattad dataflödeshastighet på 0,5–2 GB/CPU-kärna/minut:

Tabellstorlek Rekommenderad klusterstorlek Beräknad datakopieringstid Uppskattad nedtid för läsare och skrivare
100 GB eller mindre 32-kärnor/X-Large SQL-databaslager ~6 min eller mindre ~1-2 min eller mindre
1 TB 64-kärnor/2X-stort SQL-lager ~30 min ~1-2 min
10 terabyte 256-kärnor/4X-stort SQL-lager ~1,5 timmar ~1-5 min

Note

Stilleståndstiden kan variera beroende på faktorer som filstorlek, antal filer och antal incheckningar.

Främmande tabeller

Avbrott i konvertering av utländska tabeller beror på om du använder MOVE eller COPY:

  • För MOVEkan stilleståndstid uppstå enligt beskrivningen för externa tabeller. Se Externa tabeller.
  • För COPYansvarar du för att hantera driftstopp eftersom konverteringsprocessen kopierar källtabellen till den hanterade lagringsplatsen och skapar två separata kopior av data. Du ansvarar för att inaktivera läsningar och skrivningar till källtabellen i den externa katalogen och migrera arbetsbelastningar för att använda den nya hanterade tabellen.

Konvertera till en hanterad tabell

Konvertera en extern tabell med hjälp av Catalog Explorer eller SQL, eller konvertera en främmande tabell med hjälp av SQL.

Externa tabeller med hjälp av Katalogutforskaren (Beta)

Important

Konvertering av externa till hanterade tabeller med Hjälp av Catalog Explorer finns i Beta.

Med Hjälp av Katalogutforskaren kan du konvertera en eller flera externa tabeller i ett schema i taget.

  1. Gå till den tabell eller det schema som du vill konvertera i Katalogutforskaren.

  2. Under Om den här tabellen (tabellinformationssida) eller Om det här schemat (schemainformationssidan) klickar du på Utforska optimeringar.

  3. I dialogrutan Varför migrera till hanterade Unity Catalog-tabeller? klickar du på Fortsätt.

    Dialogrutan Varför migrera till hanterade tabeller i Unity Catalog med knappen Fortsätt

  4. Välj de externa tabeller som du vill konvertera. Om du öppnade dialogrutan från en tabellinformationssida väljer Katalogutforskaren tabellen i förväg. Använd sökfältet för att hitta ytterligare tabeller. Hanterade tabeller kan inte väljas.

    Tabellvalssida som visar en förvald extern tabell och en otillgänglig hanterad tabell

  5. Klicka på Skapa konverteringsanteckningsbok.

  6. Du kan också ange ett namn för notebook-filen. Som standard sparar detta anteckningsboken i din hemmapp. Klicka på Bläddra för att spara den på en annan plats.

    Dialogrutan Skapa konverteringsanteckningsbok som visar namnfältet och alternativet Bläddra

  7. Granska rekommenderade metoder i notebook-filen och kontrollera att du uppfyller alla krav.

  8. Kör cellen SET MANAGED Queries (HANTERADE frågor ).

När cellen har körts visas tabelltypen som HANTERAd i stället för EXTERN i Katalogutforskaren. Uppdatera sidan om statusen inte uppdateras omedelbart.

Externa tabeller med SQL

Beroende på om din externa tabell har aktiverade Apache Iceberg-avläsningar (UniForm) kör något av följande kommandon. Information om hur du kontrollerar om isbergsläsningar är aktiverade i tabellen finns i Kontrollera att isbergsläsningar är aktiverade.

  • Kör följande kommando för externa tabeller i Unity Catalog utan aktiverad Iceberg-läsning:

    ALTER TABLE catalog.schema.my_external_table SET MANAGED;
    

    Efter konverteringen kan du aktivera Iceberg-läsningar i den hanterade tabellen utan kompatibilitetsproblem.

  • För externa tabeller i Unity Catalog där Iceberg-läsning redan har aktiverats kör du följande kommando:

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

    Inkludera TRUNCATE UNIFORM HISTORY för att upprätthålla optimala tabellprestanda och kompatibilitet. TRUNCATE UNIFORM HISTORY trunkerar endast UniForm Iceberg-historiken och tar inte bort Delta-historiken. Det här kommandot resulterar i en kort nedtid för både läsning och skrivning för Iceberg efter trunkeringen.

Efter tabellkonverteringen misslyckas befintliga läs- och skrivströmmar. Starta om strömmar med samma konfigurationer för att automatiskt använda sökvägsbaserad omdirigering. Kontrollera att läsarna och författarna arbetar med den hanterade tabellen. Se Beteende för direktuppspelning.

Förutsägande optimering aktiveras automatiskt efter konverteringen om du inte inaktiverade den manuellt. Se Kontrollera om förutsägelseoptimering är aktiverat.

Azure Databricks behåller data på den externa platsen i Unity Catalog i 14 dagar för att tillåta återställning. Se Ångra en hanterad tabellkonvertering. Efter 14 dagar, med förutsägande optimering aktiverad, tar Azure Databricks automatiskt bort dessa data för att frigöra lagring och spara kostnader. Om du inaktiverar prediktiv optimering, kör du VACUUM (kräver Databricks Runtime 17.3 LTS eller senare eller serverlös beräkning) på den nyligen konverterade hanterade tabellen efter 14 dagar för att frigöra lagringsutrymmet själv.

VACUUM my_converted_table

Note

Även om förutsägande optimering är aktiverat kanske data på den externa platsen i Unity Catalog inte tas bort efter 14 dagar. Detta kan till exempel inträffa när den hanterade tabellen används sällan eller är liten. Om tidigare data finns kvar kör du VACUUM manuellt för att ta bort dem.

Azure Databricks tar bara bort data på den externa platsen. Delta-transaktionsloggen och referensen till tabellen i Unity Catalog behålls.

Främmande tabeller med SQL

Important

Konvertering av en sekundär tabell till en hanterad tabell finns i offentlig förhandsversion.

Kör följande kommando för att konvertera den externa Unity Catalog-tabellen till en styrd Unity Catalog-tabell.

ALTER TABLE source_table SET MANAGED {MOVE | COPY}
  • source_table

    En befintlig extern tabell federerad i Unity Catalog.

  • MOVE

    Konverterar tabellen till hanterad och inaktiverar åtkomst till källtabellen i den externa katalogen.

    • Åtkomst via den externa katalogen eller sökvägsbaserad åtkomst misslyckas när du har konverterat tabellen. Alla läsare och författare till tabellen måste använda Unity Catalog-namnområdet för åtkomst. Ett exempel:

      SELECT * FROM catalog_name.schema_name.table_name;
      
    • Sökvägsbaserad åtkomst stöds inte och misslyckas när du har konverterat tabellen. Ett exempel:

      SELECT * FROM delta.`protocol://path/to/table`;
      
    • Läsar-/skrivarversionen och kraven på klientkompatibilitet är desamma som beskrivs i Krav och Äldre läsare och författare.

    • Förutsägande optimering är inställt på INHERIT om du inte har konfigurerat den manuellt. Om du vill kontrollera om förutsägande optimering är aktiverat kan du läsa Kontrollera om förutsägelseoptimering är aktiverat.

  • COPY

    Konverterar tabellen till hanterad utan att ändra eller inaktivera åtkomst till källtabellen i den externa katalogen.

    • Under konverteringen till hanterad kopierar konverteringsprocessen data från källtabellen till den hanterade lagringsplats som definierats för den externa tabellen, vilket skapar två separata kopior: den nya hanterade tabellen och källtabellen i den externa katalogen.
    • Till skillnad från MOVE, där läsningar och skrivningar misslyckas, ansvarar du vid användning av COPY för att korrekt inaktivera läsningar och skrivningar till källtabellen i den externa katalogen och se till att arbetsbelastningarna har migrerats till den nya katalogen.

Efter tabellkonverteringen måste du starta om alla direktuppspelningsjobb (läsa eller skriva) med hjälp av den externa tabellen och kontrollera att dina läsare och författare arbetar med den hanterade tabellen.

Om du släpper källtabellen i den externa katalogen före konverteringen, så släpper Unity Catalog även den externa tabellen. När du har konverterat tabellen till hanterad påverkar det inte den hanterade tabellen i Unity Catalog att ta bort källtabellen i den externa katalogen.

Om kommandot avbryts när data kopieras startar du om det. Kommandot återupptas där det slutade.

Varning

Databricks rekommenderar att du undviker att köra flera SET MANAGED kommandon samtidigt i samma tabell, vilket kan leda till ett inkonsekvent tabelltillstånd.

Verifiera konvertering

Kontrollera att tabellen har konverterats till en hanterad tabell genom att kontrollera om tabellen Type är MANAGED. Du kan göra något av följande:

  • Öppna en ny flik och gå till Katalogutforskaren. På fliken Information under Om den här tabellen visas tabelltypen som Hanterad.

  • Kontrollera tabellen Type genom att köra följande SQL-kommando:

    DESCRIBE EXTENDED catalog_name.schema_name.table_name
    

    Om du vill kontrollera flera tabeller samtidigt eller skripta kontrollen frågar du information_schema.tables i stället:

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

Äldre läsare och författare

Databricks rekommenderar att du uppgraderar alla läsare och skrivare till Databricks Runtime 15.4 LTS eller senare version för att kunna använda alla funktioner i SET MANAGED, inklusive bevarande av tabellhistorik.

Du kan fortfarande använda SET MANAGED om du har läsare eller författare på Databricks Runtime 15.3 eller lägre. Men när du har konverterat den till en hanterad tabell kan du bara gå tillbaka till historiska incheckningar med hjälp av versionsnummer, inte med tidsstämpel.

Om du återgår till en extern tabell inom 14 dagar återaktiveras åtkomst till historiska ändringar från före konverteringen. Tidsresor med hjälp av tidsstämplar stöds inte för ändringar som görs i den konverterade hanterade tabellen mellan konverteringen och återställningen. Se Ångra en hanterad tabellkonvertering.

Om du skriver till en tabell efter konverteringen med Databricks Runtime 15.3 eller senare måste du ta bort inCommitTimestamp funktionen:

ALTER TABLE <table_name> DROP FEATURE inCommitTimestamp;

Sökvägsbaserad omdirigering

I Databricks Runtime 18.1 och senare omdirigeras sökvägsbaserade läsningar och skrivningar till den tidigare externa platsen automatiskt till den nya hanterade platsen när du har konverterat en extern tabell till en hanterad Unity Catalog-tabell. En sökvägsbaserad läsning är kod som SELECT * FROM delta.`/path/to/my_table`. Sökvägsbaserad omdirigering minskar den tid och det arbete som krävs för att migrera till hanterade tabeller genom att tillåta äldre kod som använder lagringssökvägar för att fortsätta arbeta utan refaktorisering.

Konverteringar av utländska tabeller omdirigerar inte sökvägsbaserad åtkomst.

För användningsfall med låg latens rekommenderar Azure Databricks att du migrerar sökvägsbaserad åtkomst till namnbaserad åtkomst. Sökvägsbaserad omdirigering lägger till flera hundra millisekunder i tid för varje sökvägsbaserad läsning eller skrivning, och kräver att du behåller gamla Delta-loggar aktiva på din externa plats i Unity Catalog. Namnbaserade läsningar och skrivningar har inte ytterligare prestandakostnader. Se Migrera sökvägsbaserad kod till namnbaserad.

Migrera sökvägsbaserad kod till namnbaserad

Om du bestämmer dig för att inte använda sökvägsbaserad omdirigering kan du migrera äldre kod. Om du vill migrera ersätter du sökvägsbaserade referenser med namnbaserade referenser.

Följande kodexempel innehåller en sökvägsbaserad tabellreferens till filer:

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

Ersätt den sökvägsbaserade referensen med en namnbaserad referens till en extern tabell, som i följande kod:

SELECT * FROM catalog_name.schema_name.customers_table;

Beteende för direktuppspelning

Direktuppspelning med sökvägsbaserad omdirigering stöder läsningar och skrivningar i följande Databricks Runtime-versioner:

  • Läsningar stöds i Databricks Runtime 18.1 och senare.
  • Skrivoperationer stöds i Databricks Runtime 18.2 och senare.

Efter konverteringen måste du starta om alla direktuppspelningsjobb för att undvika att läsa från eller skriva till den tidigare tabellplatsen.

Sökvägsbaserade direktuppspelningsläsningar och skrivningar misslyckas och stoppas vid nästa kontrollpunkt med ett migreringsmeddelande:

  • Vid läsningar genererar strömmen ett fel: 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.
  • För skrivningar genererar den första mikrobatchen efter konverteringen ett fel: Operation not allowed: STREAMING WRITE cannot be performed on a table with redirect feature. The no redirect rules are not satisfied [].

Lös fel genom att starta om strömmar med samma konfigurationer. Sökvägsbaserad åtkomst omdirigeras automatiskt till den hanterade tabellen.

Sökvägsbaserade omdirigeringsbegränsningar finns i Begränsningar.

Felsöka konverteringsfel

I det här avsnittet beskrivs hur du löser vanliga problem när du konverterar externa tabeller till hanterade Unity Catalog-tabeller med hjälp av SET MANAGED.

VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED

Om konverteringen misslyckas försöker du alltid igen med samma Databricks Runtime-version. Metadata kan serialiseras på olika sätt i olika versioner, vilket orsakar ett VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED fel om du försöker konvertera på en annan Databricks Runtime-version.

Avstängning av kluster under konvertering

Om klustret stängs av under konverteringen kan kommandot misslyckas med DELTA_ALTER_TABLE_SET_MANAGED_INTERNAL_ERROR. Försök igen med kommandot för att återuppta konverteringen.

Skadad extern tabell

Om den externa tabellen redan är skadad (till exempel inte giltigt tabelltillstånd) kan konverteringen misslyckas med fel som DELTA_TRUNCATED_TRANSACTION_LOG, DELTA_TXN_LOG_FAILED_INTEGRITYeller DELTA_STATE_RECOVER_ERRORS. Innan du försöker konvertera kontrollerar du att du kan köra grundläggande åtgärder i den externa tabellen, till exempel DESCRIBE DETAIL.

Filvalideringsfel

Kommandot SET MANAGED verifierar att det kopierade alla filer i den senaste ögonblicksbilden av tabellen till den nya hanterade tabellplatsen. Om några filer saknas misslyckas kommandot med ett DELTA_ALTER_TABLE_SET_MANAGED_FAILED.FILE_VALIDATION_FAILED fel.

Så här löser du problemet:

  1. Kontrollera Spark-drivrutinsloggarna för att identifiera vilka filer som inte kunde migreras.
  2. Kontrollera att dessa filer finns på platsen för den externa källtabellen och att de är tillgängliga.
  3. Försök igen med ALTER TABLE ... SET MANAGED kommandot.

Om problemet kvarstår kontaktar du Databricks-supporten.

Ångra en konvertering till hanterad tabell

Important

Återställningskommandon kräver serverlös beräkning eller Databricks Runtime 17.3 LTS och senare.

Extern tabellen

När du har konverterat en extern tabell till en hanterad tabell kan du återställa inom 14 dagar med hjälp UNSET MANAGED av kommandot . Detta uppdaterar tabellmetadata så att de pekar tillbaka till den ursprungliga externa platsen. Databricks bevarar alla skrivningar som görs till den hanterade platsen efter konverteringen.

Kör följande kommando för att återställa till en extern tabell:

ALTER TABLE catalog.schema.my_managed_table UNSET MANAGED;

Tänk på följande information:

  • Om återställningskommandot avbryts eller misslyckas kör du det igen för att försöka igen.
  • Du måste starta om dina strömningsjobb efter återställningen, precis som vid konvertering.
  • Incheckningar som görs i den hanterade lagringsplatsen mellan konvertering och återställning gör det möjligt att resa i tiden efter version, men inte efter tidsstämpel.
  • Sju dagar efter återställningen tar Azure Databricks automatiskt bort data på den hanterade platsen.

Extern tabell: MOVE

Varning

Du MÅSTE köra UNSET MANAGED innan du tar bort den hanterade tabellen. Om du släpper tabellen utan att köra UNSET MANAGED den först kan det leda till dataförlust eller inkonsekvenser.

Du kan återställa tabellmigreringen och återfå åtkomsten till källtabellen i den externa katalogen med hjälp UNSET MANAGED av kommandot . Återställning kräver två steg: först måste du återställa tabellen till en extern tabell och sedan ta bort den externa tabellen för att federera tabellen igen som en främmande tabell.

  1. Kör följande kommando för att återställa till en extern tabell:
ALTER TABLE catalog.schema.my_managed_table UNSET MANAGED
  1. Om du vill federera tabellen på nytt till en främmande tabell tar du bort den externa tabellen med följande kommando:
DROP TABLE catalog.schema.my_managed_table

Den externa tabellen är tillgänglig efter nästa katalogsynkronisering.

Tänk på följande information:

  • För incheckningar som du gjorde till den externa platsen mellan konvertering och återställning kan du resa i tiden med hjälp av version, men inte med hjälp av tidsstämpel.
  • Sju dagar efter återställningen tar Databricks bort data på den hanterade platsen.

Extern tabell: COPY

Om du vill återställa tabellmigreringen behöver du inte köra UNSET MANAGED kommandot eftersom källtabellen i den externa katalogen inte ändrades. Ta bort den hanterade tabellen, så federerar Databricks den på nytt som en extern tabell efter nästa katalogsynkronisering.

Verifiera återställning

Verifiera återställningar på olika sätt för externa och främmande tabeller.

Externa tabeller

Kontrollera att den hanterade tabellen har återställts till en extern tabell genom att kontrollera om tabellen Type är EXTERNAL. Du kan göra något av följande:

  • Öppna en ny flik och gå till Katalogutforskaren. På fliken Information under Om den här tabellen visas tabelltypen som Extern.

  • Kontrollera tabellen Type genom att köra följande SQL-kommando:

    DESCRIBE EXTENDED catalog_name.schema_name.table_name
    

    Om du vill kontrollera flera tabeller samtidigt eller skripta kontrollen frågar du information_schema.tables i stället:

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

Externa tabeller

För att kontrollera att den hanterade tabellen har återställts som en extern tabell kontrollerar du om tabellen Type är FOREIGN. Du kan göra något av följande:

  • Öppna en ny flik och gå till Katalogutforskaren. På fliken Detaljer, under Om den här tabellen, visas tabellens Typ som Extern.

  • Kontrollera tabelltypen genom att köra följande SQL-kommando:

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

    Kolumnen table_type visas som FOREIGN.

Note

Använd inte DESCRIBE EXTENDED för att verifiera konvertering eller återställning av främmande tabeller. Federationen använder hive_metastore katalogbeteende för det här kommandot, så tabellen Type visas som EXTERNAL, oavsett tabellens faktiska tillstånd.

Avancerade ämnen

Det här avsnittet innehåller avancerade ämnen om att konvertera främmande och externa tabeller till hanterade tabeller.

Konvertera på schema- eller katalognivå

Du har följande två alternativ för att automatisera konvertering av tabeller på schema- eller katalognivå:

  • Iterera genom dina tabeller i dina scheman för att konvertera varje tabell individuellt.

  • Använd projektet discoverx labs för att konvertera hela scheman eller kataloger på en gång:

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

Se Databricks Labs och discoverx.

Skapa tabeller i en extern katalog

Du kan skapa externa eller hanterade tabeller i en extern katalog. Beteendet beror på schemakonfigurationen:

  • För Glue- eller eHMS-scheman, eller för scheman med en hanterad plats som angetts i Unity Catalog: Om du kör CREATE TABLE foreign_catalog.schema.table, skapar detta en hanterad eller extern Unity Catalog-tabell. Databricks överför eller synkroniserar inte tabellen till den externa katalogen.
  • För scheman från interna Hive-metaarkivanslutningar: Om du försöker skapa en tabell i ett sekundärschema skapar den fortfarande en sekundär tabell och skapar även en tabell i hive_metastore.
  • För Hive-metastore i äldre arbetsytor: Eftersom detta har läs- och skrivfederation skapas även en tabell i det interna Hive-metastore om du skapar en tabell i den externa katalogen.

DBFS-stödda externa tabeller

När du konverterar en tabell som backas av DBFS lagrar Databricks den aktuella mappningen för DBFS-sökvägen som den externa tabellens molnsökväg.

Begränsningar

Att konvertera externa eller främmande tabeller till hanterade tabeller har följande begränsningar:

  • Tabellhistoriken för incheckningar som gjorts efter konverteringen men före återställningen möjliggör tidsresa baserat på version, men inte baserat på tidsstämpel.

  • OpenSharing är inte helt kompatibelt med SET MANAGED kommandot. Open OpenSharing stöds, men Databricks-till-Databricks-delning uppdaterar inte mottagartabellens hanterade plats automatiskt. Mottagaren fortsätter att läsa från den gamla platsen tills du delar tabellen igen. Om du vill dela tabellen igen kör du följande kommandon:

    ALTER SHARE <share_name> REMOVE TABLE <table_name>;
    ALTER SHARE <share_name> ADD TABLE <table_name> AS <table_share_name> WITH HISTORY;
    
  • Om standardplatsen för enhetskatalogens metaarkiv, katalog eller schema finns i en annan molnregion än källtabellens lagringsplats kan det medföra ytterligare kostnader för dataöverföring mellan regioner från molnleverantören.

    Kontrollera platsen för schemat och katalogen genom att köra följande kommandon:

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

    Kontrollera platsen för metaarkivet genom att köra något av följande kommandon:

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

Sökvägsbaserade omdirigeringsbegränsningar:

  • Du måste starta om alla direktuppspelningsjobb efter konverteringen. Se Beteende för direktuppspelning.
  • Sökvägsbaserad omdirigering har endast bakåtkompatibilitet för migreringsprocessen och aktiverar inte ny sökvägsbaserad åtkomst till hanterade Unity Catalog-tabeller.

Begränsningar för externa tabeller: