rockyourdata | Unsorted

Telegram-канал rockyourdata - Инжиниринг Данных

23384

Делюсь новостями из мира аналитики и карьерными советами. 15 лет в Аналитике и Инжиниринге Данных, 10 лет в MAANG 🛠️ dataengineer.ru | 🏄‍♂️ Surfalytics.com №5017813306 Реклама: https://almond-rule-130.notion.site/1199f595f76a8030ba1be1e607c9a8ce

Subscribe to a channel

Инжиниринг Данных

На этой неделе буду в Денвере, Колорадо, а в выходные в Сиэтле. Можно как обычно на data&drinks🗽

Читать полностью…

Инжиниринг Данных

Записал видео для вас в августе 2024, но что-то не опубликовал, зато в августе 2025 можно вернуться в прошлое:)

Читать полностью…

Инжиниринг Данных

А у нас кстати в Ванкувере ходят туры на Аляску🛥, не бывали еще на Аляске? Хорошее направление, может кто порекомендует?

Читать полностью…

Инжиниринг Данных

996 - новая норма для AI стартапов и BigTech.

Это значит с 9 утра до 9 вечера 6 дней в неделю. Говорят, что в Китайских компаниях это норма. Хотят недавно казалось, что все единогласно были против crazy work hours в западном мире. Так же, как и кто-то говорил, что 4х дневная рабочая неделя это круто и эффективно. Некоторые СЕО вообще говорят, что 6 дней это хорошо, но лучше 7 дней. Короче grinding in the office day and night это новая норма.

Время прошло, и теперь компании с самыми высокими зарплатами хотят, чтобы люди работали в офисе, 80+ часов в неделю. Чтобы себя заставить так много работать, надо от этого балдеть. Чтобы кайфовать от того, что ты делаешь, должен быть хороший incentive.

Я вообще верю, что в основе любой мотивации лежит incentive, он может быть материальный и нематериальный. В случае с AI компаниями, им удается сразу платить намного выше рынка, даже рядовым инженерам. И все они работают над крутой миссией, ощущая себя причастным к великому. Часто в ущерб здоровью и семье. Но каждый волен делать, что ему нравится.

Возможно когда вам 20-30, самое время фигачить по 80+ часов и зарабатывать как CEO. Хотя реальность такова, что вы можете работать столько же много и получать низкую зарплату, и даже не работать на созданием AGI, а просто ковырять кривые отчетики в токсичной компании с токсичным руководством.

С другой стороны, чтобы создать что-то великое, нужно пахать, пахать и гореть тем, что ты делаешь - get rich or die trying?:)

Я уверен у каждого должен быть период в жизни 996, но это не должно становится нормой. Тут как в анекдоте про профессионалов и любителей.

Вызывают на заводе двух инженеров чинить сломавшийся станок.

Любитель:
Приходит с чемоданом инструментов, раскручивает половину станка, меняет кучу деталей, возится весь день. В итоге станок кое-как заработал, но с грохотом и искрами.

Профессионал:
Приходит, слушает станок пять секунд, достаёт маленький молоточек, тук — и всё заработало идеально.

Директор удивлён:
— И за что вы хотите 500 долларов? За один удар?


Профессионал:
— Нет. Один доллар — за удар.
499 — за то, что знал, куда ударить.


Мораль, чтобы иметь хорошую карьеру, зарабатывать выше рынка, вам не обязательно работать в AI стратапе 996. Даже работаю в AI стартапе, вы все еще должны думать о job security. Совсем недавно, Cognition купил остатки Windsurf. Сразу уволили 30 человек. Остальным 200 предложили buyout, чтобы они ушли. Их СЕО сказал - «Мы не верим в work-life balance — миссия настолько важна, что разделить её с жизнью нельзя»

Поэтому каждый сам выбирает, что его делает счастливым🤝

Читать полностью…

Инжиниринг Данных

Data-специалисты — общий сбор 💪

В этом году на IT-конференции GoCloud Tech будет отдельный трек про данные и аналитику:

➡️ Платформа данных в облаке
➡️ Как настраивать потоковое чтение с геораспределенных хранилищ
➡️ Как работают быстрые NVMe-oF RDMA-диски
➡️ Тренды в мире данных: куда стремятся СУБД
➡️ Как работать на автопилоте с Jupyter-ноутбуком


А еще будут отдельные треки про тренды в AI&ML, облачную инфраструктуру и инструменты, ускоряющие разработку.

Где и когда ⬇️
3 сентября, Москва, Гоэлро Лофт

Регистрируйтесь🖱

Читать полностью…

Инжиниринг Данных

Пример data stack в компании Clair. Взял у них в Linkedin.

Очень стандартный и понятный кейс. Если сравнить с РФ кейсом, то на российском рынке нет 3rd party managed продуктов для ETL, BI, DW. Ну как нет, они-то есть, но всегда возникает вопрос, а где хостить? А где хранить данные? Вроде бы облаком можно отечественным, но вот много всяких НО.

Поэтому по опыту общения с коллегами вижу два основных направления:

1) полностью on-premise так, где может быть Hadoop+HDFS+Spark, Greenplum или Clickhouse.
Все остальное для слоя хранения редко и не обычно. Есть еще множество старых и надежных решений на SQL Server.

