CopyTable je jednoduchý nástroj Apache HBase, který lze nepřekvapivě použít pro kopírování jednotlivých tabulek v rámci clusteru HBase nebo z jednoho clusteru HBase do druhého. V tomto příspěvku na blogu budeme hovořit o tom, co tento nástroj je, proč jej chcete používat, jak jej používat a některá běžná upozornění týkající se konfigurace.
Případy použití:
CopyTable je ve svém jádru úloha Apache Hadoop MapReduce, která používá standardní rozhraní cesty čtení HBase Scan ke čtení záznamů z jednotlivé tabulky a zapisuje je do jiné tabulky (případně na samostatný cluster) pomocí standardního rozhraní cesty zápisu HBase Put. Můžete jej využít k mnoha účelům:
- Interní kopie tabulky (snímek chudáka)
- Vzdálená záloha instance HBase
- Přírůstkové kopie tabulky HBase
- Částečné kopie tabulky HBase a změny schématu tabulky HBase
Předpoklady a omezení:
Nástroj CopyTable má některé základní předpoklady a omezení. Za prvé, při použití v situaci s více clustery musí být oba clustery online a cílová instance musí mít v cílové tabulce stejné rodiny sloupců definované jako zdrojová tabulka.
Protože nástroj používá standardní skenování a vkládání, cílový cluster nemusí mít stejný počet uzlů nebo oblastí. Ve skutečnosti může mít různý počet tabulek, různý počet serverů regionů a může mít úplně jiné hranice rozdělení regionů. Protože kopírujeme celé tabulky, můžete pro větší efektivitu použít nastavení optimalizace výkonu, jako je nastavení větších hodnot mezipaměti skeneru. Použití rozhraní put také znamená, že lze vytvářet kopie mezi clustery různých vedlejších verzí. (0.90.4 -> 0.90.6, CDH3u3 -> CDH3u4) nebo verze, které jsou drátově kompatibilní (0.92.1 -> 0.94.0).
A konečně, HBase poskytuje pouze záruky ACID na úrovni řádků; to znamená, že zatímco CopyTable probíhá, mohou se objevit nově vložené nebo aktualizované řádky a tyto souběžné úpravy budou buď zcela zahrnuty, nebo zcela vyloučeny. I když řádky budou konzistentní, neexistuje žádná záruka ohledně konzistence, kauzality nebo pořadí umístění na ostatních řádcích.
Interní kopie tabulky (snímek chudáka)
Verze HBase až po nejnovější verze 0.94.x včetně nepodporují vytváření snímků tabulek. Navzdory omezením HBase ACID lze CopyTable použít jako naivní mechanismus pro vytváření snímků, který vytvoří fyzickou kopii konkrétní tabulky.
Řekněme, že máme tabulku tableOrig s rodinami sloupců cf1 a cf2. Chceme zkopírovat všechna jeho data do tableCopy. Nejprve musíme vytvořit tableCopy se stejnými rodinami sloupců:
srcCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell
Potom můžeme vytvořit a zkopírovat tabulku s novým názvem ve stejné instanci HBase:
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=tableCopy tableOrig
Tímto se spustí úloha MR, která zkopíruje data.
Vzdálená záloha instance HBase
Řekněme, že chceme zkopírovat data do jiného clusteru. Může se jednat o jednorázovou zálohu, periodickou úlohu nebo o bootstrapping pro replikaci mezi clustery. V tomto příkladu budeme mít dva samostatné clustery:srcCluster a dstCluster.
V tomto případě s více clustery je CopyTable proces push – vaším zdrojem bude instance HBase, na kterou odkazuje váš aktuální hbase-site.xml, a přidané argumenty ukazují na cílový cluster a tabulku. To také předpokládá, že všechny MR TaskTrackery mají přístup ke všem uzlům HBase a ZK v cílovém clusteru. Tento mechanismus pro konfiguraci také znamená, že to můžete spustit jako úlohu ve vzdáleném klastru přepsáním konfigurací hbase/mr tak, aby používali nastavení z libovolného dostupného vzdáleného klastru a specifikovali uzly ZK v cílovém klastru. To by mohlo být užitečné, pokud byste chtěli kopírovat data z clusteru HBase s nižšími smlouvami SLA a nechtěli na nich přímo spouštět úlohy MR.
K určení souboru ZK cílového clusteru (např. clusteru, do kterého kopírujete) použijete nastavení –peer.adr. K tomu potřebujeme IP a port kvora ZK a také kořenový uzel ZK HBase pro naši instanci HBase. Řekněme, že jeden z těchto strojů je srcClusterZK (uvedený v hbase.zookeeper.quorum) a že používáme výchozí klientský port zk 2181 (hbase.zookeeper.property.clientPort) a výchozí rodič ZK znode /hbase (zookeeper.znode). rodič). (Poznámka:Pokud byste měli dvě instance HBase používající stejný ZK, potřebovali byste pro každý cluster jiný zookeeper.znode.parent.
# 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
Všimněte si, že ke kopírování do jinak pojmenované tabulky v dstCluster můžete použít argument –new.name s –peer.adr.
# 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
Toto zkopíruje data z tableOrig na srcCluster do tabulky tableCopy dstCluster.
Přírůstkové kopie tabulky HBase
Jakmile máte kopii tabulky v cílovém clusteru, jak zkopírujete nová data, která jsou později zapsána do zdrojového clusteru? Naivně byste mohli znovu spustit úlohu CopyTable a zkopírovat celou tabulku. CopyTable však poskytuje efektivnější mechanismus přírůstkového kopírování, který pouze zkopíruje aktualizované řádky z srcCluster do záložního dstCluster zadaného v časovém okně. Po počátečním kopírování byste tedy mohli mít pravidelnou úlohu cron, která kopíruje data pouze za předchozí hodinu z srcCluster do dstCuster.
To se provádí zadáním argumentů –starttime a –endtime. Časy jsou specifikovány jako desetinné milisekundy od doby unixové epochy.
# 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
Částečné kopie tabulky HBase a změny schématu tabulky HBase
Ve výchozím nastavení CopyTable zkopíruje všechny rodiny sloupců z odpovídajících řádků. CopyTable poskytuje možnosti pouze pro kopírování dat z konkrétních rodin sloupců. To by mohlo být užitečné pro kopírování původních zdrojových dat a vyloučení odvozených skupin datových sloupců, které jsou přidány následným zpracováním.
Přidáním těchto argumentů zkopírujeme pouze data ze zadaných rodin sloupců.
- –families=srcCf1
- –families=srcCf1,srcCf2
Počínaje verzí 0.92.0 můžete při změně názvu rodiny sloupců kopírovat:
- –families=srcCf1:dstCf1
- kopírovat z srcCf1 do dstCf1
- –families=srcCf1:dstCf1,dstCf2,srcCf3:dstCf3
- kopírovat z srcCf1 do destCf1, zkopírovat dstCf2 do dstCf2 (bez přejmenování) a srcCf3 do dstCf3
Upozorňujeme, že dstCf* musí být přítomen v tabulce dstCluster!
Počínaje verzí 0.94.0 jsou nabízeny nové možnosti kopírování a odstraňování značek a zahrnutí omezeného počtu přepsaných verzí. Dříve, pokud byl odstraněn řádek ve zdrojovém clusteru, odstranění by se nezkopírovalo – místo toho by v cílovém clusteru zůstala zastaralá verze tohoto řádku. To využívá některé z pokročilých funkcí vydání 0.94.0.
- –versions=vers
- kde vers je počet verzí buněk, které se mají zkopírovat (výchozí je 1, tedy pouze nejnovější)
- –all.cells
- také zkopírujte smazané značky a smazané buňky
Běžná úskalí
Klient HBase ve verzích 0.90.x, 0.92.xa 0.94.x vždy používá zoo.cfg, pokud je v cestě ke třídě, i když soubor hbase-site.xml určuje jiná nastavení konfigurace kvora ZooKeeper. Tato „funkce“ způsobuje problém běžný v CDH3 HBase, protože jeho balíčky ve výchozím nastavení zahrnují adresář, kde se nachází zoo.cfg v cestě třídy HBase. To může vést a vede k frustraci při pokusu o použití CopyTable (HBASE-4614). Řešením je vyloučit soubor zoo.cfg z cesty třídy vaší HBase a zadat vlastnosti konfigurace ZooKeeper v souboru hbase-site.xml. http://hbase.apache.org/book.html#zookeeper
Závěr
CopyTable poskytuje jednoduché, ale efektivní pojištění obnovy po havárii pro nasazení HBase 0.90.x (CDH3). Ve spojení s funkcí replikace, která se nachází a podporuje v HBase založeném na CDH4 HBase 0.92.x, se přírůstkové funkce CopyTable stávají méně hodnotnými, ale jejich základní funkce jsou důležité pro bootstrapping replikované tabulky. I když pokročilejší funkce, jako jsou snímky HBase (HBASE-50), mohou po implementaci pomoci s obnovou po havárii, CopyTable bude stále užitečným nástrojem pro správce HBase.