Уход Oracle, Microsoft и Teradata из России поставил перед компаниями и ведомствами конкретную задачу: чем заменить аналитическое хранилище, на котором держится отчётность, бюджетирование и регуляторная выгрузка. Поддержка прекращена, обновления безопасности недоступны, а требования к импортозамещению в госсекторе и КИИ только ужесточаются. Хорошая новость – российский стек уже закрывает большую часть сценариев DWH. Плохая – переносить схему «как было» нельзя, проектировать нужно заново под реальные нагрузки.

Выбор ядра хранилища

Под аналитику отдельно стоит смотреть колоночные СУБД. ClickHouse (разработка Яндекса, в реестре отечественного ПО) держит миллиарды строк и отдаёт агрегаты за секунды – это рабочая замена связки «Oracle + витрины» для отчётности и дашбордов. Для классической реляционной нагрузки и сложных JOIN подойдёт Postgres Pro или Tantor на базе PostgreSQL: зрелый оптимизатор, партиционирование, поддержка от российского вендора с SLA. Greenplum в форме Tantor SE или Arenadata DB закрывает MPP-сценарии, где данные не помещаются на один узел.

Практический критерий выбора простой. Если у вас преимущественно чтение и агрегация – берите колоночное ядро. Если хранилище обслуживает и оперативные транзакции, и аналитику – разделяйте контуры: OLTP на PostgreSQL, OLAP на ClickHouse или Greenplum, между ними – регламентная загрузка. Не пытайтесь сделать одну СУБД универсальной, на этом обжигались ещё на Oracle.

ETL, BI и слой моделирования

Загрузку и трансформацию данных закрывают Apache NiFi и Airflow – оба открытые, без лицензионных рисков, с предсказуемым поведением под нагрузкой. Для визуализации вместо Power BI и Tableau используйте Visiology или Apache Superset; последний бесплатен и хорошо ложится на ClickHouse. Слой моделирования – звёзды, снежинки, медальон-архитектура – остаётся прежним, меняется только исполнитель. Логика витрин не зависит от вендора СУБД, и это ваш главный актив при миграции.

Отдельно про данные для ИИ-сервисов. Если вы планируете аналитику поверх неструктурированного контента – документов, обращений, переписки, – стоит заранее предусмотреть слой эмбеддингов и векторного поиска рядом с DWH; мы разбирали этот подход в материале про базу знаний на RAG. Хранилище и поисковый индекс лучше проектировать как единую платформу данных, а не два изолированных проекта.

Миграция без простоя и потери данных

Переезд хранилища – это не разовая выгрузка, а параллельная работа двух систем на время сверки. Сначала поднимаете новый контур, настраиваете загрузку из тех же источников, затем неделями сверяете цифры в старой и новой отчётности до полного совпадения. Только после этого отключаете legacy. Тот же принцип мы применяли при замене SAP на производстве: двойной контур снижает риск до приемлемого.

Не забудьте про регламент восстановления. Аналитическое хранилище кажется некритичным до первого сбоя перед закрытием периода, поэтому резервное копирование и проверенный план DR закладывайте в проект сразу – как это устроено, мы описывали в статье про резервное копирование и аварийное восстановление.

Вывод

Построить DWH без Oracle и Teradata сегодня – рабочая, а не экспериментальная задача. Российский стек даёт зрелые компоненты под каждый слой: ядро, загрузку, визуализацию. Ключ к результату – не механическая замена продуктов, а пересборка архитектуры хранилища под фактические данные и нагрузки.