Для загрузки данных используют Python и запускают его в Airflow, иди стрим через Kafka.

2) компании по смелей или по меньше уже могут идти в облака и строить там аналитические решения на VK, Ya облаках. Причем у них есть отличная возможность хостить все на Managed Kubernetes, чтобы развернуть Airbyte, Metabase, Trino и тп. Такой кейс будет очень похож на западный, но выбор инструментов будет достаточно скуден и устоявшийся

На западе наоборот все, мы сначала выбираем public cloud - AWS, Azure, GCP. Затем выбираем слой хранения (Snowflake, Databricks, Trino, Athena, Synapse, BigQuery) и потом уже решаем как туда загружать данных и как их визуализоровать. Как правило все инструменты отлично поддерживают кейсы для ML, Streaming, Reverse ETL.

Еще кардинальная разница будет в DevOps и Data Observability. На западе очень много решений на любой вкус и цвет и все они стандартизированы и работают с любым из публичных облаков.

Поэтому в зависимости от ваших карьерных целей, ваш road map может отличаться.

Читать полностью…

Инжиниринг Данных

Давно мы не обсуждали эксперименты…! 🧐

Подумали аналитики из Авито и запланировали онлайн-митап на 14 августа. Там будут обсуждаться 3 доклада:

☄️ Дмитрий Кротов из команды Авито Подработки расскажет, как делегировать часть аналитики без ущерба для процессов;

☄️ Егор Лукьянов из Ozon поделится опытом работы с сейлз-командами и бэк-офисом и объяснит, как эксперименты влияют на операционную деятельность компании;

☄️ Диля Хакимова из Яндекса Go раскроет формулу доверия: речь об аналитических доверительных интервалах для ratio- и uplift-метрик.

Обязательно регистрируйтесь и приходите!
Точнее, подключайтесь — в этот раз встреча будет только в онлайне.

Читать полностью…

Инжиниринг Данных

Само решение достаточно не сложное, данные все хранятся в AWS S3 в Parquet. Другая команда использует kinesis и пишет в S3. Данные каждый час обрабатываются с помощью Athena и запускается в Glue Python Shell (даже не PySpark). Результат складывается в другой S3 bucket и дальше он проверяется с помощью другого Glue Job. Все метрики публикуются в Cloud Watch.

Cloud Watch подключен через SNS topic к Pager Duty, и в случае отклонения получаем alert в Slack. Сейчас решение мигрируется в Databricks, таблицы переходят с Parquet на managed delta tables (Parquet + Delta log). Для проверки качества данных используем DBX библиотеку. Самое забавное, цена в Databricks получается значительно дороже, чем в Glue Athena. В качестве оркестратора AWS Managed Airflow.

Читать полностью…

Инжиниринг Данных

Ох gpt5 здесь, чтобы всех нас заменить 🦯

Читать полностью…

Инжиниринг Данных

Интересная статья про отрицательную селекцию

Читать полностью…

Инжиниринг Данных

В русскоязычном IT прямо сейчас разворачивается один из крупнейших скандалов в этом году. Я не могу пройти мимо и хочу высказаться.

Для контекста. Из компании Газпром-Медиа уволили накрутчика опыта, который работал над Rutube. Сотрудники службы безопасности нашли отзыв, который он оставил год назад, где рассказал, что накрутил опыт. Накрутчик работал в компании около года. С его перформансом всё было в порядке. Он готовился идти на повышение.

То есть ещё раз: нормально работающего сотрудника уволили за то, как он попал в компанию год назад.

Газпром-Медиа решили пойти дальше и устроили охоту на ведьм. Сотрудник считается заведомо недобросовестным, если подписан на «Осознанную Меркантильность» (далее «ОМ»). Плевать, накручивал он опыт или нет, как использует сообщество, работает ли на нескольких работах и т. д. Сам факт подписки уже является поводом расторгнуть рабочие отношения.

В Газпром-Медиа запущено так называемое «дело волков» (я не шучу, они сами так его называют), людей водят на допросы в службу безопасности, где светят лампой в лицо.

Охранительная часть IT-комьюнити рукоплещет Газпром-Медиа за такую инициативу. Глеб Михеев написал:

Все, кто идет в волки должны понимать последствия. Последствия со службой безопасности, увольнением с занесением в трудовую, в личное дело. Это должна быть черная метка. Волчья метка.

Если мы хотим, чтобы у нас была в отрасли здоровая атмосфера, то мы обязаны создать в ней институт репутации.


Сам Глеб занимал пост «Директор по развитию образовательной платформы» в Skillbox. Работа там, кстати, на репутацию не влияет. Skillbox всего лишь оставил тысячи людей с кредитами, не дав ничего взамен. А вот подписка на «ОМ» — это клеймо на репутации.

Зачистку же внутри Rutube проводит ещё один моральный камертон отрасли, Head of Client Development в Rutube, Максим Ульянов. На скриншоте его сообщение из внутреннего рабочего чатика. Давайте представим, что институт репутации действительно есть. А вы работаете в государевом видеохостинге, который существует из-за двух причин: распилить гос. бабки и отрезать граждан собственной страны от информации. Плюсом, Rutube — рассадник пиратского контента. Но вы не перепутайте, у Максима репутация просто прекрасная, а вот у подписчиков «ОМ» — нет.

