Replikacja (opisana w tym poprzednim artykule na blogu) została wydana od jakiegoś czasu i jest jedną z najczęściej używanych funkcji Apache HBase. Posiadanie klastrów replikujących dane z różnymi urządzeniami równorzędnymi jest bardzo powszechnym wdrożeniem, czy to jako strategia DR, czy po prostu jako płynny sposób replikacji danych między środowiskami produkcyjnymi/stabilnymi/rozwojowymi. Chociaż jest to wydajny sposób utrzymywania synchronizacji różnych baz danych HBase w czasie poniżej sekundy, replikacja działa tylko na danych pozyskiwanych po włączeniu tej funkcji. Oznacza to, że wszelkie dane istniejące wcześniej we wszystkich klastrach biorących udział we wdrażaniu replikacji nadal będą musiały zostać skopiowane między urządzeniami równorzędnymi w inny sposób. Istnieje wiele narzędzi, których można użyć do synchronizacji istniejących danych w różnych klastrach równorzędnych. Migawki, BulkLoad, CopyTable to dobrze znane przykłady takich narzędzi omówione w poprzednich wpisach na blogu Cloudera. W tym artykule omówimy HashTable/SyncTable, szczegółowo opisując niektóre z jej wewnętrznej logiki implementacji, zalety i wady jej używania oraz porównanie z niektórymi innymi technikami kopiowania danych wymienionymi powyżej.
HashTable/SyncTable w skrócie
HashTable/SyncTable to narzędzie zaimplementowane jako dwa zadania map-reduce, które są wykonywane jako pojedyncze kroki. Wygląda podobnie do CopyTable narzędzie, które może wykonywać zarówno częściowe, jak i całe kopie danych tabeli. W przeciwieństwie do Kopiuj tabelę kopiuje tylko rozbieżne dane między klastrami docelowymi, oszczędzając zarówno sieć, jak i zasoby obliczeniowe podczas procedury kopiowania.
Pierwszym krokiem do wykonania w procesie jest HashTable mapa-redukcja pracy. Powinno to zostać uruchomione w klastrze, którego dane powinny zostać skopiowane do zdalnego węzła, zwykle klastra źródłowego. Poniżej przedstawiono krótki przykład jego uruchomienia, szczegółowe wyjaśnienie każdego z wymaganych parametrów znajduje się w dalszej części tego artykułu:
hbase org.apache.hadoop.hbase.mapreduce.HashTable --families=cf my-table /hashs/test-tbl…20/04/28 05:05:48 INFO mapreduce.Job:mapa 100% zmniejsz 100 %20/04/28 05:05:49 INFO mapreduce.Job:Zadanie zadanie_1587986840019_0001 zakończone pomyślnie20/04/28 05:05:49 INFO mapreduce.Job:Liczniki:68…Liczniki formatu wejściowego pliku Bajty Odczyt=0Liczniki formatu wyjściowego pliku Bajty Napisane=6811788
Gdy HashTable wykonanie zadania powyższym poleceniem zostało zakończone, niektóre pliki wyjściowe zostały wygenerowane w źródłowym hdfs /hashes/my-table katalog:
hdfs dfs -ls -R /hashs/test-tbldrwxr-xr-x - root supergrupa 0 2020-04-28 05:05 /hashs/test-tbl/hashes-rw-r--r-- 2 root supergrupa 0 2020-04-28 05:05 /hashs/test-tbl/hashes/_SUCCESSdrwxr-xr-x - główna supergrupa 0 2020-04-28 05:05 /hashs/test-tbl/hashs/part-r-00000 -rw-r--r-- 2 supergrupa główna 6790909 2020-04-28 05:05 /hashes/test-tbl/hashs/part-r-00000/data-rw-r--r-- 2 supergrupa główna 20879 2020-04-28 05:05 /hashes/test-tbl/hashs/part-r-00000/index-rw-r--r-- 2 supergrupa główna 99 2020-04-28 05:04 /hashes/test- tbl/manifest-rw-r--r-- 2 supergrupa główna 153 2020-04-28 05:04 /hashs/test-tbl/partitions
Są one potrzebne jako dane wejściowe dla SyncTable biegać. Tabela synchronizacyjna musi być uruchomiony na docelowym urządzeniu równorzędnym. Poniższe polecenie uruchamia SyncTable dla wyjścia HashTable z poprzedniego przykładu. Używa dryrun opcja wyjaśniona w dalszej części tego artykułu:
hbase org.apache.hadoop.hbase.mapreduce.SyncTable --dryrun --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://source- cluster-active-nn/hashs/test-tbl test-tbl test-tbl…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97146HASHES_NOT_MATCHED=2MATCHINGCELLSMAT=17MATCHINGROWSWOTSCHESCHESCHELLFIFRANS=2DIFRAN 1
Jako szybkie odniesienie możesz po prostu zastąpić podane parametry w obu przykładach rzeczywistymi wartościami środowiskowymi. Pozostała część tego artykułu omówi szczegółowo szczegóły implementacji.
Dlaczego dwa różne kroki?
Głównym celem tego narzędzia jest identyfikacja i kopiowanie tylko danych, których brakuje między dwoma klastrami. Tabela haszująca działa jako zadanie shardingu/indeksowania, analizując partie danych tabeli i generując indeksy haszujące dla każdej z tych partii. To są dane wyjściowe zapisane w plikach pod /hashs/my-table katalog hdfs przekazany jako jeden z parametrów zadania. Jak wspomniano wcześniej, dane wyjściowe są wymagane przez SyncTable stanowisko. Tabela synchronizacyjna skanuje lokalnie tabelę docelową w tych samych rozmiarach partii, co używane przez HashTable, a także oblicza wartości skrótu dla tych partii przy użyciu tej samej funkcji używanej przez HashTable. Następnie porównuje lokalny skrót partii wartość z wartością z HashTable wyjście. Jeśli wartości skrótu są równe, oznacza to, że cała partia jest identyczna w dwóch klastrach i nie trzeba nic kopiować w tym segmencie. W przeciwnym razie otwiera skanowanie partii w klastrze źródłowym, sprawdzając, czy każda z komórek już istnieje w klastrze docelowym, kopiując tylko te, które są rozbieżne. W przypadku nielicznych, nieco innych zestawów danych, spowodowałoby to znacznie mniej danych kopiowanych między dwoma klastrami. Wymagałoby to również przeskanowania tylko niewielkiej liczby komórek w źródle w celu sprawdzenia niezgodności.
Wymagane parametry
Tabela haszująca wymaga tylko dwóch parametrów:nazwy tabeli i ścieżki wyjściowej, w której zostaną zapisane powiązane skróty i inne pliki metainformacji. SyncTable używa HashTable output dir jako input, wraz z nazwami tabel odpowiednio w źródłowym i docelowym klastrze. Ponieważ używamy HashTable /SyncTable do przenoszenia danych między zdalnymi klastrami, sourcezkcluster opcja musi być zdefiniowana dla SyncTable . Powinien to być adres kworum zookeepera klastra źródłowego. W tym przykładzie artykułu odnieśliśmy się również bezpośrednio do adresu aktywnego węzła nazw klastra źródłowego, więc SyncTable odczyta plik wyjściowy skrótu bezpośrednio z klastra źródłowego. Alternatywnie, HashTable dane wyjściowe można ręcznie skopiować z klastra źródłowego do klastra zdalnego (na przykład za pomocą distcp).
| UWAGA:Praca ze zdalnymi klastrami w innej dziedzinie Kerberos jest obsługiwana tylko od CDH 6.2.1. |
Opcje zaawansowane
Obie HashTable i SyncTable oferują dodatkowe opcje opcjonalne, które można dostroić w celu uzyskania optymalnych wyników.
Tabela mieszająca pozwala na filtrowanie danych zarówno według klucza wiersza, jak i czasu modyfikacji, z startrow/starttime, stoprow/stoptime odpowiednio właściwości. Zakres zbioru danych może być również ograniczony przez wersje i rodziny nieruchomości. wielkość partii właściwość definiuje rozmiar każdej części, która będzie zahaszowana. Ma to bezpośredni wpływ na wydajność synchronizacji. W przypadku bardzo niewielu niezgodności ustawienie większych wartości rozmiaru partii może prowadzić do lepszej wydajności, ponieważ większa część zestawu danych byłaby ignorowana bez konieczności skanowania przez SyncTable.
Tabela synchronizacyjna zapewnia dryrun opcja umożliwiająca podgląd zmian do zastosowania w celu.
SyncTable domyślnym zachowaniem jest lustrzane odbicie danych źródłowych po stronie docelowej, więc każda dodatkowa komórka obecna w miejscu docelowym, ale nieobecna w źródle, zostanie usunięta po stronie docelowej. Może to być niepożądane podczas synchronizowania klastrów w konfiguracji replikacji typu aktywna-aktywna i w takich przypadkach doDeletes opcje można zmienić na fałsz, pomijając replikację usunięć w miejscu docelowym. Istnieje również podobny doPuts flaga dla przypadków, w których dodatkowe komórki nie powinny być wstawiane do klastra docelowego.
Analiza wyników
Tabela mieszająca wyprowadza kilka plików z metainformacjami dla SyncTable, te jednak nie są czytelne dla człowieka. Nie wprowadza żadnych zmian na istniejących danych, więc powiązane informacje są mało interesujące dla kontekstu użytkownika.
Tabela synchronizacyjna jest krokiem, który naprawdę stosuje modyfikacje w celu i może być ważne, aby przejrzeć jego podsumowanie przed zmianą danych klastra docelowego (patrz dryrun opcja wymieniona powyżej). Publikuje kilka odpowiednich liczników na końcu mapy, aby zmniejszyć wykonanie. Patrząc na wartości z powyższego przykładu, widzimy, że było 97148 zaszyfrowane partycje (zgłaszane przez PARTIE licznik), który SyncTable wykrył rozbieżności tylko w dwóch z nich (zgodnie z HASHES_MATCHED i HASHES_NOT_MACTHED liczniki). Dodatkowo, w obrębie dwóch partycji o różnych wartościach skrótu, 17 komórek ponad 2 rzędy pasowały (zgłoszone przez MATCHING_CELLS i MATCHING_ROWS, odpowiednio), ale były też 2 rzędy rozbieżne, na tych dwóch partycjach (zgodnie z RANGESNOTMATCHED i ROWSWITHDIFFS ). Wreszcie SOURCEMISSINGCELLS i TARGETMISSINGCELLS powiedz nam szczegółowo, czy komórki były obecne tylko w klastrze źródłowym czy docelowym. W tym przykładzie klaster źródłowy miał jedną komórkę, która nie znajdowała się w miejscu docelowym, ale cel miał również komórkę, która nie znajdowała się w źródle. Od SyncTable został uruchomiony bez określenia dryrun opcja i ustawienie doDeletes opcja fałsz , zadanie usunęło dodatkową komórkę w klastrze docelowym i dodało dodatkową komórkę znalezioną w źródle do klastra docelowego. Zakładając, że nie zapisuje w obu klastrach, kolejne uruchomienie tego samego SyncTable polecenie w klastrze docelowym nie wykaże żadnych różnic:
hbase org.apache.hadoop.hbase.mapreduce.SyncTable --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://nn:9000/hash /test-tbl test-tbl test-tbl…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97148…
Odpowiednie scenariusze
Synchronizacja danych
Na pierwszy rzut oka HashTable/SyncTable może wydawać się, że nakłada się na Kopiuj tabelę narzędzie, ale nadal istnieją konkretne scenariusze, w których którekolwiek z narzędzi byłoby bardziej odpowiednie. Jako pierwszy przykład porównawczy przy użyciu HashTable/SyncTable początkowe ładowanie tabeli zawierającej 100 004 wierszy i łączny rozmiar danych 5,17 GB wymagało kilku minut tylko dla SyncTable do ukończenia:
...20/04/29 03:48:00 INFO mapreduce.Job:Uruchamianie zadania:job_1587985272792_001120/04/29 03:48:09 INFO mapreduce.Job:Zadanie zadanie_1587985272792_0011 działające w trybie uber :false20/04/ 29 03:48:09 INFO mapreduce.Job: mapa 0% zmniejsz 0%20/04/29 03:54:08 INFO mapreduce.Job: mapa 100% zmniejsz 0%20/04/29 03:54:09 INFO mapreduce .Job:zadanie Job_1587985272792_0011 zostało zakończone pomyślnie…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148EMPTY_BATCHES=97148HASHES_NOT_MATCHED=97148RANGESNOTMATCHED=97148ROW89TARGETRGETMIS1000S9504SNawet na tak małym zbiorze danych CopyTable wykonywane szybciej (około 3 minuty, podczas gdy SyncTable skopiowanie całego zestawu danych zajęło 6 minut):
...20/04/29 05:12:07 INFO mapreduce.Job:Uruchamianie zadania:job_1587986840019_000520/04/29 05:12:24 INFO mapreduce.Job:Zadanie zadanie_1587986840019_0005 działające w trybie uber :false20/04/ 29 05:12:24 INFO mapreduce.Job: mapa 0% zmniejsz 0%20/04/29 05:13:16 INFO mapreduce.Job: mapa 25% zmniejsz 0% 20/04/29 05:13:49 INFO mapreduce .Job: mapa 50% zmniejsz 0% 20/04/29 05:14:37 INFO mapreduce.Job: mapa 75% zmniejsz 0% 20/04/29 05:15:14 INFO mapreduce.Job: mapa 100% zmniejsz 0 %20/04/29 05:15:14 INFO mapreduce.Job:Job job_1587986840019_0005 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=2787236791BYTES_IN_RESULTS=5549784428MILLIS_BETWEEN_NEXTS=130808NOT_SERVING_REGION_EXCEPTION=0NUM_SCANNER_RESTARTS=0NUM_SCAN_RESULTS_STALE=0REGIONS_SCANNED=4REMOTE_RPC_CALLS=1334REMOTE_RPC_RETRIES=0ROWS_FILTERED=0ROWS_SCANNED=100004RPC_CALLS=2657RPC_RETRIES=0Teraz ponownie użyjmy obu narzędzi, aby poradzić sobie z nielicznymi różnicami w zestawie danych. tabela testowa Tabela używana we wszystkich tych przykładach ma cztery regiony w klastrze źródłowym. Po skopiowaniu całego oryginalnego zestawu danych do klastra docelowego w poprzednim przykładzie, dodaliśmy cztery dodatkowe wiersze tylko po stronie źródłowej, po jednym dla każdego z istniejących regionów, a następnie uruchomiliśmy HashTable/SyncTable ponownie, aby zsynchronizować oba klastry:
20/04/29 05:29:23 INFO mapreduce.Job:Uruchamiam zadanie:job_1587985272792_001320/04/29 05:29:39 INFO mapreduce.Job:Job job_1587985272792_0013 działa w trybie uber :false20/04/29 05:29:39 INFO mapreduce.Job: mapa 0% zmniejsz 0%20/04/29 05:29:53 INFO mapreduce.Job: mapa 50% zmniejsz 0%20/04/29 05:30:42 INFO mapreduce.Job:mapa 100% zmniejsz 0%20/04/29 05:30:42 INFO mapreduce.Job:Job job_1587985272792_0013 ukończony pomyślnie…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97144HASHES_NOTCHINGCHING=5RANGESNOTMATCHED=4ROWSWITHDIFFS=4TARGETMISSINGCELLS=4TARGETMISSINGROWS=4Możemy to zobaczyć po zaledwie czterech niezgodność partycji, SyncTable był znacznie szybszy (około minuty do ukończenia). Korzystanie z Kopiuj tabelę wykonać tę samą synchronizację pokazał następujące wyniki:
20/04/29 08:32:38 INFO mapreduce.Job:Uruchamiam zadanie:job_1587986840019_000820/04/29 08:32:52 INFO mapreduce.Job:Job job_1587986840019_0008 działa w trybie uber :false20/04/29 08:32:52 INFO mapreduce.Job: mapa 0% zmniejsz 0%20/04/29 08:33:38 INFO mapreduce.Job: mapa 25% zmniejsz 0%20/04/29 08:34:15 INFO mapreduce.Job:mapa 50% zmniejsz 0%20/04/29 08:34:48 INFO mapreduce.Job: mapa 75% zmniejsz 0%20/04/29 08:35:31 INFO mapreduce.Job: mapa 100% zmniejsz 0%20/ 04/29 08:35:32 INFO mapreduce.Job:Job job_1587986840019_0008 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=2762547723BYTES_IN_RESULTS=5549784600MILLIS_BETWEEN_NEXTS=340672NOT_SERVING_REGION_EXCEPTION=0NUM_SCANNER_RESTARTS=0NUM_SCAN_RESULTS_STALE=0REGIONS_SCANNED=4REMOTE_RPC_CALLS=1323REMOTE_RPC_RETRIES=0ROWS_FILTERED=0ROWS_SCANNED=100008RPC_CALLS=2657RPC_RETRIES=0Kopiuj tabelę synchronizacja tabel zajęła tyle samo czasu, co kopiowanie całego zestawu danych, mimo że były tylko cztery komórki do skopiowania. To nadal było w porządku w przypadku tego bardzo małego zestawu danych i bezczynnego klastra, ale w produkcyjnych przypadkach użycia z większymi zestawami danych i gdzie klaster docelowy może być również używany przez wiele aplikacji klienckich zapisujących w nim dane, CopyTable pogorszenie wydajności w porównaniu z SyncTable byłby jeszcze wyższy.
Warto wspomnieć, że istnieją również dodatkowe narzędzia/funkcje, które można wykorzystać w połączeniu do wstępnego ładowania klastra docelowego (cel nie zawiera żadnych danych), takie jak eksport migawek, ładowanie zbiorcze, a nawet bezpośrednia kopia oryginału katalogi tabel z klastra źródłowego. W przypadku początkowego wczytywania z dużymi ilościami danych do skopiowania wykonaj zrzut tabeli, a następnie użyj ExportSnapshot narzędzie przewyższa narzędzia do kopiowania online, takie jak SyncTable lub Kopiuj tabelę.
Sprawdzanie integralności replikacji
Innym typowym zastosowaniem HashTable/SyncTable jest monitorowanie stanu replikacji między klastrami podczas rozwiązywania ewentualnych problemów z replikacją. W tym scenariuszu działa jako alternatywa dla narzędzia VerifyReplication. Zazwyczaj podczas sprawdzania stanu między dwoma klastrami nie ma żadnych niezgodności lub tymczasowy problem częściowy spowodował brak synchronizacji niewielkiej części większego zestawu danych. W środowisku testowym, którego używaliśmy w poprzednim przykładzie, powinno być 100008 wierszy z pasującymi wartościami w obu klastrach. Uruchomienie SyncTable w klastrze docelowym z opcją dryrun pozwoli nam zidentyfikować wszelkie różnice:
20/05/04 10:47:25 INFO mapreduce.Job:Uruchamiam zadanie:job_1588611199158_0004…20/05/04 10:48:48 INFO mapreduce.Job:mapa 100% zmniejsz 0% 20/05/04 10 :48:48 INFO mapreduce.Job:Job job_1588611199158_0004 ukończony pomyślnie…HBase CountersBYTES_IN_REMOTE_RESULTS=3753476784BYTES_IN_RESULTS=5549784600ROWS_SCANNED=100008…org.apache.hadoop.hbase.CountableBCHEES97Mamcreduce. narzędzie VerifyReplication w klastrze źródłowym. Przekazujemy identyfikator peera jako jeden z jego parametrów, aby mógł znaleźć zdalny klaster do przeskanowania w celu porównania:20/05/04 11:01:58 INFO mapreduce.Job:Uruchamianie zadania:job_1588611196128_0001…20/05/04 11:04:39 INFO mapreduce.Job:mapa 100% zmniejsz 0%20/05/04 11:04:39 INFO mapreduce.Job:Job job_1588611196128_0001 ukończony pomyślnie…HBase CounterBYTES_IN_REMOTE_RESULTS=2761955495BYTES_IN_RESULTS=5549784600. .replication.VerifyReplication$Verifier$CountersGOODROWS=100008...Bez różnic, SyncTable znajduje wszystkie skróty pasujące między partycjami źródłowymi i docelowymi, dzięki czemu unika konieczności ponownego skanowania zdalnego klastra źródłowego. VerifyReplication przeprowadza jedno po drugim porównanie dla każdej komórki w obu klastrach, co może już wiązać się z wysokimi kosztami sieci, nawet w przypadku tak małych zestawów danych.
Dodanie jednego dodatkowego wiersza w klastrze źródłowym i ponowne wykonanie kontroli. Z VerifyReplication:
20/05/05 11:14:05 INFO mapreduce.Job:Uruchamianie zadania:job_1588611196128_0004…20/05/05 11:16:32 INFO mapreduce.Job:mapa 100% zmniejsz 0% 20/05/05 11 :16:32 INFO mapreduce.Job:Job job_1588611196128_0004 ukończony pomyślnie…org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication$Verifier$CountersBADROWS=1GOODROWS=100008ONLY_IN_SOURCE_TABLE_ROWS=1…Zanim będziemy mogli użyć SyncTable, musimy ponownie wygenerować skróty w źródle za pomocą HashTable, ponieważ jest teraz nowa komórka:
20/05/04 11:31:48 INFO mapreduce.Job:Uruchamianie zadania:zadanie_1588611196128_0003…20/05/04 11:33:15 INFO mapreduce.Job:Zadanie zadanie_1588611196128_0003 zakończone pomyślnie...Teraz SyncTable:
20/05/07 05:47:51 INFO mapreduce.Job:Uruchamianie zadania:zadanie_1588611199158_0014…20/05/07 05:49:20 INFO mapreduce.Job:Zadanie zadanie_1588611199158_0014 zakończone pomyślnie… org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_NOT_MATCHED=97148MATCHINGCELLS=749593MATCHINGROWS=100008RANGESMATCHED=97147RANGESNOTMATCHED=1ROWSWITHDIFFS=1MISELLSTSTARGETMISS=1MISELLSRGETMISS=1Widzimy wzrost czasu wykonania z powodu dodatkowego skanowania i porównania komórek między dwoma zdalnymi klastrami. W międzyczasie czas wykonania VerifyReplication wykazywał niewielkie różnice.
Wniosek
HashTable/SyncTable jest cennym narzędziem do przenoszenia danych, gdy mamy do czynienia z rzadkimi niezgodnościami między zestawami danych dwóch klastrów. Wykorzystuje partycjonowanie danych i mieszanie, aby skutecznie wykrywać różnice w zakresach z dwóch zestawów danych, zmniejszając liczbę komórek do przeskanowania podczas porównywania danych z dwóch klastrów, jednocześnie unikając niepotrzebnego umieszczania już istniejących wartości w klastrze docelowym. Nie jest to jednak srebrna kula, jak pokazano na niektórych przykładach powyżej, chociaż może wydawać się, że pokrywa się w funkcji z CopyTable narzędzie, to ostatnie może zapewnić lepszą wydajność podczas obsługi większego, sekwencyjnego zakresu niedopasowanych komórek. W tym sensie HashTable/SyncTable byłoby najbardziej odpowiednie w przypadkach, gdy oba klastry mają już pewne dane lub w przypadkach, gdy istniejąca konfiguracja replikacji została zakłócona przez tymczasową niedostępność jednego z węzłów.
Powiązane artykuły:
https://blog.cloudera.com/apache-hbase-replication-overview/
https://blog.cloudera.com/approaches-to-backup-and-disaster-recovery-in-hbase/
https://blog.cloudera.com/online-apache-hbase-backups-with-copytable/
https://blog.cloudera.com/introduction-to-apache-hbase-snapshots/
