CopyTable е проста помощна програма на Apache HBase, която не е изненадващо, че може да се използва за копиране на отделни таблици в HBase клъстер или от един HBase клъстер в друг. В тази публикация в блога ще говорим за това какво представлява този инструмент, защо бихте искали да го използвате, как да го използвате и някои общи предупреждения за конфигурацията.
Случаи на употреба:
CopyTable е в основата си задача на Apache Hadoop MapReduce, която използва стандартния интерфейс за четене на HBase Scan за четене на записи от отделна таблица и ги записва в друга таблица (евентуално в отделен клъстер), използвайки стандартния интерфейс за път на запис HBase Put. Може да се използва за много цели:
- Вътрешно копие на таблица (Моментна снимка на бедния човек)
- Отдалечено архивиране на HBase екземпляр
- Инкрементални копия на таблица на HBase
- Частични копия на HBase таблици и промени в схемата на HBase таблици
Предположения и ограничения:
Инструментът CopyTable има някои основни допускания и ограничения. Първо, ако се използват в ситуация с множество клъстери, и двата клъстера трябва да са онлайн и целевият екземпляр трябва да има целевата таблица със същите семейства колони, дефинирани като таблицата източник.
Тъй като инструментът използва стандартно сканиране и поставяне, целевият клъстер не трябва да има същия брой възли или региони. Всъщност той може да има различен брой таблици, различен брой регионални сървъри и може да има напълно различни граници на разделяне на региони. Тъй като копираме цели таблици, можете да използвате настройки за оптимизиране на производителността, като задаване на по-големи стойности за кеширане на скенера за по-голяма ефективност. Използването на интерфейса put също означава, че могат да се правят копия между клъстери от различни второстепенни версии. (0.90.4 -> 0.90.6, CDH3u3 -> CDH3u4) или версии, които са съвместими с кабел (0.92.1 -> 0.94.0).
И накрая, HBase предоставя само ACID гаранции на ниво ред; това означава, че докато CopyTable е в ход, може да се появят нововмъкнати или актуализирани редове и тези едновременни редакции ще бъдат или напълно включени, или напълно изключени. Въпреки че редовете ще бъдат последователни, няма гаранции за последователността, причинно-следствената връзка или реда на поставяне на другите редове.
Вътрешно копие на таблица (Моментна снимка на бедния човек)
Версии на HBase до и включително най-новите версии 0.94.x не поддържат моментна снимка на таблицата. Въпреки ограниченията на ACID на HBase, CopyTable може да се използва като наивен механизъм за моментни снимки, който прави физическо копие на определена таблица.
Да кажем, че имаме таблица, tableOrig със семейства колони cf1 и cf2. Искаме да копираме всички негови данни в tableCopy. Първо трябва да създадем tableCopy със същите семейства колони:
srcCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell
След това можем да създадем и копираме таблицата с ново име на същия HBase екземпляр:
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=tableCopy tableOrig
Това стартира MR задание, което ще копира данните.
Отдалечено архивиране на HBase екземпляр
Да кажем, че искаме да копираме данни в друг клъстер. Това може да бъде еднократно архивиране, периодична работа или може да бъде за стартиране за кръстосано репликация. В този пример ще имаме два отделни клъстера:srcCluster и dstCluster.
В този случай с множество клъстери, CopyTable е процес на натискане — вашият източник ще бъде HBase екземплярът, към който се отнася текущият ви hbase-site.xml, а добавените аргументи сочат към целевия клъстер и таблица. Това също предполага, че всички MR TaskTrackers имат достъп до всички HBase и ZK възли в целевия клъстер. Този механизъм за конфигуриране също означава, че можете да стартирате това като работа на отдалечен клъстер, като отмените конфигурациите hbase/mr, за да използвате настройки от всеки достъпен отдалечен клъстер и да посочите ZK възлите в целевия клъстер. Това може да бъде полезно, ако искате да копирате данни от HBase клъстер с по-ниски SLA и не искате да изпълнявате MR задания върху тях директно.
Ще използвате настройката –peer.adr, за да посочите ZK ансамбъла на целевия клъстер (например клъстера, към който копирате). За това се нуждаем от IP и порт на кворума на ZK, както и от основния ZK възел на HBase за нашия HBase екземпляр. Да кажем, че една от тези машини е srcClusterZK (изброена в hbase.zookeeper.quorum) и че използваме клиентския порт по подразбиране 2181 (hbase.zookeeper.property.clientPort) и родителския ZK znode /hbase (zookeeper.znode. родител). (Забележка:Ако сте имали два HBase екземпляра, използващи един и същ ZK, ще ви трябва различен 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
Обърнете внимание, че можете да използвате аргумента –new.name с –peer.adr, за да копирате в таблица с различно име в 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
Това ще копира данните от tableOrig в srcCluster в таблицата tableCopy на dstCluster.
Инкрементални копия на таблица HBase
След като имате копие на таблица в целевия клъстер, как да копирате нови данни, които по-късно се записват в изходния клъстер? Наивно можете да стартирате отново заданието CopyTable и да копирате върху цялата таблица. Въпреки това, CopyTable предоставя по-ефективен механизъм за инкрементално копиране, който просто копира актуализираните редове от srcCluster в резервния dstCluster, посочен в определен период от време. По този начин, след първоначалното копие, можете да имате периодично задание за cron, което копира данни само от предходния час от srcCluster към dstCuster.
Това става чрез посочване на аргументите –starttime и –endtime. Времената са посочени като десетични милисекунди от времето на епохата в 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
Частични копия на таблици HBase и промени в схемата на HBase таблица
По подразбиране CopyTable ще копира всички семейства колони от съвпадащи редове. CopyTable предоставя опции за копиране само на данни от конкретни семейства колони. Това може да бъде полезно за копиране на оригинални изходни данни и изключване на семейства колони с производни данни, които се добавят при последваща обработка.
Чрез добавяне на тези аргументи копираме само данни от посочените семейства колони.
- –families=srcCf1
- –families=srcCf1,srcCf2
Започвайки от 0.92.0, можете да копирате, докато променяте фамилното име на колоната:
- –families=srcCf1:dstCf1
- копиране от srcCf1 в dstCf1
- –families=srcCf1:dstCf1,dstCf2,srcCf3:dstCf3
- копирайте от srcCf1 в destCf1, копирайте dstCf2 в dstCf2 (без преименуване) и srcCf3 в dstCf3
Моля, имайте предвид, че dstCf* трябва да присъства в таблицата dstCluster!
Започвайки от 0.94.0 се предлагат нови опции за копиране на маркери за изтриване и за включване на ограничен брой презаписани версии. По-рано, ако ред бъде изтрит в изходния клъстер, изтриването няма да бъде копирано - вместо това остаряла версия на този ред ще остане в целевия клъстер. Това се възползва от някои от разширените функции на версията 0.94.0.
- –версии=верси
- където vers е броят на версиите на клетките за копиране (по подразбиране е 1 или само най-новата)
- –всички.клетки
- също копирайте маркерите за изтриване и изтритите клетки
Чести клопки
Клиентът HBase във версиите 0.90.x, 0.92.x и 0.94.x винаги използва zoo.cfg, ако е в пътя към класа, дори ако файл hbase-site.xml определя други настройки за конфигурация на кворума на ZooKeeper. Тази „функция“ причинява проблем, често срещан в CDH3 HBase, тъй като пакетите му по подразбиране включват директория, където zoo.cfg живее в пътя на класа на HBase. Това може и е довело до разочарование при опит за използване на CopyTable (HBASE-4614). Решението за това е да изключите файла zoo.cfg от пътя към класа на вашия HBase и да посочите конфигурационните свойства на ZooKeeper във вашия файл hbase-site.xml. http://hbase.apache.org/book.html#zookeeper
Заключение
CopyTable предоставя проста, но ефективна застраховка за възстановяване при бедствия за внедряване на HBase 0.90.x (CDH3). Във връзка с функцията за репликация, открита и поддържана в HBase на CDH4 HBase 0.92.x, инкременталните функции на CopyTable стават по-малко ценни, но основната му функционалност е важна за стартиране на репликирана таблица. Докато по-разширените функции като HBase моментни снимки (HBASE-50) могат да помогнат за възстановяването при аварийно състояние, когато бъде внедрено, CopyTable все още ще бъде полезен инструмент за администратора на HBase.
