К какому классу систем (OLTP, OLAP, гибрид) относится система на вашем текущем/последнем проекте и почему?

На моем последнем проекте основная система относилась к OLAP-классу (Online Analytical Processing), с элементами гибридной архитектуры на уровне данных (Lakehouse).

Аргументация:

1. Назначение системы: Это было корпоративное хранилище данных (DWH) и платформа для анализа. Основные задачи:

   • Агрегация данных из 20+ источников (OLTP-системы, лог-файлы, внешние API).
   • Выполнение сложных аналитических запросов для формирования отчетов по продажам, финансам и поведению пользователей.
   • Обслуживание ML-моделей прогнозирования.

2. Характер нагрузки (Паттерны доступа):

   • Чтение-интенсивная: Соотношение запросов на запись/чтение было примерно 1:1000.
   • Пакетная запись: Данные загружались крупными пачками (batch) в ночное окно через ETL/ELT-пайплайны (Airflow).
   • Сложные запросы: Частые запросы с JOIN больших таблиц (миллиарды строк), оконными функциями (ROW_NUMBER(), LAG()), полным сканированием и агрегациями (SUM, COUNT DISTINCT).

3. Технологический стек, подтверждающий OLAP-направленность:

   • Хранилище: Greenplum (MPP-СУБД, оптимизированная для аналитики) и Delta Lake на S3 как data lake.
   • Модель данных: Денормализованная звездообразная схема (star schema) с большими таблицами фактов и компактными измерениями для ускорения JOIN.
   • Инструменты доступа: BI-системы (Power BI, Superset), Jupyter Notebooks для анализа данных, прямое подключение аналитиков через SQL-клиенты.

Гибридные элементы (Lakehouse): Мы использовали подход Lakehouse, где "сырые" данные в разных форматах (JSON, Parquet) хранились в Delta Lake на S3 (высокая масштабируемость, низкая стоимость), а затем преобразовывались в структурированные, оптимизированные таблицы в Greenplum для выполнения высокопроизводительных SQL-запросов. Это сочетало гибкость data lake с производительностью классического DWH.