Максим и Глеб, очень хорошо учить других жизни и говорить про репутацию, когда у самих рыльце в пушку. Репутации в IT нет, и вы вдвоём — выгодоприобретатели этого. Потому что если бы она была, то первой бы ударила по вам.

Обращаюсь к обоим, вы публично призываете к тому, чтобы лишить возможности работать огромную группу людей просто по факту подписки на ОМ. Приходите ко мне на канал для дебатов с Антоном. Можете по одному, можете вдвоём. Я готов предоставить площадку для дебатов. Антон дважды дебатировал у меня на канале, от обоих оппонентов Антона ко мне не было нареканий по модерации. Если не принимаете предложение, то жду публичного ответа.

Читать полностью…

Инжиниринг Данных

Изначально мы планировали из Парижа добраться до побережья Франции и взяли машину на 3 дня. Но я ошибся в расчетах и получилось на 6 дней. После Парижа мы поехали в Шампань, пробовать шампанское.

Ездить по полям и лугам Франции показалось скучно и мы решили сразу устроить детям урок географии, прокатиться по немецкому автобану и съесть рульку с пивом, посмотреть на швейцарские банки, поесть пиццу в Италии на озере Лекко, где я проходил стажировку целый месяц лет 15 назад, поплавать на озере Комо и потом уже приехать на французскую Ривьеру.

На карте увидели Баден Баден, что-то с урока по литературе и решили там остановится, покупаться в целебных водах и выпить с Достоевским, когда-то он тут жил. Гоголь тут тоже лечился. Вообще в Баден Баден я больше встретил русских на улице, чем немцев. Тут русский 3й язык и все таблички, рестораны и магазины обслуживают на русском.

Посмотрим, как дела в Цюрихе завтра👉

Читать полностью…

Инжиниринг Данных

Знаете какая самая популярная метрик в SaaS бизнесе?

ARR (Annual Recurring Revenue). Это когда вы продаете продукт по подписке (subscription), где клиенты могу платить по месяцам. То есть, если купили ChatGPT за 20$ в месяц, то ARR будет 12x20=240$. Конечно, там всякие нюансы, про годовую vs месячную подписку, B2B vs B2C, модели ценообразования и тп, но это прям must have domain knowledge. Есть еще и MRR, ну вы поняли:)

Но пост-то не про это😜

Обычно когда мы в найме, мы работаем за зарплату. Зарплата может быть gross/net, за месяц/за год. Но ключевое слово зарплата, где мы ощущаем себя наемными (то есть легко заменимыми) рабочими, которых хотят заменить то ли AI, то ли дешевой рабочей силой из Индии (применимо для западного мира). Вот и живем в такой парадигме найма, часто мучаемся от burnout, mental health pressure, панические атаки из-за риска потерять работу и далее по списку психологических расстройств modern workforce, то есть нас.

А что если, поменять парадигму? Мы работаем не за зарплату, а у нас бизнес, и наша зарплата, которую нам платит работодатель клиент это на самом деле ARR, вы у нас (или нас самих) купили по подписки, чтобы мы делали работу, то есть нам нужно считать ARR (это gross доход). Тогда и клиентов и доходов может быть больше одного (ваши side проектики, консультации и тп).

В таком случае вы не будете ныть, что у вас плохой performance review или вам не подняли зп, вы думаете в контексте клиентского опыта, где доход зависит от качества оказываемых вами услуг. Причем, услуг не технических (с hard skills обычно не бывает проблем), а услуг связанных с soft skills.

Тогда риск burnout и других ментальных расстройств сокращается, доход возрастает (ребята в Surfalytics не дадут соврать), job security как таковой уже не главная проблема, если человек все время учится и в режиме grow mindset и вместо утренней зарядки идет на собеседование (на всякий случай). С таким подходом качество работы возрастает, ведь если инженер или аналитик думают о своих проектах на работе как о личных проект, думают о “клиентском опыте” работодателя и своего менеджера, то все действия будут направлены на повышения этих метрик, что в конечном итоге приводит к повышения ARR.

Я больше не использую слово зарплата, мне важен мой ARR и факторы которые на него влияют.

Читать полностью…

Инжиниринг Данных

В свежей статье Cursor makes developers less effective автор затронул важную для разработчиков тему - помогает ли AI IDE делать работу быстрей?

Его пост написано основе исследования - Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, в котором приняло 16 разработчиков. Разработчики решали 136 реальных задач. Им платили по 150$ в час за участие в эксперименте.



Что же интересного в исследовании?

📊 Главный результат: AI замедляет, вопреки ожиданиям
- Разработчики с AI-инструментами выполняли задачи на 19% дольше, чем те, кто работал без AI.
- При этом они ожидали ускорения на 24%, и даже после замедления считали, что ускорились на 20%.
- Это говорит о серьёзном разрыве между субъективным восприятием и объективной реальностью.


🧠 Почему AI-инструменты замедляют? Анализ от экспертов
Simon Willison:

У AI-инструментов высокий порог обучения. Пока разработчики встраивают их в свой процесс, производительность падает.


Quentin Anthony (PhD, участник исследования):
AI не ускоряет всех одинаково. Важнее не уровень навыков, а умение избежать ошибок в работе с AI.

LLM работают хорошо только на определённых типах задач. Например, плохо справляются с низкоуровневым системным кодом.

