Data Engineering *

Если вы работали с API Ozon, то наверняка испытывали смешанные чувства, поняв, что отчет по транзакциям формируется по отправлениям. а не по товарам, как в WB. И проблема в том, что в одной строке ответа API метода v3/finance/transaction/list мы имеем данные по отправлению, в котором может быть несколько товаров. При этом указанная сумма покупки (accruals_for_sale), комиссии, логистики и других начислений в отчете указана одна, то есть на все отправление в целом. А значит встает задача, посчитать сколько из общей суммы приходится на единицу товара.

В этом статья поделюсь, как я решил эту проблему в своей системе аналитики продаж через Wildberries и Ozon. Напомню, небольшой обзор своей системы WBOZYA‑dash я делал в первой статье. А как получать данные из API маркетплейсов без ошибок 429 и 50x описал во второй статье.

В мае 2024 года Broadcom заархивировал публичный репозиторий Greenplum: последний коммит остался на месте, дальнейшая разработка ушла в закрытый репозиторий, enterprise-сборка теперь доступна только по подписке. Greenplum как живой OSS-проект остановился — но сам код, выпускавшийся с октября 2015-го, остался под Apache 2.0. Именно на этой кодовой базе стартанули остальные форки.

Те, кто строил аналитику на Greenplum, оказались перед развилкой. Сообщество разделилось: Apache Cloudberry (incubating), Greengage DB от Arenadata, WarehousePG от EDB. Каждый форк продолжает линию, но в собственной траектории. У компании с боевым кластером появляется конкретный вопрос: переехать/остаться в одном из этих форков или мигрировать на принципиально другую платформу и архитектурную парадигму.

Эта статья (сага из трёх эпизодов) будет полезна, если у вас уже есть Greenplum-кластер, вы понимаете его DDL/ETL/backup-процессы и хотите оценить, насколько болезненным будет переход на StarRocks. 

Всем привет! Меня зовут Вадим, я — Data Scientist в компании Raft. Эта статья написана по мотивам моего выступления на конференции AiConf 2025. В ней мы разберём, какими метриками измеряется машинное разучивание и какие основные методы позволяют добиться контролируемого «забывания» без полного переобучения модели. Погрузимся в методы, метрики и бенчмарки, связанные с машинным разучиванием.

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

Всем привет, меня зовут Никита. Не так давно к моей команде обратился сервис аналитики маркетплейсов — они собирали данные по WB и Ozon и отдавали их селлерам в виде отчетов.

Процесс был устроен по простой схеме: по расписанию обращались к API Wildberries и Ozon, выгружали данные в Google Sheets, дальше внутри таблиц уже считали метрики — продажи, конверсии, воронки, какие-то производные показатели. У каждого клиента свой набор таблиц, свои формулы, свои доработки.

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

Проблемы начались, когда объем клиентов вырос.

У каждого по несколько кабинетов (WB, Ozon), таблицы начали разрастаться, логика расчётов расползлась. Каждое обновление данных требовало ручной проверки и правок, из-за чего команда тратила всё больше времени на поддержку таблиц вместо аналитики. По мере роста клиентов начали накапливаться ошибки, а масштабирование напрямую упёрлось в количество людей, которые могли это обслуживать.

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

В качестве инструмента визуализации выбрали Yandex DataLens. Он закрывает базовые задачи по работе с дашбордами и при этом остаётся простым для пользователей без технической подготовки. Также было важно, что сервис доступен в России без ограничений и не требует больших затрат на внедрение и использование.

Всем привет! Меня зовут Сергей Тимакин, мне 22 года, я работаю в Озоне на должности аналитика данных и учусь на первом курсе онлайн-магистратуры «Специалист по работе с данными и ИИ» НИЯУ МИФИ в партнёрстве с Яндекс Практикумом.

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

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

 BI-задачи неплохо подходят для такой проверки ввиду своей разнородности. Дашборд — это не один SQL-запрос и не одна визуализация. Нужно понять бизнес-запрос, уточнить KPI, проверить данные, спроектировать датасет, собрать чарты, собрать дашборд и на каждом этапе обеспечить соответствующие проверки.

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

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

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

 Суть эксперимента: проверить, можно ли сделать переходы между агентами управляемыми на конкретном BI-сценарии: провести задачу от входного запроса до готового дашборда в Apache Superset через команду агентов на multica — open-source платформе управления задачами с канбан доской в стиле Jira/Yougile. В multica можно создавать изолированные рабочие пространства, в каждому свои runtime и набор агентов. При этом задачи канбан доски можно назначить не только человеку, но и агенту: агент получает конкретный issue, в которой видны все его сессии, также через CLI агенту доступны комментарии, изменения статусов, создание новых задач для передачи работы дальше по конвейеру. Таким образом агенты участвует в процессе как исполнитель конкретного шага, так и как координаторы.

Apache Doris 4.1 добавляет UPDATE, DELETE и MERGE INTO на Iceberg-таблицы прямо из SQL-клиента — без отдельного Spark job. Iceberg V3 Deletion Vectors и Row Lineage делают этот DML архитектурно здоровым: нет линейной деградации от delete files, нет false positives в CDC после compaction. Перевод и адаптация статьи Mingyu Chen (CC BY 4.0) с бенчмарками, SQL-примерами и Quick Start.

Если у математиков нет идеального фильтра, тогда у философов нет истины?

В математике есть понятие «фильтр» — это инструмент, который позволяет отделять одни множества от других, выделять главное, отбрасывать лишнее. Но что, если в самой математике нет идеального фильтра? И если так, то что это значит для философии и её вечного поиска истины?

Привет, Хабр! Жизнь не стоит на месте, как и мое исследование, так что пришла пора пересмотреть то, как я оцениваю код.

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

