Replikering (som behandlas i den här tidigare bloggartikeln) har släppts ett tag och är bland de mest använda funktionerna i Apache HBase. Att ha kluster som replikerar data med olika peers är en mycket vanlig implementering, oavsett om det är en DR-strategi eller helt enkelt som ett sömlöst sätt att replikera data mellan produktions-/staging-/utvecklingsmiljöer. Även om det är ett effektivt sätt att hålla olika HBase-databaser synkroniserade inom en fördröjning på mindre än en sekund, fungerar replikeringen endast över data som tas in efter att funktionen har aktiverats. Det betyder att all befintlig data om alla kluster som är involverade i replikeringsdistributionen fortfarande måste kopieras mellan peers på något annat sätt. Det finns en hel del verktyg som kan användas för att synkronisera redan existerande data på olika peer-kluster. Snapshots, BulkLoad, CopyTable är välkända exempel på sådana verktyg som behandlats i tidigare Cloudera-blogginlägg. I den här artikeln kommer vi att ta upp HashTable/SyncTable, beskriver en del av dess interna implementeringslogik, för- och nackdelar med att använda den, och hur den kan jämföras med några av de andra datakopieringsteknikerna som nämns ovan.
HashTable/SyncTable i ett nötskal
HashTable/SyncTable är ett verktyg implementerat som två kartreducerande jobb som exekveras som individuella steg. Den liknar CopyTable verktyg, som kan utföra både partiella eller hela tabelldatakopior. Till skillnad från CopyTable den kopierar bara divergerande data mellan målkluster, vilket sparar både nätverks- och datorresurser under kopieringsproceduren.
Det första steget som ska utföras i processen är HashTable kartreducera jobb. Detta bör köras på klustret vars data ska kopieras till fjärranslutningen, normalt källklustret. Ett snabbt exempel på hur man kör det visas nedan, detaljerad förklaring av var och en av de nödvändiga parametrarna ges längre fram i den här artikeln:
hbase org.apache.hadoop.hbase.mapreduce.HashTable --families=cf my-table /hashes/test-tbl…20/04/28 05:05:48 INFO mapreduce.Job: map 100% reducera 100 %20/04/28 05:05:49 INFO mapreduce.Job:Job job_1587986840019_0001 slutfört framgångsrikt20/04/28 05:05:49 INFO mapreduce.Job:Räknare:68...Fil Utmatningsformat Räknare Bytes Läs =0 Räknare Bytes Skrivet=6811788
När HashTable jobbexekveringen med kommandot ovan har slutförts, några utdatafiler har genererats i källkoden hdfs /hashes/my-table katalog:
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 supergrupp 0 0 2020-04-28 05:05 /hashes/test-tbl/hashes/_SUCCESSdrwxr-xr-x - rotsupergrupp 0 2020-04-28 05:05 /blt-0s0/hash-0/hash-0 -rw-r--r-- 2 rotsupergrupp 6790909 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000/data-rw-r--r-- 2 rotsupergrupp 7 9 20 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000/index-rw-r--r-- 2 rotsupergrupp 99 2020-04-28 05:04 /hashes/test- tbl/manifest-rw-r--r-- 2 rotsupergrupp 153 2020-04-28 05:04 /hashes/test-tbl/partitions
Dessa behövs som indata för SyncTable springa. SyncTable måste lanseras på målkamraten. Kommandot nedan körs SyncTable för utdata från HashTable från föregående exempel. Den använder dryrun alternativ som förklaras senare i den här artikeln:
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=2MATCHINGMATCHED=2MATCHINGMATCHINGCELLS 2MATCHINGMATCHED=2MATCHINGMATCHED=2MATCHINGMATCHED=17146 1
Som en snabbreferens kan du bara ersätta de givna parametrarna i båda exemplen med dina faktiska miljövärden. Resten av den här artikeln kommer att täcka implementeringsdetaljerna mer på djupet.
Varför två olika steg?
Huvudmålet med detta verktyg är att identifiera och kopiera endast data som saknas mellan de två klustren. HashTable fungerar som ett skärnings-/indexeringsjobb, analyserar partier av tabelldata och genererar hashindex för var och en av dessa batcher. Dessa är utdata som skrivits i filerna under /hashes/my-table hdfs-katalogen skickades som en av jobbparametrarna. Som nämnts tidigare krävs denna utdata av SyncTable jobb. SyncTable skannar måltabellen lokalt i samma batchstorlekar som används av HashTable, och beräknar även hash-värden för dessa batcher med samma funktion som används av HashTable. Den jämför sedan lokal batch-hash värde med det från HashTable produktion. Om hash-värdena är lika betyder det att hela batchen är identisk i de två klustren, och ingenting behöver kopieras på det segmentet. Annars öppnar den en skanning för batchen i källklustret, kontrollerar om var och en av cellerna redan finns i målklustret, kopierar endast de som divergerar. På glesa, något olika datamängder, skulle detta resultera i att mycket mindre data kopieras mellan de två klustren. Det skulle också kräva att endast ett litet antal celler skannades i källan för att kontrollera om det inte överensstämmer.
Obligatoriska parametrar
HashTable kräver bara två parametrar:tabellnamnet och utdatasökvägen där relaterade hash- och andra metainformationsfiler kommer att skrivas. SyncTable använder HashTable mata ut dir som indata, tillsammans med tabellnamnen i källan respektive i målklustret. Eftersom vi använder HashTable /SyncTable för att flytta data mellan fjärrkluster, sourcezkcluster alternativet måste definieras för SyncTable . Detta bör vara zookeepers kvorumadress för källklustret. I det här artikelexemplet hade vi också refererat till källklustrets aktiva namnnodsadress direkt, så att SyncTable kommer att läsa hash-utdatafilen direkt från källklustret. Alternativt HashTable utdata kan kopieras manuellt från källkluster till fjärrkluster (med distcp, till exempel).
| OBS:Arbeta med fjärrkluster under olika kerberos-sfärer stöds endast från CDH 6.2.1 och framåt. |
Avancerade alternativ
Båda HashTable och SyncTable erbjuder extra tillval som kan ställas in för optimala resultat.
HashTable tillåter filtrering av data efter både radnyckel och ändringstid, med startrad/starttid, stopprad/stopptid respektive fastigheter. Datauppsättningens omfattning kan också begränsas av versioner och familjer egenskaper. batchstorleken egenskapen definierar storleken på varje del som ska hashas. Detta påverkar direkt synkroniseringsprestandan. I fall av mycket få felmatchningar kan inställning av större batchstorleksvärden leda till bättre prestanda eftersom större delar av datamängden skulle ignoreras utan att behöva skannas av SyncTable.
SyncTable ger en dryrun alternativ som tillåter en förhandsgranskning av ändringarna som ska tillämpas i målet.
SyncTable Standardbeteendet är att spegla källdata på målsidan, så att alla ytterligare celler som finns i målet men saknas i källan kommer att raderas på målsidan. Det kan vara oönskat när du synkroniserar kluster under en Active-Active replikeringsinställning och i sådana fall doDeletes alternativ kan ställas om till falska, och hoppar över replikering av raderingar på målet. Det finns också en liknande doPuts flagga för fall där ytterligare celler inte ska infogas i målklustret.
Analysering av utdata
HashTable matar ut några filer med metainformation för SyncTable, dessa är dock inte läsbara för människor. Den gör inga ändringar på befintliga data, så relaterad information är av lite intresse för en användarkontext.
SyncTable är steget som verkligen tillämpar ändringarna på målet och det kan vara viktigt att granska dess sammanfattning innan du faktiskt ändrar målklusterdata (se dryrun alternativ som nämns ovan). Den publicerar några relevanta räknare i slutet av kartan minskar exekvering. Om vi tittar på värdena från ovanstående exempel kan vi se att det fanns 97148 partitioner hashade (rapporterade av BATCHES räknare), som SyncTable upptäckt avvikelser i endast två av dem (enligt HASHES_MATCHED och HASHES_NOT_MACTHED räknare). Dessutom, inom de två partitionerna som har olika hash, 17 celler över 2 rader matchade (som rapporterats av MATCHING_CELLS och MATCHING_ROWS, respektive), men det fanns också 2 rader divergerande, på dessa två partitioner (enligt RANGESNOTMATCHED och ROWSWITHDIFFS ). Slutligen, SOURCEMISSINGCELLS och MÅLSANNANDECELLER berätta i detalj om celler endast fanns på käll- eller målkluster. I det här exemplet hade källklustret en cell som inte fanns på målet, men målet hade också en cell som inte fanns på källan. Sedan SyncTable kördes utan att ange dryrun alternativ och inställning doDeletes alternativet till false , jobbet har tagit bort den extra cellen i målklustret och lagt till den extra cellen som hittades i källan till målklustret. Förutsatt att ingen skriver ske på båda klustren, en efterföljande körning av samma SyncTable kommandot i målklustret skulle inte visa några skillnader:
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...
Tillämpliga scenarier
Datasynkronisering
Vid första anblicken, HashTable/SyncTable kan tyckas överlappa med CopyTable verktyg, men det finns fortfarande specifika scenarier där båda verktygen skulle vara mer lämpliga. Som ett första jämförelseexempel, med HashTable/SyncTable för en initial laddning av en tabell som innehåller 100 004 rader och en total datastorlek på 5,17 GB krävs några minuter bara för SyncTable för att slutföra:
...20/04/29 03:48:00 INFO mapreduce.Jobb:Löpande jobb:job_1587985272792_001120/04/29 03:48:09 INFO mapreduce.Jobb:Job job_15879852727/02 false i läget 29 03:48:09 INFO mapreduce.Job: map 0% reduce 0%20/04/29 03:54:08 INFO mapreduce.Job: map 100% reduce 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
Även på en så liten datamängd, CopyTable körs snabbare (ungefär 3 minuter, medan SyncTable tog 6 minuter att kopiera hela datamängden):
...20/04/29 05:12:07 INFO mapreduce.Jobb:Löpande jobb:job_1587986840019_000520/04/29 05:12:24 INFO mapreduce.Jobb:Job job_158798684000198684005/4 false 29 05:12:24 INFO mapreduce.Job: map 0% reduce 0%20/04/29 05:13:16 INFO mapreduce.Job: map 25% reduce 0%20/04/29 05:13:49 INFO mapreduce .Jobb: kartan 50% minska 0%20/04/29 05:14:37 INFO mapreduce.Job: map 75% reduce 0%20/04/29 05:15:14 INFO mapreduce.Job: map 100% reduce 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=0
Låt oss nu använda båda verktygen igen för att hantera glesa skillnader över datamängden. test-tbl Tabellen som används i alla dessa exempel har fyra regioner i källklustret. Efter att all den ursprungliga datamängden hade kopierats till målklustret i det tidigare exemplet, lade vi till ytterligare fyra rader endast på källsidan, en för var och en av de befintliga regionerna, och kör sedan HashTable/SyncTable igen för att synkronisera båda klustren:
20/04/29 05:29:23 INFO mapreduce.Jobb:Löpande jobb:job_1587985272792_001320/04/29 05:29:39 INFO mapreduce.Jobb:Job job_1587985272702 i utrustat läge 29:39 INFO mapreduce.Job: map 0% reduce 0%20/04/29 05:29:53 INFO mapreduce.Job: map 50% reduce 0%20/04/29 05:30:42 INFO mapreduce.Job:karta 100% reducering 0%20/04/29 05:30:42 INFO mapreduce.Job:Job job_1587985272792_0013 slutfört framgångsrikt…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHESHASH4MATCHESHASH4MATCHESH4MATCHESHATCHES3D7MATCH4MATCHES3D7MATCH4MATCHES3D=90000001 5RANGESNOTMATCHED=4ROWSWITHDIFFS=4TARGETMISSINGCELLS=4TARGETMISSINGROWS=4
Vi kan se det med bara fyra partitioner som inte matchar, SyncTable var betydligt snabbare (ungefär en minut att slutföra). Använder CopyTable för att utföra samma synkronisering visade följande resultat:
20/04/29 08:32:38 INFO mapreduce.Jobb:Löpande jobb:job_1587986840019_000820/04/29 08:32:52 INFO mapreduce.Jobb:Job job_15879868040089 i u_040082/9 false:02/9 32:52 INFO mapreduce.Job: map 0% reduce 0%20/04/29 08:33:38 INFO mapreduce.Job: map 25% reduce 0%20/04/29 08:34:15 INFO mapreduce.Job:karta 50% reducera 0%20/04/29 08:34:48 INFO mapreduce.Job: map 75% reduce 0%20/04/29 08:35:31 INFO mapreduce.Job: map 100% reduce 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=0
CopyTable det tog lika lång tid att synkronisera tabellerna som när man kopierade hela datamängden, även om det bara fanns fyra celler att kopiera. Detta var fortfarande ok för denna mycket lilla datamängd, och med ett ledigt kluster, men under produktionsanvändning med större datamängder och där målklustret också kan användas av många klientapplikationer som skriver data på det, CopyTable prestandaförsämring jämfört med SyncTable skulle vara ännu högre.
Det är värt att nämna att det också finns ytterligare verktyg/funktioner som kan användas i kombination för en initial laddning av ett målkluster (målet har inga data alls), såsom export av ögonblicksbilder, bulkladdning eller till och med en direkt kopia av originalet tabell dirs från källklustret. För initiala laddningar med stora mängder data att kopiera, ta en ögonblicksbild av tabellen och sedan använda ExportSnapshot verktyget kommer att överträffa onlinekopieringsverktyg som SyncTable eller CopyTable.
Kontrollera replikeringsintegriteten
En annan vanlig användning av HashTable/SyncTable är för att övervaka replikeringstillstånd mellan kluster vid felsökning av eventuella replikeringsproblem. I det här scenariot fungerar det som ett alternativ till verktyget VerifyReplication. Vanligtvis när man kontrollerar tillståndet mellan två kluster finns det antingen inga felmatchningar alls eller så har ett tillfälligt opartionellt problem gjort att en liten del av den större datamängden faller ur synk. I testmiljön som vi har använt för vårt tidigare exempel bör det finnas 100 008 rader med matchande värden på båda klustren. Att köra SyncTable på destinationsklustret med alternativet dryrun låter oss identifiera eventuella skillnader:
20/05/04 10:47:25 INFO mapreduce.Jobb:Löpande jobb:job_1588611199158_0004…20/05/04 10:48:48 INFO mapreduce.Job: map 100% reduce 0/040/05/040/05 :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 verktyget VerifyReplication på källklustret. Vi skickar peer-id:t som en av dess parametrar så att det kan hitta fjärrklustret att skanna för jämförelse:20/05/04 11:01:58 INFO mapreduce.Job:Running job:job_1588611196128_0001…20/05/04 11:04:39 INFO mapreduce.Job: map 100% reduce 0%20/05/04 11:04:39 INFO mapreduce.Job:Job job_1588611196128_0001 slutfört framgångsrikt…HBase CountersBYTES_IN_REMOTE_4IN50SMAHA .replication.VerifyReplication$Verifier$CountersGOODROWS=100008...
Utan skillnader hittar SyncTable alla hash som matchar mellan käll- och målpartitioner och undviker därmed behovet av att skanna fjärrkällklustret igen. VerifyReplication utför en jämförelse för varje cell i båda klustren som redan kan ha en hög nätverkskostnad även när man hanterar så små datamängder.
Lägger till en extra rad i källklustret och utför kontrollerna igen. Med VerifyReplication:
20/05/05 11:14:05 INFO mapreduce.Jobb:Löpande jobb:job_1588611196128_0004…20/05/05 11:16:32 INFO mapreduce.Job: map 100% reduce 0%050/0115 :16:32 INFO mapreduce.Job:Job job_1588611196128_0004 slutfört framgångsrikt...org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication$Verifier$CountersBADROWS=1GOODROWS=100008_WSROWSOUR=100008_WSROWSOUR=100008_WSROWSROWSOUR=100008ONLY_IN_BLESOUR=ONLY_IN_BLESInnan vi kan använda SyncTable måste vi återskapa hashs på källkod med HashTable igen, eftersom det finns en ny cell nu:
20/05/04 11:31:48 INFO mapreduce.Job:Löpande jobb:job_1588611196128_0003…20/05/04 11:33:15 INFO mapreduce.Job:Job job_15886111961ly{100}{101}Nu SyncTable:
20/05/07 05:47:51 INFO mapreduce.Job:Löpande jobb:job_1588611199158_0014…20/05/07 05:49:20 INFO mapreduce.Job:Job job_15886111915>lyckat org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_NOT_MATCHED=97148MATCHINGCELLS=749593MATCHINGROWS=100008RANGESMATCHED=97147DFF1SNOTWSWITSTROMSDI=97147DFF1SNOTSWIDSTROMMISSAR/Vi kan se ökningen av exekveringstid på grund av ytterligare skanning och celljämförelse mellan de två avlägsna klustren. Samtidigt visade körtiden för VerifyReplication liten variation.
Slutsats
HashTable/SyncTable är ett värdefullt verktyg för att flytta runt data när man hanterar glesa missmatchningar mellan två klusterdatauppsättningar. Den använder sig av datapartitionering och hashning för att effektivt upptäcka skillnader i intervall från de två datamängderna, vilket minskar antalet celler som ska skannas samtidigt som data från de två klustren jämförs, samtidigt som man undviker onödiga placeringar av redan existerande värden i målklustret. Det är dock inte en silverkula, som visas i några av exemplen ovan, även om den kan tyckas överlappa i funktion med CopyTable verktyg, kan det senare erbjuda bättre prestanda vid hantering av större, sekventiellt intervall av felaktiga celler. I den meningen HashTable/SyncTable skulle vara mest tillämpligt i fall där båda klustren redan har en del data, eller i fall där en befintlig replikeringsinställning har störts av tillfällig otillgänglighet för en av peers.
Relaterade artiklar:
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/