AI вызывает потери фокуса. Пока AI генерирует, легко отвлечься, например, на соцсети. Эти “30 секунд” превращаются в 30 минут.


🧠 Влияние переключения контекста и “выпадения из потока”
- Высокопродуктивная работа часто возникает в состоянии “потока”, когда разработчик полностью сосредоточен.
- AI может мешать этому состоянию, так как требует:
- постоянных ожиданий,
- промежуточной оценки предложений,
- частого переключения внимания.
- Эти контекстные переключения могут нивелировать любую экономию времени от генерации кода.


Я лично уже являюсь клиентом Cursor несколько месяцев, типовые задачи:
- Terraform, Terragrunt
- YAML файлы
- dbt модели
- Python
- Prot0buf
- Node.js
- идеи проектов для Surfalytics
- и тп

То есть все задачи уже работает в контексте готового решения, репозитория. То есть в роли contributor.

В Surfalytics сообществе пользователи разделились на три группы:
- Cursor
- VS Code + Claude Code
- бесплатные инструменты (free tier)

Согласно наши многочисленным собеседования никто пока не спрашивает и не требует знания AI или использования AI инструментов. Мне лично очень нравится работать с Cursor, даже если он иногда дает не правильный ответ, то это все равно удобней, чем гуглить или читать документацию🤪. И как говорят, общения с AI помогает войти в “поток”, главное начать.

А недавно я установил cursor старшему сыну (13 лет), показал как работает. Он довольно быстро насоздавали больше 1000 строк рабочего кода для Roblox Studio. Сразу видно, что мозг у нового поколения работает по другому и при правильном использовании AI возможности у них безграничные.

Параллельно с Cursor он изучает книгу Think Python и запускает код только в командной строке. А младший (8 лет) пока ковыряется в Music Lab от code.org. Вообще я хочу, чтобы они работали как команда и вместе строили проект, но пока трудно их вместе сорганизовать.

Читать полностью…

Инжиниринг Данных

Бесплатный курс по PostgreSQL от практиков рынка

Присоединяйтесь к бесплатному курсу по основам PostgreSQL от Selectel и Эльбрус Буткемп. Он будет полезен Junior- и Middle-специалистам: администраторам баз данных, разработчикам, DevOps-инженерам и аналитикам.
 
Вы научитесь:
🔹создавать и связывать таблицы,
🔹выполнять базовые операции с данными,
🔹работать с РСУБД.

Бонусы: вы можете получить сертификат о прохождении курса, а также промокоды для практики на мощностях Selectel.

Начните обучение уже сегодня.

Реклама. АО «Селектел», ИНН 7810962785, ERID: 2VtzqwWX4Pi

Читать полностью…

Инжиниринг Данных

В статье The Inconvenient Truths of Self-Service Analytics автор (Seattle DataGuy), рассуждает про Self-Service. Тот самый, которые еще появился во времена взрывного роста Tableau, Power BI и других вендоров, которые обещали самостоятельную аналитику для бизнес пользователей или как обычно бывают лили в уши клиентам, про их замечательные продукты, упуская из вида действительно важные составляющие такой аналитики.

Основные тезисы статьи:

Сформулируйте бизнес‑вопрос до создания
Не начинайте с данных и дашбордов. Сначала определите, для каких решений нужна аналитика. Без конкретной цели создаются многочисленные отчёты, которые никто не использует

Создайте управляемые и качественные потоки данных
Даже самый красивый дашборд бесполезен, если данные нельзя доверять. Необходимо обеспечить стандартизацию метрик, чёткие определения и автоматический контроль качества данных

Дизайн решений под конкретные роли
Разные роли (руководители, операционные команды) нуждаются в разных форматах аналитических данных. Универсальные дашборды часто не эффективны — нужен индивидуальный подход

Внедрение и обучение — это обязательная часть решения
Даже самый продуманный инструмент аналитики требует обучения пользователей и комфортного процесса внедрения. Без этого дашборды останутся невостребованными

Контекст отрасли важнее общего инструментария
Общие бизнес‑метрики могут не отражать конкретных реалий вашего бизнеса. Отраслевой контекст, особенности и знание процесса намного важнее красивых визуализаций

Иногда стоит привлечь внешних экспертов
Консультанты могут ускорить создание аналитической платформы — они обладают опытом и шаблонами, которые можно адаптировать под ваш бизнес, а затем передать команде

Переосмыслить "self‑service" — сделать это "action‑service"
Дашборд — лишь средство, а не цель. Настоящая ценность аналитики в том, чтобы она приводила к действиям: рекомендовать следующий шаг, автоматически реагировать на тренды и т.п.


То есть получается, что ни один вендор вам не сделает правильную self-аналитику. Это больше про настройку процессов, мониторинг качества данных, адаптацию пользователей через обучение и онбординг, принятие правильных и эффективных бизнес решений.

Вообще вендоры они такие, им бы лишь бы впарить свой продукт, и их маркетинговый отдел, который, как правило не сильно понимает разницу между BI и DW, готов на все, лишь бы привлечь ваше внимание💰 А иногда бывают, что и руководители в погоне за модными вендорами, готовы устроить очередную миграцию или внедрение shiny tech, лишь бы не заниматься действительно важной и полезной работой.

