Привет, Хабр! Меня зовут Дима Пичугин, и уже семь лет я занимаюсь различными компонентами T Data Platform. Эта статья — результат внутреннего аудита наших инструментов, но я подумал, что она может быть интересна не только нашим аудиторам, но и более широкой аудитории. Enjoy!

Платформа данных в Т-Банке существует более 18 лет и за это время прошла значительный путь эволюции. Она помогает более чем 17 тысячам пользователей извлекать из данных ценную информацию для бизнеса. За последние годы подходы к работе с данными заметно изменились: индустрия постепенно отходила от классических концепций хранилищ данных по Инмону и Кимбеллу в сторону Data Lake, а затем — Lakehouse-архитектур. Вместе с отраслью менялась и наша платформа.

В статье расскажу, как трансформировалась T Data Platform за 18 лет развития, и опишу ее текущее устройство — без погружения в технические детали, но с акцентом на общую архитектуру. Для тех, кому интересны отдельные инструменты или решения, оставлю ссылки на подробные материалы и выступления.

Что такое платформа данных

В ИТ-практике под «платформой» чаще всего понимается базовая среда, которая предоставляет разработчикам готовые инструменты, интерфейсы и сервисы. Такая среда упрощает и ускоряет создание и запуск приложений, избавляя команды от необходимости погружаться в детали низкоуровневой инфраструктуры.

T Data Platform выполняет аналогичную роль, но в контексте данных. Data Platform — это технологическое решение, охватывающее весь жизненный цикл работы с данными. Оно выступает в роли центрального хаба для всей экосистемы данных компании: от сбора информации из разных источников до аналитики и практического применения в бизнесе.

Главная задача платформы — сократить time-to-value для аналитиков, обеспечив удобные, масштабируемые и безопасные инструменты для обработки данных. Сегодня такие решения стали стандартом в крупных технологических компаниях и фактически являются неотъемлемой частью бизнеса в его современном виде.

Платформа данных в Т

Несколько цифр о платформе данных в Т:

• Срок существования: > 18 лет (можно покупать алкоголь :woohoo:)

• MAU: > 17 тысяч пользователей

• Объем данных: > 1,7 петабайт уникальных данных в GreenPlum

• Количество таблиц с данными: > 287 тысяч

• Количество запросов к данным в месяц: > 144 млн

Пользователи нашей платформы — не только аналитики. Ее инструменты активно используют разработчики, менеджеры, тестировщики и многие другие. В Т-Банке важно обладать инженерными компетенциями — они требуются и от аналитиков, вне зависимости от их специализации или уровня. 

Покажу на диаграммах, как с платформой взаимодействуют две ключевые пользовательские роли: инженеры данных и аналитики. Не пугайтесь, если будет много незнакомых названий — я расскажу про каждое дальше.

Подробнее о роли инженера в Т-Банке писал мой коллега:

Кто такой data-инженер в Тинькофф и как им стать

Привет! Меня зовут Михаил Иванов, я работаю архитектором DWH в Тинькофф и занимаюсь развитием Batch ...

habr.com

Диаграммы демонстрируют, что пользователи работают с большим числом компонентов платформы, решая широкий спектр разнообразных и часто сложных задач. Для T Data Platform этот факт вкупе с наличием у пользователей сильных инженерных компетенций означает, что платформа должна предоставлять максимально широкий спектр возможностей. Иногда — в ущерб простоте конкретных решений, чтобы сохранить гибкость и силу инструментария для всех категорий пользователей.

Архитектурная диаграмма платформы данных

Диаграмма нарисована на основе структуры Unified data infrastructure 2.0 и включает только те системы, которые были ключевыми в Q1.2025 года. 

Блок Sources

В Sources собраны все возможные источники данных, из которых информация загружается в T Data Platform. Через компонент Ingestion & Transportation в платформу поступают данные более чем из тысячи систем. Их высокая разнородность вынуждает нас иметь широкий набор опций для быстрой и удобной интеграции этих данных в общую экосистему.

Блок Ingestion & Transportation

