Data Engineering *

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

В эпоху повсеместного распространения инструментов на базе искусственного интеллекта (ИИ) вопрос применения доменно-специфичных языков (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 до копейки, а прибыль по артикулам посчитана неверно. Разбираю, почему совпадение «сверху» ничего не доказывает, как устроена сверка двумя независимыми источниками, какие инварианты ловят ошибки по товарам, и где мой движок ошибался: чужая колонка, потерянный знак, файл, который врёт о своём размере.

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

Kwai перенесла расчёт метрик A/B-экспериментов со Spark на Apache Doris: до 145 раз быстрее при снижении потребления ресурсов на 72%. В переводе разбираем, как команда переработала размещение данных, Local Distinct, UDF, планирование и метаданные FE на кластере из 2000 BE-узлов. С примечаниями о границах сравнения и доступности оптимизаций в открытом Doris.

Как устроена платформа данных «АстраЗенека» в России: BI, DWH и Data Lake в одном контуре

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

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

Меня зовут Микаэл Новиков, я главный разработчик в команде ML-платформы MAGNIT TECH. Расскажу, как мы в проекте F&R не смогли оставить data quality без внимания, отобразили результаты проверок в OpenMetadata и попутно наступили на несколько грабель интеграции open source-решения.

Всем привет! Я Аня Мавлютова, технический менеджер продуктов Data Governance в Платформе данных в Т-Банке. Работаю в компании больше девяти лет. Начинала свой путь с дата-инженера, последние три года занимаюсь продуктами, которые помогают нашим пользователям работать с данными многократно быстрее и удобнее. В моей зоне ответственности продукты каталога метаданных Data Detective, инструменты Data Quality и сервис управления разметкой чувствительных данных.

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

В статье расскажу, как мы прошли путь от 11 длительных ручных шагов до автоматизации через AI-агента. Почему отказались от low-code-подхода, как работает распознавание intent и почему выбрали агентскую архитектуру вместо цепочки промптов. Спойлер: решение оказалось смелее, чем мы планировали в начале.