Ситуация
К нам обратился один из наших ключевых заказчиков с предложением принять участие в большом проекте по миграции корпоративных данных на другое хранилище. Нашей задачей стал перенос пользовательских объектов.
У компании-заказчика большое количество аналитических команд. Эти специалисты участвуют в решении различных бизнес-задач, в том числе, конечно, с использованием корпоративного хранилища данных.
В процессе своей работы аналитики создают различные объекты с данными — таблицы, представления над данными, витрины данных. Такие пользовательские объекты могут быть временными, когда команде нужно было, например, проверить какую-то гипотезу, или провести ad-hoc аналитику по запросу. Одновременно с этим команды аналитиков реализуют на постоянной основе процесс сложной аналитики, когда на выходе образуется витрина, использующаяся для построения регулярной нерегламентированной отчётности. Эти витрины могут хранить исторические данные глубиной в несколько лет, в них на регулярной основе инкрементально добавляется новая порция данных за очередной отчётный период.
Цели и бизнес-задачи
Наша задача была мигрировать такие объекты на новое хранилище данных, при этом сохранив рабочие процессы команд-аналитиков на текущем уровне, чтобы для пользователей это выглядело практически бесшовно. Пользовательские объекты у нашего заказчика хранятся в песочницах (sandbox).
Кроме объектов данных как таковых, команды аналитиков сами пишут скрипты для того, чтобы в автоматическом режиме обновлять и обогащать свои объекты, так что задача переноса, фактически, состояла не только из миграции данных на новое хранилище, но и из миграции кода из старого хранилища в новое.
В нашем проекте у компании-заказчика не было механизма автоматической очистки песочниц — например, не происходило удаление объектов старше определённого возраста. В том числе и за счёт этого, число пользовательских объектов в песочницах было очень разным — от нескольких сотен до нескольких тысяч объектов.
Решение
На этапе анализа основной задачей было определить перечень песочниц, которые будут подлежать переносу. Мы провели аудит всех песочниц в хранилище данных компании-заказчика, выявили среди них неактуальные, которые не было необходимости переносить в новое хранилище.
Далее, нужно было определить владельцев (и пользователей) песочниц, чтобы на новом хранилище воспроизвести структуру песочниц старого хранилища, согласовав наименование песочниц с архитекторами компании.
После формирования реестра песочниц необходимо сделать выгрузку мета-данных из дата-словаря текущего хранилища для того, чтобы собрать информацию обо всех объектах внутри этих песочниц.
Определили, какие данные мы хотим видеть в этой выгрузке — имя объекта, тип объекта, кто и когда его создал, когда было последнее обращение к объекту, дата последнего изменения объекта, список пользователей, обращавшихся к объекту. Для материализованных объектов выгрузили также количество количество строк и размер занимаемый объектом на диске.
После того, как такая выгрузка будет готова, можно организовывать работу с пользователями, чтобы выявить
- актуальность владельцев
- актуальность объектов (возможно, что-то можно удалить и не тратить ресурсы на перенос)
- актуальность глубины хранения объектов
- приоритет переноса объектов
- пользовательские процессы, построенные на использовании объектов внутри песочниц (сбор скриптов)
На этом этапе можно выявить команды, у которых в пользовательских песочницах реализованы сложные процессы на основе самостоятельно написанных скриптов и которым может потребоваться помощь в организации работы после миграции на новое хранилище.
С точки зрения работы с пользователями мы выбрали подход «мягкой силы». Данные переносятся поэтапно, старое хранилище продолжает работать в течение переходного периода. Новые объекты уже создаются только на новом хранилище, при этом определена целевая дата, до которой необходимо полностью завершить перенос.
Совместно с пользователями можно выработать перечень приоритетных для переноса объектов, на которых основаны основные бизнес-процессы.
При переносе объектов, которые содержат в себе данные большой исторической глубины, мы выработали следующий сценарий: сначала переносим данные за архивные периоды. После этого пользователи могут протестировать функционал нового хранилища на привычных им данных. Более свежие данные переносим в последнюю очередь по согласованию с пользователями, на этом этапе удобно переключить их бизнес-процессы на новое хранилище.
Саму задачу по автоматизации переноса данных мы разбили на подготовительную часть и написание скрипта.
- Совместно с архитекторами компании определить, какие опции нового хранилища будут активно применяться (колоночная модель хранения, разные варианты сжатия, ключи распределения и т.д.).
- Составить маппинг типов данных между старым и новым хранилищами.
- Определить правила именования объектов после миграции.
- Выяснить, как новое хранилище работает с кириллическими символами в названиях объектов.
- Определить, какие варианты есть в новом хранилище по предоставлению доступа к данным. Возможно, в новом хранилище ролевая модель доступа отличается и это нужно учесть при написании кода, создающего объекты в новом хранилище.
После того, как подготовительный этап завершён, можно начинать разработку скрипта по автоматическому переносу данных, переносить пользовательские песочницы и переключать пользователей на работу с новым хранилищем данных.
Выводы и рекомендации
В процессе работы над проектом столкнулись с рядом проблем, которых можно было бы избежать. Хочется поделиться этими моментами, чтобы вы смогли их заранее учесть.
При проведении анализа мы ограничились семплом мета-данных старого хранилища, из-за чего на этапе переноса столкнулись с тем, что не все типы данных были включены в маппинги типов старого и нового хранилищ.
Так что наша рекомендация здесь — сделать полную выгрузку мета-данных объектов внутри песочниц, чтобы для каждого типа данных определить маппинг.
Возникли проблемы с линейным переносом объёмных (50Гб+) таблиц (не хватает ресурсов системы и/или сегмента памяти для переноса, перенос занимает длительное время без возможности продолжить с момента сбоя, если он произошёл).
Наша рекомендация — переносить такие объекты не линейно, а разбивать их на партиции.
Что может помочь в переключении пользователей на новое хранилище — это проведение индивидуальных сессий с командами аналитики, своего рода «бебиситтинг». От команды миграции выделяется ответственный сотрудник, который назначается на фиксированный срок для помощи команде аналитиков. Этот сотрудник проводит встречи для обучения подходам работы с новым хранилищем, отвечает на вопросы, помогает адаптировать пользовательские скрипты для нового хранилища, проводит ревью кода аналитиков и т.д.
По завершению работы с одной командой аналитиков может начинаться работа со следующей и т.д. Важно обозначить срок, чтобы в целом понимать прогноз завершения процесса, когда все команды аналитиков будут подготовлены к работе с новым хранилищем.
Если резюмировать, то задача миграции пользовательских объектов поддаётся формализации и разделению на этапы, и заодно хорошо совмещается с наведением порядка в хранилище и избавлении от неиспользуемых данных.