В блоке Ingestion & Transportation собраны компоненты платформы, которые извлекают данные из операционных систем и передают их в T Data Platform в той же структуре, в которой данные хранились на источнике. При необходимости компоненты загружают аналитические данные обратно в операционные системы для поддержки бизнес-процессов.

Компоненты блока: Data Replication, Event Sourcing и Reverse ETL.

Data Replication — процесс создания и поддержки синхронизированных копий данных в различных системах или хранилищах. Репликация данных включает использование механизмов для отслеживания изменений, своевременного обновления и согласования копий с исходными данными. Это особенно важно для обеспечения оперативного доступа к production-данным при построении аналитики.

Data Replication реализуется системами BODS и Chrono.

BODS (Batch Operational Data Store) — инструмент для пакетной репликации данных из реляционных баз данных (Oracle и Postgres) в Data Platform. В настоящее время BODS считается legacy-инструментом и находится в процессе замены на Chrono.

Основной кейс использования — пакетная (батчевая) репликация таблиц из реляционных баз данных в Data Platform по pull-подходу.

 Технологический стек:

• Бэкенд: Python, Go, C, Flask, FastAPI, SQL Alchemy.

• БД: HardDB.

• Observability: Grafana, Sage, Prometheus.

• Инфраструктура: Docker, K8s, VM, Istio, Postgres, Oracle.

Основная метрика — количество реплицируемых таблиц > 6300.

Chrono — инструмент для потоковой репликации данных из баз данных Postgres в Data Platform в соответствии с Data Contract. Создан как замена BODS, сейчас идет миграция с BODS на Chrono.

Основной кейс использования — потоковая репликация таблиц из Postgres в Data Platform по pull-подходу.

Технологический стек:

• Бэкенд: Java, Quarkus, Kora, Debezium, Spark, Iceberg.

• БД: DBaaS.

• Observability: Grafana, Sage, Prometheus.

• Инфраструктура: Docker, K8s, VM, Istio, Postgres, Kafka, Kafka connect, S3.

Основная метрика — количество реплицируемых таблиц > 500.

Event Sourcing — подход, при котором каждое изменение состояния системы фиксируется как отдельное, неизменяемое событие. Благодаря этому сохраняется полная история всех изменений, а не только текущее состояние данных. В контексте T Data Platform такой подход значительно упрощает анализ и отладку бизнес-процессов, предоставляя всю необходимую информацию для принятия решений.

Event Sourcing реализуется системой SDP — Streaming Data Transfer Platform. 

SDP— внутренняя платформа self-service для доставки и трансформации данных, предназначенная для интеграции и аналитики. Основана на принципах Event Sourcing и Data Mesh и позволяет системе-источнику самостоятельно создавать Data Contract и выгружать данные в заданном формате в Kafka-топик. После этого SDP автоматически обрабатывает и загружает данные в платформу в реляционном виде, удобном для использования.

Основной кейс использования — передача данных операционных систем в Data Platform по инициативе операционной системы (push-подход).

Технологический стек:

• Бэкенд: Java, Quarkus, Kora, Debezium, Spark, Iceberg.

• БД: DBaaS.

• Observability: Grafana, Sage, Prometheus.

• Инфраструктура: Docker, K8s, VM, Istio, Postgres, Kafka, Kafka connect, S3.

Основные метрики:

• Количество потоков поставки данных > 2200.

• Объем данных, загружаемых ежедневно, > 8 ТБ.

Reverse ETL — подход, при котором данные извлекаются из T Data Platform и загружаются в различные операционные системы и бизнес-приложения, чтобы сотрудники могли использовать их в повседневной работе.

Классический ETL перемещает данные в центральное хранилище. Он собирает информацию из разных источников, обрабатывает ее и загружает для последующего анализа.

Обратный ETL действует в обратном направлении: перемещает данные из хранилища в операционные бизнес-системы. Это позволяет использовать уже обработанные, очищенные и структурированные данные непосредственно в рабочих процессах.

Reverse ETL реализуется системой Spheradian.

Spheradian — внутренний инструмент, предназначенный для упрощения доступа операционных систем к признакам, рассчитанным на аналитических данных. 

