Hive-metaarkivfederation: aktivera Unity Catalog för att styra tabeller som registrerats i ett Hive-metaarkiv

Den här artikeln introducerar Hive-metaarkivfederation, en funktion som gör det möjligt för Unity Catalog att styra tabeller som lagras i ett Hive-metaarkiv. Du kan federera ett externt Hive-metaarkiv eller ett äldre internt Azure Databricks Hive-metaarkiv.

Hive metastore federation kan användas för följande användningsområden:

• Detta är ett steg i migreringsvägen till Unity Catalog som möjliggör successiv migrering utan kodanpassning, där vissa av dina arbetsprocesser fortsätter att använda data som är registrerade i Hive-metastoren medan andra migreras.

  Det här användningsfallet passar bäst för organisationer som använder ett äldre internt Azure Databricks Hive-metaarkiv idag, eftersom federerade interna Hive-metaarkiv tillåter både läs- och skrivarbetsbelastningar.

• För att tillhandahålla en mer långsiktig hybridmodell för organisationer som måste underhålla vissa data i ett Hive-metaarkiv tillsammans med sina data som är registrerade i Unity Catalog.

  Det här användningsfallet passar bäst för organisationer som använder ett externt Hive-metaarkiv, eftersom utländska kataloger för dessa Hive-metaarkiv är skrivskyddade.

Översikt över federering av Hive-metadatalager

I Hive-metaarkivfederationen skapar du en anslutning från Din Azure Databricks-arbetsyta till hive-metaarkivet, och Unity Catalog crawlar Hive-metaarkivet för att fylla i en extern katalog, ibland kallad en federerad katalog, som gör att din organisation kan arbeta med hive-metaarkivtabellerna i Unity Catalog, vilket ger centraliserade åtkomstkontroller, ursprung, sökning, och mycket mer.

Federerade Hive-metaarkiv som är externa till din Azure Databricks-arbetsyta tillåter läsningar med Unity Catalog. Interna Hive-metaarkiv tillåter läsningar och skrivningar, uppdaterar Hive-metaarkivmetadata samt Unity Catalog-metadata när du skriver.

När du kör frågor mot utländska tabeller i ett federerat Hive-metaarkiv tillhandahåller Unity Catalog styrningslagret och utför funktioner som åtkomstkontroller och granskning, medan frågor körs enligt Hive-metaarkivsemantik. Om en användare till exempel frågar en tabell som lagras i Parquet-format i en sekundär katalog:

• Unity Catalog kontrollerar om användaren har åtkomst till tabellen och härleder ursprung för frågan.
• Själva frågan körs mot det underliggande Hive-metaarkivet och utnyttjar den senaste metadata- och partitionsinformationen som lagras där.

Hur jämför sig Hive-metastore-federationen med användningen av externa tabeller i Unity Catalog?

Unity Catalog har möjlighet att skapa externa tabeller, ta data som redan finns på en godtycklig molnlagringsplats och registrera dem i Unity Catalog som en tabell. Det här avsnittet utforskar skillnaderna mellan externa och externa tabeller i ett federerat Hive-metaarkiv.

Båda tabelltyperna har följande egenskaper:

• Kan användas för att registrera en godtycklig plats i molnlagring som en tabell.
• Kan tillämpa Unity Catalog-behörigheter och detaljerad åtkomstkontroll.
• Kan visas i härstamningen för frågor som refererar till dem.

Utländska tabeller i ett federerat Hive-metadatalager har följande egenskaper:

• Identifieras automatiskt baserat på crawlning av ett Hive-metaarkiv. Så snart tabeller har skapats i Hive-metaarkivet visas de och är tillgängliga för frågor i den externa katalogen för Unity Catalog.
• Tillåt att tabeller definieras med Hive-semantik som Hive SerDes och partitioner.
• Tillåt att tabeller har överlappande sökvägar med andra tabeller i externa kataloger.
• Tillåt att tabeller lokaliseras vid DBFS-rotplatser.
• Inkludera vyer som definieras i Hive-metadatalager.

På så sätt kan du tänka på externa tabeller i ett federerat Hive-metaarkiv som att de erbjuder bakåtkompatibilitet med Hive-metaarkiv, vilket gör att arbetsbelastningar kan använda endast Hive-semantik men med styrning som tillhandahålls av Unity Catalog.

