Data Engineering *

Всем привет! Это Алексей из GlowByte. В прошлой статье я говорил о том, почему категорийный менеджер в большой сети часто чувствует себя одиноким среди сотен дашбордов: систем у него избыток, а компетентного собеседника, который был бы в его контексте и без своей повестки, рядом нет. Решение, которое мы GlowByte называем мультиагентной платформой, закрывает именно эту потребность. В новой статье разберём, что под капотом у такого решения и почему ИИ‑напарник ближе к партнёру по бизнесу, чем к очередному чат‑боту.

Привет, Хабр! Меня зовут Михаил Сичалов, я руководитель проектов и эксперт практики Applied Intelligence в компании Axenix.

Это вводная статья из цикла работ, посвящённых реальным сценариям использования Apache Spark и сопутствующим техническим нюансам, с которыми я столкнулся за последнее десятилетие работы над проектами в области Data Engineering. Я решил систематизировать и переосмыслить свой опыт работы с этим фреймворком и поделиться с сообществом интересными и нестандартными аспектами, освоенными на практике.

Несмотря на выразительность модуля Spark SQL с точки зрения описания преобразований над данными, зачастую возникает необходимость в создании пользовательских функций (UDF). Для этого в Apache Spark есть целое подмножество API, с помощью которого можно реализовать пользовательскую функцию произвольной сложности. Но что делать в случае, когда код функции становится доступным только в рантайме, а Spark используется в связке с Java API?

В данной статье рассмотрим подход к подготовке, компиляции и исполнению Java-кода пользовательских функций в рантайме приложения Spark, а также, почему этого не стоит повторять.

10 идей конференции AI Engineer о том, как меняется разработка, когда код пишут агенты.

В начале 2026 года небольшая команда OpenAI рассказала о необычном эксперименте.

Три инженера за пять месяцев создали внутренний продукт объёмом около миллиона строк кода и провели через репозиторий примерно 1500 pull request’ов. Продуктом пользовались сотни сотрудников. При этом люди не написали вручную ни одной строки: прикладной код, тесты, CI‑конфигурацию, документацию, observability и внутренние инструменты генерировал Codex.

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

Но наиболее интересным результатом эксперимента оказался не миллион строк кода. Им стало открытие нового узкого места.

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

Именно этот сдвиг лучше всего описывают выступления AI Engineer 2026 — весенней конференции Europe в Лондоне и летней World's Fair в Сан‑Франциско.

Доклады посвящены разным темам: контексту, памяти, длительным циклам, командной координации, верификации и безопасности. При этом важно не сводить их к одной заранее выбранной теории. Каждый спикер предлагает собственную модель AI‑first разработки, основанную на своём опыте и профессиональной перспективе.

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

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

Как перепроверить отчёт, который прислали специалисты? Как перестать постоянно обращаться к аналитикам с ad hoc-запросами и часами ждать очередную таблицу? Может быть, стоит просто спросить нейросеть о показателях своей компании?

У этой концепции есть название — GenBI. Сама идея не нова: сегодня производители встраивают копилотов практически во все аналитические сервисы и обещают доступ к корпоративным данным через запросы на естественном языке.

Но на практике всё оказывается сложнее.

Когда говорят о GenBI, архитектуру часто описывают так: пользователь задаёт вопрос на естественном языке, большая языковая модель пишет SQL, база данных выполняет запрос, а модель объясняет результат.

Для демонстрации этого достаточно.

Для корпоративной аналитики — обычно нет.

Мы с командой занимаемся проектированием и разработкой корпоративных BI-систем на базе SQL Server, SSIS, SSAS Tabular и Power BI. В основном это on-premise-решения, где данные из учётных систем проходят через DWH и семантическую модель, прежде чем становятся доступны пользователям. В последнее время также занимаемся интеграцией таких моделей с LLM-интерфейсами.

Главная проблема здесь не в том, умеет ли LLM написать синтаксически корректный запрос. Современные модели умеют генерировать и SQL, и DAX. Проблема в другом: откуда модель должна узнать, что именно компания называет выручкой, продажей, активным клиентом, себестоимостью или остатком?

