Бустим data-проекты с ИИ — бесплатно до 31 октября! 🚀

До 31 октября Cloud․ru открывает бесплатный доступ к топовым AI и LLM-моделям для работы с данными в Evolution Foundation Models.

В сервисе уже доступно больше 20 моделей: reasoning-модели gpt-oss-120b и DeepSeek-R1, эмбеддеры Qwen Embeddings и bge-m3, кодовые модели Qwen3-Coder-480B и GLM-4.5 и другие мощные решения 🧠

Что умеют модели

➡️ Structured Outputs — автогенерация отчетов из сырых данных
➡️ Function Calling — интеграция с вашими аналитическими API
➡️ Reasoning — глубокий анализ и инсайты из сложных датасетов
➡️ Embeddings & Reranking — семантический поиск по корпоративным данным

Как это ускорит вашу работу

1️⃣

Регистрируйтесь в личном кабинете Cloud․ru

2️⃣

Выбирайте модели под ваши ML-задачи

3️⃣

Подключайте через OpenAI-совместимый API к своим data pipeline

4️⃣

Автоматизируйте EDA, генерацию отчетов и интерпретацию результатов

Модели развернуты на российских серверах — ваши данные под защитой🔒

А если зарегистрируетесь как юрлицо, получите 20 000 бонусов на расширенные возможности.

Попробовать бесплатно🖱

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

В западных компаниях есть термин - Mutual Separation Agreement, то есть обоюдное разделение.

Вот работаете вы в компании и понимаете, вроде все ок, но что-то не то.

Что делать?

Любители обычно начинают искать работу или того хуже, сразу увольняются, отработав последние 2 недели.

А как делают профессионалы? Узнают, есть ли у них в компании MSA, пишут письмо боссу и HR, что так и так, вроде все хорошо, но немного не по пути, давайте договоримся по хорошему - мне 2-6 зарплат, а у вас будет отличная возможность найти хорошего человека.

Такое может получится, если вы работает в компании 1,5-2 года как минимум. Очевидно, если меньше года, ловить нечего, лучше тогда по PIP разойтись:)

Вы знали про такой подход MSA?

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

Так уж исторически сложилось, что я собеседую всех кандидатов на руководящие позиции в свой ИТ-департамент в Ситидрайв. Это небольшая встреча-знакомство на 30–40 минут, на которой я составляю второе мнение о кандидате и передаю его нанимающему менеджеру для оценки рисков. Сейчас у нас открыто несколько таких позиций, поэтому за последние несколько недель у меня было достаточно встреч, чтобы заметить одну тенденцию у некоторых кандидатов.

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

И вот третий такой кандидат и побудил меня написать эту заметку. Он — крепкий технарь, но точно не руководитель. И я ему задаю вопрос: «Слушай, а если вместо руководящей позиции мы тебе предложим инженерную, ты согласишься?». Тут он сразу приободрился, одобрительно начал кивать головой и подчеркнул: «Это будет даже лучше!». Я ему начал объяснять, что в этом случае мы будем оценивать его как инженера, и есть немаленькая вероятность, что именно столько, сколько он хочет, мы предложить не сможем, и спросил – готов ли он двигаться по своим ожиданиям. Тут я получил категоричный отказ, мол, он уже привык к такому уровню заработка и меньше получать никак не хочет.

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

И таких историй масса, и они случаются на разных уровнях. И чем выше — тем страшнее. В другой компании руководителем разработки сделали бывшего разработчика, который дольше всех работал в компании. И вот его пять команд в 30 человек жили своей жизнью, а он жил своей — писал сложные алгоритмы и решал инциденты в сервисах, о которых знал только он 🫠

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

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

Я в своих наблюдениях не одинок — всё, о чём я тут пишу, было подмечено канадским исследователем Лоуренсом Дж. Питером ещё в 1969 году в книге «The Peter Principle: Why Things Always Go Wrong».

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

Что делать, шеф?

❗️Перестать делать то же самое, что ты делал до этого, и рассчитывать на то, что этого достаточно или что это именно то, что от тебя ожидают. Воспринимай новую должность как новую профессию и начинай учиться.

И если ты понимаешь, что это не твоё — не страшно сделать шаг назад, чтобы потом сделать два шага вперёд 😎

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

Помните классику?

Ученый на интервью: «Все мои суждения бессмысленны, если они вырваны из контекста». Заголовок в газете на следующий день: «Знаменитый ученый признался, что все его суждения бессмысленны!»

