Этот выпуск полезен тем, что приземляет разговор о платформах данных из общего хайпа в реальные вопросы централизации, федерализации, подхода Data Mesh и границ между OLTP, MPP и платформенными сервисами.
В реальной инженерной работе он помогает переводить рыночные идеи 2025 года в карту возможностей и конкретные архитектурные решения, а не в очередной список инструментов, который команда потом будет годами поддерживать.
На интервью и архитектурных обсуждениях глава особенно сильна там, где нужно показать риск разрастания набора инструментов, зависимости от вендора и стоимости платформы, которая растёт быстрее реальной пользы.
Практическая польза главы
Практика проектирования
Переводит рыночные тренды 2025 года в конкретные архитектурные решения для команд платформ данных.
Качество решений
Помогает оценивать зрелость платформы через карту возможностей, а не через перечень технологий.
Аргументация на интервью
Добавляет актуальный контекст для обсуждения современного стека данных, управления и контроля стоимости.
Риски и компромиссы
Подсвечивает риск разрастания набора инструментов, зависимости от вендора и неуправляемой стоимости платформы.
Платформы данных в 2025 году: интервью с Николаем Головым
Интервью о том, как платформа данных живёт на практике, а не на схеме: операционная модель, платформа как продукт, где упирается транзакционная обработка (OLTP) и массово-параллельная (MPP) и как внедрять всё это, не разводя организационный хаос.
Источник
Telegram: Книжный куб
Краткий конспект интервью и основные тезисы выпуска одним постом.
О выпуске
Разговор крутится вокруг главного вопроса 2025 года: как построить платформу данных, которая ускоряет продуктовые команды, а не усложняет им жизнь. Решает здесь не выбор технологии, а баланс между доменной автономией, едиными платформенными стандартами и контролем стоимости.
Практический акцент простой: споры про «правильный стек» обычно уводят в сторону. Успех платформы чаще определяют операционная модель, зоны ответственности и качество платформенных возможностей — то, что не выбирается одной покупкой.
В этой главе рассматривается через , , , , и . Дальше мы связываем , , и с практикой внедрения.
Гость и контекст
Николай Голов
- Head of Data Engineering в ManyChat.
- Бывший руководитель платформы данных в Авито.
- Практик по построению платформ данных и преподаватель в области баз данных.
Ценность интервью в том, что организационные решения и архитектурные компромиссы здесь разбираются вместе, а не по отдельности, — на практике именно их разрыв и ломает платформы.
Что изменилось в 2025 году
- Спор о выборе хранилища отошёл на второй план: чаще решает операционная модель платформы — кто за что отвечает и как команды получают данные.
- Дата-продуктов стало больше, и это режет в обе стороны: спрос на самообслуживание вырос, но и цена слабого управления теперь видна сразу.
- Разделение хранения и вычислений и открытые форматы таблиц перестали быть экспериментом — без них предложение по платформе уже не воспринимают всерьёз.
- Сценарии с большими языковыми моделями (LLM) и малой задержкой подняли планку: устаревшие данные и непрозрачные конвейеры теперь попадают в продукт быстрее, чем их успевают заметить.
- Экономика платформы данных вместе с практиками управления затратами (FinOps) стала таким же архитектурным ограничением, как задержка и надёжность.
Связанная глава
Краткий обзор платформы данных Т-Банка
Практический кейс: как платформа данных проходит путь от классического хранилища (DWH) к lakehouse-архитектуре.
Организационные модели платформы данных
Централизованная платформа
Когда работает: Ранний этап или ограниченное число доменов и аналитических команд.
Сильные стороны
- Единые стандарты качества, безопасности и инструментов держатся одной командой.
- Базовые платформенные сервисы внедряются быстро, без долгих согласований между доменами.
Риски
- Доменные запросы упираются в одну команду — она же становится узким местом.
- Продуктовые команды слабо отвечают за качество исходных данных: за них это делает платформа.
Гибридная модель: платформа и доменные команды
Когда работает: Средняя или крупная компания с разными продуктами; соглашение об уровне сервиса (SLA) и целевой уровень сервиса (SLO) к данным уже нужно фиксировать явно.
Сильные стороны
- Платформа развивает общие возможности, а домены владеют своими дата-продуктами и отвечают за них.
- Время до получения данных сокращается, при этом стандарты и контроль стоимости не теряются.
Риски
- Нужны чёткие границы владения и договорённости по контрактам — иначе ответственность размывается.
- Стоит ослабить управление — и качество, схемы и семантика начинают расходиться между доменами.
Федеративная модель: зрелый подход Data Mesh
Когда работает: Очень крупные организации с автономными доменными подразделениями.
Сильные стороны
- Домены движутся на максимальной скорости и сами отвечают за результат у себя.
- Зоны ответственности масштабируются без того, чтобы все решения сводить в центр.
Риски
- Без единой планки качества вместо сетки данных получается набор разрозненных локальных решений.
- Если общий платформенный слой недоинвестирован, стоимость координации между доменами быстро растёт.
Референсная архитектура платформы данных
Слой приёма и захвата данных
Фокус: Захват изменений данных (CDC), событийные шины, пакетные коннекторы и приём данных по контрактам.
Задача слоя — доставлять данные в платформу предсказуемо, удерживая контроль над свежестью и схемами. Здесь же ломается всё остальное, если приём нестабилен.
Слой хранения и форматов таблиц
Фокус: Объектное хранилище, открытые форматы таблиц Iceberg/Delta/Hudi, партиционирование и сжатие файлов.
Слой отвечает за долговечность данных и эволюцию схем и отделяет вычисления от физического хранения — менять движок обработки можно, не трогая сами данные.
Слой вычислений и преобразований
Фокус: Пакетная и потоковая обработка, преобразования dbt/SQL, оркестрация и повторные запуски.
Здесь собираются готовые для доменов витрины и задаются целевые окна свежести. Цена ошибки на этом слое — невоспроизводимый конвейер, который при повторном запуске даёт другой результат.
Слой выдачи и потребления
Фокус: BI, обратная загрузка данных, хранилище признаков, API-доступ к дата-продуктам и MPP-выдача.
Слой потребления держит баланс между самообслуживанием и управляемостью: дать командам забирать данные самим, но не потерять контроль над стоимостью запросов и доступами.
Слой управления и надёжности
Фокус: Каталог, происхождение данных, контракты, проверки качества, наблюдаемость и сценарии реагирования на инциденты.
Этот слой обычно режут первым ради скорости — и именно тогда платформа копит скрытый долг и теряет доверие бизнеса. Восстановить доверие дороже, чем не терять.
Типичные антипаттерны
Подход Data Mesh без платформы
Проблема: Командам объявили автономию, но не дали общих возможностей для контрактов, качества и поиска данных. Автономия без опоры превращается в разрозненность.
Что делать: Сначала соберите общий платформенный слой и минимальные правила управления — и только потом расширяйте федерализацию.
Один MPP как ответ на всё
Проблема: MPP (массово-параллельная обработка) закрывает часть нагрузки аналитической обработки OLAP, но не отвечает за надёжность приёма данных, контракты и ответственность за результат.
Что делать: Ставьте MPP как слой выдачи внутри более широкого контура платформы данных, а не как саму платформу.
Сырые данные без продуктовой ответственности
Проблема: За смысл данных не отвечает никто — и команды-потребители строят несовместимые метрики поверх одних и тех же таблиц. Дальше расхождение в цифрах всплывает уже в отчётах для бизнеса.
Что делать: Назначьте владельцев дата-продуктов, публичное соглашение об уровне сервиса (SLA) и целевой уровень сервиса (SLO) на качество и свежесть.
Фокус только на технологиях
Проблема: Стек обновляется, а время до получения данных для продуктовых команд не меняется. Модернизация ради модернизации не оправдывает себя перед бизнесом.
Что делать: Привязывайте каждую инициативу к бизнес-метрике: времени поставки, надёжности или стоимости запроса.
Паттерны, которые работают
- Контракты на данные как обязательный интерфейс между командами-поставщиками и командами-потребителями: меняешь схему — не ломаешь чужой конвейер молча.
- Единый каталог и происхождение данных, чтобы находить зависимости и заранее видеть, что сломает изменение, до того как оно дойдёт до потребителей.
- Стандартизованные слои Bronze, Silver и Gold и семантический слой задают предсказуемый путь данных вместо набора разрозненных трансформаций.
- Продуктовая ответственность задаёт целевой уровень сервиса (SLO) на свежесть, полноту и стабильность схемы — у каждого дата-продукта есть владелец, а не только автор.
- Практики управления затратами (FinOps) на платформе: бюджетирование вычислений, оптимизация хранения, показ затрат командам (showback) и их перераспределение на команды (chargeback), чтобы стоимость была видна тем, кто её создаёт.
Дорожная карта внедрения на 180 дней
Базовая картина и карта ограничений
Сначала инвентаризация: источники, критичные конвейеры, текущее соглашение об уровне сервиса (SLA), целевой уровень сервиса (SLO) и инциденты. Фиксируем архитектурную картину и проблемы, которые действительно мешают продуктовым командам, а не те, что красиво звучат на докладе.
Минимум управления и единые интерфейсы
Внедряем контракты на данные, каталог и базовые проверки качества для критичных доменов. Здесь же закрепляем правила эволюции схем и ответственность за дата-продукты, пока доменов немного и договариваться дешевле.
Возможности самообслуживания
Запускаем шаблоны приёма и преобразования данных, стандарты наблюдаемости и повторяемые шаблоны конвейеров. Цель этапа — сократить время до первого набора данных для нового сценария, чтобы команды перестали ждать платформу в очереди.
Экономика и масштабирование модели
Подключаем показ затрат командам (showback) и их перераспределение на команды (chargeback), оптимизируем вычисления и хранение, расширяем доменную ответственность. К этому моменту гибридная модель обычно и становится основной.
Связанная глава
Data Governance & Compliance
Что держит доверие к данным: практики качества, происхождение данных и контроль доступа.
Метрики зрелости платформы
Время до первого набора данных
Ориентир: < 1 неделя
Как быстро новый сценарий получает готовые к работе данные. Растёт это время — платформа становится узким местом.
Надёжность конвейеров
Ориентир: 99.9%+
Доля успешных запусков критичных конвейеров без ручного вмешательства. Всё, что чинят руками по ночам, сюда не попадает.
Целевой уровень сервиса (SLO) по свежести соблюдается
Ориентир: >= 95%
Как часто данные укладываются в заявленные окна актуальности. Метрика показывает, можно ли доверять обещанной свежести.
Частота инцидентов схемы
Ориентир: Снижение квартал-к-кварталу
Сколько инцидентов вызвано несовместимыми изменениями схемы — прямой сигнал, работают ли контракты на данные.
Стоимость полезного инсайта
Ориентир: Контролируемое снижение
Связывает стоимость платформы с реальной ценностью для бизнеса, а не просто со счётом за вычисления.
Доля повторного использования
Ориентир: > 60%
Доля повторно используемых дата-продуктов и шаблонных конвейеров. Низкая доля означает, что каждая команда строит своё с нуля.
Связанные материалы и источники
- YouTube: Data platforms 2025 - Полная видеозапись интервью.
- Telegram: Книжный куб - Краткий конспект выпуска и ключевые тезисы.
- Яндекс Музыка - Аудиоверсия подкаста.
- Podster.fm - Альтернативная аудиоплощадка.
- Краткий обзор платформы данных Т-Банка - Те же компромиссы на реальном кейсе: как платформа и её архитектура менялись со временем.
- Data Mesh in Action: подход Data Mesh - Что стоит за федеративной моделью: доменная ответственность, самообслуживание и федеративное управление.
- Архитектура конвейеров данных: извлечение, преобразование и загрузка (ETL) и ELT - Как устроены слои приёма, преобразования и выдачи, о которых идёт речь в этой главе.
- Data Governance & Compliance - Слой управления крупным планом: качество данных, их происхождение и соответствие требованиям.
- Apache Iceberg: архитектура - Как открытые форматы таблиц дают транзакционный слой поверх lakehouse-хранилища.
- ClickHouse - Быстрая аналитическая выдача для дата-продуктов на слое потребления.