rzv Data Engineering

Привет, делюсь папкой дата инженерных каналов с интересным контентом.
Заходи к нам на вечеринку по ссылке: https://t.me/addlist/a1B07iwrPxUxNWIy

#поразмыслим

Проблема "дрейфующих" первичных ключей при объединении данных из разных систем

🔸 Допустим, есть 10 разных однотипных источников о клиентах, из которых нужно получить по 1 записи о каждом "реальном" клиенте.

Для решения такой задачи есть процессы "матчинга" и "мёржинга". В первом случае сопоставляем строки между собой и формируем "кластер" записей. Во втором — схлопываем в одну "золотую" запись, выбирая самый полный набор атрибутов из самых достоверных источников. Я уже писал выше про ``splink`` как один из python пакетов, на которых можно такое реализовать.

🔸 Но что делать с ключами? Если выбирать "главную" запись в кластере и делать, например, расчёт хэша на основе её хэша, на первый взгляд всё хорошо.

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

🔸 А что если эта "главная" запись удалится, а остальные — продолжат формировать кластер? Как сохранить итоговый ключ, чтобы сохранить историю изменений?

И на основе чего его можно считать, если у нас нет надёжного набора бизнес-ключей, по которым мы можем гарантировать, что эти записи — об одном человеке. И запись из любого источника может удалиться или "перенестись" в другой кластер при изменении правила матчинга.

Более подробный пример будет в комментах внутри

Ставь 🐘 или ⭐️, если хочешь больше сеньорных постов

#поразмыслим

Проблема "дрейфующих" первичных ключей при объединении данных из разных систем

🔸 Допустим, есть 10 разных однотипных источников о клиентах, из которых нужно получить по 1 записи о каждом "реальном" клиенте.

Для решения такой задачи есть процессы "матчинга" и "мёржинга". В первом случае сопоставляем строки между собой и формируем "кластер" записей. Во втором — схлопываем в одну "золотую" запись, выбирая самый полный набор атрибутов из самых достоверных источников. Я уже писал выше про ``splink`` как один из python пакетов, на которых можно такое реализовать.

🔸 Но что делать с ключами? Если выбирать "главную" запись в кластере и делать, например, расчёт хэша на основе её хэша, на первый взгляд всё хорошо.

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

🔸 А что если эта "главная" запись удалится, а остальные — продолжат формировать кластер? Как сохранить итоговый ключ, чтобы сохранить историю изменений?

И на основе чего его можно считать, если у нас нет надёжного набора бизнес-ключей, по которым мы можем гарантировать, что эти записи — об одном человеке. И запись из любого источника может удалиться или "перенестись" в другой кластер при изменении правила матчинга.

Более подробный пример будет в комментах внутри

Ставь 🐘 или ⭐️, если хочешь больше сеньорных постов

rzv Data Engineering pinned a photo

#термин_дня

Версионирование данных при работе с дата лейком

Листая ленту, наткнулся на любопытный инструмент: https://projectnessie.org/

Работает с Iceberg и даёт возможность работать с данными как с кодом:
. отводить отдельные ветки для отладки фичей
. версионирование
. транзакционное изменение пачки файлов (acid-like)

При этом обещают, что разделять пространство на разные "контура" дев-тест-прод и ветки можно без копирования данных -- только на уровне "диффов изменений"

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

#термин_дня

Версионирование данных при работе с дата лейком

Листая ленту, наткнулся на любопытный инструмент: https://projectnessie.org/

Работает с Iceberg и даёт возможность работать с данными как с кодом:
. отводить отдельные ветки для отладки фичей
. версионирование
. транзакционное изменение пачки файлов (acid-like)

При этом обещают, что разделять пространство на разные "контура" дев-тест-прод и ветки можно без копирования данных -- только на уровне "диффов изменений"

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

(само-) #реклама

Занимай активную позицию по отношению к карьере в самом начале 2025-го!

🎆 Для новых и возвращающихся подписчиков делюсь промо-ссылкой на бусти чат. В нём помогаем друг другу развиваться в сфере дата инжиниринга с самых разных уровней -- есть что и с кем обсудить и "вкатунам", и сеньорам, и всем между ними)

🎁 Первая сотня шустрых людей получит доступ на 2 дня ко всем 19 тредам чата (на картинке показана только часть).

