Краткий обзор платформы данных Т-Банка (Рубрика #Data)

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

1. Сбор и транспортировка данных
- Data Replication: BODS (legacy) и Chrono для пакетной и потоковой репликации
- Event Sourcing: SDP (Streaming Data Transfer Platform) на основе принципов Data Mesh
- Reverse ETL: Spheradian для возврата данных в операционные системы с латентностью до 100 мс
2. Хранение данных
- Data Warehouse: GreenPlum как основная СУБД (15 кластеров, 1,7 ПБ данных)
- LakeHouse: Spark/Trino + S3 с несколькими вычислительными движками
- Real-Time Analytics: ClickHouse для быстрой аналитики на больших таблицах
3. Обработка и трансформация
- Streaming Processing: Unicorn (на Apache Flink) и NiFi
- Workflow Management: TEDI (на Apache Airflow) и Moebius для оркестрации
- Analytics Tools: Proteus (на Apache Superset) для дашбордов и Helicopter для совместной работы
4. Управление данными
- Data Discovery: Data Detective для поиска и каталогизации
- Data Governance: Data Contracts для управления поставками данных
- Data Observability: DQ Tools для контроля качества и Data Incident Management
- Data Security: SLH для управления доступом к чувствительным данным

Если хочется узнать больше, то можно почитать статью и позадавать вопросы в комментариях.

#Data #Database #Architecture #Software #Engineering #PlatformEngineering

Сегодня выступил удаленно на митапе Юmoney в Питере про dbt, презентация https://docs.google.com/presentation/d/17deTqSeuSjHIVLIWxQ3QIt40o9gKL8k6bmg1WxtPmcU/edit?usp=sharing

Пример репозитория: https://github.com/dimoobraznii1986/dbt_workshop_vk/tree/main/models

Если есть вопросы, пишите в комментах.

В комментарии к прошлому посту был вопрос:

В ETL-процессе на стадии Transform имеем много DAG’ов с большой Python-логикой, основанной на Pandas, внутри от аналитиков данных. В итоге такой типичный DAG занимает 30–50 ГБ RAM в Airflow и может отрабатывать несколько часов. Как такие DAG’и с Python внутри переносить на dbt?

Паттерн использования Airflow, чтобы выполнять Python (Pandas и т.п.), очень понятен и удобен, особенно если вы делаете пет-проекты, изучаете Airflow или Python. Возможно, это хороший вариант для небольшого MVP, но в продакшн лучше такое не тащить. У нас получается монолит, который трещит по швам, и из-за плохого запроса может всё упасть.

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

На всякий случай для читателей - Airflow - это инструмент оркестрации. Он создан для того, чтобы запускать наши data pipelines (jobs) по расписанию. Это очень популярный инструмент в мире, и прям number one в РФ среди open-source инструментов. Его назначения - запускать задачи по расписанию.

Из-за того, что DAGs (jobs) мы пишем на Python, так и хочется сразу всё сделать внутри одного job. Но лучше так не делать.

Какие есть альтернативы? Конечно, среди них есть и dbt, но мы же не хотим на том же самом инстансе запускать dbt, где только что был Pandas.
1. Вместо Pandas можно попробовать PyArrow, Polars или DuckDB (pyduck) — просто ради интереса сравнить потребление памяти. Но в любом случае, мы не хотим запускать вычисления там же.
2. Вопрос про то, как мы хостим Airflow? Мы же можем использовать Managed Airflow в отечественном облаке, можем хостить на виртуальной машине, в контейнере или в поде (Kubernetes).
3. Например, если мы хотим дать возможность запускать Python/Pandas/DuckDB-скрипты, то нам всё равно нужно место, где это делать. Один из вариантов — использовать паттерн, в котором каждая программа (job/DAG) будет выполняться в своём контейнере. Например, мы запускаем DAG, а в нём task запускает Pod/Container с нашей логикой. Если не хватит памяти, то на Airflow это никак не повлияет.

Точно так же и dbt. Самый главный вопрос — где будет compute, который будет запускать dbt? В случае контейнеров и подов, можно просто запустить Airflow DAG, который возьмёт образ с dbt из регистра и запустит его.

А сама миграция с Pandas на dbt — это по сути миграция Pandas DataFrames на SQL. В dbt будет легче организовать модели (SQL-файлы), установить naming standards, добавить тесты и документацию. Появится lineage и зависимости.

Я, конечно, могу ошибаться, но когда я слышу про Pandas в проде - это мне напоминает «куяк-куяк — и в продакшн, потом починим»

А как у вас с custom Python, где вы его выполняете и что делаете, когда не хватает памяти?

Сейчас во многих компаниях проводится quarterly performance reviews - то есть оценка вашей производительности как аналитика, менеджера, инженера.

Как правило, мы сами себе готовы поставить самый высокий балл из возможных, но менеджер вряд ли согласится с таким раскладом и в лучшем случае скажет meet expectations — типа всё оки, работаем дальше.

Как же быть в такой непростой ситуации?

* всегда документируйте свои достижения
* создавайте артефакты - документация, playbooks, технические документы (System Design), документы по принятию решений (DACI/RAPID)
* перед началом цикла уточните, каким образом можно будет измерять ваши цели, на что обращает внимание руководство
* во время каждой встречи 1:1 используйте время, чтобы оценить прогресс по вашим целям
* ищите возможность взять дополнительную ответственность, а главное - облегчить жизнь вашего линейного руководителя

Это базовые вещи, о которых мы часто забываем. Опасность кроется в другом - я называю это false expectations, когда мы сами себе придумываем цели и результат, много работаем на достижение этих целей, а потом оказывается, что это никому не нужно. Как результат - выгорание, потеря вовлечённости, поиск новой работы. Что вообще-то всегда хорошо лично для вас, потому что job security это миф.

Поэтому перед вами развилка - вы хотите играть в эту игру по корпоративным правилам, где важней видимость вашего труда, где есть конкретный impact на бизнес‑задачу в ущерб всему остальному. Или вы просто работаете в комфортном для вас режиме без каких-либо ожиданий.

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

* Вам нужно установить чёткие цели для команды и для каждого инженера в отдельности. Цели должны быть измеримы и иметь чёткий impact на бизнес, даже если мы говорим про обработку 50 гигабайт данных в оперативной памяти с помощью Pandas.
* 1:1 ‑ встречи - ваш главный инструмент для отслеживания и корректировки целей. Вам важно контролировать ситуацию, чтобы на performance review не было сюрпризов, которые потом выльются в увольнение инженеров.
* Общайтесь с другими департаментами, чтобы лучше понимать фидбек о вашей команде и инженерах
* Во время процесса оценки лучше разделить личностный рост и рост компенсации — не смешивайте эти две вещи
* Имейте чёткую карьерную лестницу с уровнями и ожиданиями от инженеров и помогите разобраться в ней вашим инженерам
* Старайтесь избегать эмоциональных ответов и прокачивайте soft skills. Если инженеру ещё простительно ляпнуть ерунду, то менеджеру уже нет.
* К сожалению, как и в HR, менеджеру важно думать, что будет хорошо для компании, а не для инженера
* Обязательно постарайтесь найти бюджет на команду, чтобы отправить их на курсы, конференции
* Найдите бюджет на team building - желательно не поход в кино, а недельную поездку к морю или экспедицию на Дальний Восток
* Если инженер себя переоценивает (все мы bias), то лучше сразу привести пример, почему он не прав
* При любом удобном случае хвалите команду
* Всегда учитесь, теперь вам надо понимать не только технические аспекты решения, но и психологию, эмоциональный интеллект. Читайте профессиональную литературу и прокачивайте soft skills.

Пока мы фиксим Airflow DAGs, учимся не страдать и не выгорать на работе, тут такие страсти происходит, каких наверно data сообщество еще не встречало. Ну хоть какой-то движ в вендорах. Из последнего только Fivetran купил Census:)

