Tabele zarządzane są tabelami należącymi do Hive, gdzie cały cykl życia danych tabel jest zarządzany i kontrolowany przez Hive. Tabele zewnętrzne to tabele, w których Hive ma luźne powiązania z danymi. Replication Manager replikuje tabele zewnętrzne z powodzeniem do klastra docelowego. Tabele zarządzane są przekształcane w tabele zewnętrzne po replikacji.

Hive wspiera replikację tabel zewnętrznych z danymi do klastra docelowego i zachowuje wszystkie właściwości tabel zewnętrznych. Uprawnienia i własność plików danych są zachowane tak, że odpowiednie procesy zewnętrzne mogą kontynuować zapisywanie w nich nawet po awarii.

Zapisy na tabelach zewnętrznych są wykonywane za pomocą poleceń SQL Hive, a pliki danych mogą być również dostępne i zarządzane przez procesy spoza Hive. Jeśli zewnętrzna tabela lub partycja zostanie usunięta, tylko metadane związane z tabelą lub partycją są usuwane, ale podstawowe pliki danych pozostają nienaruszone. Typowym przykładem dla tabeli zewnętrznej jest uruchamianie zapytań analitycznych na danych należących do HBase lub Druid za pomocą Hive, gdzie pliki danych są zapisywane przez HBase lub Druid, a Hive odczytuje je do analizy.

Gdy tworzysz harmonogram dla polityki replikacji Hive, ustaw częstotliwość tak, aby zmiany były replikowane wystarczająco często, aby uniknąć zbyt dużych kopii.

Możesz natknąć się na następujące przypadki użycia podczas replikacji Hive:

Przypadek użycia aktualizacji Replication Manager W normalnym scenariuszu, jeśli miałeś zewnętrzne tabele, które były replikowane jako tabele zarządzane, po procesie aktualizacji musisz usunąć te tabele z celu i ustawić katalog bazowy. W następnej instancji zostaną one zreplikowane jako tabele zewnętrzne. Konflikty w lokalizacji danych tabel zewnętrznych dla replikacji wielu klastrów źródłowych na ten sam klaster docelowy Aby obsłużyć konflikty w lokalizacji danych tabel zewnętrznych dla replikacji wielu klastrów źródłowych na ten sam klaster docelowy, Menadżer Replikacji przypisuje unikalny katalog bazowy dla każdego klastra źródłowego, pod który kopiowane są dane tabel zewnętrznych z odpowiedniego klastra źródłowego. Na przykład, jeśli lokalizacja tabeli zewnętrznej w klastrze źródłowym to /ext/hbase_data, to lokalizacja w klastrze docelowym po replikacji to <base_dir>/ext/hbase_data. Możesz użyć polecenia DESCRIBE TABLE, aby śledzić nową lokalizację zewnętrznych tabel. Konflikty replikacji między HDFS a lokalizacją tabeli zewnętrznej Hive Kiedy uruchamiasz politykę replikacji Hive na tabeli zewnętrznej, dane są przechowywane w katalogu docelowym w określonej lokalizacji. Następnie, gdy uruchamiamy politykę replikacji HDFS, która próbuje skopiować dane w tej samej lokalizacji tabeli zewnętrznej, Replication Manager zapewnia, że dane Hive nie zostaną nadpisane przez HDFS. Na przykład, gdy uruchamiasz politykę replikacji Hive na tabeli zewnętrznej, polityka tworzy katalog docelowy /tmp/db1/ext1. Kiedy uruchamiamy politykę replikacji HDFS, nie powinna ona nadpisywać danych poprzez replikację na katalogu /tmp/db1/ext1. Konflikty podczas procesu replikacji tabel zewnętrznych Konflikty pojawiają się, gdy dwie polityki replikacji Hive na DB1 i DB2 (z tego samego klastra źródłowego lub różnych klastrów źródłowych) mają tabele zewnętrzne, które wskazują na tę samą lokalizację danych (na przykład /abc) i są replikowane do tego samego klastra docelowego. Aby uniknąć takich konfliktów, musisz ustawić różne ścieżki dla konfiguracji katalogu bazowego tabeli zewnętrznej dla obu polityk. Na przykład, ustaw /db1 dla DB1 i /db2 dla DB2. Zapewnia to, że docelowa lokalizacja danych tabeli zewnętrznej jest inna dla obu baz danych. Na przykład: /db1/abcd i /db2/abcd.

Articles

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.