Vissa Unity Catalog-funktioner är dock inte tillgängliga i utländska tabeller, till exempel:

• Funktioner som endast är tillgängliga för hanterade Unity Catalog-tabeller, till exempel förutsägande optimering.
• Vektorsökning, Deltadelning, Lakehouse-övervakning och onlinetabeller.
• Viss funktionalitet i funktionsbutiken, inklusive skapande av funktionsbutik, skapande av modelltjänster, skapande av funktionsspecifikationer, modellloggning och batchbedömning.

Prestandan kan vara marginellt sämre än förfrågningar i Unity Catalog eller Hive-metaarkiv, eftersom både Hive-metaarkivet och Unity Catalog finns på frågesökvägen för en utländsk tabell.

Mer information om funktioner som stöds finns i Krav och funktionsstöd.

Vad innebär det att skriva till en utländsk katalog i ett federerat Hive-metaarkiv?

Skrivningar stöds endast för federerade interna Hive-metaarkiv, inte externa Hive-metaarkiv.

Skrivningar till federerade metaarkiv är av två typer:

• DDL-åtgärder, exempelvis CREATE TABLE, ALTER TABLEoch DROP TABLE.

  DDL-åtgärder återspeglas synkront i det underliggande Hive-metaarkivet. Om du till exempel kör en CREATE TABLE-instruktion skapas tabellen i både Hive-metaarkivet och den externa katalogen.

  Warning

  Det innebär också att DROP kommandon återspeglas i Hive-metaarkivet. Till exempel släpper DROP SCHEMA mySchema CASCADE alla tabeller i det underliggande Hive-metaarkivschemat, utan alternativet att UNDROP, eftersom Hive-metaarkivet inte stöder UNDROP.

• DML-åtgärder som INSERT, UPDATEoch DELETE.

  DML-åtgärder återspeglas också synkront i den underliggande Hive-metaarkivtabellen. Om du till exempel kör INSERT INTO läggs poster till i tabellen i Hive-metaarkivet.

  Skrivstöd är en nyckel för att möjliggöra en sömlös övergång under migreringen från Hive-metaarkivet till Unity Catalog. Se Hur använder du Hive-metaarkivfederation under migreringen till Unity Catalog?.

Hur konfigurerar du Hive metastore-federation?

För att konfigurera Hive-metastore-federation gör du följande:

1. Skapa en anslutning i Unity Catalog som anger sökvägen och autentiseringsuppgifterna för åtkomst till Hive-metaarkivet.

   Federationen för Hive-metaarkivet använder den här anslutningen för att genomsöka Hive-metaarkivet. För de flesta databassystem anger du ett användarnamn och lösenord. För en anslutning till ett äldre internt Hive-metaarkiv för Azure Databricks-arbetsytan tar Hive-metaarkivfederationen hand om auktoriseringen.

2. Skapa autentiseringsuppgifter för lagring och en extern plats i Unity Catalog för sökvägarna till tabellerna som registrerats i Hive-metastore.

   Externa platser innehåller sökvägar och lagringsautentiseringsuppgifter som krävs för åtkomst till dessa sökvägar. Autentiseringsuppgifter för lagring är Skyddsbara objekt i Unity Catalog som anger autentiseringsuppgifter, till exempel Azure-hanterade identiteter, för åtkomst till molnlagring. Beroende på vilket arbetsflöde du väljer för att skapa externa platser kan du behöva skapa autentiseringsuppgifter för lagring innan du skapar den externa platsen.

3. Skapa en sekundär katalog i Unity Catalog med hjälp av den anslutning som du skapade i steg 1.

   Det här är den katalog som arbetsyteanvändare och arbetsflöden använder för att arbeta med Hive-metaarkivtabeller med hjälp av Unity Catalog. När du har skapat den externa katalogen fyller Unity Catalog i den med tabellerna som är registrerade i Hive-metaarkivet.

4. Bevilja behörigheter till tabellerna i den externa katalogen med hjälp av Unity Catalog.

   Du kan också använda rad- och kolumnfilter för Unity Catalog för detaljerad åtkomstkontroll.

