CopyTable is een eenvoudig Apache HBase-hulpprogramma dat, niet verwonderlijk, kan worden gebruikt voor het kopiëren van afzonderlijke tabellen binnen een HBase-cluster of van het ene HBase-cluster naar het andere. In deze blogpost zullen we het hebben over wat deze tool is, waarom je hem zou willen gebruiken, hoe je hem moet gebruiken en enkele veelvoorkomende configuratievoorbehouden.
Gebruikssituaties:
CopyTable is in wezen een Apache Hadoop MapReduce-taak die de standaard HBase Scan-leespadinterface gebruikt om records van een afzonderlijke tabel te lezen en ze naar een andere tabel te schrijven (mogelijk op een apart cluster) met behulp van de standaard HBase Put-schrijfpadinterface. Het kan voor vele doeleinden worden gebruikt:
- Interne kopie van een tabel (momentopname van de arme man)
- Back-up van HBase-instantie op afstand
- Incrementele HBase-tabelkopieën
- Gedeeltelijke HBase-tabelkopieën en wijzigingen in HBase-tabelschema
Aannames en beperkingen:
De tool CopyTable heeft enkele basisaannames en beperkingen. Ten eerste, als ze worden gebruikt in de situatie met meerdere clusters, moeten beide clusters online zijn en moet de doelinstantie de doeltabel hebben met dezelfde kolomfamilies die zijn gedefinieerd als de brontabel.
Omdat de tool standaardscans en puts gebruikt, hoeft het doelcluster niet hetzelfde aantal knooppunten of regio's te hebben. In feite kan het verschillende aantallen tafels hebben, verschillende aantallen regioservers en kan het compleet verschillende regiogrenzen hebben. Omdat we hele tabellen kopiëren, kunt u prestatie-optimalisatie-instellingen gebruiken, zoals het instellen van grotere scannercachewaarden voor meer efficiëntie. Het gebruik van de put-interface betekent ook dat er kopieën kunnen worden gemaakt tussen clusters van verschillende secundaire versies. (0.90.4 -> 0.90.6, CDH3u3 -> CDH3u4) of versies die compatibel zijn met draad (0.92.1 -> 0.94.0).
Ten slotte biedt HBase alleen ACID-garanties op rijniveau; dit betekent dat terwijl een CopyTable bezig is, er nieuw ingevoegde of bijgewerkte rijen kunnen optreden en dat deze gelijktijdige bewerkingen ofwel volledig worden opgenomen of volledig worden uitgesloten. Hoewel rijen consistent zullen zijn, zijn er geen garanties over de consistentie, causaliteit of volgorde van plaatsingen op de andere rijen.
Interne kopie van een tabel (poor man's snapshot)
Versies van HBase tot en met de meest recente 0.94.x-versies ondersteunen geen snapshots van tabellen. Ondanks de ACID-beperkingen van HBase, kan CopyTable worden gebruikt als een naïef snapshotmechanisme dat een fysieke kopie van een bepaalde tabel maakt.
Laten we zeggen dat we een tabel hebben, tableOrig met kolomfamilies cf1 en cf2. We willen alle gegevens naar tableCopy kopiëren. We moeten eerst tableCopy maken met dezelfde kolomfamilies:
srcCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell
We kunnen dan de tabel maken en kopiëren met een nieuwe naam op dezelfde HBase-instantie:
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=tableCopy tableOrig
Hiermee wordt een MR-taak gestart die de gegevens zal kopiëren.
Back-up van HBase-instantie op afstand
Stel dat we gegevens naar een ander cluster willen kopiëren. Dit kan een eenmalige back-up zijn, een periodieke taak of bootstrapping voor cross-cluster replicatie. In dit voorbeeld hebben we twee afzonderlijke clusters:srcCluster en dstCluster.
In dit geval met meerdere clusters is CopyTable een push-proces - uw bron is de HBase-instantie waarnaar uw huidige hbase-site.xml verwijst en de toegevoegde argumenten verwijzen naar het doelcluster en de doeltabel. Dit veronderstelt ook dat alle MR TaskTrackers toegang hebben tot alle HBase- en ZK-knooppunten in het doelcluster. Dit configuratiemechanisme betekent ook dat u dit als een taak op een extern cluster kunt uitvoeren door de hbase/mr-configuraties te overschrijven om instellingen van een toegankelijk extern cluster te gebruiken en de ZK-knooppunten in het doelcluster op te geven. Dit kan handig zijn als u gegevens van een HBase-cluster met lagere SLA's wilt kopiëren en er niet rechtstreeks MR-taken op wilt uitvoeren.
U gebruikt de instelling –peer.adr om het ZK-ensemble van het doelcluster op te geven (bijvoorbeeld het cluster waarnaar u kopieert). Hiervoor hebben we het IP-adres en de poort van het ZK-quorum nodig, evenals het HBase-root ZK-knooppunt voor onze HBase-instantie. Laten we zeggen dat een van deze machines srcClusterZK is (vermeld in hbase.zookeeper.quorum) en dat we de standaard zk-clientpoort 2181 (hbase.zookeeper.property.clientPort) en de standaard ZK znode-ouder /hbase (zookeeper.znode. ouder). (Opmerking:als u twee HBase-instanties had die dezelfde ZK gebruikten, heeft u voor elk cluster een andere zookeeper.znode.parent nodig.
# 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
Houd er rekening mee dat u het argument –new.name met de –peer.adr kunt gebruiken om naar een tabel met een andere naam in de dstCluster te kopiëren.
# 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
Hiermee worden gegevens van tableOrig op de srcCluster gekopieerd naar de tableCopy-tabel van de dstCluster.
Incrementele HBase-tabelkopieën
Als u eenmaal een kopie van een tabel op een doelcluster hebt, hoe kopieert u dan nieuwe gegevens die later naar het broncluster worden geschreven? Naïef zou u de CopyTable-taak opnieuw kunnen uitvoeren en over de hele tabel kunnen kopiëren. CopyTable biedt echter een efficiënter incrementeel kopieermechanisme dat alleen de bijgewerkte rijen kopieert van de srcCluster naar de back-up dstCluster die is opgegeven in een bepaald tijdsbestek. Dus, na de eerste kopie, zou je dan een periodieke cron-taak kunnen hebben die gegevens kopieert van alleen het vorige uur van srcCluster naar de dstCuster.
Dit wordt gedaan door de argumenten –starttime en –endtime op te geven. Tijden worden gespecificeerd als decimale milliseconden sinds de unix epoch-tijd.
# 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
Gedeeltelijke HBase-tabelkopieën en wijzigingen in HBase-tabelschema
Standaard kopieert CopyTable alle kolomfamilies van overeenkomende rijen. CopyTable biedt opties om alleen gegevens van specifieke kolomfamilies te kopiëren. Dit kan handig zijn voor het kopiëren van originele brongegevens en het uitsluiten van afgeleide gegevenskolomfamilies die worden toegevoegd door vervolgverwerking.
Door deze argumenten toe te voegen, kopiëren we alleen gegevens uit de opgegeven kolomfamilies.
- –families=srcCf1
- –families=srcCf1,srcCf2
Vanaf 0.92.0 kunt u kopiëren terwijl u de kolomfamilienaam wijzigt:
- –families=srcCf1:dstCf1
- kopiëren van srcCf1 naar dstCf1
- –families=srcCf1:dstCf1,dstCf2,srcCf3:dstCf3
- kopieer van srcCf1 naar destCf1, kopieer dstCf2 naar dstCf2 (niet hernoemen), en srcCf3 naar dstCf3
Houd er rekening mee dat dstCf* aanwezig moet zijn in de dstCluster-tabel!
Vanaf 0.94.0 worden nieuwe opties aangeboden om verwijdermarkeringen te kopiëren en om een beperkt aantal overschreven versies op te nemen. Als voorheen een rij in het broncluster wordt verwijderd, wordt de verwijdering niet gekopieerd, maar blijft een verouderde versie van die rij in het doelcluster. Dit maakt gebruik van enkele van de geavanceerde functies van de 0.94.0-release.
- –versions=vers
- waarbij vers het aantal celversies is dat moet worden gekopieerd (standaard is 1 ook wel alleen de laatste)
- –alle.cellen
- kopieer ook verwijdermarkeringen en verwijderde cellen
Veelvoorkomende valkuilen
De HBase-client in de versies 0.90.x, 0.92.x en 0.94.x gebruikt altijd zoo.cfg als deze zich in het klassenpad bevindt, zelfs als een hbase-site.xml-bestand andere ZooKeeper-quorumconfiguratie-instellingen specificeert. Deze "functie" veroorzaakt een probleem dat veel voorkomt in CDH3 HBase, omdat de pakketten standaard een map bevatten waarin zoo.cfg zich in het klassenpad van HBase bevindt. Dit kan en heeft tot frustratie geleid bij het gebruik van CopyTable (HBASE-4614). De tijdelijke oplossing hiervoor is om het bestand zoo.cfg uit te sluiten van het klassenpad van uw HBase en om ZooKeeper-configuratie-eigenschappen op te geven in uw hbase-site.xml-bestand. http://hbase.apache.org/book.html#zookeeper
Conclusie
CopyTable biedt een eenvoudige maar effectieve noodherstelverzekering voor HBase 0.90.x (CDH3)-implementaties. In combinatie met de replicatiefunctie die wordt gevonden en ondersteund in de op HBase 0.92.x gebaseerde HBase van CDH4, worden de incrementele functies van CopyTable minder waardevol, maar de kernfunctionaliteit is belangrijk voor het bootstrappen van een gerepliceerde tabel. Hoewel meer geavanceerde functies zoals HBase-snapshots (HBASE-50) kunnen helpen bij noodherstel wanneer het wordt geïmplementeerd, zal CopyTable nog steeds een handig hulpmiddel zijn voor de HBase-beheerder.