Big Data *

Реранк — самая дорогая стадия пайплайна классификации по справочнику ОКТРУ: поиск отбирает 30 кандидатов, LLM выбирает один. Я проверил, можно ли отдать этот шаг модели, которая вообще не генерирует текст, — TypeSafe Jev: она принимает состояние и типизированные вопросы, а возвращает вероятности.

Замер на 928 позициях технических спецификаций госзакупок, на одном пуле кандидатов, против gpt-oss-120b с reasoning и без него, Gemma-4-31B, Gemini 3.5 Flash Lite, 3.8 Flash и 3.1 Pro и классического кросс-энкодера Qwen3-Reranker-8B. Jev дал отличную точность, как у больших моделей, но при этом стоимость и латенси как у небольшой 8B-модели.

Привет, Хабр! По первому образованию я юрист. Успел поработать в прокуратуре и арбитражном суде, потом ушёл в ИТ и последние 13 лет занимаюсь инфраструктурой, разработкой и DevOps. Сейчас строю MLOps-платформу.

Эта биография мешает мне спокойно читать споры об авторском праве и генеративном ИИ. Юрист видит копирование чужих книг. Инженер — цепочку операций: crawler, raw storage, очистку, дедупликацию, training mix, веса, API. Между «скачали страницу» и «модель ответила пользователю» слишком много разных действий, чтобы обсуждать их одним словом «обучение».

Отправной точкой для этого разбора стала колонка Мэтта Столлера о внутренних материалах OpenAI и Microsoft. Столлер пишет прежде всего о политике и неравном применении закона. Меня зацепил другой вопрос: как тот же конфликт выглядит на уровне движения данных по ML-pipeline — и что с этим вообще может сделать инженерная команда.

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

Часто задаюсь таким вопросами:

• что будет с моими активами через 5 лет, если взять квартиру в ипотеку?

• стану ли я богаче или же беднее от этого?

• смогу ли я выплатить вообще с текущими доходами и расходами всю ипотеку?

• а если не смогу, в какой момент получу кассовый разрыв?

Ипотечные калькуляторы считают только платёж, а в Excel нужно знать тонну формул для учета всех нюансов расчетов во времени, да и наглядность в эксель сильно хромает.

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

• снимать квартиру и параллельно гасить ипотеку

• или взять жильё на миллион дороже, сразу заехать и отправлять сэкономленную аренду в досрочное погашение.

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

В феврале этого года проект с красивым именем Polaris незаметно стал полноценным проектом фонда Apache. Новость прошла как-то мимо, ну стал и стал, мало ли. Между тем это одна из тех новостей, которые лет через пять, возможно, будут называть поворотной точкой. Потому что Polaris — это каталог. А каталог в мире Iceberg — то самое место, где на самом деле лежит власть над вашими данными.

Звучит громко, понимаю. Поясню, откуда такая уверенность.

Последние несколько лет хранилища данных строят по новой схеме: файлы лежат в объектном хранилище, поверх них открытый формат в виде метаданных, движки обработки живут отдельно в виде федеративного обработчика и ходят за данными. Схему назвали лейкхаусом (Data LakeHouse), а формат в ней почти везде один и тот же — Apache Iceberg. Вендоры за него отвоевались, открыли и согласовали, и все выдохнули. Данные наконец-то ничьи (формат parquet): лежат у вас, читаются чем угодно, никакой платформы-хозяина.

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

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

Добро пожаловать в середину сентября 2026 года. Если вам казалось, что индустрия ИИ летит на гиперскорости в бетонную стену, то на этой неделе это поняли и сами водители спорткаров. Риски того, что технологии выйдут из-под контроля, перестали быть сюжетом для блогов и перешли в разряд экстренных совещаний.

Эта неделя подарила нам киберпанковые сюжеты: нейросети начали взламывать серверы конкурентов (буквально), автономные агенты изобретают собственные диалекты с отсылками к Джойсу, а для «спятивших» ботов теперь создают горячие линии доносов. И пока в Китае ИИ-актеры уже захватили рынок мобильных сериалов, бигтех всерьез заговорил о том, чтобы ударить по тормозам.

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

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

Такую работу удобно поручать Агенту.

Привет, Хабр. Я Игорь Юрченко, backend-разработчик Сбера. В предыдущей статье я описал автоматизацию развёртывания потоков NiFi, а сейчас расскажу о дальнейшем развитии этого подхода для интеграции с корпоративной системой управления секретами — SecMan. Буду использовать терминологию предыдущей статьи.

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

Я автоматизировал почти всю цепочку действий по фандрейзингу: сбор инвесторов из источников, отбор, отправку им сообщений через свою CRM, отслеживание ответов и вывод на звонок.

Чуть ниже описываю, как делал и какие цифры получились. Ну и где не получилось так, как мне бы хотелось.

Привет, Хабр! Я Алексей Новаков, ведущий инженер данных в Рунити. Сегодня разберемся, зачем Lakehouse понадобился streaming, почему одного Iceberg для этого не всегда хватает и как Iceberg и Paimon могут жить рядом в одном конвейере.

Если сильно упростить, классический Lakehouse решает понятную задачу: берем дешевое объектное хранилище и добавляем поверх него то, чего не хватало обычному Data Lake — транзакции, schema evolution, snapshots, SQL, update/delete отдельных строк и одновременное чтение и запись.

Но дальше возникает следующий вопрос: что делать, если аналитика должна видеть не вчерашние или часовые данные, а состояние, которое обновляется постоянно?

Именно здесь Lakehouse начинает превращаться в Streaming Lakehouse — или Streamhouse.

Привет! Я Денис, старший бэкенд-разработчик в Selectel. В предыдущих частях мы познакомились с архитектурой Apache Iceberg, а также развернули и настроили каталог метаданных.

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

Однако при ручном просмотре S3-бакета ничего похожего на таблицу не обнаружится — видны лишь вложенные папки с Parquet-файлами и JSON-метаданными. Да, Iceberg и каталог решили задачу хранения и версионирования, но не ответили на вопрос, как читать эти данные с помощью SQL.

И вот возникает практическая задача: как аналитику или инженеру обратиться к Iceberg-таблице посредством SQL, не поднимая Spark-кластер и не перенося данные в отдельную СУБД?

Команда 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‑агентов