Инструмент скрывает от пользователя всю сложность Data Platform и служит единой точкой интеграции операционных систем с платформой, а также каталогом существующих интеграционных сценариев. Spheradian обеспечивает доступ к данным с задержкой (latency) до 100 мс, что позволяет использовать продукт в сценариях продакшен-моделей и бизнес-процессов.

Основной кейс использования — применение признаков в операционных процессах, в том числе при обучении и работе c ML.

Технологический стек:

• Хранение данных: Kafka (точка входа), Cassandra (хранилище признаков).

• Доступ к данным: UI (typescript) + API (java).

Основные метрики:

• Количество загруженных признаков > 1500.

• Количество интеграций операционных систем с Spheradian > 400.

Блок Storage

В Storage собраны компоненты платформы, которые позволяют хранить данные в формате, подходящем для аналитики и обеспечивающем оптимальное для платформы сочетание параметров согласованности, производительности, стоимости и масштабируемости

Компоненты Storage: Data Warehouse, LakeHouse, Real-Time Analytics Database

Data Warehouse — подход, который собирает, объединяет и систематизирует большие объемы информации из различных внутренних и внешних источников компании в централизованном хранилище данных, предназначенном для бизнес-аналитики и поддержки обоснованных управленческих решений.

Data Warehouse реализуется системами:

GreenPlum — это распределенная аналитическая база данных на основе PostgreSQL, оптимизированная для массово-параллельной обработки (MPP). Она предназначена для работы с большими объемами данных и выполнения сложных аналитических запросов в режиме реального времени. Ранее GreenPlum распространялся как open source. 

В Т Data Platform GreenPlum является основной СУБД для Data Platform и включает 15 крупных кластеров, вокруг которых создана система сервисов для управления кластерами как единой платформой.

Основной кейс использования — универсальный инструмент, выступающий в роли «швейцарского ножа» и дефолтной СУБД для всех аналитических задач в Т. Применяется практически во всех случаях, за исключением некоторых специализированных сценариев, где используются другие СУБД, например ClickHouse.

Технологический стек: Ansible, Gitlab CI, Python и Golang.

Основные метрики:

• MAU: > 9 500 пользователей.

• Объем данных: > 1,7 петабайт уникальных данных.

LakeHouse — подход, объединяющий возможности Data Lake и Data Warehouse в единой платформе для хранения, обработки и аналитики данных. Он поддерживает хранение как неструктурированных, так и структурированных данных, сочетая масштабируемость и гибкость Data Lake с управляемостью, надежностью и поддержкой ACID-транзакций, присущими Data Warehouse.

LakeHouse реализуется системами Spark/Trino + S3 (Data LakeHouse) и Feature Store. 

Spark/Trino + S3 (Data LakeHouse) — разрабатываемая в Т платформа для гибкого доступа к данным для разных клиентских задач. Она построена с разделением вычислительных ресурсов (compute) и систем хранения данных (storage), что оптимизирует процессы и повышает эффективность работы с большими объемами информации. В качестве хранилища используется объектное хранилище на базе технологии S3 и транзакционный слой метаданных, обеспечивающие надежность и масштабируемость данных.

У платформы несколько вычислительных движков: Spark, Tea и Trino, каждый из них адаптирован под определенные типы задач. Это позволяет пользователям выбирать наиболее подходящий инструмент для аналитики больших данных, машинного обучения или других сценариев обработки.

В отличие от Data Warehouse (например, GreenPlum и его экосистемы), Data LakeHouse спроектирован с учетом масштабируемости вширь, повышенной отказоустойчивости и поддержки разнообразных пользовательских сценариев. В будущем Data LakeHouse планируется заменить GreenPlum как дефолтную СУБД для аналитики в Т, при этом GreenPlum сохранит нишу быстрой аналитики на небольших объемах данных.

Основной кейс использования — дефолтная СУБД для всех аналитических задач в Т. Она будет применяться практически всегда, за исключением некоторых специализированных сценариев, где востребованны другие СУБД, такие как GreenPlum и ClickHouse.

Технологический стек:

• Технологии: Ceph, Hive Metastore, Apache Iceberg, Apache Spark, Trino, Sage.

• Языки: Java, C++.

Основные метрики:

• Объем данных: > 1 петабайта.

