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

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, всегда важна безопасность, цена и производительность. Именно на этом и нужно акцентировать внимание при работе и собеседованиях.

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

Само решение достаточно не сложное, данные все хранятся в 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.

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%;

Пример 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 может отличаться.

⚡Гендиректор 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

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

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 — миссия настолько важна, что разделить её с жизнью нельзя»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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