Архитектура сервиса

Data Lakehouse (DLH) собирает структурированные и неструктурированные данные из различных источников, обрабатывает их через Cloud Spark (ETL или ELT) или Cloud Trino (SQL-запросы), хранит в S3-хранилище с каталогизацией в Cloud Iceberg Metastore, управляет метаданными в DataHub и предоставляет данные для аналитики, BI и ML через Cloud Trino, Cloud Spark или Cloud ClickHouse.

Архитектура сервиса
  1. Структурированные данные из оперативных (OLTP) и корпоративных (CRM, ERP) систем поступают в Cloud Trino напрямую или через Cloud Spark для выполнения сложных ETL- и ELT-процессов.

  2. Полуструктурированные (JSON, XML, CSV) и неструктурированные (медиафайлы, документы) данные передаются в хранилище S3 в виде потоков или блоками.

  3. Cloud Trino и Cloud Spark используют API Iceberg Metastore для обмена данными с хранилищем S3.

    В Cloud Trino процесс обработки запросов включает прием (PULL-модель) и оптимизацию SQL-запросов координатором (Coordinator), который затем распределяет их между рабочими узлами (Workers), обеспечивая функциональность, аналогичную традиционным СУБД.

    Cloud Spark применяется для выполнения сложных ETL- и ELT-процессов. Этот сервис поддерживает как пакетную, так и потоковую обработку данных:

    • При потоковой обработке (Streaming Processing) данные обрабатываются непрерывно, микропартиями (mini-batches) или событийно (event-by-event), в режиме реального времени. Потоковая обработка осуществляется по PUSH-модели.

    • При пакетной обработке (Batch Processing) данные накапливаются партиями (файлы, таблицы) и обрабатываются единовременно. Процесс извлечения запускается по расписанию или вручную (PULL-модель).

  4. Cloud Iceberg Metastore каталогизирует объекты хранилища S3 и предоставляет API для доступа к нему.

    Хранение данных организовано с поддержкой ACID-транзакций через сервис Cloud Iceberg Metastore, который позволяет представить объекты хранилища S3 как таблицы БД. Использование хранилища S3 значительно снижает стоимость хранения.

  5. Общий список объектов и правил их обработки публикуется в каталоге данных на базе DataHub (с поддержкой функционала Data Discovery, Data Quality, Metadata Management, Data Governance, Data Lineage) для управления доступом и отслеживания истории данных.

  6. Обработанные данные из Cloud Trino и Cloud Spark могут быть использованы в различных внешних аналитических системах: MLflow, Jupyter, ClickHouse. Эти системы позволяют проводить углубленный анализ данных, создавать детализированные визуализации и управлять жизненным циклом моделей машинного обучения.

Модели обработки данных

В зависимости от задачи данные могут обрабатываться следующими способами:

  • PULL-модель — это подход, при котором данные из источника извлекаются по расписанию путем выполнения batch-процессов, которыми удобно управлять в Cloud Airflow. Подход применяется для простых ETL- и ELT-процессов, аналитики в хранилище S3, BI-интеграции, SQL-запросов к базам данных и если нагрузку на источник нужно контролировать.

  • PUSH-модель — это подход, при котором данные из источника автоматически отправляются в Cloud Spark или Cloud Trino. Подход используется для задач, где критична непрерывная доставка и обработка больших объемов данных: сложные ETL- и ELT-процессы, подготовка данных для аналитики, машинное обучение на больших данных.

При проектировании архитектуры Data Lakehouse важно определить, какие типы данных и каким образом будут обрабатываться:

Критерий

PULL-модель

PUSH-модель

Сервис

Cloud Airflow, Cloud Trino, Cloud Spark (пакетная обработка)

Cloud Spark (потоковая обработка, микробатчи)

Поддержка источников

API, БД, файлы

Для каждого источника необходимо разработать компонент, который будет отправлять данные через Producer API

Частота обновления

По расписанию

В реальном времени

Задержка данных

5–60 минут

< 1 секунды

Нагрузка на источник

Высокая (50–500 подключений в час)

Низкая (1–5 постоянных подключений)

Масштабируемость

Ограниченная (до 100 параллельных операций в секунду)

Высокая (до 10 000 параллельных операций в секунду)

Сложность интеграции

Низкая (1–2 дня на конфигурацию)

Высокая (требуется разработка Producer)