Читать полностью…

Инжиниринг Данных

Сегодня я поймал себя на мысли, что через неделю начинается новый проект в новом стартапе, с кем я общался где-то месяц назад, но я не могу вспомнить их название.

Что это - Опыт? Старость? Пофигизм? 🦯 Наверно просто каникулы и work life balance, а не эти вот ваши 996🗽

Читать полностью…

Инжиниринг Данных

Вот были времена, когда люди делали code review и могли проявлять чудеса смекалки, а теперь все бездушный AI.

Читать полностью…

Инжиниринг Данных

Для всех кто делает курсы - пример отличного pivot, как залететь в топ и создавать учебный контент, собирать лайки и просмотры😃

Читать полностью…

Инжиниринг Данных

⚡Гендиректор GitHub Томас Думке уходит, чтобы вернуться к работе над стартапами.

- Microsoft не будет назначать нового CEO и полностью интегрирует GitHub в свою AI-команду CoreAI.

- Теперь GitHub станет ещё теснее связан с развитием инструментов на базе искусственного интеллекта, таких как Copilot.

https://www.theverge.com/news/757461/microsoft-github-thomas-dohmke-resignation-coreai-team-transition

https://news.ycombinator.com/item?id=44865560

Читать полностью…

Инжиниринг Данных

MWS Cloud запустила платформу для внедрения и работы ИИ, выйдя на рынок объемом более 15 млрд рублей.

Платформа Inference Valve помогает вывести в продакшн обученные ML-модели, большие языковые модели и модели компьютерного зрения. С помощью платформы их можно разворачивать на инфраструктуре, подключать к ИТ-системам компаний через стандартные API, масштабировать, а также обновлять и мониторить.

После запуска кластера специалисты заказчика загружают артефакты модели (например, ONNX, TorchScript) в платформу, после чего она автоматически формирует контейнер сервиса и публикует эндпоинт. Платформа поддерживает одновременную работу сразу с несколькими моделями с выделением квот вычислительных ресурсов, управление версиями, маршрутизацию трафика между версиями и масштабирование под нагрузку как на GPU, так и на CPU.

Inference Valve также предоставляет метрики задержек и пропускной способности, мониторинг доступности, алёрты и дашборды; доступна телеметрия качества, включая отслеживание дрейфа данных и моделей, контроль целевых метрик и уведомления при деградации. Интеграция с системами наблюдаемости (Prometheus/Grafana) и журналированием запросов упрощает аудит и разбор инцидентов.


По словам CEO MWS Cloud, исполнительного директора МТС Web Services Игоря Зарубинского, платформа позволяет:

- В десятки раз быстрее интегрировать LLM и CV-модели с ИТ-системами компаний;

- На 70% снизить операционную нагрузку на ML-команды при эксплуатации моделей;

- Повысить автоматизацию CI/CD более чем на треть;

- Уменьшить затраты на GPU более чем на 15%;

Читать полностью…

Инжиниринг Данных

Тут не только LinkedIn, даже все телеграмм каналы про ИТ👀

Читать полностью…

Инжиниринг Данных

Data Observability относится к data engineering, и является его неотъемлемой частью, согласно best practices, конечно.

У меня давно в закладках лежит статья - SLA vs SLO.

В больших компаниях мы часто можем слышать про SLA и SLO, и даже SLI. Очень часто их путают. Поэтому статья помогает понять, что для чего и как использовать.

📌 Зачем вообще всё это нужно?
SLA, SLO и SLI — это инструменты управления надёжностью сервисов. Они помогают установить понятные и измеримые ожидания между теми, кто предоставляет сервис (разработчики, команды, компании), и теми, кто его использует (внутренние или внешние клиенты).


💡 Основные термины:
SLI (Service Level Indicator) — Показатель уровня сервиса: метрика, которая показывает, насколько хорошо работает сервис с точки зрения пользователя (например, доступность, время отклика, процент ошибок).

SLO (Service Level Objective) — Целевой уровень сервиса: цель по метрике (например, “доступность 99.9% за 30 дней”). Если сервис ниже цели — это тревожный сигнал, может остановиться деплой, пойдут расследования.

SLA (Service Level Agreement) — Юридическое соглашение об уровне сервиса: официальный контракт, в котором закреплены SLO и последствия их невыполнения (штрафы, компенсации). Обычно используется во внешних отношениях с клиентами.

🤝 Зачем это нужно:
Командам — чтобы знать, когда сервис работает плохо и нести ответственность.
Бизнесу — чтобы договариваться с клиентами на чётких условиях.
Пользователям — чтобы понимать, на что можно рассчитывать (и требовать компенсацию при сбоях).

🧭 Простая аналогия:
SLI — это стрелка на спидометре.
SLO — это знак "не ехать быстрее 100 км/ч".
SLA — это штраф за превышение.


Практически на всех проектах по инжинирингу данных обсуждается тема мониторинга, но очень редко мы действительно устанавливаем метрики, ведь в большинстве случаев аналитика и хранилище данных это не business critical приложение, и если что-то сломалось, то мы можем починить в течения дня. Хотя было бы неплохо установить SLO для бизнеса, что хранилище данных и отчетность будет доступна 99% в течение рабочего времени. И даже если это не соответствует действительности, мы можем установить начальную точку и двигаться в сторону улучшения. Как правило у нас SLA не будет, да и SLI тоже не обязателен.

