Последние несколько лет ежедневные стендапы по 20-30 минут стали для меня невыносимы.
Они бывают разными:
• Каждый день можно выходить к доске и переклеивать sticky notes, если вы работаете в офисе.
• Online-встречи с коллегами, где каждый делает вид, что рассказывает, что он сделал вчера и что будет делать сегодня.
• Иногда проходят встречи для cross-команд, и тогда эта канитель занимает не 15-20 минут, а 30-40 минут. У нас было так: нужно было назвать следующего человека, вести учет из 20-25 людей, кто уже говорил, а кто — нет… Для меня это был настоящий челлендж.
• Когда я работал на ГКНПЦ им. Хруничева в должности мастера участка механообработки, каждое утро я обходил токарей, фрезеровщиков и слесарей, жал им руку и спрашивал про прогресс. К сожалению, они не собирались у доски, и мне приходилось искать их по цеху. Это тоже был своеобразный, но бесполезный стендап.
В общем, за последние два года я осознал, насколько круто проводить полностью асинхронные стендапы, где каждый пишет в thread в Slack о своём прогрессе. Это сразу освобождает больше времени на работу.
Кстати, такой метод внедрил один из моих бывших менеджеров, который много лет проработал в Meta, а до этого вышел на IPO вместе с Lyft и смог купить домик в Сиэтле за 4 миллиона долларов. Он был противником бесполезных встреч и сделал все нудные процессы полностью асинхронными. Это оказалось очень эффективно.
Очевидно, что это хорошо работает с опытными специалистами. А как быть с новичками и стажерами? Здесь лучше иметь onboard-бадди или ментора, который будет работать с ними над задачами.
Теперь у меня всё просто: если на митинге больше четырёх человек, включая меня, на 99% он бесполезен, и можно не ходить. Точнее, присутствовать надо, но мыслями и делами быть в другом месте, то есть заниматься работой.
А как у вас обстоят дела с ежедневными стендапами и другими церемониями?
Они бывают разными:
• Каждый день можно выходить к доске и переклеивать sticky notes, если вы работаете в офисе.
• Online-встречи с коллегами, где каждый делает вид, что рассказывает, что он сделал вчера и что будет делать сегодня.
• Иногда проходят встречи для cross-команд, и тогда эта канитель занимает не 15-20 минут, а 30-40 минут. У нас было так: нужно было назвать следующего человека, вести учет из 20-25 людей, кто уже говорил, а кто — нет… Для меня это был настоящий челлендж.
• Когда я работал на ГКНПЦ им. Хруничева в должности мастера участка механообработки, каждое утро я обходил токарей, фрезеровщиков и слесарей, жал им руку и спрашивал про прогресс. К сожалению, они не собирались у доски, и мне приходилось искать их по цеху. Это тоже был своеобразный, но бесполезный стендап.
В общем, за последние два года я осознал, насколько круто проводить полностью асинхронные стендапы, где каждый пишет в thread в Slack о своём прогрессе. Это сразу освобождает больше времени на работу.
Кстати, такой метод внедрил один из моих бывших менеджеров, который много лет проработал в Meta, а до этого вышел на IPO вместе с Lyft и смог купить домик в Сиэтле за 4 миллиона долларов. Он был противником бесполезных встреч и сделал все нудные процессы полностью асинхронными. Это оказалось очень эффективно.
Очевидно, что это хорошо работает с опытными специалистами. А как быть с новичками и стажерами? Здесь лучше иметь onboard-бадди или ментора, который будет работать с ними над задачами.
Теперь у меня всё просто: если на митинге больше четырёх человек, включая меня, на 99% он бесполезен, и можно не ходить. Точнее, присутствовать надо, но мыслями и делами быть в другом месте, то есть заниматься работой.
А как у вас обстоят дела с ежедневными стендапами и другими церемониями?
💯91🙈6👨💻5💘4 2
This media is not supported in the widget
VIEW IN TELEGRAM
6⚡128🙉19🫡15 13🦄10👾6🐳3👨💻3🗿3🍌2😈1
Увидел пост в Linkedin и перевел его в chatgpt:
Я прочитал прогноз, что к 2030 году 80% разработчиков программного обеспечения будут заменены ИИ (или, что в противном случае, зарплаты сильно снизятся).
Я также посмотрел видео на YouTube, где один парень заказал приложение у разработчиков, работающих с no-code решениями, которые оказались быстрее, дешевле и лучше, чем обычные разработчики.
Я использую и Copilot, и ChatGPT в своей работе, но все же считаю себя разработчиком программного обеспечения, и хотя я нахожу эти инструменты потрясающими, мне сложно представить, как подобные прогнозы и утверждения могут стать реальностью, особенно в такие короткие сроки.
Буду благодарен за советы, чего я не замечаю! Какие-то конкретные прорывы или разработки помимо Copilot и ChatGPT, рабочие процессы или интеграции?
Вопрос понятный и актуальный. Мне понравился коммент от Gergely Orosz (автор The Pragmatic Engineer):
Обратите внимание на то, кто делает такие прогнозы. Я вижу подобные предсказания почти исключительно от людей, работающих в компаниях с венчурным финансированием, создающих такие инструменты (их успех зависит от этого прогноза), от венчурных инвесторов, вкладывающих средства в те же компании, и от людей, которые не занимаются разработкой день за днем с использованием этих инструментов.
Я спросил разработчиков, которые используют эти инструменты каждый день, и почувствовал суровую реальность по сравнению со всем этим хайпом: ссылка.
От себя добавлю, что мне сложно предсказать, что будет с индустрией через пять лет. Возможно, такие опытные специалисты, как я, с пятнадцатилетним стажем выполнения примерно одних и тех же задач, будут востребованы в каком-то объеме. Однако начинать карьеру в качестве junior analyst в 2030 году, скорее всего, станет сложнее. Возможно, не столько из-за AI, сколько из-за количества кандидатов на рынке, которые прошли (и заплатили большие деньги) курсы и получили сертификат, подтверждающий, что они готовы "грызть" данные.
Сейчас я на собственном опыте вижу, что ChatGPT и Copilot иногда помогают мне выполнять работу быстрее, но явно не лучше. Качество работы зависит от опыта и навыков.
Например, у меня на велосипеде почти год не работал гидравлический тормоз. Я пытался его починить в мастерской, но мне говорили, что придется ждать неделю, чтобы просто прокачать масло. В итоге, времени все не хватало. И тут я зашел в небольшой магазин, и мастер за 5 минут и 10 долларов устранил проблему. Оказалось, что на моем gravel bike можно регулировать ручку тормоза под длину пальцев, и у меня она была неправильно настроена, из-за чего тормоз не работал.
То есть, у него многолетний опыт, и он видит всю картину целиком. Я бы заплатил ему и 50 долларов за 10 минут работы, потому что он действительно профессионал в своем деле.
Возвращаясь к AI, по моему скромному мнению, эти инструменты пока еще плохо воспринимают (бизнес-) контекст и общую картину. Они решают точечные задачи и автоматизируют узкие бизнес-процессы (например, поддержку).
В аналитике, как правило, очень широкий и уникальный контекст. AI может создать pipeline, дашборд, собрать метрики, но пока это еще далеко от реальности, и крупные компании не скоро смогут это внедрить. До сих пор многие компании используют Teradata/Oracle с 90-х годов. У них огромные бюджеты на AI, которые раньше тратились на ML, Big Data, Cloud и т.д.
В целом, нам не стоит беспокоиться по этому поводу, ведь мы не можем контролировать этот процесс. Но мы можем контролировать свою гибкость и всегда быть открытыми к новому (гибкое мышление), чтобы учиться и развиваться, о чем я часто пишу в этом канале.
Нашим детям будет сложнее, и все, что мы можем сделать для них — это создать комфортные условия для учебы и спорта. Математика, чтение, языки и спорт — и все будет отлично!
Ладно, а как вы себе представляете AI-апокалипсис?
Лично я больше боюсь землетрясения, которое уж точно лишит всех работы в IT, как это уже бывало раньше - The M9 Cascadia Megathrust Earthquake of January 26, 1700
Я прочитал прогноз, что к 2030 году 80% разработчиков программного обеспечения будут заменены ИИ (или, что в противном случае, зарплаты сильно снизятся).
Я также посмотрел видео на YouTube, где один парень заказал приложение у разработчиков, работающих с no-code решениями, которые оказались быстрее, дешевле и лучше, чем обычные разработчики.
Я использую и Copilot, и ChatGPT в своей работе, но все же считаю себя разработчиком программного обеспечения, и хотя я нахожу эти инструменты потрясающими, мне сложно представить, как подобные прогнозы и утверждения могут стать реальностью, особенно в такие короткие сроки.
Буду благодарен за советы, чего я не замечаю! Какие-то конкретные прорывы или разработки помимо Copilot и ChatGPT, рабочие процессы или интеграции?
Вопрос понятный и актуальный. Мне понравился коммент от Gergely Orosz (автор The Pragmatic Engineer):
Обратите внимание на то, кто делает такие прогнозы. Я вижу подобные предсказания почти исключительно от людей, работающих в компаниях с венчурным финансированием, создающих такие инструменты (их успех зависит от этого прогноза), от венчурных инвесторов, вкладывающих средства в те же компании, и от людей, которые не занимаются разработкой день за днем с использованием этих инструментов.
Я спросил разработчиков, которые используют эти инструменты каждый день, и почувствовал суровую реальность по сравнению со всем этим хайпом: ссылка.
От себя добавлю, что мне сложно предсказать, что будет с индустрией через пять лет. Возможно, такие опытные специалисты, как я, с пятнадцатилетним стажем выполнения примерно одних и тех же задач, будут востребованы в каком-то объеме. Однако начинать карьеру в качестве junior analyst в 2030 году, скорее всего, станет сложнее. Возможно, не столько из-за AI, сколько из-за количества кандидатов на рынке, которые прошли (и заплатили большие деньги) курсы и получили сертификат, подтверждающий, что они готовы "грызть" данные.
Сейчас я на собственном опыте вижу, что ChatGPT и Copilot иногда помогают мне выполнять работу быстрее, но явно не лучше. Качество работы зависит от опыта и навыков.
Например, у меня на велосипеде почти год не работал гидравлический тормоз. Я пытался его починить в мастерской, но мне говорили, что придется ждать неделю, чтобы просто прокачать масло. В итоге, времени все не хватало. И тут я зашел в небольшой магазин, и мастер за 5 минут и 10 долларов устранил проблему. Оказалось, что на моем gravel bike можно регулировать ручку тормоза под длину пальцев, и у меня она была неправильно настроена, из-за чего тормоз не работал.
То есть, у него многолетний опыт, и он видит всю картину целиком. Я бы заплатил ему и 50 долларов за 10 минут работы, потому что он действительно профессионал в своем деле.
Возвращаясь к AI, по моему скромному мнению, эти инструменты пока еще плохо воспринимают (бизнес-) контекст и общую картину. Они решают точечные задачи и автоматизируют узкие бизнес-процессы (например, поддержку).
В аналитике, как правило, очень широкий и уникальный контекст. AI может создать pipeline, дашборд, собрать метрики, но пока это еще далеко от реальности, и крупные компании не скоро смогут это внедрить. До сих пор многие компании используют Teradata/Oracle с 90-х годов. У них огромные бюджеты на AI, которые раньше тратились на ML, Big Data, Cloud и т.д.
В целом, нам не стоит беспокоиться по этому поводу, ведь мы не можем контролировать этот процесс. Но мы можем контролировать свою гибкость и всегда быть открытыми к новому (гибкое мышление), чтобы учиться и развиваться, о чем я часто пишу в этом канале.
Нашим детям будет сложнее, и все, что мы можем сделать для них — это создать комфортные условия для учебы и спорта. Математика, чтение, языки и спорт — и все будет отлично!
Ладно, а как вы себе представляете AI-апокалипсис?
Лично я больше боюсь землетрясения, которое уж точно лишит всех работы в IT, как это уже бывало раньше - The M9 Cascadia Megathrust Earthquake of January 26, 1700
❤🔥65 14👾5🤷♀4⚡4🐳1
This media is not supported in the widget
VIEW IN TELEGRAM
⚡62 29❤🔥6🗿2
Я часто слышал и видел Permifrost — утилиту для настройки прав доступа в Snowflake.
Permifrost — это Python-инструмент для управления правами доступа в Snowflake. Основная документация по его использованию доступна в проекте и на PyPI. Разработан в GitLab.
Одна из ключевых особенностей Snowflake — это удобное управление доступом с помощью Access Control Framework.
Внутри Snowflake у нас есть:
- база данных;
- внутри базы данных есть схемы;
- внутри схемы есть объекты: таблицы, вьюхи, процедуры.
Чтобы написать запрос, пользователь или сервисный пользователь должен иметь привилегии на объекты, например, на SELECT. Привилегий много, но для нас важно разделить их на категории READ, MODIFY и ADMIN — этого будет достаточно.
Все привилегии назначаются не конкретному пользователю, а роли, и уже потом мы назначаем роль пользователю.
Кроме DATABASE, ROLE, и USER есть ещё один важный элемент — это WAREHOUSE (вычислительный кластер). Часто для каждого сервиса можно выбрать свой compute, и таким образом легче отслеживать его стоимость.
Для меня все эти DBA-штучки в Snowflake довольно запутанные, и, если сильно углубляться, можно потратить много времени на планирование модели безопасности.
Безусловно, есть классные вещи, такие как IP Policy для пользователя — мы указываем список IP-адресов для сервисного пользователя, откуда могут приходить запросы. Dynamic Masking позволяет скрывать PII-данные для пользователей, у которых нет прав доступа к "красным" данным.
Обычно всё это настраивается с помощью команд GRANT, но легко потеряться в деталях. Поэтому Permifrost очень удобен: мы просто создаём YAML-файл, в котором описываем уже существующие объекты:
- ROLES (можно группировать по App, Base, Functional и т.д.; каждая роль может быть
- DATABASES;
- USERS;
- WAREHOUSES.
После этого мы выполняем команду, и все GRANT/REVOKE обновляются.
Обычно Permifrost разворачивается через Dockerfile и настраивается на запуск в GitHub Actions раз в сутки (на всякий случай, но если изменения редкие, то и расписание не нужно).
Таким образом, все изменения прав происходят через YAML-файл и Pull Request, что делает их полностью прозрачными для всех.
Пример статьи по теме: Snowflake RBAC Implementation with Permifrost
Пример реализации от Meltano: [GitHub link](https://github.com/meltano/squared/blob/main/data/utilities/permifrost/roles.yml)
Теперь расскажу, как мне пришлось разбираться с этой штукой.
В проекте, который мне нужно было просмотреть и подправить, где до меня консультанты внедряли Snowflake и dbt, необходимо было создавать новые таблицы и давать права на чтение. Но почему-то на следующий день все мои GRANTы пропадали.
Потом я создал нового пользователя для BI и дал ему права на чтение всех баз данных, но на следующий день всё снова пропало.
В документации и репозитории была информация о Permifrost, но не было самого YAML-файла с конфигурацией, и вообще было непонятно, как изначально создавалась структура в Snowflake. Но по названиям было очевидно, что использовался какой-то шаблон.
Я написал консультантам, они ответили в духе «мы ничего не знаем, лошадь не моя». Мне всё равно нужно было создать модель безопасности и взять ситуацию под контроль. Очевидное решение — использовать Permifrost.
Проблема была в том, что если я начну менять права, то мой Permifrost может забрать права у сервисных пользователей, баз данных и т.д. А я тогда ещё не до конца понимал, как всё взаимосвязано.
Следуя любимым Amazon Leadership Principles — Bias for Action, Ownership, Deliver Results — я сразу начал менять продакшн в 10 вечера. Сначала отвалился Fivetran, затем оказалось, что у меня нет даже пароля от сервисного пользователя Fivetran. Методом научного тыка я разобрался, как выстроить взаимосвязь между YAML-спеком и Snowflake, сбросил пароль пользователя, и вроде бы Fivetran заработал. На следующий день я сломал dbt, но потом всё пошло быстрее.
Permifrost — это Python-инструмент для управления правами доступа в Snowflake. Основная документация по его использованию доступна в проекте и на PyPI. Разработан в GitLab.
Одна из ключевых особенностей Snowflake — это удобное управление доступом с помощью Access Control Framework.
Внутри Snowflake у нас есть:
- база данных;
- внутри базы данных есть схемы;
- внутри схемы есть объекты: таблицы, вьюхи, процедуры.
Чтобы написать запрос, пользователь или сервисный пользователь должен иметь привилегии на объекты, например, на SELECT. Привилегий много, но для нас важно разделить их на категории READ, MODIFY и ADMIN — этого будет достаточно.
Все привилегии назначаются не конкретному пользователю, а роли, и уже потом мы назначаем роль пользователю.
Кроме DATABASE, ROLE, и USER есть ещё один важный элемент — это WAREHOUSE (вычислительный кластер). Часто для каждого сервиса можно выбрать свой compute, и таким образом легче отслеживать его стоимость.
Для меня все эти DBA-штучки в Snowflake довольно запутанные, и, если сильно углубляться, можно потратить много времени на планирование модели безопасности.
Безусловно, есть классные вещи, такие как IP Policy для пользователя — мы указываем список IP-адресов для сервисного пользователя, откуда могут приходить запросы. Dynamic Masking позволяет скрывать PII-данные для пользователей, у которых нет прав доступа к "красным" данным.
Обычно всё это настраивается с помощью команд GRANT, но легко потеряться в деталях. Поэтому Permifrost очень удобен: мы просто создаём YAML-файл, в котором описываем уже существующие объекты:
- ROLES (можно группировать по App, Base, Functional и т.д.; каждая роль может быть
_admin, _modify, _view);- DATABASES;
- USERS;
- WAREHOUSES.
После этого мы выполняем команду, и все GRANT/REVOKE обновляются.
Обычно Permifrost разворачивается через Dockerfile и настраивается на запуск в GitHub Actions раз в сутки (на всякий случай, но если изменения редкие, то и расписание не нужно).
Таким образом, все изменения прав происходят через YAML-файл и Pull Request, что делает их полностью прозрачными для всех.
Пример статьи по теме: Snowflake RBAC Implementation with Permifrost
Пример реализации от Meltano: [GitHub link](https://github.com/meltano/squared/blob/main/data/utilities/permifrost/roles.yml)
Теперь расскажу, как мне пришлось разбираться с этой штукой.
В проекте, который мне нужно было просмотреть и подправить, где до меня консультанты внедряли Snowflake и dbt, необходимо было создавать новые таблицы и давать права на чтение. Но почему-то на следующий день все мои GRANTы пропадали.
Потом я создал нового пользователя для BI и дал ему права на чтение всех баз данных, но на следующий день всё снова пропало.
В документации и репозитории была информация о Permifrost, но не было самого YAML-файла с конфигурацией, и вообще было непонятно, как изначально создавалась структура в Snowflake. Но по названиям было очевидно, что использовался какой-то шаблон.
Я написал консультантам, они ответили в духе «мы ничего не знаем, лошадь не моя». Мне всё равно нужно было создать модель безопасности и взять ситуацию под контроль. Очевидное решение — использовать Permifrost.
Проблема была в том, что если я начну менять права, то мой Permifrost может забрать права у сервисных пользователей, баз данных и т.д. А я тогда ещё не до конца понимал, как всё взаимосвязано.
Следуя любимым Amazon Leadership Principles — Bias for Action, Ownership, Deliver Results — я сразу начал менять продакшн в 10 вечера. Сначала отвалился Fivetran, затем оказалось, что у меня нет даже пароля от сервисного пользователя Fivetran. Методом научного тыка я разобрался, как выстроить взаимосвязь между YAML-спеком и Snowflake, сбросил пароль пользователя, и вроде бы Fivetran заработал. На следующий день я сломал dbt, но потом всё пошло быстрее.
⚡26❤🔥5
В итоге за три дня я смог полностью пересобрать модель безопасности для Snowflake, понять, как работает Permifrost, и разблокировать все задачи, связанные с добавлением новых объектов в хранилище данных.
Заодно появился готовый проект для Surfalytics по использованию Permifrost, который мы будем изучать.
—-
PS: В чём ценность Permifrost и такого знания? Как мне видится, это отличная галочка в резюме для Analytics/Data Engineer. Очень полезная вещь для любого проекта в Snowflake и легко описывается в формате STAR (Situation, Task, Action, Result). Этому мы тоже будем учиться в Surfalytics.
А так интересно услышать от экспертов про:
1) Использовании Permiftost или альтернатив, как например Terraform, где можно создавать все объекта и давать права в одном месте
2) В целом про best practices RBAC
3) Как это делается в BigQuery, Databricks, Redshift и тп
Заодно появился готовый проект для Surfalytics по использованию Permifrost, который мы будем изучать.
—-
PS: В чём ценность Permifrost и такого знания? Как мне видится, это отличная галочка в резюме для Analytics/Data Engineer. Очень полезная вещь для любого проекта в Snowflake и легко описывается в формате STAR (Situation, Task, Action, Result). Этому мы тоже будем учиться в Surfalytics.
А так интересно услышать от экспертов про:
1) Использовании Permiftost или альтернатив, как например Terraform, где можно создавать все объекта и давать права в одном месте
2) В целом про best practices RBAC
3) Как это делается в BigQuery, Databricks, Redshift и тп
⚡31🫡3👾3
Media is too big
VIEW IN TELEGRAM
Вот и прошел наш 6ти дневный Surfalytics meetup в красивом Тофино на острове Ванкувер на берегу открытого Тихого океана.
6 дней пролетело незаметно, было 10 семей и каждый нашел свое, все попробовали серф и влюбились в это место как мы 9 лет назад.
Мы были рады разделить эти дни с замечательной компанией и надеюсь в след году будет еще больше людей и еще больше дней.
Instagram: https://www.instagram.com/surfalytics/
🌊🌊🌊
6 дней пролетело незаметно, было 10 семей и каждый нашел свое, все попробовали серф и влюбились в это место как мы 9 лет назад.
Мы были рады разделить эти дни с замечательной компанией и надеюсь в след году будет еще больше людей и еще больше дней.
Instagram: https://www.instagram.com/surfalytics/
🌊🌊🌊
🐳55❤🔥43🍾8⚡2
Media is too big
VIEW IN TELEGRAM
Отвечаю очень развернуто на вопрос как стать дата инженером. В конце бонусом рассказываю про пользу сертификации, то есть бесполезность сертификатов при поиске работы.
❤🔥65⚡16🫡9 5🙉2
Решили завтра сгонять в Seattle на пару деньков пока у детей не сильная загрузка. В среду в 6 вечера буду на Lake Union с сидром и семьей, подходите пообщаемся про рынок Seattle/US.
❤🔥29
Arch.Meetup by Sber: современное управление архитектурой данных – регистрация открыта ✅
Уже 11 сентября в офисе Сбера и онлайн вместе с ИТ-архитекторами, data-инженерами и спикерами из трех IT-компаний поговорим об архитектуре данных и ее роли в управлении данными.
В программе – сразу 3 доклада, нетворкинг с большим архитектурным сообществом, выставка новых продуктов и технологий Сбера и фуршет.
О чем поговорим?
▪️Есть ли Архитектура данных за пределами хранилищ?
▪️Как моделировать данные на Enterprise-уровне?
▪️Как архитектура помогает в вопросах инвентаризации данных?
▪️Что такое Data API и почему мы часто говорим об интегрируемости данных?
👉🏻 Подробная программа и регистрация – по этой ссылке. Успей пройти регистрацию – количество очных мест ограничено.
Уже 11 сентября в офисе Сбера и онлайн вместе с ИТ-архитекторами, data-инженерами и спикерами из трех IT-компаний поговорим об архитектуре данных и ее роли в управлении данными.
В программе – сразу 3 доклада, нетворкинг с большим архитектурным сообществом, выставка новых продуктов и технологий Сбера и фуршет.
О чем поговорим?
▪️Есть ли Архитектура данных за пределами хранилищ?
▪️Как моделировать данные на Enterprise-уровне?
▪️Как архитектура помогает в вопросах инвентаризации данных?
▪️Что такое Data API и почему мы часто говорим об интегрируемости данных?
👉🏻 Подробная программа и регистрация – по этой ссылке. Успей пройти регистрацию – количество очных мест ограничено.
Please open Telegram to view this post
VIEW IN TELEGRAM
Свежая книжка по DE
Data projects are an intrinsic part of an organization's technical ecosystem, but data engineers in many companies are still trying to solve problems that others have already solved. This hands-on guide shows you how to provide valuable data by focusing on various aspects of data engineering, including data ingestion, data quality, idempotency, and more.
Author Bartosz Konieczny guides you through the process of building reliable end-to-end data engineering projects, from data ingestion to data observability, focusing on data engineering design patterns that solve common business problems in a secure and storage-optimized manner.
Each pattern includes a user-facing description of the problem, solutions, and consequences that place the pattern into the context of real-life scenarios.
Throughout this journey, you'll use open source data tools and public cloud services to see how to put each pattern into practice. You'll learn:
- Challenges data engineers face and their impact on data systems
- How these challenges relate to data system components
What data engineering patterns are for
- How to identify and fix issues with your current data components
- Technology-agnostic solutions to new and existing data projects
- How to implement patterns with Apache Airflow, Apache Spark, Apache Flink, and Delta Lake
URL: https://www.oreilly.com/library/view/data-engineering-design/9781098165826/ (по подписке доступна ранняя версия)
Data projects are an intrinsic part of an organization's technical ecosystem, but data engineers in many companies are still trying to solve problems that others have already solved. This hands-on guide shows you how to provide valuable data by focusing on various aspects of data engineering, including data ingestion, data quality, idempotency, and more.
Author Bartosz Konieczny guides you through the process of building reliable end-to-end data engineering projects, from data ingestion to data observability, focusing on data engineering design patterns that solve common business problems in a secure and storage-optimized manner.
Each pattern includes a user-facing description of the problem, solutions, and consequences that place the pattern into the context of real-life scenarios.
Throughout this journey, you'll use open source data tools and public cloud services to see how to put each pattern into practice. You'll learn:
- Challenges data engineers face and their impact on data systems
- How these challenges relate to data system components
What data engineering patterns are for
- How to identify and fix issues with your current data components
- Technology-agnostic solutions to new and existing data projects
- How to implement patterns with Apache Airflow, Apache Spark, Apache Flink, and Delta Lake
URL: https://www.oreilly.com/library/view/data-engineering-design/9781098165826/ (по подписке доступна ранняя версия)
1🫡26❤🔥19⚡3
Еще одна свежая книга, которая покрывает важный термин - Data Contracts.
Poor data quality can cause major problems for data teams, from breaking revenue-generating data pipelines to losing the trust of data consumers. Despite the importance of data quality, many data teams still struggle to avoid these issues—especially when their data is sourced from upstream workflows outside of their control. The solution: data contracts. Data contracts enable high-quality, well-governed data assets by documenting expectations of the data, establishing ownership of data assets, and then automatically enforcing these constraints within the CI/CD workflow.
This practical book introduces data contract architecture with a clear definition of data contracts, explains why the data industry needs them, and shares real-world use cases of data contracts in production. In addition, you'll learn how to implement components of the data contract architecture and understand how they're used in the data lifecycle. Finally, you'll build a case for implementing data contracts in your organization.
Authors Chad Sanderson and Mark Freeman will help you:
- Explore real-world applications of data contracts within the industry
- Understand how to apply each component of this architecture, such as CI/CD, monitoring, version control data, and more
- Learn how to implement data contracts using open source tools
- Examine ways to resolve data quality issues using data contract architecture
- Measure the impact of implementing a data contract in your organization
- Develop a strategy to determine how data contracts will be used in your organization
Компания Chad ищет инвестиции и я смотрел их pitch deck, пока у них как-то тухло по paying customers.
Если попростому, то data contracts это договоренность между 2мя командами о схеме и типе данных.
Например, вы забираете данные из backend OLTP. Инженеры решили поменять табличку, переименовали поле в таблицу и у вас упал ETL pipeline, ведь хранилище данных это Schema on Write. Вы его конечно почините, но так происходит часто и это влияете на качество дашбордов и в целом BI users experience.
Поэтому data contract позволяет нам проактивно мониторить этот процесс. Инженеры в backend знаю как их изменения повлияют на хранилище данных. Можно это внедрить и обычным способом, например в git кто-то из дата команды должен делать code review, чтобы знать об изменениях, но это подходит для маленьких компаний.
Poor data quality can cause major problems for data teams, from breaking revenue-generating data pipelines to losing the trust of data consumers. Despite the importance of data quality, many data teams still struggle to avoid these issues—especially when their data is sourced from upstream workflows outside of their control. The solution: data contracts. Data contracts enable high-quality, well-governed data assets by documenting expectations of the data, establishing ownership of data assets, and then automatically enforcing these constraints within the CI/CD workflow.
This practical book introduces data contract architecture with a clear definition of data contracts, explains why the data industry needs them, and shares real-world use cases of data contracts in production. In addition, you'll learn how to implement components of the data contract architecture and understand how they're used in the data lifecycle. Finally, you'll build a case for implementing data contracts in your organization.
Authors Chad Sanderson and Mark Freeman will help you:
- Explore real-world applications of data contracts within the industry
- Understand how to apply each component of this architecture, such as CI/CD, monitoring, version control data, and more
- Learn how to implement data contracts using open source tools
- Examine ways to resolve data quality issues using data contract architecture
- Measure the impact of implementing a data contract in your organization
- Develop a strategy to determine how data contracts will be used in your organization
Компания Chad ищет инвестиции и я смотрел их pitch deck, пока у них как-то тухло по paying customers.
Если попростому, то data contracts это договоренность между 2мя командами о схеме и типе данных.
Например, вы забираете данные из backend OLTP. Инженеры решили поменять табличку, переименовали поле в таблицу и у вас упал ETL pipeline, ведь хранилище данных это Schema on Write. Вы его конечно почините, но так происходит часто и это влияете на качество дашбордов и в целом BI users experience.
Поэтому data contract позволяет нам проактивно мониторить этот процесс. Инженеры в backend знаю как их изменения повлияют на хранилище данных. Можно это внедрить и обычным способом, например в git кто-то из дата команды должен делать code review, чтобы знать об изменениях, но это подходит для маленьких компаний.
❤🔥30🌭3🗿1
Forwarded from Стартап дня. Александр Горный.
Что ещё почитать?
Удивительно, что до сих пор не постил в канал свой список любимых книг. Они действительно хорошие.
Лейл Лаундес "Как говорить с кем угодно и о чем угодно"
Джим Кэмп “Сначала скажите нет”
Брайан Трейси "Переговоры"
Stephanie Palmer “Good in a Room”
Карен Прайор «Не рычите на собаку! Книга о дрессировке людей, животных и самого себя»
Пять учебников по переговорам и общению с другими людьми. Они очень разные между собой и по формату, и по целевой аудитории, и по рекомендациям, но каждый из пяти этих взглядов на коммуникацию был мне очень полезен и каждым я активно пользуюсь.
"Думай медленно... Решай быстро", Дэниел Канеман
“The Willpower Instinct: How Self-Control Works, Why It Matters, and What You Can Do to Get More of It”, Kelly McGonigal
"The Shallows", Николас Карр
Три отличные книги о том, как люди думают и как на это можно влиять. В первую очередь интересно понимать и влиять на самого себя, конечно. И выключите, наконец, уведомления на телефоне!
“Remote. Office not required”, David Heinemeier Hansson, Jason Fried
Книга об удаленке, написанная задолго до COVID. Очень много конкретных мыслей и предложений о том, как организовать её эффективнее.
Аллен Карр "Легкий способ сбросить вес"
Алексей Филатов "Теория и практика жиросжигания"
Две лучшие книги по борьбе с лишним весом из тех, что я читал, а читал я много. По их рецептам я реально худел с минимальными усилиями. Та самая “волшебная таблетка”.
"Ценностное управление для бизнеса", Константин Харский
Культура ест стратегию на завтрак, как известно. А чтобы ценности вашей компании использовались как-то иначе, чем просто висеть на холодильнике – прочтите книгу Харского.
"Школа продаж. Что делать, если клиент не хочет покупать?" Александр Деревицкий
«Метод тыквы. Как стать лидером в своей нише без бюджета», Майк Микаловиц
“No B.S. Ruthless Management of People and Profits” Dan S. Kennedy
Учебники бизнеса. Из каждого есть что взять и с чем поспорить, но даже то, “с чем поспорить”, читается с огромным интересом.
"Разумное распределение активов", Уильям Дж. Бернстайн
Лучшая книга об инвестициях. Вы не потеряете много денег, если будете инвестировать, опираясь на её идеи.
“Onward: How Starbucks Fought for Its Life without Losing Its Soul”, Howard Schultz
“Anything You Want: 40 Lessons for a New Kind of Entrepreneur”, Derek Sivers
Две вдохновляющие истории двух совершенно разных бизнесов.
Патрик Ленсиони «Пять пороков команды. Притчи о лидерстве»
“Кто, решите вашу проблему номер один”, Джефф Смарт, Рэнди Стрит
Две лучшие книги о найме и работе с людьми. А люди – это же самое главное в бизнесе?
Мою с соавторами книгу в этот список вставлять нескромно, так что я её просто рядом поставлю. Список закончился выше.
“50 бизнес-моделей новой экономики. Уроки компаний-единорогов”, Алексей Черняк, Михаил Иванов, Александр Горный
https://50i.ru/
P.S.: меньше книг, но с более подробным комментарием о каждой – в весеннем ролике на YouTube.
https://youtu.be/fzjRJwnFWC4
#личныйопыт
Удивительно, что до сих пор не постил в канал свой список любимых книг. Они действительно хорошие.
Лейл Лаундес "Как говорить с кем угодно и о чем угодно"
Джим Кэмп “Сначала скажите нет”
Брайан Трейси "Переговоры"
Stephanie Palmer “Good in a Room”
Карен Прайор «Не рычите на собаку! Книга о дрессировке людей, животных и самого себя»
Пять учебников по переговорам и общению с другими людьми. Они очень разные между собой и по формату, и по целевой аудитории, и по рекомендациям, но каждый из пяти этих взглядов на коммуникацию был мне очень полезен и каждым я активно пользуюсь.
"Думай медленно... Решай быстро", Дэниел Канеман
“The Willpower Instinct: How Self-Control Works, Why It Matters, and What You Can Do to Get More of It”, Kelly McGonigal
"The Shallows", Николас Карр
Три отличные книги о том, как люди думают и как на это можно влиять. В первую очередь интересно понимать и влиять на самого себя, конечно. И выключите, наконец, уведомления на телефоне!
“Remote. Office not required”, David Heinemeier Hansson, Jason Fried
Книга об удаленке, написанная задолго до COVID. Очень много конкретных мыслей и предложений о том, как организовать её эффективнее.
Аллен Карр "Легкий способ сбросить вес"
Алексей Филатов "Теория и практика жиросжигания"
Две лучшие книги по борьбе с лишним весом из тех, что я читал, а читал я много. По их рецептам я реально худел с минимальными усилиями. Та самая “волшебная таблетка”.
"Ценностное управление для бизнеса", Константин Харский
Культура ест стратегию на завтрак, как известно. А чтобы ценности вашей компании использовались как-то иначе, чем просто висеть на холодильнике – прочтите книгу Харского.
"Школа продаж. Что делать, если клиент не хочет покупать?" Александр Деревицкий
«Метод тыквы. Как стать лидером в своей нише без бюджета», Майк Микаловиц
“No B.S. Ruthless Management of People and Profits” Dan S. Kennedy
Учебники бизнеса. Из каждого есть что взять и с чем поспорить, но даже то, “с чем поспорить”, читается с огромным интересом.
"Разумное распределение активов", Уильям Дж. Бернстайн
Лучшая книга об инвестициях. Вы не потеряете много денег, если будете инвестировать, опираясь на её идеи.
“Onward: How Starbucks Fought for Its Life without Losing Its Soul”, Howard Schultz
“Anything You Want: 40 Lessons for a New Kind of Entrepreneur”, Derek Sivers
Две вдохновляющие истории двух совершенно разных бизнесов.
Патрик Ленсиони «Пять пороков команды. Притчи о лидерстве»
“Кто, решите вашу проблему номер один”, Джефф Смарт, Рэнди Стрит
Две лучшие книги о найме и работе с людьми. А люди – это же самое главное в бизнесе?
Мою с соавторами книгу в этот список вставлять нескромно, так что я её просто рядом поставлю. Список закончился выше.
“50 бизнес-моделей новой экономики. Уроки компаний-единорогов”, Алексей Черняк, Михаил Иванов, Александр Горный
https://50i.ru/
P.S.: меньше книг, но с более подробным комментарием о каждой – в весеннем ролике на YouTube.
https://youtu.be/fzjRJwnFWC4
#личныйопыт
❤🔥33💯3🤷3🍌1🙈1
Визуализация дня.
Согласно нему брак заключается реже по многим причинам — высоким уровням личной задолженности (кредиты/ипотеки), снижению общественного давления и другим факторам, — но одним из главных, похоже, является равенство заработной платы.
Согласно исследованию Калифорнийского университета, каждое увеличение средней зарплаты женщин на 10% приводит к снижению числа заключаемых браков на 7%.
Как все успели жениться, замуж выйти?)
Согласно нему брак заключается реже по многим причинам — высоким уровням личной задолженности (кредиты/ипотеки), снижению общественного давления и другим факторам, — но одним из главных, похоже, является равенство заработной платы.
Согласно исследованию Калифорнийского университета, каждое увеличение средней зарплаты женщин на 10% приводит к снижению числа заключаемых браков на 7%.
Как все успели жениться, замуж выйти?)
👾27🫡20❤🔥10🌚1😈1
Знаете какой самый популярный SQL запрос у крутого дата инженера?
А крутого дата инженера, но с реальным опытом, будет немного другой:
Даже chatGPT понял, что к чему:
- does it make sense?
- Да, это шутка, и она передает смысл! Первое выражение показывает запрос новичка или “крутого” дата инженера, который хочет увидеть все данные, а второе - опытного инженера, который понимает, что часто достаточно увидеть лишь часть данных, чтобы оценить содержимое таблицы и сэкономить ресурсы.
Эта шутка подчёркивает, что опытные инженеры более прагматичны и ценят эффективность в работе с данными. Отличная шутка для тех, кто знаком с SQL и повседневными задачами дата инженеров!
Реально мой день начинается и заканчивается с этих запросов🙌
SELECT * FROM <TABLE NAME>
А крутого дата инженера, но с реальным опытом, будет немного другой:
SELECT * FROM <TABLE NAME>
LIMIT 10
Даже chatGPT понял, что к чему:
- does it make sense?
- Да, это шутка, и она передает смысл! Первое выражение показывает запрос новичка или “крутого” дата инженера, который хочет увидеть все данные, а второе - опытного инженера, который понимает, что часто достаточно увидеть лишь часть данных, чтобы оценить содержимое таблицы и сэкономить ресурсы.
Эта шутка подчёркивает, что опытные инженеры более прагматичны и ценят эффективность в работе с данными. Отличная шутка для тех, кто знаком с SQL и повседневными задачами дата инженеров!
Реально мой день начинается и заканчивается с этих запросов
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥87💯24🙈15⚡6👨💻3😭2 2😈1🤷1