Arenadata - Миграция на отечественные решения хранения и обработки данных
Данный раздел создавался как пособие для компаний, планирующих миграцию с инженерных систем, то есть с преднастроенной совокупности оборудования и СУБД. Однако он в полной мере покрывает и задачи, которые будут стоять при миграции обычных, не инженерных СУБД. При любой миграции следует помнить, что оборудование, необходимое для работы разных СУБД – тоже разное, не всегда удаётся переиспользовать имеющиеся мощности, и не всегда можно обойтись без дозакупки оборудования. Эта мысль зачастую не находится в фокусе внимания в проектах срочной миграции, и за невнимание к этой детали можно заплатить немалую цену, как деньгами, так и временем. В связи с этим крайне важно не игнорировать аппаратный фактор, затронутый в данном материале.
- Каким образом достигается продолжение функционирования прикладных разработок, созданных в рамках эксплуатации инженерных систем, таких как Teradata, Exadata, Netezza на ПО Arenadata.
- Какова структура трудозатрат миграции данных и процессов, варианты структуры проекта миграции. Рассмотрим два ключевых варианта со своими плюсами и минусами.
- Особенности ресурсного плана под трудозатраты миграции и компетенцию вовлекаемых специалистов и команд.
- Порядок подбора commodity-оборудования, покрывающего производительность действующей инженерной системы.
Сохранение прикладных разработок
Прикладные разработки, специфичные для используемой инженерной системы, необходимо локализовать и изменить так, чтобы их можно было использовать после миграции.
Обычно их можно найти в следующих системах и конструкциях (с удельным весом в % строк):
Изменение кода, необходимое для функционирования разработок, делится на 3 части:
- Изменение метаданных, то есть служебных сведений, описывающих как хранятся данные и объекты, на них влияющие.
Это самая простая часть, так как подавляющая часть кода метаданных может быть сконвертирована автоматически. В ряде случаев всё же необходимо участие разработчиков, конвертирующих уникальные конструкции СУБД инженерной системы в аналогичные конструкции, используемые в замещающей СУБД.
- Изменение скриптового кода запросов и представлений, в том числе содержащихся в хранимых процедурах.
Это код, описывающий алгоритмы преобразования данных перед их конечным представлением в слое витрин или в конкретных отчётах, сервисах или приложениях. Большая часть трудозатрат миграции заключена именно здесь, несмотря на то, что от 90% до 98% такого кода будет работать на замещающей системе вообще без каких-либо изменений. Оставшиеся же 2-10% кода будут требовать от команды миграции понимания логики алгоритмов запросов и знания различий синтаксиса СУБД.
- Изменение функционального кода процедур, пакетов, функций и триггеров.
Когда мы говорим о любом диалекте SQL, мы на самом деле говорим про два языка, работающих вместе: скриптовый и функциональный. Циклы, объявления переменных, динамический SQL и т.п. – всё это также необходимо переписать в процессе миграции.
Общая картина процесса миграции кода с разделением по ролям участников миграции выглядит следующим образом:
Структура трудозатрат миграции
Основная часть трудозатрат миграции – это перенос кода.
Структуру переноса мы концептуализировали ранее. В этом же разделе мы выделим конкретные задачи в рамках и за рамками переноса, и предложим индикативы по весам этих задач.
80% Перенос кода
Состав работ в обоих сценариях миграции примерно одинаков. Однако, в случае схемы Offload, добавляется работа по созданию внутренних и внешних федераций данных.
Offload
✓ Доступность данных как из старой системы, так и из новой (замещающей);
✓ Плавный переход вместо «переключения рубильником» со старой на новую системы;
✓ Минимизируется риск плохой адаптации пользователей.
X Разовые затраты выше, чем при миграции;
X Возможно лишь для систем, допускающих федеративный доступ к данным;
X Часть проведённых работ окажется бесполезной после завершения миграции.
Миграция
✓ Производятся только необходимые работы, поэтому проект – короче, а разовые затраты – меньше.
✓ Возможна для любых замещаемых систем;
✓ Проект становится прозрачней за счёт отсутствия полумер.
X Есть риск плохой адаптации пользователей (последствия: текучка, плохое качество кода);
X Риск технического простоя при переключении на новую систему.
|
Задача (путь Миграции) |
Роли |
% трудоёмкости |
1 |
Сбор кода с источников (СУБД, ETL-процессы, код приложений) |
аналитик, разработчик |
2% |
2 |
Развёртывание замещающего комплекса технических средств |
инженер |
0% |
3 |
Создание DDL таблиц в замещающей СУБД по собранным метаданным |
разработчик |
5% |
4 |
Переписывание SQL-скриптов на диалект SQL целевой СУБД |
аналитик, разработчик |
41% |
5 |
Переписывание объектов с функциональным кодом на диалект целевой СУБД и внедрение в целевую СУБД |
разработчик |
25% |
6 |
Первоначальная миграция данныx |
архитектор, разработчик |
2% |
7 |
Перенастройка ETL/ELT-процессов (обновление ссылок на процедуры СУБД, замена исполняемого кода на ссылки на процедуры/представления СУБД). Вывод в регламент. |
разработчик |
13% |
8 |
Замена кода, встроенного в приложения, на ссылки на процедуры/представления СУБД или обновление таких ссылок. |
прикладной разработчик |
2% |
9 |
Приёмо-сдаточные испытания |
все роли |
10% |
Ресурсный план миграции
(без пакетных услуг вендора)
Длительность |
Этап |
2 месяца |
Формальные процедуры и организация работ |
3 месяца |
Сбор кода и обследование |
1 месяц |
Миграция данных |
4-8 месяцев |
Миграция процессов и процедур |
1 месяц |
Испытания и ОПЭ |
Ресурсы (FTE)
- 0.4-1 FTE руководителя проекта;
- 0.3 FTE архитектора на весь проект и 0.5-1 FTE на старте;
- 0.1 FTE инженера + 10 ч.д. на старте;
- По 0.5 FTE специалистов заказчика от всех бизнесов-потребителей на этапах анализа и приёмки;
- Технические специалисты заказчика: по необходимости, от 1 до 3 FTE на 5-10 вовлечённых сотрудников.
- Аналитики со знанием SQL и разработчики: ресурс исходя из оценки трудозатрат согласно метрикам оценки.
- Тимлиды групп разработки и аналитики: 20% от ресурса аналитиков и разработчиков
Профиль ресурсного плана миграции инженерных решений совпадает с типичным профилем DWH/BDW-проекта, с соответствующим вовлечением бизнесов и консультанта-интегратора.
Порядок подбора оборудования
Раньше жили в такой парадигме. Если удастся остаться в ней – это идеально.
Новые вводные новых реалий
- Клиенты будут практиковать panic buy в cloud-провайдерах и у поставщиков ПАКов, так как верят, что у последних всё хорошо с железом. В действительности у cloud-провайдеров те же проблемы с оборудованием, что и у всех, но они ещё и усугублены необходимостью оперировать стандартизированным оборудованием.
- Не-cloud-native решения для работы с большими данными (практически все основанные на opensource продукты) в публичных облаках работают плохо из-за нецелевой физической архитектуры облаков, которая рассчитана на большое количество небольших клиентов. Эффективно работать такие решения будут только в некоторых частных облаках, количество оборудования под которые сильно ограничено, и это оборудование не commodity. Уводить клиентов в облака сейчас – ошибка, даже в краткосрочной перспективе.
- Аналитические системы, как и прочие business-operational-системы, уходят на второй план, так как клиентам в моменте важнее всего выстроить долгосрочную стратегию непрерывности бизнеса. Однако, не все клиенты ранее думали над тем, что нужно разделять аналитический и транзакционный контуры. Сейчас выгодно отделять аналитический контур от business-critical систем, отдавая под него более медленное оборудование и жертвуя SLA и TTM некритичных сервисов в пользу устойчивости критичных.
- Доля софта, услуг и работ в общей стоимости решения становится существенно меньше. Если вы смогли достать оборудование, то вам простят многие наценки.
Возможные меры
(если нового железа нет и не предвидится)
- Сжать всё, что возможно, максимально эффективным из доступных алгоритмов сжатия. На сжатие расходуется ресурс CPU, так что процессы, завязанные на сжатые данные, замедлятся, однако так получится создать запас для роста или высвободить часть оборудования. Как и прежде, следует находить баланс между расходом CPUи силой сжатия, но точка баланса теперь сильно смещена в сторону повышения компрессии.
- Провести проверки соответствия политик резервирования и катастрофоустойчивости требованиям бизнеса в новое время. Если требования снизились, то часть мощностей хранения под оперативные бэкапы (не на лентах) можно высвободить.
- Рассмотреть возможность объединения ранее разделённых контуров/сред (разработка, тестирование, UAT, preprod). Решение, принятое в сытые годы, может поменяться.
- Освободившееся оборудование использовать под СУБД, обладающие следующими свойствами:
- Колоночное хранение – сильно уменьшает объём места, занимаемого данными;
- Эффективное сжатие данных (например, z_std);
- Возможность федерализации запросов – как входящих, так и исходящих.
При этом нельзя забывать про стандартные enterprise-требования: наличие инструментов резервного копирования, наличие визуальных средств администратора (мониторинг, расширение, сопровождение), коннекторов к другим СУБД и, конечно, поддержки с SLA и готовности вендора исправлять код ПО в соответствии с заведёнными тикетами заказчика по багам.
Риски переиспользования оборудования
Если у клиента есть инженерная система или иное оборудование, адаптированное под конкретный софт, и из-за тех или иных причин софтом пользоваться более возможности нет, то у клиента неизбежно возникнет большой соблазн его переиспользовать. Что в этом случае учитывать:
- Проверить, будут ли работоспособны сервера в случае зачистки и установки другого ПО. Нужно исключить риск неработоспособности физических компонент при смене софтверных. Например, если ранее использованный софт содержит в себе драйверы, без которых оборудование бесполезно, и получить эти драйверы иным путём нельзя.
- Если оборудование всё же неработоспособно в комплексе, то можно проверить, переиспользуемы ли отдельные его компоненты: CPU, RAM, диски, RAID-контроллеры, сетевые карты.
- Вопрос пере-используемости оборудования нужно поднимать в контексте архитектуры нового ПО, под которое будут использованы компоненты. У разного ПО разные узкие места и разные аппаратные потребности.
Если достать оборудование – не проблема
- Жить в старой парадигме и давать сайзинги, заточенные на максимальную производительность, уже никто не может себе позволить. Если вы сможете достать для клиента новое оборудование, то почти наверняка кратно дороже, чем раньше. В такой ситуации нужно оптимизировать стоимость терабайта хранения.
- Всегда рассматривайте опцию температурного хранения данных. В текущих реалиях может оказаться выгоднее выделять холодные зоны в основных кластерах Arenadata DB или Arenadata Quick Marts, а не выносить эти данные в Arenadata Hadoop, так как ADB и ADQM дают более эффективное сжатие при колоночном хранении. Экономия на лицензиях из-за использования более дешёвого ПО теперь несущественна по сравнению с экономией на оборудовании из-за сжатия и колоночного хранения.
- Предлагайте варианты с бОльшим объёмом дисков или общей ёмкости на тот же объём CPU и RAM.
- Могут возникнуть ситуации, в которых клиент не может использовать ничего кроме имеющихся мощностей, и эти мощности никак не бьются с лучшими практиками подбора оборудования. Раньше в таких случаях клиенту отказывали. Сейчас для клиента это может быть вопросом выживания и нужно не отказываться, а сконцентрироваться на damage control от нецелевой конфигурации. В чём следует убедиться:
- Правдами и неправдами обеспечить равномерную нагрузку на узлы распределённых систем.
- Всеми силами избегать использования общих с другими системами коммутаторов, сетевых каналов или находить какие-то варианты лимитирования нагрузки на ваше оборудование от сторонних систем.
- Клиент должен понимать, что нецелевая конфигурация – всё равно риск, и вендор на себя этот риск взять не сможет. Arenadata будет проактивно идти навстречу в спорных ситуациях.
Матрица соответствия программных продуктов
Мигрируемый продукт |
Тип нагрузки / задача |
Куда мигрируем |
Oracle DB, MS SQL, SAP Sybase ASE, MS Access, IBM DB/2 |
OLTP |
Arenadata Postgres |
Oracle (< 1000 TPS) |
OLAP / RAC / Exadata (DWH) |
Arenadata DB |
Oracle, MS SQL, Teradata |
Витрины данных |
Arenadata Quick Marts |
Teradata, Netezza, Vertica, Exasol, Impala, Presto, Tanzu/Pivotal Greenplum, SAP Sybase IQ |
DWH, Реляционная MPP СУБД |
Arenadata DB |
MongoDB, Cassandra, DynamoDB |
Хранение документов, JSON |
Arenadata Hadoop: Hbase |
Redis, Hazelcast |
In-memory Key-Value |
Picodata Grid |
Elasticsearch |
Поиск, анализ логов |
Arenadata Log Search |
Snowflake, RedShift |
Реляционная облачная MPP, DWH |
Arenadata DB |
Azure SQL, Google Big Query |
Реляционная облачная СУБД |
Arenadata DB, Arenadata Hadoop |
SAP HANA |
In-memory RDBMS |
Arenadata Quick Marts + Arenadata DB |
Продукты Cloudera / Hortonworks |
Экосистема Hadoop |
Arenadata Hadoop |
Confluent Kafka |
Pub/Sub брокер сообщений |
Arenadata Streaming: Kafka |
IBM Streams, SAS Event Streams Processing, Azure Stream Analytics, TIBCO Streaming, Cloudera DataFlow |
Потоковая аналитика |
Arenadata Streaming: Kafka (KSQL) |
Amazon Timestream, HCL Informix, InfluxDB Enterprise, Kdb+ |
СУБД для анализа временных рядов |
Arenadata QuickMarts или TimescaleDB |
Подробнее можно ознакомиться здесь:
Скачать Миграция на отечественные решения хранения и обработки данных