Вот буквально это проделали журналисты и эксперты с недавним отчетом MIT о «полном провале ИИ-инициатив в корпорациях». Велик шанс, что вам на днях попадались заголовки про «всего 5% ИИ-инициатив успешны» и «ИИ провален в 95% случаев». Внимательно прочитать 26 страниц текста с картинками, похоже, мало кто смог.
Поэтому порадовала редкая статья, где автор с некоторым недоумением замечает, что отчет-то совсем о другом — если его прочитать. Он о том, что сотрудники массово и добровольно используют публично доступный ИИ в своей повседневной работе (и не пользуются корпоративными решениями в силу их очевидно более низкого качества).
a closer reading tells a starkly different story — one of unprecedented grassroots technology adoption that has quietly revolutionized work while corporate initiatives stumble. Это не проблемы ИИ, а полная некомпетентность руководителей, поэтому — уникальный случай! — происходит «революция снизу»: researchers found that 90% of employees regularly use personal AI tools for work. И вот про эти 90% не написал никто. Поразительно, но сформировалась «теневая экономика ИИ», не попадающая в корпоративные отчеты: Far from showing AI failure, the shadow economy reveals massive productivity gains that don’t appear in corporate metrics.
Почитайте материал по ссылке, если уж не сам отчет, там много интересных примеров:)
https://venturebeat.com/ai/mit-report-misunderstood-shadow-ai-economy-booms-while-headlines-cry-failure/

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

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

Нашли занятный материал на Хабе о том, как визуализация с помощью SHAP (от summary_plot до PDP и ICE) помогает не просто анализировать, а понимать, какие фичи реально влияют на отток клиентов. Эксперт ВТБ Андрей Бояренков делится эффективными приёмами: от выбора признаков до цветовой кодировки и примеров кода.

Это тот случай, когда объяснимый ML = сильное резюме и больше доверия к вашей модели.

👉 Читайте разбор с примерами и лайфхаками: https://habr.com/ru/companies/vtb/articles/938988/

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

Data Engineer в мою команду в Лондоне!

Начал искать инженера данных в свою команду в Лондоне.
Уровень ближе к Senior. Предпочтительно в Лондоне.
У нас нестандартый open-source стeк: /channel/topdatalab/426

Ссылка на вакансию: https://newfts.bamboohr.com/careers/180?source=aWQ9MTE%3D

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

Признавайтесь у кого сколько мониторов))

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

В статье 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 у нас в договоре другие, метрики такие как я указал.

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

Если вдруг забыли или не знаете про Big O

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

В посте, товарищ рассказал, как они круто выкинули Табло Север и стали использовать Slack бота + GenAI, чтобы отвечать на вопросы пользователей. Само собой разумеется, что они пофиксили семантический слой, определили метрики, позаботились о качестве данных.

Как результат пользователи пишут вопрос в Slack, и LLM возвращает им ответ. Такая функциональность доступна уже из коробки в Snowflake (Semantic Layer). Вам просто нужно описать вашу модель данных в YML, и все.

Навести порядок в данных это обычно самое сложное. Часто не выполнимая задача, потому что разработчики ленивые, и часто у них нет достаточно мотивации держать стерильную чистоту в хранилище/озере данных. А GenAI не понимают бизнес контекста и аббревиатуры и naming conventions.

В целом тренд очевидный, сам BI можно уже отдавать на outsource GenAI приложению.

Ребята из команды VILKY (кстати дашборд на Tableau Public) недавно показали отличный пример, как они задали вопрос и LLM написала SQL и провела небольшой анализ. То есть концепт работает, если данные хорошо организованы под такую задачу.

Но тут возникает интересный вопрос. Сейчас я приведу пример, который немного добавит контекста.

В моей любимой книге Angel: How to Invest in Technology Startups, автор упоминает инвестицию в проект Cafe X — "кафе, где кофе варят роботы, конкурирующее со Starbucks, и создающее возможность продавать кофе дешевле за счёт автоматизации”.

Главная идея, ваше кофе должно стоить не 5-6$ (сейчас оно так стоит), а на 50% дешевле.

Вот буквально на днях в Сиэтле мне попалась кафе с кофе, где его делают роботы. Больше похоже на самоделкиных.

Делают сносно, но цена при этом такая же как и в обычном кафе, где работает бариста.

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

Но самое важное проблема в этом, пока еще сам человек, которому комфортней сходить к человеку баристе, потому что он всегда так делал.

