Data Engineering *

Сказ о том, как после долгого перерыва я "взял в руки шашки" (поучаствовал в ML-соревновании) и дотащил задачу на "таблички" до первого места на финальном "приватном" лидерборде с помощью простейшей подготовки фич и классической линейной регрессии с регуляризацией, внезапно обогнав при этом всех модных катбустеров, банально переобучившихся на "паблике".

В задаче нужно было предсказать, "доживёт" ли ёлка до определённой даты, учитывая время рубки, наличие дома кота, вес гирлянды, далеко ли от ёлки стоит обогреватель (и есть ли он вообще) и прочие важные и не очень сведения.

Генетический алгоритм как инструмент инженера: практический кейс раскроя полотен

Генетический алгоритм — это «умный» инструмент для автоматизации раскроя материалов (металл, ткань, пластик). Вместо ручного подбора или полного перебора он по принципам естественного отбора ищет компактное размещение деталей, минимизируя отходы. В статье показан практический кейс на Python: как без сложной математики создать алгоритм, который экономит материал, время. Этот подход можно адаптировать под ваши производственные задачи.

В статье рассказывается, как команда интегрировала Qlik с OpenMetadata, создав собственный коннектор вместо использования коробочного решения. Авторы объясняют, почему стандартный подход не обеспечивал нужного lineage и привязки к глоссарию, и как они решили проблему с помощью парсера скриптов Qlik, поддержки include-файлов и доменной модели Business Views. В результате удалось связать дашборды с источниками данных и бизнес-терминами, сократив время поиска отчётов с 2 часов до 2 минут и обеспечив покрытие lineage более чем для 85% приложений. Статья будет полезна тем, кто сталкивается с управлением метаданными в крупных BI-инфраструктурах.

Генерация, понимание и редактирование реалистичных изображений – всё ещё сложнейшая задача для ИИ. Потому качественные данные сегодня на вес золота, а компании готовы тратить миллионы на труд разметчиков и API мастодонтов вроде Gemini Pro Image. Такой подход не только предельно дорог и ресурсозатратен – но и полон ошибок, которых не лишены даже “генеративные ИИ-гиганты”. 

Я хочу рассказать вам о другом, менее популярном сегодня методе сбора визуальных данных – автоматической сборке 3D-сцен и рендере их изображений. Конечно, и этот подход не лишен своих недостатков – но он быстр, дёшев и не так затратен, при этом он покрывает очень тяжёлые для современных моделей ниши. Такой метод позволяет детерминировано понимать и контролировать содержимое генерируемых данных с точностью до миллиметра. В этой статье мы с нуля построим полностью автоматический пайплайн формирования и генерации изображений и метаданных к ним в Blender – для задач генерации, понимания и редактирования изображений. А запускаться и работать он может на чём угодно – от GPU-серверов, до обычного домашнего ПК.

Аналитике редко учат напрямую: как выстраивать аналитическое мышление, находить реальные причины изменений в метриках и выбирать KPI, которые ведут к решениям, а не к «красивым отчётам». Эта статья — о навыках аналитика, которые формируются на практике и чаще всего через ошибки.

Пятничный вечер, бар, шумные разговоры. Мы - компания из нескольких ML-инженеров, DE и DA из Сбера, Магнита, Озона и Альфа-Банка собрались не ради обсуждения задачек в JIRA. Разговор зашел о наболевшем: как найти своих людей и команду мечты? Обсудили зарплату и плюшки, удалёнку и офис, стартапы и зрелые продукты, переработки, карьерный рост и рабочую культуру. В статье - цитаты из обсуждения и обобщённые выводы. А в конце - список вопросов, которые стоит задать на собеседовании, чтобы не ошибиться с выбором и найти тех людей, с кем не страшно будет выкатить релиз в пятницу вечером.

Хочу рассказать о своей разработке и поделиться ей с сообществом habr в виде готового модуля для Python.

Этот модуль решает задачу обновления данных в базе данных. Он выполняет insert/update/delete в одном действии.

Модуль DBMerge проектировался для упрощения ETL процессов по загрузке данных из множества внешних источников в SQL базу.

Для взаимодействия с базой данных используется SQLAlchemy и ее универсальные механизмы, таким образом, разработка не имеет привязки к конкретной БД. (На момент написания статьи, детальные тесты проводились для PostgreSQL, MariaDB, SQLite, MS SQL)

Принцип действия

Принцип действия следующий: модуль создает временную таблицу в базе и записывает в нее весь входящий датасет через операцию массового insert. Далее он выполняет инструкции UPDATE, INSERT, DELETE для целевой таблицы.

Привет, Хабр. Меня зовут Василий Мельник, я product owner решения для потоковой обработки данных Data Ocean SDI в компании Data Sapience. Наша команда приобрела большой практический опыт работы с Apache Iceberg в задачах на стыке традиционной пакетной обработки и near real-time и конкретно с использованием технологий на базе Flink, поэтому мы не могли пройти мимо нового открытого табличного формата (OTF) Paimon от разработчиков Apache Flink. В этой статье я опишу наш опыт и те практические выводы, которые мы сделали на промышленных средах, в виде репрезентативного тестирования, на котором проиллюстрирую ключевые практические сценарии.

Представьте: вы работаете в крупной компании с федеральной сетью. У вас более 300 баз данных Microsoft SQL Server, сотни тысяч объектов — таблиц, процедур, функций, триггеров. Значительная часть бизнес-логики реализована с использованием cross-database references и распределённых запросов через linked servers, что создаёт сложные зависимости между объектами на разных базах и даже серверах.

