Big Data *

Команда VK Cloud перевела материал Netflix о двух подходах к автомасштабированию Apache Flink. Сначала компания разработала собственный автоскейлер, который анализировал внешние метрики кластера и эффективно экономил ресурсы на простых потоковых конвейерах. Но с ростом числа stateful-задач и сложных графов обработки этого стало недостаточно.

В статье — о том, чем автомасштабирование на уровне отдельных операторов отличается от масштабирования всего кластера, как Flink Autoscaler использует показатель True Processing Rate, зачем Netflix запускает отдельный Temporal workflow для каждой задачи и почему ради стабильности иногда выгоднее сознательно оставить запас вычислительных ресурсов.

Когда я начинал этот проект, казалось, что собрать данные по Dota 2 будет просто: есть Steam API, есть матчи, остаётся только сохранить их в базу и строить аналитику. На практике всё оказалось интереснее. У Steam есть endpoint для детальной информации о матче, но для новых матчей он давно возвращает ошибку. А Stratz даёт нужные игровые события, но ограничивает бесплатный ключ 15 тысячами запросов в сутки. Один матч, один запрос. В итоге вместо простого скрипта появился отдельный операционный слой: Steam находит матчи, Stratz отдаёт события, PostgreSQL хранит сущности и состояние загрузок, MongoDB хранит детальную историю игры. Очереди, обработка 429, ограничение бэклога, очистка старых данных.

Методы replaceUsing и replaceOn обеспечивают более удобный способ перезаписи, а каталог теперь проверяет каждую операцию, а не только фиксацию.

Выпуск Delta Lake 4.3 состоялся в июне 2026 года, и он основан на Apache Spark 4.1.0 и 4.0.1. Если прочитать примечания к выпуску от начала до конца, вы увидите длинный список изменений, охватывающих Delta Spark, ядро, UniForm, Sharing и Flink, который легко принять за релиз с исправлениями, дополненный описанием каталога обновлений.

Два момента заслуживают вашего внимания, и они находятся на противоположных концах стека. Первый — небольшой и сразу полезный: replaceUsingнаконец replaceOn-то API DataFrame получает возможность выборочной перезаписи, которая не является replaceWhere. Второй — структурный: теперь каждая операция с таблицей, управляемой каталогом, проходит через API Unity Catalog Delta , а не только фиксация изменений. В Delta 4.2 фиксации изменений были скоординированы с каталогом. В Delta 4.3 остальная часть интерфейса, загрузка таблиц, CREATE, CTAS, REPLACE, и запись метаданных, объединены в один проверенный путь.

В этой статье рассматривается версия 4.3 с точки зрения разработчика конвейера: какие изменения в коде вы вносите, какие изменения происходят под вашим контролем и что следует проверить перед обновлением. Приводятся примеры testing.defaultдля каталога и схемы, а также пример компании CH Enterprise. Ссылки на исходный код находятся внизу.

Когда много работаешь с ИТ‑проектами, быстро понимаешь, какие инструменты действительно экономят время команды. Я работаю аналитиком и архитектором систем в компании интеграторе, где а мы помогаем компаниям автоматизировать передачу данных из 1С в BI‑системы (системы аналитики). Проще говоря — настраиваем обмен между 1С и BI так, чтобы нужные данные автоматически поступали в контур аналитики и обновлялись по расписанию, без регулярной ручной загрузки.

Со временем мы заметили, что нашим заказчикам не хватает быстрого и удобного способа собирать витрины данных для BI — без сложного кода, с понятной логикой и простым обслуживанием. Да, есть конечно Apache AirFlow, есть DBT — но все это для технарей, для искущенных в Python и SQL.

И в какой‑то момент возникла мысль о своем ETL‑решении, но дружелюбном к нормальным бизнес‑пользователям. Так появился DVT — low‑code ETL‑сервис, который мы сначала развивали в собственных проектах, а теперь решили сделать общедоступным, выпустив его в Open Source. 

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

Часть 2 из 2. В первой части серии мы предсказали отказ насоса за 60 дней и выяснили, что годами чинили не то. Увидели, что материал встретил вашу живую реакцию, поэтому возвращаемся по горячим следам со второй частью. В этом материале, как и обещали, погружаемся в технику. Расскажем, что было под капотом, как решалась судьба насоса и с какими сложностями мы столкнулись.

Привет, Хабр!

Меня зовут Илья Петров, я руковожу продуктом Digital Q.Sensor BI в «Диасофт». За последний год я неоднократно слышал одну и ту же фразу от разных команд — и своих, и клиентских: «нам бы сюда буквально пару графиков». И каждый раз внутри у меня загорается тревожная лампочка, потому что я примерно знаю, чем это заканчивается.

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

В Lаmoda Tech мы внедряем машинное обучение и работаем с большими данными, чтобы сделать онлайн-шоппинг для миллионов пользователей комфортным, увлекательным и вдохновляющим. И делимся на митапах самыми интересными кейсами.

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

Привет, Хабр! На связи команда CVM (Customer Value Management) B2B из МТС — техлид Артём Каледин и ML-инженер Александр Швайко. 

Менеджер должен быстро разбираться, как строить обсуждение с техническим директором компании. Но даже если информация о продукте есть, иногда бывает сложно быстро найти нужные материалы и выбрать плюсы для конкретного клиента. Раньше коллеги готовились к встречам с помощью Telegram-бота, но недавно от бизнеса поступила задача: сократить время на подготовку и повысить качество рекомендаций и контента. 

В статье по мотивам доклада на Inside AI Meetup расскажем про архитектуру нашей системы и этапы работы, поделимся результатами и планами, а еще — как построили надежный RAG, который не галлюцинирует (ну, почти).