Презентация про Snowflake Cortex AI, в который вы найдете AI возможности платформы Snowflake.

Все у кого есть снежинка трудятся над их внедрением, я пробовал некоторые из решений GenAI, ML, но все они одинаково плохо работали для меня из коробки.

Как вы там осваивает vibe coding?

Смотря что понимать под вайб-кодингом. Если попытки делать сервисы, не имея ни малейшего технического кругозора и желания его получить, то нет - это тупик. Всегда говорю - если нейронка генерит тебе за раз больше 1-2к строк кода, то чаще всего лучше выкинуть этот код. Не потому что он плохой, а потому что ты, скорее всего, тупо не успеешь его переварить и окрылённый первыми успехами ("работает!") начнёшь наслаивать новые огромные куски. По итогу снежный ком, который тебя переедет. Потому что самое важное для меня - не отпускать чувство контроля над происходящим в моей же кодовой базе. Иначе (замечаю часто у Claude при всей её прелести) каждая новая просьба что-то исправить будет оборачиваться не исправлением существующего, а набрасыванием новых 300-400 строк кода. Я молчу про ситуацию, она очень частая, когда происходит сбой и нейронка переписывая огромный кусок попутно выпиливает нужные куски или тупо не дописывает новые - и как тут быть, если ты не контролируешь ситуацию, пребывая на чилле?

