Data Engineering *

Если вы когда‑либо строили пайплайны для обработки потоков данных в реальном времени со строгими требованиями, то наверняка знаете, сколько инфраструктурных заморочек в этом деле. Например, обеспечивать относительно низкие end‑to‑end‑задержки в штатном режиме относительно несложно. Но что, если они нужны и в высоких перцентилях, в том числе при сбоях или плановом обслуживании одного из используемых дата‑центров целиком? Как правильно партиционировать поток данных, обрабатывающие его процессы и их долгосрочное состояние, если нагрузка постоянно меняется? Как гарантировать exactly‑once, то есть отсутствие потерь и дублей даже при сбоях оборудования и в краевых случаях? Как понять, обработали ли мы все данные на тот или иной момент? 

С такими вопросами мы столкнулись при разработке высоконагруженных рекомендательных систем. Для этих задач мы создали YTsaurus Flow — фреймворк потоковой обработки данных с сохранением состояния между событиями и гарантиями exactly‑once по умолчанию. Это совместный проект команд Yandex Infrastructure и Яндекс Рекламы для обработки потоков данных в реальном времени. И сегодня мы открываем его исходный код под лицензией Apache® 2.0.

Flow — часть YTsaurus, платформы хранения и обработки данных, которую мы выложили на GitHub в марте 2023 года. Flow использует хранилище, очереди и общий механизм транзакций платформы, чтобы брать на себя управление состоянием и восстановление обработки после сбоев. Разработчик пайплайна при этом сосредоточивается на прикладной логике.

В статье разберём, зачем мы разработали собственный движок, как устроены его пайплайны и за счёт чего обеспечивается exactly‑once. А на примере реального сервиса покажем, как переход на Flow помог сократить задержку поставки данных для дообучения моделей с десятка‑другого часов примерно до двух.

Привет! На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Я достаточно много занимаюсь интеграциями, хранилищами данных и BI, поэтому, когда ребята из «Денвик Аналитика» предложили познакомиться с новым инструментом DVT, не стал отказываться.

Привет, Хаброжители! Джей Бортен дает подробное практическое руководство по интеграции данных — от базовых понятий и терминологии до реального сквозного примера, который шаг за шагом превращает разрозненные источники в работающий конвейер на AWS, Qlik, Databricks и Confl uent.

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

BeautifulSoup, Scrapy, Selenium и Playwright часто сравнивают как аналоги, хотя это инструменты разных уровней. Я собрала тестовый стенд и сравнила их на статическом HTML, JavaScript-странице, массовом обходе и работе с UI — с замерами времени, памяти и неожиданными результатами.

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

Решил сделать персональную разметку телепрограммы: читать названия и описания, находить подходящие передачи и добавлять звёздочку в начало названия. Получился конвейер от XMLTV до небольшой BERT-модели в домашнем Kubernetes. На синтетически расширенной выборке модель показала macro-F1 = 1,000, а в выходном расписании нашлись 66 записей со звёздочкой.

При проверке материала для статьи выяснилось, что оба результата требуют серьёзных оговорок. У 119 из 120 тестовых записей описание уже встречалось в обучении с другим номером части. В обработчике XML обнаружилась ошибка, из-за которой тысячи передач записались пустыми. Ниже разберу устройство системы, реальные ответы модели и то, что мы преждевременно приняли за успешное внедрение.

Всем привет. Меня зовут Сергей и я руковожу разработкой автоматизации внутренних бизнес-процессов в рамках Центра управления процессами Московской Биржи.

В эпоху повсеместного распространения инструментов на базе искусственного интеллекта (ИИ) вопрос применения доменно-специфичных языков (DSL, domain specific language) вызывает неоднозначную реакцию. С одной стороны, большие языковые модели прекрасно понимают широкое многообразие естественного языка и могут работать напрямую с ним. С другой стороны, присущая любому человеческому общению неоднозначность оставляет простор для неправильных трактовок и ошибок.

Я собрал больше 32 тысяч объявлений с Krisha и данные БНС по зарплатам, ценам, тарифам и переездам. Потом посчитал, сколько остаётся от зарплаты после аренды, еды и коммуналки, и сравнил это с тем, куда на самом деле переезжают люди.

Ivory начинался как небольшой инструмент, упрощающий работу с кластерами PostgreSQL и Patroni.

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

Теперь Ivory помогает делать то же самое и упрощает работу с другими сложными системами баз данных: MongoDB, ClickHouse, Redis и т. д. А если вы захотите добавить любую другую базу данных, это легко сделать с помощью AI-агентов. Для этого есть специальный subagent.

