Этот выпуск полезен тем, что приземляет разговор о data platforms из общего хайпа в реальные вопросы централизации, федерализации, mesh-подхода и границ между OLTP, MPP и платформенными сервисами.
В реальной инженерной работе он помогает переводить рыночные идеи 2025 года в capability map и конкретные архитектурные решения, а не в очередной список инструментов, который команда потом будет годами поддерживать.
На интервью, review и архитектурных разговорах глава особенно сильна там, где нужно показать риск tool sprawl, vendor lock-in и платформенной стоимости, которая растет быстрее реальной пользы.
Практическая польза главы
Практика проектирования
Переводит рыночные тренды 2025 в конкретные архитектурные решения для data-platform команд.
Качество решений
Помогает оценивать зрелость платформы через capability map, а не через перечень технологий.
Interview-аргументация
Добавляет актуальный контекст для обсуждения modern data stack, governance и cost control.
Риски и компромиссы
Подсвечивает риск tool sprawl, vendor lock-in и неуправляемой стоимости платформы.
Data platforms: как строить в 2025 году
Интервью о практической архитектуре современных data platform: операционные модели, платформа как продукт, ограничения OLTP/MPP и реалистичный путь внедрения без организационного хаоса.
Источник
Telegram: book_cube
Пост с кратким конспектом интервью и основными тезисами выпуска.
О выпуске
Разговор концентрируется на главном вопросе 2025 года: как построить платформу данных, которая ускоряет продуктовые команды, а не усложняет им жизнь. В центре обсуждения - баланс между доменной автономией, едиными платформенными стандартами и контролем стоимости.
Важный практический акцент: вместо абстрактных споров про «правильный стек» интервью показывает, почему успех платформы чаще определяется operating model, ownership и качеством platform capabilities.
Гость и контекст
Николай Голов
- Head of Data Engineering в ManyChat.
- Ex Head of Data Platform в Авито.
- Практик по построению data platform и преподаватель в области баз данных.
Интервью полезно тем, что связывает организационные решения и архитектурные trade-offs, а не рассматривает их отдельно.
Что изменилось в 2025
- Компании перестали спорить только про выбор хранилища и сместились к вопросу operating model платформы.
- Рост количества data products усилил спрос на self-service, но одновременно повысил цену ошибок в governance.
- Storage/compute decoupling и открытые table formats стали базовым ожиданием, а не экспериментом.
- LLM- и realtime-сценарии усилили требования к свежести данных и наблюдаемости data-пайплайнов.
- Экономика платформы (FinOps для data) стала частью архитектурных решений наравне с latency и reliability.
Связанная глава
Платформа данных Т-Банка
Практический кейс эволюции data platform от DWH-подхода к Lakehouse.
Организационные модели платформы
Централизованная платформа
Когда работает: Ранний этап или ограниченное число доменов и аналитических команд.
Сильные стороны
- Единые стандарты качества, безопасности и инструментов.
- Быстрое внедрение базовых платформенных сервисов.
Риски
- Платформенная команда становится bottleneck для доменных запросов.
- Слабая ответственность продуктовых команд за качество исходных данных.
Гибридная (platform + domain squads)
Когда работает: Средняя и крупная компания с разными продуктами и SLA к данным.
Сильные стороны
- Платформа развивает общие capabilities, домены владеют data products.
- Снижается time-to-data без потери стандартов и контроля стоимости.
Риски
- Требуются чёткие интерфейсы владения и договорённости по контрактам.
- Без governance легко получить расхождение по quality и semantics.
Федеративная (data mesh в зрелой форме)
Когда работает: Очень крупные организации с автономными доменными unit-ами.
Сильные стороны
- Максимальная доменная скорость и локальная ответственность.
- Масштабирование ownership без централизации всех решений.
Риски
- Риск data mash: много локальных решений без единого quality bar.
- Высокая стоимость координации, если platform layer недоинвестирован.
Референс-архитектура data platform
Ingestion и capture слой
Фокус: CDC, событийные шины, batch connectors, contract-based ingestion.
Ключевая цель - стабильно и предсказуемо доставлять данные в платформу с контролем свежести и схем.
Storage и table format слой
Фокус: Object storage + open table formats (Iceberg/Delta/Hudi), partitioning, compaction.
Этот слой отвечает за долговечность, эволюцию схем и изоляцию вычислений от физического хранения.
Compute и transform слой
Фокус: Batch/stream processing, dbt/SQL transformations, orchestration и retries.
Именно здесь формируются domain-ready витрины, SLA по свежести и повторяемость пайплайнов.
Serving и consumption слой
Фокус: BI, reverse ETL, feature stores, API-доступ к data products, MPP-serving.
Слой потребления должен быть self-service и одновременно управляем по стоимости и доступам.
Governance и reliability слой
Фокус: Каталог, lineage, data contracts, quality checks, observability и incident playbooks.
Без этого слоя платформа быстро накапливает hidden debt и теряет доверие со стороны бизнеса.
Типичные антипаттерны
Data mesh без платформы
Проблема: Команды объявляются автономными, но не получают общих capabilities для contracts, quality и discoverability.
Что делать: Сначала соберите platform layer и governance minimum, потом расширяйте федерализацию.
Один MPP как ответ на всё
Проблема: MPP закрывает часть OLAP-нагрузки, но не решает ingestion reliability, contracts и ownership.
Что делать: Проектируйте MPP как serving-слой внутри более широкого data platform контура.
Сырые данные без продуктового ownership
Проблема: Никто не отвечает за semantic quality, из-за чего downstream-команды строят несовместимые метрики.
Что делать: Назначьте владельцев data products и публичные SLA/SLO на качество и свежесть.
Фокус только на технологиях
Проблема: Команда улучшает stack, но не уменьшает time-to-data для продуктовых команд.
Что делать: Каждую инициативу связывайте с бизнес-метрикой: lead time, reliability, cost-per-query.
Паттерны, которые работают
- Data contracts как обязательный интерфейс между producer и consumer командами.
- Единый каталог + lineage для обнаружения зависимостей и impact analysis изменений.
- Стандартизованный medallion/semantic layering для предсказуемого пути данных.
- Product-oriented ownership с SLO на freshness, completeness и schema stability.
- FinOps-контур платформы: бюджетирование compute, оптимизация хранения, chargeback/showback.
Roadmap внедрения (0-180 дней)
Baseline и карта ограничений
Инвентаризация источников, критичных пайплайнов, текущих SLA и инцидентов. Фиксация архитектурного baseline и целевых проблем, которые действительно мешают продуктовым командам.
Governance minimum + единые интерфейсы
Внедрение data contracts, каталога и базовых quality checks для критичных доменов. Формализация правил schema evolution и ответственности за data products.
Self-service capabilities
Запуск шаблонов ingestion/transform, стандартов наблюдаемости и повторяемых pipeline templates. Цель - сократить time-to-first-dataset для новых use case.
Экономика и масштабирование модели
Подключение showback/chargeback, оптимизация compute/storage, расширение доменного ownership. На этом этапе гибридная модель обычно становится основной.
Связанная глава
Data Governance & Compliance
Практики качества, lineage и контроля доступа в платформе данных.
Метрики зрелости платформы
Time-to-first-dataset
Ориентир: < 1 неделя
Скорость доставки новых данных в продуктовые команды.
Pipeline reliability
Ориентир: 99.9%+
Доля успешных запусков критичных пайплайнов без ручного вмешательства.
Freshness SLO compliance
Ориентир: >= 95%
Насколько часто данные укладываются в заявленные окна актуальности.
Schema incident rate
Ориентир: Снижение квартал-к-кварталу
Частота инцидентов из-за несовместимых schema changes.
Cost per successful insight
Ориентир: Контролируемое снижение
Связка стоимости платформы с реальной ценностью для бизнеса.
Reusability ratio
Ориентир: > 60%
Доля повторно используемых data products и шаблонных пайплайнов.
Связанные материалы и источники
- YouTube: Data platforms 2025 - Полная видеозапись интервью.
- Telegram: book_cube - Краткий конспект выпуска и ключевые тезисы.
- Яндекс Музыка - Аудиоверсия подкаста.
- Podster.fm - Альтернативная аудиоплощадка.
- Краткий обзор платформы данных Т-Банка - Практический кейс эволюции платформы и архитектурных решений.
- Data Mesh in Action - Практика domain ownership, self-serve и federated governance.
- Data Pipeline / ETL / ELT Architecture - Проектирование ingestion/transform/serving контура.
- Data Governance & Compliance - Контроль качества данных, lineage и compliance-практики.
- Apache Iceberg: архитектура - Open table formats и транзакционный слой Lakehouse.
- ClickHouse - Быстрый аналитический serving для data products.