Replikering (dækket i denne tidligere blogartikel) er blevet frigivet i et stykke tid og er blandt de mest brugte funktioner i Apache HBase. At have klynger, der replikerer data med forskellige peers, er en meget almindelig implementering, hvad enten det er som en DR-strategi eller blot som en problemfri måde at replikere data mellem produktions-/iscenesættelses-/udviklingsmiljøer. Selvom det er en effektiv måde at holde forskellige HBase-databaser synkroniserede inden for en forsinkelse på under sekund, fungerer replikering kun over data, der indtages, efter at funktionen er blevet aktiveret. Det betyder, at alle allerede eksisterende data på alle klynger involveret i replikeringsimplementeringen stadig skal kopieres mellem peers på en anden måde. Der er en del værktøjer, der kan bruges til at synkronisere allerede eksisterende data på forskellige peer-klynger. Snapshots, BulkLoad, CopyTable er velkendte eksempler på sådanne værktøjer, der er dækket i tidligere Cloudera blogindlæg. I denne artikel skal vi dække HashTable/SyncTable, beskriver noget af dets interne implementeringslogik, fordele og ulemper ved at bruge det, og hvordan det kan sammenlignes med nogle af de andre datakopieringsteknikker nævnt ovenfor.
HashTable/SyncTable i en nøddeskal
HashTable/SyncTable er et værktøj implementeret som to kort-reducerende job, der udføres som individuelle trin. Den ligner CopyTable værktøj, som kan udføre både delvise eller hele tabeldatakopier. I modsætning til CopyTable den kopierer kun divergerende data mellem målklynger, hvilket sparer både netværks- og computerressourcer under kopieringsproceduren.
Det første trin, der skal udføres i processen, er HashTable kort-reducer job. Dette skal køres på den klynge, hvis data skal kopieres til den eksterne peer, normalt kildeklyngen. Et hurtigt eksempel på, hvordan man kører det, er vist nedenfor, detaljeret forklaring af hver af de påkrævede parametre er givet senere i denne artikel:
hbase org.apache.hadoop.hbase.mapreduce.HashTable --families=cf my-table /hashes/test-tbl…20/04/28 05:05:48 INFO mapreduce.Job: kort 100% reduktion 100 %20/04/28 05:05:49 INFO mapreduce.Job:Job job_1587986840019_0001 afsluttet succesfuldt20/04/28 05:05:49 INFO mapreduce.Job:Tællere:68…Fil Input Format Tællere Bytes. Skrevet=6811788
Når HashTable jobudførelsen med ovenstående kommando er fuldført, nogle outputfiler er blevet genereret i kilden hdfs /hashes/my-table mappe:
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 supergruppe 0 2020-04-28 05:05 /hashes/test-tbl/hashes/_SUCCESSdrwxr-xr-x - root-supergruppe 0 2020-04-28 05:05 /bl-0-0-0-0-0-0 test -rw-r--r-- 2 rodsupergruppe 6790909 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000/data-rw-r--r-- 2 rodsupergruppe 8 20 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000/index-rw-r--r-- 2-rods supergruppe 99 2020-04-28 05:04 /hashes/test- tbl/manifest-rw-r--r-- 2 root-supergruppe 153 2020-04-28 05:04 /hashes/test-tbl/partitions
Disse er nødvendige som input til SyncTable løb. Synkroniseringstabel skal lanceres på mål-peer. Nedenstående kommando kører SyncTable til output fra HashTable fra det forrige eksempel. Den bruger dryrun mulighed forklaret senere i denne artikel:
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=2MATCHINGMATCHED=2MATCHINGMATCHISSCELLS1000S1712S1712=2MATCHINGMATCHED=2MATCHINGMATCHED=2MATCHINGMATCHED=17148 1
Som en hurtig reference kan du bare erstatte de givne parametre på begge eksempler med dine faktiske miljøværdier. Resten af denne artikel vil dække implementeringsdetaljerne mere i dybden.
Hvorfor to forskellige trin?
Hovedmålet med dette værktøj er kun at identificere og kopiere data, der mangler mellem de to klynger. Hashtabel fungerer som et sharding/indekseringsjob, analyserer batches af tabeldataene og genererer hash-indekser for hver af disse batcher. Disse er output skrevet i filerne under /hashes/my-table hdfs-biblioteket videregivet som en af jobparametrene. Som nævnt før kræves dette output af SyncTable job. Synkroniseringstabel scanner måltabellen lokalt i de samme batchstørrelser som brugt af HashTable, og beregner også hash-værdier for disse batches ved hjælp af den samme funktion, som bruges af HashTable. Den sammenligner derefter den lokale batch-hash værdi med den fra HashTable produktion. Hvis hash-værdierne er ens, betyder det, at hele batchen er identisk i de to klynger, og intet skal kopieres på det segment. Ellers åbner den en scanning for batchen i kildeklyngen, og kontrollerer, om hver af cellerne allerede findes i målklyngen, og kopierer kun dem, der divergerer. På sparsomme, lidt forskellige datasæt, ville dette resultere i, at meget færre data kopieres mellem de to klynger. Det ville også kræve, at kun et lille antal celler skal scannes i kilden for at kontrollere for uoverensstemmelser.
Påkrævede parametre
Hashtabel kræver kun to parametre:tabelnavnet og outputstien, hvor relaterede hashes og andre metainfo-filer vil blive skrevet. SyncTable bruger HashTable output dir som input, sammen med tabelnavnene i henholdsvis kilden og i målklyngen. Da vi bruger HashTable /SyncTable for at flytte data mellem fjernklynger, sourcezkcluster indstilling skal defineres for SyncTable . Dette bør være kildeklyngens zookeepers kvorumsadresse. I dette artikeleksempel havde vi også refereret direkte til kildeklyngens aktive navnenodeadresse, så SyncTable vil læse hash-outputfilen direkte fra kildeklyngen. Alternativt HashTable output kan kopieres manuelt fra kildeklynge til fjernklynge (med f.eks. distcp).
| BEMÆRK:Arbejde med fjernklynger under forskellige kerberos-områder understøttes kun fra CDH 6.2.1 og fremefter. |
Avancerede muligheder
Begge HashTable og SyncTable tilbyde ekstra valgfrie muligheder, der kan tunes til optimale resultater.
Hashtabel giver mulighed for at filtrere data efter både rækkenøgle og ændringstidspunkt med startrække/starttid, stoprække/stoptid ejendomme, hhv. Datasættets omfang kan også begrænses af versioner og familier ejendomme. batchstørrelsen egenskaben definerer størrelsen af hver del, der skal hash. Dette påvirker direkte synkroniseringsydelsen. I tilfælde af meget få uoverensstemmelser kan indstilling af større batchstørrelsesværdier føre til bedre ydeevne, da større dele af datasættet ville blive ignoreret uden at skulle scannes af SyncTable.
Synkroniseringstabel giver en dryrun mulighed, som giver mulighed for en forhåndsvisning af de ændringer, der skal anvendes i målet.
SyncTable standardadfærd er at spejle kildedataene på målsiden, så enhver yderligere celle, der er til stede i målet, men fraværende i kilden, ender med at blive slettet på målsiden. Det kan være uønsket ved synkronisering af klynger under en Active-Active replikeringsopsætning og i sådanne tilfælde doDeletes indstillinger kan vendes til falske, hvorved replikering af sletninger på målet springes over. Der er også en lignende doPuts flag for tilfælde, hvor yderligere celler ikke bør indsættes i målklyngen.
Analyse af udgangene
Hashtabel udlæser et par filer med metaoplysninger til SyncTable, disse er dog ikke læselige af mennesker. Den udfører ingen ændringer på eksisterende data, så relateret info er af ringe interesse for en brugerkontekst.
Synkroniseringstabel er det trin, der virkelig anvender ændringerne på målet, og det kan være vigtigt at gennemgå dets oversigt, før du rent faktisk ændrer målklyngedataene (se dryrun mulighed nævnt ovenfor). Den udgiver nogle relevante tællere i slutningen af kortet, reducerer udførelse. Ser vi på værdierne fra ovenstående eksempel, kan vi se, at der var 97148 partitioner hashed (rapporteret af BATCHES tæller), som SyncTable opdagede afvigelser i kun to af dem (ifølge HASHES_MATCHED og HASHES_NOT_MACTHED tællere). Derudover, inden for de to partitioner, der har forskellige hashes, 17 celler over 2 rækker matchede (som rapporteret af MATCHING_CELLS og MATCHING_ROWS, hhv.), men der var også 2 rækker divergerende, på disse to partitioner (ifølge RANGESNOTMATCHED og ROWSWITHDIFFS ). Til sidst, SOURCEMISSINGCELLS og MANGLEDE CELLER fortæl os i detaljer, hvis celler kun var til stede på kilden eller målklyngen. I dette eksempel havde kildeklyngen én celle, der ikke var på målet, men målet havde også en celle, der ikke var på kilden. Siden SyncTable blev kørt uden at angive dryrun mulighed og indstilling doDeletes mulighed for at false , jobbet har slettet den ekstra celle i målklyngen og har føjet den ekstra celle fundet i kilden til målklyngen. Forudsat at ingen skriver ske på begge klynger, en efterfølgende kørsel af den samme SyncTable kommandoen i målklyngen ville ikke vise nogen forskelle:
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…
Gældende scenarier
Datasynkronisering
Ved første øjekast, HashTable/SyncTable kan synes at overlappe med CopyTable værktøj, men der er stadig specifikke scenarier, hvor begge værktøjer ville være mere egnede. Som et første sammenligningseksempel ved at bruge HashTable/SyncTable for en indledende indlæsning af en tabel, der indeholder 100.004 rækker og en samlet datastørrelse på 5,17 GB, kræves der et par minutter kun for SyncTable for at fuldføre:
...20/04/29 03:48:00 INFO mapreduce.Job:Løbende job:job_1587985272792_001120/04/29 03:48:09 INFO mapreduce.Job:Job job_15879852727/02 false/ufalse mode 29 03:48:09 INFO kortreducere.Job: kort 0% reducere 0%20/04/29 03:54:08 INFO kortreducere.Job: kort 100% reducere 0%20/04/29 03:54:09 INFO kortreducere .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
Selv på et så lille datasæt, CopyTable udføres hurtigere (ca. 3 minutter, mens SyncTable tog 6 minutter at kopiere hele datasættet):
...20/04/29 05:12:07 INFO mapreduce.Job:Løbende job:job_1587986840019_000520/04/29 05:12:24 INFO mapreduce.Job:Job job_158798684000198684005/4 false 29 05:12:24 INFO kortreducer.Job: kort 0% reduktion 0%20/04/29 05:13:16 INFO kortreducer.Job: kort 25% reduktion 0%20/04/29 05:13:49 INFO kortreducer .Job: kort 50% reducere 0%20/04/29 05:14:37 INFO kortreducere.Job: kort 75% reducere 0%20/04/29 05:15:14 INFO kortreducere.Job: kort 100% reducere 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
Lad os nu bruge begge værktøjer igen til at håndtere sparsomme forskelle over datasættet. test-tbl tabel brugt på alle disse eksempler har fire områder i kildeklyngen. Efter at alt det originale datasæt var blevet kopieret til målklyngen i det tidligere eksempel, tilføjede vi kun fire yderligere rækker på kildesiden, én for hver af de eksisterende regioner, og kørte derefter HashTable/SyncTable igen for at synkronisere begge klynger:
20/04/29 05:29:23 INFO mapreduce.Job:Løbende job:job_1587985272792_001320/04/29 05:29:39 INFO mapreduce.Job:Job job_158798527270:02 i ugyldig tilstand:02 i ugyldig tilstand. 29:39 INFO mapreduce.Job: kort 0% reducere 0%20/04/29 05:29:53 INFO mapreduce.Job: kort 50% reducere 0%20/04/29 05:30:42 INFO mapreduce.Job:kort 100% reduktion 0%20/04/29 05:30:42 INFO mapreduce.Job:Job job_1587985272792_0013 afsluttet med succes…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHESHASH4MATCHES3D7MATCH4MATCHESHATCH4MATCHES3D7MATCH4MATCH4S3D7S3D7S3D7S3D7S3D7S3D3D 5RANGESNOTMATCHED=4ROWSWITHDIFFS=4TARGETMISSINGCELLS=4TARGETMISSINGROWS=4
Vi kan se det med kun fire partitioner, der ikke matcher, SyncTable var betydeligt hurtigere (omkring et minut at fuldføre). Brug af CopyTable for at udføre denne samme synkronisering viste følgende resultater:
20/04/29 08:32:38 INFO mapreduce.Job:Løbende job:job_1587986840019_000820/04/29 08:32:52 INFO mapreduce.Job:Job job_1587986804008:02 i ugyldig tilstand:02 false:02/9 32:52 INFO mapreduce.Job: kort 0% reducere 0%20/04/29 08:33:38 INFO mapreduce.Job: kort 25% reducere 0%20/04/29 08:34:15 INFO mapreduce.Job:kort 50% reduktion 0%20/04/29 08:34:48 INFO mapreduce.Job: kort 75% reducer 0%20/04/29 08:35:31 INFO mapreduce.Job: kort 100% reducer 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 samme tid at synkronisere tabellerne, som når du kopierede hele datasættet, selvom der kun var fire celler til at kopiere. Dette var stadig ok for dette meget lille datasæt og med en ledig klynge, men under produktionsbrug med større datasæt, og hvor målklyngen også kan være i brug af mange klientapplikationer, der skriver data på den, CopyTable ydeevneforringelse i forhold til SyncTable ville være endnu højere.
Det er værd at nævne, at der også er yderligere værktøjer/funktioner, der kan bruges i kombination til en indledende belastning af en målklynge (målet har slet ingen data), såsom eksport af øjebliksbilleder, bulk load eller endda en direkte kopi af originalen tabel dirs fra kilde klynge. For indledende indlæsninger med store mængder data at kopiere, tage et tabeløjebliksbillede og derefter bruge Eksporter snapshot værktøj vil overgå online kopiværktøjer såsom SyncTable eller CopyTable.
Kontrol af replikeringsintegritet
En anden almindelig brug af HashTable/SyncTable er til at overvåge replikeringstilstanden mellem klynger ved fejlfinding af mulige replikeringsproblemer. I dette scenarie fungerer det som et alternativ til VerifyReplication-værktøjet. Når du kontrollerer tilstanden mellem to klynger, er der typisk ingen uoverensstemmelser overhovedet, eller et midlertidigt opartionelt problem har fået en lille del af det større datasæt til at falde ud af synkronisering. I det testmiljø, vi har brugt til vores tidligere eksempel, skulle der være 100.008 rækker med matchende værdier på begge klynger. At køre SyncTable på destinationsklyngen med dryrun-indstillingen vil lade os identificere eventuelle forskelle:
20/05/04 10:47:25 INFO mapreduce.Job:Løbende job:job_1588611199158_0004…20/05/04 10:48:48 INFO mapreduce.Job: kort 100% reduktion 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 VerifyReplication-værktøjet på kildeklyngen. Vi videregiver peer-id'et som en af dets parametre, så det kan finde fjernklyngen, der skal scannes til sammenligning:20/05/04 11:01:58 INFO mapreduce.Job:Løbende job:job_1588611196128_0001…20/05/04 11:04:39 INFO mapreduce.Job: kort 100% reduktion 0%20/05/04 11:04:39 INFO mapreduce.Job:Job job_1588611196128_0001 afsluttet med succes…HBase CountersBYTES_IN_REMOTE_7IN50SMA_500.00 .replication.VerifyReplication$Verifier$CountersGOODROWS=100008...
Uden forskelle finder SyncTable alle hashes, der matcher mellem kilde- og målpartitioner og undgår dermed behovet for at scanne fjernkildeklyngen igen. VerifyReplication udfører en en efter en sammenligning for hver celle i begge klynger, som måske allerede har en høj netværksomkostning, selv når der er tale om så små datasæt.
Tilføjelse af en ekstra række i kildeklyngen og udførelse af kontrollerne igen. Med VerifyReplication:
20/05/05 11:14:05 INFO mapreduce.Job:Løbende job:job_1588611196128_0004…20/05/05 11:16:32 INFO mapreduce.Job: kort 100% reduktion 0%20/01 :16:32 INFO mapreduce.Job:Job job_1588611196128_0004 afsluttet med succes…org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication$Verifier$CountersBADROWS=1GOODROWS=100008_WSROWS=100008_WSROWS=100008KUNCE_1_BLESOUR=100008_WSRO_1_BLESOURFør vi kan bruge SyncTable, er vi nødt til at regenerere hashes på kilden med HashTable igen, da der er en ny celle nu:
20/05/04 11:31:48 INFO mapreduce.Job:Løbende job:job_1588611196128_0003…20/05/04 11:33:15 INFO mapreduce.Job:Job job_15886111961{101}Nu SyncTable:
20/05/07 05:47:51 INFO mapreduce.Job:Løbende job:job_1588611199158_0014…20/05/07 05:49:20 INFO mapreduce.Job:Job job_15886111991b>fuldført org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_NOT_MATCHED=97148MATCHINGCELLS=749593MATCHINGROWS=100008RANGESMATCHED=97147D=1SNOTWSTIGHED=97147DREFF1SNOTWSTIJSDI/Vi kan se stigningen i udførelsestid på grund af yderligere scanning og cellesammenligning mellem de to fjernklynger. I mellemtiden viste VerifyReplication-udførelsestiden kun lidt variation.
Konklusion
HashTable/SyncTable er et værdifuldt værktøj til at flytte data rundt, når man håndterer sparsomme uoverensstemmelser mellem to klyngedatasæt. Det gør brug af datapartitionering og hashing til effektivt at detektere forskelle på områder fra de to datasæt, hvilket reducerer antallet af celler, der skal scannes, mens data fra de to klynger sammenlignes, mens det også undgår unødvendige anbringelser af allerede eksisterende værdier i målklyngen. Det er dog ikke en sølvkugle, som vist i nogle af eksemplerne ovenfor, mens det kan synes at overlappe i funktion med CopyTable værktøj, kan sidstnævnte tilbyde bedre ydeevne ved håndtering af større, sekventielt udvalg af mismatchende celler. I den forstand HashTable/SyncTable ville være mest anvendelig i tilfælde, hvor begge klynger allerede har nogle data, eller i tilfælde, hvor en eksisterende replikeringsopsætning er blevet forstyrret af midlertidig utilgængelighed af en af peers.
Relaterede artikler:
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/