Forwarded from LEFT JOIN
Дата инжиниринг – одна из самых сложных и востребованных профессий в области данных. В новом выпуске подкаста Data Heroes мы поговорим с инженерами данных и наконец-то узнаем, чем именно они занимаются 🚀
В этом эпизоде мы поговорим о важности роли дата инженера в бизнес-процессах, а также сложностях и нюансах специализации.
Наши эксперты поделятся своим бесценным опытом и расскажут о:
▪️Своем извилистом пути в профессию
▪️Современном дата инжиниринге и о том, как он отличается от компании к компании
▪️Сходствах и различиях в ролях аналитика и дата инженера и о том, когда эти роли можно совмещать
▪️Важности софт-скиллов для дата инженера
БОНУС: Как и всегда, наши спикеры дадут полезные рекомендации и советы для новичков в специализации 🧑🎓
Включайте подкаст и погружайтесь вместе с нами в загадочный мир дата инжиниринга!
СПИКЕРЫ: Семен Осипов, Ксения Томак, Сергей Бойцов, Александр Михайлов
Слушайте подкаст на платформах: Spotify, Anchor, Apple Podcasts, Yandex, Overcast, Mave, Castbox, Telegram (↓)
#подкаст #DataHeroes
В этом эпизоде мы поговорим о важности роли дата инженера в бизнес-процессах, а также сложностях и нюансах специализации.
Наши эксперты поделятся своим бесценным опытом и расскажут о:
▪️Своем извилистом пути в профессию
▪️Современном дата инжиниринге и о том, как он отличается от компании к компании
▪️Сходствах и различиях в ролях аналитика и дата инженера и о том, когда эти роли можно совмещать
▪️Важности софт-скиллов для дата инженера
БОНУС: Как и всегда, наши спикеры дадут полезные рекомендации и советы для новичков в специализации 🧑🎓
Включайте подкаст и погружайтесь вместе с нами в загадочный мир дата инжиниринга!
СПИКЕРЫ: Семен Осипов, Ксения Томак, Сергей Бойцов, Александр Михайлов
Слушайте подкаст на платформах: Spotify, Anchor, Apple Podcasts, Yandex, Overcast, Mave, Castbox, Telegram (↓)
#подкаст #DataHeroes
https://www.youtube.com/watch?v=-DVyjdw4t9I
Кто тут пожаловал в гости к Лексу Фридману, уже второй раз оказывается, сам Гвидо Ван Россум!
Для начала, кто такой Lex Fridman. Чел из MIT, эксперт в ML, AI, Deep Learning и вот этом всем, но не на уровне PowerPoint презентаций, а прям лекций в университетах.
Вот его сайт - https://lexfridman.com/
У него есть подкаст, в который приходят поговорить умные люди из индустрии, немного рядом или вообще далеко. Но всегда слушать интересно. Например, Цукерберг, Маск, Дорси, Карпати, Карлсен (который гроссмейстер), Кармак, Роган, даже Канье Вест залетал.
Так вот, в свежем выпуске создатель Питончика размышляет про будущее программирования. Оч советую послушать и вообще подписаться на челика, у него оч много интересного контента.
@ohmydataengineer
Кто тут пожаловал в гости к Лексу Фридману, уже второй раз оказывается, сам Гвидо Ван Россум!
Для начала, кто такой Lex Fridman. Чел из MIT, эксперт в ML, AI, Deep Learning и вот этом всем, но не на уровне PowerPoint презентаций, а прям лекций в университетах.
Вот его сайт - https://lexfridman.com/
У него есть подкаст, в который приходят поговорить умные люди из индустрии, немного рядом или вообще далеко. Но всегда слушать интересно. Например, Цукерберг, Маск, Дорси, Карпати, Карлсен (который гроссмейстер), Кармак, Роган, даже Канье Вест залетал.
Так вот, в свежем выпуске создатель Питончика размышляет про будущее программирования. Оч советую послушать и вообще подписаться на челика, у него оч много интересного контента.
@ohmydataengineer
YouTube
Guido van Rossum: Python and the Future of Programming | Lex Fridman Podcast #341
Guido van Rossum is the creator of Python programming language. Please support this podcast by checking out our sponsors:
- GiveDirectly: https://givedirectly.org/lex to get gift matched up to $1000
- Eight Sleep: https://www.eightsleep.com/lex to get special…
- GiveDirectly: https://givedirectly.org/lex to get gift matched up to $1000
- Eight Sleep: https://www.eightsleep.com/lex to get special…
https://habr.com/ru/company/habr_career/blog/702558/
Очередная статистика по зарплатам в РФ от Хабр Карьеры.
Как ее воспринимать, это решение каждого. Помните, что на карьеро-зарплатные вопросы отвечают люди, которые а) читают этот ресурс и видели пост про опрос (или получили рассылку), б) есть время и желание это заполнять.
Если ваша з/п сильно выбивается из описанных, помните, что вы, возможно, совсем в другом пузыре находитесь и это полезно помнить при любых спорах.
Конкретно про методологию сборки данных для этого исследования - в конце статьи.
@ohmydataengineer
Очередная статистика по зарплатам в РФ от Хабр Карьеры.
Как ее воспринимать, это решение каждого. Помните, что на карьеро-зарплатные вопросы отвечают люди, которые а) читают этот ресурс и видели пост про опрос (или получили рассылку), б) есть время и желание это заполнять.
Если ваша з/п сильно выбивается из описанных, помните, что вы, возможно, совсем в другом пузыре находитесь и это полезно помнить при любых спорах.
Конкретно про методологию сборки данных для этого исследования - в конце статьи.
@ohmydataengineer
Хабр
Зарплаты разработчиков в первой половине 2022: языки и квалификации
Когда-то давно мы решили, что смотреть на зарплаты айтишников только в большом зарплатном исследовании — недостаточно, и начали копать глубже. Так появился срез зарплат в контексте языков...
Пост очередного подгорания жопки!
https://towardsdatascience.com/whats-next-for-data-engineering-in-2023-7-predictions-b57e3c1bf2d3
Меня немножко кидает из стороны в сторону, то я ругаюсь на капитанский и откровенно булшитный контент, то наоборот защищаю, потому что у всех разные пузыри и не оч понятно, для кого это очевидно, а для кого нет.
Вот в очередной рассылке про данные, прилетела статья. Автор - Co-Founder and CEO, Monte Carlo, Barr Moses, то есть вроде бы вопросиков к автору не должно быть, человечек знает, что пишет.
Но открываешь статью и видишь следующее:
…
Currently, data team roles are segmented primarily by data processing stage:
1 )Data engineers pipe the data in,
2) Analytical engineers clean it up, and
3) Data analysts/scientists visualize and glean insights from it.
…
…
Most machine learning models (>51%) will successfully make it to production
…
…
Predicting data teams will continue to transition toward a data mesh
…
…
Data reliability engineers will ensure data quality
…
…
As a result, next year’s hottest trends will be less about optimizing or scaling infrastructure, but instead processes for making this enlarged universe more organized, reliable, and accessible.
…
Заголовок то кликбейтный, типа “Эксперт предсказал тренды в дата инженеринге в 2023”, а потом вот такое. Сижу, и не понимаю, как реагировать на это. То ли лыжи не едут, то ли я… Ну вы поняли.
Поэтому у меня предложение - напишите в комментарии к этому посту 1-2 ваших предположения на ближайшие пару лет касательно DE и вообще “датки” =)
Вы у меня клевые, классные и умные, уверен, что булшита у нас в комментах не будет! 😄
@ohmydataengineer
https://towardsdatascience.com/whats-next-for-data-engineering-in-2023-7-predictions-b57e3c1bf2d3
Меня немножко кидает из стороны в сторону, то я ругаюсь на капитанский и откровенно булшитный контент, то наоборот защищаю, потому что у всех разные пузыри и не оч понятно, для кого это очевидно, а для кого нет.
Вот в очередной рассылке про данные, прилетела статья. Автор - Co-Founder and CEO, Monte Carlo, Barr Moses, то есть вроде бы вопросиков к автору не должно быть, человечек знает, что пишет.
Но открываешь статью и видишь следующее:
…
Currently, data team roles are segmented primarily by data processing stage:
1 )Data engineers pipe the data in,
2) Analytical engineers clean it up, and
3) Data analysts/scientists visualize and glean insights from it.
…
…
Most machine learning models (>51%) will successfully make it to production
…
…
Predicting data teams will continue to transition toward a data mesh
…
…
Data reliability engineers will ensure data quality
…
…
As a result, next year’s hottest trends will be less about optimizing or scaling infrastructure, but instead processes for making this enlarged universe more organized, reliable, and accessible.
…
Заголовок то кликбейтный, типа “Эксперт предсказал тренды в дата инженеринге в 2023”, а потом вот такое. Сижу, и не понимаю, как реагировать на это. То ли лыжи не едут, то ли я… Ну вы поняли.
Поэтому у меня предложение - напишите в комментарии к этому посту 1-2 ваших предположения на ближайшие пару лет касательно DE и вообще “датки” =)
Вы у меня клевые, классные и умные, уверен, что булшита у нас в комментах не будет! 😄
@ohmydataengineer
Medium
What’s Next for Data Engineering in 2023? 7 Predictions
What’s in store for the future of data engineering? In this article, I share some of my topline predictions for 2023 — and beyond.
https://beeline.jugru.org/?utm_source=jrg_info_partner&utm_medium=ohmydataengineer&utm_campaign=announce_meetup_beeline
Давно у меня не было материала на канале, переезд в другую страну сбил все графики.
Но ничего, вроде все вопросики уладили, поэтому возвращаемся в ритм.
Начем с анонса онлайн-митапа от JUG и Билайна.
В списке тем:
- Как настроить ETL с JSON’ами в Apache NiFi
- Система сквозного логирования с передачей единого идентификатора процесса между независимыми задачами Airflow
- Apache Flink: Flink Table API & SQL
Доклад в середине - то, чего мне не хватало года полтора/два назад, поэтому мы что-то придумывали сами. Теперь интересно узнать, как это делают в других местах.
@ohmydataengineer
Давно у меня не было материала на канале, переезд в другую страну сбил все графики.
Но ничего, вроде все вопросики уладили, поэтому возвращаемся в ритм.
Начем с анонса онлайн-митапа от JUG и Билайна.
В списке тем:
- Как настроить ETL с JSON’ами в Apache NiFi
- Система сквозного логирования с передачей единого идентификатора процесса между независимыми задачами Airflow
- Apache Flink: Flink Table API & SQL
Доклад в середине - то, чего мне не хватало года полтора/два назад, поэтому мы что-то придумывали сами. Теперь интересно узнать, как это делают в других местах.
@ohmydataengineer
beeline.jugru.org
bee.tech. DevOps meetup. Контейнеры, безопасность и миграция
Митап для DevOps-специалистов
https://iximiuz.com/en/posts/ssh-tunnels/
Хехе, сегодня необычный пост, потому что он не про Data Engineering. По ссылке выше - прекрасный иллюстрируемый гайд про то, как работает SSH тунель.
Когда он мне попался на глаза, немножк всплакнул, потому что вспомнил вот такую историю:
На одном из рабочих мест, ввиду политики информационной безопасности, доступ на продакшен кластер K8S и ко всем продакшен базам данных, расположенным в одой сети, был запрещен снаружи, то есть с рабочего компа из дома не постучаться; То есть только из офисного Wi-Fi.
И нет, с корпоративным VPN тоже нельзя. И да, это уже был Covid, и мы были на удаленке.
Тогда хитрый жук Семен, чтобы не пользоваться RDS (удаленным рабочим столом), сделал хитрый финт ушами:
- поднял в личном облаке машину за $3
- поднял под в неймспейсе своего продукта, который делал Reverse SSH Tunnel на эту машину и Port Forwarding
- все коннекшен стринги (к базам и к кластерам) поменял на адрес машины.
В итоге когда Data Grip исполнял заброс, он летел на машину в моем облаке, по обратному тоннелю уходил в под, который в прод кластере, а уже оттуда - в базенку.
Никто из DevOps и ИБ, за год+ работы этой схемы так и не пришел ругаться 😜
@ohmydataengineer
Хехе, сегодня необычный пост, потому что он не про Data Engineering. По ссылке выше - прекрасный иллюстрируемый гайд про то, как работает SSH тунель.
Когда он мне попался на глаза, немножк всплакнул, потому что вспомнил вот такую историю:
На одном из рабочих мест, ввиду политики информационной безопасности, доступ на продакшен кластер K8S и ко всем продакшен базам данных, расположенным в одой сети, был запрещен снаружи, то есть с рабочего компа из дома не постучаться; То есть только из офисного Wi-Fi.
И нет, с корпоративным VPN тоже нельзя. И да, это уже был Covid, и мы были на удаленке.
Тогда хитрый жук Семен, чтобы не пользоваться RDS (удаленным рабочим столом), сделал хитрый финт ушами:
- поднял в личном облаке машину за $3
- поднял под в неймспейсе своего продукта, который делал Reverse SSH Tunnel на эту машину и Port Forwarding
- все коннекшен стринги (к базам и к кластерам) поменял на адрес машины.
В итоге когда Data Grip исполнял заброс, он летел на машину в моем облаке, по обратному тоннелю уходил в под, который в прод кластере, а уже оттуда - в базенку.
Никто из DevOps и ИБ, за год+ работы этой схемы так и не пришел ругаться 😜
@ohmydataengineer
Iximiuz
A Visual Guide to SSH Tunnels: Local and Remote Port Forwarding
SSH port forwarding explained in a clean and visual way. How to use local and remote port forwarding. What sshd settings may need to be adjusted. How to memorize the right flags.
Вас 2000 человек! Спасибо большое, что вы читаете меня!
Для меня это оч большое достижение. Когда я только начинал свой канал, это была просто копилка каких-то идей и интересных статей.
А теперь нас 2000 человек и это уже большоя группа людей, с очень разносторонними мнениями и взглядами на технологии, с которыми прикольно общаться и оч мотивирует, когда вы присылаете 💩, мотивирует искать материал лучше)
В ближайшие дни буду подводить итоги года и писать планы на будущий. Stay tuned, как говориться 🤪
@ohmydataengineer
Для меня это оч большое достижение. Когда я только начинал свой канал, это была просто копилка каких-то идей и интересных статей.
А теперь нас 2000 человек и это уже большоя группа людей, с очень разносторонними мнениями и взглядами на технологии, с которыми прикольно общаться и оч мотивирует, когда вы присылаете 💩, мотивирует искать материал лучше)
В ближайшие дни буду подводить итоги года и писать планы на будущий. Stay tuned, как говориться 🤪
@ohmydataengineer
Итоги года.
Если вас еще не достали итоги года во всех остальных социальных сетях, то вот чуток от меня, самые заметные события в моей жизни за этот год.
- Канал “Труба Данных” активно растет и развивается. Для меня это огромная радость и удовольствие, делиться всяким полезным с вами. Много раз в комментах были клевые обсуждения, которые расширяли картину мира. Немного статистики на скриншоте выше. И да, никакой рекламы и канал остается независимым до сих пор, хотя приходят каждый день с запросом на платное размещение 😄 Даже кнопка вверху “На развитие канала" больше для успокоения моей совести (но я всегда рад донатам, конечно же😁).
- Мне досталась новая роль, на этот раз официально - я теперь тимлид. Ага, целая команда из нескольких человек и много стейкхолдеров, которым что-то очень срочно надо всегда. Если раньше мне удавалось “лидить”, но при этом официально у меня не было ответственности, то теперь она есть и приходится отвечать. Очень новый опыт, очень интересный и необычный.
- Релокация. Новое место (я никогда не был на Кипре до релокации), новый удивительный мир (и левостороннее движение). Теперь мой айти-пузырь побольше, картина мира пошире. Очень жду митапов и встреч с коллегами по цеху.
- Конференции, подкасты, митапы. Очень скучал по движухам и очень рад, что в 2022 удалось по конфам походить и повыступать. Не все удалось сделать, что задумывалось, поэтому на следующий год цели еще более амбициозные!
За все неисполненные обещания (например, за Iceberg или DBT) можно напихать автору в комментах!
@ohmydataengineer
Если вас еще не достали итоги года во всех остальных социальных сетях, то вот чуток от меня, самые заметные события в моей жизни за этот год.
- Канал “Труба Данных” активно растет и развивается. Для меня это огромная радость и удовольствие, делиться всяким полезным с вами. Много раз в комментах были клевые обсуждения, которые расширяли картину мира. Немного статистики на скриншоте выше. И да, никакой рекламы и канал остается независимым до сих пор, хотя приходят каждый день с запросом на платное размещение 😄 Даже кнопка вверху “На развитие канала" больше для успокоения моей совести (но я всегда рад донатам, конечно же😁).
- Мне досталась новая роль, на этот раз официально - я теперь тимлид. Ага, целая команда из нескольких человек и много стейкхолдеров, которым что-то очень срочно надо всегда. Если раньше мне удавалось “лидить”, но при этом официально у меня не было ответственности, то теперь она есть и приходится отвечать. Очень новый опыт, очень интересный и необычный.
- Релокация. Новое место (я никогда не был на Кипре до релокации), новый удивительный мир (и левостороннее движение). Теперь мой айти-пузырь побольше, картина мира пошире. Очень жду митапов и встреч с коллегами по цеху.
- Конференции, подкасты, митапы. Очень скучал по движухам и очень рад, что в 2022 удалось по конфам походить и повыступать. Не все удалось сделать, что задумывалось, поэтому на следующий год цели еще более амбициозные!
За все неисполненные обещания (например, за Iceberg или DBT) можно напихать автору в комментах!
@ohmydataengineer
Цели 2023 года
Ага-ага, строили мы планы на 2022, но все крякнулось. Поэтому с одной стороны планировать что-то теперь в этом ну оч быстро меняющемся мире стало сильно сложней. С другой стороны - “If you fail to plan, you plan to fail”. Поэтому немного о том, что я хочу сделать в этом году:
- Продолжить развивать “Трубу данных”, писать куда более стабильно в канал и более информативно, а не просто швыряться ссылками.
- Начать писать на английском языке. Это не заменит этот канал, тут все будет так и в том формате, как есть сейчас. Я скорее про профессиональный блог на каком-нибудь Medium, Dev.to или еще лучше, Substack. При этом оч не хочется превращать это все в LinkedIn Influencer (ох уж у меня такого контента в ленте)
- Митапы, конференции и подкасты. В этом году поставил сразу две цели по конференциям: main stage на русскоговорящей и в целом податься (авось пройдет) на англоговорящую конференцию. Ну и дежурно сходить пообщаться в 1-2 подкаста 🤦
И маленький мини-анонс side-project. Большую часть года я занимался карьерным консультированием. Помогал знакомым и не очень людям скорректировать свою траекторию карьеры, как собеседоваться (и нет, это не про верчение деревьев), а главное - получить хороший оффер и даже поторговаться за него. Но я нигде про это не рассказывал и работало просто сарафанное радио. В этом году я решил, что можно открыть свой проект наружу немножко. Про проект “🚜Ведутся Карьерные Работы” я расскажу попозже.
Желаю все хорошего и продуктивного года!
@ohmydataengineer
Ага-ага, строили мы планы на 2022, но все крякнулось. Поэтому с одной стороны планировать что-то теперь в этом ну оч быстро меняющемся мире стало сильно сложней. С другой стороны - “If you fail to plan, you plan to fail”. Поэтому немного о том, что я хочу сделать в этом году:
- Продолжить развивать “Трубу данных”, писать куда более стабильно в канал и более информативно, а не просто швыряться ссылками.
- Начать писать на английском языке. Это не заменит этот канал, тут все будет так и в том формате, как есть сейчас. Я скорее про профессиональный блог на каком-нибудь Medium, Dev.to или еще лучше, Substack. При этом оч не хочется превращать это все в LinkedIn Influencer (ох уж у меня такого контента в ленте)
- Митапы, конференции и подкасты. В этом году поставил сразу две цели по конференциям: main stage на русскоговорящей и в целом податься (авось пройдет) на англоговорящую конференцию. Ну и дежурно сходить пообщаться в 1-2 подкаста 🤦
И маленький мини-анонс side-project. Большую часть года я занимался карьерным консультированием. Помогал знакомым и не очень людям скорректировать свою траекторию карьеры, как собеседоваться (и нет, это не про верчение деревьев), а главное - получить хороший оффер и даже поторговаться за него. Но я нигде про это не рассказывал и работало просто сарафанное радио. В этом году я решил, что можно открыть свой проект наружу немножко. Про проект “🚜Ведутся Карьерные Работы” я расскажу попозже.
Желаю все хорошего и продуктивного года!
@ohmydataengineer
Как вы могли заметить, я не размещаю на канале ни рекламу курсов, и всякие weekend offer events, ни вакансии. Но у последнего бывают исключения, и сегодня ровно такой день) 🤪
Если кто-то ищет для себя новый вызов в интересной компании, с очень клевыми людьми (лично знаком и с CEO, и с CTO), с прикольным продуктом (local purchasing power) - присылайте Кириллу свои CV.
Писать @KirillGugaev
Если кто-то ищет для себя новый вызов в интересной компании, с очень клевыми людьми (лично знаком и с CEO, и с CTO), с прикольным продуктом (local purchasing power) - присылайте Кириллу свои CV.
Писать @KirillGugaev
Forwarded from Kirill Gugaev
Привет всем! Я - CTO в американском YC-стартапе Corrily, ищу хорошего data-инженера!
#вакансия #data_engineer #senior
Компания: Corrily Inc
Занятость: проектная / парт-тайм
Формат работы: удаленка, контракт с оплатой по-часам (пишите свой рейт)
Описание проекта:
Corrily - это ML-сервис для динамического прайсинга SaaS сервисов.
Мы помогаем крупным интернет-сервисам по всему миру проводить эксперименты с ценами и поднимать выручку на 10-20% за счет изменения цен в разных странах и для разных сегментов на более справедливые.
Кого ищем:
Мы ищем опытного data-инженера, кто бы совместно с нашими разработчиками помогал бы расширять SaaS-аналитику (разбираться в данных, добавлять новые метрики, оптимизировать структуры данных / таблиц, добавлять дата-тесты, строить пайплайны). Работы не хватит на фуллтайм-вакансию, поэтому я думаю начать на контрактной основе, а потом уже посмотреть как пойдет. Общаемся на английском
Стек: Google Cloud BigQuery, DBT, Postgres, Airflow, Python
Будет плюсом, если вы уже работали с платежными данными (считали MRR / Revenue / Cashflow) или имеете интерес в области финтеха.
Можем платить официально в $ или официально в крипте )))
Писать можно мне в телегу, созвонимся и расскажу подробности
#вакансия #data_engineer #senior
Компания: Corrily Inc
Занятость: проектная / парт-тайм
Формат работы: удаленка, контракт с оплатой по-часам (пишите свой рейт)
Описание проекта:
Corrily - это ML-сервис для динамического прайсинга SaaS сервисов.
Мы помогаем крупным интернет-сервисам по всему миру проводить эксперименты с ценами и поднимать выручку на 10-20% за счет изменения цен в разных странах и для разных сегментов на более справедливые.
Кого ищем:
Мы ищем опытного data-инженера, кто бы совместно с нашими разработчиками помогал бы расширять SaaS-аналитику (разбираться в данных, добавлять новые метрики, оптимизировать структуры данных / таблиц, добавлять дата-тесты, строить пайплайны). Работы не хватит на фуллтайм-вакансию, поэтому я думаю начать на контрактной основе, а потом уже посмотреть как пойдет. Общаемся на английском
Стек: Google Cloud BigQuery, DBT, Postgres, Airflow, Python
Будет плюсом, если вы уже работали с платежными данными (считали MRR / Revenue / Cashflow) или имеете интерес в области финтеха.
Можем платить официально в $ или официально в крипте )))
Писать можно мне в телегу, созвонимся и расскажу подробности
Corrily
Corrily | The Monetization Growth Engine
Corrily is the all-in-one platform web & mobile subscription companies use to grow revenue — with paywall design, analytics, AI insights, experiments, and personalized pricing and discounting.
shorturl.at/fxEQ0
Вот тут попалась в одном из телеграм каналов реклама одной релевантной конференции. Российская конференция про качество данных.
Все бы ничего, но у меня есть вопросики к формулировкам:
<…решениям обеспечения гарантированного качества данных в условиях динамичных изменений и экономической неопределенности…>
Оч канцелярно. Ну и создается ощущение, что с приходом санкций у нас нет доступа к инструментам по качеству данных.
А потом посмотрел фотографии и сложилось впечатление, что DQ это какая-то старперская дисциплина, стало грустно.
Вы уж простите, немножко эйджизмом попахивает, но никого обидеть не хотел.
Автора можно закидать 💩 или написать свое мнение в комментариях к посту.
@ohymydataengineer
Вот тут попалась в одном из телеграм каналов реклама одной релевантной конференции. Российская конференция про качество данных.
Все бы ничего, но у меня есть вопросики к формулировкам:
<…решениям обеспечения гарантированного качества данных в условиях динамичных изменений и экономической неопределенности…>
Оч канцелярно. Ну и создается ощущение, что с приходом санкций у нас нет доступа к инструментам по качеству данных.
А потом посмотрел фотографии и сложилось впечатление, что DQ это какая-то старперская дисциплина, стало грустно.
Вы уж простите, немножко эйджизмом попахивает, но никого обидеть не хотел.
Автора можно закидать 💩 или написать свое мнение в комментариях к посту.
@ohymydataengineer
Дима из «Инжиниринг Данных» еще летом постил ссылку, только сейчас дошли руки прочитать и очень срезонировало. Я даже в пост вынесу ровно тот же вывод:
The core problem with working longer hours is that time is a finite resource. Energy is a different story.
(Сама статья тут https://hbr.org/2007/10/manage-your-energy-not-your-time. Она за пейволом, но две статьи в месяц бесплатно. Так что если вы не заходили на Harvard Business Review в этом месяце, то можно почитать в оригинале)
Идея в том, чтобы за основной ресурс и метрику брать не время, которое вы работаете, а сколько энергии вы расходуете И как ее эффективно восполняете. Можно целый день прокрастинировать и устать.
Источников энергии 4: тело, эмоции, мозг и дух. Поэтому занимаемся спортом, меньше фокусируемся на негативе, развиваемся и обучаемся, а также думаем о своей кукухе.
Очевидный бабаян, но хочется про него еще раз напомнить: ваша работа это не ваша жизнь, а с головой на плечах обеспечить себя достаточно для комфортной жизни вы всегда сможете. Херачить по 16 часов - оно того не стоит.
По себе заметил, насколько я стал продуктивней, когда стал думать об этом, чем тупо “ща еще пару часиков посижу” 💩
В коменты жду людей которые фигачат на 2 работах, подискутировать на тему денег)
@ohmydataengineer
The core problem with working longer hours is that time is a finite resource. Energy is a different story.
(Сама статья тут https://hbr.org/2007/10/manage-your-energy-not-your-time. Она за пейволом, но две статьи в месяц бесплатно. Так что если вы не заходили на Harvard Business Review в этом месяце, то можно почитать в оригинале)
Идея в том, чтобы за основной ресурс и метрику брать не время, которое вы работаете, а сколько энергии вы расходуете И как ее эффективно восполняете. Можно целый день прокрастинировать и устать.
Источников энергии 4: тело, эмоции, мозг и дух. Поэтому занимаемся спортом, меньше фокусируемся на негативе, развиваемся и обучаемся, а также думаем о своей кукухе.
Очевидный бабаян, но хочется про него еще раз напомнить: ваша работа это не ваша жизнь, а с головой на плечах обеспечить себя достаточно для комфортной жизни вы всегда сможете. Херачить по 16 часов - оно того не стоит.
По себе заметил, насколько я стал продуктивней, когда стал думать об этом, чем тупо “ща еще пару часиков посижу” 💩
В коменты жду людей которые фигачат на 2 работах, подискутировать на тему денег)
@ohmydataengineer
Telegram
Инжиниринг Данных
The core problem with working longer hours is that time is a finite resource. Energy is a different story. - цитата из статья HBR Manage Your Energy, Not Your Time
Совершенна другой угол обзора на насущную проблему - мы работаем много часов и устаем. Мы…
Совершенна другой угол обзора на насущную проблему - мы работаем много часов и устаем. Мы…
На LinkedIn попался пост, который хорошо лег в душеньку:
Every layoff of 2023 has been a fraction of new headcount added in 2022 alone.
It's not that 2H and 1H 2023 is weird, it's that 2020,2021 were deeply atypical
One of the questions we should be asking companies that hired so aggressively in 2022 is what were you thinking?
What data did you have that suggested Pandemic life was the new normal.
Есть такое выражение “Too big to fail”, которое значит что-то в стиле “Ну Сбербанк никуда не денется!”, то есть “Ну Гугл / Амазон / Мета не могут ошибаться, они очень большие и умные”.
Но, как мы видим, даже топы могут ошибаться. Ну и большие компании делали ошибки, которые приводили к их краху. Например, Nokia, Kodak. Где, например, гарантия того, что Metaverse от Меты выстрелит?
Ну и последнее: хорошие инженеры нужны всегда. Оверфитнутые на собесы в FAANG - останутся на обочине.
https://twitter.com/abstract_artem/status/1618207308919767041
Приходите в комменты сраться за лейофы!
@ohmydataengineer
Every layoff of 2023 has been a fraction of new headcount added in 2022 alone.
It's not that 2H and 1H 2023 is weird, it's that 2020,2021 were deeply atypical
One of the questions we should be asking companies that hired so aggressively in 2022 is what were you thinking?
What data did you have that suggested Pandemic life was the new normal.
Есть такое выражение “Too big to fail”, которое значит что-то в стиле “Ну Сбербанк никуда не денется!”, то есть “Ну Гугл / Амазон / Мета не могут ошибаться, они очень большие и умные”.
Но, как мы видим, даже топы могут ошибаться. Ну и большие компании делали ошибки, которые приводили к их краху. Например, Nokia, Kodak. Где, например, гарантия того, что Metaverse от Меты выстрелит?
Ну и последнее: хорошие инженеры нужны всегда. Оверфитнутые на собесы в FAANG - останутся на обочине.
https://twitter.com/abstract_artem/status/1618207308919767041
Приходите в комменты сраться за лейофы!
@ohmydataengineer
Минутка болезненной рефлексии..
В общем, когда в очередной раз я обнаружил, что мой календарь забит встречами с 8 утра до 6 вечера, я погрустнел. При этом я сознательно отдаю команде возможности полидировать какие-то направления и целые фичи, пытаюсь не быть узким горлышком, но все равно выходит какая-то ерунда.
Где-то что-то поломалось и пока я не понял, как починить. В попытках и поисках ответа на этот вопрос я зашел на сервис…ахаха думали тут реклама … я залез в интернет и накопал парочку интересных статей для рефлексии. Статьи интересные, но я все равно не понял про себя, правильно ли я делаю или нет. Вот такие вот пироги, сижу туплю в тупике 🤪
https://erik.wiffin.com/posts/limiting-work-in-progress-as-a-manager/
https://medium.com/illumination/back-to-back-meetings-create-an-illusion-of-productivity-why-the-best-leaders-keep-an-empty-adbb02abdc0f
@ohmydataengineer
В общем, когда в очередной раз я обнаружил, что мой календарь забит встречами с 8 утра до 6 вечера, я погрустнел. При этом я сознательно отдаю команде возможности полидировать какие-то направления и целые фичи, пытаюсь не быть узким горлышком, но все равно выходит какая-то ерунда.
Где-то что-то поломалось и пока я не понял, как починить. В попытках и поисках ответа на этот вопрос я зашел на сервис…
https://erik.wiffin.com/posts/limiting-work-in-progress-as-a-manager/
https://medium.com/illumination/back-to-back-meetings-create-an-illusion-of-productivity-why-the-best-leaders-keep-an-empty-adbb02abdc0f
@ohmydataengineer
erik.wiffin
Limiting Work In Progress as a Manager
The demands on a manager’s time are endless and sometimes it feels like you’re being pulled in every direction at once. These demands can make it hard to focus, they make it hard to move …
https://betterprogramming.pub/data-engineering-is-not-software-engineering-af81eb8d3949
А давайте посремся немножко?
Вот такой заголовок промелькнул в ленте у меня, глаза зацепились:
Data Engineering is Not Software Engineering
Pretending like data and software are the same is counterproductive to the success of your data engineers
Итак, какие аргументы приводит автор статьи?
- A Pipeline Is Either Completed or Worthless
Ну мы или поставили данные, или нихрена. Наполовину работающее приложение хоть как-то что-то делает пользователю, а вот наполовину отработанный пайплайн - нет. Если мы отправили 9 из 10 нужных колонок в базенку, это все равно бесполезно для DS, например.
- Feedback loops in pipeline development are glacial
Все просто. Если юнит тестов нет, жди пока закончится пайплайн и смотри глазами, что там с данными. В разработке без тестов очень больно, а в “датке” все привыкли писать пайплайны без них, потом разберемся!
- Pipeline Development Can Not Be Parallelized
Вы можете работать параллельно с кем-то над фичей в приложении, а вот над пайплайном - очень редкая практика.
Отсюда мой вопрос к вам (приходите в комменты): как вы считаете, data engineering != sowftware development или нет? Вы называете себя девелопером/разработчиком/инженером?
Или это все просто семантика, называйте меня как хотите, лишь бы $160k base salary?
@ohmydataengineer
А давайте посремся немножко?
Вот такой заголовок промелькнул в ленте у меня, глаза зацепились:
Data Engineering is Not Software Engineering
Pretending like data and software are the same is counterproductive to the success of your data engineers
Итак, какие аргументы приводит автор статьи?
- A Pipeline Is Either Completed or Worthless
Ну мы или поставили данные, или нихрена. Наполовину работающее приложение хоть как-то что-то делает пользователю, а вот наполовину отработанный пайплайн - нет. Если мы отправили 9 из 10 нужных колонок в базенку, это все равно бесполезно для DS, например.
- Feedback loops in pipeline development are glacial
Все просто. Если юнит тестов нет, жди пока закончится пайплайн и смотри глазами, что там с данными. В разработке без тестов очень больно, а в “датке” все привыкли писать пайплайны без них, потом разберемся!
- Pipeline Development Can Not Be Parallelized
Вы можете работать параллельно с кем-то над фичей в приложении, а вот над пайплайном - очень редкая практика.
Отсюда мой вопрос к вам (приходите в комменты): как вы считаете, data engineering != sowftware development или нет? Вы называете себя девелопером/разработчиком/инженером?
Или это все просто семантика, называйте меня как хотите, лишь бы $160k base salary?
@ohmydataengineer
Medium
Data Engineering is Not Software Engineering
Pretending like data and software are the same is counterproductive to the success of your data engineers
https://motherduck.com/blog/big-data-is-dead/
За последнюю неделю эту статью обсудили везде где только можно: во всех чатах, линкединах и пабликах. Если что, автор - один из founding engineers BigQuery, поэтому его слова, как минимум, не стоит игнорировать. Решил перечитать ее пару раз, вот на какие мысли наткнулся в своей головушке, в целом соглашаясь с автором:
Бигдата на самом деле не такая большая
Тут я с автором согласен. Подавляющее большинство компаний и команд, с которыми я общался, считают, что у них очень много данных и они обрабатывают петагигамегабайты, но на деле все сильно меньше. В погоне за хайпом и “у нас хранилище 400 Террабайт!” мы потеряли главный смысл - данные должны приносить пользу, а не лежать в json-гробах.
Compute нужно сильно меньше, даже когда растет Storage
Тут все тоже довольно просто: с легкой барской руки мы накидываем ворверов и экзекьюторов, потому что у нас хранилище увеличилось в 2 раза, но на деле нет прямой пропорциональной зависимости compute (вычислительные мощности) от storage (наших объемов хранилищ).
Данных много, а анализируем всего лишь небольшую часть
Тут можно разделить на две части:
- Базы данных умеют в оптимизацию достаточно хорошо, поэтому даже при плохом запросе умудряются уменьшать объем обрабатываемых данных
- Большинство данных очень важны за вчера, меньше за неделю, за месяц еще реже, за год данные нам нужны чаще всего только для больших корпоративных презентаций. Ну и сезонность / праздники иногда посчитать.
Очень порадовало определение “Big Data is when the cost of keeping data around is less than the cost of figuring out what to throw away”, проще хранить, чем тратить время и выяснять, а что можно удалить, а что по закону надо хранить 7 лет.
Ну и еще из классического: “if the date is older than 2019 use the revenue field, between 2019 and 2021 use the revenue_usd field, and after 2022 use the revenue_usd_audited field”.
В конце статьи есть прекрасный список вопросов, очень рациональный, по поводу внедрения бигдаты и всего этого красивого.
@ohmydataengineer
За последнюю неделю эту статью обсудили везде где только можно: во всех чатах, линкединах и пабликах. Если что, автор - один из founding engineers BigQuery, поэтому его слова, как минимум, не стоит игнорировать. Решил перечитать ее пару раз, вот на какие мысли наткнулся в своей головушке, в целом соглашаясь с автором:
Бигдата на самом деле не такая большая
Тут я с автором согласен. Подавляющее большинство компаний и команд, с которыми я общался, считают, что у них очень много данных и они обрабатывают петагигамегабайты, но на деле все сильно меньше. В погоне за хайпом и “у нас хранилище 400 Террабайт!” мы потеряли главный смысл - данные должны приносить пользу, а не лежать в json-гробах.
Compute нужно сильно меньше, даже когда растет Storage
Тут все тоже довольно просто: с легкой барской руки мы накидываем ворверов и экзекьюторов, потому что у нас хранилище увеличилось в 2 раза, но на деле нет прямой пропорциональной зависимости compute (вычислительные мощности) от storage (наших объемов хранилищ).
Данных много, а анализируем всего лишь небольшую часть
Тут можно разделить на две части:
- Базы данных умеют в оптимизацию достаточно хорошо, поэтому даже при плохом запросе умудряются уменьшать объем обрабатываемых данных
- Большинство данных очень важны за вчера, меньше за неделю, за месяц еще реже, за год данные нам нужны чаще всего только для больших корпоративных презентаций. Ну и сезонность / праздники иногда посчитать.
Очень порадовало определение “Big Data is when the cost of keeping data around is less than the cost of figuring out what to throw away”, проще хранить, чем тратить время и выяснять, а что можно удалить, а что по закону надо хранить 7 лет.
Ну и еще из классического: “if the date is older than 2019 use the revenue field, between 2019 and 2021 use the revenue_usd field, and after 2022 use the revenue_usd_audited field”.
В конце статьи есть прекрасный список вопросов, очень рациональный, по поводу внедрения бигдаты и всего этого красивого.
@ohmydataengineer
MotherDuck
Big Data is Dead - MotherDuck Blog
Big data is dead. Long live easy data.