Dela via

Databasobjekt i det äldre Hive-metaarkivet

  • Artikel

Azure Databricks-dokumentationen fokuserar på att arbeta med dataobjekt med hjälp av Unity Catalog, men de flesta instruktionerna gäller även för att arbeta med objekt som är registrerade i det äldre Hive-metaarkivet.

Den här artikeln fokuserar på hur du arbetar med databasobjekt som är registrerade i det äldre Hive-metaarkivet. Mer specifikt beskrivs i den här artikeln var arbetet med Hive-metaarkivobjekt skiljer sig från att arbeta med Unity Catalog-objekt. Den beskriver även andra beteenden som kan vara oväntade.

Databricks rekommenderar att du migrerar alla data från det äldre Hive-metaarkivet till Unity Catalog. Se Uppgradera Hive-tabeller och vyer till Unity Catalog.

Hur fungerar Datastyrning för Hive-metaarkiv?

Även om Azure Databricks-arbetsytor fortsätter att innehålla det inbyggda Hive-metaarkivet är datastyrning med Hive-metaarkiv inaktuellt. Databricks rekommenderar att du använder Unity Catalog för all datastyrning. Se Arbeta med Unity Catalog och det äldre Hive-metaarkivet.

Att aktivera en arbetsyta för Unity Catalog minskar inte möjligheten att arbeta med data som redan har registrerats i Hive-metaarkivet. Alla dataobjekt som registrerats i det äldre Hive-metaarkivet visas i Unity Catalog-gränssnitten hive_metastore i katalogen. Ett Hive-hybridmetaarkiv och en Unity Catalog-arbetsyta kan vara en användbar modell för övergång av en långvarig Hive-metaarkivarbetsyta. Datastyrnings- och prestandafördelarna med Unity Catalog är dock höga, och du bör helt överföra dina arbetsytor så snart du kan.

Hive-metaarkivet använder tabellåtkomstkontroll (tabell-ACL:er) för att hantera åtkomst till databasobjekt. Viss support finns kvar för tabellåtkomstkontroll när du använder beräkning i läget för delad åtkomst. Se Åtkomstkontroll för Hive-metaarkivtabell (äldre).

Genomströmning av autentiseringsuppgifter är ett inaktuellt mönster för datastyrning på Hive-metaarkivdatabasobjekt. Den här artikeln behandlar inte genomströmning av autentiseringsuppgifter. Se Genomströmning för autentiseringsuppgifter (äldre).

Kommentar

Om den här artikeln refererar till dataåtkomstkontroll i Hive-metaarkivet refererar den till äldre tabellåtkomstkontroll.

Vad är hive_metastore katalogen?

På en arbetsyta som är aktiverad för Unity Catalog visas alla scheman i Hive-metaarkivet som underordnade hive_metastore till katalogen i unity-katalogens namnområde på tre nivåer. Hive-metaarkivet använder faktiskt inte kataloger, och den här konstruktionen ger en startpunkt för tabeller i det äldre Hive-metaarkivet för Unity Catalog-användare. Använd följande syntax för att fråga efter tabeller i det äldre Hive-metaarkivet:

SELECT * FROM hive_metastore.schema_name.table_name

Kommentar

Du kan också ange hive_metastore katalogen som standard i Unity Catalog-aktiverade arbetsytor. Se Hantera standardkatalogen.

Scheman i Hive-metaarkiv

I det äldre Hive-metaarkivet är ett schema den högsta nivån i dataobjekthierarkin.

Det finns några viktiga skillnader mellan Unity Catalog och Hive-metaarkivet, inklusive följande:

  • Du kan inte skapa scheman i Hive-metaarkivet med hjälp av Catalog Explorer. Du kan visa och redigera behörigheter för scheman.
  • Scheman som skapats i Hive-metaarkivet kan endast använda alfanumeriska ASCII-tecken och understreck i deras namn.
  • Med Hive-metaarkivet kan du deklarera ett LOCATION för ett schema när du skapar det. Detta fungerar på samma sätt som hanterade lagringsplatser i Unity Catalog, med följande beteendemässiga skillnader:
    • Om du inte anger någon plats används standardplatsen /user/hive/warehouse/<schema-name> . Den här platsen finns på DBFS-roten, vilket inte rekommenderas för lagring av produktionsdata.
    • Den angivna sökvägen kan vara vilken molnlagringsplats som helst som är tillgänglig för användaren som skapar schemat, inklusive moln-URI:er, DBFS-rot- och DBFS-monteringar.
    • Åtkomst till platsen hanteras inte av Hive-metaarkivet.
    • Om du tar bort ett schema i Hive-metaarkivet tas alla filer på den schemaplatsen bort rekursivt, oavsett tabelltyp (hanterad eller extern).

