Планирование заданий - демон cron.
Резервирование с помощью технологии git.
Большие данные всегда находятся в стадии развития. В ходе изменений очень часто приходится делать откаты назад или пытаться рассматривать набор данных по какому-либо другому альтернативному направлению анализа, то есть делать ветвления (fork - форки). Для возможности отслеживания всех таких изменений, а также отката на любой момент фиксации изменений разработаны специальные системы управления версионностью. Такие системы в течение всего процесса работы с данными позволяют фиксировать любое изменение, сопровождая его комментариями, храня дату и автора изменений, а при необходимости предоставляют возможность вернуться к состоянию данных (восстановить содержимое всех файлов и папок) на заданный момент времени.
Если над данными работает несколько человек, то может возникнуть еще одна сложность - разные люди могут пытаться вносить противоречивые изменения в одно и то же место, такие ситуации называются конфликтами. Системы управления версиями программ должны предлагать эффективные методы борьбы с конфликтами.
Важным понятием при использовании систем управления версиями программ является понятие репозитория. Репозиторий можно воспринимать как обычный каталог с файлами и другими каталогами. Однако в репозитории содержится еще и мета-информация, связанная с хранением хронологии всех изменений. Такую мета-информацию можно воспринимать как некоторую базу данных внутри репозитория (обычно это специальный скрытый каталог, например, в системе git этот каталог имеет имя .git).
Принято различать два подхода к построению систем управления версиями: централизованные системы, распределенные системы. Централизованные системы предполагают использование одного центрального репозитория и все участики должны перед началом работы получить из него свежие данные, а по окончании работы записать изменения в центральный репозиторий.
Распределенные системы не требуют изначального выбора главного - центрального репозитория. Фактически репозитории всех участников равноправны и независимы, но при необходимости могут быть синхронизированы друг с другом. В настоящее время все большее признание получают именно распределенные системы, ярким представителем которых является система git, разработанная изначально Линусом Торвальдсом в 2005 году для сопровождения процесса создания ядра операционной системы Linux.
Рассмотрим основной функционал системы git.
Начнем с установки системы git. Здесь следует обратиться к официальному сайту \url{https://git-scm.com/}. В операционных системах семейства GNU/Linux (дистрибутивы Debian, Ubuntu) для установки можно использовать команду:
>sudo apt-get install git
Работа с системой git начинается с создания репозитория. Для этого перейдя в выбранный каталог, для которого необходимо создать репозиторий, следует выполнить команду:
>git init
После выполнения этой команды в текущей директории будет создан специальный скрытый каталог .git, который и будет обслуживать хронологию изменений текущего каталога.
Для контроля состояния репозитория используется команда:
> git status
Если в каталоге нет никаких изменений, система git сообщит об этом, или наоборот укажет, что относительно хранимой системой git истории, произошли изменения.
Пока добавленные файлы система никак не отслеживает, мы не дали для этого ей никаких распоряжений. Чтобы добавить файлы к отслеживанию нужно выполнить команду git add с перечислением имен всех файлов, которые необходимо отслеживать. Если требуется добавить все новые файлы, можно выполнить команду git add .
Теперь система приняла файлы к учету, однако просит создать коммит.
Коммит - это важный термин системы git. По сути это обычный комментарий, однако у системы git, к ним особое отношение - они являются обязательным атрибутом окончательной фиксации изменений в системе git. Коммит можно понимать как подтверждающее транзакционное действие. После внесения коммита откатить изменения будет невозможно. Да, конечно, можно опять удалить добавленные файлы и закоммитить это изменение, но в хронологии системы эти файлы все равно останутся, и при необходимости их обратно можно получить, перейдя на нужный коммит. Для внесения коммита требуется выполнить команду git commit -m name.
Еще одним важным действием в системе git является операция клонирования git clone. Чтобы выполнить клонирование локальной директории /a в локальную директорию /b достаточно выполнить команду git clone /a /b.
Как видно из рисунка, содержимое каталога a полностью склонировано в каталог /b, кроме того, там также появился скрытый каталог .git.
С этого момента каталоги /a и /b начинают самостоятельную жизнь - в них могут добавляться новые файлы, или удаляться уже существующие и т.д., но при необходимости эти каталоги можно синхронизировать.
Репозиторий можно откатить до любого состояния, зафиксированного коммитом. Чтобы посмотреть все коммиты можно использовать команду git log.
Чтобы откатить состояние каталога до какого-нибудь коммита нужно использовать команду git chechout хеш коммита.
Дальнейшие действия зависят от целей отката. Если целью было просто посмотреть содержимое каталога, то можно вернуться на последний коммит все той же командой git chechout хеш коммита, или можно просто указать главную ветку git check out master.
Другая альтернатива может заключаться в том, что потребовалось сделать новую ветвь, в которой содержимое каталога будет следовать своей хронологии. Это можно сделать командой git checkout -b имя-новой-ветки хеш-коммита текущей ветки.
Посмотреть список веток можно командой git branch - -list.
Использование всех возможностей системы git реализовано в различных хостингах. Одним из таких наиболее популярных хостингов является github.com.
Многие аналитики выкладывают результаты своего анализа на github.com:
https://github.com/andriygav/MachineLearningSeminars
https://github.com/ranalytics/data-mining
Рассмотрим использование github.com для хостинга данных. Для начала работы с github.com очевидно требуется пройти этап регистрации и создания собственного профиля. После этого в авторизованном режиме пользователю среди прочих действий предоставляется возможность создать свой приватный или публичный репозиторий.
Для локальной работы с репозиторием его необходимо клонировать. Клонировать репозиторий с github можно по нескольким протоколам, наиболее популярные из которых: https, ssh. Для работы по протоколу https необходимо сгенерить и получить токен доступа в разделе настроек своего прифиля на сайте github. Для работы по протоколу ssh необходимо на локальном компьютере установить систему ssh, далее по выбранному ассимметричному криптографическому протоколу (rsa, dsa и др.) сгенерировать публичный и секретный ключи, публичный ключ загрузить на сайт github, а для секретного ключа настроить его использование системой ssh. Здесь мы рассмотрим только использование протокола https.
Для получения токена необходимо перейти в раздел https:// github.com/settings/tokens
Данный токен нужно сохранить, например, в простом текстовом формате. После получения токена можно перейти к клонированию репозитория по протоколу https (заметим, что публичные репозитории можно клонировать и без токена, однако пушить изменения обратно на github без токена не получится).
Для клонирования репозитория необходимо получить ссылку на репозиторий по соответствующему протоколу.
После получения ссылки в терминале своего локального компьютера выполняем команду:
git clone ссылка
Система git очень гибкая и разветвленная, она содержит огромное количество различных команд. Фактически мы рассмотрели лишь базовые возможности. Все подробности можно узнать из литературы, специально посвященной этому вопросу: