Data Engineering *

Привет! Я Сергей Кляхандлер, senior DS-инженер в команде LLM Авито. 

В статье рассказываю, как мы разработали ML-модель, которая автоматически генерирует описания для объявлений из категории Одежда и Обувь. Подробно расписываю, откуда мы брали данные для обучения, какую архитектуру использовали и как тренировали модель. А в конце говорю про важную часть работы — фейлы.

Статья будет полезна DS-инженерам, которые работают с мультимодальными LLM-моделями.

Привет! Меня зовут Руслан Гилязев, я работаю в подразделении DS SWAT в Авито, руковожу командой платформы Item2param. В этой статье рассказываю, с помощью каких технологий мы решаем задачу классификации объявлений и почему это важно для бизнеса. Материал будет полезен DS-инженерам любого грейда и backend-инженерам, которые интересуются темой data science. 

В этой статье — без воды, трюизмов, академизмов и формул — разберёмся, в чём принципиальное отличие машинного обучения (ML) от до-ИИ программирования, а затем генеративного ИИ от классических моделей машинного обучения (ML). Поговорим о типах генеративных моделей, их архитектуре и областях применения.
Заодно затронем важный вопрос: где проходит граница между классическим программированием и вероятностным творчеством, на котором построены современные нейросети.
Статья ориентирована прежде всего на тех, кто делает первые шаги в ИИ, но если ты начинающий ML-инженер, архитектор ИИ-приложений, основатель стартапа или просто хочешь разобраться, что на самом деле происходит под капотом у ChatGPT и Midjourney — ты, скорее всего, найдёшь здесь для себя что-то полезное.

Привет, Хабр! Меня зовут Дима Пичугин, и уже семь лет я занимаюсь различными компонентами T Data Platform. Эта статья — результат внутреннего аудита наших инструментов, но я подумал, что она может быть интересна не только нашим аудиторам, но и более широкой аудитории. Enjoy!

Платформа данных в Т-Банке существует более 18 лет и за это время прошла значительный путь эволюции. Она помогает более чем 17 тысячам пользователей извлекать из данных ценную информацию для бизнеса. За последние годы подходы к работе с данными заметно изменились: индустрия постепенно отходила от классических концепций хранилищ данных по Инмону и Кимбеллу в сторону Data Lake, а затем — Lakehouse-архитектур. Вместе с отраслью менялась и наша платформа.

В статье расскажу, как трансформировалась T Data Platform за 18 лет развития, и опишу ее текущее устройство — без погружения в технические детали, но с акцентом на общую архитектуру. Для тех, кому интересны отдельные инструменты или решения, оставлю ссылки на подробные материалы и выступления.

Привет, дорогой друг. Меня зовут Максим и я data-инженер в одной из прекрасных команд AI area компании Домклик. Правильно перевозить байтики с места на место нам помогает огромный зоопарк инструментов. И, кажется, мы приручили ещё одного питомца.

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

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

Всем привет! Меня зовут Саттар Гюльмамедов и я работаю в команде ETL платформы DataOps в МТС. Марк Твен как-то написал «Слухи о моей смерти сильно преувеличены» — про Big Data сейчас можно сказать то же самое. Волна хайпа, которую многие пытались оседлать, прошла. Но, как и значительная часть инженерных достижений, работа с большими данными стала рутиной, помогающей развиваться другим направлениям в ИТ. 

В экосистеме МТС мы строим для Big Data отдельную платформу, где есть инструменты для хранения и оценки данных, анализа и построения отчетов. Но все начинается с их загрузки и обработки. Получение и преобразование данных — как раз задача библиотек и сервисов, которые делает моя команда. Многие знают мем о перекладывании JSON. А мы как раз делаем инструменты для тех случаев, когда такие задачи уже не столь тривиальны и нужно разобраться с разными типами данных, разными структурам, хранящимися к тому же в разных форматах, и все это нужно сделать в рамках одного процесса.

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

Дисклеймер:
чтобы не отклоняться от темы, я не буду подробно описывать концепции ETL и ELT (они хорошо разобраны тут, тут и тут). Наши инструменты следуют парадигме «E[TL]+», т. е. позволяют выполнять трансформации данных как в процессе переноса, так и в целевом хранилище.

Про нашу платформу в общих чертах писал мой коллега Дмитрий Бодин в своей публикации «Customer Happiness: как не только разработать, но и внедрить новый продукт внутри крупной компании». Я продолжу начатый им рассказ и добавлю подробностей о компоненте ETL, его составляющих и нашей команде.

Как связаны скидки, пользовательские пути и огромные массивы данных в Яндекс Рекламе? 

Привет, Хабр! Меня зовут Максим Стаценко, я работаю с базами данных и яростно в них копаюсь с 2010 года, а в Big Data — с 2016. Сейчас работаю в Яндексе в DWH поиска и рекламы.

Мы работаем с ОЧЕНЬ большими данными. Каждый день миллионы пользователей видят рекламу Яндекса, а наши системы обрабатывают огромные объёмы данных. Чтобы реклама работала эффективно, нам нужно в каждый момент времени иметь максимально полную информацию об истории жизни рекламного объявления, а значит нужно каким-то образом передавать данные от одного события к другому внутри рекламной воронки. Расскажу, как мы решали эту проблему.

Всем привет! Меня зовут Александр Токарев, я работаю в Yandex Infrastructure и занимаюсь интеграцией Apache Spark (далее просто Spark) с YTsaurus. В этой статье я расскажу про то, как мы сначала форкнули и пропатчили Spark, а потом вернулись к использованию оригинальной версии и поддержали совместимость с множеством других версий.

YTsaurus — это разработанная Яндексом система для хранения и обработки больших объёмов данных. Она активно развивается с 2010 года, а в 2023 году была выложена в опенсорс. Подробнее почитать про историю создания и выход YTsaurus в опенсорс можно в статье Максима Бабенко.

В какой‑то момент мы решили подружить YTsaurus и Spark. Так и родился проект SPYT powered by Apache Spark (далее просто SPYT), который активно развивается с 2019 года. Основательница проекта Саша Белоусова уже рассказывала, как были реализованы SPI Spark для работы со структурами данных YTsaurus — это набор классов, интерфейсов, методов, которые мы расширяем или реализуем. Во многом эта статья и моё выступление на HighLoad++ 2024 являются продолжением её доклада.

Привет, на связи Светлана Морозова и Сергей Кляхандлер из команды data science Авито. Рассказываем, как у нас устроен рост сотрудников, поговорим и о особенностях этого процесса в big tech-компаниях в целом и в Авито в частности. Статья будет интересна всем, кто хочет развиваться в профессии или просто ищет работу в направлении data science.

Привет, Хабр! Меня зовут Алексей Быков, я занимаюсь развитием cloud-native-платформы для обработки данных Arenadata One (AD.ONE). В этой статье мы поговорим о neon-kubernetes-реализации PostgreSQL, её устройстве, особенностях и о том, почему классический подход к Postgres в Kubernetes не позволяет в полной мере использовать преимущества гибкой облачной инфраструктуры.

Тема не новая и активно развивается: уже давно существуют операторы (Zalando, Crunchy Data, CloudNativePG) для автоматизации развёртывания Postgres в Kubernetes. Однако они сохраняют монолитность базы, когда данные по-прежнему жёстко связаны с узлами, а горизонтальное или вертикальное масштабирование требует ручной настройки и остаётся непростым процессом. Подход Neon основан на полном разделении вычислений (compute) и хранилища (storage), что даёт нам возможность взглянуть на использование PostgreSQL в облаке по-новому, как на сервис с возможностью динамического масштабирования, мгновенного запуска инстансов, изолированных веток (branching) и других возможностей без необходимости в сложной инфраструктурной обвязке.

Готов поспорить вы слышали о стандартном отклонении или кто то из колег упоминал его в разговоре (чтобы показать какой он умный и поставить вас на место). Звучит похоже на умственное отклонение, но интуиция подсказывает вам что возможно разговор тут совсем про другое? Ваша интуиция совершенно права. Настало время поставить коллег на место и разобраться что же это такое.
Вот объяснение, которое даже ваша собака сможет понять.

Несколько лет назад наш корпоративный слой данных жил на проприетарных технологиях. Данных было много, а основная СУБД — MPP-система Sybase IQ — долго не обновлялась. Мы регулярно сталкивались с тем, что у кластера «падали» ноды, каталог базы повреждался, порой даже терялись данные, а вендор не спешил выпускать исправления или даже признавать проблему. ETL-процессы работали через IBM DataStage, который также перестал развиваться. Все решения были закрыты, и мы не могли влиять на их улучшение. Vendor lock-in означает, что вы зависите от поставщика: если вендор не поддерживает нужные возможности, развитие замедляется, а долгоживущие ошибки остаются нерешенными. Такое положение становилось критичным.

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

