Data Engineering *

В прошлый раз я рассказывал, как в одиночку с AI-агентами собрал ERP-платформу на Kubernetes из 30+ сервисов. Эта статья — про её мозг: не «ещё один агентский фреймворк», а продакшн-движок, который год несёт живых клиентов (рекрутинг с AI-интервью, CRM, парсинг-конвейеры, копилот).

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

Сервис работает на Node, на CPU.

Привет, Хаброжители!  Представьте: в компании десятки ИТ-систем, каталогов данных и баз знаний. Каждая описывает свою часть ИТ-ландшафта, но общей картины нет. Поэтому при слиянии компаний, миграции в облако или запуске проектов в области данных и ИИ приходится заново выяснять, какие системы существуют и как они связаны.

В книге «Управление метаданными. Как метасетки объединяют данные, информацию и знания» Оле Олесен-Баньё объясняет, почему метаданные часто остаются разрозненными, и предлагает способ связать их без создания очередной универсальной платформы.

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

Появляются десятки и сотни DAG, Spark-приложений, таблиц Iceberg и цепочек зависимостей. Часть процессов уже переведена на новую платформу, часть всё ещё живёт в legacy, постоянно что-то догружается, пересчитывается и меняется.

И довольно быстро простой вопрос: «Что сейчас вообще происходит на платформе?» перестаёт иметь очевидный ответ.

Чтобы понять причину задержки витрины, инженер идёт в Airflow. Потом открывает upstream DAG. Потом ещё один. Затем Spark History Server. Потом логи. Потом Grafana. Потом смотрит метаданные таблицы. А через двадцать минут обнаруживает, что проблема вообще началась тремя уровнями выше по линеджу.

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

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

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

В Jupyter Notebook модель показывает отличный ROC‑AUC, а через пару недель в продакшене её предсказания становятся хуже случайного выбора. Причина может скрываться в признаке, который при обучении и инференсе рассчитывается по‑разному, или в изменившемся поведении пользователей.

Разбираемся, как Data Drift, Concept Drift и ошибки в работе с признаками влияют на качество моделей и какие практики ML System Design помогают избежать подобных проблем.

Хабр, привет! Давай начнём с самого начала, а именно:

Если вам непонятно почему одни пишут программы так словно говорят с компьютером на одном языке, а у других токены от AI агентов заканчиваются уже к обеду. То я, скорее всего, смогу вам ответить, а так же рассказать много интересного по теме программирования. Наука это всё-таки или искусство.

Добрый день, Хабр! В рамках основной деятельности — проектирования витрин данных в корпоративных хранилищах, — неизбежно сталкиваюсь с вопросом происхождения данных. Проще говоря, необходимо понять, кто и когда, как, из чего и в чьих интересах собрал попавшийся под руку датасет. Обновляется ли срез данных и есть ли у него пользователи? Для такого процесса в мире DWH давно укоренилось название «построить Data Lineage». Предлагаю вместе со мной еще раз пройтись по определению и попробовать его уточнить, так сказать, донащупать.

Builder ELT — open-source ELT-приложение, которое позволяет визуально создавать потоки загрузки, объединять их в цепочки и запускать по расписанию. Преобразования выполняются средствами целевой базы данных на нативном SQL, а Python используется для работы с нестандартными источниками и API. Приложение не хранит в себе пользовательские данные. Основная цель создать стандартизированное решение, в котором можно было бы быстро создать ELT поток, не теряя гибкость SQL трансформаций. В итоге любой аналитик знающий SQL может загрузить себе данные.

Откуда это все и зачем.

Примерно в начале 2026 года, работая инженером аналитиком на проекте, я написал питон код для стандартизации ELT процессов. В нем обычная дельта/фулл выборка и запись в журнал.