А есть совсем другой пример, когда компания продает данные американских клиентов (их обезличенные гео данные на млн долларов) в другую компанию, которая находится за пределами США. Эта компания, использует данные для классической аналитики трафика людей в разных городах. Так как компания платит большие деньги они установили SLO и SLA. И в случае сбоев выставляют штрафы. Из недостатков такого проекта для дата инженеров - on-call.

SLI (Service Level Indicators) — метрики, которые мы измеряем:
unique_user_count - Кол-во уникальных пользователей в часовой выгрузке
event_volume_total - Общее кол-во событий в часовой выгрузке

SLO (Service Level Objectives) — цели по этим метрикам
unique_user_count - > 90% от среднего значения за 4 недели
event_volume_total - > 90% от среднего значения за 4 недели
data_delivery_lag_minutes - < 10 минут задержки 99% времени
data_integrity_flag - 100% данных доставлены без ошибок 98% времени

SLA (Service Level Agreement) — договор с клиентом, в котором
- Фиксируете SLO (например, 98% своевременных поставок в течение месяца)
- Описываете последствия (например, штрафы, перерасчет, SLA-кредит)
- Уточняете исключения (форс-мажор, проблемы на стороне клиента)
- Описываете процесс эскалации и ответственности

Пример SLA-формулировки:
Мы гарантируем доставку данных каждый час в течение 10 минут после окончания часа. Минимально допустимый объем — не менее 90% от среднего за предыдущие 4 недели. Если в течение календарного месяца нарушены более 2 SLA-интервала, предоставляется SLA-кредит 10% от месячного счета.

Цифры SLA у нас в договоре другие, метрики такие как я указал.

Читать полностью…

Инжиниринг Данных

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

В посте товарищ указал на некоторые из проблем, с которыми он столкнулся:

Я работаю с технологией Snowflake уже 7 лет, и вот вещи, с которыми большинство внедрений Snowflake сталкиваются и с большим трудом справляются.
- Role-based access control — Очень легко создать полный хаос, после чего команда DBA оказывается навечно занята решением проблем с доступами.
- Virtual Warehouse deployment — В итоге у вас появляется сотни VW, и расходы стремительно выходят из-под контроля.
- Data Clustering — Они не работают как индексы и часто приводят к огромным затратам без какого-либо прироста производительности.
- Migrating to Snowflake — На первый взгляд кажется, что это намного проще, чем миграция на Oracle (или с него), но затем вы понимаете, что Snowflake сильно отличается — а миграции баз данных вообще всегда болезненны.
- Performance vs. Cost — В Oracle или SQL Server вы раньше просто тюнили производительность. В Snowflake же у вас три конкурирующие задачи:
- (a) Performance — как можно быстрее выполнять пользовательские запросы
- (b) Throughput — обрабатывать огромные объёмы данных, т.е. буква T в ELT
- (c) Cost — о которой вы даже не задумываетесь, пока менеджеры не начнут жаловаться, что система обходится в миллионы долларов в год.

Про RBAC полностью соглашусь, я использовал и Terraform, и permifrost, но в больших конторах всегда все выходило из под контроля и любые изменения занимают время + ограничения каждого из подходов.

Цена у Snowflake всегда боль. А с тюнингом не заморачиваются, просто увеличивают размер VW или кластера.

Альтернативы всегда есть, но как всегда в ИТ это tradeoff.

Какая мораль истории? Во всех аналитических проектах, даже если там не Snowflake, всегда важна безопасность, цена и производительность. Именно на этом и нужно акцентировать внимание при работе и собеседованиях.

Читать полностью…

Инжиниринг Данных

Как любил говорить мой любимый учитель английского в лицее №1501: «Когда одним хорошо, другим дурно».
Когда читаешь истории о людях, которых увольняют из-за ерунды, становится грустно. Если бы я сам всегда был честен, не уверен, что смог бы перейти с завода ГКНПЦ им. Хруничева в Cetelem (BNP Paribas). К сожалению, у меня не было ментора, который мог бы подсказать, что учить, что говорить. Первые три месяца я вообще работал бесплатно.

В индустрии всё давно уже самоорганизовалось. У компаний попроще — маленький бюджет, невысокие требования: туда проще попасть без большого опыта, подтянуть знания и идти дальше. Топовые компании платят лучше, у них строже отбор и более сложные задачи — туда уже нужны сильные скиллы.

А теперь представим: вы захотели работать в ИТ, но у вас нет профильного образования и опыта. Что делать? Заплатить 150–250 тысяч за псевдокурсы с обещаниями трудоустройства? Или смириться и пойти в курьеры?

Лучшее, что можно сделать — найти эксперта, ментора, который подскажет, как достичь желаемого. Он объяснит, что делать, чтобы не тратить деньги впустую. Окей, допустим, человек приукрасил опыт. А что, если реального опыта нет, но человек соображает, задачи решает, хочет развиваться, учиться и зарабатывать? Так не мешайте ему. Если работает плохо — расстаньтесь. Но не нужно из мухи делать слона.

