Гайд ролей BI разработчиков в Amazon

Краткий обзор платформы данных Т-Банка (Рубрика #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, но все они одинаково плохо работали для меня из коробки.