Udostępnij przez

Obiekty bazy danych w starszym magazynie metadanych Hive

Dokumentacja Azure Databricks koncentruje się na operowaniu na obiektach danych przy użyciu Unity Catalog, ale większość instrukcji można również zastosować do pracy z obiektami zarejestrowanymi w starszym metastore Hive.

Ten artykuł koncentruje się na sposobie pracy z obiektami bazy danych zarejestrowanymi w starszym magazynie metadanych Hive. W szczególności w tym artykule wyjaśniono, gdzie praca z obiektami metastore Hive różni się od pracy z obiektami katalogu Unity. Opisuje również inne zachowania, które mogą być nieoczekiwane.

Databricks zaleca przeprowadzenie migracji wszystkich danych ze starszego magazynu metadanych Hive do Unity Catalog. Zobacz Uaktualnianie tabel i widoków Hive do Unity Catalog.

Jak działa nadzór nad danymi magazynu metadanych Hive?

Mimo że obszary robocze usługi Azure Databricks nadal zawierają wbudowany magazyn metadanych Hive, ład danych przy użyciu magazynu metadanych Hive jest przestarzały. Databricks zaleca korzystanie z Unity Catalog do zarządzania wszystkimi danymi. Zobacz Praca ze starszym metastore'em Hive w połączeniu z Unity Catalog.

Włączenie obszaru roboczego dla Unity Catalog nie zmniejsza możliwości pracy z danymi już zarejestrowanymi w metastore Hive. Wszystkie obiekty danych zarejestrowane w starszym metastore Hive są widoczne w interfejsach katalogu Unity w katalogu hive_metastore. Hybrydowy metastore Hive i obszar roboczy Unity Catalog mogą być przydatnym modelem umożliwiającym przejście długotrwałego obszaru roboczego metastore Hive. Jednak zalety zarządzania danymi i wydajności Unity Catalog są znaczące i należy jak najszybciej w pełni przenieść obszary robocze.

Metastore Hive używa listy kontrolne dostępu do tabel (ACL tabel) do zarządzania dostępem do obiektów bazy danych. Pewna obsługa w zakresie kontroli dostępu do tabel pozostaje dostępna, gdy używasz obliczeń w standardowym trybie dostępu. Zobacz Kontrola dostępu do tabel magazynu metadanych Hive (starsza wersja).

Przekazywanie poświadczeń jest przestarzałym wzorcem ładu danych w obiektach bazy danych magazynu metadanych Hive. Ten artykuł nie zawiera adresu przekazywania poświadczeń. Zobacz Przekazywanie poświadczeń (starsza wersja).

Uwaga

W przypadku, gdy ten artykuł odnosi się do kontroli dostępu do danych w magazynie metadanych Hive, odnosi się on do starszej kontroli dostępu do tabel.

Co to jest hive_metastore katalog?

W obszarze roboczym, w którym włączono katalog Unity, wszystkie schematy w magazynie metadanych Hive są wyświetlane jako elementy podrzędne hive_metastore katalogu w trójpoziomowej przestrzeni nazw katalogu Unity. Magazyn metadanych Hive faktycznie nie używa katalogów, a to rozwiązanie zapewnia punkt wejścia do tabel w starszym magazynie metadanych Hive dla użytkowników Unity Catalog. Użyj następującej składni, aby wykonywać zapytania o tabele w starszym magazynie metadanych Hive:

SELECT * FROM hive_metastore.schema_name.table_name

Uwaga

Opcjonalnie możesz ustawić hive_metastore katalog jako domyślny katalog roboczy w obszarach roboczych z katalogiem Unity. Zobacz Zarządzanie domyślnym katalogiem.

Schematy w magazynie metadanych Hive

W starszym magazynie metadanych Hive schemat jest najwyższym poziomem w hierarchii obiektów danych.

Istnieją pewne istotne różnice między katalogiem Unity a magazynem metadanych Hive, w tym takie jak:

  • Nie można przy użyciu Eksploratora katalogu tworzyć schematów w magazynie metadanych Hive. Uprawnienia do schematów można wyświetlać i edytować.
  • Schematy utworzone w magazynie metadanych Hive mogą używać tylko alfanumerycznych znaków ASCII i podkreśleń w nazwach.
  • Magazyn metadanych Hive umożliwia zadeklarowanie LOCATION dla schematu podczas tworzenia. Ta funkcja działa podobnie do lokalizacji magazynu zarządzanych przez Unity Catalog, z następującymi różnicami w działaniu:
    • Jeśli nie podasz lokalizacji, zostanie użyta lokalizacja /user/hive/warehouse/<schema-name> domyślna. Ta lokalizacja znajduje się w katalogu głównym systemu plików DBFS, który nie jest zalecany do przechowywania żadnych danych produkcyjnych.
    • Podana ścieżka może być dowolną lokalizacją magazynu w chmurze dostępną dla użytkownika, który tworzy schemat, w tym identyfikatory URI chmury, katalog główny DBFS i punkty montowania DBFS.
    • Dostęp do lokalizacji nie jest zarządzany przez magazyn metadanych Hive.
    • Usunięcie schematu w magazynie metadanych Hive powoduje ponowne usunięcie wszystkich plików w tej lokalizacji schematu niezależnie od typu tabeli (zarządzanego lub zewnętrznego).

Aby uniknąć przypadkowej utraty danych, usługa Databricks zaleca następujące zalecenia podczas pracy z lokalizacjami schematu magazynu metadanych Hive:

  • Nie przypisuj lokalizacji schematu, która zawiera już dane.
  • Nie twórz tabeli zewnętrznej w lokalizacji schematu.
  • Nie udostępniaj lokalizacji między wieloma schematami.
  • Nie przypisuj lokalizacji schematu, która nakłada się na inną lokalizację schematu. Innymi słowy, nie używaj ścieżki będącej elementem podrzędnym innej lokalizacji schematu.
  • Nie przypisuj lokalizacji schematu, która nakłada się na lokalizację tabeli zewnętrznej.

