про Data Contracts в подкасте dbt
Chad Sanderson из Convoy (heavy modern data staсk users 🥸) делится своим кейсом: занимаются бизнесом, который truly ML driven, т.е. эм-эль не просто где-то сбоку, а без него не было бы самого бизнеса.
Начали работать, сначала всё шло хорошо, а потом начали появляться сообщения от коллег, что мол в колонках до 25% пропусков, где бизнесово их быть не должно — для обучения моделей приходится вычищать четверть датасета.
И так из других отделов тоже, общий тренд такой, что «мы не доверяем данным». Так начали развивать Data Quality (и до сих пор в этом процессе).
⌘⌘⌘
Ещё раз звучала аналогия, что датасеты (по крайне мере те которые «свои») — это как API. Подразумевается, что нельзя просто так вносить изменения без обратной совместимости.
С другой стороны, разработчики — не демоны. У них нет цели сломать процессы, нижестоящие по пайплайну данных. Они могут быть просто не в курсе, что ИХ ДАННЫМИ пользуется кто-то ещё.
С источниками надо коммуницировать. Причём делать это лучше заранее, а не так чтобы прибегать к ним с криками «ВЫ ЛОМАЕТЕ НАМ ДЕШИ!», когда уже всё сломалось. На это они могут резонно ответить, что типа с чего это вы вешаете продакшен-критичные зависимости без предупреждения, мы не подписывались на это.
Ещё обсуждали, что дата-контракты могут «подписывать» только со стороны источника. Это в ответ на реплику в дбт-шном Слаке, что бывают producer-side и consumer-side контракты. Участники подкаста сходятся в том, что пользователи могут только обвешать входные данные чеками и алертами, но влиять на них не могут.
Ссылки на послушать на сайте подкаста:
https://roundup.getdbt.com/p/ep-34-why-youll-need-data-contracts
#послушано
Chad Sanderson из Convoy (heavy modern data staсk users 🥸) делится своим кейсом: занимаются бизнесом, который truly ML driven, т.е. эм-эль не просто где-то сбоку, а без него не было бы самого бизнеса.
Начали работать, сначала всё шло хорошо, а потом начали появляться сообщения от коллег, что мол в колонках до 25% пропусков, где бизнесово их быть не должно — для обучения моделей приходится вычищать четверть датасета.
И так из других отделов тоже, общий тренд такой, что «мы не доверяем данным». Так начали развивать Data Quality (и до сих пор в этом процессе).
⌘⌘⌘
Ещё раз звучала аналогия, что датасеты (по крайне мере те которые «свои») — это как API. Подразумевается, что нельзя просто так вносить изменения без обратной совместимости.
С другой стороны, разработчики — не демоны. У них нет цели сломать процессы, нижестоящие по пайплайну данных. Они могут быть просто не в курсе, что ИХ ДАННЫМИ пользуется кто-то ещё.
С источниками надо коммуницировать. Причём делать это лучше заранее, а не так чтобы прибегать к ним с криками «ВЫ ЛОМАЕТЕ НАМ ДЕШИ!», когда уже всё сломалось. На это они могут резонно ответить, что типа с чего это вы вешаете продакшен-критичные зависимости без предупреждения, мы не подписывались на это.
Ещё обсуждали, что дата-контракты могут «подписывать» только со стороны источника. Это в ответ на реплику в дбт-шном Слаке, что бывают producer-side и consumer-side контракты. Участники подкаста сходятся в том, что пользователи могут только обвешать входные данные чеками и алертами, но влиять на них не могут.
Ссылки на послушать на сайте подкаста:
https://roundup.getdbt.com/p/ep-34-why-youll-need-data-contracts
#послушано
Getdbt
Ep 34: Why you’ll need data contracts (w/ Chad Sanderson + Prukalpa Sankar)
WARNING: This episode contains in-depth discussion of data contracts. Are they a solve for the collaboration challenges between producers + consumers that impact data quality?
🔥4👍1
Каким-то образом удалось затесаться одним из гостей в подкаст Data Heroes от команды Николая Валиотти. Вчерашний джун попал в компанию матёрых сеньоров, хе-хе. Тем не менее постарался поделиться своими мыслями о работе инженером данных.
Опытом делились Семён Осипов из Gett, Ксения Томак из Dodo Brands и Сергей Бойцов; их и приглашаю послушать, получилось разносторонне, у всех свой опыт и итоговые советы получились довольно уникальными.
Ссылки где послушать в канале Left Join:
https://news.1rj.ru/str/leftjoin/841
Опытом делились Семён Осипов из Gett, Ксения Томак из Dodo Brands и Сергей Бойцов; их и приглашаю послушать, получилось разносторонне, у всех свой опыт и итоговые советы получились довольно уникальными.
Ссылки где послушать в канале Left Join:
https://news.1rj.ru/str/leftjoin/841
Telegram
LEFT JOIN
Дата инжиниринг – одна из самых сложных и востребованных профессий в области данных. В новом выпуске подкаста Data Heroes мы поговорим с инженерами данных и наконец-то узнаем, чем именно они занимаются 🚀
В этом эпизоде мы поговорим о важности роли дата…
В этом эпизоде мы поговорим о важности роли дата…
🔥11👍2
«Бэкенд» бэкенда
Есть профессии, которые прямо можно оценить по вносимому вкладу — особенно ближе к сезону перфоманс ревью поднимаются вопросы тип «вот сколько Вася принёс денег компании?».
Как ни старайся, DWH таким аршином не измеришь. Только если вешать «счётчик входящих» и высчитывать % от оклада у всех кто пользуется нашими сущностями.
Получается, наша работа в другом — мы подносим патроны. Причём подносим патроны тем, кто сам подносит патроны. Мы в глубоком тылу. В чём же наша польза? Как её измерить?
Один из вариантов ответов, который мне больше всего нравится, — мы повышаем стабильность и скорость общей работы. Мы поддерживаем документацию, чтобы менеджеры могли быстрее найти как поджойнить зоны с тарифами. Мы сокращаем количество джойнов, которые нужно сделать аналитикам для ответов на свои вопросы (говорят, Женя Козлов предлагал такую метрику в Яндекс Такси).
В идеальном случае мы должны быть аналогом тех самых четырёх девяток после запятой. Нашим данным должны доверять, на наших сущностях можно строить отчёты для самых топов, не боясь задержек и косяков.
Перекликается с тем, как Ваня-инженер писал про отсутствие провалов в противовес бешенному достигаторству.
И по совокупности всех этих показателяй мы должны выделяться на фоне «теневого DWH» (иначе, зачем нужен «официальный», да?)
Есть профессии, которые прямо можно оценить по вносимому вкладу — особенно ближе к сезону перфоманс ревью поднимаются вопросы тип «вот сколько Вася принёс денег компании?».
Как ни старайся, DWH таким аршином не измеришь. Только если вешать «счётчик входящих» и высчитывать % от оклада у всех кто пользуется нашими сущностями.
Получается, наша работа в другом — мы подносим патроны. Причём подносим патроны тем, кто сам подносит патроны. Мы в глубоком тылу. В чём же наша польза? Как её измерить?
Один из вариантов ответов, который мне больше всего нравится, — мы повышаем стабильность и скорость общей работы. Мы поддерживаем документацию, чтобы менеджеры могли быстрее найти как поджойнить зоны с тарифами. Мы сокращаем количество джойнов, которые нужно сделать аналитикам для ответов на свои вопросы (говорят, Женя Козлов предлагал такую метрику в Яндекс Такси).
В идеальном случае мы должны быть аналогом тех самых четырёх девяток после запятой. Нашим данным должны доверять, на наших сущностях можно строить отчёты для самых топов, не боясь задержек и косяков.
Перекликается с тем, как Ваня-инженер писал про отсутствие провалов в противовес бешенному достигаторству.
И по совокупности всех этих показателяй мы должны выделяться на фоне «теневого DWH» (иначе, зачем нужен «официальный», да?)
Telegram
Секрет лапшичного супа
Мысли и опыт Евгения Козлова:
— CDO @ Dwelly (AI-enabled-агентство недвижимости в UK)
— CDO @ Rhino (бронетакси в Бразилии)
— former Yandex Fellow & Head of analytics @ Yandex.Taxi
tg: @eugenekozlov
linkedin: https://www.linkedin.com/in/kozlov-eugene/
— CDO @ Dwelly (AI-enabled-агентство недвижимости в UK)
— CDO @ Rhino (бронетакси в Бразилии)
— former Yandex Fellow & Head of analytics @ Yandex.Taxi
tg: @eugenekozlov
linkedin: https://www.linkedin.com/in/kozlov-eugene/
🔥5
Кто в прошлом году вёл себя плохо, тот в следующем будет писать SQL на кириллице 😈
картинка из чатика Data Coffee
картинка из чатика Data Coffee
🔥14💩13
О развитии как разработчика баз данных
Алексей Махоткин известен среди меня тем, что продвигает фреймворк проектирования (?) Minimal Modeling. В посте Алексей рассуждает о развитии как разработчика баз данных.
Интересно, что он не уходит в список необходимых утилит и фреймворков, а сосредотачивается на понимании бизнеса:
⁃ First, learn to speak the language of the business side. [..] also need to have a common language with stakeholders, such as data analysts and researchers, and especially with marketing [..]
⁃ Second, think about removing the organizational bottlenecks around data processes [..]
⁃ There are also some other activities that could help with reducing friction, such as establishing data provenance. [..]
Понравился тезис, что хранение данных, должно «оплачивать свою аренду» =)
Another thing I'd suggest keeping in mind: how much does the data cost? When your company stores values for a certain attribute (anything, say "the day of birth of the user"): how much does it cost to store all those days of birth, in dollars? Next question is of course: does this data pay the rent?
Кажется, у дата инженеров принят обратный подход: надо собрать с источника все доступные данные, желательно с сохранением истории изменений. И потом ещё у себя всё собранное разложить на две реплики в двух кластерах ^_^
Но это всё в «сырых» слоях. А вот дальше по слоям уже действительно протаскивается только нужное и скурпулёзно документированное.
https://minimalmodeling.substack.com/p/how-to-grow-as-a-database-developer
Алексей Махоткин известен среди меня тем, что продвигает фреймворк проектирования (?) Minimal Modeling. В посте Алексей рассуждает о развитии как разработчика баз данных.
Интересно, что он не уходит в список необходимых утилит и фреймворков, а сосредотачивается на понимании бизнеса:
⁃ First, learn to speak the language of the business side. [..] also need to have a common language with stakeholders, such as data analysts and researchers, and especially with marketing [..]
⁃ Second, think about removing the organizational bottlenecks around data processes [..]
⁃ There are also some other activities that could help with reducing friction, such as establishing data provenance. [..]
Понравился тезис, что хранение данных, должно «оплачивать свою аренду» =)
Another thing I'd suggest keeping in mind: how much does the data cost? When your company stores values for a certain attribute (anything, say "the day of birth of the user"): how much does it cost to store all those days of birth, in dollars? Next question is of course: does this data pay the rent?
Кажется, у дата инженеров принят обратный подход: надо собрать с источника все доступные данные, желательно с сохранением истории изменений. И потом ещё у себя всё собранное разложить на две реплики в двух кластерах ^_^
Но это всё в «сырых» слоях. А вот дальше по слоям уже действительно протаскивается только нужное и скурпулёзно документированное.
https://minimalmodeling.substack.com/p/how-to-grow-as-a-database-developer
Minimal Modeling
How to grow as a database developer?
Here is my response to the question: "What would you, more experienced DB devs recommend a less experienced dev learn to grow and improve their database skills?"
👍4
data будни
😱 ААА! Код-ревью Прошёл тут эпичный код-ревью: 20 комментов в самом пулл-реквесте и ещё 43 сообщения в соответствующем треде в Слаке. Было жёстко, но интересно! Всё началось как приключение на 20 минут: поправить в двух сущностях поля партиционирования и…
Необязательные код-ревью
Интересный подход применяют в компании Raycast — они решили отказаться от обязательных код-ревью и коммитить сразу в дев ветку. Ежедневно автоматика собирает внутренний релиз из этой ветки, чтобы проявить возможные нестыковки.
Приводят следующие доводы:
⁃ Ревью подрывает доверие, типа твоему решению не доверяют и за тобой приходятся проверять код
⁃ Баги случаются и после код-ревью, то есть это не 100% гарантия
⁃ Ревью отнимает время, а значит тормозит разработку
Видимо, это удобно когда маленькая команда и высокий средний навык. Оставляя код-ревью только для отдельных осознанных случаев — когда затрагиваешь новый участок кода или идёт адаптация новых сотрудников.
https://www.raycast.com/blog/no-code-reviews-by-default
И к заметке есть отдельные комментарии, где радуются за авторов и потом рассказывают почему так делать нельзя, и почему всё сломается.
https://news.ycombinator.com/item?id=27606066
И в комментариях приводят ссылку на ментальную модель про забор Честертона. Мол, не спеши удалять то, что сделано до тебя, пока не разобрался зачем оно нужно. «Не нужно» или «не знаю зачем нужно» — недостаточные аргументы. Если предположить, что делали не полные дураки, то надо для начала разузнать истинную причину зачем делали и уже судить по ней.
https://fs.blog/chestertons-fence/
Интересный подход применяют в компании Raycast — они решили отказаться от обязательных код-ревью и коммитить сразу в дев ветку. Ежедневно автоматика собирает внутренний релиз из этой ветки, чтобы проявить возможные нестыковки.
Приводят следующие доводы:
⁃ Ревью подрывает доверие, типа твоему решению не доверяют и за тобой приходятся проверять код
⁃ Баги случаются и после код-ревью, то есть это не 100% гарантия
⁃ Ревью отнимает время, а значит тормозит разработку
Видимо, это удобно когда маленькая команда и высокий средний навык. Оставляя код-ревью только для отдельных осознанных случаев — когда затрагиваешь новый участок кода или идёт адаптация новых сотрудников.
https://www.raycast.com/blog/no-code-reviews-by-default
И к заметке есть отдельные комментарии, где радуются за авторов и потом рассказывают почему так делать нельзя, и почему всё сломается.
https://news.ycombinator.com/item?id=27606066
И в комментариях приводят ссылку на ментальную модель про забор Честертона. Мол, не спеши удалять то, что сделано до тебя, пока не разобрался зачем оно нужно. «Не нужно» или «не знаю зачем нужно» — недостаточные аргументы. Если предположить, что делали не полные дураки, то надо для начала разузнать истинную причину зачем делали и уже судить по ней.
https://fs.blog/chestertons-fence/
Raycast
No code reviews by default - Raycast Blog
How we built an engineering culture based on trust that allows us to move incredibly fast without requiring code reviews.
👍2
data будни
Необязательные код-ревью Интересный подход применяют в компании Raycast — они решили отказаться от обязательных код-ревью и коммитить сразу в дев ветку. Ежедневно автоматика собирает внутренний релиз из этой ветки, чтобы проявить возможные нестыковки. Приводят…
Максимизация скорости разработки через ZDD©
К предыдущему посту Игорь Мосягин прислал релевантную ссылку — как Илья Лебедев 2 года назад внедрял в BestDoctor нечто под названием Zaeb*s Driven Development.
https://youtube.com/watch?v=8lSG028Z2Vg
Ребят не устраивал предыдущий подход, в первую очередь своей скоростью разработки. Понравилось как они декомпозировали глобальную цель и пересмотрели каждый этап разработки через новую призму. И неважно насколько дико это может выглядеть.
Как было:
1. Фича-бранч у каждого разраба
2. Мерж-реквест, который ревьюился (сколько-то кем-то)
3. Все фичи спринта мерджились в релиз-ветку
4. Всё «регрессилось»
5. Мерж в мастер → прод
Как хочется:
⁃ очень частые интеграции кода
⁃ частые релизы
⁃ много тестов
⁃ автоматизировать что можно
⁃ not break things much
К чему пришли:
⁃ фигачить в мастер, к чёрту бранч
⁃ релизы по расписанию на кроне (неотвратимы как рассвет!)
⁃ тесты не блокируют релиз (хе-хе)
⁃ код-ревью не блокирует релиз (хе-хе-хе!)
⁃ боты говорят людям, что делать (посмотреть такой-то пр до HH:MM сегодня)
⁃ обвешали процесс метриками, которые прорастают в OKR
- по ночам на простаивающем железе гонялись времязатратные тесты
Общие подходы:
⁃ убираем ручной труд
⁃ сокращаем ментальную сложность — что можно перекладываем на машины
- много общаемся с коллегами, объясняя свои подходы =)
К предыдущему посту Игорь Мосягин прислал релевантную ссылку — как Илья Лебедев 2 года назад внедрял в BestDoctor нечто под названием Zaeb*s Driven Development.
https://youtube.com/watch?v=8lSG028Z2Vg
Ребят не устраивал предыдущий подход, в первую очередь своей скоростью разработки. Понравилось как они декомпозировали глобальную цель и пересмотрели каждый этап разработки через новую призму. И неважно насколько дико это может выглядеть.
Как было:
1. Фича-бранч у каждого разраба
2. Мерж-реквест, который ревьюился (сколько-то кем-то)
3. Все фичи спринта мерджились в релиз-ветку
4. Всё «регрессилось»
5. Мерж в мастер → прод
Как хочется:
⁃ очень частые интеграции кода
⁃ частые релизы
⁃ много тестов
⁃ автоматизировать что можно
⁃ not break things much
К чему пришли:
⁃ фигачить в мастер, к чёрту бранч
⁃ релизы по расписанию на кроне (неотвратимы как рассвет!)
⁃ тесты не блокируют релиз (хе-хе)
⁃ код-ревью не блокирует релиз (хе-хе-хе!)
⁃ боты говорят людям, что делать (посмотреть такой-то пр до HH:MM сегодня)
⁃ обвешали процесс метриками, которые прорастают в OKR
- по ночам на простаивающем железе гонялись времязатратные тесты
Общие подходы:
⁃ убираем ручной труд
⁃ сокращаем ментальную сложность — что можно перекладываем на машины
- много общаемся с коллегами, объясняя свои подходы =)
YouTube
ZDD: как устроена разработка в BestDoctor
"ZDD: как устроена разработка в BestDoctor" – Илья Лебедев, BestDoctor dev meetup #1
Слайды: https://speakerdeck.com/bestdoctor/zdd-kak-ustroiena-razrabotka-v-bestdoctor
Слайды: https://speakerdeck.com/bestdoctor/zdd-kak-ustroiena-razrabotka-v-bestdoctor
👍1
Мета ДВХ: ДВХ для ДВХ
Посмотрел доклад Жени Ермакова двухлетней давности о том как они делали МетаДВХ в Яндекс Такси. Отдельное удовольствие сначала поработать годик внутри, а потом посмотреть такое вводное видео как пришли к такому решению.
Суть доклада сводиться к тому, что логи использования ДВХ засунули в ДВХ как отдельный источник. Смоделировав опрятные модели, это позволило посчитать метрики и отслеживать насколько хорошо команды ДВХ справляются со своими задачами.
Мы пользуемся такими отчётами, чтобы отслеживать использование новых объектов (не зря ли мы старались, добавляя их); а ещё поддерживаем счёт в нашей битве за пользователей с «теневым двх»: ключевая метрика здесь — соотношение использования двх-объектов ко всем прочим.
https://youtube.com/watch?v=EHmf0tTxd6A
Посмотрел доклад Жени Ермакова двухлетней давности о том как они делали МетаДВХ в Яндекс Такси. Отдельное удовольствие сначала поработать годик внутри, а потом посмотреть такое вводное видео как пришли к такому решению.
Суть доклада сводиться к тому, что логи использования ДВХ засунули в ДВХ как отдельный источник. Смоделировав опрятные модели, это позволило посчитать метрики и отслеживать насколько хорошо команды ДВХ справляются со своими задачами.
Мы пользуемся такими отчётами, чтобы отслеживать использование новых объектов (не зря ли мы старались, добавляя их); а ещё поддерживаем счёт в нашей битве за пользователей с «теневым двх»: ключевая метрика здесь — соотношение использования двх-объектов ко всем прочим.
https://youtube.com/watch?v=EHmf0tTxd6A
YouTube
Евгений Ермаков: Meta DWH о DWH для DWH
Data Fest Online 2020
Data Governance track https://ods.ai/tracks/data-governance-df2020
Спикер: Евгений Ермаков, архитектор хранилищ данных, Яндекс Такси
Из очень простой идеи «а почему бы нам не сделать хранилище данных на данных самого хранилища данных…
Data Governance track https://ods.ai/tracks/data-governance-df2020
Спикер: Евгений Ермаков, архитектор хранилищ данных, Яндекс Такси
Из очень простой идеи «а почему бы нам не сделать хранилище данных на данных самого хранилища данных…
🔥7
Netflix Chaos Monkey
чтобы достичь доступности в распределённых сервисах используют избыточность: несколько дисков в рейд-массиве вместо одного или несколько машин вместо одной.
в идеале при выходе из строя одного элемента, система должна поддерживать дееспособность на определённом уровне. Если у нас 10 000 дисков, то по техническим допускам в среднем один диск должен выходить из строя каждый день.
даже когда есть чёткие инструкции по восстановлению, только практика может отточить навык, а чтобы такая практика происходила регулярно, в Нетфликсе в инфру запускают МАРТЫШКУ ХАОСА (лайк за нейминг!).
точнее даже целое стадо разноспециализированных мартышек: одна рандомно прибивает неоптимальной настроенные машинки, другая повышает время отклика, третья смотрит на настройки доступа и т.д.
в конце приходит рейд-босс — Chaos Gorilla — и вырубает целую зону в облачной инфре.
https://netflixtechblog.com/the-netflix-simian-army-16e57fbab116
чтобы достичь доступности в распределённых сервисах используют избыточность: несколько дисков в рейд-массиве вместо одного или несколько машин вместо одной.
в идеале при выходе из строя одного элемента, система должна поддерживать дееспособность на определённом уровне. Если у нас 10 000 дисков, то по техническим допускам в среднем один диск должен выходить из строя каждый день.
даже когда есть чёткие инструкции по восстановлению, только практика может отточить навык, а чтобы такая практика происходила регулярно, в Нетфликсе в инфру запускают МАРТЫШКУ ХАОСА (лайк за нейминг!).
точнее даже целое стадо разноспециализированных мартышек: одна рандомно прибивает неоптимальной настроенные машинки, другая повышает время отклика, третья смотрит на настройки доступа и т.д.
в конце приходит рейд-босс — Chaos Gorilla — и вырубает целую зону в облачной инфре.
https://netflixtechblog.com/the-netflix-simian-army-16e57fbab116
Medium
The Netflix Simian Army
Keeping our cloud safe, secure, and highly available
🔥16
data будни
Мета ДВХ: ДВХ для ДВХ Посмотрел доклад Жени Ермакова двухлетней давности о том как они делали МетаДВХ в Яндекс Такси. Отдельное удовольствие сначала поработать годик внутри, а потом посмотреть такое вводное видео как пришли к такому решению. Суть доклада…
DWH → Data Mesh
Рассказ Жени Ермакова как переводили DWH Яндекс GO на рельсы Data Mesh. Женя там явно ссылается на предыдущий рассказ ↑ о метриках ДВХ, поэтому лучше начать с предыдущего.
Когда DWH достигает определённого размера, то теряется скорость и адаптивность — всё как у стартапа, переходящего к большой компании.
В мире разработки в таких случаях принято распиливать монолит на микросервисы, а на просторах DWH консалтеры из Thoughtworks в лице Zhamak Dehghani придумали парадигму Data Mesh. Это когда в DWH есть условно независимые архитектурные кванты с единой платформой и под общим федеративно-архитектурным присмотром.
На практике это выглядело как выделение команд в отдельные ДВХ. Мы съехали со своими етл-пайплайнами на отдельный «етл-сервис» с независимым циклом релиза. А потом постепенно забрали все свои сущности в отдельные схемы-домены.
Получается, раньше аналитики и менеджера Доставки носили свои хотелки в DWH Такси, а после разъезда им стало ходить ближе — появилось «своё» DWH, плотно погруженное в доменную область.
из недостатков:
⁃ пришлось перетащить кажется все сущности в другие папки-схемы. Некоторые по несколько раз >_< Не обошлось без сопутствующих проблем: очевидцы вспоминают процесс не иначе как «демонизация» (вместо официального «доменизация»)
⁃ при делении техническая экспертиза распределилась неравномерно между командами
в вопросах после доклада кто-то «из зала» обратил внимание на схожесть описанного Женей процесса на внедрение аджайла — поверим ему на слово =)
https://youtube.com/watch?v=XCnHS_lXHAA&si=EnSIkaIECMiOmarE
Рассказ Жени Ермакова как переводили DWH Яндекс GO на рельсы Data Mesh. Женя там явно ссылается на предыдущий рассказ ↑ о метриках ДВХ, поэтому лучше начать с предыдущего.
Когда DWH достигает определённого размера, то теряется скорость и адаптивность — всё как у стартапа, переходящего к большой компании.
В мире разработки в таких случаях принято распиливать монолит на микросервисы, а на просторах DWH консалтеры из Thoughtworks в лице Zhamak Dehghani придумали парадигму Data Mesh. Это когда в DWH есть условно независимые архитектурные кванты с единой платформой и под общим федеративно-архитектурным присмотром.
На практике это выглядело как выделение команд в отдельные ДВХ. Мы съехали со своими етл-пайплайнами на отдельный «етл-сервис» с независимым циклом релиза. А потом постепенно забрали все свои сущности в отдельные схемы-домены.
Получается, раньше аналитики и менеджера Доставки носили свои хотелки в DWH Такси, а после разъезда им стало ходить ближе — появилось «своё» DWH, плотно погруженное в доменную область.
из недостатков:
⁃ пришлось перетащить кажется все сущности в другие папки-схемы. Некоторые по несколько раз >_< Не обошлось без сопутствующих проблем: очевидцы вспоминают процесс не иначе как «демонизация» (вместо официального «доменизация»)
⁃ при делении техническая экспертиза распределилась неравномерно между командами
в вопросах после доклада кто-то «из зала» обратил внимание на схожесть описанного Женей процесса на внедрение аджайла — поверим ему на слово =)
https://youtube.com/watch?v=XCnHS_lXHAA&si=EnSIkaIECMiOmarE
YouTube
Как с помощью Data Mesh разломать ваше DWH — Евгений Ермаков, Яндекс GO
Концепция «Data Mesh» стала притчей в мире данных и все больше компаний пытаются его внедрить. Но возникает справедливый вопрос — стоит ли этот подход окружающего его хайпа или это просто веяние моды, которое сменится чем-то в ближайшее время?
В рамках…
В рамках…
👍3
иллюстрация «как должен выглядеть Data Mesh» из той самой статьи от Zhamak Dehghani из 2020 года
https://martinfowler.com/articles/data-mesh-principles.html
сверху купол федеративного арх-надзора с документами-инструкциями
в центре слои-домены с выделенными командами
в основании — общая платформа для того, чтобы всё работало
https://martinfowler.com/articles/data-mesh-principles.html
сверху купол федеративного арх-надзора с документами-инструкциями
в центре слои-домены с выделенными командами
в основании — общая платформа для того, чтобы всё работало
👍1🔥1
NoSQL → Not Only SQL
NoSQL сейчас употребляется в смысле anti-SQL, как противопоставление доминирующим ораклам и постягрям с их ненавистной реляционной моделью.
Хотя изначально смысл закладывался другой — не прямое противопоставление, а как ещё один вариант, алтернатива. В Книге С Кабанчиком™ Мартин Клеппманн приводит ссылку на заметку из 2009 года.
https://web.archive.org/web/20190623045155/http://blog.sym-link.com/2009/10/30/nosql_whats_in_a_name.html
Действительно это был просто хэштег для митапа по альтернативным базам данных. Хештег потом прилепился, но смысл его постепенно стал более категоричным.
А изначально было действительно в значение Not Only SQL.
и ещё вот твит от фаундера графовой БД Neo4j из того же 2009
https://twitter.com/emileifrem/status/5200345765
NoSQL сейчас употребляется в смысле anti-SQL, как противопоставление доминирующим ораклам и постягрям с их ненавистной реляционной моделью.
Хотя изначально смысл закладывался другой — не прямое противопоставление, а как ещё один вариант, алтернатива. В Книге С Кабанчиком™ Мартин Клеппманн приводит ссылку на заметку из 2009 года.
https://web.archive.org/web/20190623045155/http://blog.sym-link.com/2009/10/30/nosql_whats_in_a_name.html
Действительно это был просто хэштег для митапа по альтернативным базам данных. Хештег потом прилепился, но смысл его постепенно стал более категоричным.
А изначально было действительно в значение Not Only SQL.
и ещё вот твит от фаундера графовой БД Neo4j из того же 2009
https://twitter.com/emileifrem/status/5200345765
Twitter
@samj @jeremyday Who are those people? Honestly want to know. I for one have tried REALLY HARD to emphasize that #nosql = Not Only SQL.
🔥1
Легенды базостроительства в подкасте от dbt
Mike Stonebraker занимается базами данных с 1970-х. Тогда он написал реляционную БД Ingress, за три года до того как Ларри Эллисон выпустил Oracle. После этого Майкл приложил руку к Postgres (название отсылает к Ingres).
Рассказал, как в 1990-х обратили внимание на колоночный тип хранения. Строчное хранение оптимизирует запись, в то время как данных скопилось много и начались проблемы со скоростью чтения — появилась необходимость в том, что стало называться DWH.
В 2005 они выпустили Вертику. Понравилась байка как они пришли показывать Вертику в большой тогдашний е-ком. Там был инстанс Оракла за миллион долларов, который обрабатывал аналитический запрос сутки. Команда Майка установила им Вертику, закачала туда их данные и тот же запрос отработал уже за секунды. Вот она вся прелесть DWH.
Ещё Майк очень сожалеет, что не выложили тогда Вертику в опенсорс — он уверен, что сегодня это было бы дефолтное решение для многих проектов.
Вообще, судя по Википедии, дядьке 79 лет! Он уже как полвека что-то делает полезное, написал несколько популярных движков бд и кажется не планирует останавливаться. Вот сейчас мутит очередной дата-стартап. Говорит, что ему скучно просто лежать на пляже =)
https://roundup.getdbt.com/p/ep38-a-romp-through-database-history
Mike Stonebraker занимается базами данных с 1970-х. Тогда он написал реляционную БД Ingress, за три года до того как Ларри Эллисон выпустил Oracle. После этого Майкл приложил руку к Postgres (название отсылает к Ingres).
Рассказал, как в 1990-х обратили внимание на колоночный тип хранения. Строчное хранение оптимизирует запись, в то время как данных скопилось много и начались проблемы со скоростью чтения — появилась необходимость в том, что стало называться DWH.
В 2005 они выпустили Вертику. Понравилась байка как они пришли показывать Вертику в большой тогдашний е-ком. Там был инстанс Оракла за миллион долларов, который обрабатывал аналитический запрос сутки. Команда Майка установила им Вертику, закачала туда их данные и тот же запрос отработал уже за секунды. Вот она вся прелесть DWH.
Ещё Майк очень сожалеет, что не выложили тогда Вертику в опенсорс — он уверен, что сегодня это было бы дефолтное решение для многих проектов.
Вообще, судя по Википедии, дядьке 79 лет! Он уже как полвека что-то делает полезное, написал несколько популярных движков бд и кажется не планирует останавливаться. Вот сейчас мутит очередной дата-стартап. Говорит, что ему скучно просто лежать на пляже =)
https://roundup.getdbt.com/p/ep38-a-romp-through-database-history
Getdbt
Ep38: A romp through database history (w/ Postgres co-creator Mike Stonebraker + Andy Palmer)
How did datetime as a type come to be? And other factoids to use at your next data meetup.
👍6🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
в каждом меме есть доля шутки — в далёком 2020 я присматривался куда пойти… и не пошёл в ML 🙃 типа ща я тут по-быстрому с аналитикой сперва разберусь, а там до мл уже шапкой докинуть!
🔥19👍3
короткой строкой про дата-инженерские вакансии в Яндексе:
1. открыта вакансия в Практикум. Судя по описанию, всё довольно стандартно: там собрать, сюда положить, сверху витрины; ждут кандидатов с 3+ годами опыта. Если я ничего не путаю, Практикум работает удалённо, а ещё там супер душевная команда ❤️
2. а ещё случайно узнал, что 4-5 марта (это уже ЗАВТРА!) можно получить фаст оффер в DWH Яндекс Маркета. Про требования к кандидатам всё написано общо́. Маркет использует подходы к двх-строению как у нас в Go, поэтому там должно быть круто. Я б сходил чисто по фану — часто перетереть за данные с умными людьми без каких-то обязательств 😉
3. ну и к нам в Доставку тоже ищут инженера. У нас YT (Hadoop) + Greenplum, свой etl-фрейморк, работающий data mesh и свой анкор-моделинг для дата-ценителей. Тут уже могу рассказать всё в деталях, если будет интересно.
1. открыта вакансия в Практикум. Судя по описанию, всё довольно стандартно: там собрать, сюда положить, сверху витрины; ждут кандидатов с 3+ годами опыта. Если я ничего не путаю, Практикум работает удалённо, а ещё там супер душевная команда ❤️
2. а ещё случайно узнал, что 4-5 марта (это уже ЗАВТРА!) можно получить фаст оффер в DWH Яндекс Маркета. Про требования к кандидатам всё написано общо́. Маркет использует подходы к двх-строению как у нас в Go, поэтому там должно быть круто. Я б сходил чисто по фану — часто перетереть за данные с умными людьми без каких-то обязательств 😉
3. ну и к нам в Доставку тоже ищут инженера. У нас YT (Hadoop) + Greenplum, свой etl-фрейморк, работающий data mesh и свой анкор-моделинг для дата-ценителей. Тут уже могу рассказать всё в деталях, если будет интересно.
yandex.ru
Вакансия «Data Engineer в Практикум» в Яндексе — работа в компании Яндекс для IT-специалистов
Работа в компании Яндекс для специалиста «Data Engineer в Практикум» с уровнем квалификации от «Специалист» до «Старший» — Высокая заработная плата и социальные гарантии в IT-компании России
🔥12
деньги-денежки-деньжата
так-так-так, что тут у нас? это же зарплаты дата-профессий в Европе!
что может быть интереснее, чем залезть в карман к брату-инженеру и узнать сколько туда капает каждый месяц.
ребята собрали статистику по 500 вакансиям, сконвертили всё в доллары и сделали разрезы по синьорности, стране и компаниям.
⌘ что интересного увидели:
1. по синьорности: зп есть прямая корреляция на первых 6 лет карьеры, дальше всё по-разному
2. по локациям: в Берлина в среднем зп ниже, объясняют наличием там офисов Delivery Hero и Zalando, где зп чуть ниже рынка. А вот в Дублине, кажется, собрались сеньёристые ребята и там явный перекос зп в сторону высоких грейдов.
3. по компаниям: Delivery Hero и Zalando находятся где-то слева на распределении зп (см. п2 про них). А вот в Мете, Амазоне и Букинге есть выбросы по зп даже для мидлов — вот кому хорошо)
⌘ для нашего рынка раньше такое делали Хабр в 2021 и New.HR в 2019
за ссылку спасибо подборке от дата-кофе
так-так-так, что тут у нас? это же зарплаты дата-профессий в Европе!
что может быть интереснее, чем залезть в карман к брату-инженеру и узнать сколько туда капает каждый месяц.
ребята собрали статистику по 500 вакансиям, сконвертили всё в доллары и сделали разрезы по синьорности, стране и компаниям.
⌘ что интересного увидели:
1. по синьорности: зп есть прямая корреляция на первых 6 лет карьеры, дальше всё по-разному
2. по локациям: в Берлина в среднем зп ниже, объясняют наличием там офисов Delivery Hero и Zalando, где зп чуть ниже рынка. А вот в Дублине, кажется, собрались сеньёристые ребята и там явный перекос зп в сторону высоких грейдов.
3. по компаниям: Delivery Hero и Zalando находятся где-то слева на распределении зп (см. п2 про них). А вот в Мете, Амазоне и Букинге есть выбросы по зп даже для мидлов — вот кому хорошо)
⌘ для нашего рынка раньше такое делали Хабр в 2021 и New.HR в 2019
за ссылку спасибо подборке от дата-кофе
👍6
#послушано
доклад Ивана Ямщикова на TechTrain про практические применения МЛ — от банальных до продвинутых. Медицина, легал и прочие отрасли. В конце общее (позитивное!) напутствие.
> Какие сейчас перед нами сценарии развития искусственного интеллекта? Ждет ли нас еще одна «зима»? Как машинное обучение меняет рынки, общества и планету?
iTunes, YouTube
⌘⌘⌘
В яндексовый подкаст позвали двух директоров Такси (и одного таксиста-блогера). Поговорили об актуальном: распределение загрузки сервиса по часам и месяцам, цены на поездки, как внедряют новые фичи. Ещё из подкаста можно узнать, что СЕО Яндекс Такси регулярно таксует в Саратове (до чего работа довела человека!)
iTunes, YouTube
⌘⌘⌘
Спотифай делает аккуратный шажочек в голосовые помощники. Там взяли крутого диджея, заперлись с ним в студии и сделали персонального диджея для каждого пользователя Спотифай. МЛ-диджей объявляет следующие треки и иногда делает вставки с фан-фактами об исполнителе. Примечательно, что диджей интегрирован с рекомендательной системой и может комментировать почему та или иная песня попала именно в твой плейлист.
iTunes
#подкаст
доклад Ивана Ямщикова на TechTrain про практические применения МЛ — от банальных до продвинутых. Медицина, легал и прочие отрасли. В конце общее (позитивное!) напутствие.
> Какие сейчас перед нами сценарии развития искусственного интеллекта? Ждет ли нас еще одна «зима»? Как машинное обучение меняет рынки, общества и планету?
iTunes, YouTube
⌘⌘⌘
В яндексовый подкаст позвали двух директоров Такси (и одного таксиста-блогера). Поговорили об актуальном: распределение загрузки сервиса по часам и месяцам, цены на поездки, как внедряют новые фичи. Ещё из подкаста можно узнать, что СЕО Яндекс Такси регулярно таксует в Саратове (до чего работа довела человека!)
iTunes, YouTube
⌘⌘⌘
Спотифай делает аккуратный шажочек в голосовые помощники. Там взяли крутого диджея, заперлись с ним в студии и сделали персонального диджея для каждого пользователя Спотифай. МЛ-диджей объявляет следующие треки и иногда делает вставки с фан-фактами об исполнителе. Примечательно, что диджей интегрирован с рекомендательной системой и может комментировать почему та или иная песня попала именно в твой плейлист.
iTunes
#подкаст
Apple Podcasts
Вещие вещи: искусственный интеллект и будущее
Выпуск подкаста · Проветримся! · Сез. 8, вып. 6 · 40 мин.
👍4
студенты есть? там открыли конкурс на стажировки, где за деньги можно поконтрибьютить в разный опенсорс: CatBoost, YDB и наш любимый YTsaurus
https://foss.kruzhok.org/code-for-all
https://foss.kruzhok.org/code-for-all
foss.kruzhok.org
Код для всех 2025
Онлайн программа для начинающих разработчиков, которые хотят узнать больше об интересных проектах в open source и готовы развивать их с помощью менторов в течение 6 недель в 2025 году
Промпт-инженеры
Зацепила фраза Григория Бакунова (bobuk) про промт для GitHub Copilot (работает на ChatGPT):
> Для тех кто не программирует, посмотрите на картинку — вот так выглядит будущее программирование искусственного интеллекта.
Действительно эти ~25 предложений можно представить как ~25 абзацев кода для какого-то приложения.
Продолжая аналогию с программированием, можно вспомнить с чего начинается почти каждый урок — тот самый Hello world! И то же самое происходит с тем, кто впервые сталкивается с гот-моделями — их промты простые и односложные.
А вот продвинутые юзеры гпт-моделей через пробы и ошибки учатся улучшают свои промты и некоторые уже даже не помещаются на страницу. Чем не продвинутая программа уже?
Получается, придумали весь этот МЛ, чтобы не писать кучу IF’ов — и теперь пишем эти же ифы, только теперь на естественном языке.
Зацепила фраза Григория Бакунова (bobuk) про промт для GitHub Copilot (работает на ChatGPT):
> Для тех кто не программирует, посмотрите на картинку — вот так выглядит будущее программирование искусственного интеллекта.
Действительно эти ~25 предложений можно представить как ~25 абзацев кода для какого-то приложения.
Продолжая аналогию с программированием, можно вспомнить с чего начинается почти каждый урок — тот самый Hello world! И то же самое происходит с тем, кто впервые сталкивается с гот-моделями — их промты простые и односложные.
А вот продвинутые юзеры гпт-моделей через пробы и ошибки учатся улучшают свои промты и некоторые уже даже не помещаются на страницу. Чем не продвинутая программа уже?
Получается, придумали весь этот МЛ, чтобы не писать кучу IF’ов — и теперь пишем эти же ифы, только теперь на естественном языке.
Telegram
addmeto
Пользователи бета-версии нового Github CoPilot смогли добраться до его промпта, т.е. текстового запроса, который помещается в каждый диалог, чтобы GPT4 делал то, что задумано. Посмотрите, как любопытно.
Для тех кто не программирует, посмотрите на картинку…
Для тех кто не программирует, посмотрите на картинку…
👍2
Книжный клуб + Кабанчик = 🖤
Два года назад как начинающий и ответственный дата-инженер заказал оригинал книги Мартина Клеппманна Designing Data-Intensive Applications с Амазона. Но книга так и лежала у меня с тех пор, не смотря на рейтинг 5.0 и рекомендации со всех сторон.
И вот в рабочей флудилке заговорили про книжные клубы, я решил что это хороший повод и закинул идею совместно прочитать этот технический бестселлер.
План был максимальной простой: одна глава = одна неделя. Встречаемся каждый четверг, обсуждаем прочитанное, вспоминаем байки из опыта (если есть), находим аналоги в нашей инфраструктуре. И вот спустя 12 недель Кабанчик прочитан, книга исчёркана карандашными заметками, в заметках осталось 12 относительно структурированных конспектов.
В общем идею можно признать успешной: паблик комитент работает плюс в компании единомышленников читать веселее. Сами обсуждения тоже были полезными: приносил темы что остались непонятными, а коллеги подсказывали что упустил — профит!
Заметки на будущее: сложность материала возрастает к последним главам. В первых Мартин описывает базовые концепции и повествование в следующих главах строит уже поверх них. Последние несколько глав можно смело делить на два захода, потому как 50-60 страниц технического текста за неделю осилить уже сложновато.
Отдельно стоит отметить примечания к каждой главе. Мартин скрупулёзно собирал источники для каждого тезиса. В заметках можно найти научные работы, датированные начиная с 1960-х и до 2018 (года публикации книги). Для желающих копнуть глубже можно всегда обратиться к оригиналам.
Два года назад как начинающий и ответственный дата-инженер заказал оригинал книги Мартина Клеппманна Designing Data-Intensive Applications с Амазона. Но книга так и лежала у меня с тех пор, не смотря на рейтинг 5.0 и рекомендации со всех сторон.
И вот в рабочей флудилке заговорили про книжные клубы, я решил что это хороший повод и закинул идею совместно прочитать этот технический бестселлер.
План был максимальной простой: одна глава = одна неделя. Встречаемся каждый четверг, обсуждаем прочитанное, вспоминаем байки из опыта (если есть), находим аналоги в нашей инфраструктуре. И вот спустя 12 недель Кабанчик прочитан, книга исчёркана карандашными заметками, в заметках осталось 12 относительно структурированных конспектов.
В общем идею можно признать успешной: паблик комитент работает плюс в компании единомышленников читать веселее. Сами обсуждения тоже были полезными: приносил темы что остались непонятными, а коллеги подсказывали что упустил — профит!
Заметки на будущее: сложность материала возрастает к последним главам. В первых Мартин описывает базовые концепции и повествование в следующих главах строит уже поверх них. Последние несколько глав можно смело делить на два захода, потому как 50-60 страниц технического текста за неделю осилить уже сложновато.
Отдельно стоит отметить примечания к каждой главе. Мартин скрупулёзно собирал источники для каждого тезиса. В заметках можно найти научные работы, датированные начиная с 1960-х и до 2018 (года публикации книги). Для желающих копнуть глубже можно всегда обратиться к оригиналам.
🔥17