Какое-то время назад я писал анонс про книгу “Fundamentals of Data Engineering”.

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

А теперь из прикольного: у ребят в datatalks.club в слаке есть канал book-of-the-week, где эту неделю автор книги отвечает на все вопросы. Советую заглянуть и почитать треды.

@ohmydataengineer

У ребят из Datafold еще в июле вышла прекрасная статья - https://is.gd/l4oNaY. Основной фокус в статье можно описать одним предложением: *Rather than building systems that detect and alert on breakages, build systems that don’t break.*

Observability это хорошо, очень хорошо. Но если вы в день видите 24 уведомления о том, что у вас кривые данные, весь ваш день будет потрачен на то, чтобы эти кривые данные поправить. Так может стоит инвестировать в то, чтобы строить то, что не ломается? Например, тесты, data lineage, data diff. Про это в статье как раз речь.

Мы имеем свойство переоценивать количество проблем с данными, которые приходят снаружи, и существенно недооцениваем количество наших собственных косяков. Основные драйверы этой проблемы

1. Данные это сложно – чтобы писать нормальный код, нужно знать очень многое про модель и про то, какие данные туда приходят, как они туда приходят, какое распределение у них и так далее.
2. Нам еще и бизнес-логики туда накрутили - SQL в тыщу строк? Легко!
3. Поставщики данных не спят и развиваются - платформы данных должны успевать за всеми изменениями поставщиков данных, а их много и они развиваются с огромной скоростью. Нас ждать не будут.
4. Быстрее, быстрее, быстрее!  - стейкхолдеры ждут свои дашборды, чтобы принимать решения. Тут все старо как мир.

Статью советую взглянуть, вещи хоть и относительно простые и очевидные написаны, но очень важные.

P.S. Datafold делает тулзу для DQ и опытный человек мог заметить UTM-ссылку, можно сказать, что я аффилирован! Опять же, мне никто за это не платит, с ребятами я знаком давно и лично, когда-то, даже, когда их было всего 5-7 человек, мы с ними поработали вместе несколько месяцев. Мне нравится, что и как они делают. Глеб, привет!

@ohmydataengineer

https://dataproducts.substack.com/p/the-rise-of-data-contracts

Сегодня будет горячая для меня тема: контракты данных. Начнем прямо с главного:

*Today, engineers have almost no incentive to take ownership of the data quality they produce outside operational use cases. This is not their fault. They have been completely abstracted away from analytics and ML.*

И это в большинстве случаев правда. Разработчики не особо парятся про то, что происходит с их данными за пределами базы их сервисов. А нам потом с этим работать и недовольный пользователь первым делом кидается какашкой в нас, владельцев платформы.

Рассмотрим пример: есть GDPR процесс, по которому пользователь может у вас запросить удалить все PII данные про него. Разработчики сервиса решают особо не парится, и просто делают все PII данные NULL, потому что им так удобней и проще (их право, их сервис, про других не подумали). А вот то, что потом эти нули приедут в DWH и там поедут метрики и дашборды, не говоря уже про проверки качества. И будем мы бегать и пытаться понять “А тут NULL почему? Потому что у сервиса что-то пошло не так? Или у нас? Или это GDPR?”
P.S. хорошим решением было бы вместо нулей положить что-то в стиле ’GDPR_deleted_’ + md5(), флаг is_gdpr_deleted и время манипуляции gdpr_deleted_timestamp.

Дата контракты становятся такой-же важной вещью, как и контракты по API между сервисами, фронтом и беком. Договоренности о том, как нам отдают данные, в каком формате, с использованием простого интерфейса и валидацией на входе - сильно упрощает понимание того, что происходит с данными. Разрабы смогут спокойно работать со своими базами не боясь того, что какие-то изменения у них поломают продакшен.

Напишите в комменты, есть ли у вас data contracts?

@ohmydataengineer

- https://seattledataguy.substack.com/p/cataloging-data-catalogs

- https://github.com/opendatadiscovery/awesome-data-catalogs

- И целый топик в GitHub - https://github.com/topics/data-catalog