• Количество таблиц: > 3 000.

Feature Store — централизованное хранилище признаков (features), предназначенное для обучения ML-моделей. Оно обеспечивает удобное управление, хранение и совместное использование признаков между различными командами и ML-пайплайнами.

Основная цель Feature Store — сократить время выхода моделей в продакшен за счет переиспользования признаков. Этот новый для платформы данных продукт был запущен совсем недавно.

Основной кейс использования — регистрация, хранение и переиспользование признаков в едином каталоге с возможностью поиска, доступа к историческим и обновляемым данным через клиент, а также мониторинга качества и влияния признаков на модели.

Технологический стек:

• Бэкэнд: Java, Arrow Flight, Kora, dbqueue, Iceberg, Parquet, Kyuubi, Trino.

• БД: DBaaS.

• Observability: Grafana, Sage, Prometeus, Proteus.

• Инфраструктура: Docker, k8s, istio, postgres, kafka, s3.

Основные метрики:

• Количество фич > 850.

• MAU > 30.

Real-Time Analytics Database — специализированный тип хранилищ, оптимизированный для быстрой обработки и анализа данных в режиме реального времени. Он обеспечивает высокую производительность за счет поддержки параллельной обработки запросов, потоковой интеграции данных и использования in-memory-технологий, что важно для систем с требованием мгновенного отклика.

Система Real-Time Analytics Database: ClickHouse — это open source столбцовая система управления базами данных для очень быстрой обработки OLAP-запросов на больших объемах данных. 

Основной кейс использования — быстрая аналитика на одиночных больших таблицах, таких как логи, а также построение дашбордов в Proteus.

Технологический стек: Ansible, Gitlab CI, Python и Golang.

Основная метрика MAU > 2 300 пользователей.

Блок Query & Processing

В Query & Processing собраны компоненты платформы, предназначенные для преобразования высокоуровневого кода (обычно на SQL, Python или Java/Scala) в низкоуровневые задачи обработки данных с использованием распределенных вычислений.

Компонент, который входит в блок: Streaming Processing — подход к обработке данных, при котором входящие данные анализируются и преобразуются непрерывно в режиме реального времени по мере поступления, а не пакетной обработкой. Такой метод позволяет мгновенно фильтровать, агрегировать и трансформировать большие потоки данных с минимальной задержкой, что важно для оперативного принятия решений и мониторинга бизнес-процессов.

Streaming Processing реализуется системами: Unicorn и NiFi.

Unicorn — ETL- инструмент, предназначенный для решения большинства задач обработки потоковых данных. Целью разработки было создание надежного продукта для построения сложных потоков данных в режиме near real time с минимальным порогом входа. Важно, чтобы пользователи могли сосредоточиться на бизнес-задачах, а не на технических деталях инструмента. 

В основе Unicorn ETL лежит Apache Flink, функциональность которого значительно расширена, а интерфейс упрощен для удобства пользователей.

Основной кейс использования — потоковая обработка и сложные преобразования данных (фильтрация, объединение, агрегация) в режиме near-real-time.

Технологический стек: Apache Flink. 

Основная метрика — количество потоков данных > 90.

NiFi — open-source-инструмент для потоковой и микробатч-загрузки данных из различных источников. Он предоставляет удобный интерфейс для создания потоков данных с помощью диаграмм потоков. В Т Data Platform используется доработанная версия NiFi, поддерживающая работу с нашими источниками данных и предоставляющая расширенный набор процессоров для обработки данных и среду для создания, тестирования и доставки потоков в production.

Основной кейс использования — загрузка данных произвольного формата в T Data Platform из слабо структурированных источников с минимальным написанием кода.

Технологический стек: Java, Spring.

Основная метрика — количество потоков данных > 450.

Блок Transformation

В блоке Transformation собраны компоненты платформы, предназначенные для преобразования данных в структуру, готовую к использованию в аналитике и для оркестрации необходимых ресурсов.

Компонент блока: Workflow Manager — специализированный инструмент для автоматизации и оркестрации процессов обработки данных. Он позволяет управлять последовательностью выполнения задач и их зависимостями, обеспечивая централизованное планирование, мониторинг и контроль выполнения ETL-процессов

