Data Engineering *

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

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

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

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

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

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

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

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

Сегодня обзор новой книги по математическому аппарату ИИ — для всех вовлеченных в анализ данных и построение ML/DL моделей. «Базовая математика для искусственного интеллекта» (Essential Math for AI: Next‑Level Mathematics for Efficient and Successful AI Systems) от издательства O'Reilly Media, в переводе от БХВ Петербург — это фолиант на 600 стр. для дата-сайентистов всех уровней. Полезность книги — в обширном материале по мат.аппарату ИИ, собранном в одном месте.

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

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

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

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

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

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

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

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

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

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

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

Как не потеряться в данных для аналитики? 

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

Но что, если данных в компании много, они отличаются сложной структурой и поступают из разных источников? Едут и из MongoDB, и из PostgresSQL, и из MS SQL; при этом постоянно появляются новые продукты и направления, данных становится ещё больше. Документация по ним устаревает примерно в тот момент, когда заканчиваешь её писать.

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

Упростить жизнь в такой ситуации призван Data Catalog, и в Сравни мы выбрали популярный вариант — DataHub. Под катом рассказываем, как меняется работа с данными для аналитики, когда в твоей жизни появляется визуализация потоков данных.

На днях вышла новая версия модели для сегментации видео - SAM2, которая не только стала быстрее выше сильнее предшественника, но и нацелилась поменять разметку видео также, как с картинками это проделала первая версия модели.

Оригинальную SAM мы используем для разметки в достаточно промышленных масштабах (в том числе и для видео), и потому пройти мимо препарирования SAM2 было невозможно, но так как модель уже по верхам разобрали в тг-каналах, пейпер хорош, а то, что модель феноменальна - понятно без слов, то я постараюсь поглубже разобрать подготовку датасета/разметку и саму модель именно на сложных примерах с моими комментариями.

Легкое чтиво и много гифок — самое то для бодрого старта понедельничка!

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

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

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

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

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

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

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

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

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

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

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

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

Greengage Database — наш форк Greenplum Database. Основная идея — оставить исходный код открытым и продолжить разработку и совершенствование базы данных. Мы собираемся перенести Greengage Database на более новую версию Postgres, предоставив более богатый набор функций всем пользователям сообщества и нашим клиентам.

Но эта задача сложнее, чем может показаться. Ранее для реализации функций массивно-параллельных вычислений Greenplum Database основная функциональность Postgres была существенно переработана. Таким образом, обновление версии Postgres создавало огромные сложности. Например, переход с Postgres 9 на Postgres 12 потребовал огромных усилий — между мажорными релизами было почти 5 лет разработки.

Имея это в виду, мы начали масштабный рефакторинг ядра Greengage Database. Мы собираемся разделить ядро ​​Postgres и специфичные функции Greengage Database, используя стандартные существующие средства Postgres для расширений.

В этой статье я расскажу, как можно запустить простой ETL-процесс на виртуальном сервере, используя связку Superset, Airflow и ClickHouse. В качестве платформы я взял готовую конфигурацию от Beget, включающую Superset и Airflow из коробки — это позволяет сосредоточиться на логике обработки данных, а не на настройке окружения.

В качестве примера мы подготовим процесс выгрузки и визуализации данных о товарах с сайта Wildberries.

Для извлечения данных мы будем использовать Python-библиотеки selenium и BeautifulSoup — они хорошо подходят для парсинга веб-страниц. Дополнительно применим re для обработки текстовой информации с помощью регулярных выражений.

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

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

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

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