5. Börja göra förfrågningar på data.

   Åtkomst till främmande tabeller med Unity Catalog är endast läsbehörighet för externa Hive-metaarkiv och läs- och skrivbehörighet för interna Hive-metaarkiv.

   För interna Hive-metaarkiv och externa Hive-metaarkiv uppdaterar Unity Catalog kontinuerligt tabellmetadata när de ändras i Hive-metaarkivet. För interna Hive-metaarkiv skrivs nya tabeller och tabelluppdateringar från den externa katalogen tillbaka till Hive-metaarkivet, vilket upprätthåller fullständig samverkan mellan Unity Catalog- och Hive-metaarkivkatalogerna.

Detaljerade instruktioner finns i:

• Aktivera federation av Hive-metastore för en äldre Hive-metastore-arbetsyta
• Aktivera Hive-metaarkivfederation för ett externt Hive-metaarkiv

Hur använder du Hive-metaarkivfederation under migreringen till Unity Catalog?

Med Hive-metaarkivfederationen kan du migrera till Unity Catalog stegvis genom att minska behovet av samordning mellan team och arbetsbelastningar. Om du migrerar från din Azure Databricks-arbetsytas interna Hive-metaarkiv innebär möjligheten att läsa från och skriva till både Hive-metaarkivet och Unity Catalog-metaarkivet att du kan underhålla "speglade" metaarkiv under migreringen, vilket ger följande fördelar:

• Arbetsbelastningar som körs mot utländska kataloger körs i Hive-metaarkivets kompatibilitetsläge, vilket minskar kostnaden för kodanpassning under migreringen.
• Varje arbetsbelastning kan välja att migrera oberoende av andra, med vetskapen om att data under migreringsperioden kommer att vara tillgängliga i både Hive-metaarkivet och Unity Catalog, vilket minskar behovet av att samordna mellan arbetsbelastningar som har beroenden på varandra.

Det här avsnittet beskriver ett typiskt arbetsflöde för migrering av en Azure Databricks-arbetsytas interna äldre Hive-metaarkiv till Unity Catalog, där Hive-metaarkivfederationen underlättar övergången. Det gäller inte för migrering av ett externt Hive-metaarkiv. Externa kataloger för externa Hive-metaarkiv stöder inte skrivningar.

Steg 1: Federera det interna Hive-metadatalagret

I det här steget skapar du en sekundär katalog som speglar ditt Hive-metaarkiv i Unity Catalog. Låt oss kalla det hms_in_uc.

För mer information, se Aktivera Hive-metaarkivfederation för ett äldre arbetsytas Hive-metaarkiv.

Steg 2. Kör nya arbetslaster mot den främmande katalogen i Unity Catalog

När du har en utländsk katalog på plats kan du ge SQL-analytiker och datavetenskapskonsumenter åtkomst till den och börja utveckla nya arbetsbelastningar som pekar på den. De nya arbetsflödena drar nytta av den utökade funktionsuppsättningen i Unity Catalog, inklusive åtkomstkontroller, sökning och härkomst.

I det här steget gör du vanligtvis följande:

• Välj Unity Catalog-kompatibel beräkning (dvs. standard- eller dedikerade beräkningsåtkomstlägen, SQL-lager eller serverlös beräkning). Se Krav och funktionsstöd.
• Gör den externa katalogen till den standardkatalogen på beräkningsresursen eller lägg till USE CATALOG hms_in_uc överst i koden. Eftersom scheman och tabellnamn i den externa katalogen är exakta speglar av dem i Hive-metaarkivet börjar koden referera till den externa katalogen.

Steg 3. Migrera befintliga jobb som ska köras mot den främmande katalogen

Så här migrerar du befintliga jobb för att fråga den externa katalogen:

1. Ändra standardkatalogen i jobbklustret till hms_in_uc, antingen genom att ange en egenskap i själva klustret eller genom att lägga till USE CATALOG hms_in_uc överst i koden.
2. Växla jobbet till standardbaserad eller dedikerad åtkomstlägesberäkning och uppgradera till en av Databricks Runtime-versionerna som stöder Hive-metaarkivfederation. Se Krav och funktionsstöd.
3. Be en Azure Databricks-administratör att bevilja rätt Unity Catalog-behörigheter för dataobjekten i hms_in_uc och på alla molnlagringsvägar (ingår i externa Platser i Unity Catalog) som jobbet kommer åt. Se avsnitt Hantera privilegier i Unity Catalog.