Workflow Manager реализуется системами: TEDI и Moebius.

TEDI — ETL-инструмент на базе Apache Airflow, предназначенный для создания и поддержки пакетных процессов загрузки, обработки и выгрузки данных. Инструмент предоставляет полноценную IDE для инженеров данных, полностью покрывающую все этапы процесса разработки потоков данных.

Основной кейс использования инструмента — пакетная обработка и сложные преобразования данных.

Технологический стек:

• Бэкенд: Airflow, Python, FastAPI.

• БД: SQL Alchemy, PostgreSQL DBaaS, Redis.

• Фронтенд: React.

• Observability: Grafana, Sage, K8s, Prometheus.

• Инфраструктура: K8s.

Основная метрика — количество потоков данных > 9 000.

Moebius — это Workflow Manager, разработанный специально для инфраструктуры и процессов T и ежедневно оркестрирующий десятки тысяч потоков данных из наших ETL- и BI-инструментов.

Основной кейс использования инструмента — управление цепочкой событийных запусков взаимозависимых потоков данных.

Технологический стек:

• Бэкенд: Python: FastAPI, Faust-streaming.

• БД: SQL Alchemy, DBaaS.

• Фронтенд: React, React-Query, Vite.

• Observability: Grafana, Sage, K8s, Prometheus.

• Инфраструктура: Docker, K8s, VM, Istio, Kafka.

Основная метрика — количество ежедневно запускаемых потоков данных > 20 000.

Блок Analytics & Output

В Analytics & Output собраны компоненты платформы, которые предоставляют пользователям T Data Platform удобный интерфейс для аналитики и других сценариев работы с данными.

Компоненты блока: Dashboards, Data Workspace

Dashboards — специализированный инструмент, который собирает и визуализирует ключевые показатели и метрики в интерактивном графическом интерфейсе. Его главная ценность — возможность наглядно представить сложные данные, чтобы быстро принимать обоснованные решения.

Dashboards реализуется системой Proteus — это BI-инструмент на базе Apache Superset, разработанный для замены Tableau и предназначенный для создания интерактивных дашбордов на данных T Data Platform. Он облегчает принятие стратегических и оперативных решений сотрудниками на основе большого объема доступных данных.

Основной кейс использования инструмента — создание интерактивных и удобных дашбордов для визуализации ключевых бизнес-показателей и поддержки управленческих решений.

Технологический стек:

• Веб: WSGI Gunicorn, Flask и SSR.

• Фронтенд: React v16, Redux v4 и webpack.

• БД: PostgreSQL 14, DBaaS и SQLAlchemy.

Основные метрики:

• MAU > 17 000.

• Количество дашбордов > 10 000.

Data Workspace — интегрированная среда для совместной работы и взаимодействия дата-сайентистов, аналитиков, дата-инженеров и бизнес-пользователей — основных ролей, которые извлекают ценность из данных. 

Data Workspace представляет собой слой интеграции существующих платформенных решений, призванный упростить для пользователей ключевые сценарии работы с данными: исследование, моделирование, трансформацию, визуализацию и взаимодействие.

Data Workspace реализуется системой Helicopter — cloud-native-вычислительная платформа с расширенными возможностями для совместной работы команд, занимающихся исследованиями и операционализацией данных: построением аналитики, ETL-процессов, отчетов и data-приложений. Ближайшие аналоги продукта — JupyterLab, Apache Zeppelin, Google Colab и Hex.tech.

Основной кейс использования инструмента — выполнение ad-hoc-аналитики, создание регламентных процессов и автоматизаций на Python из ноутбуков, а также организация self-service ETL-процессов.

Технологический стек: Spring boot 3, Java 21, Kotlin, React/Typescript/WASM; Gitlab CI/CD.

Основные метрики:

• MAU > 12 000.

• DAU > 5 000.

• Количество ноутбуков > 650 000.

Блок Governance

В блоке Governance собраны компоненты платформы, обеспечивающие сквозное управление и контроль над корпоративными данными на всех этапах их жизненного цикла.

Компоненты блока: Data Discovery, Data Governance, Data Observability и Data Security. 