Совершенно другое для меня дело, когда с помощью вайб-кодинга ты подступаешься и буквально за несколько часов внедряешь фичи, о которых раньше мог только мечтать (не потому что фичи не подступные, а потому что у тебя никак не было времени сесть и подтянуть матчасть, чтобы вообще понять, с какой стороны заходить).

Вчера буквально была такая маленькая победа (для меня так, пусть и вызовет у опытных улыбку). Надо было очень быстро впилить TOTP-аутентификацию (те самые сгорающие 30-cекундные числовые пароли). Никогда я этого не касался, а благодаря нейронке страх пропал.

1. Сначала минут 30 поговорил с ней о том, как вообще устроена эта аутентификация. На выходе получил чёткое представление, при этом не боясь задавать кучу "глупых" вопросов, на которые сразу получил нужные ответы.

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

3. Почитав это саммари и поняв, что в голове пазл складывается (для меня это главный маркер, если звучит логично, то в 99% случаев всё будет работать) попросил сразу написать весь набор тестовых сценариев. Чтобы ещё не приступая к фронту, через командную строку поделать запросы и убедиться, что сервер ведет себя ожидаемо (не принимает просроченные TOTP, принимает свежие пароли и т.д.).

Все тесты отработали как надо и тогда я уже двинулся к фронтенду. Сердце спокойно - на бэке все крутится.

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

4. Пошёл делать фронт по тем же принципам что и бэк. С фронтом было заковыристее конечно. Тут реально глаз да глаз за нейронкой.

До прода не докатил ещё, ушёл на юбилей к другу, но локально всё работает как надо и сделано это где-то за 3-4 часа.

И это кайф. На этом примере я прям кожей почувствовал, что я работал с крутым напарником. Быстро, качественно. Нам не нужны были подмастерья, нам не нужны были тестировщики, нам не нужны были бесконечные стыки между командами бэка и фронта. Просто сели и сделали. Я впервые реально понял, что резать расходы на IT-персонал за счёт активного внедрения нейронок - это правильно, если они в правильных руках. Я реально не смог найти ни одного аргумента в пользу того, а зачем мне"живые" напарники при решении сегодняшней задачи.

Резюме. Ленивому, бездумному, не желающему вникать в суть логики и инструментов вайб-кодингу - бой. А вот осознанному, контролируемому, критически оцениваемому на каждом этапе - только зелёный свет.

Сорян за много букв, я ещё отхожу от юбилея друга и, что называется, "накатило" 😊

🐚 Обсудим AI для разработчиков c Яндексом

27 июля пройдёт AI Dev Day — первый митап Яндекса на эту тему. Мы обсудим, как AI-агенты ускоряют процессы, помогают разработчикам работать с кодом и автоматизировать рутинные задачи.

Это будет интересно разработчикам, которые ищут способы побороть рутину и писать код эффективнее.

Для этого мы подготовили 2 формата обмена опытом:

🟠 Доклады об инструментах AI Productivity. Спикеры расскажут, как внедрять AI в команды разных направлений и в каких случаях в этом нет необходимости

🟠 Lightning talks. Короткие выступления тех, кто попробовал AI в реальных проектах и готов подсветить свои успехи, провалы и актуальные инсайты

⏭️ Посмотреть программу и зарегистрироваться можно здесь: https://clck.ru/3NDjiV/?erid=2VtzqwKqzwr