Data Engineering *

Привет, Хабр! Я Павел Молчанов, Data Engineer из группы обработки гео- и медиаданных Big Data компании МТС Web Services. Наш продукт «ГеоЭффект» занимается расчетами различных геостатистик на основе телеком-данных (например, по туризму).

У нас есть ежедневно обновляемая инфраструктурной командой витрина-источник с событиями (точками нахождения абонентов) на основе мобильной сети по всем регионам присутствия МТС. За сутки на каждого абонента приходится в среднем порядка 200 геособытий, общий объем данных в витрине — около 11 млрд записей в сутки. Однако в витрине-источнике не было привязки геособытий к административно-территориальной информации «Регион РФ / район», что критически важно нам как продуктовой команде, решающей бизнес-кейсы в интересах заказчиков. 

Отсюда и появилась задача — дообогатить витрину дополнительными атрибутами на основе координат геособытий. Так что в этом материале по мотивам доклада для Highload++ поделюсь, как мы это сделали, а еще ускорили джойн датафреймов с геоданными.

Пара слов по технологическому стеку: сейчас мы активно проводим подготовительные работы по переходу на Data LakeHouse, но пока что основная рабочая лошадка — Spark на старом добром Hadoop-кластере с HDFS и Hive Metastore. Так что повествование будет идти в контексте технологий Spark on YARN + Sedona + HDFS + Hive.

Что делать, если Docker Desktop и L2 multicast живут в разных мирах, а доказать failover кластера перед тегом v1.3.0 всё равно нужно? Под капотом: SSH-контейнеры, unicast keepalived, 9 PASS / 0 SKIP и пара неожиданных багов с Alpine и CRLF.

Открывая онлайн-кинотеатр, сервис для прослушивания аудиокниг или музыки, пользователи редко задумывается о том, почему перед ним оказались именно эти фильмы, книги или треки. Между тем рекомендательные системы в последнее время переживают крупную трансформацию. Если раньше задача сервисов сводилась к поиску похожих пользователей или товаров, то сегодня они уже умеют предугадывать намерения человека, и развитие LLM ускорило этот процесс.

Делюсь инсайтами с конференции «Урбан ML», которая прошла 2 августа в Loft Hall (ЗИЛ) в Москве. Эксперты по Data Science поделились, от чего отказываются современные рекомендательные системы, какие проблемы остаются нерешенными и куда движется отрасль.

Когда-то я всерьез занялся изучением темы согласий на рекламу и обнаружил, что Федеральная антимонопольная служба (ФАС) ведет открытый реестр дел. Это супер ценные данные для меня как исследователя, но они совсем не структурированы и анализировать их можно только вручную перечитывая каждое дело. Меня это не очень устроило, поэтому я сделал общедоступную карту дел ФАС и хочу рассказать о том, как она работает. Надеюсь, кому-то будет полезным.

parquet - данные лежат в открытом формате - казалось бы, бери кто хочешь. Но есть неприметный артефакт, от которого зависит, увидите вы таблицы или мусор из файлов и кого вообще к ним подпустят. Это каталог. Разбираю просто, что такое Apache Iceberg, зачем ему каталог - и почему новость про Polaris важнее, чем кажется. В продолжение анонса новостей…

Данная статья наврятли является гидом по созданию домашней лаборатории, скорее это некое описание намерений.

Когда вышел DuckDB 1.0, я написал статью Всё что нужно знать про DuckDB. Теперь вышел DuckLake v1.0 — LakeHouse-формат из той же экосистемы. Это отличный повод разобраться, как он устроен и как его можно использовать в production-сценариях.

В этой статье разберём, какую проблему решает DuckLake, чем его архитектура отличается от Apache Iceberg и как поднять DuckLake локально или в окружении, приближённом к production: PostgreSQL для каталога метаданных и S3/MinIO для файлов данных.

50 лет назад была выдвинута гипотеза о Языке Мышления. Наверняка вы про нее не слышали – а зря. Классная штука, которая может перевернуть (и уже переворачивает) представление о возможных методах обработки информации, воплощенных в технологиях.

Всем привет! Это Алексей из 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 на массовом железе.

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