Я не буду хитрым жуком и типа “я нашел эту статью сам, вот ссылка!”.
Случайно наткнулся на этот канал и конспекты больших статей - прямо очень топчинский контент. Хоть очень редко, но метко.
И нет, в тысячный раз, рекламы и платной джинсы в этом канале не будет никогда. Автору канала написал уже после того, как поставил пост в расписание )
Случайно наткнулся на этот канал и конспекты больших статей - прямо очень топчинский контент. Хоть очень редко, но метко.
И нет, в тысячный раз, рекламы и платной джинсы в этом канале не будет никогда. Автору канала написал уже после того, как поставил пост в расписание )
Forwarded from How to DWH with Python
Подготовил конспект статьи от Shopify о сетапе Airflow на 10 тысяч DAG'ов со 150 тысячами запусков в день. Сэкономит вам время на прочтении и поможет освежить в памяти в будущем.
#briefly #airflow Airflow: scaling out recommendations by Shopify
https://telegra.ph/Airflow-scaling-out-recommendations-by-Shopify-06-03
What's inside:
— Cloud Storage vs Network File System.
— Metadata retention policy.
— Manifest file.
— Consistent distribution of load.
— Concurrency management.
— Using different execution environments.
Origin: Lessons Learned From Running Apache Airflow at Scale
#briefly #airflow Airflow: scaling out recommendations by Shopify
https://telegra.ph/Airflow-scaling-out-recommendations-by-Shopify-06-03
What's inside:
— Cloud Storage vs Network File System.
— Metadata retention policy.
— Manifest file.
— Consistent distribution of load.
— Concurrency management.
— Using different execution environments.
Origin: Lessons Learned From Running Apache Airflow at Scale
Telegraph
Airflow: scaling out recommendations by Shopify
Shopify runs over 10k DAGs. 150k runs per day. Over 400 tasks at a given moment on average. This is a brief overview of their approach. Link to source article. Fast file access Problem: reading DAGs files from Google Cloud Storage (through GCSFuse as a filesystem…
Привет!
Меня не покидала мысль про расширение аудитории и в очередной раз мне про нее напомнили.
Я хочу доносить свои идеи про хороших инженеров, дата инженеринг и все вокруг этого до большего количества людей.
И кажется, 1000+ человек на русском языке - это отличный показатель, но постепенно наступает diminishing return (это я помню из игры в WoW, а никак не экономики 😁)
Можно, конечно, постить всякие мемосики, брать деньги за рекламу и вообще размазать фокус на все уровни, от тех, кто хочет войти в IT до матерых DBA, но мне не хочется делать ничего из этого.
Отсюда вылезает самый главный вопрос, который я задаю себе уже некоторое количество десятков раз - продолжить вести данный канал на русском языке или перевести его на английский? Паша Дуров говорит, что аудитория Telegram 700 миллионов, но чет мой пузырь состоит только из рускоязычных каналов….
Приходите в комментарии, потрем за развитие канала, накидайте своего фидбека не только про английский язык, но в целом про канал: зачем вы его читаете, что вы хотите тут видеть, а что лишнее?
Меня не покидала мысль про расширение аудитории и в очередной раз мне про нее напомнили.
Я хочу доносить свои идеи про хороших инженеров, дата инженеринг и все вокруг этого до большего количества людей.
И кажется, 1000+ человек на русском языке - это отличный показатель, но постепенно наступает diminishing return (это я помню из игры в WoW, а никак не экономики 😁)
Можно, конечно, постить всякие мемосики, брать деньги за рекламу и вообще размазать фокус на все уровни, от тех, кто хочет войти в IT до матерых DBA, но мне не хочется делать ничего из этого.
Отсюда вылезает самый главный вопрос, который я задаю себе уже некоторое количество десятков раз - продолжить вести данный канал на русском языке или перевести его на английский? Паша Дуров говорит, что аудитория Telegram 700 миллионов, но чет мой пузырь состоит только из рускоязычных каналов….
Приходите в комментарии, потрем за развитие канала, накидайте своего фидбека не только про английский язык, но в целом про канал: зачем вы его читаете, что вы хотите тут видеть, а что лишнее?
https://habr.com/ru/company/jugru/blog/670018/
Какое-то время назад я постил пару статей (раз и два - https://news.1rj.ru/str/ohmydataengineer/210) на тему сеньорности и того, как вырасти в хорошего инженера. На глаза мне попалась еще одна статья на эту тему, но уже на русском (вообще, это был доклад на DotNet-конференции, там внутри есть ссылка на на его).
Интересный момент: заявление на скриншоте противоречит заявлению из второй статьи. Вот это поворот!
Наблюдая за коллегами, менторю потихоньку, стараюсь заложить им в голову похожие принципы.
Потому что, когда-то, мой ментор что-то похожее закладывал в меня и мне это очень помогло.
@ohmydataengineer
Какое-то время назад я постил пару статей (раз и два - https://news.1rj.ru/str/ohmydataengineer/210) на тему сеньорности и того, как вырасти в хорошего инженера. На глаза мне попалась еще одна статья на эту тему, но уже на русском (вообще, это был доклад на DotNet-конференции, там внутри есть ссылка на на его).
Интересный момент: заявление на скриншоте противоречит заявлению из второй статьи. Вот это поворот!
Наблюдая за коллегами, менторю потихоньку, стараюсь заложить им в голову похожие принципы.
Потому что, когда-то, мой ментор что-то похожее закладывал в меня и мне это очень помогло.
@ohmydataengineer
https://www.youtube.com/watch?v=srP-DkkJWRc
Так, в мае 2019 года я ходил в подкаст MoscowPython и тогда мы болтали про всякое. Выпуск, кстати, стал самым популярным среди всех выпусков подкаста.
Спустя 3 года я снова решил зайти в гости к своим друзьям, мы поболтали про ML & Data Ops, про мой карьерный путь и про то, как получать больше денег, при этом не прыгая с работы на работу. Конечно, не оч получилось поговорить про все детально, но, надеюсь, вам понравится.
Приходите кидаться помидорами в комменты сюда или к видео.
@ohmydataengineer
Так, в мае 2019 года я ходил в подкаст MoscowPython и тогда мы болтали про всякое. Выпуск, кстати, стал самым популярным среди всех выпусков подкаста.
Спустя 3 года я снова решил зайти в гости к своим друзьям, мы поболтали про ML & Data Ops, про мой карьерный путь и про то, как получать больше денег, при этом не прыгая с работы на работу. Конечно, не оч получилось поговорить про все детально, но, надеюсь, вам понравится.
Приходите кидаться помидорами в комменты сюда или к видео.
@ohmydataengineer
YouTube
Moscow Python Podcast. ML и DataOps (level: all)
В гостях у Moscow Python Podcast MLOps и DataOps Дead компании Gett Семён Осипов. Поговорили с Семёном о его пути в разработке и что такое MLOps и DataOps и зачем он нужен.
Ведущие выпуска — сооснователь MoscowPython и компании Geekfactor.io Валентин Домбровский…
Ведущие выпуска — сооснователь MoscowPython и компании Geekfactor.io Валентин Домбровский…
👍3
https://dataproducts.substack.com/p/datas-collaboration-problem
Как по живому.
Смотришь иногда какие-то доклады по хранилищам и у всех там все прекрасно, mesh, fabric, вся фигня.
А на деле, у большинства такое болото. А я то думал, что это только мне не везет.
В погоне за всеми модными тулзами и growth, мы подзабили на модели, на архитектуру, на качество хранилища, закидав все деньгами. Не надо так!
Не тащите Modern Data Stack только потому, что он Modern…
@ohmydataengineer
Как по живому.
Смотришь иногда какие-то доклады по хранилищам и у всех там все прекрасно, mesh, fabric, вся фигня.
А на деле, у большинства такое болото. А я то думал, что это только мне не везет.
В погоне за всеми модными тулзами и growth, мы подзабили на модели, на архитектуру, на качество хранилища, закидав все деньгами. Не надо так!
Не тащите Modern Data Stack только потому, что он Modern…
@ohmydataengineer
Data Products
Data's Collaboration Problem
And Why the Modern Data Stack Can't Scale Without Fixing It
https://habr.com/ru/post/671058/
И еще одна тема для жаркого спора про то, как выглядит хороший инженер. В последнем выпуске подкаста я вскольз затрагивал эту тему: чем больше вы вовлекаетесь в продукт, тем больше вас ценят и если это правильно использовать, то вам за это больше платят.
Я поддерживаю автора статьи за позицию “product engineer” - ты работаешь на благо продукта и гордись тем, что ты делаешь. Всегда старайся сделать это лучше и выгодней для продукта и компании.
Однако, в комментах есть люди (да и среди моих читателей тоже), которые придерживаются позиции “Моя хата с краю, дайте мне тикет нормально описанный, я отвечаю лишь за код, а все остальное - проблемы других людей”. Тоже валидная позиция.
Приходите в комментарии высказаться про то, манипуляция ли это со стороны компании или что-то иное?
@ohmydataengineer
И еще одна тема для жаркого спора про то, как выглядит хороший инженер. В последнем выпуске подкаста я вскольз затрагивал эту тему: чем больше вы вовлекаетесь в продукт, тем больше вас ценят и если это правильно использовать, то вам за это больше платят.
Я поддерживаю автора статьи за позицию “product engineer” - ты работаешь на благо продукта и гордись тем, что ты делаешь. Всегда старайся сделать это лучше и выгодней для продукта и компании.
Однако, в комментах есть люди (да и среди моих читателей тоже), которые придерживаются позиции “Моя хата с краю, дайте мне тикет нормально описанный, я отвечаю лишь за код, а все остальное - проблемы других людей”. Тоже валидная позиция.
Приходите в комментарии высказаться про то, манипуляция ли это со стороны компании или что-то иное?
@ohmydataengineer
Хабр
Почему разработчик должен владеть продуктом и как это сделает его счастливым
Привет! Я уже 10 лет работаю программистом, успел поработать в разных компаниях — продуктовых и аутсорсинговых, больших и маленьких. Последние три года я ещё и менеджер — управляю командой...
👍2
ООООО! Гартнер выкатил “свежий” обзор текущих технологий и подходов в работе с данными, и это, если честно, очень смешно.
Самые забавные моменты, что мне бросились в глаза:
Data Mesh is obsolete. То у меня все лидеры мнений в линкедине постят про Data Mesh и Data Fabric, а то половина из этого, оказывается, уже устарела, даже не зайдя на хайп, а вторая летит в трубу.
Data Stewardship тоже устарело. Кхм, а не вы ли продвигали кровавому энтерпрайзу, что вам надо заводить Data Stewards?
Data Observability в самом начале пути..
Половина технологий - вообще какой-то странный набор хайпослов, ничего не имеющих общего с реальностью.
Поэтому, как только вам ваш CDO начинает задвигать что-то в стиле “Мы взяли 3-4 приложения из верхнего правого квадранта Гартнера”, это повод задуматься о текущем состоянии дел.
Ах, да. Data Engineering сейчас на самом “дне разочарования”.
@ohmydataengineer
Самые забавные моменты, что мне бросились в глаза:
Data Mesh is obsolete. То у меня все лидеры мнений в линкедине постят про Data Mesh и Data Fabric, а то половина из этого, оказывается, уже устарела, даже не зайдя на хайп, а вторая летит в трубу.
Data Stewardship тоже устарело. Кхм, а не вы ли продвигали кровавому энтерпрайзу, что вам надо заводить Data Stewards?
Data Observability в самом начале пути..
Половина технологий - вообще какой-то странный набор хайпослов, ничего не имеющих общего с реальностью.
Поэтому, как только вам ваш CDO начинает задвигать что-то в стиле “Мы взяли 3-4 приложения из верхнего правого квадранта Гартнера”, это повод задуматься о текущем состоянии дел.
Ах, да. Data Engineering сейчас на самом “дне разочарования”.
@ohmydataengineer
👍2
https://blog.dataminded.com/why-rising-cloud-costs-are-the-silent-killers-of-data-platforms-52a98b371f28
Статья хоть и написана людьми ради продвижения своего продукта, однако в целом, очень правдивая. Snowflake, Databricks и все остальные платформы наглядно нам показывают, как быстро можно раздуть свой бюджет на овердофига тысяч долларов.
Несколько раз уже видел, как казалось бы несложные платформы и относительно простые ETL (а еще и интеграции всякие и другие cloud решения) очень быстренько кушают годовой бюджет.
Потому что что? Правильно, долгое время нам позволяли закидывать проблемы деньгами, вместо того, чтобы сразу делать нормально.
@ohmydataengineer
Статья хоть и написана людьми ради продвижения своего продукта, однако в целом, очень правдивая. Snowflake, Databricks и все остальные платформы наглядно нам показывают, как быстро можно раздуть свой бюджет на овердофига тысяч долларов.
Несколько раз уже видел, как казалось бы несложные платформы и относительно простые ETL (а еще и интеграции всякие и другие cloud решения) очень быстренько кушают годовой бюджет.
Потому что что? Правильно, долгое время нам позволяли закидывать проблемы деньгами, вместо того, чтобы сразу делать нормально.
@ohmydataengineer
Medium
Why rising cloud costs are the silent killers of data platforms
Building data platforms in the cloud is changing. Gone are the days that you would manually set up a few EC2 instances and run some modest…
🔥5
https://medium.com/miro-engineering/our-journey-to-data-engineering-monitoring-c14d6ff20351
О! Моя любимая тема - monitoring & observability. Я был шокирован, когда распрашивал людей о том, что и как они мониторят в части данных. Чаще всего ответ был: “Да там у девопсов настроены алерты!”. Дай боже половина людей имела уведомления в Slack о том, что у них упал какой-то пайплайн.
Поэтому если вы думаете начать, наконец-то!, мониторить свои data-компоненты, вот прекрасная статья о том, как это сделали в Miro.
@ohmydataengineer
О! Моя любимая тема - monitoring & observability. Я был шокирован, когда распрашивал людей о том, что и как они мониторят в части данных. Чаще всего ответ был: “Да там у девопсов настроены алерты!”. Дай боже половина людей имела уведомления в Slack о том, что у них упал какой-то пайплайн.
Поэтому если вы думаете начать, наконец-то!, мониторить свои data-компоненты, вот прекрасная статья о том, как это сделали в Miro.
@ohmydataengineer
Medium
Miro Data Engineering team’s journey to monitoring
Co-authored by Ricardo Souza.
👍2
Datacamp (это вот эти https://www.datacamp.com/) с 18 по 24 июля делает все свои курсы открытыми и бесплатными.
Даже карточку привязывать не надо.
Если есть время, то можно успеть пройти какой-нибудь из из курсов
@ohmydataengineer
Даже карточку привязывать не надо.
Если есть время, то можно успеть пройти какой-нибудь из из курсов
@ohmydataengineer
👍8🔥5
https://clck.ru/sJ4eM
Тинькофф проводит очередной митап по работа с данными, 21 июля. В этот раз следующие темы:
Под капотом каталога данных
Это доклад самих ребят про их Data Detective - каталог данных. Расширенная и дополненная версия доклада с Хайлоада https://highload.ru/foundation/2022/abstracts/8105
Как с помощью Data Mesh разломать ваше DWH
Яндекс GO про модную и хайповую тему. Послушать стоит потому, чтобы понимать, а нужно ли вам вообще это внедрять или “да ну его нафиг!”
Как мы строим Metadata Management
Еще один доклад от ребят и девчат из Т. На этот раз про метаданные
Data-docs — как найти данные о данных
Наконец, Авито, тоже про каталоги данных и документацию данных.
В общем, 3 из 4 тем это главную проблему текущего состояния индустрии: бигдату мы внедрили, стриминги накатили, каргокульта добавили, а теперь нифига не понимаем, где у нас и что лежит и в каком состоянии.
Встреча будет оффлайн и онлайн трансляция. Регистрация по ссылке
Тинькофф проводит очередной митап по работа с данными, 21 июля. В этот раз следующие темы:
Под капотом каталога данных
Это доклад самих ребят про их Data Detective - каталог данных. Расширенная и дополненная версия доклада с Хайлоада https://highload.ru/foundation/2022/abstracts/8105
Как с помощью Data Mesh разломать ваше DWH
Яндекс GO про модную и хайповую тему. Послушать стоит потому, чтобы понимать, а нужно ли вам вообще это внедрять или “да ну его нафиг!”
Как мы строим Metadata Management
Еще один доклад от ребят и девчат из Т. На этот раз про метаданные
Data-docs — как найти данные о данных
Наконец, Авито, тоже про каталоги данных и документацию данных.
В общем, 3 из 4 тем это главную проблему текущего состояния индустрии: бигдату мы внедрили, стриминги накатили, каргокульта добавили, а теперь нифига не понимаем, где у нас и что лежит и в каком состоянии.
Встреча будет оффлайн и онлайн трансляция. Регистрация по ссылке
Т-Банк Митапы
Митап IT’s Tinkoff Data Meetup
Управляем данными
👍11👎3🔥1
https://www.youtube.com/playlist?list=PLTPXxbhUt-YVWi_cf2UUDc9VZFLoRgu0l
Databricks выкатили видео с Data + AI Summit 2022. в США.
В плейлисте по ссылке >300 (!) сессий.
Доклады на всевозможные темы: от классических “How to test your ETL pipelines” до экзотических “Sound Data Engineering in Rust”
@ohmydataengineer
Databricks выкатили видео с Data + AI Summit 2022. в США.
В плейлисте по ссылке >300 (!) сессий.
Доклады на всевозможные темы: от классических “How to test your ETL pipelines” до экзотических “Sound Data Engineering in Rust”
@ohmydataengineer
YouTube
Data + AI Summit 2022 North America/Virtual - All Sessions
Share your videos with friends, family, and the world
🔥14👍7
Часто-заголядывающая рубрика в моем бложике - про карьеру.
Читая книжку 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
Читая книжку 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
Lethain
Downturn career decisions.
When I joined Yahoo In 2008, I received a small number of options. I don’t remember how many–it was very few–but I do know my strike price was roughly $16. I don’t remember that because my strike price was particularly lucrative, but rather because some of…
👍8
Так, я тут буквально недавно кидал статью про то, что проблемы с данными есть у всех. И костыли есть у всех, причем иногда целая фабрика костылей.
Ты такой сидишь и думаешь: “Блин, ну это только у нас так! У других все нормально!”. А вот и нет. Вот пример систематических проблем по всей индустрии:
- “Наша инфраструктура для данных ерунда!” - Кажется, что вы используете неправильные тулы и вообще ваша DWH тормозит. На деле большие компании имеют свойство закидывать проблему людьми и ресурсами, поэтому у них работает.
- “А кто за эту табличку отвечает?” - Первыми по башке прилетает всегда дата команде: “А что за херня у вас с данными?”. А то, что поставщик данных, из соседней команды, льющий все в data lake, что-то там неожиданно поменял и никому не сказал - никого не волнует. Люди не хотят брать отвественность за данные.
- “А почему так долго?” - Пользователи хотят как можно быстрей пользоваться данными, а инженеры хотят построить систему, которая не сломается от того, что вместо Null стали прилетать 0 в конкретное поле. Вечная борьба сроков и качества, где чаще всего побеждает первое, к сожалению.
Из этого всего вылезает еще один пункт:
- “А давайте всех научим SQL!” - ага, и выпустим в поле DWH, твори что хочешь! Конечно, знание SQL это прекрасно, и если каждый сможет самостоятельно что-то поглядеть в хранилище. Но для начала нужно все разложить по полочкам, раздать верные уровни доступа и ресурсы, иначе потом у вас будет 300 копий одной и той же метрики в разных таблицах и схемах.
Вольный перевод с отсебятиной вот этой статьи.
@ohmydataenginer
Ты такой сидишь и думаешь: “Блин, ну это только у нас так! У других все нормально!”. А вот и нет. Вот пример систематических проблем по всей индустрии:
- “Наша инфраструктура для данных ерунда!” - Кажется, что вы используете неправильные тулы и вообще ваша DWH тормозит. На деле большие компании имеют свойство закидывать проблему людьми и ресурсами, поэтому у них работает.
- “А кто за эту табличку отвечает?” - Первыми по башке прилетает всегда дата команде: “А что за херня у вас с данными?”. А то, что поставщик данных, из соседней команды, льющий все в data lake, что-то там неожиданно поменял и никому не сказал - никого не волнует. Люди не хотят брать отвественность за данные.
- “А почему так долго?” - Пользователи хотят как можно быстрей пользоваться данными, а инженеры хотят построить систему, которая не сломается от того, что вместо Null стали прилетать 0 в конкретное поле. Вечная борьба сроков и качества, где чаще всего побеждает первое, к сожалению.
Из этого всего вылезает еще один пункт:
- “А давайте всех научим SQL!” - ага, и выпустим в поле DWH, твори что хочешь! Конечно, знание SQL это прекрасно, и если каждый сможет самостоятельно что-то поглядеть в хранилище. Но для начала нужно все разложить по полочкам, раздать верные уровни доступа и ресурсы, иначе потом у вас будет 300 копий одной и той же метрики в разных таблицах и схемах.
Вольный перевод с отсебятиной вот этой статьи.
@ohmydataenginer
Telegram
Труба данных
https://dataproducts.substack.com/p/datas-collaboration-problem
Как по живому.
Смотришь иногда какие-то доклады по хранилищам и у всех там все прекрасно, mesh, fabric, вся фигня.
А на деле, у большинства такое болото. А я то думал, что это только мне не…
Как по живому.
Смотришь иногда какие-то доклады по хранилищам и у всех там все прекрасно, mesh, fabric, вся фигня.
А на деле, у большинства такое болото. А я то думал, что это только мне не…
👍13🔥5
https://blog.bytebytego.com/
Я как-то ранее писал про Gergely Orosz (aka Венгр) с его очень хорошей рассылкой The Pragmatic Engineer. Судя по статистике Substack, его подписка самая популярная среди Tech категории. Однако у него появился серьезный конкурент: ByteByteGo. Ребята довольно детально, с картинками, рассказывают как устроены сложные системы. Для понимания System Design - отличное чтиво, вмеру простое, вмеру погруженное.
Примеры рассматриваемых тем:
- What happens when you swipe a credit card?
- SOAP vs REST vs GraphQL vs RPC detailed comparison
- Top caching strategies
- и т.д.
@ohmydataengineer
Я как-то ранее писал про Gergely Orosz (aka Венгр) с его очень хорошей рассылкой The Pragmatic Engineer. Судя по статистике Substack, его подписка самая популярная среди Tech категории. Однако у него появился серьезный конкурент: ByteByteGo. Ребята довольно детально, с картинками, рассказывают как устроены сложные системы. Для понимания System Design - отличное чтиво, вмеру простое, вмеру погруженное.
Примеры рассматриваемых тем:
- What happens when you swipe a credit card?
- SOAP vs REST vs GraphQL vs RPC detailed comparison
- Top caching strategies
- и т.д.
@ohmydataengineer
👍16🔥4
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
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
👍7🔥1
SmartData - конференция для Дата Инженеров.
“О нееет, реклама! А говорил, что не продашься! И вообще ты самый последний, кто запостил эту новость, все с тобой понятно!”
А вот и нет! С ребятами из JUG мы знакомы давно и никаких денег за рекламу единственной в РФ конфы для дата инженеров я не собирался брать.
Ребята открыли CFP - Call For Papers - то есть можно подавать заявки на доклады. Если помните, какое-то время назад я делал опрос про то, о чем написать. Тогда победил всеми любимый DBT. И если вы думаете, что я забил, то ни-фи-га. Я не только не забил, но даже почти притащил DBT в компанию. Осталось презентовать и раскатить 😋 (мы честно, в связи с нагрузкой, презентацию переносили аж полтора месяца). И про вот это все я как раз и хочу рассказать, подав свой доклад на конфу. Ну, а если не пройду, то пойду сам на очную часть, которая пройдет в Питере.
Думаю, докладик будет простого/среднего уровня, как раз разбавит хардкорные доклады.
Кстати, даже если не пойдете, то все доклады с SmartData доступны на Youtube: за 2021 год, за 2020 год.
Билеты по базовой цене - тут
@ohmydataengineer
“О нееет, реклама! А говорил, что не продашься! И вообще ты самый последний, кто запостил эту новость, все с тобой понятно!”
А вот и нет! С ребятами из JUG мы знакомы давно и никаких денег за рекламу единственной в РФ конфы для дата инженеров я не собирался брать.
Ребята открыли CFP - Call For Papers - то есть можно подавать заявки на доклады. Если помните, какое-то время назад я делал опрос про то, о чем написать. Тогда победил всеми любимый DBT. И если вы думаете, что я забил, то ни-фи-га. Я не только не забил, но даже почти притащил DBT в компанию. Осталось презентовать и раскатить 😋 (мы честно, в связи с нагрузкой, презентацию переносили аж полтора месяца). И про вот это все я как раз и хочу рассказать, подав свой доклад на конфу. Ну, а если не пройду, то пойду сам на очную часть, которая пройдет в Питере.
Думаю, докладик будет простого/среднего уровня, как раз разбавит хардкорные доклады.
Кстати, даже если не пойдете, то все доклады с SmartData доступны на Youtube: за 2021 год, за 2020 год.
Билеты по базовой цене - тут
@ohmydataengineer
SmartData 2024. Конференция по инженерии данных
SmartData 2024 | Подача заявки на доклад | Конференция по инженерии данных
Всё о том, как стать спикером SmartData 2024: как подать заявку, как выбрать тему, какие доклады подойдут, как выглядит процесс рассмотрения
👍4🔥3
В очередной раз про хороших инженеров…
В мой последний поход в подкаст я говорил о том, как инженерам расти по зарплате / грейдам / whatever внутри компании или, как говорится, “за всё хорошее против всего плохого”.
После этого выпуска мне в личку пришли несколько человек и задали вопрос: “Собственно, а как ты берешь на себя больше ответственности? Еще один пайплайн поддерживаешь? А потом еще базенку берешь деплоить и мониторить? Так на это все времени не хватит!”
Здесь есть маленький секрет: кроме классических “возьму на себя дополнительной работы, буду по ночам Spark деплоить”, есть другой подход. Выглядит он примерно следующим образом:
- Находим раздражающую вас вещь: деплой приложения, запуск тестов, проверка кода, как проходят стендапы
Совершенно не важно, что это будет, главное, что это мешает команде двигаться быстрей, что это тормозит процесс или просто раздражает разработчиков.
- Если возможно, фиксим сразу (автоматизация, документация, рефакт). Если моментальный фикс невозможен (дейли стендапы), то предлагаем команде провести эксперимент и сделать неделю “иначе”.
Или мы сразу в дамки и все нас благодарят, что сделал процесс чуть приятней и быстрей, или мы соберем обратную связь, что и как нам мешает, посмотрим на наш процесс с другой стороны и чуточку улучшим его.
И если мы берем ответственность за свои факапы, объясняем почему так произошло и что мы сделаем для того, чтобы это не повторилось - тем больше к нам доверия. Чем больше к нам доверия, тем бОльше изменения в процессах нам позволяют сделать. Чем бОльше изменения, тем бОльше их позитивное влияние на продукт. Чем бОльше влияние на продукт, тем больше у вас аргументов для разговора с руководителем про свою компенсацию и рост.
Навеяно постом из блога Senior Developer Mindset про Trust / Responsibility.
@ohmydataengineer
В мой последний поход в подкаст я говорил о том, как инженерам расти по зарплате / грейдам / whatever внутри компании или, как говорится, “за всё хорошее против всего плохого”.
После этого выпуска мне в личку пришли несколько человек и задали вопрос: “Собственно, а как ты берешь на себя больше ответственности? Еще один пайплайн поддерживаешь? А потом еще базенку берешь деплоить и мониторить? Так на это все времени не хватит!”
Здесь есть маленький секрет: кроме классических “возьму на себя дополнительной работы, буду по ночам Spark деплоить”, есть другой подход. Выглядит он примерно следующим образом:
- Находим раздражающую вас вещь: деплой приложения, запуск тестов, проверка кода, как проходят стендапы
Совершенно не важно, что это будет, главное, что это мешает команде двигаться быстрей, что это тормозит процесс или просто раздражает разработчиков.
- Если возможно, фиксим сразу (автоматизация, документация, рефакт). Если моментальный фикс невозможен (дейли стендапы), то предлагаем команде провести эксперимент и сделать неделю “иначе”.
Или мы сразу в дамки и все нас благодарят, что сделал процесс чуть приятней и быстрей, или мы соберем обратную связь, что и как нам мешает, посмотрим на наш процесс с другой стороны и чуточку улучшим его.
И если мы берем ответственность за свои факапы, объясняем почему так произошло и что мы сделаем для того, чтобы это не повторилось - тем больше к нам доверия. Чем больше к нам доверия, тем бОльше изменения в процессах нам позволяют сделать. Чем бОльше изменения, тем бОльше их позитивное влияние на продукт. Чем бОльше влияние на продукт, тем больше у вас аргументов для разговора с руководителем про свою компенсацию и рост.
Навеяно постом из блога Senior Developer Mindset про Trust / Responsibility.
@ohmydataengineer
👍25🔥5