Гибридное хранилище данных

Гибридное хранилище данных (англ. Data Lakehouse, сокращенно DLH) — это архитектурный паттерн, реализующий возможности, аналогичные возможностям баз данных (далее БД), поверх масштабируемого объектного хранилища [1]. Этот паттерн предлагает многослойную конструкцию, где каждый слой отвечает за определённые функции [1]. Концепция Data Lakehouse является закономерным этапом эволюции архитектур управления корпоративными данными, обеспечивающий фундамент для построения AI-Ready платформы.

В современном корпоративном ландшафте данные перестали быть просто побочным продуктом операционной деятельности — они стали стратегическим активом и топливом для цифровой трансформации. Однако, организации сталкиваются с фундаментальной дилеммой: как совместить гибкость хранения любых форматов данных с дисциплиной, необходимой для получения надёжных аналитических выводов? Традиционные Data Warehouse (DWH) предлагали структурированность, высокую производительность запросов и дисциплину данных, но оказались дороги в масштабировании и негибки при работе с неструктурированными форматами [2]. Data Lake решили проблему стоимости хранения, позволив накапливать данные в любом виде, однако быстро превращались в «Data Swamp» (болото данных) из-за отсутствия ACID-транзакций, согласованности и эффективных механизмов управления [1][6].

Ответом на эти вызовы стала архитектура Data Lakehouse — конвергентное решение, которое наносит структуру и дисциплину хранилища поверх гибкости и масштабируемости озера данных. Как показывают исследования Harby и Zulkernine (2025), Lakehouse объединяет сильные стороны обеих парадигм, обеспечивая поддержку ACID-транзакций, управление схемой и эффективную аналитику без многократного копирования данных [4][8]. Эволюция архитектур управления данными [2]:

Характеристика	Data Warehouse (1990-е)	Data Lake (2010-е)	Data Lakehouse (2020-е)
Основной фокус	Бизнес-аналитика, отчётность	Big Data, ML, неструктурированные данные	Единая платформа для BI и AI/ML
Формат данных	Структурированные, очищенные	Любые (сырые, структурированные и нет)	Любые, с управляемой схемой
Стоимость хранения	Высокая	Низкая	Низкая
ACID-транзакции	Полная поддержка	Отсутствуют	Полная поддержка на уровне таблиц
Производительность	Высокая	Низкая без доп. обработки	Высокая (индексы, кэширование)
Управление схемой	Schema-on-write	Schema-on-read	Schema-on-write с эволюцией

Концепция AI-Ready Data, определяемая IBM как данные с унифицированным доступом к структурированной и неструктурированной информации, единым семантическим слоем и возможностью безопасного масштабирования [3], находит свою естественную реализацию именно в архитектуре Lakehouse. Исследователи подчёркивают, что большинство GenAI-проектов останавливаются на стадии пилотов именно из-за неподготовленности данных [3]. Lakehouse для AI-Ready платформ обеспечивает:

Прямой доступ к данным для фреймворков машинного обучения без необходимости предварительной выгрузки [1].
Открытые форматы хранения (Parquet, Iceberg), исключающие привязку к вендору [1][7].
Единый семантический слой для согласованной интерпретации данных бизнес-пользователями и AI-моделями.
Поддержку как транзакционных, так и аналитических нагрузок в рамках единой платформы [3].

Пример практической реализации: Проект гибридного хранилища

Пример исходных условий и требований

Источник данных: операционная таблица table_1 в MS SQL Server (db_1) со следующими характеристиками:

Текущий объём: 3 ТБ
Ежегодный прирост: 2 ТБ
Структура: 5 колонок (включая UUID, дату-время, неструктурированные данные в формате JSON)
Режим работы: несколько тысяч пользователей 23/7, пик 9:00-18:00, окно обслуживания 7:00-8:00

Цель: обеспечить долгосрочное (5+ лет) хранение данных и доступ для аналитики, минимизируя влияние на операционную систему и создавая фундамент для AI-инициатив.

Архитектурное решение: Медальон-архитектура на PostgrSQL

В проекте сознательно использованы функциональные названия слоёв STAGING и RAW DATA LAKE, соответствующие их роли в медальон-архитектуре [2]:

Слой 1: STAGING (бронзовый/приёмочный слой)

Назначение: первичная загрузка свежих данных из источника
Характеристики: перезаписывается при каждой загрузке (интервал — сутки в окно 7:00-8:00), минимизирует нагрузку на операционную БД
Технология: временные таблицы PostgreSQL

Слой 2: RAW DATA LAKE (бронзовый/архивный слой)

Назначение: долговременное накопление сырых данных в неизменном виде (append-only)
Характеристики: партиционирование по кварталам, хранение 5+ лет (прогнозируемый объём 11 ТБ)
Технология: PostgreSQL с декларативным партиционированием и табличными пространствами на отдельных LVM-томах

Слой 3: COMMON DATA MARTS (золотой слой)

Назначение: витрины данных для аналитики и операционного использования
Характеристики: агрегированные, очищенные данные, оптимизированные для BI-инструментов
Технология: представления (views) и материализованные представления PostgreSQL

Трёхэтапный план реализации

