rzv Data Engineering

Новый видос)
2 часа болтали с сеньором DE-SQL-щиком, полная версия на youtube с обратной связью в конце

https://youtu.be/uU8NNP9ckRw

#реклама

Та же Kafka, но без заморочек

Чем больше сервисов в системе — тем быстрее Kafka превращается из помощника в отдельный проект по сопровождению. В Яндексе с этим сталкивались не раз и в итоге сделали YDB Topics — брокер, который по-прежнему понимает Kafka-протокол, но сам масштабируется и встраивается в базу без плясок с бубном.

23 апреля 12:00 по МСК на вебинаре расскажут, как работать без transactional outbox, как топики и таблицы участвуют в одной транзакции и за счёт чего вся эта конструкция не падает при отказах оборудования.

Подключайтесь — будет практика, а не просто обзор возможностей.

#реклама

Поговорим про инженерные платформы и AI?

23 апреля Т-Банк приглашает на Platform Engineering Night. Приходите послушать, как AI помогает автоматизировать процессы, оптимизировать ресурсы и повысить продуктивность платформенных команд.

Что будет в программе:
— Доклады экспертов о применении AI в инженерных платформах.
— Зоны демонстрации AI-решений в платформах.
— Нетворкинг с инженерами и лидерами отрасли.

Встреча пройдет 23 апреля в 19:00 в T-Space по адресу Москва, Грузинский Вал, 7. Доклады можно послушать в онлайне.

Это бесплатно, успейте зарегистрироваться.

"Промежуточный ход" или как можно креативно оптимизировать расчёт витрины 2/2

🔸 И решения для этой проблемы я нашёл два, одно чудеснее другого:
* или рекурсивно вычислять связи, проверяя правила и цепляя запись к мастер-ключу всё более общего кластера
* или сгенерировать все возможные комбинации связей для записи по правилам, а потом уже схлопнуть кластер по общему правилу

Первое было отброшено из-за взрывного роста стадий в движке Trino -- с минимальной указанной вложенностью улетало за 450.
Второе даже работало, пока не вылезла ещё одна особенность данных на источнике:
ПО ОДНОМУ ПРАВИЛУ ВОЗМОЖНЫ ТЫСЯЧИ СОВПАДЕНИЙ, т.к. под "ИНН" tax_id могут скрываться компании, объединения и прочие юридические сущности.

Получаем классический row explosion, когда сотни тысяч записей превращаются в сотни миллионов и миллиарды. Упираемся в лимит с другой стороны. Тупик?

🔸 И тут аналитику нашей команды приходит в голову светлая идея:
* таких "tax_id" с кучей дублей не больше десятка на каждого клиента
* дак давайте сначала отбросим их, посчитаем остальные связи как обычно
* а потом в отдельном потоке посчитаем простым group by + min() и присоединим к остальным через union

🔸 Результат: падение по памяти после 25 минут натужной работы железа сменилось 3.5 минутами в обычном режиме. С полным сохранением логики алгоритма. Красота.

❔А какие у тебя были случаи успешной (или не очень) оптимизации в сфере DE?

#вести_с_полей

"Промежуточный ход" или как можно креативно оптимизировать расчёт витрины 1/2

🔸 Есть задача: сопоставить записи из разных систем и объединить в одну мастер-запись. Где-то процесс называют вычислением "золотой записи" или "мастер-записи", где-то -- матч-мёржингом. В этом тексте пишу о первой половине, матчинге.

Если брать полное совпадение выбранных полей, то задача выглядит просто -- сделать self-join по полям и схлопнуть записи, выбрав ключ "кластера" записей, например как минимальный ключ в группе.

Уровень сложности добавляется, если вспомнить про возможные транзитные зависимости:
это когда если А зависит от В, а В зависит от С, значит А зависит от С.

🔸 На примере клиентов с правилом

(tax_id) or (birth_date and last_name)

Получим, например, следующую цепочку трансформаций:

Hashkey, tax_id , birth_date, last_name
0a00001, 000-000, 1970-01-01, Milchick
0a00002, 000-001, 1970-01-01, Milchick
0a00003, 000-002, 1980-01-01, Scout
0a00004, 000-002, 1980-01-01, S
0a00005, 000-003, 1980-01-01, S

Hashkey, Master_Hashkey
0a00001, 0a00001
0a00002, 0a00001 -- birth_date + last_name
0a00003, 0a00003
0a00004, 0a00003 -- tax_id
0a00005, 0a00004 -- birth_date + last_name

Hashkey, Master_Hashkey
0a00001, 0a00001
0a00002, 0a00001 -- birth_date + last_name
0a00003, 0a00003
0a00004, 0a00003 -- tax_id
0a00005, 0a00003 -- birth_date + last_name -> + tax_id

#вести_с_полей

"Промежуточный ход" или как можно креативно оптимизировать расчёт витрины 1/2

🔸 Есть задача: сопоставить записи из разных систем и объединить в одну мастер-запись. Где-то процесс называют вычислением "золотой записи" или "мастер-записи", где-то -- матч-мёржингом. В этом тексте пишу о первой половине, матчинге.

Если брать полное совпадение выбранных полей, то задача выглядит просто -- сделать self-join по полям и схлопнуть записи, выбрав ключ "кластера" записей, например как минимальный ключ в группе.

Уровень сложности добавляется, если вспомнить про возможные транзитные зависимости:
это когда если А зависит от В, а В зависит от С, значит А зависит от С.

🔸 На примере клиентов с правилом

(tax_id) or (birth_date and last_name)

Получим, например, следующую цепочку трансформаций:

Hashkey, tax_id , birth_date, last_name
0a00001, 000-000, 1970-01-01, Milchick
0a00002, 000-001, 1970-01-01, Milchick
0a00003, 000-002, 1980-01-01, Scout
0a00004, 000-002, 1980-01-01, S
0a00005, 000-003, 1980-01-01, S

Hashkey, Master_Hashkey
0a00001, 0a00001
0a00002, 0a00001 -- birth_date + last_name
0a00003, 0a00003
0a00004, 0a00003 -- tax_id
0a00005, 0a00004 -- birth_date + last_name

Hashkey, Master_Hashkey
0a00001, 0a00001
0a00002, 0a00001 -- birth_date + last_name
0a00003, 0a00003
0a00004, 0a00003 -- tax_id
0a00005, 0a00003 -- birth_date + last_name -> + tax_id

⚡️Как Docker упрощает жизнь аналитиков и инженеров данных

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

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

Что будем делать на вебинаре:
🟠Разберём основы Docker и как контейнеры упрощают работу;
🟠Выполним анализ данных, запустив Python прямо внутри контейнера;
🟠Автоматизируем окружение с помощью Docker Compose (Python + PostgreSQL);
🟠Настроим удобный доступ к результатам анализа;
🟠Организуем ускоренную обработку больших данных.

😶Зарегистрироваться на бесплатный вебинар

Начинаем! Я выступаю вторым, минут через 25-30. Постарался сделать доклад живым и жизненным

p.s. Рассказал, объяснил. Репо можно потыкать самостоятельно здесь: https://github.com/LexxaRRioo/dbt_meetup_2025_march

Outline

нельзя писать в одну таблицу из разных мест
* наивный подход
* с учётом duckdb адаптированного кода
* с учётом зависимостей
* а если нужна разная логика по источникам

работа с макросами
* список, return и {{ }}
* {{ log() if execute }}
* джсон ‘’ и “ ”

юнит-тесты и кодогенерация
* пример конфига
* пример простой модельки генерации метрик
* во что это превращается с юнит тестами

монорепо vs разные репо
* на примере dbt docs
* только важные связи между моделями

Послушать остальные доклады: https://kinescope.io/0cmxcXhvwJvwYbnTLTaDYG

Начинаем! Я выступаю вторым, минут через 25-30. Постарался сделать доклад живым и жизненным

https://kinescope.io/0cmxcXhvwJvwYbnTLTaDYG

Рассказал, объяснил про костыли в DBT.
—> Видео выложено на youtube

Outline

нельзя писать в одну таблицу из разных мест
* наивный подход
* с учётом duckdb адаптированного кода
* с учётом зависимостей
* а если нужна разная логика по источникам

работа с макросами
* список, return и {{ }}
* {{ log() if execute }}
* джсон ‘’ и “ ”

юнит-тесты и кодогенерация
* пример конфига
* пример простой модельки генерации метрик
* во что это превращается с юнит тестами

монорепо vs разные репо
* на примере dbt docs
* только важные связи между моделями

—> Послушать остальные доклады