Главный сдвиг — Data Catalog перестал быть просто справочником метаданных и становится инфраструктурой доверия к данным и источником контекста для аналитиков, процессов и ИИ-агентов.

Три года назад мы выпустили исследование российских каталогов данных. Тогда для сравнения решений хватало около 20 вопросов: есть ли автоматическая каталогизация, Data Lineage, бизнес-глоссарий и другие базовые функции.

В отчёте «Data Catalog Круг Громова 2026» - количество критериев выросло до 325. За три года рынок заметно изменился, и прежней методики стало недостаточно. В этой статье расскажем не о результатах сравнения продуктов, а о главных изменениях рынка — в том числе тех, которых мы сами не ожидали увидеть.

В первой части материала мы разобрали, что необходимо контролировать в корпоративном хранилище данных - от инфраструктуры и ETL/ELT-процессов до Data Quality и выполнения запросов:

Мониторинг и логирование DWH, часть 1: уровни контроля, метрики и типовые проблемы

Во второй части перейдем к конкретным инструментам: Prometheus, Grafana, Zabbix, ELK Stack, OpenSearch, Loki. Разберем, как они устроены, какие задачи решают, чем отличаются друг от друга и на что обратить внимание при выборе стека для мониторинга и логирования DWH.

Привет, Хабр! Меня зовут Максим Шуматбаев, я инженер технической поддержки в Arenadata. Это вторая часть разбора, что на самом деле происходит при работе клиентских приложений с Kafka-кластером. В первой части мы проследили запись от получения метаданных до транзакций и exactly-once. Теперь очередь второй половины пути: как потребитель получает данные, делит партиции с другими участниками группы, фиксирует прогресс и почему иногда начинает отставать.

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

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

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

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

Сценарий знакомый: открываешь в pandas файл побольше, ноутбук задумывается, и через минуту всё падает с MemoryError. Следом обычно звучит совет: для больших данных есть Spark. Я решил проверить его цифрами, но не на кластере, а на слабой машине с двумя ядрами и 5,8 ГБ памяти.

Сравнил шесть вариантов: pandas, pandas с pyarrow, Polars, Polars в потоковом режиме, DuckDB и PySpark. Пять типовых операций, объёмы от 6 до 180 млн строк, контроль памяти и автоматическая сверка результатов между библиотеками. Эта сверка по дороге нашла баг, из-за которого Spark терял целый день данных.

Кто сдался первым, кто удивил и почему переход на Spark часто не лучший выход, рассказываю под катом.

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

Привет! Меня зовут Максим Коцюба, я старший инженер по данным с опытом в финсекторе — ВТБ и Сбер, выпускник онлайн-магистратуры «Инженерия данных» НИУ ВШЭ и Нетологии. В выпускной работе я взялся за эту задачу и собрал сквозной ML/MLOps-пайплайн, который не просто классифицирует операции, а ранжирует их по степени риска. Расскажу, что получилось и почему одной классификации оказалось мало.

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

Меня зовут Олег Игнатов, я Head of Product Analytics в Garage Eight. В статье расскажу, как мы собрали матрицу зрелости аналитики, а затем превратили результаты оценки в планы развития. Покажу, почему партнерская модель — важный, но не финальный этап развития аналитика, и объясню, почему с распространением AI роль аналитика-владельца становится только важнее.

В скрипте обучения лежал список из 39 парковок, которые надо исключить: у них замороженный ряд, и модель учится на них предсказывать константу. Сегодня молчащих парковок тоже 39, и совпадают из них девять. Пока разбирался, выяснилось интересное: эти 39 константных рядов улучшают публикуемую MAE на 16% и превращают наивную базу с отрицательным R² в базу с положительным. При этом на самих этих парковках модель работает хуже, чем её отсутствие.

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

Поэтому при эксплуатации DWH используют инструменты мониторинга и логирования.

В первой части материала про мониторинг DWH разберем, что именно необходимо контролировать на каждом уровне хранилища и какие сигналы помогают своевременно обнаружить проблемы.

Привет, я Салават Динмухаметов, senior ML-engineer в команде рекомендаций Авито. В статье расскажу, как мы изменили систему рекомендаций на главной странице. 

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

Мы решили ускорить обучение — и за несколько итераций сделали neartime-архитектуру, которая обновляется каждые 20 минут. Это повысило качество, бизнес-метрики и сэкономило память.

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

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

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