Этап	Технологии	Сроки	Результат
MVP	PostgreSQL, cron, LVM, Python + ODBC	2-3 дня	Автоматическая ежесуточная загрузка, двухслойное хранение, партиционирование
Промышленное внедрение	Apache Airflow, Zabbix, Grafana, Docker (опционально)	2-3 месяца	Оркестрация, мониторинг, загрузка исторических данных чанками, резервное копирование
Развитие	dbt (опционально), расширение PostgreSQL	6-12 месяцев	Витрины данных, интеграция новых источников, SCD, семантический слой

Расчёт ресурсов проекта

Исходные данные и допущения

Источник: таблица table_1 (MS SQL Server) размером 3 ТБ на старте, ежегодный прирост 2 ТБ.
Сырые данные (RAW): хранятся без изменений. За 5 лет общий объем RAW достигнет 3 + 4×2 = 11 ТБ (с учетом начальных 3 ТБ и 4 лет прироста по 2 ТБ). В дальнейшем будем оперировать максимальным расчетным объемом 11 ТБ для сырых данных.
Производные слои: ODS, DDS, витрины (Common Data Marts). Их объем зависит от степени агрегации и нормализации. Примем коэффициент 1.5 от объема сырых данных (на основе опыта подобных проектов). Тогда общий объем данных в PostgreSQL составит: 11 × 1.5 ≈ 16.5 ТБ.
Индексы: для таблиц фактов и измерений необходимы индексы. В среднем индексы занимают 30% от объема таблиц. С учетом индексов общий объем БД: 16.5 × 1.3 ≈ 21.5 ТБ.
Партиционирование: данные разбиты по кварталам. Каждая квартальная партиция RAW содержит примерно 2 ТБ / 4 = 0.5 ТБ сырых данных. С индексами и накладными расходами – 0.65 ТБ. Для 5 лет (20 кварталов) – 13 ТБ только RAW. Остальные слои также будут партиционированы по датам, но их размер меньше.

Дисковая подсистема

Тома должны обеспечивать разделение данных по производительности и надежности. Используем комбинацию быстрых SSD (RAID10) для активных данных и медленных HDD (RAID6) для архивов и бэкапов.

Тома для данных PostgreSQL (активные партиции):

Назначение: хранение данных за последние 2 года (8 кварталов) — наиболее часто запрашиваемые для аналитики.
Объем:
- Сырые данные за 2 года: 4 ТБ (2 года × 2 ТБ/год).
- Производные слои за тот же период: примерно 4 × 1.5 = 6 ТБ (без индексов).
- С индексами: 6 × 1.3 = 7.8 ТБ.
- Итого активные данные: 4 + 7.8 = 11.8 ТБ.
Распределение по кварталам: 8 томов по ~1.5 ТБ каждый (с запасом на рост индексов и временные файлы).
Тип дисков: SSD (SAS или NVMe) – высокие IOPS для операций вставки (загрузка исторических данных) и аналитических запросов.
RAID: RAID10 (зеркало+полоса) – максимальная производительность и отказоустойчивость.
Ожидаемая нагрузка:
- Пиковая запись: при загрузке исторических данных чанками до 100 ГБ/час.
- Пиковое чтение: сложные аналитические запросы, сканирования больших таблиц.
Требуемые IOPS: не менее 5000 IOPS (случайное чтение/запись), лучше 10 000+.
Пропускная способность: не менее 500 МБ/с на последовательное чтение/запись.

Тома для данных PostgreSQL (архивные партиции старше 2 лет):

Назначение: данные с 3-го по 5-й год (12 кварталов), доступ к которым редок.
Объем: аналогично расчету для активных, но без производных слоев? Фактически производные слои тоже могут архивироваться, но для упрощения считаем, что они также хранятся, но на медленных дисках. Итого: за 3-5 годы (3 года) сырых данных 6 ТБ, производные слои 9 ТБ, с индексами ~12 ТБ. Всего архивных данных: ~18 ТБ.
Распределение: 12 томов по 1.5 ТБ.
Тип дисков: HDD (SAS 7.2k rpm) – достаточная емкость, низкая стоимость.
RAID: RAID6 (двойная четность) – эффективное использование емкости, защита от сбоев двух дисков.
Требования: низкие IOPS (достаточно 500-1000), пропускная способность 100-200 МБ/с.

Том для WAL (Write-Ahead Log):

Назначение: оперативный журнал транзакций PostgreSQL.
Размер: рекомендуется 100–200 ГБ для обеспечения бесперебойной работы при пиковых нагрузках. Расчет: средняя дневная запись данных ~5.5 ГБ (при 2 ТБ в год). WAL генерируется примерно в том же объеме, что и изменения, плюс накладные. За сутки ~10 ГБ. Для надежности и с учетом исторических загрузок (до 1 ТБ в день) нужно иметь запас. Берем 200 ГБ.
Тип дисков: SSD или NVMe с очень низкой задержкой.
RAID: RAID10.
IOPS: критически важна задержка записи (должна быть < 1 мс). Ожидаемая нагрузка до 1000-2000 IOPS.

Том для WAL-архивов (непрерывное архивирование):

Назначение: хранение архивных сегментов WAL для восстановления на любой момент времени.
Размер: хранение минимум 2 недели. При максимальной интенсивности записи (например, при загрузке исторических данных) за 2 недели может накопиться до 2 ТБ данных (если загружается 10 ТБ за 2 недели). Заложим 500 ГБ с запасом.
Тип дисков: SSD или HDD в RAID10 (для надежности).
RAID: RAID10.

Том для резервных копий (бэкапы):

