Эта глава ценна тем, что даёт не абстрактную платформу данных, а живой эволюционный кейс: как большая компания проходит путь от DWH-подхода к lakehouse-хранилищу и платформенной модели без одного магического прыжка.
В реальной инженерной работе она помогает видеть платформу как последовательность управляемых шагов: что централизовать, что оставить доменам, как пережить миграционный долг и где проходит граница между общей платформенной возможностью и локальной свободой команды.
На интервью и архитектурных обсуждениях она особенно полезна там, где нужно говорить не только о целевом состоянии, но и о цене перехода: разделении зон ответственности, управлении изменениями и накопленном архитектурном долге.
Практическая польза главы
Практика проектирования
Показывает эволюцию платформы данных как последовательность управляемых архитектурных шагов.
Качество решений
Даёт ориентиры, когда централизовать платформенную возможность, а когда оставить доменный контур автономным.
Аргументация на интервью
Усиливает ответы реальным производственным примером операционной модели платформы и её ограничений.
Риски и компромиссы
Фокусирует на стоимости трансформации: миграционном долге, разделении ответственности и управлении изменениями.
Источник
Платформа данных Т-Банка
Разбор эволюции платформы, текущего ландшафта систем и ключевых архитектурных контуров.
В этой главе рассматривается как общий путь от источников к потребителям: , , , , и должны работать как единый . Отдельное внимание здесь получают , , и .
Краткий обзор платформы данных Т-Банка показывает, как архитектура эволюционирует при росте компании: от классического DWH-подхода (Inmon/Kimball) к озеру данных и . На масштабе 17k+ пользователей и 144M+ запросов в месяц платформа превращается в набор специализированных слоёв с явными зонами ответственности.
Масштаб платформы
Период эволюции
18+ лет
Переход от классического DWH к озеру данных и дальше к lakehouse-хранилищу.
Пользователи платформы
17 000+
Инженеры, аналитики и продуктовые команды работают через общий контур данных.
Запросы в месяц
144 млн+
Высокая нагрузка требует постоянной работы над масштабируемостью и задержкой.
Ключевые системы
19
Сквозной жизненный цикл: приём данных, хранение, обработка, управление, наблюдаемость и безопасность.
Архитектурные блоки платформы
Приём и доставка данных
Контур приёма и репликации соединяет OLTP-системы, потоки событий и потребительские дата-продукты.
Data Replication: BODS + Chrono
Исторический пакетный контур и современная потоковая репликация для стабильной доставки изменений.
Event Sourcing: SDP
Платформа потоковой передачи данных, построенная с учётом принципов Data Mesh для доменных событий.
Reverse ETL: Spheradian
Обратная загрузка обогащённых данных в операционные системы с задержкой до 100 мс.
Архитектурные выводы
На масштабе платформы данных не работает одна универсальная СУБД: нужны специализированные контуры хранения и вычислений под разные профили задержки и пропускной способности.
Контракты на данные и наблюдаемость становятся критичными: без них рост числа команд превращает платформу в неуправляемый набор интеграций.
Обратная загрузка данных закрывает разрыв между аналитикой и операционными продуктами: обогащённые признаки должны быстро возвращаться в бизнес-процессы.
Устойчивость платформы обеспечивается не только технологиями, но и организационной ответственностью: явные владельцы, инцидент-процессы и единые стандарты поставки данных.
Практический чеклист
- Разделяйте приём данных, хранение, обработку и управление как отдельные архитектурные слои с явными SLA/SLO.
- Для каждого дата-продукта фиксируйте контракт, владельца и обратную совместимость при изменении схем.
- Планируйте выполнение на нескольких движках заранее: оптимальный движок для пакетной, потоковой и исследовательской аналитики обычно разный.
- Внедряйте управление инцидентами в данных как обязательный процесс, а не как практику после первого крупного сбоя.
Источники
Связанные главы
- Эволюция архитектуры Т-Банка - Как менялся общий архитектурный контур компании и подход к платформенной инженерии.
- Платформы данных в 2025 году: интервью с Николаем Головым - Системные компромиссы построения платформ данных в 2025 году.
- Архитектура конвейеров данных: ETL и ELT - Практика построения контура приёма, преобразования и выдачи данных.
- Apache Iceberg: архитектура таблиц в озере данных - Как открытые форматы таблиц поддерживают lakehouse-хранилища и управляемую эволюцию данных.
- Техношоу «Дропнуто»: выпуск 1 - Практический разбор инцидента в платформе данных и инженерных выводов для эксплуатации.