Каталог Каталогов Данных

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

@ohmydataengineer

https://www.jeremiahlee.com/posts/failed-squad-goals/

Управление командами, а тем более компаниями, штука непростая. Я за последний месяц успел это прочувствовать это на себе, получив обязанности тимлида. Не удивляет меня и то, что компании всегда в поиске модели взаимодействия, которое поможет им:
- упростить взаимодействие между командами
- ускорить поставку нового функционала
- разделять знания и адаптировать лучшие практики соседних команд.

Возможно, вы слышали про инженерную культуры Spotify. Если нет, то можно почитать и посмотреть небольшой видос. Наверняка, вы слышали про эту культуру и организованность.
Меня лично очень сильно удивляло, когда российские компании начали слепо адаптировать эту модель и в некоторых банках появились сквады, трайбы, гильдии и вот это все. Я почему-то чувствовал, что это не работает и просто кто-то занимается ИБД. Как и вся эта идея, слишком много интересных слов, на деле - слишком сложно.
А вот по самой первой ссылке подтверждение моих ощущений: такая модель не сработала и в Spotify, они со временем постепенно вернулись к обычной матричной структуре.

@ohmydataengineer

https://movedata.airbyte.com/

Есть такие ребята Airbyte (https://airbyte.com), конкуренты Airflow, запускатор по расписанию, опенсорсный бесплатный и платный у них в облаке.
Так вот они решили организовать конференцию по Data Engineering.
Есть только даты (8-10 Ноября) и ссылка на Slack, программы пока нет.

Возможно, будет что-то интересное. А может и нет. Just FYI.

P.S. Аудитория подсказывает, что ближайшие конкуренты это Fivetran, Stitch или Hevo. Спасибо @nikbeesti


@ohmydataengineer

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

https://medium.com/data-monzo/the-many-layers-of-data-lineage-2eb898709ad3

Да-да, каталоги и data lineage - моя больная тема.
А вот тут прекрасная статья нашлась, которая поясняет, что data lineage на деле, это не просто связь между колонками и таблицами, а нечно более. А именно несколько слоев: зависимость колонок, зависимость таблиц, зависимость на уровне моделей (ага, таблица != модель), зависимость на бизнес уровне.
И как только вы построили самый нижний слой (например, при помощи DBT), у вас появляется еще кучка новых вопросов.

@ohmydataengineer

Так, SmartData уже не за горами и на сайте уже появились некоторые доклады https://bit.ly/3KSsrvM
Из интересного лично мне:

Владимир Озеров “Как устроено выполнение SQL-запросов в Trino” (https://smartdataconf.ru/talks/1fc81e775df2473f9865202aca7a4642/)
Наш основной инструмент работы с данными в Gett. И хоть я пару книжек прочитал по теме, все равно интересно.

Юлия Волкова “Любовь и ненависть к Prefect 2.0 после Apache Airflow” (https://smartdataconf.ru/talks/aceb4db19f59418780bcc9dc8fd4fc08/)
Мы ж когда-нибудь свалим с Jenkins (да-да, так бывает, не спрашивайте). И вот выбор Airflow vs Prefect - это наш шортлист. Забавный факт, несколько лет назад, когда я был джуном, меня Юля собесила. Техсобес я не прошел, потому что литкод зло 😁

Анастасия Ожигина “Как загрузить в каталог данных всё на свете и не умереть” (https://smartdataconf.ru/talks/d5dd4232460942648e174e606eb6dc71/)
Это попаболь моих последних дней, вы и сами все знаете.

Напомните работодателю про бюджеты на образование и приходите на конфу!

@ohmydataengineer

https://blog.pragmaticengineer.com/what-is-data-engineering/

The Pragmatic Engineer вместе с SeattleDataGuy написал огромную статью про то, что же такое Data Engineering.
Если вы не читали Fundamentals of Data Engineering - то это фактически сокращенная выжимка.
Ничего сеньорного, в целом самые базовые концепции поясняются, целевая аудитория все-таки все остальные в айтишке, не дата инженеры =)

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

P.S. Исправил ссылку, потому что она была из рассылки, а она платная. Но автор выкладывал и в открытый доступ статью, так что теперь выше - правильная ссылка.

@ohmydataengineer

Про онбоардинг в Data Teams

Пару недель назад ко мне в команду пришел новый инженер и мне предстояло его онбоардить. До этого процесс онбоардинга у нас выглядел “своеобразно” - 35 видео, от 20 до 40 минут, в какждом из которых рассказывалось про какую-либо тулзу или процесс, котороый у нас есть.
С одной стороны, это прикольно, не тратишь ничье время, смотришь видосы, и ты готов что-то делать. Но практика оказалась другой: видосы ты посмотрел, а делать пока не можешь, потому что уже забыл, в каком видосе и что пояснялось. В итоге, вместо полноценной единицы через месяц получалось что-то на 50% готовое делать полноценные задачи, 70% если ты мотивированный и активный и 30% если нет.

Что я в итоге сделал? Нарезал заранее мелких задач по главным тема, так, чтобы человек начинал делать уже во время просмотра видео, а не после всех. Ну и peer-to-peer сессии с почти каждым членом команды тоже дали эффект. Человек уже через 1.5 недели со всеми доступами и пилит продовые задачи.

Да, можно еще быстрей (видел компании, где коммитят в прод чуть ли не в первый день).
Да, можно еще качественней.
Да, можно еще лучше.
Но я только начал =)

Кстати, неплохой пример подходов онбоардинга в дата командах https://seattledataguy.substack.com/p/onboarding-for-data-teams.
Как всегда, без каких-то откровений и серебрянных пуль.

@ohmydataengineer

https://blog.pragmaticengineer.com/what-is-data-engineering-2/

Продолжение предыдущей части про DE от The Pragmatic Engineer.
Все также основные базовые понятия, сама статья даже маловата, если честно, но для ознакомления, что же такое DE - все еще прекрасно подходит.

@ohmydataengineer

Хех,💩 под постом говорят о том, что кому-то не понравился мой пост про донаты. И я даже догадываюсь, почему.

Хочу чуть пояснить свою позицию:

В этом канале никогда не будет платной рекламы. И этим постом я не хотел “вымогать” деньги из подписчиков, в стиле “или задонатьте, или я начну брать рекламу”.
Ее не будет здесь, если я что-то буду постить, это будет потому, что это понравилось мне и я посчитал нужным и полезным этим с вами поделиться.
Донат - это способ для вас сказать мне “спасибо” за то, что я делаю. Даже если мне никто не будет больше донатить (спасибо большое тем, кто закинул), я все равно продолжу вести этот канал в том же стиле, что и раньше.
Поэтому 4 человека, кто поставил какашонки, вернитесь пожалуйста, я вас всех очень люблю. ❤️

P.S. Первое сообщение с сомнительным текстом (который можно было прочитать двояко) я удалю, сделаю новое. Прошу прощение за уведомление!

P.S.S. Та реклама, что появляется в виде отдельного сообщения под самым последним моим постом - я не вижу в своей ленте, не контролирую и с него ничего не получаю. Это ерунда от Дурова и как ее убрать, я хз пока.

Важное объявление!
Думаю, по скриншоту все понятно 🤪

Хочется немного порефлексировать: уехать я хотел очень давно. Потому что работа моей мечты не в РФ.

И в целом план по релокации был сначала на 4-5 лет. И сразу в США.

Потом он сократился до 1.5 лет, а список стран изменился и стали были болота (так мы называем Нидерланды).

А потом снова обстоятельства изменились и 1.5 года превратились в 6 месяцев и Сербию. А затем 6 месяцев в 2. И Кипр.

Обстоятельства меняются, страны меняются, сроки меняются. Цель 🎯 остается.

Спасибо Gett что не смотря на все сложности, он делает все, чтобы было хорошо.

Тем, кто остается: это ваш выбор, я его уважаю и вне зависимости от причин, желаю вам сил и побольше возможностей. ❤️

Тем, кто уехал: мы с вами обязательно увидимся где-то на новом месте!