То есть во многих случаях, человек хочет общаться с человеком, а не с бездушной машиной. Компания Klarna уже обожглась.

Так же и с BI, с одной стороны, мы можешь сделать insights on demand, через LLM, а с другой стороны, я еще не знаю ни одной компании, которая не использует хоть какой-то BI инструмент, потому что пользователям так комфортно, и пока большинство не хочет менять привычки. Уверен, скоро кто-нибудь большой выпендрится, какие они молодцы - BI-AI first, раньше всех.

Но все движется к тому, что большие BI вендоры находятся в конкуренции с LLM и даже, если они добавят новые фичи, это им не поможет.

А как вы думает про кейс BI+LLM или LLM вместо BI в средней перспективе?

Мне видится, что для executive dashboards будет классический BI, а вот для self-services и deep dives скоро будут больше полагаться на GenAI. Опят же не заменяя человека, а дополняя, где человеку нужно будет валидировать гипотезы и инсайты.

Представляете, приходите на работу и после ночного ETL 20 новых гипотез и инсайтов, нужно выбрать только 1-2 из них.

Кто-то скажет, что и человек не нужен будет…вот и узнаем скоро:)

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

Отличный урок про Claude code https://www.youtube.com/watch?v=6eBSHbLKuN0

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

Американские рынки падают и Financial Times заявляет, что Уолл-стрит напугал отчёт из именитого MIT. Согласно ему, на внедрение искусственного интеллекта бизнес в США потратил около 40 миллиардов долларов, однако лишь 5% компаний смогли интегрировать ИИ в свои производственные процессы и зафиксировать увеличение прибыльности. 95% организаций не получают никакой отдачи («are getting zero return»). Галя, у нас отмена!

https://www.ft.com/content/33914f25-093c-4069-bb16-8626cfc15a51

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

Все выступления конференции MCP Dev Days (29–30 июля 2025 г.) теперь доступны онлайн в свободном доступе.
👉 Полный плейлист MCP Dev Days на YouTube

День 1 — DevTools и Сообщество
- Ключевая сессия: «Строим будущее AI-разработки вместе» — спикеры Jay Parikh (EVP Core AI, Microsoft), James Montemagno, Linda Li, Drew Hodun, Burke Holland и Donald Thompson.
- MCP Power-User Mode: обзор всех возможностей MCP в VS Code (демо от Liam Hampton).
- Discoverability Unlocked: публикация и поиск MCP-серверов в Community Registry (Toby Padilla, Tadas Antanavicius).
- Chat with the Web: проект NLWeb о диалоговом взаимодействии с интернетом (Ramanathan Guha, Jennifer Marsman, Chelsea Carter, James …).

День 2 — Построение серверов и безопасность
- Использование MCP в продакшене
- MCP с AI-агентами
- Безопасность и практики защиты
- Инструменты поддержки экосистемы

В канале уже много раз обсуждался MCP, один из новых трендов в AI, который важно знать и понимать для инженеров и руководителей. Я пока только использую MCP для подключения к базе данных (Snowflake), чтобы было легче в Cursor получать контекст для генерации кода (Terraform, dbt SQL/YML, Python).

В Surfalytics у нас появился специальный канал dev-boost-with-ai, в которым мы делимся подходами к работе с AI и материалами. Пользователи разделились на Cursor и Claude Code.

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

🎮 Как насчёт начать кодить с нуля?

«Школа 21» от Сбера — это бесплатная школа цифровых технологий. Здесь ты соберёшь портфолио и получишь востребованную профессию в ИТ

Всё это — совершенно бесплатно. Без лекций, преподавателей и ограничений. Только практика и нетворкинг.

📌 Что еще?
— кампусы, которые работают 24/7 в Москве, Уфе, Казани, Новосибирске, Белгороде, Липецке, Нижнем Новгороде и других городах России.
— возможность совмещать с работой или учебой в вузе.
— сюда поступают независимо от образования: 50% участников пришли без опыта в ИТ.
— гарантированная стажировка в ИТ-компании.
— востребованные профессии: разработчик, devops/sre-инженер, data scientist, qa-инженер, специалист по кибербезопасности, бизнес- и системный аналитик.

🎯 Не упускай возможность — подавай заявку прямо сейчас: https://21-school.ru/

Реклама. Заказчик АНО «Школа 21» ИНН 7736316133

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

На этой неделе буду в Денвере, Колорадо, а в выходные в Сиэтле. Можно как обычно на 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 здесь, чтобы всех нас заменить 🦯

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