В системах персонализации классическая архитектура обычно строится вокруг предрасчётов — витрины в Hadoop, загрузки в PostgreSQL и множество ETL для разных сервисов. Такой подход хорошо работает на старте, но со временем начинает замедлять развитие продукта: каждый новый сценарий требует отдельной доставки данных.
В докладе я расскажу об эволюции data-платформы персонализации на десятках миллионов пользователей и переходе от push-архитектуры к lakehouse-подходу (S3 + Iceberg + Trino). Мы разберём, где классическая схема начинает ограничивать систему и как federated query-движок позволяет сервисам напрямую работать с исходными данными. Обсудим компромиссы такого перехода, сравнение с отдельной аналитической БД и возможность self-service витрин без новых ETL.
Highload, Интеграции, Архитектура
Бэкенд-разработчик, Руководитель команды / Технический руководитель, Технический директор / Архитектор
Средний
Data Engineer с более чем десятилетним опытом работы с большими данными.
Работал над data-платформами в телекоме и ритейле, включая системы персонализации для десятков миллионов пользователей, а также над проектами по обработке открытых данных.
Интересуется архитектурой data-систем, экспериментирует с технологиями и ищет инженерные подходы, которые помогают превращать данные в работающие продуктовые решения.