☕️ Взгляни на историю сообщений и текущее общение, почувствуй атмосферу и реши, хочешь остаться с нами или нет ;)

>>> Успей перейти по ссылке

Итоги года 2024

Спасибо всем и каждому, кто пришёл и остался читать канал.
Удалось пройти немаленький путь за год существования канала, но верю, что самое интересное ещё впереди.
Вместе мы продвинем знание об инженерии данных в массы :)

Это канал про DE, поэтому держи немного сухих данных.

🔸 Сводка за год:
Подписчиков: 1368
Постов: 253
Среднее кол-во просмотров: 866.5
Максимум просмотров: 4852
Рекорд постов за день: 15 (2024-01-21)

🔸 Топ тегов:
#термин_дня: 38
#зачем_нужно: 25
#вести_с_полей: 13
#поразмыслим: 12
#реклама: 11 (спасибо за поддержку)

🔸 Самые популярные серии постов за год (по просмотрам):
https://t.me/rzv_de/228
https://t.me/rzv_de/257
https://t.me/rzv_de/175
https://t.me/rzv_de/241
https://t.me/rzv_de/244
https://t.me/rzv_de/183
https://t.me/rzv_de/233
https://t.me/rzv_de/213
https://t.me/rzv_de/248
https://t.me/rzv_de/224

Также около 15 человек получилось довести до оффера (тыкаю их в переписке, чтобы внесли инфу в стату и попали в дашборд, а то никто ж не поверит), нескольким десяткам людей помог консультациями, вырастил закрытое бусти сообщество до 60 человек, дважды сменил работу с ростом ЗП х3.5

p.s. а вообще, в начале пути выпустил много маленьких полезных постов, пролистай на праздниках -- меню "сэндвич", "go to the beginning" ;)

Итоги года 2024

Спасибо всем и каждому, кто пришёл и остался читать канал.
Удалось пройти немаленький путь за год существования канала, но верю, что самое интересное ещё впереди.
Вместе мы продвинем знание об инженерии данных в массы :)

Это канал про DE, поэтому держи немного сухих данных.

🔸 Сводка за год:
Подписчиков: 1368
Постов: 253
Среднее кол-во просмотров: 866.5
Максимум просмотров: 4852
Рекорд постов за день: 15 (2024-01-21)

🔸 Топ тегов:
#термин_дня: 38
#зачем_нужно: 25
#вести_с_полей: 13
#поразмыслим: 12
#реклама: 11 (спасибо за поддержку)

🔸 Самые популярные серии постов за год (по просмотрам):
https://t.me/rzv_de/228
https://t.me/rzv_de/257
https://t.me/rzv_de/175
https://t.me/rzv_de/241
https://t.me/rzv_de/244
https://t.me/rzv_de/183
https://t.me/rzv_de/233
https://t.me/rzv_de/213
https://t.me/rzv_de/248
https://t.me/rzv_de/224

Также около 15 человек получилось довести до оффера (тыкаю их в переписке, чтобы внесли инфу в стату и попали в дашборд, а то никто ж не поверит), нескольким десяткам людей помог консультациями, вырастил закрытое бусти сообщество до 60 человек, дважды сменил работу с ростом ЗП х3.5

p.s. а вообще, в начале пути выпустил много маленьких полезных постов, пролистай на праздниках -- меню "сэндвич", "go to the beginning" ;)

REPLACE TABLE в Delta lake вместо DROP + RECREATE 2/2

🔸 Какое решение есть у delta table? Как и во многом другом, современные инструменты дают простой интерфейс для решения проблем, а сами делают тяжёлую работу под капотом. Будто говорит: "Хочешь пересоздать таблицу? Так именно это и напиши"

REPLACE TABLE table_name
as select * from ...

Помимо того, что поддерживается одновременный доступ на чтение для многих запросов (concurrently), операция выполняется в транзакции (см. ACID), ещё и история сохраняется — можно откатить к предыдущей версии одной командой (см. time travel in Delta tables).

В dbt, например, включается единственным конфигом на весь проект: on_table_exists: replace

В хорошее время живём)

p.s. Delta формат открытый и бесплатный, можно использовать уже завтра без доплаты за остальной Databricks