В этой статье рассказываем о том, как мы перешли с проприетарных ETL-инструментов на open-source на базе dbt, какие проблемы решали по ходу внедрения, и как построили экосистему вокруг dbt для автоматизации рутинных задач.

Привет, Хабр! Я Георгий Новожилов, инженер данных в «ДАР» (ГК «КОРУС Консалтинг»).

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

22 апреля 2025 года компания Apache выпустила новую версию своего оркестратора, которая была в разработке последние 4 года. Среди ключевых изменений — новый интерфейс, обновлённая и защищённая архитектура, а также стабильный интерфейс разработки.

В этой статье предлагаю рассмотреть, какие ещё нововведения нам привезли в масштабном обновлении Apache Airflow 3.0.0.

Pandas — это основная библиотека для работы с данными. Вот несколько приёмов, которые я использую, чтобы быстрее и проще выполнять повторяющиеся задачи по работе с данными.

Всем привет! Меня зовут Константин Малолетов, я архитектор облачных сервисов в компании Arenadata. Сегодня хочу рассказать, как мы решаем задачу эффективного размещения ресурсоёмких систем, таких как Arenadata DB, в облаке.

В статье рассмотрим несколько сценариев использования вычислительных ресурсов и их влияние на работу ADB, а также поделимся результатами проведённых тестов.

Представьте, что вам нужно объединить две базы данных с информацией о клиентах, каждая из которых содержит несколько миллионов записей. В них есть ФИО, паспортные данные, СНИЛС, даты рождения, адреса и другие данные. Ваша задача — найти все похожие записи и не допустить ошибочных объединений. 

Причем данные могут содержать ошибки, опечатки операторов или неверные транскрипции. Для полной сверки каждого с каждым потребуются триллионы операций сравнения. И вишенка на торте — братья-близнецы с редкими, но созвучными именами. Даже оператор может решить, что это дубль, и объединить их записи.

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

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

Retrieval‑Augmented Generation (RAG) — это архитектурный подход к генеративным моделям, который сочетает навыки поиска информации с генеративными возможностями больших языковых моделей (LLM). Идея RAG была предложена в 2020 году, чтобы преодолеть ограничение LLM — замкнутость на знаниях из обучающих данных. Вместо попыток «вживить» все знания в параметры модели, RAG‑подход позволяет модели запрашивать актуальные сведения из внешних источников (баз знаний) во время генерации ответа. Это обеспечивает более точные и актуальные ответы, опирающиеся на факты, а не только на память модели.

В этой статье мы подробно рассмотрим: архитектуру RAG, её компоненты и этапы работы, современные инструменты и практики для реализации RAG, примеры кода на Python, кейсы применения в бизнесе и науке, технические вызовы и лучшие практики, сравнение RAG с классическим fine‑tuning, перспективы технологии.

Когда в проекте используется составной B-tree индекс, важно не просто "создать индекс", а сделать это правильно — иначе запросы могут не только не ускориться, но и начать работать медленнее. Возникает логичный вопрос: как выбрать порядок колонок, чтобы индекс действительно работал эффективно? Брутфорсом? По интуиции? По селективности?

В этой статье я расскажу, как подходить к построению составных индексов в PostgreSQL, на что реально влияет порядок колонок. Также разберём простое правило ESR, которое помогает упростить выбор и получать стабильный прирост производительности на всех стендах.

Привет, Хабр! Когда-то я проверяла завещания и готовила доверенности, а теперь проверяю витрины данных, ищу дубли и считаю доходность по инвестиционным инструментам. Меня зовут Арина Шахтарина, и я — Data Quality-инженер в Сбере. Это история о том, как любовь к данным и таблицам превратилась в новую профессию, и почему SQL — лучший универсальный язык после русского. Тут будет про карьерные повороты, боли с форматами данных, проверки данных и немного про мечты, которые сбываются (даже если ты не в отпуске).

Меня зовут Вера Романцова, я работаю в 2ГИС в команде компьютерного зрения. Мы создаём ML-модели и сервисы, которые автоматизируют работу с картами и данными. 

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

В этой статье я расскажу:

🌚 Кто такой менеджер данных и чем он занимается.

🦾 Как эта роль помогла нашей команде ML-инженеров.

🔜 Когда такой специалист может понадобиться вам.

🔎 Как найти подходящего кандидата на эту позицию.