För att undvika oavsiktlig dataförlust rekommenderar Databricks följande när du arbetar med Hive-metaarkivschemaplatser:

  • Tilldela inte en schemaplats som redan innehåller data.
  • Skapa inte en extern tabell på en schemaplats.
  • Dela inte en plats mellan flera scheman.
  • Tilldela inte en schemaplats som överlappar en annan schemaplats. Använd med andra ord inte en sökväg som är underordnad en annan schemaplats.
  • Tilldela inte en schemaplats som överlappar platsen för en extern tabell.

Hanterade tabeller i Hive-metaarkiv

Hanterade tabeller i Hive-metaarkivet har ingen av prestandafördelarna med hanterade tabeller i Unity Catalog. Precis som hanterade Tabeller i Unity Catalog använder hive-metaarkivhanterade tabeller Delta Lake som standard. Men i Hive-metaarkivet, till skillnad från Unity Catalog, kan du också skapa en hanterad tabell med de flesta andra dataformat som stöds av Azure Databricks.

Hanterade tabeller i Hive-metaarkivet skapas alltid på lagringsplatsen för det innehållande schemat. Den beräkning som du använder för att fråga en hanterad tabell måste ha åtkomst till lagringsplatsen.

Hive-metaarkivet hanterar inte datalayouten för hanterade tabeller på det sätt som Unity Catalog gör. När du släpper en hanterad tabell i Hive-metaarkivet tas alla underliggande datafiler bort omedelbart. I Unity Catalog kan UNDROP du å andra sidan en hanterad tabell i 7 dagar och data tas bort permanent inom 30 dagar.

Du kan använda sökvägsbaserad åtkomst för att läsa eller skriva data i hanterade Hive-metaarkivtabeller, medan du i Unity Catalog inte kan och inte behöver det.

Externa tabeller i Hive-metaarkiv

De flesta tabeller som skapades i Azure Databricks innan Unity Catalog introducerades konfigurerades som externa tabeller i Hive-metaarkivet. Äldre rekommendationer som gynnade externa tabeller fokuserar vanligtvis på några viktiga aspekter:

  • Du kan registrera en extern tabell ovanpå befintliga data i molnobjektlagring.
  • Du kan komma åt datafiler direkt i externa tabeller från externa system för läsningar eller skrivningar.
  • Datafiler togs inte bort om tabellen togs bort av misstag.
  • Eftersom externa tabeller kräver en LOCATION, var produktionsdata mindre benägna att oavsiktligt hamna i DBFS-roten.

Azure Databricks rekommenderar nu hanterade Unity Catalog-tabeller för de flesta tabelldatalagring. Se Arbeta med hanterade tabeller.

Vyer i Hive-metaarkiv

Du kan deklarera en vy i Hive-metaarkivet som backas upp av alla datakällor som stöds av Azure Databricks. I Unity Catalog kan du bara deklarera vyer mot Unity Catalog-tabeller och vyer, inklusive utländska tabeller, materialiserade vyer och deltadelningstabeller.

På grund av möjligheten att deklarera vyer mot icke-tabellbaserade datakällor kan vyer i Hive-metaarkivet ge oväntad eller oavsiktlig åtkomst till data i kombination med andra åtkomstkonfigurationer i användarmiljön.

Tänk till exempel på följande:

  • En tabell my_table definieras med hjälp av DBFS-monteringssökvägen /mnt/my_table.
    • Autentiseringsuppgifter för DBFS-montering lagras på arbetsytan, så alla användare har åtkomst till den här sökvägen som standard.
  • Tabell-ACL:er används för att begränsa åtkomsten till my_table en grupp användare.
    • ACL:er för äldre tabeller gäller endast för beräkning som är konfigurerade med läget för delad åtkomst eller SQL-lager.
  • En vy my_view definieras direkt mot moln-URI:n som stöder samma datafiler 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'.
    • URI-autentiseringsuppgifter förlitar sig på åtkomstprinciper som definierats i Spark-sessionen eller beräkningskonfigurationen.

Vyn my_view har följande egenskaper:

  • Den använder inte autentiseringsuppgifterna för DBFS-monteringen som används för att montera molnobjektlagring till /mnt/my_table.
  • Den respekterar inte tabell-ACL:er som angetts för my_table, oavsett beräkningskonfigurationer.
  • Det kräver en dataåtkomstprincip som konfigurerats för beräkning som ger läsåtkomst till 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'.

Kommentar

Detta är ett exempel på oväntat beteende som du kan stöta på, och inte omfattande alla potentiella fallgropar som presenteras av vyer i äldre Hive-metaarkiv. Databricks rekommenderar att du använder Unity Catalog för alla vydefinitioner.

Äldre Hive-tabeller och HiveQL-stöd

Azure Databricks innehåller visst äldre stöd för Hive-tabeller och HiveQL-funktioner. Den här funktionen är en rest av tidiga versioner av Azure Databricks och Apache Hadoop-ekosystemet med verktyg. Databricks rekommenderar inte att du använder Hive-tabeller eller andra Hive-funktioner, eftersom den här funktionen inte är optimerad och saknar stöd i vissa beräkningskonfigurationer.

I följande artiklar beskrivs äldre Hive-funktioner: