Obiekty bazy danych w starszym magazynie metadanych Hive

Dokumentacja Azure Databricks koncentruje się na pracy z obiektami danych przy użyciu Unity Catalog, ale większość instrukcji dotyczy również pracy z obiektami zarejestrowanymi w starszym magazynie metadanych 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, where pracy z obiektami magazynu metadanych Hive różni się od pracy z obiektami Catalog aparatu Unity. Opisuje również inne zachowania, które mogą być nieoczekiwane.

Usługa Databricks zaleca migrowanie wszystkich danych ze starszego magazynu metadanych Hive do środowiska Unity Catalog. Zobacz Zaktualizuj Ule tables i views do Jedności 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 używanie Unity Catalog do zarządzania danymi. Zobacz Praca z Unity Catalog oraz starszą metadane Hive.

Włączenie obszaru roboczego dla środowiska Unity Catalog nie zmniejsza możliwości pracy z danymi już zarejestrowanymi w magazynie metadanych Hive. Wszystkie obiekty danych zarejestrowane w starszym magazynie metadanych Hive pojawiają się w interfejsach aparatu Unity Catalog w hive_metastorecatalog. Hybrydowy magazyn metadanych Hive i obszar roboczy środowiska Unity Catalog może być przydatnym modelem do przejścia z istniejącego, dobrze ugruntowanego obszaru roboczego magazynu metadanych Hive. Jednak zalety zapewniania ładu i wydajności danych w środowisku Unity Catalog są wysokie i należy w pełni przenieść obszary robocze tak szybko, jak to możliwe.

Repozytorium metadanych Hive używa table kontroli dostępu (ACLtable) do zarządzania dostępem do obiektów bazy danych. Pozostaje pewne wsparcie dla kontroli dostępu table podczas korzystania z zasobów obliczeniowych w trybie dostępu współdzielonego. Zobacz magazyn metadanych Hive table kontroli dostępu (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).

Co to jest hive_metastorecatalog?

W obszarze roboczym, który jest zintegrowany z aparatem Unity Catalog, wszystkie schematy w magazynie metadanych Hive są wyświetlane jako elementy podrzędne hive_metastorecatalog w trzystopniowej przestrzeni nazw Unity Catalog. Magazyn metadanych Hive w rzeczywistości nie używa catalogs. Ta konstrukcja zapewnia punkt startowy do tables w starszym magazynie metadanych Hive dla użytkowników Unity Catalog. Użyj następującej składni, aby wykonać zapytanie tables w starszym Hive Metastore.

SELECT * FROM hive_metastore.schema_name.table_name

Schematy w magazynie metadanych Hive

W tradycyjnym magazynie metadanych Hive, schema oznacza najwyższy poziom w hierarchii obiektów danych.

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

• Nie można tworzyć schematów w magazynie metadanych Programu Hive przy użyciu programu Catalog Explorer. 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 schema podczas tworzenia. Ta funkcja działa podobnie do obiektów Unity Catalog zarządzanych lokalizacji magazynu z następującymi różnicami behawioralnymi:
  • 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 schema, w tym identyfikatory URI chmury, katalog główny systemu DBFS i punkty montowania DBFS.
  • Dostęp do lokalizacji nie jest zarządzany przez magazyn metadanych Hive.
  • Usunięcie schema w magazynie metadanych Hive powoduje ponowne usunięcie wszystkich plików w tej lokalizacji schema niezależnie od typu table (zarządzanego lub zewnętrznego).

Aby uniknąć przypadkowej utraty danych, usługa Databricks zaleca następujące kroki podczas pracy z magazynem metadanych Hive w lokalizacjach schema:

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

Zarządzane tables w magazynie metadanych Hive

Zarządzane tables w metastore Hive nie mają żadnych korzyści związanych z wydajnością, które mają zarządzane tables w środowisku Unity Catalog. Podobnie jak Catalog zarządzane tablesaparatu Unity, zarządzane tables magazynu metadanych Hive domyślnie używają usługi Delta Lake. Jednak w magazynie metadanych Hive, w przeciwieństwie do środowiska Unity Catalog, można również utworzyć zarządzany zasób table, korzystając z większości innych formatów danych obsługiwanych przez Azure Databricks.

