Часто-заголядывающая рубрика в моем бложике - про карьеру.
Читая книжку Staff Engineer, зашел к автору в блог и наткнулся на клевую заметку про карьерные решения. Актуально в текущих условиях “кризиса”.

- Во-первых, вы же знаете, что сейчас рецессия, кризис, и не только в мире, но и в айтишке. Хоть дебаты идут, “а вообще мы в рецессии?” и “А сколько она продлится?”, статистика говорит о том, что такие события длятся ±15 месяцев. То есть ориентируемся на конец 2023 года. Что мы можем с этим сделать?

- На любой позиции можно сделать приоритетом деньги, “скорость и режим работы”, собственное обучение, престиж или работу с людьми. Возможно, если вам сейчас комфортно, стоит сфокусироваться на обучении и на работе с классными людьми, чем в неспокойное время менять работу ради максимизации собственной прибыли?

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

Остальные пункты можно почтать в статье тут, но в целом мне хочется выделить один абзац и оставить его без перевода, ибо он прекрасен:

Combining the last few points: my general advice to folks would be to stay where you are as long as you’re reasonably happy day to day and feel like you’re learning at a good rate. Even if your effective compensation has declined a bit, it’s very hard to determine if the compensation at any other company will hold up either. Don’t get me wrong, if you’re unhappy for non-compensation reasons, then of course you should find another role. Well, unless you’re unhappy because the company is more focused on short-term profitability, because pretty much anywhere you go right now will have that orientation. Referring back to the first point, this isn’t the new normal, just a difficult ~15 month period to navigate

Так, я тут буквально недавно кидал статью про то, что проблемы с данными есть у всех. И костыли есть у всех, причем иногда целая фабрика костылей.
Ты такой сидишь и думаешь: “Блин, ну это только у нас так! У других все нормально!”. А вот и нет. Вот пример систематических проблем по всей индустрии:

- “Наша инфраструктура для данных ерунда!” - Кажется, что вы используете неправильные тулы и вообще ваша DWH тормозит. На деле большие компании имеют свойство закидывать проблему людьми и ресурсами, поэтому у них работает.

- “А кто за эту табличку отвечает?” - Первыми по башке прилетает всегда дата команде: “А что за херня у вас с данными?”. А то, что поставщик данных, из соседней команды, льющий все в data lake, что-то там неожиданно поменял и никому не сказал - никого не волнует. Люди не хотят брать отвественность за данные.

- “А почему так долго?” - Пользователи хотят как можно быстрей пользоваться данными, а инженеры хотят построить систему, которая не сломается от того, что вместо Null стали прилетать 0 в конкретное поле. Вечная борьба сроков и качества, где чаще всего побеждает первое, к сожалению.

Из этого всего вылезает еще один пункт:
- “А давайте всех научим SQL!” - ага, и выпустим в поле DWH, твори что хочешь! Конечно, знание SQL это прекрасно, и если каждый сможет самостоятельно что-то поглядеть в хранилище. Но для начала нужно все разложить по полочкам, раздать верные уровни доступа и ресурсы, иначе потом у вас будет 300 копий одной и той же метрики в разных таблицах и схемах.

Вольный перевод с отсебятиной вот этой статьи.

@ohmydataenginer

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 вышел выпуск про каталоги данных, что, куда и зачем.