Мы уже писали о важности резервного копирования данных в Apache HBase на примере ИТ-компании Clairvoyant. Сегодня рассмотрим опыт индийской компании Myntra, которая предложила простую методику создания инкрементных бэкапов для Apache HBase 2.1.4 и Hadoop 2.7.3, а также восстановления нужных данных из этих резервных копий в BLOB-хранилищах по требованию пользователя.
5 шагов создания инкрементных бэкапов из Apache HBase в BLOB-хранилище
Apache HBase, популярная NoSQL-база данных, реализует возможности Google BigTable для Hadoop HDFS. Хотя она отличается высокой надежностью, резервное копирование актуально и для этого NoSQL-хранилища. Корпоративные версии HBase от IBM, Cloudera, Hortonworks и прочих коммерческих провайдеров, предоставляются с функцией инкрементного резервного копирования, а в open-source дистрибутивах эти функции отсутствуют. Впрочем, справедливости ради стоит отметить, что в релизе 3.0 есть возможность инкрементного резервного копирования. Однако, версия 3.0, выпущенная 27 июня 2022 года, все еще находится в статусе альфа и не рекомендуется для промышленного применения. Тем не менее, стратегия постепенного резервного копирования данных и их восстановления в случае катастрофического сбоя помогает избежать нехватки места на диске для кластера HBase по мере роста данных. Эту стратегию реализует постоянное создание резервных копий данных в облачное хранилище, чтобы восстановить их в зависимости от выбранной детализации времени.
Следующая стратегия инкрементного резервного копирования и восстановления, реализованная в индийской ИТ-компании Myntra, рассчитана на Apache HBase 2.1.4 и Hadoop 2.7.3. Дата-инженеры Myntra хранят данные за последние 30 дней в своем кластере HBase, а более старые данные резервируются в облачном хранилище данных, сжимаются и готовы к восстановлению по требованию. Время жизни каждой записи составляет 1 месяц (30 дней), и любая запись старше 30 дней автоматически удаляется. Это время жизни задается при создании таблицы в команде CREATE:
create ‘my_table’, {‘NAME’ => ‘my_col_fam’,’TTL’ => 2592000}
Для вчерашних данных ежедневно запускается cron-задание резервного копирования, которое состоит из следующих шагов:
- фрагментирование и экспорт данных. Учитывая ежедневный объем (миллионы строк), достаточно высока вероятность получить ошибку тайм-аута при попытке сделать резервную копию данных за весь день. Перезапуск процесса также является дорогостоящей операцией без гарантии успешного выполнения. Поэтому дневные данные делятся по часам. Резервное копирование данных предыдущего дня выполняется сперва за первый час (с 00:00:00 до 01:00:00), затем за второй час, за третий и т.д. Каждый фрагмент данных (chunk) копируется во временное место в HDFS с помощью команды экспорта с опциями, определяющими имя таблицы, каталог HDFS для хранения, версию, а также начало и конец временного диапазона в эпохе:
hbase org.apache.hadoop.hbase.coprocessor.Export ‘my_table’ hdfs://hbase_master_ip:9000/backup/2021–01–02–07–00–00TO2021–01–02–08–00–00 5 1609551000000 16095546000000
- Далее экспортированные данные копируются в локальный каталог на узле кластера Hadoop
hadoop fs -copyToLocal hdfs://hbase_master_ip:9000/backup/2021–01–02–07–00–00TO2021–01–02–08–00–00 /tmp
- Затем выполняется уплотнение данных. Рекомендуется сжимать данные для эффективного использования хранилища BLOB-объектов.
cd /tmp && tar -zcvf 2021–01–02–07–00–00TO2021–01–02–08–00–00 2021–01–02–07–00–00TO2021–01–02–08–00–00.tar.gz
- Затем сжатый фрагмент загружается в хранилище больших двоичных объектов через пользовательскую операцию.
- Наконец, необходимо выполнить очистку дискового пространства, занятого временными и промежуточными файлами, которые были созданы в процессе резервного копирования на вышеуказанных шагах. Это можно сделать с помощью следующих команд
fs -rm -R hdfs://hdfs_master_ip:9000/backup/2021–01–02–07–00–00TO2021–01–02–08–00–00rm -rf /tmp/2021–01–02–07–00–00TO2021–01–02–08–00–00.tar.gz rm -rf /tmp/2021–01–02–07–00–00TO2021–01–02–08–00–00
Далее рассмотрим процедуру, обратную созданию бэкапов, т.е. восстановление данных из резервной копии.
Восстановление данных
Восстановление данных из резервной копии сводится к зеркальному отображению процесса создания бэкапа. Нужно взять фрагмент данных из облачного хранилища и восстановить их в таблице HBase. Обычно это выполняется не в регулярном режиме, а по запросу и представляет собой следующий набор действий:
- сперва фрагмент загружается из хранилища BLOB-объектов на локальный компьютер
cd /tmp && wget {cloud_storage_end_point}/my-team-hbase-dumps/my-table/2021–01–02/2021–01–02–07–00–00TO2021–01–02–08–00–00.tar.gz
- затем этот файл нужно разархивировать
cd /tmp && tar -zxvf 2021–01–02–07–00–00TO2021–01–02–08–00–00 2021–01–02–07–00–00TO2021–01–02–08–00–00.tar.gz
- далее скопировать из локального каталога в каталог HDFS
hadoop fs -copyFromLocal /tmp/2021–01–02–07–00–00TO2021–01–02–08–00–00 hdfs://hdfs_master_ip:9000/backup
- наконец, фрагмент данных из резервной копии попадает в таблицу HBase
hbase org.apache.hadoop.hbase.mapreduce.Import ‘my-table’ hdfs://hdfs_master_ip:9000/backup/2021–01–02–07–00–00TO2021–01–02–08–00–00
- в заключение следует удалить все временные файлы
hadoop fs -rm -R hdfs://hdfs_master_ip:9000/backup/2021–01–02–07–00–00TO2021–01–02–08–00–00rm -rf /tmp/2021–01–02–07–00–00TO2021–01–02–08–00–00.tar.gz
Чтобы вышеуказанный процесс резервного копирования и восстановления работал бесперебойно в экосистеме Hadoop и HBase, кластер должен иметь несколько конфигураций. Прежде всего, необходимо настроить запуск YARN, изменив файл yarn-site.xml. Следующую конфигурацию надо установить на всех главных и подчиненных узлах HDFS:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<property>
<name>yarn.acl.enable</name>
<value>0</value>
</property>
<property>
<name>yarn.resourcemanager.hostname</name>
<value>hadoop_master_ip</value>
</property>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
<property>
<name>yarn.scheduler.minimum-allocation-mb</name>
<value>9216</value>
<description>Minimum limit of memory to allocate to each container request at the Resource Manager.</description>
</property>
<property>
<name>yarn.scheduler.maximum-allocation-mb</name>
<value>27648</value>
<description>Maximum limit of memory to allocate to each container request at the Resource Manager.</description>
</property>
<property>
<name>yarn.nodemanager.resource.memory-mb</name>
<value>27648</value>
</property>
<property>
<name>mapreduce.map.memory.mb</name>
<value>9216</value>
</property>
<property>
<name>mapreduce.map.java.opts</name>
<value>-Xmx7372m</value>
</property>
<property>
<name>mapreduce.reduce.memory.mb</name>
<value>9216</value>
</property>
<property>
<name>mapreduce.reduce.java.opts</name>
<value>-Xmx7372m</value>
</property>
<property>
<name>yarn.app.mapreduce.am.resource.mb</name>
<value>9216</value>
</property>
<property>
<name>yarn.app.mapreduce.am.command-opts</name>
<value>-Xmx7372m</value>
</property>
<property>
<name>mapreduce.task.io.sort.mb</name>
<value>3686</value>
</property>
</configuration>
Также меняется файл mapred-site.xml:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
</configuration>
Для запуска команды экспорта данных в HBase следует настроить классы сопроцессора в файле hbase-site.xml на главном узле:
<?xml version="1.0" encoding="UTF-8"?> <configuration> <property> <name>hbase.coprocessor.region.classes</name> <value>org.apache.hadoop.hbase.coprocessor.Export</value> </property> <property> <name>zookeeper.session.timeout</name> <value>2400000</value> </property> <property> <name>hbase.zookeeper.property.tickTime</name> <value>120000</value> </property> <property> <name>hbase.rpc.timeout</name> <value>2400000</value> </property> <property> <name>hbase.client.operation.timeout</name> <value>2400000</value> </property> <property> <name>hbase.rpc.read.timeout</name> <value>2400000</value> </property> <property> <name>hbase.rpc.write.timeout</name> <value>2400000</value> </property> <property> <name>hbase.client.meta.operation.timeout</name> <value>2400000</value> </property> <property> <name>hbase.client.scanner.timeout.period</name> <value>2400000</value> </property> </configuration>
В этой конфигурации указано более высокое значение для параметра hbase.zookeeper.property.tickTime, т.к. для экспорта огромных данных требуется больше времени. Если время превышает значение параметра zookeeper.session.timeout, процесс становится незавершенным, и экспорт данных завершится сбоем. Чтобы избежать этого, следует увеличить значение zookeeper.session.timeout, не меньше hbase.zookeeper.property.tickTime*2, но не больше hbase.zookeeper.property.tickTime*20.
Эти изменения конфигурационных файлов помогли команде дата-инженеров и администраторов Myntra повысить стабильность кластера Apache HBase, а также увеличить надежность этой NoSQL-СУБД за счет регулярных операций резервного копирования и восстановления данных из бэкапа по требованию.
Код курса
NOSQL
Ближайшая дата курса
Продолжительность
ак.часов
Стоимость обучения
0 руб.
Узнайте больше подробностей про администрирование и эксплуатацию Apache Hive и других компонентов экосистемы Hadoop для хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
