Эта глава ценна тем, что даёт не абстрактную платформу данных, а живой эволюционный кейс: как большая компания проходит путь от 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 году: интервью с Николаем Головым - Где в построении платформ данных проходят настоящие компромиссы и какие из них приходится выбирать осознанно.
- Архитектура конвейеров данных: извлечение, преобразование и загрузка (ETL) и ELT - Практика построения контура приёма, преобразования и выдачи данных.
- Apache Iceberg: архитектура таблиц в озере данных - Как открытые форматы таблиц поддерживают lakehouse-хранилища и управляемую эволюцию данных.
- Техношоу «Дропнуто»: выпуск 1 - Практический разбор инцидента в платформе данных и инженерных выводов для эксплуатации.