26 марта 2026 года стало известно, что ПАО «ВК Технологии» присоединяет к себе CedrusData — команду и продукт, выросший вокруг аналитического движка на базе Trino. Для студента это не просто новость из мира M&A. Это готовый, свежий и легитимный контекст актуальности для ВКР по Data Engineering. Рынок консолидирует компетенции вокруг data lakehouse, MPP-запросов по внешним источникам и единой инфраструктуры дата-сервисов. Значит, тема «свой аналитический слой на Trino/Iceberg/Spark» перестаёт быть абстрактной и превращается в востребованный инженерный трек — с диаграммами, метриками и понятной бизнес-ценностью. Ниже — как это собрать в работу, которую примет кафедра и поймёт комиссия.
Статья относится к поддомену Data Engineering. Роль, от которой идёт разбор — Data/ML-инженер: мы смотрим на пайплайны, хранилища, движки запросов и то, как всё это живёт в Kubernetes.
Основной запрос: дата-сервисы и Lakehouse для ВКР.
LSI-пул: Trino, Apache Iceberg, Apache Spark, ClickHouse, Data Lakehouse, MPP-запросы, S3-совместимое хранилище, Kubernetes, оркестрация Airflow, Data Lineage, OpenTelemetry, SLA/SLO запросов, TCO кластера.
| Сущность | Где пригодится в дипломе |
|---|---|
| ГОСТ 34.601 / 34.602 | Стадии проектирования и ТЗ на систему обработки данных |
| ISO/IEC 25010 | Метрики качества: производительность, надёжность, сопровождаемость |
| Kubernetes | Развёртывание Trino/Spark, ресурсные лимиты, HPA |
| OpenTelemetry | Трассировка запросов, latency по стадиям, поиск узких мест |
| C4 / UML | Архитектурные и sequence-диаграммы конвейера данных |
Актуальность: интеграция CedrusData в VK Tech — прямой сигнал, что движки федеративных запросов становятся частью корпоративной платформы данных. Цель: спроектировать и оценить аналитический слой поверх S3-хранилища с форматом таблиц Iceberg.
Задачи: обзор MPP-движков; развёртывание Trino в Kubernetes; настройка каталога Iceberg; замер latency для выборок 1/10/100 ГБ; расчёт стоимости хранения против классического DWH.
Главы: 1 — анализ парадигм DWH vs Lakehouse; 2 — проектирование C4-диаграммы и развёртывание; 3 — бенчмарки, SLA и TCO.
Актуальность: объединение команд вокруг дата-платформ ускоряет запрос на унифицированные пайплайны. Цель: построить ETL-конвейер с контролем качества данных.
Задачи: постановка задачи по ГОСТ 34.602; DAG в Airflow; трансформации на Spark; data quality-проверки; мониторинг через OpenTelemetry.
Главы: 1 — обзор инструментов оркестрации; 2 — реализация DAG и слоёв bronze/silver/gold; 3 — тестирование качества и отказоустойчивости.
Актуальность: выбор движка — типичный спор инженеров после консолидации платформы. Цель: сравнить два движка на одном наборе данных и обосновать выбор.
Задачи: подготовка датасета; сценарии запросов; замеры QPS и p95-latency; оценка ресурсов в Kubernetes; выводы для production-архитектуры.
Главы: 1 — теория колоночных и MPP-движков; 2 — стенд и конфигурации; 3 — сравнительные метрики по ISO/IEC 25010.
Не пересказывайте новость. Возьмите из неё факт консолидации и постройте вокруг него проблему: разрозненные дата-сервисы дороже единой платформы. Здесь уместна диаграмма C4 уровня Context, где акторы — аналитик, инженер данных, BI-система, а внешние системы — S3, metastore, оркестратор.
Опишите архитектуру слоями: ingest → storage (Iceberg поверх S3) → compute (Trino/Spark) → serving. Приложите UML-диаграмму последовательности одного запроса. Ниже — минимальный пример развёртывания Trino в Kubernetes:
apiVersion: apps/v1
kind: Deployment
metadata:
name: trino-coordinator
spec:
replicas: 1
template:
spec:
containers:
- name: trino
image: trinodb/trino:latest
ports:
- containerPort: 8080
resources:
limits:
memory: "4Gi"
cpu: "2"
env:
- name: CATALOG_MANAGEMENT
value: "static"
Считать нужно не «быстро/медленно», а конкретно: p50/p95 latency, пропускная способность (запросов/сек), utilization CPU, стоимость ГБ обработки. Сведите результаты в таблицу и сопоставьте с ISO/IEC 25010 (производительность, надёжность). Такой подход легко защитить — цифры закрывают вопрос «а где тут научная новизна?».
Для ВКР бакалавра достаточно стенда в Docker/Kubernetes (k3s, minikube). Важно честно указать конфигурацию и ограничения — комиссия ценит воспроизводимость больше, чем «как в проде».
Открытые наборы: NYC Taxi, TPC-H, TPC-DS. Их удобно масштабировать генератором — это даёт честные замеры на 1/10/100 ГБ и красивый график.
Обычно: функциональная схема по ГОСТ 34.201, диаграмма классов/компонентов UML, sequence-диаграмма, ER-модель хранилища. C4 тоже принимают, если есть легенда.
Считайте TCO: стоимость ВМ/часов, объём хранения, стоимость запроса. Разница между классическим DWH и Lakehouse на вашем стенде — это и есть защищаемый результат.
1. Абстрактная актуальность. Пишут «данные растут», а не «интеграция CedrusData в VK Tech показывает консолидацию вокруг MPP-движков». Ссылайтесь на конкретное событие из статьи — это сразу выделяет работу.
2. Метрики без методологии. Замер «до/после» без указания числа прогонов, прогрева кэша и железа не защитим. Фиксируйте среду по ISO/IEC 25010.
3. Архитектура «на словах». Если развёртывание в Kubernetes описано абзацем, а не манифестом — комиссия задаст неудобные вопросы. Прикладывайте YAML и DAG.
Источник: VK Tech усиливает направление дата-сервисов: к группе присоединяется CedrusData (опубликовано 2026-03-26)