А теперь представьте, что все изменения в схему вносятся напрямую в production — через SSMS, без версионирования, без ревью, без возможности отката.

Звучит как кошмар? Но именно так работала наша команда более 10 лет.
«Так исторически сложилось» — и это было нормой. Такой подход неизбежно порождал инциденты: от локальных нарушений целостности данных до масштабных простоев, напрямую влияющих на выручку и репутацию компании.

Мы поняли: нужно внедрять CI/CD. Но главная проблема оказалась не в технологиях — а в людях.

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

Современные комплексы бизнес-приложений отличаются высокой сложностью, из-за чего могут происходить сбои - сообщения теряются, consumer’ы падают, очереди переполняются. Поделимся реальным кейсом, в котором Eventual Consistency удалось обеспечить без серьезной переработки существующих систем.

Обеспечение Eventual Consistency в сложных системах

Уже давно стандартом де-факто стали микросервисы, поэтому практически любая система представляет собой набор компонентов, взаимодействующих между собой как синхронно (например, по REST), так и асинхронно — через шины сообщений (RabbitMQ, Kafka).

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

Где именно все может сломаться

Предположим, у нас две системы:

Вас приветствует команда Data Sapience, и в сегодняшней публикации мы расскажем о реализации процедурного расширения для работы с MPP-движками Lakehouse-платформы данных Data Ocean Nova, которое стало доступным для пользователей. В материале пойдет речь о возможностях, применимости и сценариях использования процедурного языка в аналитической платформе данных и примеры реализации решения типовых задач.

Всем привет! На связи практика Business Intelligence GlowByte. Открываем год полезной информацией. 

В 2022 году мы опубликовали на Habr статью про выбор BI-платформы, публикация набрала более 24 000 просмотров. Тогда наш подход был простым: составили большую таблицу сравнения по множеству критериев, поставили баллы — и вуаля, выбирайте лидера.

Четыре года спустя понимаем: такой подход работал для своего времени, но сегодня устарел. В условиях большой неопределенности компании действительно искали универсальные решения "на все случаи жизни". Логика была понятной: выбираем один инструмент, который закроет максимум потребностей на годы вперед.

Но рынок BI созрел. Заказчики стали подходить к выбору осознаннее, исходя не из абстрактного функционала, а из конкретных бизнес-сценариев. И оказалось, что попытка найти "универсальную пилюлю" часто приводит к разочарованию.

Расскажу, как мы в GlowByte пересмотрели методику выбора BI и почему сценарный подход работает эффективнее.

CedrusData Engine — это lakehouse-движок, основанный на Trino. На реальных нагрузках наш продукт рутинно превосходит по производительности другие технологии (Trino, Doris, Dremio, StarRocks) в 1.5-3 раза, с еще более значительным отрывом от устаревших Greenplum и Impala. Эти результаты — следствие постоянных вложений в разработку новейших техник обработки больших данных. В этой статье я расскажу про проект Oxide — одну из наших ключевых инициатив прошлого года по переписыванию ядра Trino с Java на Rust.

В декабре 2025 года VK провёл RecSys Challenge LSVD — соревнование по машинному обучению с нестандартной постановкой задачи. Традиционные рекомендательные системы решают проблему "что показать пользователю", но здесь требовалось обратное: для каждого нового клипа определить, каким пользователям он может быть интересен. Такой подход помогает решать проблему холодного старта контента, когда новое видео только появляется в системе и не имеет истории взаимодействий.

Я принял участие в этом челлендже и хочу поделиться своим решением, архитектурой системы и практическими выводами.

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

Эта статья проведёт вас через классический проект по машинному обучению — анализ датасета Titanic. Мы разберём полный цикл работы: от первоначального знакомства с данными и их очистки до построения и валидации первых предсказательных моделей. Вы узнаете, как преобразовывать категориальные признаки, создавать новые переменные, бороться с пропущенными значениями и оценивать качество моделей через ключевые метрики. На примере Random Forest и логистической регрессии наглядно показываю, как разные алгоритмы решают одну задачу и почему выбор модели зависит от поставленной цели.

Это первая статья из цикла о построении CDC-пайплайна в домашней лаборатории.
Полный путь: Telegram → PostgreSQL → Debezium → Kafka → HDFS → DWH.
Но любой пайплайн начинается с данных — и эта статья про их получение.

Все мы знаем стандартную лестницу: Junior, Middle, Senior. Но где на самом деле проходит граница? Почему в одном стартапе «сеньор» — это тот, кто вчера узнал про LINQ, а в кровавом энтерпрайзе от «мидла» требуют проектировать распределенные системы под нагрузкой в миллион RPS?

Я задалась вопросом оценки собственного грейда, когда уходила со своего первого места работы. Кто я для рынка? Почему мои знания на собесе в одной компании соответствуют чуть ли не уровню Senior, а в другой – покрывают максимум вакансию Junior’a?

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

Я решила отойти от субъективности и спросить у самого рынка. В этой статье — результаты анализа 700+ актуальных вакансий .Net разработчика, графы связности навыков и ответ на вопрос: в какой момент количество выученных библиотек наконец-то превращается в качество инженера.

За двадцать с лишним лет работы в области управления данными я видел всё: от Excel-таблиц вместо MDM до попыток построить Data Governance на коленке. Видел, как компании тратят миллионы на внедрение систем, которые никто не использует. И видел, как правильный инструмент меняет всё: от культуры работы с данными до скорости принятия решений.

Сегодня российский рынок Data Management активно развивается, растёт осознание важности управления данными. Но любопытство берёт своё: а что там, на западе? Какие подходы, какие фишки, какие боли они решают?