Репликацията (разгледана в тази предишна статия в блога) беше пусната за известно време и е сред най-използваните функции на Apache HBase. Наличието на клъстери, репликиращи данни с различни партньори, е много често срещано внедряване, независимо дали като стратегия за DR или просто като безпроблемен начин за репликиране на данни между среда за производство/постановка/разработка. Въпреки че е ефективен начин за синхронизиране на различни HBase бази данни в рамките на латентност от по-малко от секунда, репликацията работи само върху данни, погълнати след активиране на функцията. Това означава, че всички съществуващи данни за всички клъстери, участващи в разгръщането на репликация, все пак ще трябва да бъдат копирани между партньорите по някакъв друг начин. Има доста инструменти, които могат да се използват за синхронизиране на вече съществуващи данни на различни партньорски клъстери. Snapshots, BulkLoad, CopyTable са добре познати примери за такива инструменти, обхванати в предишни публикации в блога на Cloudera. В тази статия ще разгледаме HashTable/SyncTable, подробно описвайки част от вътрешната му логика на внедряване, плюсовете и минусите на използването му и как се сравнява с някои от другите техники за копиране на данни, споменати по-горе.
HashTable/SyncTable накратко
HashTable/SyncTable е инструмент, реализиран като две задачи за намаляване на картата, които се изпълняват като отделни стъпки. Изглежда подобно на CopyTable инструмент, който може да извършва както частични, така и цели копия на данни в таблицата. За разлика от CopyTable той копира само различни данни между целевите клъстери, спестявайки както мрежови, така и изчислителни ресурси по време на процедурата на копиране.
Първата стъпка, която трябва да се изпълни в процеса, е HashTable работа за намаляване на картата. Това трябва да се изпълнява на клъстера, чиито данни трябва да бъдат копирани на отдалечения партньор, обикновено изходния клъстер. По-долу е показан бърз пример за това как да го стартирате, подробно обяснение на всеки от необходимите параметри е дадено по-късно в тази статия:
hbase org.apache.hadoop.hbase.mapreduce.HashTable --families=cf my-table /hashes/test-tbl…20/04/28 05:05:48 ИНФОРМАЦИЯ mapreduce.Работа: карта 100% намаление 100 %20/04/28 05:05:49 INFO mapreduce.Job:Работа job_1587986840019_0001 завършена успешно 20/04/28 05:05:49 INFO mapreduce.Job:Броячи:68...File Input Formats Formats Readmat=0 Написано=6811788
След като HashTable изпълнението на заданието с горната команда е завършено, някои изходни файлове са генерирани в изходния hdfs /hashes/my-table директория:
hdfs dfs -ls -R /hashes/test-tbldrwxr-xr-x - основна супергрупа 0 2020-04-28 05:05 /hashes/test-tbl/hashes-rw-r--r-- 2 корена супергрупа 0 2020-04-28 05:05 /hashes/test-tbl/hashes/_SUCCESSdrwxr-xr-x - основна супергрупа 0 2020-04-28 05:05 /hashes/hashes/test/ -rw-r--r-- 2 коренна супергрупа 6790909 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000/data-rw-r--r-- 2 коренна супергрупа 7 9 208 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000/index-rw-r--r-- 2 коренна супергрупа 99 2020-04-28 05:04 /hashes/test- tbl/manifest-rw-r--r-- 2 коренова супергрупа 153 2020-04-28 05:04 /hashes/test-tbl/partitions
Те са необходими като вход за SyncTable бягай. SyncTable трябва да се стартира на целевия партньор. Командата по-долу изпълнява SyncTable за изхода на HashTable от предишния пример. Той използва dryrun опция, обяснена по-късно в тази статия:
hbase org.apache.hadoop.hbase.mapreduce.SyncTable --dryrun --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://source- cluster-active-nn/hashes/test-tbl test-tbl test-tbl…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97146HASHES_NOT_MATCHED=2MATCHINGCELLS=17MATCHINGROWS=2RANGESNOTMATCHED=2ROWSWITHDIFFS=2SOURCEMISSINGCELLS=1TARGETMISSINGCELLS=1
Като бърза справка можете просто да замените дадените параметри и в двата примера с действителните стойности на средата. Останалата част от тази статия ще обхване подробностите за внедряването по-задълбочено.
Защо две различни стъпки?
Основната цел на този инструмент е да идентифицира и копира само данни, които липсват между двата клъстера. HashTable работи като задача за разделяне/индексиране, като анализира партиди от данни от таблицата и генерира хеш индекси за всяка от тези партиди. Това са резултатите, записани във файловете под /hashes/my-table hdfs директорията се предава като един от параметрите на заданието. Както бе споменато по-горе, този изход се изисква от SyncTable работа. SyncTable сканира целевата таблица локално в същите партидни размери, както се използва от HashTable, и също така изчислява хеш стойности за тези партиди, използвайки същата функция, използвана от HashTable. След това сравнява локалния пакетен хеш стойност с тази от HashTable изход. Ако хеш стойностите са равни, това означава, че цялата партида е идентична в двата клъстера и нищо не трябва да се копира в този сегмент. В противен случай той отваря сканиране за партидата в изходния клъстер, като проверява дали всяка от клетките вече съществува в целевия клъстер, като копира само тези, които се разминават. При оскъдни, малко по-различни набори от данни, това би довело до много по-малко данни, които се копират между двата клъстера. Също така ще изисква само малък брой клетки да бъдат сканирани в източника, за да се провери за несъответствия.
Задължителни параметри
HashTable изисква само два параметъра:името на таблицата и изходния път, където ще бъдат записани свързани хешове и други метаинформационни файлове. SyncTable използва HashTable изходен каталог като вход, заедно с имената на таблиците в източника и в целевия клъстер, съответно. Тъй като използваме HashTable /SyncTable за преместване на данни между отдалечени клъстери, sourcezkcluster опцията трябва да бъде дефинирана за SyncTable . Това трябва да бъде адресът на кворума на zookeeper на изходния клъстер. В този пример за статия също така се позовахме директно на адреса на активния възел на източника на клъстера, така че SyncTable ще прочете изходния файл на хеш директно от изходния клъстер. Като алтернатива, HashTable изходът може да бъде копиран ръчно от изходен клъстер в отдалечен клъстер (например с distcp).
| ЗАБЕЛЕЖКА:Работата с отдалечени клъстери под различни kerberos сфери се поддържа само от CDH 6.2.1 нататък. |
Разширени опции
И двете HashTable и SyncTable предлагат допълнителни опции, които могат да бъдат настроени за оптимални резултати.
HashTable позволява филтриране на данните както по ключ на реда, така и по време на модификация, с startrow/starttime, stoprow/stoptime имоти, респ. Обхватът на набора от данни може също да бъде ограничен от версии и семейства Имоти. Размерът на партидата свойството определя размера на всяка част, която ще бъде хеширана. Това влияе пряко върху производителността на синхронизиране. В случаите на много малко несъответствия, задаването на по-големи стойности на партидата може да доведе до по-добра производителност, тъй като по-големи части от набора от данни ще бъдат игнорирани, без да е необходимо да бъдат сканирани от SyncTable.
SyncTable осигурява сухо изпълнение опция, която позволява предварителен преглед на промените, които да бъдат приложени в целта.
SyncTable поведението по подразбиране е да се отразяват изходните данни на целевата страна, така че всяка допълнителна клетка, присъстваща в целта, но отсъстваща в източника, в крайна сметка се изтрива от целевата страна. Това може да е нежелателно при синхронизиране на клъстери при настройка за репликация Active-Active и за такива случаи doDeletes опциите могат да бъдат превърнати на false, като се пропуска репликацията на изтривания на целта. Има и подобен doPuts флаг за случаи, когато допълнителни клетки не трябва да се вмъкват в целевия клъстер.
Анализиране на изходите
HashTable извежда няколко файла с мета информация за SyncTable, те обаче не са четими от човека. Той не извършва никакви промени върху съществуващите данни, така че свързаната информация е от малък интерес за потребителския контекст.
SyncTable е стъпката, която наистина прилага модификациите към целта и може да е важно да прегледате нейното обобщение, преди действително да промените данните за целевия клъстер (вижте dryrun опция, спомената по-горе). Той публикува някои подходящи броячи в края на картата намалява изпълнението. Разглеждайки стойностите от горния пример, можем да видим, че има 97148 хеширани дялове (докладвани от ПАРТДИ брояч), който SyncTable открити отклонения само в две от тях (според HASHES_MATCHED и HASHES_NOT_MACTHED броячи). Освен това, в рамките на двата дяла с различни хешове, 17 клетки над 2 реда съвпадат (както се съобщава от MATCHING_CELLS и MATCHING_ROWS, съответно), но имаше и 2 реда разминаващи се, на тези два дяла (според RANGESNOTMATCHED и ROWSWITHDIFFS ). И накрая, SOURCEMISSINGCELLS и ЦЕЛЕВИ КЛЕТКИ кажете ни подробно дали клетките са присъствали само в изходния или целевия клъстер. В този пример изходният клъстер имаше една клетка, която не беше на целта, но целта имаше и клетка, която не беше в източника. От SyncTable беше стартирано без да се посочи dryrun опция и настройка doDeletes опция за false , заданието е изтрило допълнителната клетка в целевия клъстер и е добавило допълнителната клетка, намерена в източника, към целевия клъстер. Ако приемем, че няма записвания се случва на всеки клъстер, последващо изпълнение на същата SyncTable командата в целевия клъстер няма да покаже разлики:
hbase org.apache.hadoop.hbase.mapreduce.SyncTable --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://nn:9000/hashes /test-tbl test-tbl test-tbl…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97148…
Приложими сценарии
Синхронизиране на данни
На пръв поглед HashTable/SyncTable може да изглежда, че се припокрива с CopyTable инструмент, но все още има специфични сценарии, при които всеки инструмент би бил по-подходящ. Като първи пример за сравнение, използвайки HashTable/SyncTable за първоначално зареждане на таблица, съдържаща 100 004 реда и общ размер на данните от 5,17 GB, са необходими няколко минути само за SyncTable за да завършите:
...20/04/29 03:48:00 INFO mapreduce.Job:Работно задание:job_1587985272792_001120/04/29 03:48:09 ИНФОРМАЦИЯ mapreduce.Job:Job job_15879852079 Running job_15879852070 в режим u/false10 29 03:48:09 ИНФО mapreduce.Работа: карта 0% намаление 0%20/04/29 03:54:08 ИНФОРМАЦИЯ mapreduce.Работа: карта 100% намаление 0%20/04/29 03:54:09 ИНФО mapreduce .Job:Job job_1587985272792_0011 completed successfully…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148EMPTY_BATCHES=97148HASHES_NOT_MATCHED=97148RANGESNOTMATCHED=97148ROWSWITHDIFFS=100004TARGETMISSINGCELLS=749589TARGETMISSINGROWS=100004
Дори на такъв малък набор от данни, CopyTable се изпълнява по-бързо (приблизително 3 минути, докато SyncTable отне 6 минути за копиране на целия набор от данни):
...20/04/29 05:12:07 INFO mapreduce.Job:Работно задание:job_1587986840019_000520/04/29 05:12:24 ИНФОРМАЦИЯ mapreduce.Job:Job job_1587986. 29 05:12:24 ИНФО mapreduce.Работа: карта 0% намаление 0%20/04/29 05:13:16 ИНФО mapreduce.Работа: карта 25% намаление 0%20/04/29 05:13:49 ИНФО mapreduce .Работа: карта 50% намаление 0%20/04/29 05:14:37 ИНФОРМАЦИЯ mapreduce.Работа: карта 75% намаление 0%20/04/29 05:15:14 ИНФОРМАЦИЯ mapreduce.Работа: карта 100% намаление 0 %20/04/29 05:15:14 INFO mapreduce.Job:Job job_1587986840019_0005 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=2787236791BYTES_IN_RESULTS=5549784428MILLIS_BETWEEN_NEXTS=130808NOT_SERVING_REGION_EXCEPTION=0NUM_SCANNER_RESTARTS=0NUM_SCAN_RESULTS_STALE=0REGIONS_SCANNED=4REMOTE_RPC_CALLS=1334REMOTE_RPC_RETRIES=0ROWS_FILTERED=0ROWS_SCANNED=100004RPC_CALLS=2657RPC_RETRIES=0Сега нека отново използваме двата инструмента, за да се справим с оскъдните разлики в набора от данни. test-tbl таблицата, използвана във всички тези примери, има четири региона в изходния клъстер. След като целият оригинален набор от данни беше копиран в целеви клъстер в предишния пример, добавихме четири допълнителни реда само от страната на източника, по един за всеки от съществуващите региони, след което стартирахме HashTable/SyncTable отново за синхронизиране и двата клъстера:
20/04/29 05:29:23 INFO mapreduce.Job:Работно задание:job_1587985272792_001320/04/04/29 05:29:39 INFO mapreduce.Job:Job job_158798527029:Работа job_158798527029:0 run:u false mode:0 false 29:39 ИНФОРМАЦИЯ mapreduce.Job: карта 0% намаление 0%20/04/29 05:29:53 INFO mapreduce.Job: карта 50% намаление 0%20/04/29 05:30:42 INFO mapreduce.Job:карта 100% намаление 0%20/04/29 05:30:42 ИНФОРМАЦИЯ mapreduce.Job:Работата job_1587985272792_0013 завършена успешно…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncTable$SyncMappersHatchMapper4ShMapper4ShMapper1ChMapperShMapper4ShMapper1ChMapper4ShMapper1ChMapper4ShMapper1ChMapper4ShMapper1ChMapper4ShMapper1ChMapper4ShMapper1ChMapper4ShMapper1ChMapper4ShMapper4ChMapper4ShMapperShMapperShMapper4ShMapper1ChMapper4ShMapperShMapper4ShMapperShMapperShMapper4ShMapperShMapper4ShMapper100 5RANGESNOTMATCHED=4ROWSWITHDIFFS=4TARGETMISSINGCELLS=4TARGETMISSINGROWS=4Можем да видим това само с четири несъответстващи дялове, SyncTable беше значително по-бързо (приблизително една минута за завършване). Използване на CopyTable за да извършите същото синхронизиране показа следните резултати:
20/04/29 08:32:38 INFO mapreduce.Job:Работно задание:job_1587986840019_000820/04/04/29 08:32:52 INFO mapreduce.Job:Job job_1587986_0908 run:u false mode:0 false 32:52 ИНФОРМАЦИЯ mapreduce.Job: карта 0% намаление 0%20/04/29 08:33:38 ИНФОРМАЦИЯ mapreduce.Job: карта 25% намаление 0% 20/04/29 08:34:15 ИНФОРМАЦИЯ mapreduce.Job:карта 50% намаление 0%20/04/29 08:34:48 ИНФОРМАЦИЯ mapreduce.Работа: карта 75% намаление 0%20/04/29 08:35:31 ИНФОРМАЦИЯ mapreduce.Работа: карта 100% намаление 0%20/ 04/29 08:35:32 INFO mapreduce.Job:Job job_1587986840019_0008 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=2762547723BYTES_IN_RESULTS=5549784600MILLIS_BETWEEN_NEXTS=340672NOT_SERVING_REGION_EXCEPTION=0NUM_SCANNER_RESTARTS=0NUM_SCAN_RESULTS_STALE=0REGIONS_SCANNED=4REMOTE_RPC_CALLS=1323REMOTE_RPC_RETRIES=0ROWS_FILTERED=0ROWS_SCANNED=100008RPC_CALLS=2657RPC_RETRIES=0CopyTable отне същото време за синхронизиране на таблиците, както при копирането на целия набор от данни, въпреки че имаше само четири клетки за копиране. Това все още беше добре за този много малък набор от данни и с неактивен клъстер, но при производствени случаи на използване с по-големи набори от данни и където целевият клъстер може също да се използва от много клиентски приложения, записващи данни върху него, CopyTable влошаване на производителността в сравнение с SyncTable би било дори по-високо.
Струва си да се спомене, че има и допълнителни инструменти/функции, които могат да се използват в комбинация за първоначално зареждане на целеви клъстер (целта изобщо няма данни), като експортиране на моментни снимки, групово натоварване или дори директно копие на оригинала директории на таблица от изходен клъстер. За първоначално зареждане с големи суми данни за копиране, правене на моментна снимка на таблицата и след това използване на ExportSnapshot инструментът ще превъзхожда онлайн инструментите за копиране като SyncTable или CopyTable.
Проверка на целостта на репликацията
Друга често срещана употреба на HashTable/SyncTable е за наблюдение на състоянието на репликация между клъстери, когато се отстраняват възможни проблеми с репликацията. В този сценарий той функционира като алтернатива на инструмента VerifyReplication. Обикновено при проверка на състоянието между два клъстера или изобщо няма несъответствия, или временен проблем с опцията е причинил несинхронизиране на малка част от по-големия набор от данни. В тестовата среда, която използвахме за предишния ни пример, трябва да има 100 008 реда със съвпадащи стойности и в двата клъстера. Изпълнението на SyncTable в целевия клъстер с опцията за сухо изпълнение ще ни позволи да идентифицираме всички разлики:
20/05/04 10:47:25 ИНФОРМАЦИЯ mapreduce.Работа:Работна задача:job_1588611199158_0004…20/05/04 10:48:48 ИНФОРМАЦИЯ mapreduce.Работа: карта 100% намаление 0%20/10 :48:48 INFO mapreduce.Job:Job job_1588611199158_0004 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=3753476784BYTES_IN_RESULTS=5549784600ROWS_SCANNED=100008…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97148...Unlike SyncTable we must run инструмента VerifyReplication на изходния клъстер. Предаваме идентификатора на партньора като един от неговите параметри, така че той да може да намери отдалечения клъстер, който да сканира за сравнение:20/05/04 11:01:58 INFO mapreduce.Job:Running job:job_1588611196128_0001…20/05/04 11:04:39 ИНФОРМАЦИЯ MapReduce.JOB:Карта 100% Намаляване 0% 20/05/04 11:04:39 Информация MapReduce.Job:Job Job_1588611196128_0001 Завършено ... .replication.VerifyReplication$Verifier$CountersGOODROWS=100008...Без разлики SyncTable открива всички хешове, които съвпадат между изходния и целевия дял и по този начин избягва необходимостта от повторно сканиране на отдалечения източник на клъстер. VerifyReplication извършва едно по едно сравнение за всяка клетка и в двата клъстера, което вече може да носи висока мрежова цена, дори когато се работи с толкова малки набори от данни.
Добавяне на един допълнителен ред в изходния клъстер и извършване на проверките отново. С VerifyReplication:
20/05/05 11:14:05 ИНФОРМАЦИЯ mapreduce.Работа:Работна задача:job_1588611196128_0004…20/05/05 11:16:32 ИНФОРМАЦИЯ mapreduce.Работа: карта 100% намаление 0%20/10 :16:32 ИНФОРМАЦИЯ mapreduce.Job:Job job_1588611196128_0004 завършена успешно…org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication$Verifier$CountersBADROWS=1GOODROWS=1000W08=1GOODROWS=1000W0_RO...Преди да можем да използваме SyncTable, трябва отново да регенерираме хешове в източника с HashTable, тъй като сега има нова клетка:
20/05/04 11:31:48 ИНФОРМАЦИЯ mapreduce.Job:Работно задание:job_1588611196128_0003…20/05/04 11:33:15 INFO mapreduce.Job:Job job_1588611110612 завършено успешноСега SyncTable:
20/05/07 05:47:51 ИНФОРМАЦИЯ mapreduce.Работа:Работно задание:job_1588611199158_0014…20/05/07 05:49:20 ИНФОРМАЦИЯ mapreduce.Работа:Работа job_1588611199 завършена успешно<>4 завършена8_00b>4 org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_NOT_MATCHED=97148MATCHINGCELLS=749593MATCHINGROWS=100008RANGESMATCHED=97147RANGESNOTMATCHED=1ROWSWITHDIFFS=1TARGETMISSINGCELLS=1TARGETMISSINGROWS=1Можем да видим увеличаването на времето за изпълнение поради допълнително сканиране и сравнение на клетки между двата отдалечени клъстера. Междувременно времето за изпълнение на VerifyReplication показва малки вариации.
Заключение
HashTable/SyncTable е ценен инструмент за преместване на данни наоколо, когато се справяте с оскъдни несъответствия между два набора от данни за клъстери. Той използва разделяне на данни и хеширане за ефективно откриване на разлики в диапазони от двата набора данни, като намалява броя на клетките, които трябва да бъдат сканирани, докато сравнява данни от двата клъстера, като същевременно избягва ненужно поставяне на вече съществуващи стойности в целевия клъстер. Това обаче не е сребърен куршум, както е показано в някои от примерите по-горе, докато може да изглежда, че се припокрива във функция с CopyTable инструмент, последният може да предложи по-добра производителност при работа с по-голям, последователен диапазон от несъответстващи клетки. В този смисъл, HashTable/SyncTable би било най-приложимо в случаите, когато и двата клъстера вече имат някои данни, или в случаите, когато съществуваща настройка на репликация е била нарушена поради временна недостъпност на един от партньорите.
Свързани статии:
https://blog.cloudera.com/apache-hbase-replication-overview/
https://blog.cloudera.com/approaches-to-backup-and-disaster-recovery-in-hbase/
https://blog.cloudera.com/online-apache-hbase-backups-with-copytable/
https://blog.cloudera.com/introduction-to-apache-hbase-snapshots/