Data Discovery — процесс поиска, исследования и анализа данных в условиях множества и разнообразия источников информации, возможный только при условии, что организация провела работу по идентификации, каталогизации и классификации данных, доступных для компании.

Data Discovery реализуется системой Data Detective — каталог данных, обеспечивающий поиск и централизованный доступ к ним. Его задача предоставить единую точку для поиска, доступа и обмена данными внутри компании. Основная функция инструмента — находить информацию о данных и их характеристиках. Ближайшие известные аналоги — DataHub и OpenMetadata.

Основной кейс использования инструмента — простой и общедоступный поиск данных в T Data Platform с возможностью получения подробной информации об объектах данных, включая описание, владельца, Data Lineage и другие характеристики.

Технологический стек: Python, Postgres, Kotlin, React.

Основные метрики:

• MAU > 5 600.

• Количество карточек метаданных > 7 000 000.

Data Governance — подход, включающий всю совокупность правил, процессов, политик и технологий для управления жизненным циклом данных, обеспечения их качества, безопасности и соответствия нормативным требованиям. Он включает распределение ролей и ответственности, определение стандартов обработки, хранения и доступа к данным, а также внедрение механизмов контроля и аудита, что гарантирует целостность и надежность информации.

Data Governance реализуется системой Data Contracts — это система, служащая центральной точкой управления обменом данных между T Data Platform и системами — источниками данных. Контракт— важный элемент концепции Data Mesh, обязательный при создании новой поставки данных в T Data Platform. Помимо каталогизации продукт устанавливает четкие границы ответственности и определяет ожидания между заинтересованными сторонами (например, зоны ответственности, структуру данных, SLA и другие параметры).

Основной кейс использования инструмента — создание поставок данных в Data Platform в соответствии с едиными стандартами и требованиями надежности.

Технологический стек: GitLab, GitOps, Kotlin.

Основная метрика — количество контрактов > 3 700.

Data Observability — процесс, который позволяет организации иметь полную видимость состояния своего ландшафта данных за счет непрерывного сбора, консолидации и анализа алертов с разных уровней зависимостей. Это дает возможность выявления, контроля, предотвращения, эскалации и устранения сбоев в работе данных в рамках установленных SLA.

Data Observability реализуется системами: DQ Tools и Data Incident Management.

DQ Tools — портал, объединяющий инструменты контроля качества данных. Он предоставляет широкие возможности для управления и разработки проверок качества данных и состоит из трех основных компонентов:

1. Data Metrics — продукт для систематизации проверок качества данных и единое место хранения информации о качестве данных в T Data Platform. 

2. Data Checker — python-библиотека, основанная на open-source-решении Soda Core, которая упрощает разработку проверок качества данных. 

3. Severity — продукт для хранения, управления и контроля соглашений об актуальности объектов данных в T Data Platform.

Основные кейсы использования инструмента — контроль и анализ качества и актуальности данных в таблицах T Data Platform, разработка и каталогизация конкретных проверок качества и актуальности данных.

Технологический стек: Python, React, Kotlin.

Основная метрика — количество DQ проверок > 34 000.

Data Incident Management — единый инструмент управления инцидентами, разметки бизнес-процессов и оценки их критичности. Он содержит инструменты оповещения о сбоях, обеспечивает прозрачность работы с инцидентами и состоянием дата-пайплайна, помогает разграничить ответственность при их решении, предоставляет статистику и аналитику по инцидентам. А еще позволяет корректно размечать критичность данных и обеспечивать соответствующий уровень поддержки.

Основные кейсы использования инструмента — траблшутинг и решение инцидентов с данными, разметка и согласование их критичности, обеспечение информирования, прозрачности и аналитики по инцидентам.

Технологический стек: Python, Prometheus, PostgreSQL, Kafka, K8s.

Основные метрики:

• Количество дата-процессов в инструменте: 187.

• Количество бизнес-линий, использующих инструмент: 16.

Data Security — подход, включающий всю совокупность политик, процессов, технологий и мер контроля, направленных на защиту данных от несанкционированного доступа, утечек, изменений или уничтожения. Data Security применяет современные методы шифрования, управления доступом, мониторинга и обнаружения угроз, что обеспечивает целостность, конфиденциальность и доступность информации в корпоративной инфраструктуре.

