https://www.linkedin.com/posts/chad-sanderson_im-very-happy-to-unveil-the-semantic-warehouse-activity-6958091220157964288-JSXj


I'm very happy to unveil The Semantic Warehouse - the culmination of years of work, thinking, and trial-and-error on how to solve some of the biggest data problems at Convoy. It incorporates best practices espoused by Bill Inmon for robust, scalable Warehouse design built for the Cloud as an abstraction of the Modern Data Stack with Data Modeling at its core.

Вот такой вот цитатой встретил меня утром сегодня LinkedIn. Очередная концепция построения хранилища и вокруг, сколько их уже у нас там? Data Warehouse, Data Lake. Data Lakehouse, Data Fabric, Data Mesh и так далее. В комментах, кстати, заметили проблемки данного дизайна, однако автор говорит, что все фигня и все норм.

У автора есть хорошие материалы в блоге, но вот это, если честно, кажется карго-культом и кандидатом для бритвы Оккамы.

@ohmydataengineer

SmartData - конференция для Дата Инженеров.

“О нееет, реклама! А говорил, что не продашься! И вообще ты самый последний, кто запостил эту новость, все с тобой понятно!”

А вот и нет! С ребятами из JUG мы знакомы давно и никаких денег за рекламу единственной в РФ конфы для дата инженеров я не собирался брать.

Ребята открыли CFP - Call For Papers - то есть можно подавать заявки на доклады. Если помните, какое-то время назад я делал опрос про то, о чем написать. Тогда победил всеми любимый DBT. И если вы думаете, что я забил, то ни-фи-га. Я не только не забил, но даже почти притащил DBT в компанию. Осталось презентовать и раскатить 😋 (мы честно, в связи с нагрузкой, презентацию переносили аж полтора месяца). И про вот это все я как раз и хочу рассказать, подав свой доклад на конфу. Ну, а если не пройду, то пойду сам на очную часть, которая пройдет в Питере.

Думаю, докладик будет простого/среднего уровня, как раз разбавит хардкорные доклады.

Кстати, даже если не пойдете, то все доклады с SmartData доступны на Youtube: за 2021 год, за 2020 год.

Билеты по базовой цене - тут


@ohmydataengineer

В очередной раз про хороших инженеров…

В мой последний поход в подкаст я говорил о том, как инженерам расти по зарплате / грейдам / whatever внутри компании или, как говорится, “за всё хорошее против всего плохого”.
После этого выпуска мне в личку пришли несколько человек и задали вопрос: “Собственно, а как ты берешь на себя больше ответственности? Еще один пайплайн поддерживаешь? А потом еще базенку берешь деплоить и мониторить? Так на это все времени не хватит!”

Здесь есть маленький секрет: кроме классических “возьму на себя дополнительной работы, буду по ночам Spark деплоить”, есть другой подход. Выглядит он примерно следующим образом:

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

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

И если мы берем ответственность за свои факапы, объясняем почему так произошло и что мы сделаем для того, чтобы это не повторилось - тем больше к нам доверия. Чем больше к нам доверия, тем бОльше изменения в процессах нам позволяют сделать. Чем бОльше изменения, тем бОльше их позитивное влияние на продукт. Чем бОльше влияние на продукт, тем больше у вас аргументов для разговора с руководителем про свою компенсацию и рост.

Навеяно постом из блога Senior Developer Mindset про Trust / Responsibility.

@ohmydataengineer

О чем в кризис надо говорить? Правильно, о зарплатах.

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

И не смотря на то, что я не люблю эти отчеты, я решил посмотреть, что тут выдали ребята из Harnham. Полные отчеты приложены к посту, чтобы вам не пришлось регистрироваться, чтобы их скачать. Несколько наблюдений из отчетов:

- Отчеты называются “Data & Analytics Salary Guide 2022” и вот Top-5 технологий из EU отчета: SQL, Python, SAS, Google Analytics, Tableau. Питон и SQL, никаких Java или Scala, и, боже упаси, data science on Haskell. А вот в американском отчете есть AWS и R, но нет GA и SAS
- Those in the Netherlands, were the least interested in working fully remotely (only 15% wanted to do so). При этом Нидерланды недавно приняли закон WFH is employee right, а в статье написано, что 60% нравятся full remote. Истина где-то рядом. Про принятый закон в NL
- На картинке средние зарплаты в NL. Обладатели 160 base смотрят на директоров с высокой колокольни. Обратите внимание на второй скрин, там US зарплаты. С учетом того, что евро и доллар сравнялись, американские компании в EU смогут предлагать более комфортные условия.

Больше информации вы можете самостоятельно посмотреть в приложенных файлах

Какое-то время назад я писал анонс про книгу “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