Telegram Web
Типы timestamps в Data Engineering 3/3

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

Бизнес-даты особенно важны в регуляторной отчётности и compliance, где нужно чётко различать, когда событие произошло в реальности и когда оно было зафиксировано в системе.

И вопрос тебе: какие самые неочевидные баги в своей практике ты находил(а) из-за путаницы с timestamps? Делись в комментариях!
🔸 Принял участие в коллабе с коллегами по цеху. Пока ещё не всё просмотрел и прочёл в соседних разделах, но в целом выглядит годно

Моя часть -- про DBT (data build tool), структурировал и выгрузил знания за почти год плотной работы с этим тулом. Остальные лавры кидай другим двум авторам)

Пользуйся, предлагай правки в pull request'ах, рассказывай всем друзьям и близким. Ну и измени свою жизнь к лучшему, если ещё не)

🔸 А если даже примерно не представляешь, что такое dbt, смело кликай на раздел и начинай погружение. Как раз для тебя и писал эту часть роадмапа. Всё по порядку, через практику и с разбором ровно на нужную глубину, всё как я люблю.
Анонс: В четверг, 19 декабря в 19 мск, запускаю тестовый стрим для подписчиков на бусти.
Пообщаемся в формате Ask me Anything. В качестве площадки 99% будет Twitch

Для участия можно выбрать любой уровень, смотри по наполнению и самостоятельно определи для себя самый полезный
https://boosty.to/rzv_de

Если кто недавно на канале, о чём меня можно спросить (ЦА -- как интересующиеся сферой, так и уже работающие в DE уровнем до Sr):
. как перейти в сферу дата инжиниринга с нуля или из смежных профессий
. что из инструментов популярно в России и почему
. лёгкие и средние архитектурные вопросы
. что-то по работе или собесам
. всё что угодно другое

Не обещаю, что на всё отвечу, но постараюсь прочесть каждый вопрос)

p.s. Когда заполним шкалу до конца, проведу публичный стрим часа на 3-4 для всех
Встречайте, инфографика

Возможно тебе будет интересно заглянуть за ширму, что там у нас внутри происходит. И если кто-то из знакомых или ты сам ищешь ментора по DE, пиши в личку. Если не уверен(а), нужен ли тебе ментор, -- тоже. @razvodov_de_mentor :)

Активность в чате и публикации в закрытых каналах: https://datalens.yandex/vhix6u25akgwi
Офферы, полученные с помощью меня и сообщества: https://datalens.yandex/l5r0iby4zpgg8

Upd: допилил немного собирающий стату код и выложил в открытый доступ. Дашборд по офферам собирается на основе гугл форм
https://github.com/LexxaRRioo/tg-private-ch-stats-to-sheets-export
Ставь звёзды ⭐️, используй себе на пользу, всё дела
Напоминаю, что закрытый тестовый стрим будет завтра, 19 декабря в 19:00 мск

Посты тоже будут, не переживай)) Напиши в комменты, о чём было бы интересно почитать
Может, с такой целью будет интереснее)

А Ask me Anything для канала ближе к новому году проведу просто так
#зачем_нужно #вести_с_полей
REPLACE TABLE в Delta lake вместо DROP + RECREATE 1/2

🔸 Дата инженеры работают с большими и очень большими данными, поэтому для хранения и обработки всё меньше подходят CSV и JSON. Даже Parquet и ORC заменяются Hudi, Iceberg и Delta таблицами. С последними я пилю текущий проект на работе, поэтому иногда буду писать о встреченных фишках.

🔸 Например, в случае пересчёта таблицы есть несколько обычных стратегий:
. drop + create, пересоздать объект с нуля, если есть несовместимые изменения схемы данных
. insert overwrite partition, если изменилась логика или обновился источник и можем пересчитать по партиции за раз
. create + rename + drop, создать рядом промежуточную таблицу, прогрузить её данными, а потом "свопнуть", т.е. поменять местами с текущей таблицей — актуально для тяжёлых витрин с непозволительностью даунтайма для технических работ

🔸 Однако каждый из этих способов обладает своими недостатками:
. в первом случае будет даунтайм на период просчёта, и, в случае ошибки создания новой версии, пользователи и пайплайны будут заблокированы
. во втором случае запросы над несколькими партициями сразу могут возвращать несогласованные данные до окончания операции просчёта; или объект блокируется целиком на время всего пересчёта -> снова даунтайм
. третий подход выглядит хорошо (и может быть вариантом реализации online schema evolution), но редко встречается "из коробки" и его приходится писать, например, в виде кастомной материализации в dbt
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
Итоги года 2024

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

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

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

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

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

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

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

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

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

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

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

>>> Успей перейти по ссылке
#термин_дня

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

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

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

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

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

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

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

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

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

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

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

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

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

Ставь 🐘 или ⭐️, если хочешь больше сеньорных постов
Please open Telegram to view this post
VIEW IN TELEGRAM
Привет, делюсь папкой дата инженерных каналов с интересным контентом.
Заходи к нам на вечеринку по ссылке: https://www.tgoop.com/addlist/a1B07iwrPxUxNWIy
#вести_с_полей

Напоминалка про NULL в sql

Null не содержит значения (мы не знаем, какое значение атрибута было "в том месте и в то время"),
но хранит тип данных.

На продакшене, если добавляешь новую колонку "на будущее" или гармонизируешь данные из разных источников, вместо
select ...
, null as new_int_col
, null as new_date_col
, null as new_ts_col

стоит писать
select ...
, (cast null as integer) as new_int_col
, (cast null as date) as new_date_col
, (cast null as timestamp with time zone) as new_ts_col

Иначе жди проблемы интеграций "ниже по потоку" или при union all'ах.

p.s. Ну и помни, что в SQL boolean может иметь три значения, и null != False != True :)
#анонс

Boosty-цель выполнена — стриму с разбором резюме быть

В субботу 08.02.25, в 19:00 мск, я провёл стрим на твиче на 2.5-3ч.
UPD: Запись уже лежит на youtube

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

🔸 Присылай своё резюме заранее, буду проходить по стопке "снизу-вверх", разбирая очередь. Закинуть на стриме тоже можно будет, но я не обещаю успеть всё. Планирую до 10 минут на 1 резюме, почти наверняка в "одностороннем режиме", без диалога.

🔸 Почему моё мнение может быть полезным:
. HR сами пишут мне в личку, даже когда я в пассивном поиске с фильтром "от 400к на руки"
. через меня в роли ментора прошло более 50 человек. Скину в комменты обратную связь от некоторых из них по результатам доработки резюме
. в 2024 я получил 4 Sr. DE оффера на 500к+ на руки (в том числе с релокацией на Кипр)
. сам отсобеседовал 10+ человек на позиции middle, senior

UPD: приём резюме закрыт

Моё актуальное резюме всегда доступно здесь
2025/02/18 13:56:47
Back to Top
HTML Embed Code: