CopyTable to proste narzędzie Apache HBase, które, jak można się spodziewać, może służyć do kopiowania poszczególnych tabel w klastrze HBase lub z jednego klastra HBase do drugiego. W tym poście na blogu porozmawiamy o tym, czym jest to narzędzie, dlaczego chcesz go używać, jak z niego korzystać, a także o kilku typowych zastrzeżeniach dotyczących konfiguracji.
Przypadki użycia:
CopyTable jest w istocie zadaniem Apache Hadoop MapReduce, które wykorzystuje standardowy interfejs ścieżki odczytu HBase Scan do odczytu rekordów z pojedynczej tabeli i zapisuje je w innej tabeli (prawdopodobnie w oddzielnym klastrze) przy użyciu standardowego interfejsu ścieżki zapisu HBase Put. Może być używany do wielu celów:
- Wewnętrzna kopia tabeli (zdjęcie biedaka)
- Zdalna kopia zapasowa instancji HBase
- Przyrostowe kopie tabeli HBase
- Częściowe kopie tabeli HBase i zmiany schematu tabeli HBase
Założenia i ograniczenia:
Narzędzie CopyTable ma kilka podstawowych założeń i ograniczeń. Po pierwsze, jeśli jest używany w sytuacji z wieloma klastrami, oba klastry muszą być w trybie online, a instancja docelowa musi mieć obecną tabelę docelową z tymi samymi rodzinami kolumn zdefiniowanymi jako tabela źródłowa.
Ponieważ narzędzie korzysta ze standardowych skanów i odsunięć, klaster docelowy nie musi mieć tej samej liczby węzłów lub regionów. W rzeczywistości może mieć różną liczbę tabel, różną liczbę serwerów regionu i może mieć zupełnie inne granice podziału regionów. Ponieważ kopiujemy całe tabele, możesz użyć ustawień optymalizacji wydajności, takich jak ustawienie większych wartości pamięci podręcznej skanera, aby uzyskać większą wydajność. Korzystanie z interfejsu put oznacza również, że można tworzyć kopie między klastrami różnych wersji podrzędnych. (0.90.4 -> 0.90.6, CDH3u3 -> CDH3u4) lub wersje kompatybilne przewodowo (0.92.1 -> 0.94.0).
Wreszcie, HBase zapewnia tylko gwarancje ACID na poziomie wiersza; oznacza to, że podczas działania CopyTable mogą pojawić się nowo wstawione lub zaktualizowane wiersze, a te równoczesne edycje zostaną albo całkowicie uwzględnione, albo całkowicie wykluczone. Chociaż wiersze będą spójne, nie ma gwarancji co do spójności, przyczynowości ani kolejności umieszczania w innych wierszach.
Wewnętrzna kopia tabeli (zdjęcie biedaka)
Wersje HBase do najnowszych wersji 0.94.x włącznie nie obsługują tworzenia migawek tabel. Pomimo ograniczeń ACID HBase, CopyTable może być używany jako naiwny mechanizm tworzenia migawek, który tworzy fizyczną kopię określonej tabeli.
Załóżmy, że mamy tabelę tableOrig z rodzinami kolumn cf1 i cf2. Chcemy skopiować wszystkie jego dane do tableCopy. Najpierw musimy utworzyć tableCopy z tymi samymi rodzinami kolumn:
srcCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell
Możemy wtedy utworzyć i skopiować tabelę z nową nazwą w tej samej instancji HBase:
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=tableCopy tableOrig
To uruchamia zadanie MR, które skopiuje dane.
Zdalna kopia zapasowa instancji HBase
Załóżmy, że chcemy skopiować dane do innego klastra. Może to być jednorazowa kopia zapasowa, zadanie okresowe lub może służyć do ładowania początkowego w celu replikacji między klastrami. W tym przykładzie będziemy mieć dwa oddzielne klastry:srcCluster i dstCluster.
W tym przypadku z wieloma klastrami CopyTable jest procesem wypychania — Twoim źródłem będzie instancja HBase, do której odwołuje się bieżący plik hbase-site.xml, a dodane argumenty wskazują klaster docelowy i tabelę. Zakłada się również, że wszystkie narzędzia MR TaskTracker mogą uzyskać dostęp do wszystkich węzłów HBase i ZK w klastrze docelowym. Ten mechanizm konfiguracji oznacza również, że można uruchomić to jako zadanie w zdalnym klastrze, zastępując konfiguracje hbase/mr, aby używać ustawień z dowolnego dostępnego klastra zdalnego i określić węzły ZK w klastrze docelowym. Może to być przydatne, jeśli chcesz skopiować dane z klastra HBase z niższymi umowami SLA i nie chcesz bezpośrednio uruchamiać na nich zadań MR.
Użyjesz ustawienia –peer.adr, aby określić zespół ZK docelowego klastra (np. klaster, do którego kopiujesz). W tym celu potrzebujemy adresu IP i portu kworum ZK, a także głównego węzła HBase ZK dla naszej instancji HBase. Załóżmy, że jednym z tych komputerów jest srcClusterZK (wymieniony w hbase.zookeeper.quorum) i że używamy domyślnego portu klienta zk 2181 (hbase.zookeeper.property.clientPort) i domyślnego rodzica /hbase (zookeeper.znode). rodzic). (Uwaga:jeśli masz dwie instancje HBase używające tego samego ZK, potrzebujesz innego zookeeper.znode.parent dla każdego klastra.
# create new tableOrig on destination cluster dstCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell # on source cluster run copy table with destination ZK quorum specified using --peer.adr # WARNING: In older versions, you are not alerted about any typo in these arguments! srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=dstClusterZK:2181:/hbase tableOrig
Pamiętaj, że możesz użyć argumentu –new.name z parametrem –peer.adr, aby skopiować do tabeli o innej nazwie w dstCluster.
# create new tableCopy on destination cluster dstCluster$ echo "create 'tableCopy', 'cf1', 'cf2'" | hbase shell # on source cluster run copy table with destination --peer.adr and --new.name arguments. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=dstClusterZK:2181:/hbase --new.name=tableCopy tableOrig
Spowoduje to skopiowanie danych z tableOrig w srcCluster do tabeli tableCopy dstCluster.
Przyrostowe kopie tabeli HBase
Po utworzeniu kopii tabeli w klastrze docelowym, jak skopiować nowe dane, które są później zapisywane w klastrze źródłowym? Naiwnie możesz ponownie uruchomić zadanie CopyTable i skopiować całą tabelę. Jednak CopyTable zapewnia bardziej wydajny mechanizm kopiowania przyrostowego, który po prostu kopiuje zaktualizowane wiersze z srcCluster do kopii zapasowej dstCluster określonej w określonym przedziale czasu. W ten sposób po początkowej kopii możesz mieć okresowe zadanie cron, które kopiuje dane tylko z poprzedniej godziny z srcCluster do dstCuster.
Odbywa się to poprzez określenie argumentów –starttime i –endtime. Czasy są podawane w milisekundach dziesiętnych od czasu epoki Uniksa.
# WARNING: In older versions, you are not alerted about any typo in these arguments! # copy from beginning of time until timeEnd # NOTE: Must include start time for end time to be respected. start time cannot be 0. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=1 --endtime=timeEnd ... # Copy from starting from and including timeStart until the end of time. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=timeStart ... # Copy entries rows with start time1 including time1 and ending at timeStart excluding timeEnd. srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=timestart --endtime=timeEnd
Częściowe kopie tabeli HBase i zmiany schematu tabeli HBase
Domyślnie CopyTable skopiuje wszystkie rodziny kolumn z pasujących wierszy. CopyTable udostępnia opcje kopiowania tylko danych z określonych rodzin kolumn. Może to być przydatne do kopiowania oryginalnych danych źródłowych i wykluczania pochodnych rodzin kolumn danych, które są dodawane podczas przetwarzania.
Dodając te argumenty, kopiujemy tylko dane z określonych rodzin kolumn.
- –rodziny=srcCf1
- –rodziny=srcCf1,srcCf2
Począwszy od wersji 0.92.0 możesz kopiować podczas zmiany nazwy rodziny kolumn:
- –families=srcCf1:dstCf1
- skopiuj z srcCf1 do dstCf1
- –rodziny=srcCf1:dstCf1,dstCf2,srcCf3:dstCf3
- skopiuj z srcCf1 do destCf1, skopiuj dstCf2 do dstCf2 (bez zmiany nazwy) i srcCf3 do dstCf3
Pamiętaj, że dstCf* musi być obecny w tabeli dstCluster!
Począwszy od wersji 0.94.0 oferowane są nowe opcje kopiowania znaczników usuwania i uwzględniania ograniczonej liczby nadpisanych wersji. Wcześniej, jeśli wiersz zostanie usunięty w klastrze źródłowym, usunięcie nie zostanie skopiowane — zamiast tego przestarzała wersja tego wiersza pozostanie w klastrze docelowym. Wykorzystuje to niektóre zaawansowane funkcje wersji 0.94.0.
- –versions=vers
- gdzie vers to liczba wersji komórek do skopiowania (domyślnie jest to 1, czyli tylko najnowsza)
- –all.cells
- również skopiuj znaczniki usunięcia i usunięte komórki
Typowe pułapki
Klient HBase w wersjach 0.90.x, 0.92.x i 0.94.x zawsze używa pliku zoo.cfg, jeśli znajduje się w ścieżce klasy, nawet jeśli plik hbase-site.xml określa inne ustawienia konfiguracji kworum ZooKeeper. Ta „funkcja” powoduje powszechny problem w CDH3 HBase, ponieważ jego pakiety domyślnie zawierają katalog, w którym zoo.cfg znajduje się w ścieżce klas HBase. Może to i prowadzi do frustracji podczas próby użycia CopyTable (HBASE-4614). Obejściem tego problemu jest wykluczenie pliku zoo.cfg ze ścieżki klasy HBase i określenie właściwości konfiguracyjnych ZooKeeper w pliku hbase-site.xml. http://hbase.apache.org/book.html#zookeeper
Wniosek
CopyTable zapewnia proste, ale skuteczne ubezpieczenie odzyskiwania po awarii dla wdrożeń HBase 0.90.x (CDH3). W połączeniu z funkcją replikacji znalezioną i obsługiwaną w HBase opartym na CDH4 HBase 0.92.x, przyrostowe funkcje CopyTable stają się mniej wartościowe, ale jego podstawowa funkcjonalność jest ważna dla ładowania zreplikowanej tabeli. Podczas gdy bardziej zaawansowane funkcje, takie jak migawki HBase (HBASE-50), mogą pomóc w odzyskiwaniu po awarii, gdy zostaną zaimplementowane, CopyTable nadal będzie użytecznym narzędziem dla administratora HBase.
