Data Engineering *

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

Как перепроверить отчёт, который прислали специалисты? Как перестать постоянно обращаться к аналитикам с 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-таргет реализован в пространстве пользователя. Отдельно остановимся на компромиссах, которых потребовала реализация этих решений.

Всем привет! Меня зовут Катерина Цаплина, я AI Architect и программный эксперт курса «MLOps для разработки и мониторинга моделей». Работаю на стыке ML, инфраструктуры и корпоративной архитектуры в крупной промышленной компании и на практике вижу, насколько непросто выстраивать такие процессы в реальной организации.  

Это четвёртая и финальная статья цикла о том, как компании реализуют MLOps. В предыдущих частях мы разобрали, как компании могут строить MLOps в целом, рассмотрели пример внутренней ML-платформы Uber Michelangelo и на примере Netflix Metaflow разобрались, как workflow-фреймворки помогают навести порядок в ML-разработке.

Сегодня разберём ещё одну альтернативу собственной платформе: managed-сервисы облачных провайдеров. На примерах Google Vertex AI, Yandex DataSphere и Yandex AI Studio рассмотрим, как они устроены и чем будут полезны команде и бизнесу. И, наконец, подведём итог всей серии статей.

Когда речь заходит про Lakehouse и федеративный доступ, многие вспоминают про Trino и… часто на этом все. Но федеративные запросы поддерживаются в том или ином виде довольно большим количеством СУБД, SQL-движков и систем для виртуализации данных.

В этой статье постараемся немного расширить кругозор читателей, которым интересна данная тема: рассмотрим федеративные запросы на примере набирающего популярность и активно развивающегося StarRocks. Из статьи вы узнаете: что такое федеративные запросы, как обстоят дела с реализацией гетерогенного федеративного доступа в этой СУБД и какие изменения команда решения Data Ocean Nova реализовала для оптимизации в StarRocks и Impala с целью улучшения функционала доступа к внешним данным.

Как мы провели проект через четыре «эпохи» — от ручных запусков на Windows‑планировщике до Spark + k8s на масштабе сети

Привет, Хабр! Меня зовут Имиль Валиуллин, я тимлид команды разработки платформы OSA. В предыдущих статьях цикла On Shelf Availability (OSA) уже разбирали с разных сторон: что такое OSA как продукт, как устроен алгоритм детекции аномалий и весь конвейер генерации сигналов — эвристики, ML‑модели, фильтры, обратная связь, A/B и оценка эффекта (ссылки на предыдущие статьи: 1, 2, 3). В этой статье мы раскрываем следующий слой — инженерный. Потому что всё перечисленное было бы невозможно без большой работы под капотом: данных, транспорта, оркестрации, SLA, мониторинга, качества данных, обратной связи, API и доставки сигналов в торговые точки. Многие забывают, что даже самая крутая ML‑модель — это только верхушка айсберга. Результат появляется только тогда, когда под ней есть надёжный фундамент: чистые данные, стабильный транспорт и бесперебойная доставка. Как говорится, garbage in — garbage out, и наоборот: качественный фундамент позволяет получить качественный результат.

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

Показать это мы хотим через эволюцию продукта — от legacy и ручных запусков до промышленной платформы, работающей на масштабе сети. С точки зрения пользователя это всё тот же продукт — сигналы на торговых точках (ТТ), помощь сотрудникам магазина, рост доступности товара. Но под капотом OSA прошёл несколько серьёзных инженерных перерождений, которые мы для удобства назвали «эпохами»: каменный век, бронзовый, железный и индустриальная эпоха. 

Эта идея появилась у меня давно.

Когда мы внедряли BI в крупном банке, я заметил одну вещь: больше всего внедрению радовались руководители. У них появлялись дашборды, графики, показатели, визуальная картина происходящего.

А вот люди, которые каждый день работали с данными, не всегда были в таком же восторге.

BI хорошо показывает, что что-то изменилось: появилась аномалия, просел показатель, выросло значение, изменилась динамика. Но после этого почти всегда возникает следующий вопрос: почему так произошло?

И вот тут уже приходится разбираться не с графиком, а с данными.

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

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

Для таких задач пользователи всё равно часто уходили в Excel: добавляли формулы, сверяли расчёты, сравнивали текущую выгрузку с предыдущей.

Так появилась первая версия программы: она формировала отчёты в Excel и хранила на сервере историю выгрузок.