Назначение: хранение полных и инкрементальных бэкапов.
Размер: требуется место для нескольких поколений бэкапов. Применяем политику:
- Ежедневные полные бэкапы последних 14 дней (14 копий).
- Еженедельные полные бэкапы последних 8 недель (8 копий).
- Ежемесячные полные бэкапы за последние 12 месяцев (12 копий).
Объем полного бэкапа сжатого: обычно в 2-3 раза меньше исходных данных (за счет сжатия и отсутствия индексов). При размере БД 21.5 ТБ, сжатый бэкап может занимать ~8-10 ТБ. Для расчета возьмем 10 ТБ на один полный бэкап.
Необходимое место:
- 14 ежедневных: 14 × 10 = 140 ТБ.
- 8 еженедельных: 8 × 10 = 80 ТБ.
- 12 ежемесячных: 12 × 10 = 120 ТБ.
- Итого 340 ТБ. Это очень много, но обычно применяют инкрементальные бэкапы и ротацию. На практике можно использовать более эффективную стратегию, например, один полный бэкап в неделю + ежедневные дифференциальные. Рекомендуется выделить 30–50 ТБ для бэкапов, используя дедупликацию и сжатие на уровне системы резервного копирования. В требованиях закладываем 40 ТБ как минимальный объем с возможностью расширения.
Тип дисков: HDD (большие емкости) в RAID6.
RAID: RAID6.

Том для логов (системные, PostgreSQL, Airflow):

Назначение: хранение логов всех компонентов.
Размер: при интенсивной работе лог-файлы могут занимать до 100–200 ГБ с учетом ротации (например, logrotate).
Тип дисков: SSD (для быстрого доступа при анализе проблем).
RAID: RAID1.

Системные тома для ОС (каждой ВМ):

Размер: 50–100 ГБ.
Тип дисков: SSD.
RAID: RAID1.

Том для приложений (Airflow, скрипты):

Размер: 50–100 ГБ.
Тип дисков: SSD.
RAID: RAID1.

Суммарное дисковое пространство (физическое) с учетом RAID:

Активные данные (SSD RAID10): 11.8 ТБ полезных → с учетом зеркалирования (RAID10 требует 2× места) нужно 23.6 ТБ физических SSD.
Архивные данные (HDD RAID6): 18 ТБ полезных → при RAID6 с 8 дисками эффективность (N-2)/N, например, для 8 дисков эффективность 75% → потребуется 24 ТБ физических HDD.
WAL (SSD RAID10): 0.2 ТБ полезных → 0.4 ТБ физических.
WAL-архивы (HDD RAID10): 0.5 ТБ полезных → 1 ТБ физических (если RAID10, то 2×).
Бэкапы (HDD RAID6): 40 ТБ полезных → при RAID6 из 8 дисков эффективность 75% → 53.3 ТБ физических.
Логи (SSD RAID1): 0.2 ТБ полезных → 0.4 ТБ.
Системные (SSD RAID1): на каждую ВМ по 0.1 ТБ полезных → для 3 ВМ (БД, Airflow, мониторинг) нужно 0.3 ТБ полезных, физических 0.6 ТБ.
Приложения (SSD RAID1): 0.1 ТБ полезных → 0.2 ТБ физических.

Итоговые потребности в физических дисках:

SSD: 23.6 + 0.4 + 0.4 + 0.6 + 0.2 = 25.2 ТБ.
HDD: 24 + 1 + 53.3 = 78.3 ТБ.

Оперативная память (RAM)

Рекомендации для PostgreSQL:

Shared buffers: 25% RAM, но не более 16-32 ГБ для БД до 10 ТБ (по старым правилам). Современные версии могут использовать больше, но выделим 32 ГБ.
Эффективный кэш ОС: остальная память будет использоваться для кэширования данных файловой системы. Для активного набора данных (11.8 ТБ) кэшировать всё невозможно, но важно иметь достаточно для рабочих наборов запросов.
Рабочая память для сортировок/хешей: параметры work_mem и maintenance_work_mem. При большом количестве одновременных соединений нужно достаточно памяти. Рекомендуется 64–128 ГБ для БД.
Дополнительно: память для Airflow (8–16 ГБ), мониторинга (4–8 ГБ).

Итого: для сервера БД минимум 128 ГБ, лучше 256 ГБ. Для сервера Airflow: 16 ГБ. Для сервера мониторинга: 8 ГБ.

Общая RAM в системе виртуализации: 128+16+8 = 152 ГБ (минимум), лучше 256+32+16 = 304 ГБ.

Процессор (CPU)

Сервер БД: PostgreSQL хорошо масштабируется на многоядерных системах. Требуется параллельная обработка запросов, загрузка данных, создание индексов. Рекомендуется 16–32 физических ядра (или vCPU с учетом hyper-threading). При использовании виртуализации – 32 vCPU.
Сервер Airflow: 4–8 vCPU.
Сервер мониторинга: 2–4 vCPU.

Итого: около 44 vCPU.

Сеть

Связь с источником MS SQL: для загрузки исторических данных (например, 10 ТБ за неделю) потребуется пропускная способность: 10e12 / (7*86400) ≈ 16.5 МБ/с. Это легко покрывается 1 Гбит/с (125 МБ/с). Но для параллельной загрузки и ускорения процесса рекомендуется 10 Гбит/с.
Внутренняя сеть между компонентами: для репликации БД (если будет) и обмена данными между Airflow и БД достаточно 1 Гбит/с, но для надежности лучше заложить 10 Гбит/с на всех узлах.

