Data Engineering *

Привет, Хабр! Меня зовут Егор Шлюпиков, и я работаю старшим бизнес-аналитиком в YADRO в большой команде, которая менеджерит IT-оборудование. Мы следим за парком готовой техники и комплектующих, нужных для работы сотрудников. Сколько нужно купить, что залежалось, что в ремонте и утилизации и так далее — плюс финансовая аналитика.

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

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

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

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

Со временем проект развивался, и недавно я завершил работу над его второй версией – Spark Cluster 2.

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

Проблемы подготовки отчетности на основе данных, собранных от разных сотрудников, хорошо известны: длительные сроки, ошибки, высокая стоимость процессов и влияние человеческого фактора. Однако переход на новую систему часто вызывает сопротивление персонала: сложившиеся за годы схемы работы никто не хочет менять. А что, если сохранить привычный формат работы, но отказаться от ручной обработки файлов, сверок и бесконечных согласований? Именно такой подход мы реализовали в Smart Forms Pro. В этой статье вас ждет базовый разбор нашего нового решения: я расскажу об основных возможностях и покажу его интерфейс.

В актуальном ФИАС – 123 720 367 записей. Сколько из этих записей пригодны для навигации в картографических сервисах? Под адресом. пригодном для картографических и навигационных сервисов понимаю

Мы нормализуем миллионы строк НСИ с точностью 98% на обычном сервере с 8 ядрами и 16 ГБ RAM. У нас нет Золотой Рыбки, у нас есть джинн, которого мы посадили в лампу. Рассказываю, как мы к этому пришли.

В прошлый раз я рассказывал, как в одиночку с 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 раз сократили поток событий, доходящий до основной системы.