Zarządzane tabele w Hive metastore

Tabele zarządzane w magazynie metadanych Hive nie mają żadnych korzyści wydajnościowych, jakie mają zarządzane tabele w katalogu Unity. Podobnie jak tabele zarządzane katalogiem Unity, tabele zarządzane magazynem metadanych Hive domyślnie używają technologii Delta Lake. Jednak w metastore Hive, w przeciwieństwie do Unity Catalog, można również utworzyć zarządzaną tabelę przy użyciu większości innych formatów danych obsługiwanych przez platformę Azure Databricks.

Tabele zarządzane w magazynie metadanych Hive są zawsze tworzone w lokalizacji magazynu zawierającego schemat. Obliczenia używane do wykonywania zapytań względem tabeli zarządzanej muszą mieć dostęp do lokalizacji magazynu.

Metastore Hive nie zarządza układem danych w tabelach zarządzanych tak, jak to robi Unity Catalog. Po usunięciu tabeli zarządzanej w magazynie metadanych Programu Hive wszystkie bazowe pliki danych zostaną natychmiast usunięte. Z drugiej strony w Katalogu Unity można przechowywać UNDROP tabelę przez 7 dni, a dane są trwale usuwane w ciągu 30 dni.

Dostęp oparty na ścieżkach umożliwia odczytywanie lub zapisywanie danych w tabelach zarządzanych magazynu metadanych Hive, podczas gdy w Unity Catalog nie możesz i nie musisz.

Tabele zewnętrzne w magazynie metadanych Hive

Większość tabel utworzonych w usłudze Azure Databricks przed wprowadzeniem Unity Catalog została skonfigurowana jako tabele zewnętrzne w Hive metastore. Starsze zalecenia, które preferują tabele zewnętrzne, zwykle koncentrują się na kilku kluczowych aspektach:

  • Możesz zarejestrować tabelę zewnętrzną na podstawie istniejących danych w magazynie obiektów w chmurze.
  • Możesz uzyskać bezpośredni dostęp do plików danych w tabelach zewnętrznych z systemów zewnętrznych w celu odczytu lub zapisu.
  • Pliki danych nie zostały usunięte, jeśli tabela została przypadkowo porzucona.
  • Ponieważ tabele zewnętrzne wymagają LOCATION, ryzyko przypadkowego umieszczenia danych produkcyjnych w katalogu głównym DBFS było mniejsze.

Usługa Azure Databricks zaleca teraz tabele zarządzane przez Unity Catalog dla większości przechowywania danych tabelarycznych. Zobacz Tabele zarządzane przez katalog Unity w usłudze Azure Databricks dla Delta Lake i Apache Iceberg.

Widoki w Hive metastore

Widok można zadeklarować w magazynie metadanych Hive wspieranym przez dowolne źródło danych obsługiwane przez usługę Azure Databricks. W katalogu Unity można deklarować widoki tylko dla tabel i widoków katalogu Unity, w tym tabel obcych, zmaterializowanych widoków i tabel Delta Sharing.

Ze względu na możliwość deklarowania widoków względem źródeł danych innych niż tabelaryczne widoki w magazynie metadanych Hive mogą udzielić nieoczekiwanego lub niezamierzonego dostępu do danych w połączeniu z innymi konfiguracjami dostępu w środowisku użytkownika.

Rozważmy na przykład następujące kwestie:

  • Tabela my_table jest definiowana przy użyciu ścieżki montowania /mnt/my_table systemu plików DBFS.
    • Poświadczenia instalacji systemu DBFS są przechowywane w obszarze roboczym, więc wszyscy użytkownicy mają domyślnie dostęp do tej ścieżki.
  • ACL-e tabel są używane do ograniczania dostępu do my_table dla grupy użytkowników.
    • Starsze listy ACL tabel mają zastosowanie tylko dla obliczeń skonfigurowanych w standardowym trybie dostępu lub w magazynach SQL.
  • Widok my_view jest definiowany bezpośrednio względem identyfikatora URI chmury, który wspiera te same pliki 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'danych .
    • Poświadczenia identyfikatora URI opierają się na zasadach dostępu zdefiniowanych w sesji Spark lub konfiguracji przetwarzania.

Widok my_view ma następujące właściwości:

  • Nie używa poświadczeń dostępu do DBFS używanych do podłączania magazynu obiektów w chmurze do /mnt/my_table.
  • Nie respektuje list ACL tabeli ustawionych na my_table, niezależnie od konfiguracji komputerowych.
  • Wymaga to zasad dostępu do danych skonfigurowanych dla zasobów obliczeniowych, które zapewniają dostęp do odczytu do 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'programu .

Uwaga

Jest to jeden przykład nieoczekiwanego zachowania, które można napotkać, a nie kompleksowym przeglądem wszystkich potencjalnych pułapek przedstawionych przez widoki w starszym magazynie metadanych Hive. Databricks zaleca używanie Unity Catalogu dla wszystkich definicji widoku.

Starsze tabele hive i obsługa technologii HiveQL

Usługa Azure Databricks obejmuje starszą obsługę tabel Hive i funkcji HiveQL. Ta funkcja jest pozostałością wczesnych wersji usługi Azure Databricks i ekosystemu narzędzi Apache Hadoop. Usługa Databricks nie zaleca używania tabel programu Hive ani innych funkcji programu Hive, ponieważ ta funkcja nie jest zoptymalizowana i nie obsługuje niektórych konfiguracji obliczeniowych.

W poniższych artykułach opisano starsze funkcje programu Hive:

  • Last updated on