Data Security реализуется системой SLH (SensLabelHub) — сервис централизованного хранения и управления разметкой данных по чувствительности в Data Platform. Он определяет применяемые к данным политики доступа и защиты во всех системах T Data Platform.

Основные кейсы использования инструмента — автоматическое и консистентное применение политик доступа и защиты данных к схемам, таблицам и полям на основе разметки, анализ и контроль чувствительных данных в T Data Platform.

Технологический стек: 

• Бэкенд: Kotlin, Kora, JDBC, Liquibase, JUnit.

• БД: PostgresSQL 15. DBaaS.

• Observability: Grafana, Sage, K8s, OpenTelemetry, Prometheus.

• Инфраструктура: Docker, K8s, VM, Istio, Kafka.

Основные метрики:

• Количество таблиц с чувствительной информацией в T Data Platform > 8 250.

• Количество столбцов с чувствительной информацией в T Data Platform > 22 000.

Вместо итогов

Любая платформа данных — это сложное решение, состоящее из множества компонентов. В крупных компаниях она, как правило, еще сильнее усложняется и обрастает большим количеством функциональностей, необходимых самым разным группам пользователей. 

Мы этого тоже не избежали: даже в кратком описании структуры T Data Platform фигурирует 19 систем, при этом многие из них остались вне рамок данной статьи. 

Оглядываясь назад, могу с гордостью сказать, что мы построили действительно впечатляющий продукт. Гордость лишь усиливалась по мере написания этой статьи и полного осознания всего масштаба T Data Platform. 

Самой сложной задачей было не превратить статью в книгу, а ограничиться лишь самой необходимой для описания общей структуры платформы информацией. Буду надеяться, что мне это удалось и вам было интересно прочитать этот обзор. Если у вас появились вопросы — добро пожаловать в комментарии!

Больше информации про T Data Platform

• 2015: Habr: Greenplum DB

• 2015: Habr: Data Lake — от теории к практике. Сказ про то, как мы строим ETL на Hadoop

• 2015: Habr: Проект Dual ETL, или Как мы строили Disaster Recovery для GreenPlum

• 2016: Habr: Тестирование хранилищ данных

• 2019: HighLoad: Как Tinkoff.ru использует Greenplum

• 2020: Код Желтый: Организация потока

• 2020: Код Желтый: Кастомизация NiFi

• 2021: Habr: Как QA в управлении хранилища данных эволюционировал

• 2021: Код Желтый: Альберт Айткулов, Тинькофф — GitLab CI + Clickhouse = DevOps

• 2021: SmartData: Инициирующая загрузка в NiFi

• 2021: DE or DIE: NiFi. Как загрузить данные в GreenPlum и не убить его

• 2021: Habr: Как проходит интервью с системными аналитиками DWH в Тинькофф

• 2022: SmartData: Свой ETL инструмент — это реально

• 2022: SmartData: Как построить Data Lineage. Обзор решений и опыт нашей команды

• 2022: SmartData: Как продуктовый дизайн влияет на разработку ETL-платформы

• 2022: SmartData: How to load everything in the data catalog and not to die

• 2022: SmartData: Как мы пустили пользователей строить свой ETL

• 2022: Habr: Кто такой data-инженер в Тинькофф и как им стать

• 2022: Habr: Как в Тинькофф создавали Data Catalog

• 2022: Habr: Как мы используем Greenplum в платформе данных Тинькофф

• 2022: VC: Знакомьтесь Data Detective — каталог данных от Тинькофф

• 2024: Код Желтый: Митап Tinkoff DWH Connect

• 2024: Т-Образование: Proteus

• 2024: Технологии в Тинькофф: Data Detective

• 2024: SmartData: Инструменты Data Quality: как, зачем, почему. Опыт Т-Банка

• 2025: Код Желтый: Как мы сделали BI-инструмент стабильнее, хотя пользователей стало на 104% больше

• 2025: Технологии в Тинькофф: Helicopter

• 2025: Код Желтый: Data завтрак