Уход Oracle, Teradata и Microsoft с российского рынка превратил замену хранилища данных из плановой задачи в обязательную. Заказчики из госсектора и крупного бизнеса переносят DWH на Greenplum, PostgreSQL, Arenadata DB и ClickHouse. Главный риск здесь – не сломать загрузки, а потерять историю: накопленные за десять-пятнадцать лет факты, медленно меняющиеся измерения и логику расчётов, на которую опирается управленческая и регламентная отчётность. Ниже – как проводить такую миграцию, чтобы цифры до и после совпали.

Сначала инвентаризация, потом перенос

Перед тем как трогать данные, опишите хранилище целиком: источники, слои (staging, ODS, детальный слой, витрины), ETL-потоки, расчётные правила и потребителей отчётов. На большинстве зрелых DWH накопились мёртвые таблицы, дубли витрин и логика, которую никто уже не помнит. Переносить это вслепую – значит тащить технический долг на новую платформу и платить за него хранением и поддержкой.

Отдельно зафиксируйте, как устроены исторические измерения. SCD Type 2 с интервалами действия, суррогатные ключи, флаги актуальности – всё это нужно перенести без сдвига границ периодов. Одна ошибка в датах valid_from/valid_to развалит историческую отчётность, и обнаружится это спустя месяцы, когда бизнес сверит годовой отчёт.

Перенос данных и расчётной логики

Историю грузите слоями, от детального уровня к витринам, и сверяйте каждый шаг. Несовпадение типов – частый источник тихих потерь: NUMBER Oracle без явного масштаба, разное поведение NULL в сортировках и агрегатах, форматы дат и таймзоны. Проверьте, как новая СУБД обрабатывает строки в разных кодировках и пустые значения в ключах соединения.

Расчётную логику не копируйте дословно. Хранимые процедуры на PL/SQL или T-SQL переписываются под PL/pgSQL или встроенные функции Greenplum с проверкой на каждом этапе. Если в проекте есть собственная разработка трансформаций или сервисов поверх хранилища, ведите её по тем же правилам безопасной разработки, что и остальной заказной софт для госзаказа – мы разбирали это в материале про SSDLC в госзаказе. Хранилище данных – такой же актив, как прикладные системы, и доступ к нему требует контроля.

Сверка: пока цифры не сойдутся, миграция не закончена

Параллельный прогон – единственный честный способ доказать корректность. Запускайте старое и новое хранилище одновременно на одних источниках и сверяйте витрины: контрольные суммы строк, агрегаты по ключевым метрикам, помесячные срезы за несколько лет. Расхождения разбирайте до нуля, а не списывайте на «погрешность округления».

Закладывайте на параллельную работу один-два закрытых отчётных периода. Только когда бизнес-пользователи подтвердят, что цифры в их отчётах совпали, старую систему можно выводить из эксплуатации.

Когда хранилище переехало, появляется задел и для следующего шага – аналитики поверх данных. На перенесённой истории можно собирать витрины и BI-отчётность, а описанные регламенты и метаданные пригодятся, если вы строите базу знаний на RAG для внутренних запросов к данным.

Вывод

Импортозамещение DWH – это не «перелить таблицы», а перенос истории, логики и доверия к отчётности. Инвентаризация, послойная загрузка с контролем типов, аккуратная переработка расчётов и параллельная сверка до полного совпадения цифр – четыре опоры, без которых миграция превращается в потерю того, что собирали годами.