В исходном orders.csv было 11 строк. До BI-витрины дошло 7, а валовая сумма 4720.30 после применения бизнес-правил превратилась в 2200.30 выручки. Четыре строки не исчезли: каждая попала в rejects с конкретной причиной.

На этом небольшом примере покажу весь путь данных через RAW, STG, CORE и MARTS. Разберём, где меняются строки и суммы, как пережить повторную доставку файла и какие проверки позволяют доверять итоговому дашборду. Внутри MinIO, Postgres и Airflow.

Зашёл тут на карту и вижу странную картину. На Чистых прудах висят три пина ровно друг на друге. Тыкаю, а там один и тот же «Вишнёвый сад» в Ленкоме. Совпадает всё, вплоть до времени и зала. Просто данные прилетели из трёх разных мест. Где-то площадка записана просто как Ленком, где-то полностью с именем Марка Захарова, а в третьем случае вообще пусто. Для пользователя это три разных события на карте, хотя спектакль на самом деле один.

У меня сейчас Окрест тянет афиши по шестнадцати городам из Яндекс Афиши, Afisha.ru, Timepad, KudaGo и телеграм-каналов самих площадок. Сейчас в базе 23 097 активных событий, и пересечений между источниками много. 8260 событий приходят из двух источников, 533 из трёх, десять встречаются сразу в четырёх. На карте всё это должно превращаться в одну точку, а не в гирлянду пинов.

В аналитике больших данных системы массивных параллельных вычислений часто находятся под постоянной нагрузкой в режиме 24/7. Из десятков и сотен тысяч запросов в день многие исполняются одновременно и конкурируют за ограниченные ресурсы вычислительного кластера. Чем рациональнее каждый отдельный запрос их использует, тем больше запросов система сможет обслуживать параллельно. Соответственно, выше пропускная способность за конкретный отрезок времени. Как правило, проблема нехватки ресурсов остро ощущается в пиковые часы нагрузки. Можно бесконечно до совершенства настраивать и править параметры сессии на каждый запрос индивидуально вручную, но нам — команде разработки платформы данных Data Ocean Nova — всегда хочется иметь более системный подход.

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

Магнус Карлсен сыграл партию с точностью 88.7% на Chess.com и 71% на Lichess. Кто прав? Спойлер: единственно правильного ответа здесь, скорее всего, нет. Разбираю по шагам, как Lichess считает точность партии, от сантипешек и логистической функции до гармонического среднего и контекстно-взвешенной агрегации. В конце - Python-скрипт для воспроизведения результата.

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

В статье разберём, как выстроить воспроизводимый ML‑пайплайн с контролем данных, версий и состояний, чтобы решения модели можно было восстановить, проверить и обосновать.

Артефакт нашей сборки — не бинарник, а код вместе с терабайтами рассчитанных таблиц. Рассказываем, как из штатных фич Airflow, Spark и Delta Lake у нас собрался настоящий CI/CD для данных и моделей — с релизами, стейджем и откатами. И почему кнопку «выкатить в прод» жмёт дежурный data scientist, а не инженер данных.

Мы собрали модель, которая одновременно решает детекцию, классификацию и сегментацию, и при этом остается радикально легче и экономичнее по ресурсам, чем любые современные SOTA‑архитектуры. На COCO и RF100‑VL мы получаем качество детекции уровня крупных transformer‑детекторов при сотнях раз меньшем числе параметров, а на LVIS – покрытие и точность масок, недостижимые для YOLO‑семейства без переобучения, все это в режиме близком к real‑time на массовом железе.

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

Что если задать BI-системе вопрос, который выходит за рамки рутинной аналитики? Будет ли она также эффективна? Эта идея родилась из корпоративного шуточного спора: шутили над качествами сотрудника «Рака», а в статистику попали также и другие «носители» знака зодиака. 

Мы в Modus решили проверить закономерности на данных, так как это наш профессиональный рабочий инструмент и сфера интереса. Взяли статистику всех игроков Российской Премьер-Лиги, добавили знаки зодиака — и посмотрели, что получится. 

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

Следующий "Момент Бэкуса" или почему мы, возможно, стоим на пороге новой эпохи разработки ПО.