Всех приветствую! Меня зовут Андрей, я студент 4 курса факультета математики и компьютерных наук, автор телеграм-канала Andre | Data Science. Все мы знаем, что направление машинного обучения сейчас на огромном хайпе - практически из-под каждого камня говорят о разных методах и о том, что они способны решить практически любую задачу. Но гайдов, которые бы подробно разбирали работу конкретного метода - от обычной загрузки данных до математического обоснования принципа его работы и визуализации каждого шага, - катастрофически мало.

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

Чем отличается настоящий аналитический агент от генератора SQL, почему семантический слой важнее размера языковой модели и почему локальная LLM ещё не означает технологическую независимость?

В 2026 году AI‑ассистент или AI‑агент появился едва ли не у каждого российского BI‑вендора. Проблема в том, что одинаковая наклейка «AI» скрывает совершенно разные механизмы: где‑то это чат к данным, где‑то генератор SQL, где‑то помощник разработчика дашбордов, а где‑то — мультиагентная система с оркестратором, отдельными ролями и проверкой результата.

Сравнивать такие продукты по принципу «у кого есть агент» бессмысленно. Поэтому мы решили посмотреть, что именно умеет каждый из них, как устроена архитектура, насколько можно доверять ответам и где заканчивается реальный функционал и начинается маркетинг.

Как мы исследовали AI‑агентов

Привет! На связи Ольга Попова, ИИ-Евангелист Лаборатории искусственного интеллекта Департамента больших данных Россельхозбанка. В этом выпуске к своим размышлениям добавила комментарии коллег, которые работают с этими темами каждый день. Мне кажется, их взгляд изнутри полезнее любой теории. Поехали!

Размышления, вдохновленные статьей Марка Хау «Towards ‘augmented sociology’? A practice-oriented framework for using large language model-powered chatbots» (Hau, 2025)

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

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

Представь простую задачу: ты просишь агента пересказать содержимое сайта.
Не установить пакет.
Не запустить скачанный скрипт.
Не открыть подозрительное вложение.
Просто прочитать страницу и сделать краткое резюме. Через несколько шагов на твоей машине выполняется код атакующего, устанавливается соединение с управляющим сервером и для наглядности открывается калькулятор.

И самое интересное: агент не нарушал прямой запрет. Наоборот, в ключевой момент он поступил "безопасно" — отказался запускать неизвестный бинарный файл и написал собственный декодер на Python. Именно это решение и стало частью атаки.

Такую цепочку продемонстрировал исследователь безопасности Иоганн Ребергер на Claude Code с моделью Opus 5 в Auto Mode. В его небольших сериях тестов атака срабатывала в трёх или четырёх запусках из пяти. Это не означает, что "Claude взламывается с вероятностью 80%", но хорошо показывает более важную проблему: безопасный на вид отдельный шаг ничего не гарантирует, если вся цепочка строится в среде, которую контролирует атакующий.

Привет, бойцы, вы готовы победить перенос данных?

Есть задача: перенести данные из PostgreSQL в Kafka. Первая мысль: написать небольшой сервис.

Он будет выполнять SELECT, превращать строки в сообщения и отправлять их через Kafka Producer. На схеме все выглядит почти безобидно:

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

Разбираемся на живом ClickHouse, почему база не видит предагрегат, который для неё построили, какая форма запроса это лечит (одна и та же для ClickHouse, Snowflake и BigQuery) и почему в итоге вопрос не к базе, а к семантическому слою. Внутри — замер на миллиарде строк: 3 секунды против 37 миллисекунд, сравнение восьми баз и одно правило, которое стоит проверить в своём BI.

Привет! Это Степан Малькевич, руководитель группы рекомендаций ленты ВКонтакте (AI VK).

За прошедшие месяцы 2026 года время в ленте выросло на 11%. За этими цифрами — серия изменений, каждое из которых сделало свой вклад в рост метрик. Сейчас расскажу, что мы обновили и что из этого вышло.

Насос на НПЗ ломался каждые три месяца. Ремонтники меняли подшипники, но проблема возвращалась. Мы предложили не просто мониторить вибрацию, а найти скрытую причину в данных. Результат превзошел ожидания: 60 дней упреждения и неожиданный виновник поломки. Рассказываем, как это было и почему модель — это только 20% успеха.

Привет! Меня зовут Дмитрий Гаврилов, я руководитель центра компетенции аналитики в MWS. Моя команда внедряет ИИ-скиллы в работу дата-аналитиков. Мы посмотрели на типичный рабочий день и поняли: рутина съедает до 75% времени аналитика. А можно ли это передать ИИ-агенту без потери качества? Эту гипотезу проверили на реальных задачах и получили конкретные результаты — делюсь в этом материале.

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

Например, от Бетельгейзе свет идет около 600 лет, но в любой день сними ее спектр — линии на своих местах. А если взять объект за миллиарды световых лет от Земли, что покажут фотоны? Ученые говорят, на таком расстоянии длина волны света сильно растянута из‑за расширения пространства и линии смещены в красную зону спектра.

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

Допустим, у тебя есть несколько AI-агентов. Один разбирает тикет, второй меняет код, третий запускает тесты, четвёртый готовит релиз.

Задача закрыта, тесты зелёные, артефакт собран. Метрика success_rate показывает успех.

Можно праздновать?

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

Финальное состояние корректное. Процесс — нет.

Именно эту проблему пытается измерить CoCoBench — новый бенчмарк для проверки координации нескольких AI-агентов. Его разработали исследователи из Нанкинского университета, Tsinghua и AgiBot.

Главная идея исследования полезна далеко за пределами робототехники: