CopyTable è una semplice utility Apache HBase che, ovviamente, può essere utilizzata per copiare singole tabelle all'interno di un cluster HBase o da un cluster HBase a un altro. In questo post del blog parleremo di cos'è questo strumento, perché vorresti usarlo, come usarlo e alcuni avvertimenti di configurazione comuni.
Casi d'uso:
CopyTable è fondamentalmente un lavoro Apache Hadoop MapReduce che utilizza l'interfaccia del percorso di lettura HBase Scan standard per leggere i record da una singola tabella e li scrive su un'altra tabella (possibilmente su un cluster separato) utilizzando l'interfaccia del percorso di scrittura HBase Put standard. Può essere utilizzato per molti scopi:
- Copia interna di una tabella (Snapshot del povero)
- Backup dell'istanza HBase remota
- Copie incrementali della tabella HBase
- Copie parziali della tabella HBase e modifiche allo schema della tabella HBase
Presupposti e limitazioni:
Lo strumento CopyTable ha alcuni presupposti e limitazioni di base. Innanzitutto, se utilizzati in una situazione multi-cluster, entrambi i cluster devono essere online e l'istanza di destinazione deve avere la tabella di destinazione presente con le stesse famiglie di colonne definite della tabella di origine.
Poiché lo strumento utilizza scansioni e inserimenti standard, il cluster di destinazione non deve avere lo stesso numero di nodi o regioni. In effetti, può avere diversi numeri di tabelle, diversi numeri di server di regione e potrebbe avere confini divisi di regione completamente diversi. Poiché stiamo copiando intere tabelle, puoi utilizzare impostazioni di ottimizzazione delle prestazioni come l'impostazione di valori di memorizzazione nella cache dello scanner più grandi per una maggiore efficienza. L'uso dell'interfaccia put significa anche che è possibile eseguire copie tra cluster di diverse versioni secondarie. (0.90.4 -> 0.90.6, CDH3u3 -> CDH3u4) o versioni compatibili con il cavo (0.92.1 -> 0.94.0).
Infine, HBase fornisce solo garanzie ACID a livello di riga; ciò significa che mentre è in corso una CopyTable, potrebbero verificarsi righe appena inserite o aggiornate e queste modifiche simultanee saranno completamente incluse o completamente escluse. Sebbene le righe siano coerenti, non ci sono garanzie sulla coerenza, la causalità o l'ordine delle messe nelle altre righe.
Copia interna di una tabella (Istantanea del povero)
Le versioni di HBase fino alle versioni 0.94.x più recenti incluse non supportano lo snapshot delle tabelle. Nonostante le limitazioni ACID di HBase, CopyTable può essere utilizzato come un meccanismo di snapshot ingenuo che crea una copia fisica di una tabella particolare.
Diciamo che abbiamo una tabella, tableOrig con famiglie di colonne cf1 e cf2. Vogliamo copiare tutti i suoi dati su tableCopy. Dobbiamo prima creare tableCopy con le stesse famiglie di colonne:
srcCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell
Possiamo quindi creare e copiare la tabella con un nuovo nome sulla stessa istanza HBase:
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=tableCopy tableOrig
Questo avvia un processo di risonanza magnetica che copierà i dati.
Backup dell'istanza HBase remota
Supponiamo di voler copiare i dati su un altro cluster. Questo potrebbe essere un backup una tantum, un lavoro periodico o potrebbe essere per il bootstrap per la replica tra cluster. In questo esempio, avremo due cluster separati:srcCluster e dstCluster.
In questo caso multi-cluster, CopyTable è un processo push:l'origine sarà l'istanza HBase a cui fa riferimento il tuo hbase-site.xml corrente e gli argomenti aggiunti puntano al cluster e alla tabella di destinazione. Ciò presuppone inoltre che tutti i TaskTracker di MR possano accedere a tutti i nodi HBase e ZK nel cluster di destinazione. Questo meccanismo di configurazione significa anche che puoi eseguirlo come un lavoro su un cluster remoto sovrascrivendo le configurazioni hbase/mr per utilizzare le impostazioni da qualsiasi cluster remoto accessibile e specificando i nodi ZK nel cluster di destinazione. Questo potrebbe essere utile se desideri copiare i dati da un cluster HBase con SLA inferiori e non desideri eseguire direttamente lavori di MR su di essi.
Utilizzerai l'impostazione –peer.adr per specificare l'ensemble ZK del cluster di destinazione (ad esempio il cluster in cui stai copiando). Per questo abbiamo bisogno dell'IP e della porta del quorum ZK, nonché del nodo ZK radice HBase per la nostra istanza HBase. Diciamo che una di queste macchine è srcClusterZK (elencato in hbase.zookeeper.quorum) e che stiamo usando la porta client zk predefinita 2181 (hbase.zookeeper.property.clientPort) e il genitore ZK znode predefinito /hbase (zookeeper.znode. genitore). (Nota:se avessi due istanze HBase che utilizzano la stessa ZK, avresti bisogno di un zookeeper.znode.parent diverso per ogni cluster.
# 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
Nota che puoi usare l'argomento –new.name con –peer.adr per copiare in una tabella con nome diverso sul 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
Questo copierà i dati da tableOrig su srcCluster alla tabella tableCopy di dstCluster.
Copie incrementali della tabella HBase
Dopo aver copiato una tabella su un cluster di destinazione, come si copiano i nuovi dati che vengono successivamente scritti nel cluster di origine? Ingenuamente, è possibile eseguire nuovamente il lavoro CopyTable e copiare l'intera tabella. Tuttavia, CopyTable fornisce un meccanismo di copia incrementale più efficiente che copia semplicemente le righe aggiornate da srcCluster al backup dstCluster specificato in una finestra temporale. Pertanto, dopo la copia iniziale, potresti avere un cron job periodico che copia i dati solo dall'ora precedente da srcCluster a dstCuster.
Questo viene fatto specificando gli argomenti –starttime e –endtime. I tempi sono specificati come millisecondi decimali dall'epoca unix.
# 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
Copie parziali della tabella HBase e modifiche allo schema della tabella HBase
Per impostazione predefinita, CopyTable copierà tutte le famiglie di colonne dalle righe corrispondenti. CopyTable fornisce opzioni per copiare solo i dati da famiglie di colonne specifiche. Ciò potrebbe essere utile per copiare i dati di origine originali ed escludere famiglie di colonne di dati derivati che vengono aggiunte dall'elaborazione successiva.
Aggiungendo questi argomenti copiamo solo i dati dalle famiglie di colonne specificate.
- –families=srcCf1
- –families=srcCf1,srcCf2
A partire dalla 0.92.0 puoi copiare modificando il cognome della colonna:
- –families=srcCf1:dstCf1
- copia da srcCf1 a dstCf1
- –families=srcCf1:dstCf1,dstCf2,srcCf3:dstCf3
- copia da srcCf1 a destCf1, copia dstCf2 a dstCf2 (senza rinominare) e srcCf3 a dstCf3
Si noti che dstCf* deve essere presente nella tabella dstCluster!
A partire dalla 0.94.0 vengono offerte nuove opzioni per copiare i marker di cancellazione e per includere un numero limitato di versioni sovrascritte. In precedenza, se una riga veniva eliminata nel cluster di origine, l'eliminazione non veniva copiata, ma una versione non aggiornata di quella riga rimaneva nel cluster di destinazione. Questo sfrutta alcune delle funzionalità avanzate della versione 0.94.0.
- –versions=vers
- dove vers è il numero di versioni di celle da copiare (il valore predefinito è 1, ovvero solo l'ultima)
- –all.cells
- copia anche i marcatori di eliminazione e le celle eliminate
Insidie comuni
Il client HBase nelle versioni 0.90.x, 0.92.x e 0.94.x usa sempre zoo.cfg se si trova nel classpath, anche se un file hbase-site.xml specifica altre impostazioni di configurazione del quorum ZooKeeper. Questa "funzione" causa un problema comune in CDH3 HBase perché i suoi pacchetti includono per impostazione predefinita una directory in cui zoo.cfg risiede nel percorso di classe di HBase. Questo può e ha portato a frustrazione quando si tenta di utilizzare CopyTable (HBASE-4614). La soluzione alternativa è escludere il file zoo.cfg dal percorso di classe di HBase e specificare le proprietà di configurazione di ZooKeeper nel file hbase-site.xml. http://hbase.apache.org/book.html#zookeeper
Conclusione
CopyTable fornisce un'assicurazione per il ripristino di emergenza semplice ma efficace per le distribuzioni di HBase 0.90.x (CDH3). Insieme alla funzionalità di replica trovata e supportata nell'HBase basato su HBase 0.92.x di CDH4, le funzionalità incrementali di CopyTable diventano meno preziose, ma la sua funzionalità principale è importante per il bootstrap di una tabella replicata. Anche se funzionalità più avanzate come gli snapshot HBase (HBASE-50) possono aiutare con il ripristino di emergenza una volta implementato, CopyTable sarà comunque uno strumento utile per l'amministratore di HBase.