Из подобных историй видно: процессы найма кривые, а некоторые менеджеры — самовлюблённые, без реальных заслуг, с посредственной жизнью. Такие пытаются самоутвердиться за счёт подчинённых. «Максимов» и «Глебов» хватает везде — и не только в отечественных компаниях. Обижаться на них не стоит — скорее всего, у них в жизни всё непросто и нечем гордиться.

Я не знаю ни одного действительно успешного человека, который бы занимался подобной ерундой вместо того, чтобы хорошо делать свою работу и приносить пользу.

Сообщества вроде «ОМ» и «Волки» лишь один из множество путей попасть в ИТ, причем как мы видим, довольно успешный. Сообщество решает классическую проблему отсутствия опыта, просто делают это немного эпатажно. Примерно тем же занимается Datalearn, Surfalytics. Все, кто пробился с их помощью — крутые ребята, которые действительно умеют работать.

А если кандидат слабый, не хочет и не умеет работать — это зона ответственности HR и Hiring Manager: либо отсеять, либо платить достойно, вовремя повышать, чтобы не было желания «убегать налево».

Читать полностью…

Инжиниринг Данных

В больших корпорациях есть методология выявления сотрудников с высоким потенциалом. Некоторые изобретают свою, некоторые по ощущениям, а кто-то берет готовый фреймворк, как например в статье The Ultimate Guide to High‑Potential Identification

В статье рассказывают про HiPo сотрудников (high‑potential) - это сотрудники с высоким интеллектом, стремлением к росту, гибкостью и лидерской направленностью, способные эффективно справляться с более сложными ролями в будущем.


При оценке сотрудников учитываются такие признаки:
- Стратегическое мышление
- Стремление к совершенству
- Обучаемость и адаптивность
- Умение принимать решения
- Проактивность и инициатива
- Ориентация на руководящие роли
- Построение отношений и управление заинтересованными сторонами
- Комфорт при работе в условиях неопределённости или изменений

Популярные инструменты для оценки HiPo:
- Assessment & Development Centers (ACDC) - виртуальные, традиционные или смешанные центры оценки с ролеплеями, симуляциями, интервью, тестами
- 360‑градусная обратная связь - отзывы от самих сотрудников, коллег, подчинённых и клиентов как инструмент анализа потенциала
- Assessment‑тесты - краткие стандартизованные тесты на личность, когнитивные способности, обучаемость; подходят для больших групп и начальных уровней

К сожалению здесь большую роль играет человеческий фактор. Из инструментов я использовал 360-градусов обратную связь.

В целом самый лучший подход это сфокусироваться на high impact проектах и stakeholders, и постараться сделать для них все по высшему разряду, тогда и обратная связь будет нужная и легче будет показать ваш impact.

Читать полностью…

Инжиниринг Данных

Мы прилетели утром в Париж, чтобы посмотреть финал Tour de France. Шёл небольшой дождь, центр города был перекрыт, но это никого не смутило - все пришли поддержать спортсменов и почувствовать атмосферу великого события.

Вот несколько интересных фактов о Tour de France (я попросил chatgpt рассказать про основные идеи гонки):

🚴‍♂️ Что такое Tour de France?
Tour de France — это крупнейшая и самая престижная многодневная шоссейная велогонка в мире. Она проводится ежегодно во Франции (иногда частично затрагивая соседние страны) и собирает лучших велогонщиков планеты.

📆 Когда она началась?
Первая гонка прошла в 1903 году, её организовала газета L’Auto для повышения продаж. С тех пор она проводится почти каждый год, с перерывами лишь во время мировых войн.

⏱️ Сколько длится и когда проходит?
Tour de France длится около 3 недель, традиционно в июле. В 2025 году гонка стартовала 5 июля и завершилась 25 июля — финишом на Елисейских полях в Париже.

🏔️ Какие испытания входят в гонку?
Гонка состоит из нескольких этапов (обычно 21), включая:

Равнинные этапы — для спринтеров
Горные этапы — в Альпах и Пиренеях, для горняков
Индивидуальные гонки на время (тайм-триал)
Командные этапы
Гонщики соревнуются не только за общее время, но и в различных категориях.

💰 Сколько стоит велосипед?
Профессиональный шоссейный велосипед для Tour de France стоит в среднем от 10 000 до 15 000 евро, иногда и дороже. Главное условие — велосипед должен быть "стоковым", то есть доступным на коммерческом рынке (в рамках правил UCI), без секретных или запрещённых модификаций.

🏆 Как определяют победителя?
Победителем общего зачёта становится гонщик с наименьшим суммарным временем по итогам всех этапов. Помимо главного зачёта, есть и другие:

Очковый зачёт (зелёная майка) — для лучших спринтеров
Горный зачёт (в гороховую майку) — для лучших горняков
Молодёжный зачёт (белая майка) — лучший гонщик до 25 лет
Командный зачёт


🟡 Почему жёлтая майка?
Жёлтая майка (maillot jaune) — символ лидера общего зачёта. Цвет выбран в честь бумаги, на которой печаталась газета L’Auto — организатор первой гонки (бумага была жёлтой).

🥇 Кто победил в 2025 году?
Финальный этап Tour de France 2025 завершился 25 июля на Елисейских полях в Париже.
Победителем этапа стал Jasper Philipsen (Бельгия, Alpecin-Deceuninck) — один из лучших спринтеров современности.
Победителем общего зачёта стал Tadej Pogačar (Словения, UAE Team Emirates) — он выиграл Тур уже в третий раз (после побед в 2020 и 2021 годах).