Дополнительные соображения

LVM: все тома должны быть на LVM для возможности расширения.
Zabbix/Grafana: требуют незначительных ресурсов, но необходимо предусмотреть дисковое пространство под историю метрик (например, 100 ГБ).
Возможность роста: при увеличении объема данных до 10-15 ТБ потребуется пропорциональное увеличение RAM и CPU. Архитектура должна позволять добавление ресурсов без остановки.

Итоговые требования к ресурсам

Минимальные требования к ресурсам проекта:

Компонент	Ресурс	Значение (минимум)
Сервер БД (PostgreSQL)	CPU (vCPU)	32
	RAM	128+ ГБ
	Диски SSD (RAID10)	25 ТБ (физических)
	Диски HDD (RAID6)	78 ТБ (физических)
Сервер Airflow	CPU (vCPU)	8
	RAM	16 ГБ
	Диск SSD (RAID1)	100 ГБ
Сервер мониторинга	CPU (vCPU)	4
	RAM	8 ГБ
	Диск SSD (RAID1)	100 ГБ + 100 ГБ для метрик
Сеть	Интерконнект	10 Гбит/с

Минимальные требования к дисковым томам:

Том	Размер (полезный)	Тип дисков / RAID	Назначение
Активные партиции (последние 2 года)	11.8 ТБ	SSD / RAID10	Горячие данные, высокие IOPS
Архивные партиции (старше 2 лет)	18 ТБ	HDD / RAID6	Холодные данные, редкие запросы
WAL (журнал транзакций)	200 ГБ	SSD / RAID10	Критически важная производительность записи
WAL-архивы	500 ГБ	SSD или HDD / RAID10	Непрерывное архивирование
Резервные копии	40 ТБ	HDD / RAID6	Полные и инкрементальные бэкапы
Логи	200 ГБ	SSD / RAID1	Системные логи, логи БД, Airflow

Эти цифры являются отправной точкой для проектирования. Финальные параметры должны быть уточнены после пилотного тестирования и анализа реальной нагрузки.

Почему вынос данных из операционной БД — единственно верное решение

У проекта создания Data Lakehouse на PostgreSQL есть альтернативное решение — оптимизировать хранение данных внутри исходной БД db_1 на MS SQL Server.

Подробное сравнение двух подходов

Описание подхода 1 (предложенное решение создания отдельного Data Lakehouse на PostgreSQL):

Данные выгружаются из table_1 в отдельное хранилище на базе PostgreSQL.
Используются слои: STAGING (перезаписываемый), RAW DATA LAKE (накопительный), в перспективе ODS, DDS, витрины.
Партиционирование по кварталам в PostgreSQL с размещением на отдельных томах LVM, архивация томов старше 2 лет.
Оркестрация: Airflow.
Мониторинг: Zabbix + Grafana.

Описание подхода 2 (оптимизация хранения внутри исходной MS SQL Server db_1):

Таблица table_1 остаётся в db_1, но к ней применяется партиционирование по дате (например, по кварталам).
Исторические партиции (старше 2 лет) перемещаются на медленные (архивные) диски, возможно, в другой файловой группе.
Используются возможности MS SQL Server: секционирование, перемещение секций между файловыми группами, сжатие данных, индексы.
Обеспечивается доступ к историческим данным через ту же таблицу (прозрачно для приложений) или через представления.
Для аналитики можно строить отчёты непосредственно по table_1 или создать отдельные индексы/представления.
Мониторинг осуществляется с помщью Zabbix и Grafana.

Сравнение подходов по ключевым критериям:

Критерий	Подход 1: Отдельное Data Lakehouse (PostgreSQL)	Подход 2: Оптимизация внутри исходной MS SQL Server
Влияние на операционную БД	Минимальное. Выгрузка данных происходит в окно 7:00–8:00 через чтение из `table_1`. Исторические загрузки можно выполнять чанками вне пиковых часов. Сама операционная БД не нагружается дополнительными индексами или партиционированием.	Существенное. Партиционирование больших таблиц в активно используемой БД может вызывать блокировки при переключении секций, обслуживании индексов, обновлении статистики. Операции по перемещению старых данных между дисками требуют времени и ресурсов, могут конфликтовать с рабочей нагрузкой.
Производительность операционной системы	Не изменяется, т.к. все операции с историей вынесены.	Может ухудшиться из-за фоновых задач обслуживания партиций, сжатия, перестроения индексов. Также запросы к историческим данным могут конкурировать за ресурсы с оперативными.
Доступность исторических данных для аналитики	Полноценная аналитика на отдельном сервере без риска повлиять на production. Можно строить сложные запросы, агрегации, витрины.	Аналитика выполняется на том же сервере, что может создавать нагрузку и замедлять оперативную работу. Чтобы избежать этого, придётся использовать реплики чтения или изолировать нагрузку.
Управление жизненным циклом данных (архивация)	Гибкое: тома с партициями старше 2 лет можно отмонтировать и хранить отдельно. Доступ по запросу через монтирование тома. В PostgreSQL можно отключать табличные пространства.	В MS SQL Server можно перемещать партиции в другую файловую группу на медленных дисках, но отключение/включение файловых групп без остановки БД ограничено. Полное изъятие данных из БД (detach) сложнее и может потребовать создания архивных таблиц.
Резервное копирование и восстановление	Можно выполнять независимо от production. Резервное копирование Data Lakehouse оптимизировано под большие объёмы (например, только изменения).	Бэкапы `db_1` будут включать и исторические данные, что увеличивает время бэкапа и восстановления. Приходится делать более частые бэкапы production, что дороже.
Масштабируемость	Горизонтальное масштабирование: можно вынести Data Lakehouse на отдельные мощные серверы, использовать реплики для отчётов.	Масштабирование ограничено возможностями одного экземпляра MS SQL Server. Для больших объёмов придётся использовать дорогие редакции Enterprise с поддержкой секционирования и продвинутого сжатия.
Стоимость лицензирования	PostgreSQL — бесплатен (GPL). Не требуется дополнительных лицензий. Airflow, Zabbix, Grafana — Open Source. Затраты только на оборудование и поддержку.	MS SQL Server требует лицензий. Для партиционирования необходима редакция Enterprise (очень дорогая). Также могут потребоваться дополнительные лицензии на ядра для обработки исторических данных.
Сложность внедрения и поддержки	Требуется развернуть новый стек технологий (PostgreSQL, Airflow, мониторинг). Но это делается однократно и независимо от production.	Меньше новых компонентов, но требуется глубокое знание MS SQL Server, тюнинг партиционирования, планирование окон обслуживания. Риск ошибок выше из-за работы на живой системе.
Гибкость аналитических слоёв	Максимальная: можно создавать любые промежуточные слои (ODS, DDS, витрины) без ограничений.	Ограничена возможностями SQL Server. Для построения сложных витрин придётся либо создавать дополнительные таблицы в той же БД (увеличивая нагрузку), либо использовать ETL в другую БД (фактически подход 1).
Сохранение историчности (SCD)	Реализуется на уровне DDS с поддержкой SCD типа 2.	В исходной таблице, скорее всего, данные только добавляются или обновляются? Если нужна история изменений, придётся реализовывать триггеры или CDC, что дополнительно нагружает production.
Возможность добавления новых источников	Легко расширяется: новые таблицы или внешние данные интегрируются в Data Lakehouse без влияния на production.	Всё остаётся в одной БД, что может привести к её перегрузке и усложнению структуры.
Надёжность и риск для production	Риск минимален: выгрузка данных — только чтение. Сбой в Data Lakehouse не влияет на работу прикладной системы.	Любые операции с историческими данми (обслуживание, резервное копирование) могут повлиять на production.
Архивация старых данных	Простое отмонтирование томов LVM	Требуется сложное перемещение партиций внутри БД
Скорость доступа к историческим данным	Может быть ниже, если данные на отмонтированных томах, но при подключении — приемлемо. На активных данных — высокая производительность благодаря отдельным ресурсам.	Данные всегда в БД, но на медленных дисках. Запросы к ним могут тормозить, если не оптимизированы. Но доступ прозрачен.
AI/ML-готовность	Прямой доступ к данным для фреймворков ML [1][3]	Требуется предварительная выгрузка данных

Анализ влияния на production при подходе 2:

Партиционирование в MS SQL Server требует начальной операции секционирования, которая может заблокировать таблицу на время (для больших таблиц это часы). Это нужно делать в окно обслуживания.
Перемещение исторических партиций между файловыми группами (например, на медленные диски) выполняется командой ALTER TABLE ... SWITCH — это быстрая метаданная операция, но требует, чтобы целевая партиция была пуста и находилась в нужной файловой группе. Однако сама файловая группа должна быть создана, и диски должны быть доступны.
Сжатие данных (ROW или PAGE) может снизить объём, но увеличивает нагрузку на CPU при чтении/записи.
Индексы на партиционированной таблице должны обслуживаться (перестроение, реорганизация), что также требует ресурсов.
Резервное копирование всей БД (включая историю) будет длительным и может перекрываться с рабочим временем.

Выводы из сравнения двух подходов

Подход 1 (отдельное Data Lakehouse на PostgreSQL) предпочтительнее по следующим причинам:

Минимизация рисков для операционной системы. Производственная БД остаётся нетронутой, её производительность не страдает от фоновых задач по обслуживанию истории.
Экономическая эффективность. Бесплатное ПО (PostgreSQL, Airflow) против дорогих лицензий MS SQL Server Enterprise по некоторым оценкам позволяют снизить совокупную стоимость владения до 53% [3], а по другим оценкам совокупная стоимость владения за 5 лет может быть снижена в 3-4 раза:
- Экономия на лицензиях: MS SQL Server Enterprise для 32 ядер на 5 лет составляет ~7-10 млн руб. (оценка).
- Затраты на оборудование: ~2-3 млн руб. однократно (дисковые массивы, серверы).
- Трудозатраты: поэтапное внедрение позволяет распределить нагрузку на существующую команду.
Гибкость и масштабируемость. Data Lakehouse можно развивать независимо, добавлять новые источники, строить сложные витрины без ограничений.
Удобство архивации. Отмонтирование томов LVM с партициями старше 2 лет — простое и надёжное решение, не требующее сложных операций внутри СУБД.
Разгрузка production. Аналитические запросы не конкурируют с оперативными.

Подход 2 может быть оправдан только в исключительных случаях:

Если в организации уже есть неиспользуемые мощности MS SQL Server и лицензии Enterprise.
Если требования к аналитике минимальны и достаточно простых отчётов по историческим данным.
Если невозможно развернуть дополнительную инфраструктуру из-за политик безопасности.

Однако в условиях задачи (несколько тысяч пользователей, 23-часовая работа, необходимость долгосрочного хранения и аналитики) риски и стоимость подхода 2 перевешивают его преимущества. Поэтому рекомендуется реализовать отдельное хранилище данных на PostgreSQL, как описано в первом решении.

Научное обоснование решения создания гибридного хранилища данных

Предложенное решение по созданию долгосрочного гибридного хранилища данных на базе PostgreSQL с поэтапным внедрением (MVP → промышленная эксплуатация → развитие) представляет собой архитектурный подход, который не только решает конкретную бизнес-задачу, но и соответствует ряду фундаментальных концепций и современных трендов, признанных авторитетными аналитическими и консалтинговыми компаниями. Настоящий анализ рассматривает соответствие проекта следующим ключевым направлениям: эволюция медальон-архитектуры (Medallion Architecture), принципы Data Mesh, тренды платформенной инженерии и самообслуживаемой инфраструктуры, концепция AI-Ready Data, а также фундаментальные принципы построения корпоративных хранилищ данных.

Соответствие медальон-архитектуре (Bronze-Silver-Gold)

Медальон-архитектура, популяризированная Databricks, определяет трёхслойную организацию данных: бронзовый слой (bronze) — сырые данные в исходном виде, серебряный слой (silver) — очищенные и структурированные данные, золотой слой (gold) — агрегированные витрины для бизнес-пользователей [13].

Предложенное решение полностью воспроизводит данную логику с учётом специфики закрытого контура и ограниченных ресурсов:

Слой RAW DATA LAKE соответствует бронзовому слою: данные сохраняются в исходном виде (включая JSON-поля), накапливаются за весь период хранения (5+ лет), обеспечивая возможность пересмотра бизнес-логики без повторного обращения к источникам.
Слой STAGING выполняет функции, близкие к серебряному слою: обеспечивает быструю загрузку свежих данных и их первичную подготовку.
Слой COMMON DATA MARTS (третий этап) — классический золотой слой с агрегированными витринами для аналитики и операционного использования.

Harby и Zulkernine (2025) подтверждают, что трёхслойная организация данных (бронза-серебро-золото) обеспечивает оптимальный баланс между гибкостью и производительностью [8]. Как отмечает эксперт DWHPro, «медальон-архитектура — это не новая идея, а ваш старый подход, работающий на новой инфраструктуре» [13]. Действительно, классические хранилища данных использовали аналогичные слои (staging, integration, presentation) на протяжении десятилетий. Однако современная интерпретация, реализованная в проекте, добавляет критически важные элементы:

Постоянное хранение сырых данных — в традиционных подходах staging-слой часто был эфемерным из-за дороговизны дискового пространства [13]. В предложенном решении, благодаря современным экономическим моделям хранения (LVM на относительно недорогих носителях), сырые данные сохраняются постоянно, что обеспечивает возможность пересмотра трансформаций при изменении бизнес-требований.
Партиционирование с возможностью архивации — использование отдельных томов для квартальных партиций с возможностью отмонтирования данных старше двух лет соответствует принципу разделения горячих и холодных данных (hot/cold data separation), который является ключевым для современных платформ данных [13][15]. Исследования подтверждают, что экономическая эффективность Lakehouse достигается за счёт интеллектуального управления жизненным циклом данных и размещения горячих данных на быстрых носителях, а холодных — на ёмких и дешёвых [1].
Двухслойная структура на этапе MVP — подход «start small, experiment and remain flexible» [11] позволяет избежать «analysis paralysis» и начать с минимально жизнеспособного продукта, что полностью соответствует рекомендациям Thoughtworks по внедрению современных data-архитектур.

Соответствие принципам Data Mesh

Data Mesh — социотехнический подход к архитектуре данных, введённый Замак Дегхани в 2019 году, который основывается на четырёх принципах: предметно-ориентированное децентрализованное владение данными, данные как продукт, самообслуживаемая инфраструктура данных как платформа и федеративное вычислительное управление [11][18].

Хотя проект не предполагает полномасштабного внедрения Data Mesh, он содержит элементы, соответствующие этой парадигме:

Данные как продукт (Data as a Product) — на третьем этапе предусмотрено создание витрин COMMON DATA MARTS, которые по своей сути являются data-продуктами: они имеют чётких потребителей (аналитики, операционные подразделения), определённое качество и метрики доступности. Как отмечается в анализе Thoughtworks, именно этот принцип делает ценность Data Mesh осязаемой [11].
Самообслуживаемая инфраструктура (Self-Serve Data Platform) — в проекте заложено создание платформенных компонентов (Apache Airflow для оркестрации, Zabbix и Grafana для мониторинга), которые снижают когнитивную нагрузку на команды, работающие с данными. Это соответствует определению self-serve платформы как инструмента, который позволяет «убрать трение» для доменных команд [11].
Эволюционный подход — Thoughtworks подчёркивает, что организации, успешно внедрившие Data Mesh, учились на том, что «изменение способов работы сложнее, чем изменение технологий» [11]. Предложенный поэтапный подход (MVP → промышленное внедрение → развитие) позволяет адаптировать организационные процессы постепенно.