Привет! Меня зовут Ильсаф, я инженер данных в MAGNIT OMNI — бизнес-группе ритейлера «Магнит», которая отвечает за развитие омниканального опыта для клиентов. В этой статье я собрал свои практические наблюдения по работе Kafka Connect и Debezium с PostgreSQL: от настройки репликации до мониторинга и бэкфиллинга.

P.S. Как вам этот тест для глаз?

Каждый год компании по всему миру тратят миллиарды долларов на внедрение BI-систем (Tableau, Power BI, Qlik, Looker). Аналитики Gartner и Forrester упорно твердят, что рынок растёт. Но есть цифра, о которой говорят немногие: до 70% проектов по внедрению бизнес-аналитики так и не выходят в окупаемость.

Почему? Ведь BI звучит как панацея: «Данные — это новая нефть», «Управление на основе KPI», «Дашборды первого лица». Проблема в том, что бизнес путает нефть с бензином, а бензин заливает не в тот бак. Разберем 5 фатальных ошибок, которые превращают BI в дорогую игрушку.

Всем привет! Меня зовут Сергей Тимакин, мне 22 года. Я учусь в онлайн-магистратуре НИЯУ МИФИ в партнёрстве с Яндекс Практикум на программе «Специалист по работе с данными и ИИ» и работаю аналитиком данных в Озоне. В статье рассказываю, как я стал аналитиком, устроился в Озон, зачем пошел онлайн-магистратуру и как я совмещаю учёбу с работой.

$56 млрд за 48 часов

15–17 апреля биржа Grinex — предполагаемый преемник Garantex — была взломана.

В это же время через связанный санкционный кластер на Tron прошло 56 млрд USDT крупными переводами ($100K).

Хак не остановил инфраструктуру. Трафик в отдельные часы — ускорился.

Либо выводили ликвидность. Либо хеджировались. Либо кластер просто продолжал работать параллельно — как работал всегда.

Не смотря на развитие MML, поиск видеоконтента остался на доИИшном уровне. Найти фильм по содержанию невозможно даже на Ютьюбе.

Поисковая проблема поиска видеоконтента сегодня решается не IT-гигантами, а компаниями по производству систем видеонаблюдения.

Давайте посмотрим, что на сегодняшний день есть, и заодно сравним две ведущие в нашей стране фирмы.

Ваши данные врут. Не потому, что кто-то хотел вас обмануть, а потому, что вы им это позволили.

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

Даже аккуратный дашборд может скрывать проблемы в данных, если этап подготовки был сделан формально.

Всем привет!

На одном из проектов я настраивал дашборд в Yandex DataLens, который объединяет данные о трафике из Яндекс Метрики с данными о заказах из CRM и позволяет анализировать доход в разрезе источников трафика.

В этой статье расскажу, как был выстроен процесс обработки данных и к какому результату в итоге пришёл.

Привет, меня зовут Юля, я дата-инженер в департаменте аналитических решений ЮMoney. Мы разрабатываем и поддерживаем ETL(ELT)-процессы загрузки данных для BI-продуктов компании: отчётов, дашбордов, витрин, API и других.

В этой статье поделюсь, как мы разрабатывали MVP для построения data lineage системы и к каким выводам пришли, — так вы сможете адаптировать подход под свои процессы.

Проблема, которая привела нас к разработке MVP, заключается в том, что в начале работы над большинством задач требуется подготовительная аналитика: восстановить путь происхождения данных, чтобы понимать, какие ETL(ELT)-процессы будут затронуты и на что повлияют изменения. Это увеличивает время выполнения задачи. Но, что ещё существеннее, процесс достаточно рутинный: каждый раз необходимо проводить статический анализ кода и изучать документацию (при её наличии). Мы решили автоматизировать эту работу, чтобы иметь под рукой инструмент для построения пути данных по точкам их обработки и применения, — то есть создать data lineage систему.

Мы уже рассказывали, что такое OpenSearch как сервис в Selectel и как легко и быстро начать им пользоваться. Если коротко — это managed-решение, где кластер развертывается за несколько минут, а все заботы берет на себя провайдер: обслуживает кластеры, настраивает СУБД, обеспечивает отказоустойчивость, беспокоится о бэкапах и масштабировании, предоставляет  поддержку.

Но дальше возникает вопрос — как с этим кластером работать? Как настроить мониторинг, визуализировать данные и метрики, работать с бэкапами, управлять пользователями и доступами? Можно, конечно, отправлять curl-запросы к API. Можно подключать сторонние инструменты, вроде Grafana. Но есть способ проще и удобнее — OpenSearch Dashboards.

Привет, Хабр! Меня зовут Сергей Кардапольцев, я технический писатель в Selectel. В этой статье расскажу, как можно упростить работу с кластером OpenSearch с помощью OpenSearch Dashboards.

Привет, Хабр! Меня зовут Макунина Арина, я аналитик и инженер данных в Just AI.

Рутина в работе с качеством данных почти всегда сводится к бесконечному повторению одних и тех же шагов: созданию проверок для новых таблиц и однотипному расследованию инцидентов. И без автоматизации команда может терять слишком много времени на повторяющиеся шаги.

Рассказываем, как с помощью LLM мы превратили рутинные проверки данных в спокойный и предсказуемый процесс и экономим свыше 80% рабочего времени.

Ровно год назад, 22 апреля, вышел Airflow 3, который сильно изменил архитектуру и UX платформы. Но одно из изменений неожиданно ухудшило повседневную работу — Variables: маленькое поле ввода, неудобный JSON и отсутствие нормального редактирования. В статье разбираю, что именно сломалось в привычном сценарии и как я решил это с помощью собственного плагина.