Источник
Платформа данных Т-Банка
Разбор эволюции платформы, текущего ландшафта систем и архитектурных контуров.
Краткий обзор платформы данных Т-Банка показывает, как data platform эволюционирует при росте компании: от классических DWH-подходов (Inmon/Kimball) к Data Lake и Lakehouse. На масштабе 17k+ пользователей и 144M+ запросов в месяц архитектура превращается в набор специализированных слоев, где ingestion, storage, processing и governance проектируются как единая платформа.
Масштаб платформы
Период эволюции
18+ лет
Последовательный переход от классического DWH к Data Lake и далее к Lakehouse.
Пользователи платформы
17 000+
Инженеры, аналитики и продуктовые команды используют единый data contour.
Запросы в месяц
144 млн+
Высокая нагрузка требует постоянной работы над масштабируемостью и latency.
Ключевые системы
19
Сквозной lifecycle: от ingestion и processing до governance, observability и security.
Архитектурные блоки платформы
Сбор и транспортировка данных
Контур ingest/replication, который соединяет OLTP, event streams и downstream data products.
Data Replication: BODS + Chrono
Исторический batch-контур и современная потоковая репликация для стабильной доставки изменений.
Event Sourcing: SDP
Streaming Data Transfer Platform, построенная с учетом принципов Data Mesh для доменных потоков.
Reverse ETL: Spheradian
Возврат обогащенных данных обратно в операционные системы с задержкой до 100 мс.
Архитектурные выводы
На масштабе data platform не может быть одной универсальной СУБД: нужны специализированные storage/compute контуры под разные latency и throughput профили.
Data Contracts и observability-контур становятся критичными: без них рост числа команд превращает платформу в неуправляемый набор интеграций.
Reverse ETL закрывает разрыв между аналитикой и операционными продуктами: данные должны возвращаться в business-flow почти в реальном времени.
Устойчивость платформы обеспечивается не только технологиями, но и организационным ownership: явные owners, инцидент-процессы и единые стандарты поставки данных.
Практический чеклист
- Разделяйте ingestion, storage, processing и governance как отдельные архитектурные слои с явными SLA/SLO.
- Для каждого data product фиксируйте contracts, owner и обратную совместимость при изменении схем.
- Планируйте multi-engine execution заранее: оптимальный движок для batch, stream и ad-hoc аналитики обычно разный.
- Внедряйте data incident management как обязательный процесс, а не post-factum практику после первого крупного сбоя.
Связанные главы
Эволюция архитектуры Т-Банка
Как менялся общий архитектурный контур компании и platform engineering подход.
Data platforms: интервью с Николаем Головым
Системные компромиссы построения data platform в 2025 году.
Data Pipeline / ETL / ELT Architecture
Практика построения ingestion/transform/serving контура.
Apache Iceberg: архитектура таблиц в data lake
Как open table formats поддерживают lakehouse-подход и эволюцию данных.
Техношоу «Дропнуто»: выпуск 1
Практический разбор инцидента в data-платформе и lessons learned для эксплуатации.