Миграция витрин из пропиетарных DWH на новый стек
Что учесть при миграции витрины из Oracle, Teradata, "X" на Greenplum Делюсь опытом с крупного проекта в топ-3 банке РФ. Здесь и далее подразумевается работа команды, как минимум: из 1 разработчика, который шарит за технические особенности GP, и 1 аналитика, который понимает бизнес.
1. Определи требования к финальному варианту — миграция будет 1в1 или с изменением схемы данных (типов или названий полей, бизнес-логики расчёта, количества колонок и их распределение между таблицами и вьюхами). Если второе — договорись заранее о приёмке и сверке — пусть заказчики напишут скрипты с данными вход-выход и дадут тебе для отладки. Отдельно обсуди глубину прогрузки исторических данных, время и расписание обновления витрины, глубину забора обновляемых данных для инкремента, историчность SCD2, нужно ли переносить в архив данные старше "Х" мес. и пр. детали
2. Проанализируй поля, по которым производятся JOIN и GROUP BY, определи требования по распределению (distribution) для объектов на уровне твоя витрина "минус 1", то есть таблиц и вьюх в FROM и JOIN твоей витрины (далее - upstream зависимости). Справочники по возможности выноси на каждую ноду через distributed replicated
3. Оцени текущий статус готовности upstream зависимостей. Есть ли все нужные поля? Они тех же типов, которые были на предыдущей системе? А данные там есть? А они качественные? Выстрой коммуникацию и будь в курсе всех изменений. От этого сильно зависит срок. Если есть down-stream зависимости, согласуй срок и с ними. Если это Greenplum 6.х и источники решили реализовать через функции -- увольняйся попробуй переубедить их перенести на view, materialized view или таблицы. Greenplum 6.x не поддерживает predicate pushdown в функциях, т.е. сначала обработаются данные на полном объёме, а только потом результат будет отфильтрован.
4. Используй онлайн-инструменты и шпаргалки для миграции DML логики. Определи особенности физического размещения и будущих юз-кейсов самой витрины -- по какому полю распределять и партицировать. Нужно ли материализовать часть шагов витрины, и если да, то как распределить данные в них. Реализуй нюансы загрузки из шага 1.
5. Если шагов CTE или подзапросов много, проверяй count и not null по нужным полям после каждого джоина. Если не угадать с кардинальностью связи или с ключами соединения, можно наплодить дублей или потерять какие-то данные. На финальном шаге посчитай основные агрегаты и проведи "проверку здравого смысла" (sanity check), что данные хотя бы немного похожи на реальные. Ну и, конечно, при разработке тестируй на десятке вручную отобранных репрезентативных строчек, а не на годовом датасете.
6. Проверь идемпотентность записи данных, правильность расчёта инкрементов, разумный рост времени расчёта при увеличении количества входных данных. Ну и что дашборды к витрине подключаются без ошибок и выглядят правильными. Отдавай бизнесу и требуй принять витрину, если получилось реализовать все требования из пункта 1. Если не получилось -- заранее обозначь причину с ожидаемым сроком исправления и зафиксируй ответственного, у которого можно выяснить детали. Что забыл, что не учёл?