Вот два хороших видео:
- Tour de France Explained For Newbies (тут как раз рассказывают про все, что выше)
- TOUR DE FRANCE 2025 – HISTORIC! Van Aert breaks Pogacar and triumphs on the Champs‑Élysées (про сегодняшний заезд)

Что еще рассказать? Есть интересный канал Михаила Иванова (одного из основателей издательства МИФ), он часто пишет про триатлон и велогонки, проводит велотуры в Европе и США и участвует в мировых триатлонах. Недавно он рассказал, что можно наслаждаться всей красотой горных поездок на элетро-велосипеде, реально game changer. Возможно в будущем я смогу поучаствовать в таком туре. Вообще хотелось бы взять саббатикл и просто несколько месяцев колесить по Европе без цели.
А еще Михаил много пишет про инвестиции и я у него покупал курс по инвестициям, который мне очень понравился, на котором мне простым языком рассказали какие инструменты существуют и как важно балансировать портфель.

Читать полностью…

Инжиниринг Данных

В сентябре Яндекс выпустит Нейроаналитика — ИИ-помощника, встроенного в DataLens.

Сервис поможет находить закономерности в данных, ускорять отчёты и проверку гипотез. Всё — через чат без кода и формул. Создан на базе Yandex Cloud AI Studio. Поддерживает облачную и локальную установку. Уже используется внутри Яндекса.

Сейчас можно уже оставить заявку в листе ожидания.

Реклама. ООО Яндекс.Облако. ИНН 7704458262

Читать полностью…

Инжиниринг Данных

Нужен ли TPM (Technical Product Manager или просто Product Manager) в дата-команде?

Главная задача такого человека - быть связующим звеном между бизнесом и инженерами/аналитиками. Раньше этим занимался бизнес-аналитик. Так было на проектах в Cetelem (BNP Paribas) и Сбербанке.

Для нас самая сложная часть работы - понять, чего хочет бизнес, как он зарабатывает деньги и как двигать метрики (добавлять ценность).

Задача TPM - всё это понимать и знать, что и когда нужно сделать, какие приоритеты и цели. Тогда инженеры и аналитики работают с максимальной эффективностью.

Конечно, многие команды обходятся без TPM, и, поскольку люди не глупые, они могут разобраться сами. Здесь начинается trade-off.

Кому-то больше нравится копаться в технических деталях, писать код. Для них все эти встречи со стейкхолдерами (бизнес-заказчиками) ни к чему. А кому-то же наоборот - легче ходить на митинги и обсуждать задачи.

Лично я вижу много пользы в TPM, который в курсе бизнес-контекста, текущих инициатив и фич. Он очень быстро может сказать, что нужно делать, а что - нет. И самое главное: когда он получает от дата‑команды результат, он будет безмерно рад и благодарен, и уж точно знает, как это конвертировать в epic story про достижения команды.

Но есть нюанс: TPM/PM должен быть очень вовлечён в работу. В какой-то степени он может быть «душным» для всех, зато точно знает, что нужно сделать, на каком этапе тот или иной проект и где затык. Он не будет зацикливаться на оформлении Pull Request или неправильном названии таблицы. Ему нужен результат - именно тот результат, за которые можно обоснованно просить повышение.

Поэтому я видел, как многие TPM/PM попадали под сокращение. Как правило, их «срубают» первыми. И тогда вся нагрузка ложится на технических лидов, линейных менеджеров, а может и на самих разработчиков. Это в принципе не страшно, но создаёт дополнительную нагрузку без какого‑либо стимула.

Для меня работать с product managers всегда жирный плюс. Я фокусируюсь на том, в чем я эксперт, они фокусирует на том, в чем они эксперты. Вот такой diversity я люблю.

А какое у вас отношение к TPM/PM в дата-командах?

Читать полностью…

Инжиниринг Данных

В приложение документ - Winning the Race: America’s AI Action Plan

Это 28‑страничная стратегия, представленная администрацией Дональда Трампа 23 июля 2025 г., определяющая ключевые шаги для укрепления лидерства США в сфере искусственного интеллекта. Он был опубликован одновременно с серией указов (Executive Order 14179 от 23 января 2025 г.), направленных на отмену ограничений предыдущих администраций и ускорение внедрения ИИ 

Автор и инициатор: Белый дом при участии — «потомственных» ИИ‑менеджеров, включая так называемых «ИИ и крипто‑царей», в первую очередь тех, кого назначил Трамп, например Давид Сакс (частый гость All In подкаста)


Основные акценты плана
Ускорение инноваций
— снятие регуляторных ограничений, поддержка стартапов и крупных компаний, стимулирование работы над ИИ‑моделями без «идеологического уклона»
.

Развитие инфраструктуры
— ускоренная постройка дата‑центров и полупроводниковых фабрик; снижены экологические барьеры и упрощены разрешительные процедуры.

Глобальное превосходство
— продвижение американской технологии за рубеж, борьба с китайским ИИ посредством дипломатии, экспортных инициатив и инвестиционных стимулов
.

Сейчас реально происходит AI гонка и США хочет взять лидерство. Интересно, что делает РФ?

Читать полностью…
Subscribe to a channel