Data Engineering *

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

Когда классические SQL‑базы падают под аналитической нагрузкой, а Hadoop‑кластер напоминает чемодан без ручки — пора искать новое решение.

В этой статье разбираем, как ClickHouse в связке с NoSQL‑экосистемой закрывает бреши в высоконагруженных проектах. Разберём архитектурные ловушки, Best Practices и честно оценим, где этот инструмент экономит миллионы, а где может создать проблемы.

Немного погрузимся во внутреннее устройство Apache Airflow и разберёмся, что на самом деле происходит за красивым синтаксисом TaskFlow API. Посмотрим, как работают декораторы @task и @dag, каким образом обычные Python‑функции превращаются в задачи Airflow и за счёт какой «магии» строится граф зависимостей. А заодно напишем собственный мини‑пример, чтобы лучше понять архитектурные идеи, на которых построен современный Airflow.

iceberg и его философия metadata расскажем почему iceberg эффективно выполняет запросы и прост в управлении данными благодаря своей metadata

Представьте себе классическую ситуацию: финансовый директор смотрит на два отчета по выручке за прошлый год. Один отчет, построенный в старой системе, показывает 150 миллионов рублей, другой — в новой корпоративной CRM — демонстрирует 145 миллионов. Разница в 5 миллионов, а вместе с ней и ощущение, что новая система «врет» и вводит всех в заблуждение. Начинается поиск виноватых, и, как это часто бывает, крайними оказываются ИТ-специалисты, якобы «неправильно настроившие миграцию».

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

Современные методологии управления данными, в частности Slowly Changing Dimensions (SCD) или «Медленно меняющиеся измерения», предлагают элегантный и проверенный способ справиться с этой иллюзией, превратив хаос непрерывных изменений в стройную, аналитически ценную картину.

Адаптация кода Рида-Соломона (РС) под контроллер esp32-s3. esp32-s3 имеет крайне интересный функционал поддержки работы с векторами. Задача - совместить кодирование РC с векторными возможностями этого микроконтроллера.

Привет, Хабр! На связи Илья Амосов из команды поддержки Lakehouse-платформы данных Data Ocean Nova вендора Data Sapience. В сегодняшней публикации я раскрою тему влияния динамического сокрытия чувствительных данных на производительность SQL-запросов. Мы сравним различные методики маскирования, узнаем, как работает оптимизатор и движок со скрытыми полями, происходит ли деградация пропускной способности платформы, как влияет на производительность выбранный метод сокрытия чувствительных данных в случаях, если вы используете компонент на базе Apache Ranger.

Привет! Меня зовут Катерина Цаплина, я программный эксперт курса «MLOps для разработки и мониторинга моделей», и это вторая статья цикла о том, как компании реализуют MLOps. В предыдущей части мы разбирали, какие архитектурные подходы скрываются за MLOps: от workflow-фреймворков до managed-сервисов и внутренних платформ. 

В этой статье хочу разобрать один из самых известных платформенных кейсов — Michelangelo компании Uber. Он ценен тем, что наглядно показывает, как ML-платформа вырастает из практических задач и затем эволюционирует  вместе с изменением сценариев: от классического ML к deep learning и LLMOps.

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

Привет! Меня зовут Вероника Панайотова, я руководитель практики по управлению инженерными данными в Цифровом СИБУРе. Я расскажу, как мы прошли путь от хаоса разрозненных данных и документов до полноценной системы управления инженерными данными (СУИД) — первой отечественной разработки уровня, сопоставимого с мировыми гигантами в этой области, как AVEVA и Hexagon.

ПО для ПК дорого уже потому, что нужен ПК, да еще и с такой же дорогой видеокартой(ами). ПК проигрывает и в надежности, и в обслуживании, в тысячи раз проигрывает в работе без электропитания.

Спецлаб предоставляет разработчикам Non-PC-based устройство по цене оборудования с возможностью имплантации собственных нейронных сетей – поддерживается семейство ONNX.

FPGA продвинутого типа является универсальным устройством для большого круга задач. В нем есть место и распознаванию объектов, и контролю физических величин, и управлению устройствами, и промтовой логике, и архивам хранения, и аппаратным кодерам с декодерами в рамках разрешения 8К, и всем компьютерным интерфейсам.

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

Как только AI‑агенты начинают участвовать в разработке, быстро выясняется неприятная вещь: проблема не в генерации кода, а в управлении смыслом изменений.

В статье рассказываю, как я перестроил процесс проектирования фич через связку:

— чата с агентом бизнес‑аналитиком;
 — графовой модели изменений;
 — MCP‑доступа к модели;
 — агентского бутстрапа;
 — формализованного техпроцесса.

На примере разработки агентской памяти показываю, как User Story превращается в граф ролей, целей, мотивов, API и зависимостей, а агент перестаёт быть «чатиком сбоку» и становится участником инженерного процесса.

Это не история про «ИИ пишет код».
Это история про то, как инженерное знание начинает работать как код.

На связи Илья Шуйков, руководитель продукта «Фабрика данных» компании Диасофт.

В прошлой статье мы рассказали, зачем понадобилось строить свое объектное хранилище, и как устроен S3 Архипелаг изнутри. Теперь — практика: берем дистрибутив и разворачиваем рабочее хранилище.

В мае 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.

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

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

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

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