Zarządzane tables w magazynie metadanych Hive są zawsze tworzone w lokalizacji pamięci, w której znajduje się schema. Urządzenie obliczeniowe używane do wykonywania zapytań względem zarządzanego table musi mieć dostęp do lokalizacji przechowywania.

Magazyn metadanych Hive nie zarządza układem danych zarządzanych tables w sposób, w jaki robi to Unity Catalog. Po usunięciu zarządzanej jednostki table w magazynie metadanych Hive wszystkie bazowe pliki danych zostaną natychmiast usunięte. Z kolei w Unity Catalogmożna UNDROP zarządzaną table przez 7 dni, a dane są trwale usuwane w ciągu 30 dni.

Możesz użyć dostępu opartego na ścieżkach, aby odczytać lub zapisać dane w zarządzanym przez Hive metastore tables, podczas gdy w środowisku Unity Catalog, nie możesz tego zrobić i nie ma takiej potrzeby.

Zewnętrzne tables w magazynie metadanych Hive

Większość tables utworzonych w usłudze Azure Databricks przed wprowadzeniem aparatu Unity Catalog została skonfigurowana jako zewnętrzne tables w magazynie metadanych Hive. Starsze zalecenia, które faworyzowały zewnętrzne tables, zwykle skupiały się na kilku kluczowych aspektach.

• Możesz zarejestrować zewnętrzną table na podstawie istniejących danych w magazynie obiektów w chmurze.
• Możesz uzyskać bezpośredni dostęp do plików danych w zewnętrznym tables z systemów zewnętrznych na potrzeby odczytu lub zapisu.
• Pliki danych nie zostały usunięte, jeśli table został przypadkowo usunięty.
• Ze względu na to, że zewnętrzne tables wymagają LOCATION, zmniejszyło się ryzyko przypadkowego umieszczenia danych produkcyjnych w katalogu głównym systemu plików DBFS.

Usługa Azure Databricks zaleca teraz zarządzanie Unity Catalog i tables dla większości magazynów danych tabelarycznych. Zobacz Pracę z zarządzanym tables.

Views w repozytorium metadanych Hive

Widok można zadeklarować w magazynie metadanych Hive wspieranym przez dowolne źródło danych obsługiwane przez usługę Azure Databricks. W Unity Catalogmożna zadeklarować tylko views względem Unity Catalogtables i views, w tym obcych tables, zmaterializowanych viewsi Delta Sharing tables.

Ze względu na możliwość deklarowania views dla źródeł danych innych niż tabelaryczne, konfiguracja views w magazynie metadanych Hive może prowadzić do nieoczekiwanego lub niezamierzonego dostępu do danych w połączeniu z innymi ustawieniami dostępu w środowisku użytkownika.

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

• table my_table jest definiowana przy użyciu ścieżki montowania DBFS /mnt/my_table.
  • DBFS mount credentials są przechowywane w obszarze roboczym, więc wszyscy użytkownicy mają dostęp do tej ścieżki domyślnie.
• Table ACL są używane do ograniczania dostępu do my_table dla grupy użytkowników.
  • Dziedziczne listy ACL table mają zastosowanie tylko w środowiskach obliczeniowych skonfigurowanych z trybem współdzielonego 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 .
  • URI credentials polega na zasadach dostępu zdefiniowanych w sesji platformy Spark lub konfiguracji obliczeniowej.

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

• Nie korzysta z montowania DBFS credentials, używanego do montowania magazynu obiektów w chmurze do /mnt/my_table.
• Nie uwzględnia table list ACL set na my_table, niezależnie od konfiguracji obliczeniowych.
• 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 .

Obsługa starszych technologii Hive tables i HiveQL

Usługa Azure Databricks obsługuje starsze funkcje technologii Hive tables i 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 Hive tables ani innych funkcji Hive, ponieważ ta funkcjonalność nie jest zoptymalizowana i brakuje jej obsługi w niektórych konfiguracjach obliczeniowych.

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

• Zgodność z technologią Apache Hive
• CREATE TABLE w formacie Hive
• INSERT OVERWRITE DIRECTORY z formatu Hive
• LOAD DATA
• Integracja z funkcjami zdefiniowanymi przez użytkownika programu Hive, funkcjami UDAFs i funkcjami zdefiniowanymi przez użytkownika