Введение

Многие успешные стартапы рано или поздно сталкиваются с работой с большими объемами данных и должны быть готовы - знать инструменты и алгоритмы. Благо теорию до нас проработали Google, Facebook*, Twitter и даже Amazon приготовил веб-сервисы, помогающие противостоять таким задачам.

Если, вдруг, возникла задача на резервное копирование Bigdat'ы? Можно использовать алгоритм map-reduce (от Google) или бесплатный инструмент кластерных параллельных вычислений - hadoop, используемый в Facebook*, Twitter, Yahoo и много ещё где (от единиц машин до тысяч в кластере).

* Социальная сеть признана экстремистской и запрещена на территории Российской Федерации.

  Что такое Hadoop & map-reduce

Логика этих механизмов очень проста:

1. Имеется входной поток данных (например: логи, почта, имена файлов).
2. Имеется алгоритм: взять строку из stdin и напечатать строку в stdout, что нибудь делая полезного по пути. Алгоритм реализует скриптик mapper.
3. Все что выведено в п.2, нужно агрегировать - этим занимается алгоритм в скриптике reducer.

Далее все это загружается в кластер, расширяется на кучу машин (настраивается), параллельно выполняется и получаем выполненную в N раз быстрее задачу. При этом проверяется состояние каждой задачи, каждой машины, если что, задачи рестартуются. Что важно, активно используется локальная кластерная файловая система для обмена данными между нодами кластера hdfs.

  Пример решения задачи

Имеется 10 млн. файлов, хранящиеся в бакете s3. Необходимо измененные файлы скопировать в другой бакет s3 за разумное время. Как?

Если в проекте есть 10 млн. файлов, то нужно пробежать по 10 млн файлов и определить, изменился ли каждый файл. А если изменился, то нужно скопировать в другой бакет.

То есть нужно для каждого файла выполнить операцию условного копирования (E-tag или Update-time) из бакета А, в бакет Б - по http. Сами данные - не перемещаются, только обращения к API. (Но в перспективе может возникнуть потребность и файлы переносить в другой регион на другие сервера.) Батчей на копирование в API S3 (put copy) - нет, но даже если бы были, ненамного ускорили бы.

Дополнительно можно попробовать:

• curl-multi - перерасход памяти, все равно не снимает необходимости параллелить потоки.
• Запускать параллельно в N потоков/процессов, но на одной машине можно эффективно запустить в работу довольно ограниченное число параллельных процессов - десятки.

Но даже в этом случае максимум, что можно получить из нескольких параллельных процессов на одном сервере, создавая заметную нагрузку - неделя срока на каждое резервное копирование.

И ещё сложность в том, что нужно это настроить, администрировать, запускать и останавливать.

Что предлагает Amazon

В связи с востребованностью клиентами кейса для:

• обработки и агрегации логов для систем аналитики веб-сайтов;
• обработки больших объёмов писем;
• обработки твитов (в twitter) и т.п.;
• обработки миллионов задач параллельно;

Amazon предложил веб-сервис, оптимально заточенный под резервирование больших объёмов данных:

1. hadoop уже предустановлен в виде настроенной виртуальной машины, нужно его подстроить и нагрузить заданиями.
2. Наши данные (имена файлов) заливаются в S3
3. В s3 можно разместить и выполнимый код алгоритма, например на php (хоть на bash).
4. Запускается одну команда в консоли с параметрами.
5. Создается вычислительный кластер, все данные резервируются, а результат выгружается в S3
6. Кластер закрывается

При такой схеме оплата идёт только за время использования железных серверов, но несколько (~20%) выше, чем за обычные железки. Это из-за того, что автоматической настройкой, интеграцией с S3, файероволами и обновлением кластерного софта занимается сам Amazon. В принципе клиент может сам этим заниматься и не доплачивать 20%, но придется всю автоматику написать и постоянно обслуживать.

От клиента требуется разработать простейший алгоритм, положить его в виде файлика и входные данные в S3. Дальнейшая работа по бекапу - автоматическая.

  Как реализован этот механизм на примере Битрикс24

Созданы необходимые элементарно простые mapper, reducer, конфигуратор.

Подготовил код создания списка файлов (во много потоков, конечно, но занимает полчасика и нагрузку особую не создает). Включил в крон:

/home/bitrix/bxc/cron_jobs/bkp_s3_folder_hadoop.php

/opt/aws/emr/elastic-mapreduce --create --stream \
--name bx24_s3_bkp_$D \
--step-name bx24_s3_bkp_$D \
--with-termination-protection \
--step-action CANCEL_AND_WAIT \
--ami-version '2.4.2' \
--bootstrap-action 's3://***/code/bkp_s3_folder_hadoop_bootstrap.sh' \
--bootstrap-action 's3://elasticmapreduce/bootstrap-actions/configure-hadoop' \
--args "-m,mapred.map.max.attempts=20,-m,mapred.tasktracker.map.tasks.maximum=15,-m,mapred.task.timeout=600000" \
--input 's3://***/input/' \
--mapper 's3://***/code/bkp_s3_folder_hadoop_mapper.php' \
--reducer 's3://***/code/bkp_s3_folder_hadoop_reducer.php' \
--output 's3://***/output_'$D \
--log-uri 's3://***/logs/' \
--num-instances 5 \
--master-instance-type m1.small \
--slave-instance-type m1.xlarge \
--key-pair '***'

Скрипт формирует, затем выгружает список файлов в облако и стартует кластер hadoop (6 машин):

/home/bitrix/bxc/cron_jobs/bkp_s3_folder_hadoop_launcher.sh

Необходимо также подправить настройки виртуальной машины Amazon, объем памяти и число воркеров. При старте мы в bootstrap дописываем несколько своих настроек. После всех этих действий желательно провести тестирование на большом объёме файлов, например 10 миллионов:

Этим способом можно сократить время бэкапа 10 млн. файлов до 16 часов вместо 7 дней. То есть можно делать резервное копирование чаще. А если файлов станет 20 миллионов, то надо просто изменить лишь одну циферку в скрипте запуска кластера hadoop.