Процесс загрузки данных повторяется на каждом проекте, а каждый ELT разработчик пишет код по своему. Хотелось стандартизировать хотя бы реперные точки, уменьшить время разработки и кол-во ошибок. Конечно любая стандартизация это постановка в рамки и уменьшение гибкости. Но здесь сработало правило 20/80. В добавок аналитики как правило зависели от специалистов ELT и ждали новые данные.

Сначала был написан пул питон функций и использовалось в виде локального питон-пакета. Далее для удобства был прикручен GUI и база данных для хранения метаданных. Получилось приложение, в котором можно было подключаться к источнику/приемнику, создавать поток и планировать запуск. Получилось что-то с чем можно было уже работать. Далее для возможности создавать очередь потоков был прикручен celery и redis. Ну и на сладкое провайдер авторизации keycloak.

Представим ситуацию: мы обучили модель, получили Accuracy 77% и решили немного изменить параметры. Запустили обучение повторно — теперь получилось 72%.

Представим обычную ситуацию: мы обучили несколько моделей, сравнили их на тестовой выборке и получили довольно странный результат. Простейшее дерево решений показывает Accuracy почти 97%, а Random Forest из 300 деревьев — всего 91,5%.

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

Привет! Я Дмитрий, Data Engineer в ИТ-компании SimbirSoft. В этой статье я постараюсь кратко описать основные категории существующих движков системы ClickHouse, особенности использования движков, а в конце дам несколько рекомендаций для их практического использования. Думаю, материал будет полезен больше джунам, однако и опытным специалистам, работающим с другими базами данных, будет интересно узнать про движки, которыми они еще не пользовались. Поэтому перед рассмотрением самих движков начну с небольшой вводной части.

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

Разберём небольшой учебный пример: три заказа, их позиции и оплаты. Покажу, почему COUNT(DISTINCT) может скрыть проблему, SUM(DISTINCT) — испортить результат, а предварительная агрегация — исправить расчёт только при правильно выбранной детализации. SQL‑примеры проверены в SQLite; это разбор логики данных, без привязки к конкретной BI‑системе.

Можно ли разложить 15+ млн хаотичных товаров по 1100 категориям за месяц? Да – без зубодробительного ML и миллионных затрат на LLM-инференс!

В статье о том, как:

1. ML проиграл системе простых бизнес-правил;

2. мы присвоили артикулы товарам для целой отрасли;

3. заставить работать даже самые зашумлённые данные из CRM.

В статье разбираем, как устроен Apache Airflow 3, для каких задач он используется, какую роль играет в архитектуре DWH и BI, и когда его стоит выбирать для оркестрации процессов обработки данных. Сравниваем с Prefect и Dagster.

Привет! Меня зовут Сергей Прокопкин, я развиваю мотивационную программу и отвечаю за realtime-систему трекинга заданий в Авито. 

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

На первый взгляд техническая задача выглядит довольно просто: получаем действия пользователя, проверяем их на соответствие активным заданиям и обновляем прогресс. Но когда поток событий становится большим, а число заданий и аудитория растут, простая схема начинает дорого обходиться. В нашем случае выяснилось, что более 99% обрабатываемых событий вообще не влияли на прогресс пользователей.

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

Привет, Хаброжители! Мы подготовили для вас новый перевод статьи о контрактах данных. Здесь рассмотрены контракты данных на основе объектов, реализованные на базе CDC. Рассказано, каково определение контракта, как он выполняется, и как для него предписывается схема.

А что если вместо дашборда по затратам Databricks добавить их прямо в интерфейс. С этой идеи начался наш мини проект, который решал сначала нашу локальную проблему, а теперь доступен для всех.

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

Когда говорят о Neo4j, чаще всего вспоминают social networks, fraud detection, recommendation systems или knowledge graphs.

Но графовая база может быть полезна и внутри обычного data engineering проекта, где уже есть Kafka, аналитическая база, dbt, Airflow и BI.

Мне было интересно проверить именно этот сценарий.

Первые подводные камни логирования: практика на примере Python‑коннектора в Airflow — цифры до/после, спорные кейсы уровней, карта логов как контракт.