Steg 4. Inaktivera direkt åtkomst till Hive-metaarkivet

När du har migrerat alla dina arbetsuppgifter för att använda frågor mot den externa katalogen behöver du inte längre Hive-metadatalagret.

1. Inaktivera direkt åtkomst till Hive-metaarkivet.

   Se Inaktivera åtkomst till Hive-metaarkivet som används av din Azure Databricks-arbetsyta.

2. Förhindra användare från att skapa och använda kluster som kringgår åtkomstkontroll för tabeller (kluster som inte använder något läge för delad åtkomst för isolering eller en äldre anpassad klustertyp) med hjälp av beräkningsprinciper och inställningen Framtvinga användarisolering av arbetsytor.

   Se Beräkningskonfigurationer och Framtvinga klustertyper för användarisolering på en arbetsyta.

3. Gör den federerade katalogen till standardkatalogen för arbetsytan.

   Se avsnittet Hantera standardkatalogen.

Vanliga frågor

Följande avsnitt ger mer detaljerad information om federering av Hive-metastore.

Vad är återställningsläge?

Återställningsläge är en inställning på externa platser som du kan använda för att kringgå behörighetskontroller i Unity-katalogen under migreringen till Unity Catalog. Om du anger det ser du till att arbetsbelastningar som ännu inte har migrerats inte påverkas under installationsfasen.

Unity Catalog får åtkomst till molnlagring med hjälp av externa platser, som är skyddsbara objekt som definierar en sökväg och en autentiseringsuppgift för åtkomst till ditt molnlagringskonto. Du kan utfärda behörigheter för dem, till exempel READ FILES, för att styra vem som kan använda sökvägen. En utmaning under migreringsprocessen är att du kanske inte vill att Unity Catalog ska börja styra all åtkomst till sökvägen omedelbart, till exempel när du har befintliga, omigrerade arbetsbelastningar som refererar till sökvägen.

Med reservläge kan du försena den strikta tillämpningen av åtkomstkontrollen för Unity Catalog på externa platser. När reservläget är aktiverat kontrolleras först arbetsbelastningar som får åtkomst till en sökväg mot Unity Catalog-behörigheter, och om dessa kontroller misslyckas, återgår man till att använda kluster- eller notebook-begränsade autentiseringsuppgifter, såsom instansprofiler eller Apache Spark-konfigurationsegenskaper. På så sätt kan befintliga arbetsbelastningar fortsätta att använda sina aktuella autentiseringsuppgifter.

Återställningsläge är endast avsett för användning under migreringen. Du bör inaktivera det när alla arbetsbelastningar har migrerats och du är redo att tillämpa åtkomstkontroller för Unity Catalog.

Fråga granskningsloggen för användning av fallback

Använd följande fråga för att kontrollera om någon åtkomst till den externa platsen har använt återställningsläge under de senaste 30 dagarna. Om det inte finns någon återställningslägesåtkomst i ditt konto rekommenderar Databricks att du inaktiverar återställningsläget.

SELECT event_time, user_identity, action_name, request_params, response, identity_metadata
FROM system.access.audit
WHERE
request_params.fallback_enabled = 'true' AND
request_params.path LIKE '%some-path%' AND
event_time >= current_date() - INTERVAL 30 DAYS
LIMIT 10

Vad är auktoriserade sökvägar?

När du skapar en sekundär katalog som backas upp av Hive-metaarkivfederationen uppmanas du att ange auktoriserade sökvägar till molnlagringen där Hive-metaarkivtabellerna lagras. Alla tabeller som du vill komma åt via Hive-metastore-federation måste täckas av dessa sökvägar. Databricks rekommenderar att dina auktoriserade sökvägar är delvägar som är gemensamma för ett stort antal tabeller. Om du till exempel har tabeller på abfss://container@storageaccount.dfs.core.windows.net/bucket/table1, ./bucket/table2och ./bucket/table3bör du ange abfss://container@storageaccount.dfs.core.windows.net/bucket/ som en auktoriserad sökväg.

Du kan använda UCX för att identifiera de banor som finns i Hive metastore.

