CopyTable er et simpelt Apache HBase-værktøj, som ikke overraskende kan bruges til at kopiere individuelle tabeller i en HBase-klynge eller fra en HBase-klynge til en anden. I dette blogindlæg vil vi tale om, hvad dette værktøj er, hvorfor du ønsker at bruge det, hvordan du bruger det, og nogle almindelige konfigurationsforbehold.
Brugstilfælde:
CopyTable er i sin kerne et Apache Hadoop MapReduce-job, der bruger standard HBase Scan-læsesti-grænsefladen til at læse poster fra en individuel tabel og skriver dem til en anden tabel (eventuelt på en separat klynge) ved hjælp af standard HBase Put-skrivesti-grænsefladen. Den kan bruges til mange formål:
- Intern kopi af en tabel (fattigmands øjebliksbillede)
- Fjern HBase-instanssikkerhedskopi
- Inkrementelle HBase-tabelkopier
- Delvise HBase-tabelkopier og HBase-tabelskemaændringer
Antagelser og begrænsninger:
CopyTable-værktøjet har nogle grundlæggende antagelser og begrænsninger. For det første, hvis de bruges i multi-cluster-situationen, skal begge klynger være online, og målforekomsten skal have måltabellen til stede med de samme kolonnefamilier defineret som kildetabellen.
Da værktøjet bruger standardscanninger og -sæt, behøver målklyngen ikke at have det samme antal noder eller regioner. Faktisk kan den have forskellige antal tabeller, forskellige antal regionsservere og kunne have helt forskellige regionsdelingsgrænser. Da vi kopierer hele tabeller, kan du bruge præstationsoptimeringsindstillinger som at indstille større scanner-cacheværdier for mere effektivitet. Brug af put-grænsefladen betyder også, at der kan laves kopier mellem klynger af forskellige mindre versioner. (0.90.4 -> 0.90.6, CDH3u3 -> CDH3u4) eller versioner, der er trådkompatible (0.92.1 -> 0.94.0).
Endelig giver HBase kun ACID-garantier på rækkeniveau; dette betyder, at mens en CopyTable foregår, kan der forekomme nyindsatte eller opdaterede rækker, og disse samtidige redigeringer vil enten være fuldstændig inkluderet eller fuldstændig udelukket. Selvom rækker vil være konsistente, er der ingen garantier for konsistensen, årsagssammenhængen eller rækkefølgen af sætninger på de andre rækker.
Intern kopi af en tabel (fattigmands øjebliksbillede)
Versioner af HBase til og med de seneste 0.94.x-versioner understøtter ikke tabel-snapshotting. På trods af HBases ACID-begrænsninger kan CopyTable bruges som en naiv snapshot-mekanisme, der laver en fysisk kopi af en bestemt tabel.
Lad os sige, at vi har en tabel, tableOrig med kolonnefamilier cf1 og cf2. Vi ønsker at kopiere alle dens data til tableCopy. Vi skal først oprette tableCopy med de samme kolonnefamilier:
srcCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell
Vi kan derefter oprette og kopiere tabellen med et nyt navn på den samme HBase-instans:
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=tableCopy tableOrig
Dette starter et MR-job, der kopierer dataene.
Fjern HBase-instanssikkerhedskopi
Lad os sige, at vi vil kopiere data til en anden klynge. Dette kan være en engangssikkerhedskopiering, et periodisk job eller kan være til bootstrapping til cross-cluster replikering. I dette eksempel har vi to separate klynger:srcCluster og dstCluster.
I dette tilfælde med flere klynge er CopyTable en push-proces - din kilde vil være den HBase-forekomst, din nuværende hbase-site.xml refererer til, og de tilføjede argumenter peger på destinationsklyngen og -tabellen. Dette forudsætter også, at alle MR TaskTrackers kan få adgang til alle HBase- og ZK-noder i destinationsklyngen. Denne mekanisme til konfiguration betyder også, at du kan køre dette som et job på en fjernklynge ved at tilsidesætte hbase/mr-konfigurationerne for at bruge indstillinger fra enhver tilgængelig fjernklynge og angive ZK-noder i destinationsklyngen. Dette kunne være nyttigt, hvis du ville kopiere data fra en HBase-klynge med lavere SLA'er og ikke ville køre MR-job direkte på dem.
Du skal bruge indstillingen –peer.adr til at angive destinationsklyngens ZK-ensemble (f.eks. den klynge, du kopierer til). Til dette har vi brug for ZK kvorums IP og port samt HBase root ZK node til vores HBase instans. Lad os sige, at en af disse maskiner er srcClusterZK (opført i hbase.zookeeper.quorum), og at vi bruger standard zk-klientport 2181 (hbase.zookeeper.property.clientPort) og standard ZK znode forælder /hbase (zookeeper.znode). forælder). (Bemærk:Hvis du havde to HBase-forekomster, der brugte den samme ZK, skulle du bruge en anden zookeeper.znode.parent for hver klynge.
# 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
Bemærk, at du kan bruge argumentet –new.name med –peer.adr til at kopiere til en tabel med andet navn i 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
Dette vil kopiere data fra tableOrig på srcCluster til dstClusters tableCopy-tabel.
Inkrementelle HBase-tabelkopier
Når du har en kopi af en tabel på en destinationsklynge, hvordan kopierer du så nye data, som senere skrives til kildeklyngen? Naivt kunne du køre CopyTable-jobbet igen og kopiere over hele tabellen. CopyTable giver dog en mere effektiv inkrementel kopimekanisme, der blot kopierer de opdaterede rækker fra srcCluster til backup dstCluster angivet i et tidsrum. Efter den første kopi kunne du således have et periodisk cron-job, der kopierer data fra kun den foregående time fra srcCluster til dstCuster.
Dette gøres ved at angive argumenterne –starttid og –sluttid. Tider er angivet som decimale millisekunder siden unix-epoketid.
# 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
Delvise HBase-tabelkopier og HBase-tabelskemaændringer
Som standard vil CopyTable kopiere alle kolonnefamilier fra matchende rækker. CopyTable giver muligheder for kun at kopiere data fra specifikke kolonnefamilier. Dette kan være nyttigt til at kopiere originale kildedata og udelukke afledte datakolonnefamilier, der tilføjes ved efterfølgende behandling.
Ved at tilføje disse argumenter kopierer vi kun data fra de angivne kolonnefamilier.
- –families=srcCf1
- –families=srcCf1,srcCf2
Fra 0.92.0 kan du kopiere, mens du ændrer kolonnens familienavn:
- –families=srcCf1:dstCf1
- kopi fra srcCf1 til dstCf1
- –families=srcCf1:dstCf1,dstCf2,srcCf3:dstCf3
- kopiér fra srcCf1 til destCf1, kopier dstCf2 til dstCf2 (ingen omdøbning) og srcCf3 til dstCf3
Bemærk venligst, at dstCf* skal være til stede i dstCluster-tabellen!
Fra 0.94.0 tilbydes nye muligheder for at kopiere slettemarkører og inkludere et begrænset antal overskrevne versioner. Tidligere, hvis en række blev slettet i kildeklyngen, ville sletningen ikke blive kopieret - i stedet for at en forældet version af denne række ville forblive i destinationsklyngen. Dette udnytter nogle af 0.94.0-udgivelsens avancerede funktioner.
- –versions=vers
- hvor vers er antallet af celleversioner, der skal kopieres (standard er 1 aka kun den seneste)
- –alle.celler
- kopier også slettemarkører og slettede celler
Almindelige faldgruber
HBase-klienten i versionerne 0.90.x, 0.92.x og 0.94.x bruger altid zoo.cfg, hvis den er i klassestien, selvom en hbase-site.xml-fil angiver andre ZooKeeper-kvorumskonfigurationsindstillinger. Denne "funktion" forårsager et problem, der er almindeligt i CDH3 HBase, fordi dets pakker som standard inkluderer en mappe, hvor zoo.cfg bor i HBases klassesti. Dette kan og har ført til frustration, når du forsøger at bruge CopyTable (HBASE-4614). Løsningen for dette er at udelukke filen zoo.cfg fra din HBases klassesti og at angive ZooKeeper-konfigurationsegenskaber i din hbase-site.xml-fil. http://hbase.apache.org/book.html#zookeeper
Konklusion
CopyTable giver en enkel, men effektiv katastrofe-gendannelsesforsikring til HBase 0.90.x (CDH3)-implementeringer. I forbindelse med replikeringsfunktionen, der findes og understøttes i CDH4s HBase 0.92.x-baserede HBase, bliver CopyTables inkrementelle funktioner mindre værdifulde, men dens kernefunktionalitet er vigtig for bootstrapping af en replikeret tabel. Mens mere avancerede funktioner såsom HBase-snapshots (HBASE-50) kan hjælpe med katastrofegendannelse, når det bliver implementeret, vil CopyTable stadig være et nyttigt værktøj for HBase-administratoren.