Для тех, кто задумывается о миграции хранилища данных

Недавно прошла PGConf.Russia 2025. Конференция была насыщенной, особенно по части «миграций». Много внимания уделено технологическим вопросам – минимизации downtime, учёту специфики платформ. Говорили об абстрактной миграции баз данных, миграции учётных систем, но если у вас именно хранилище данных, а не транзакционная база, то нужно действовать более рационально!

Может показаться, что проблема – только в понимании специфики исходной и целевой СУБД. Миграция базы данных с одной СУБД на другую разбивается на 2 задачи – миграция данных и миграция логики, написанной в коде. Типичный, но максимально трудоемкий подход: взять существующие таблицы, представления, код и попытаться «скопировать» их в новую систему со всеми её технологическими особенностями. Большинство обсуждаемых подходов и инструментов решают частные задачи: проблемы с типами данных, хранимыми процедурами, длинными именами, спецификой обработки транзакций.

Но корпоративное хранилище данных (DWH) – это не просто набор объектов. На более высоком уровне это процесс сбора, обработки и предоставления данных.

Конвертация базы данных не включает:

ELT – требуется адаптировать под конкретную СУБД
реализацию методологии разработки DWH – построение модели нужно переписывать с учётом диалекта SQL, автоматизировать создание объектов DWH, служебной логики
реализацию CI/CD – нужны автоматизированные процессы фиксации изменений и перенос их на среды dev-test-prod

Миграция хранилища «в лоб» – это почти всегда:

Потеря производительности, например «трансляция в лоб» T-SQL или PL-SQL в PL/pgSQL может замедлиться на порядок из-за другой реализации многопоточных операций в PostgreSQL (много медленных межпроцессных обменов данными)
Перенос legacy на новую платформу без улучшений. Это низкоуровневая работа со специфическим служебным кодом, который требует высокой экспертизы и большой трудоемкости.

Ограничения и накопленный хаос переезжают на новую платформу, меняется только обёртка. Структура и проблемы остаются прежними.

Считаем, что в проектах миграции хранилищ данных нужно применять инструменты автоматизации разработки DWH. Одним из таких инструментов является фреймворк BI.Qube.

Наш подход: автоматическая миграция данных и перенос логики с участием экспертов

Не нужно вручную переносить сотни объектов. Вы описываете процессы, настраиваете модель – всё остальное выполняется автоматически. Именно этот подход позволяет за считаные недели получить работающее хранилище без того, чтобы повторять старые ошибки.

Этап 0. Сканирование метаданных и перенос пайплайнов ELT. Если в мигрируемом DWH есть слой метаданных с описанием ELT, то автоматически переносятся 98% этой логики. Инструмент генерирует пайплайны на базе эвристических правил, учитывающих объем данных, секционирование, ключи и индексы. Для остальных 2% придется внести ручные корректировки, как правило связанные со спецификой данных.

Этап 1. Сканирование источников данных и создание пайплайнов ELT. Если в мигрируемом DWH нет слоя метаданных с описанием ELT, то мы конфигурируем в BI.Qube MetaStaging перенос данных с указанием типа загрузки, глубины и секционирования. Трудоемкость работ снижается в 15-60 раз, заменяя 15-120 минут кодирования на 1-5 минут конфигурирования каждого отдельного пайплайна. При этом, например, при замене библиотеки Pandas на фреймворк BI.Qube в 2 раза повышается производительность выполнения и снижается в 10 раз потребление памяти за счет более оптимального автоматически генерируемого кода.

Этап 2. Загрузка и сверка. Извлечение данных в автоматическом режиме на основе настроек из предыдущих этапов в BI.Qube MetaStaging. Сверка производится в полуавтоматическом режиме – автоматическое выявление расхождений в BI.Qube MetaControl и ручное исправление.

Этап 3. Генерация модели хранилища. Конфигурируем при помощи BI.Qube MetaVault и MetaFact перекладку сырых данных, полученных на этапе загрузки и сверки, в модель хранилища с определением бизнес-ключей, связей между данными и фиксацией истории изменений.На интерфейсном слое хранилища новой платформы на основании описанной модели, с учетом материализаций и перекладок, генерируются справочники и факты.

Этап 4. Перенос бизнес-логики. Трансформации, описанные в семантике SQL, переносятся с одного диалекта на другой с учетом построенной модели. Код упрощается, так как сгенерированная модель покрывает всё множество необходимых представлений данных (историчных, актуальных на произвольный и текущий момент времени, историю удаленных записей). Остается вручную перенести код логики трансформации или воспользоваться сторонними инструментами. Но полностью автоматических инструментов конвертации кода на сегодняшний день не существует.

Этап 5. Сверка хранилища. Опциональный, но крайне рекомендуемый этап, позволяющий убедиться, что миграция хранилища произведена корректно. Применяя MetaStaging и MetaControl, данные исходного хранилища (сырые или агрегаты) сверяются с данными мигрированного хранилища. Расхождения обрабатываются вручную. В результате получаем хранилище, на интерфейсном слое идентичное исходному. Все ранее написанные отчеты, созданные дашборды, интеграции внешних систем с предыдущим хранилищем, перенацеливаются на новое и продолжают работать без изменений.

Рисунок 1: Эффекты при загрузке источников в DWH (Этап 1)

Дополнительным эффектом такого подхода является появление:

CI/CD, формируемый на уровне модели. При этом фиксация изменений производится на уровне модели хранилища, в отличие от CI/CD, реализуемого на уровне объектов базы данных (таблиц/представлений). 3 строки конфигурации, которые фиксируют изменения в git, разворачиваются в тысячи строк SQL-кода на низком уровне.
Data Lineage. BI.Qube автоматически отслеживает и представляет все зависимости.

Результаты

Быстро. MVP можно собрать за считаные недели
Управляемо. Вместо старого набора таблиц – нормальная архитектура
Дёшево в сопровождении. Все имена, структуры и пайплайны прозрачны и стандартизированы
Структурировано. Хаос и «мусор» остаются в прошлом

Если вы хотите мигрировать DWH из Microsoft, Oracle или SAP BW на Postgres Pro или PostgreSQL, – воспользуйтесь экспертизой и фреймворком команды BI.Qube. Сделаем MVP на ваших данных за несколько недель, а за 3–4 месяца перенесем самую востребованную часть хранилища. Пишите – покажем на кейсе, как это работает.