Английская версия этой статьи ранее была опубликована мной в LinkedIn. Для Habr я подготовил адаптированную версию, добавил исторический контекст и подробнее раскрыл главный тезис.

SSB — «мы стояли на „плоскости“»

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

Обучил multi-label классификатор на 15 классов для модерации Discord-сообщества, получил micro F1 = 0.9358 — цифра, с которой можно закрывать задачу и не разбираться дальше. Но стоило посмотреть на precision и recall по каждому классу отдельно, как выяснилось: recall на TOXIC — около 0.78, а для части редких меток test split вообще не подтверждает качество — положительных примеров там почти нет. Разбираю на реальных цифрах и коде: почему агрегированная метрика такое скрывает, как считать вес классов через pos_weight при сильном дисбалансе, почему checkpoint стоит выбирать по macro F1, а не по training loss, и где принцип «чем проще — тем лучше» перестаёт работать при оценке качества классификатора.

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

История других отраслей показывает, что происходит дальше. До Uber цену поездки знал только таксист, и пассажир зависел от его решения. Как только маршрут и стоимость стали видны на экране, преимущество водителя исчезло. Booking сделал прозрачными цены на отели, маркетплейсы - на товары, Google Maps - на логистику. Строительство пока остаётся одним из немногих крупных рынков, устроенных «как такси до Uber»: полной картиной по стоимости и срокам владеет только одна сторона, а вторая оплачивает эту асимметрию перерасходами.

Дальше в статье - нидерландский строительный картель с двойной бухгалтерией и 1300 оштрафованных фирм; алгоритмы, которые находят следы сговора прямо в цифрах торгов; два миллиарда долларов SoftBank, сгоревшие в «кнопке Uber для стройки»; и рынок жилья, который свою уберизацию уже прошёл. Через историю и паттерны видно, какими будут инструменты уберизации строительной отрасли в следующие десятилетия.

Два месяца назад я запустил повторный замер одних и тех же 20 промптов в двух ИИ-поисковых системах — хотел посчитать, с какой скоростью источники вымываются из цитируемой выдачи. Результат оказался неожиданно резким: за первый месяц ChatGPT перестаёт ссылаться примерно на три четверти доменов, которые цитировал в начале, Алиса AI — примерно на половину. А между первым и вторым месяцем распад почти останавливается. Ниже — как я это мерил, что получилось и почему на трёх точках во времени можно уверенно говорить про форму кривой, но нельзя — про точный коэффициент.

В современном цифровом мире — от глобальных сетей передачи данных до логистических цепочек и систем обработки транзакций — мы постоянно сталкиваемся с необходимостью эффективного управления потоками. Как обеспечить бесперебойную работу интернет-соединений при пиковых нагрузках? Как оптимизировать маршруты доставки товаров в мегаполисе? Как спроектировать call-центр, чтобы клиенты не ждали ответа? Ответы на эти вопросы лежат в области теории массового обслуживания — математической дисциплины, изучающей системы, где заявки (пакеты данных, клиенты, транспортные средства) поступают на обслуживание, образуя очереди.

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

Большинство распределенных хранилищ при заполнении примерно на 95% начинают работать в 2-3 раза медленнее. В наших тестах производительность упала всего на 4–9%. Причина в архитектуре MIND uStor. В этой статье разберем, как устроена модель хранения данных, как организован ввод-вывод и за счет чего система сохраняет производительность даже при высокой утилизации дискового пространства.

В первой статье мы рассмотрели типичные проблемы программно-определяемых хранилищ (SDS): падение производительности по мере заполнения, дополнительные затраты на отказоустойчивость и сложность эксплуатации. Эти ограничения характерны для большинства систем такого класса, поэтому при разработке uStor нам пришлось искать баланс между производительностью, надежностью, эффективностью использования дискового пространства и сложностью реализации.

Здесь разберем, как устроено размещение данных, каким образом кластер сохраняет производительность при заполнении свыше 90%, как работают RF- и EC-пулы, а также почему iSCSI-таргет реализован в пространстве пользователя. Отдельно остановимся на компромиссах, которых потребовала реализация этих решений.