Важно отметить, что проект не требует полномасштабной трансформации в Data Mesh, что было бы избыточно для описанного контекста. Однако заложенные принципы модульности, расширяемости и возможности добавления новых источников данных на третьем этапе создают предпосылки для эволюционного движения в сторону децентрализованной архитектуры данных в будущем.

Платформенная инженерия и самообслуживаемая инфраструктура

Платформенная инженерия (Platform Engineering) — emerging-тренд, направленный на создание внутренних платформ для разработчиков (Internal Developer Platforms), которые обеспечивают баланс между централизованным контролем и децентрализованной ценностью [11].

Реализация в проекте:

Разделение инфраструктурных компонентов — выделение отдельных томов под данные, WAL-архивы, бэкапы и логи с использованием LVM соответствует лучшим практикам построения надёжных платформ данных [15].
Инструментарий для мониторинга и оркестрации — включение Apache Airflow, Zabbix и Grafana создаёт основу для наблюдаемости (observability) данных, что в 2026 году становится не просто преимуществом, а базовым требованием [10].
Баланс между централизацией и автономией — как отмечается в анализе Thoughtworks, наиболее эффективный паттерн — централизованная платформа, предоставляющая «инфраструктурный водопровод», при сохранении возможности доменных команд использовать инструменты, наилучшим образом подходящие для их задач [11]. Предложенное решение с PostgreSQL в качестве ядра и возможностью расширения на третьем этапе реализует именно такой подход.

Тренд на консолидацию data-инструментов (сокращение «стека из 50 инструментов до 5 платформ» [10]) полностью соответствует выбору ограниченного, но функционального набора технологий: PostgreSQL как единая платформа хранения, Airflow как единый оркестратор, Zabbix+Grafana как единая система мониторинга. Это позволяет минимизировать интеграционные издержки, которые, по данным исследований, составляют до 40% времени data-инженеров [10].

Соответствие концепции AI-Ready Data

IBM определяет AI-Ready Data как данные, которые обладают унифицированным доступом к структурированной и неструктурированной информации, единым семантическим слоем и возможностью безопасного масштабирования от пилотов до промышленной эксплуатации [12]. По данным Dell и Noventiq, Lakehouse-архитектура является единственным viable-решением для подготовки данных к использованию в AI/ML-нагрузках, поскольку обеспечивает прямой доступ к данным без их дублирования [3].

Реализация в проекте:

Работа с неструктурированными данными — исходная таблица содержит JSON-данные, что представляет собой классический пример неструктурированной информации, составляющей до 90% корпоративных данных [12]. Сохранение этих данных в неизменном виде в RAW-слое позволяет в будущем применять к ним современные методы анализа, включая LLM.
Семантический слой — на третьем этапе предусмотрено создание COMMON DATA MARTS, которые фактически являются реализацией семантического слоя (semantic layer). Как отмечается в прогнозах на 2026 год, семантический слой становится критически важным, поскольку «без него text-to-SQL — это просто угадывание» [10].
Качество данных как бизнес-функция — согласно Gartner, плохое качество данных обходится предприятиям в среднем в $12,9 млн в год [10]. Заложенная в проекте поэтапная очистка данных (STAGING → ODS/DDS → витрины) создаёт основу для управления качеством на системном уровне.

IBM подчёркивает, что большинство GenAI-проектов останавливаются на стадии пилотов именно из-за неподготовленности данных [12]. Предложенное решение, обеспечивающее чистое, структурированное и документированное хранение данных, создаёт фундамент для будущего применения AI-технологий, даже если на текущем этапе это не является приоритетом.

Фундаментальные принципы построения хранилищ данных

Независимо от технологических трендов, базовые принципы построения хранилищ данных остаются неизменными: разделение слоёв, управление жизненным циклом данных, обеспечение качества, документирование и наблюдаемость [10][13].

Реализация в проекте:

Управление жизненным циклом данных — партиционирование по кварталам с возможностью архивации томов старше двух лет обеспечивает экономически эффективное хранение больших объёмов данных (до 11 ТБ за 5 лет) без деградации производительности.
Разделение транзакционных и аналитических нагрузок — выгрузка данных в отдельное хранилище полностью исключает влияние аналитических запросов на операционную систему, что критически важно при работе нескольких тысяч пользователей 23 часа в сутки.
Резервное копирование и восстановление — выделение отдельных томов под WAL-архивы и бэкапы, использование RAID-массивов с учётом требований к надёжности и производительности соответствует enterprise-стандартам.
Наблюдаемость (Observability) — включение Zabbix и Grafana обеспечивает переход от пассивного мониторинга к активному управлению качеством данных, что является ключевым трендом 2026 года [10].

Как подчёркивается в прогнозах на 2026 год, «архитектурные изменения всё ещё могут ломать пайплайны, NULL-значения всё ещё могут разрушать отчёты, аномалии трафика всё ещё могут происходить, когда никто не мониторит в выходные» [10]. Заложенные в проекте механизмы мониторинга, резервирования и контроля качества являются не просто «nice-to-have», а необходимыми компонентами промышленного решения.

Соответствие тренду упрощения и консолидации data-стека

Аналитики фиксируют тренд на сокращение количества инструментов в корпоративном data-стеке: от 15-30 разрозненных решений к 5 интегрированным платформам [10].

Реализация в проекте:

Минималистичный стек на этапе MVP — только PostgreSQL и cron, что позволяет начать с минимальными компетенциями за 2-3 дня.
Постепенное наращивание функциональности — добавление Airflow, Zabbix, Grafana только тогда, когда это действительно требуется.
Отказ от избыточных компонентов — использование возможностей PostgreSQL для партиционирования и управления JSON-данными вместо внедрения специализированных NoSQL-решений.
Открытые технологии — выбор PostgreSQL (open-source) вместо проприетарных СУБД соответствует тренду на использование открытых форматов и предотвращение vendor lock-in [14]. Использование открытых форматов хранения и PostgreSQL гарантирует, что организация сохраняет контроль над своими данными и может менять инфраструктуру без потери информации [7].

ClickHouse в своём анализе облачных хранилищ данных отмечает, что современные архитектуры должны обеспечивать «верифицируемую свободу» от привязки к вендору [14]. Использование PostgreSQL и LVM с открытыми форматами хранения даёт организации возможность контролировать свои данные и менять инфраструктуру при необходимости без потери информации.

Итоги анализа соответствия решения проекта существующим трендам

Предложенное решение по созданию долгосрочного хранилища данных на базе PostgreSQL демонстрирует соответствие следующим ключевым концепциям и трендам в области информационных технологий:

Концепция / Тренд	Соответствие в проекте	Источник
Медальон-архитектура (Bronze-Silver-Gold)	Слои RAW → STAGING → COMMON DATA MARTS	[13]
Данные как продукт (Data as a Product)	Витрины данных с чёткими потребителями	[11], [17]
Платформенная инженерия	Самообслуживаемая инфраструктура с Airflow и мониторингом	[11]
AI-Ready Data	Сохранение неструктурированных данных, семантический слой	[12]
Разделение hot/cold данных	Партиционирование по кварталам с отмонтированием томов	[13], [15]
Наблюдаемость (Observability)	Zabbix, Grafana, мониторинг метрик	[10]
Консолидация data-стека	Ограниченный набор технологий, поэтапное внедрение	[10], [14]
Экономическая эффективность	Использование open-source, LVM, поэтапное финансирование	[11], [13]

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

Заключение

Представленный проект гибридного хранилища данных на базе PostgreSQL представляет собой не просто техническое решение конкретной задачи по долгосрочному хранению даных на базе гибридного хранилища данных, а первый шаг к созданию корпоративной AI-Ready платформы. Соответствуя современным архитектурным трендам и научным рекомендациям, он:

Минимизирует влияние на операционную систему.
Обеспечивает долгосрочное хранение данных с управляемым жизненным циклом.
Создаёт фундамент для аналитики и машинного обучения.
Экономически эффективен благодаря использованию открытого ПО и поэтапному внедрению.
Защищает от вендор-локина за счёт открытых форматов.

Как показывают успешные кейсы (Members 1st Federal Credit Union с 20 ТБ данных и 89% ускорением ML-моделей [5]; NinjaVan с трансформацией legacy-архитектуры [9]), такой подход не только реализуем, но и даёт измеримые бизнес-результаты.

Гибридное хранилище данных — это не компромисс, а эволюционно зрелое решение, объединяющее лучшее из двух миров и открывающее путь к данным, готовым для любых задач — от операционной отчётности до передовых AI-приложений.

Список используемых источников:

ClickHouse. (2026). Data Lakehouse: Озёрное хранилище данных. ClickHouse Documentation.
Открытая школа Т1. (2024). Разработчик DWH: Сквозной проект №2. GitHub Repository.
Шарипов, А. (2025). Data Lakehouse от Dell: Единая платформа для данных, аналитики и ИИ. Noventiq Blog.
Harby, A. A., & Zulkernine, F. (2025). Data Lakehouse: A survey and experimental study. Information Systems, 127, 102460. Elsevier.
Microsoft. (2025). Members 1st builds a modern data lakehouse with 3Cloud and Azure. Microsoft Partner Success Stories.
Кальченко, И. (2021). Преимущества Hybrid Data Lake. Как сочетать Data Warehouse с Data Lake. Dou.ua.
Oracle. (2025). Autonomous AI Database Data Studio. Oracle Documentation.
Harby, A. A., & Zulkernine, F. (2024). From data warehouse to lakehouse: A comparative review. In Proceedings of CIDR.
Singdata. (2025). NinjaVan’s Journey from Traditional Spark to Singdata Lakehouse. Singdata Customer Stories.
36Kr. (2026). Top 7 Predictions for Data and AI in 2026.
Thoughtworks. (2026). The state of data mesh in 2026: From hype to hard-won maturity.
IBM. (2026). The biggest data trends for 2026.
DWHPro. (2026). The Medallion Architecture Is Not New. We Just Called It Something Else.
ClickHouse. (2025). Top 5 cloud data warehouses in 2026: Architecture, cost, and open-source.
Lark. (2026). Cloud Database Management Systems: The Complete Guide.
Gartner. (2026). Data Lake, Lakehouse, Warehouse: How to Choose?
Conduktor. (2026). Data Mesh Principles and Implementation.
AllegroGraph. (2026). Data in 2026: Interchangeable Models, Clouds, and Specialization.

AI-Ready платформа Data Lakehouse ELT PostgreSQL гибридное хранилище данных корпоративная информационная система медальон-архитектура практика теория