Auktoriserade sökvägar lägger till ett extra säkerhetslager i externa kataloger som backas upp av Hive-metaarkivfederationen. De gör det möjligt för katalogägaren att tillämpa skyddsräcken på de data som användarna kan komma åt med hjälp av federation. Detta är användbart om hive-metaarkivet tillåter användare att uppdatera metadata och godtyckligt ändra tabellplatser – uppdateringar som annars skulle synkroniseras i den externa katalogen. I det här scenariot kan användarna potentiellt omdefiniera tabeller som de redan har åtkomst till så att de pekar på nya platser som de annars inte skulle ha åtkomst till.

Kan jag federera Hive-metaarkiv med UCX?

UCX, Databricks Labs-projektet för migrering av Azure Databricks-arbetsytor till Unity Catalog, innehåller verktyg för att aktivera Hive-metaarkivfederation:

• enable-hms-federation
• create-federated-catalog

Se project readme-filen på GitHub. En introduktion till UCX finns i Använda UCX-verktygen för att uppgradera din arbetsyta till Unity Catalog.

Uppdatera metadata med Lakeflow-jobb

Unity Catalog uppdaterar automatiskt metadata för externa tabeller när en fråga ställs. Om den externa katalogens schema ändras hämtar Unity Catalog de senaste metadata när frågan körs. Detta säkerställer att du alltid ser det aktuella schemat och är optimalt för de flesta arbetsbelastningar.

Databricks rekommenderar dock att metadata uppdateras manuellt i följande fall:

• För att säkerställa konsekvens för externa tabeller som används av externa motorer. Sökvägar som kringgår Databricks Runtime utlöser inte automatiska uppdateringar, vilket kan resultera i inaktuella metadata.
• För att förbättra prestanda för arbetsbelastningar där du vill undvika metadatauppdateringen under frågeexekveringen. Genom att uppdatera metadata proaktivt kan frågor köras snabbare med cachelagrade metadata. Detta är särskilt användbart direkt efter att du har skapat en utländsk katalog eftersom den första frågan annars skulle utlösa en fullständig uppdatering.

I dessa fall schemalägger du en periodisk metadatauppdatering med hjälp av ett Lakeflow-jobb med REFRESH FOREIGN SQL-kommandot. Till exempel:

-- Refresh an entire catalog
> REFRESH FOREIGN CATALOG some_catalog;
-- Refresh a specific schema
> REFRESH FOREIGN SCHEMA some_catalog.some_schema;
-- Refresh a specific table
> REFRESH FOREIGN TABLE some_catalog.some_schema.some_table;

Konfigurera jobbet så att det körs med jämna mellanrum beroende på hur ofta du förväntar dig externa schemaändringar.

Krav och funktionsstöd

I följande tabell visas de tjänster och funktioner som stöds av Hive-metaarkivfederationen. I vissa fall visas även tjänster eller funktioner som inte stöds. I dessa tabeller står "HMS" för Hive-metastore.

Arbeta med grunda kloner

Hive-metaarkivfederationen stöder skapandet av grunda kloner från tabeller som registrerats i Hive-metaarkivet, med följande förbehåll:

• När du läser den ytliga klonen från en federerad Hive-metadatakatalog har klonen en DEGRADED konfigurationsstatus. Detta indikerar att den grunda klonen använder Hive-behörighetsmodellen, vilket kräver att användaren som läser från den grunda klontabellen har SELECT behörighet för både den grunda klonen och bastabellen.

  För att uppgradera den grunda klonen så att den överensstämmer med behörighetsmodellen för Unity-katalogen måste tabellägaren köra REPAIR TABLE <table> SYNC METADATA. När kommandot har körts ändras tabellens etableringstillstånd till ACTIVE och behörigheterna styrs därefter av Unity Catalog. Efterföljande läsningar på den grunda klonen kräver endast SELECT på själva den grunda klonen, förutsatt att kommandot körs på en datormiljö som stöder Unity Catalog.

• Ytliga kloner som skapas i DBFS eller som baseras på tabeller som är monterade i DBFS stöds inte.

Limitations

• Du kan inte fråga federerade tabeller där tabellfiler lagras utanför den federerade tabellens plats. Dessa kan omfatta tabeller där partitioner lagras utanför tabellplatsen, eller när det gäller Avro-tabeller, där schemat refereras med tabellegenskapen avro.schema.url . När du kör frågor mot sådana tabeller kan ett UNAUTHORIZED_ACCESS eller AccessDeniedException undantag genereras.