CopyTable är ett enkelt Apache HBase-verktyg som, föga överraskande, kan användas för att kopiera enskilda tabeller inom ett HBase-kluster eller från ett HBase-kluster till ett annat. I det här blogginlägget kommer vi att prata om vad det här verktyget är, varför du skulle vilja använda det, hur du använder det och några vanliga konfigurationsförbehåll.
Användningsfall:
CopyTable är i sin kärna ett Apache Hadoop MapReduce-jobb som använder det vanliga HBase Scan-läsvägsgränssnittet för att läsa poster från en enskild tabell och skriver dem till en annan tabell (eventuellt i ett separat kluster) med hjälp av standardgränssnittet för HBase Put-skrivväg. Den kan användas för många ändamål:
- Intern kopia av en tabell (stackars ögonblicksbild)
- Fjärrsäkerhetskopiering av HBase-instanser
- Inkrementella HBase-tabellkopior
- Delvisa HBase-tabellkopior och HBase-tabellschemaändringar
Antaganden och begränsningar:
CopyTable-verktyget har några grundläggande antaganden och begränsningar. För det första, om de används i situationen med flera kluster måste båda klustren vara online och målinstansen måste ha måltabellen närvarande med samma kolumnfamiljer definierade som källtabellen.
Eftersom verktyget använder standardskanningar och sättningar, behöver målklustret inte ha samma antal noder eller regioner. Faktum är att den kan ha olika antal tabeller, olika antal regionservrar och kan ha helt olika regiondelade gränser. Eftersom vi kopierar hela tabeller kan du använda prestandaoptimeringsinställningar som att ställa in större skannercachingvärden för mer effektivitet. Att använda put-gränssnittet innebär också att kopior kan göras mellan kluster av olika mindre versioner. (0.90.4 -> 0.90.6, CDH3u3 -> CDH3u4) eller versioner som är trådkompatibla (0.92.1 -> 0.94.0).
Slutligen tillhandahåller HBase endast ACID-garantier på radnivå; detta innebär att medan en CopyTable pågår kan nyinfogade eller uppdaterade rader förekomma och dessa samtidiga redigeringar kommer antingen att inkluderas helt eller helt uteslutas. Även om raderna kommer att vara konsekventa, finns det inga garantier om konsistensen, orsakssambandet eller ordningen för placeringar på de andra raderna.
Intern kopia av en tabell (Stackars ögonblicksbild)
Versioner av HBase upp till och inklusive de senaste 0.94.x-versionerna stöder inte tabellöversiktsbilder. Trots HBases ACID-begränsningar kan CopyTable användas som en naiv ögonblicksbildmekanism som gör en fysisk kopia av en viss tabell.
Låt oss säga att vi har en tabell, tableOrig med kolumnfamiljer cf1 och cf2. Vi vill kopiera alla dess data till tableCopy. Vi måste först skapa tableCopy med samma kolumnfamiljer:
srcCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell
Vi kan sedan skapa och kopiera tabellen med ett nytt namn på samma HBase-instans:
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=tableCopy tableOrig
Detta startar ett MR-jobb som kopierar data.
Fjärrsäkerhetskopiering av HBase-instanser
Låt oss säga att vi vill kopiera data till ett annat kluster. Detta kan vara en engångsbackup, ett periodiskt jobb eller kan vara för bootstrapping för korsklusterreplikering. I det här exemplet har vi två separata kluster:srcCluster och dstCluster.
I det här fallet med flera kluster är CopyTable en push-process – din källa kommer att vara den HBase-instans som din nuvarande hbase-site.xml refererar till och de tillagda argumenten pekar på destinationsklustret och -tabellen. Detta förutsätter också att alla MR TaskTrackers kan komma åt alla HBase- och ZK-noder i destinationsklustret. Denna mekanism för konfiguration innebär också att du kan köra detta som ett jobb på ett fjärrkluster genom att åsidosätta hbase/mr-konfigurationerna för att använda inställningar från vilket tillgängligt fjärrkluster som helst och ange ZK-noderna i destinationsklustret. Detta kan vara användbart om du vill kopiera data från ett HBase-kluster med lägre SLA och inte vill köra MR-jobb direkt på dem.
Du använder inställningen –peer.adr för att ange destinationsklustrets ZK-ensemble (t.ex. klustret du kopierar till). För detta behöver vi ZK-kvorumets IP och port samt HBase-rot ZK-noden för vår HBase-instans. Låt oss säga att en av dessa datorer är srcClusterZK (listad i hbase.zookeeper.quorum) och att vi använder standard zk klientport 2181 (hbase.zookeeper.property.clientPort) och standard ZK znode förälder /hbase (zookeeper.znode). förälder). (Obs:Om du hade två HBase-instanser som använder samma ZK, skulle du behöva en annan zookeeper.znode.parent för varje kluster.
# 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
Observera att du kan använda argumentet –new.name med –peer.adr för att kopiera till en annan namngiven tabell 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
Detta kommer att kopiera data från tableOrig på srcCluster till dstCluster's tableCopy-tabell.
Inkrementella HBase-tabellkopior
När du har en kopia av en tabell på ett målkluster, hur kopierar du ny data som senare skrivs till källklustret? Naivt kan du köra CopyTable-jobbet igen och kopiera över hela tabellen. CopyTable tillhandahåller dock en effektivare inkrementell kopieringsmekanism som bara kopierar de uppdaterade raderna från srcCluster till backup dstCluster som anges i ett tidsfönster. Efter den första kopian kan du alltså ha ett periodiskt cron-jobb som kopierar data från endast föregående timme från srcCluster till dstCuster.
Detta görs genom att ange argumenten –starttime och –endtime. Tider anges som decimala millisekunder sedan unix-epoktid.
# 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
Delvisa HBase-tabellkopior och HBase-tabellschemaändringar
Som standard kopierar CopyTable alla kolumnfamiljer från matchande rader. CopyTable ger alternativ för att endast kopiera data från specifika kolumnfamiljer. Detta kan vara användbart för att kopiera originalkälldata och exkludera härledda kolumnfamiljer för data som läggs till efter bearbetning.
Genom att lägga till dessa argument kopierar vi endast data från de angivna kolumnfamiljerna.
- –families=srcCf1
- –families=srcCf1,srcCf2
Från och med 0.92.0 kan du kopiera samtidigt som du ändrar kolumnfamiljens namn:
- –families=srcCf1:dstCf1
- kopiera från srcCf1 till dstCf1
- –families=srcCf1:dstCf1,dstCf2,srcCf3:dstCf3
- kopiera från srcCf1 till destCf1, kopiera dstCf2 till dstCf2 (inget byte namn) och srcCf3 till dstCf3
Observera att dstCf* måste finnas i tabellen dstCluster!
Från och med 0.94.0 erbjuds nya alternativ för att kopiera raderingsmarkörer och att inkludera ett begränsat antal överskrivna versioner. Tidigare, om en rad raderades i källklustret, skulle borttagningen inte kopieras – istället för att en inaktuell version av den raden skulle finnas kvar i målklustret. Detta drar fördel av några av 0.94.0-versionens avancerade funktioner.
- –versions=vers
- där vers är antalet cellversioner som ska kopieras (standard är 1, även den senaste)
- –all.cells
- Kopiera även raderingsmarkörer och raderade celler
Vanliga fallgropar
HBase-klienten i versionerna 0.90.x, 0.92.x och 0.94.x använder alltid zoo.cfg om den finns i klasssökvägen, även om en hbase-site.xml-fil anger andra ZooKeeper-kvorumkonfigurationsinställningar. Denna "funktion" orsakar ett problem som är vanligt i CDH3 HBase eftersom dess paket som standard inkluderar en katalog där zoo.cfg finns i HBases klassväg. Detta kan och har lett till frustration när man försöker använda CopyTable (HBASE-4614). Lösningen för detta är att utesluta filen zoo.cfg från din HBases klassväg och att ange ZooKeeper-konfigurationsegenskaper i filen hbase-site.xml. http://hbase.apache.org/book.html#zookeeper
Slutsats
CopyTable tillhandahåller en enkel men effektiv återställningsförsäkring för HBase 0.90.x (CDH3)-distributioner. I samband med replikeringsfunktionen som hittas och stöds i CDH4:s HBase 0.92.x-baserade HBase, blir CopyTables inkrementella funktioner mindre värdefulla men dess kärnfunktionalitet är viktig för att bootstrapping en replikerad tabell. Även om mer avancerade funktioner som HBase-ögonblicksbilder (HBASE-50) kan hjälpa till med katastrofåterställning när den implementeras, kommer CopyTable fortfarande att vara ett användbart verktyg för HBase-administratören.