Replikace (která je popsána v tomto předchozím článku na blogu) byla vydána nějakou dobu a patří mezi nejpoužívanější funkce Apache HBase. Mít clustery replikující data s různými partnery je velmi běžné nasazení, ať už jako strategie DR nebo jednoduše jako bezproblémový způsob replikace dat mezi produkčními/stagingovými/vývojovými prostředími. I když se jedná o efektivní způsob synchronizace různých databází HBase v rámci subsekundové latence, replikace funguje pouze nad daty přijatými poté, co byla funkce povolena. To znamená, že veškerá již existující data na všech klastrech zapojených do nasazení replikace bude stále třeba zkopírovat mezi partnery nějakým jiným způsobem. Existuje poměrně málo nástrojů, které lze použít k synchronizaci již existujících dat na různých klastrech vrstevníků. Snapshots, BulkLoad, CopyTable jsou dobře známé příklady takových nástrojů, které byly popsány v předchozích příspěvcích na blogu Cloudera. V tomto článku se budeme zabývat HashTable/SyncTable, podrobně popisuje některé z jeho interní implementační logiky, klady a zápory jeho používání a srovnání s některými dalšími technikami kopírování dat uvedenými výše.
HashTable/SyncTable v kostce
HashTable/SyncTable je nástroj implementovaný jako dvě úlohy zmenšení mapy, které se provádějí jako jednotlivé kroky. Vypadá podobně jako CopyTable nástroj, který dokáže kopírovat částečné nebo celé tabulky dat. Na rozdíl od CopyTable kopíruje pouze odlišující se data mezi cílovými clustery, čímž šetří síťové i výpočetní zdroje během procedury kopírování.
Prvním krokem, který je třeba v procesu provést, je HashTable map-redukovat práci. To by mělo být spuštěno na clusteru, jehož data by měla být zkopírována do vzdáleného peeru, obvykle do zdrojového clusteru. Rychlý příklad, jak jej spustit, je uveden níže, podrobné vysvětlení každého z požadovaných parametrů je uvedeno dále v tomto článku:
hbase org.apache.hadoop.hbase.mapreduce.HashTable --families=cf moje-tabulka /hashes/test-tbl…20/04/28 05:05:48 INFO mapreduce.Job: mapa 100% snížení 100 %20/04/28 05:05:49 INFO mapreduce.Job:Job job_1587986840019_0001 dokončeno úspěšně20/04/28 05:05:49 INFO mapreduce.Job:Čítače:68…File Vstupní Formát Čítače Výstup Byty Čítače Čtení=0File Napsáno=6811788
Jakmile HashTable provádění úlohy pomocí výše uvedeného příkazu je dokončeno, některé výstupní soubory byly vygenerovány ve zdrojovém hdfs /hashes/my-table adresář:
hdfs dfs -ls -R /hashes/test-tbldrwxr-xr-x - root supergroup 0 2020-04-28 05:05 /hashes/test-tbl/hashes-rw-r--r-- 2 root supergroup 0 2020-04-28 05:05 /hashes/test-tbl/hashes/_SUCCESSdrwxr-xr-x - kořenová supergroup 0 2020-04-28 05:05 /0bl-00/test -rw-r--r-- 2 kořenová superskupina 6790909 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000/data-rw-r--r-- 2 kořenová superskupina 2087 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000/index-rw-r--r-- 2 kořenová superskupina 99 2020-04-28 05:04 /hashes/test- tbl/manifest-rw-r--r-- 2 kořenová superskupina 153 2020-04-28 05:04 /hashes/test-tbl/partitions
Ty jsou potřeba jako vstup pro SyncTable běh. SyncTable musí být spuštěn na cílovém peeru. Níže uvedený příkaz spustí SyncTable pro výstup HashTable z předchozího příkladu. Používá dryrun možnost vysvětlená dále v tomto článku:
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/hashes/test-tbl test-tbl test-tbl…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97146HASHES_NOT_MATCHED=2MATCHINGCELLS2WSTOURSTINGMATGEFFISSELLS2WSTOURSTINGTHRANGEFFING=1WSTOURSTINGMATGEFFINGF 1
Pro rychlou orientaci stačí nahradit dané parametry v obou příkladech vašimi skutečnými hodnotami prostředí. Zbytek tohoto článku se bude podrobněji zabývat implementačními detaily.
Proč dva různé kroky?
Hlavním cílem tohoto nástroje je identifikovat a zkopírovat pouze data, která mezi dvěma clustery chybí. HashTable funguje jako úloha sharding/indexování, analyzuje dávky dat tabulky a generuje hash indexy pro každou z těchto šarží. Toto jsou výstupy zapsané v souborech pod /hashes/my-table hdfs adresář předán jako jeden z parametrů úlohy. Jak již bylo zmíněno, tento výstup vyžaduje SyncTable práce. SyncTable prohledá cílovou tabulku lokálně ve stejných velikostech dávek, jaké používá HashTable, a také vypočítá hodnoty hash pro tyto dávky pomocí stejné funkce, kterou používá HashTable. Poté porovná místní dávkový hash hodnotu s hodnotou z HashTable výstup. Pokud jsou hodnoty hash stejné, znamená to, že celá dávka je ve dvou shlucích identická a na tento segment není třeba nic kopírovat. V opačném případě otevře skenování dávky ve zdrojovém clusteru, zkontroluje, zda každá z buněk již existuje v cílovém clusteru, a zkopíruje pouze ty, které se rozcházejí. Na řídkých, mírně odlišných souborech dat by to vedlo k mnohem menšímu zkopírování dat mezi těmito dvěma clustery. Vyžadovalo by to také skenování pouze malého počtu buněk ve zdroji pro kontrolu neshod.
Požadované parametry
HashTable vyžaduje pouze dva parametry:název tabulky a výstupní cestu, kam budou zapsány související hash a další meta info soubory. SyncTable používá HashTable výstupní dir jako vstup spolu s názvy tabulek ve zdrojovém a cílovém clusteru. Protože používáme HashTable /SyncTable pro přesun dat mezi vzdálenými clustery sourcezkcluster musí být definována možnost pro SyncTable . Měla by to být adresa kvora zookeeperu zdrojového clusteru. V tomto příkladu článku jsme také přímo odkazovali na adresu aktivního jmenného uzlu zdrojového clusteru, takže SyncTable přečte výstupní soubor hash přímo ze zdrojového clusteru. Případně HashTable výstup lze ručně zkopírovat ze zdrojového clusteru do vzdáleného clusteru (například pomocí distcp).
| POZNÁMKA:Práce se vzdálenými clustery pod různými sférami Kerberos je podporována pouze od CDH 6.2.1 a výše. |
Pokročilé možnosti
Oba HashTable a SyncTable nabízejí další volitelné možnosti, které lze vyladit pro optimální výsledky.
HashTable umožňuje filtrování dat podle klíče řádku a času modifikace pomocí startrow/starttime, stoprow/stoptime vlastnosti, resp. Rozsah datové sady může být také omezen verzemi a rodiny vlastnosti. velikost dávky vlastnost definuje velikost každé části, která bude hašována. To má přímý dopad na výkon synchronizace. V případech velmi malého počtu neshod může nastavení větších hodnot velikosti dávky vést k lepšímu výkonu, protože větší části souboru dat by byly ignorovány bez nutnosti skenování pomocí SyncTable.
SyncTable poskytuje sušení možnost, která umožňuje náhled změn, které mají být použity v cíli.
SyncTable výchozím chováním je zrcadlení zdrojových dat na cílové straně, takže jakákoli další buňka přítomná v cíli, ale nepřítomná ve zdroji, skončí smazáním na cílové straně. To může být nežádoucí při synchronizaci clusterů v rámci nastavení replikace Active-Active a pro takové případy doDeletes volby lze změnit na false, čímž se vynechá replikace smazání na cíli. Existuje také podobný doPuts příznak pro případy, kdy by do cílového clusteru neměly být vkládány další buňky.
Analýza výstupů
HashTable vygeneruje několik souborů s meta informacemi pro SyncTable, ty však nejsou čitelné pro člověka. Neprovádí žádné změny na existujících datech, takže související informace jsou pro kontext uživatele málo zajímavé.
SyncTable je krok, který skutečně aplikuje úpravy na cíl a může být důležité zkontrolovat jeho shrnutí, než skutečně změníte data cílového clusteru (viz dryrun výše zmíněná možnost). Zveřejňuje některé relevantní počítadla na konci mapy, což snižuje provádění. Při pohledu na hodnoty z výše uvedeného příkladu vidíme, že jich bylo 97148 hašované oddíly (oznámené BATCHES counter), který SyncTable detekoval rozdíly pouze ve dvou z nich (podle HASHES_MATCHED a HASHES_NOT_MACTHED čítače). Navíc v rámci dvou oddílů, které mají různé hodnoty hash, 17 buněk více než 2 řádky odpovídaly (jak uvádí MATCHING_CELLS a MATCHING_ROWS, v tomto pořadí), ale byly zde také 2 řádky rozbíhající se, na těchto dvou oddílech (podle RANGESNOTMATCHED a ROWSWITHDIFFS ). Nakonec SOURCEMISSINGCELLS a CÍLOVÉ CELÉ BUŇKY řekněte nám podrobně, zda byly buňky přítomny pouze ve zdrojovém nebo cílovém clusteru. V tomto příkladu měl zdrojový cluster jednu buňku, která nebyla na cíli, ale cíl měl také buňku, která nebyla na zdroji. Od SyncTable byl spuštěn bez určení dryrun možnost a nastavení doDeletes možnost false , úloha odstranila nadbytečnou buňku v cílovém clusteru a přidala další buňku nalezenou ve zdroji do cílového clusteru. Za předpokladu žádné zápisy se stane na obou clusterech, následným spuštěním úplně stejné SyncTable příkaz v cílovém clusteru nevykazuje žádné rozdíly:
hbase org.apache.hadoop.hbase.mapreduce.SyncTable --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://nn:9000/hashes /test-tbl test-tbl test-tbl…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97148…
Použitelné scénáře
Synchronizace dat
Na první pohled HashTable/SyncTable může se zdát, že se překrývá s CopyTable nástroj, ale stále existují specifické scénáře, kde by byly vhodnější oba nástroje. Jako první příklad srovnání použijte HashTable/SyncTable počáteční načtení tabulky obsahující 100 004 řádků a celkovou velikostí dat 5,17 GB vyžadovalo několik minut jen pro SyncTable dokončit:
...20/04/29 03:48:00 INFO mapreduce.Job:Běžící úloha:job_1587985272792_001120/04/29 03:48:09 INFO mapreduce.Job:Job job_15879852021792 infalse 29 03:48:09 INFO mapreduce.Zaměstnání: mapa 0% snížení 0%20/04/29 03:54:08 INFO mapreduce.Job: map 100% snížení 0%20/04/29 03:54:09 INFO mapreduce .Job:Job job_1587985272792_0011 completed successfully…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148EMPTY_BATCHES=97148HASHES_NOT_MATCHED=97148RANGESNOTMATCHED=97148ROWSWITHDIFFS=100004TARGETMISSINGCELLS=749589TARGETMISSINGROWS=100004
I na tak malém souboru dat, CopyTable proveden rychleji (přibližně 3 minuty, zatímco SyncTable zkopírování celého souboru dat trvalo 6 minut):
...20/04/29 05:12:07 INFO mapreduce.Job:Běžící úloha:job_1587986840019_000520/04/29 05:12:24 INFO mapreduce.Job:Job job_1587986/002005 infalse 29 05:12:24 INFO mapreduce.Zaměstnání: mapa 0% snížení 0%20/04/29 05:13:16 INFO mapreduce.Zaměstnání: redukce mapy 25% 0%20/04/29 05:13:49 INFO mapreduce .Job: mapa 50% snížení 0%20/04/29 05:14:37 INFO mapreduce.Job: map 75% snížení 0%20/04/29 05:15:14 INFO mapreduce.Job: mapa 100% snížení 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=0Nyní znovu použijeme oba nástroje, abychom se vypořádali s řídkými rozdíly v datové sadě. test-tbl tabulka použitá ve všech těchto příkladech má ve zdrojovém clusteru čtyři oblasti. Poté, co byla všechna původní datová sada zkopírována do cílového clusteru v předchozím příkladu, přidali jsme čtyři další řádky pouze na zdrojovou stranu, jeden pro každou ze stávajících oblastí, a poté spustili HashTable/SyncTable znovu pro synchronizaci oba shluky:
20/04/29 05:29:23 INFO mapreduce.Job:Běžící úloha:job_1587985272792_001320/04/29 05:29:39 INFO mapreduce.Job:Job job_15879852720304 u202 běžící režim:false 29:39 INFO mapreduce.Job: mapa 0% snížení 0%20/04/29 05:29:53 INFO mapreduce.Zaměstnání: mapa 50% snížení 0%20/04/29 05:30:42 INFO mapreduce.Job:mapa 100% snížení 0%20/04/29 05:30:42 INFO mapreduce.Job:Job job_1587985272792_0013 úspěšně dokončeno…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=SHCHEESHMATCHEDING14THE 5RANGESNOTMATCHED=4ROWSWITHDIFFS=4TARGETMISSINGCELLS=4TARGETMISSINGROWS=4Můžeme to vidět s pouhými čtyřmi oddíly se neshodují, SyncTable bylo podstatně rychlejší (zhruba minutu na dokončení). Pomocí CopyTable k provedení stejné synchronizace ukázaly následující výsledky:
20/04/29 08:32:38 INFO mapreduce.Job:Běžící úloha:job_1587986840019_000820/04/29 08:32:52 INFO mapreduce.Job:Job job_15879868400019_02 spuštěný:false/nepravda 32:52 INFO mapreduce.Job: mapa 0% snížení 0%20/04/29 08:33:38 INFO mapreduce.Zaměstnání: mapa 25% snížení 0%20/04/29 08:34:15 INFO mapreduce.Job:mapa 50% snížení 0%20/04/29 08:34:48 INFO mapreduce.Job: mapa 75% snížení 0%20/04/29 08:35:31 INFO mapreduce.Job: mapa 100% snížení 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=0CopyTable synchronizace tabulek trvala stejně dlouho jako při kopírování celé datové sady, i když byly pouze čtyři buňky ke kopírování. To bylo stále v pořádku pro tuto velmi malou datovou sadu as nečinným clusterem, ale v rámci produkčního použití s většími datovými sadami a kde cílový cluster může být také používán mnoha klientskými aplikacemi, které do něj zapisují data, CopyTable snížení výkonu ve srovnání s SyncTable by byla ještě vyšší.
Za zmínku stojí, že existují také další nástroje/funkce, které lze použít v kombinaci pro počáteční načtení cílového clusteru (cíl nemá vůbec žádná data), jako je export snímků, hromadné načtení nebo dokonce přímá kopie originálu tabulky dirs ze zdrojového clusteru. Pro počáteční načtení s velkým množstvím dat ke kopírování pořízení snímku tabulky a následné použití ExportSnapshot tento nástroj překoná online kopírovací nástroje, jako je SyncTable nebo CopyTable.
Kontrola integrity replikace
Další běžné použití HashTable/SyncTable je pro monitorování stavu replikace mezi clustery při odstraňování možných problémů s replikací. V tomto scénáři funguje jako alternativa k nástroji VerifyReplication. Při kontrole stavu mezi dvěma clustery obvykle buď vůbec nedochází k žádným neshodám, nebo dočasný občasný problém způsobil, že malá část větší datové sady se nesynchronizuje. V testovacím prostředí, které jsme použili v našem předchozím příkladu, by mělo být 100 008 řádků se shodnými hodnotami na obou clusterech. Spuštění SyncTable na cílovém clusteru s možností dryrun nám umožní identifikovat jakékoli rozdíly:
20/05/04 10:47:25 INFO mapreduce.Job:Běžící úloha:job_1588611199158_0004…20/05/04 10:48:48 INFO mapreduce.Job: mapa 100% snížení 0%20/105/ :48:48 INFO mapreduce.Job:Job job_1588611199158_0004 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=3753476784BYTES_IN_RESULTS=5549784600ROWS_SCANNED=100008…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97148...Unlike SyncTable we must run nástroj VerifyReplication na zdrojovém clusteru. Předáme peer id jako jeden z jeho parametrů, aby mohl najít vzdálený cluster, který má prohledat pro porovnání:20/05/04 11:01:58 INFO mapreduce.Job:Běžící úloha:job_1588611196128_0001…20/05/04 11:04:39 INFO mapreduce.Job: mapa 100% snížení 0%20/05/04 11:04:39 INFO mapreduce.Job:Job job_1588611196128_0001 dokončeno úspěšně…HBase CountersBYTES_IN_REMOTE_RESOTE_RESUMA4595preceSULTSorg751975prez525 .replication.VerifyReplication$Verifier$CountersGOODROWS=100008...Bez rozdílu najde SyncTable všechny hashe odpovídající mezi zdrojovým a cílovým oddílem, a tak se vyhne nutnosti znovu skenovat vzdálený zdrojový cluster. VerifyReplication provádí srovnání jedna po druhé pro každou buňku v obou klastrech, což již může představovat vysoké síťové náklady, i když se jedná o tak malé datové sady.
Přidání jednoho dalšího řádku do zdrojového clusteru a opětovné provedení kontrol. S VerifyReplication:
20/05/05 11:14:05 INFO mapreduce.Job:Běžící úloha:job_1588611196128_0004…20/05/05 11:16:32 INFO mapreduce.Job: mapa 100% snížení 0%20/1105/ :16:32 INFO mapreduce.Job:Job job_1588611196128_0004 úspěšně dokončeno...org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication$Verifier$CountersBADROWS=1GOODROWS=100008ONLY_IN_SOURCE= WSTABLE_SOURCE>Než budeme moci použít SyncTable, musíme znovu vygenerovat hash ve zdroji pomocí HashTable, protože je tu nyní nová buňka:
20/05/04 11:31:48 INFO mapreduce.Job:Běžící úloha:job_1588611196128_0003…20/05/04 11:33:15 INFO mapreduce.Job:Job job_15886111196128 úspěšně dokončena...Nyní SyncTable:
20/05/07 05:47:51 INFO mapreduce.Job:Běžící úloha:job_1588611199158_0014…20/05/07 05:49:20 INFO mapreduce.Job:Job job_15886111991458úspěšně dokončeno org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_NOT_MATCHED=97148MATCHINGCELLS=749593MATCHINGROWS=100008RANGESMATCHED=97147RANGETM1preMATCHEDELL=ARGETM1preMATCHEDELL=ARGETM1preMATCHEDELL=ARGETM1preMATCHEDELL=ARGETM1preMATCHEDELL=ARGETM1preMATCHEDELL=ARGETM1preMATCHEDELL=ARGETM1preMATCHEDELLMůžeme vidět prodloužení doby provádění díky dodatečnému skenování a porovnání buněk mezi dvěma vzdálenými clustery. Mezitím doba provádění VerifyReplication vykazovala malé rozdíly.
Závěr
HashTable/SyncTable je cenným nástrojem pro přesouvání dat při řešení řídkých neshod mezi dvěma klastrovými datovými sadami. Využívá dělení dat a hašování k efektivní detekci rozdílů v rozsazích mezi dvěma datovými sadami, snižuje počet buněk, které mají být naskenovány při porovnávání dat ze dvou clusterů, a zároveň zabraňuje zbytečnému vkládání již existujících hodnot do cílového clusteru. Nejde však o stříbrnou kulku, jak je ukázáno na některých výše uvedených příkladech, i když se může zdát, že se ve funkci překrývá s CopyTable Tento nástroj může nabídnout lepší výkon při manipulaci s větším, sekvenčním rozsahem nesouhlasných buněk. V tomto smyslu HashTable/SyncTable by bylo nejvhodnější v případech, kdy oba clustery již mají nějaká data uložená, nebo v případech, kdy bylo existující nastavení replikace narušeno dočasnou nedostupností jednoho z peerů.
Související články:
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/