#вести_с_полей Что учесть при миграции витрины из 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. Если не получилось -- заранее обозначь причину с ожидаемым сроком исправления и зафиксируй ответственного, у которого можно выяснить детали. Что забыл, что не учёл?