Data Engineering *

Всем привет! Меня зовут Мурад Арфанян, я разработчик информационных систем в Ozon Tech. Наша команда работает с данными жизненного цикла товаров в логистике. Объём продаж растет стремительными темпами и нешардированный ClickHouse уже не справляется с постоянно увеличивающимися потоками данных. Чтобы решить эту задачу, мы построили шардированный кластер, преодолев на пути несколько интересных технических вызовов. В этой статье я расскажу о нашем опыте и решениях, которые помогли масштабировать систему и обеспечить стабильную работу при росте нагрузки.

Всем привет! Меня зовут Алексей Николаев, я работаю дата-инженером в команде ETL-платформы MWS Data (ex DataOps). Часто сталкиваюсь с тем, что в сложной инфраструктуре и больших проектах простые, на первый взгляд, задачи по работе с данными очень сильно усложняются. В результате возникают ситуации, когда хорошие практики превращаются в плохие решения, а плохие практики как раз могут дать хороший результат.

Мои коллеги уже рассказывали про нашу платформу, ее внедрение внутри экосистемы и наши инструменты для работы с данными. В процессе развития продукта перед нами встала проблема массовых регламентных загрузок данных из реляционных источников. Для этого мы создали внутренний инструмент — библиотеку d-van. В качестве движка в ней используется Apache Spark, с которым она взаимодействует через библиотеку onETL. На примере d-van я покажу нестандартный подход к использованию возможностей Apache Spark. Расскажу, какие задачи можно решить с помощью режима master=local и как свой инструмент может стать альтернативой Apache Nifi или Debezium.

Привет! Меня зовут Наталия Вареник, я DS-инженер в Авито, занимаюсь моделями распознавания изображений. Расскажу про один из наших проектов — пайплайн для распознавания номеров с фотографии свидетельства транспортного средства (СТС). В статье описала особенности задачи и рассказала, как мы решали её с помощью декомпозиции. 

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

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

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

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

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

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

Вчера мой скрипт завис. Процессор горел на 100%. Я убил процесс.

Я Senior Developer с 10 годами опыта. Пишу на Python, знаю Java и много модных фреймворков. Но в этот момент я понял: я не умею программировать. Точнее, я умею использовать инструменты. Но я не понимаю природу вычислений.

Эта статья — о том, как одна математическая задача изменила моё понимание разработки.

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

Возможно, и тебя тоже.

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

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

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

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

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

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

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

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

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

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

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

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

Изобретаем собственный велосипед для детекции AI-generated текстов на Хабре, используя SBERT классификатор. Нет, это не сложно :-)

Всем привет! Меня зовут Александр Токарев, я работаю в 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 являются продолжением её доклада.

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

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

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

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

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

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

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

Привет, Хабр! Меня зовут Екатерина, я практикующий инхаус-юрист с фокусом на IT, IP и рекламе. Недавно я начала экспериментировать с технологией Retrieval-Augmented Generation и векторным поиском в юридических задачах, а также исследовать архитектурные подходы к построению баз знаний в юриспруденции. Этот материал — обзор трёх публикаций о способах построения таких баз, а также моя попытка начать формулировать методологию структурирования юридического знания для RAG. Буду признательна за любой инпут со стороны  ML-специалистов.

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

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

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

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

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

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

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

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

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