Меня зовут Саша, я уже шестой год помогаю упрощать логистические интерфейсы в Логистике Маркета. Сегодня я хочу поделиться, как с помощью грамотно подобранной архитектуры нам удалось упростить, стандартизировать и даже ускорить разработку мобильных приложений логистики, которых у нас очень много: приложение для курьеров, приложение для пунктов выдачи заказов, приложения для сортировочных центров и так далее.
Переезд большого сервиса с Perl на Golang едва ли кому-то покажется простой задачей. А теперь представьте, что это главная страница Яндекса, на которую ежедневно заходят миллионы пользователей. И что продукт постоянно дорабатывается, а значит, нельзя взять и остановить разработку на пару лет переезда. Представили? Сложно? А вот, оказывается, всё возможно.
Привет, Хабр! Меня зовут Вячеслав Круглов. Я руковожу одной из команд разработки бэкенда главной страницы Яндекса. Расскажу, как мы переписывали бэкенд с Perl на Go, поделюсь интересными подробностями переезда, а также сравню компоненты и продуктовые блоки.
Привет, Хабр! Меня зовут Никита, я занимаюсь iOS-разработкой в Яндекс Диске. Как вы знаете, прошлой осенью зарелизился Swift 6, а вместе c ним появились и строгие проверки для защиты от датарейсов, связанные со Swift Concurrency.
В этой статье я постараюсь разобраться с основными изменениями в каждом пропозале и поделюсь своими заметками, тем, что мне показалось самым важным или интересным. В конце статьи бонус — Playground с тестами для каждого пропозала, чтобы можно было поиграть с кодом, детальнее разобраться с изменениями и понять, как они влияют на код, написанный на Swift 5.
ML‑модели применяются в сервисах Яндекса уже много лет, мы накопили большой опыт в их обучении. Статьи об этом коллеги регулярно публикуют, в том числе на Хабре. Но сегодня хочу обсудить другую не менее важную задачу — ускорение инференса (процесса работы на конечном устройстве) моделей. Скорость зависит от разных условий, главным образом от архитектуры и железа, но есть множество интересных способов повлиять на неё. Особенно актуальна проблема тяжёлого инференса при использовании больших языковых моделей (LLM) — на то они и large!
Для команды YandexGPT, в которой я и тружусь вместе со своими коллегами, тема инференса LLM находится в разряде вечных вопросов. С предыдущей статьи прошёл уже почти год, опыта у нас стало больше — получилось протестировать новые подходы, которыми и хочется поделиться сегодня.
Привет! Меня зовут Олег Кретинин, и я разработчик в команде общих компонентов в Яндекс Еде. Сегодня я расскажу о том, как мы смогли успешно снять нагрузку с нашей базы данных, а также уменьшить её размер.
Помимо сервисов, написанных на C++, Go и Python, у нас есть монолит, он же «кора», на PHP, который всё ещё представляет огромную кодовую базу, хранит кучу логики и предоставляет данные по API для 120 сервисов.
После обновления фреймворка и версии PHP мы принялись за решение другой проблемы, которая всё чаще и чаще давала о себе знать. В тот период у нас возросло количество инцидентов, связанных с базой данных, и нам нужно было что‑то придумать, чтобы стабилизировать проект максимально быстро. Случалось, что всё сыпалось во время праздничных дней, когда количество заказов увеличивалось на 30–40%, или во время разовых массовых операций, например когда однажды в большую сеть ресторанов добавлялся бесплатный соус к каждой позиции меню.
Привет! Сегодня мы выложили в опенсорс Perforator — систему непрерывного профилирования (continuous profiling), которую используем внутри Яндекса для анализа производительности большинства сервисов.
В Github-репозитории доступен исходный код системы и инфраструктура для развёртывания своей инсталляции Perforator на кластере Kubernetes. Кроме того, Perforator можно использовать на своём компьютере как более простую замену perf record: профили получаются точнее, а оверхед меньше. Исходный код доступен под лицензией MIT (и GPL для eBPF-программ) и запускается под x86-64 Linux.
При помощи Perforator и прошлых подходов к задаче профилирования мы регулярно оптимизируем самые крупные сервисы в Яндексе, например Баннерную крутилку или Поиск, на десятки процентов. Кроме того, Perforator реализует недостающий в опенсорсе компонент профилирования для простой автоматической оптимизации программ с использованием profile-guided optimization. Наши тесты показывают, что использование PGO даёт ускорение около 10% в разных сценариях.
Под катом поговорим про профилирование под Linux, опишем вызовы и сложности, возникающие при профилировании, изучим, как устроен Perforator внутри, и обсудим, как можно использовать полученную систему.
Давным‑давно, когда мир ML состоял из бустингов, линейных моделей и статистических подходов, перед нашей командой API Яндекс Карт стояла задача сделать качественный Геокодер. Это алгоритм, который конвертирует текстовые запросы пользователей в поисковой строке карт в координаты и обратно. Он нужен, когда люди вводят адреса с ошибками, опечатками или народными наименованиями, например «Мяснитская 8». Геокодер должен понять, что имелось в виду «улица Мясницкая, дом 8/2», и вернуть на карте отметку с точной локацией и координатами.
Разработанный для России Геокодер отлично справлялся, но мы хотели найти способ быстро адаптировать это решение к адресным системам других стран. Технологические ограничения не позволяли быстро адаптировать решение, поскольку для каждой страны требовалась разработка собственных правил геокодирования, которые бы учитывали различия и языковые особенности. Однако появление и развитие алгоритмов deep learning открыло новые горизонты: методы active learning, аугментации данных и contrastive learning позволяют значительно улучшить итоговое качество геокодирования и учитывать нюансы различных адресных систем.
В этой статье мы рассмотрим основные этапы и методы построения нового Геокодера, который быстро масштабируется на адресные системы разных стран. Расскажем, что у него под капотом, как именно использовались механизмы deep learning при его создании, с какими проблемами мы столкнулись и как научили его понимать адреса с ошибками и опечатками.
Привет, меня зовут Илья Иванов, и я занимаюсь разработкой биллинга в Яндекс 360. Ежемесячно наши сервисы обслуживают 85 миллионов пользователей и более 130 тысяч организаций, обрабатывая свыше 1 миллиона запросов в секунду.
Биллинг в системе сервисов Яндекс 360 — ключевой механизм. Мы не про списание денег, а про то, чтобы пользователь получил доступ к тому, за что он заплатил, максимально быстро и без сбоев. В статье расскажу, как мы спроектировали архитектуру биллинга так, чтобы не быть единой точкой отказа.
Наверное, каждый разработчик рано или поздно задумывается о том, что же происходит в операционной системе на уровне ядра. Для ОС на базе ядра Linux относительно простой точкой входа является написание своих модулей. Модули по своей сути — это драйверы устройств (символьные char device, блочные block device, сетевые network device и другие).
В книге Linux Device Drivers (LDD) подробно описано, как создать свой модуль ядра для интересующего класса устройств. Однако эта книга очень устарела, поскольку в ней рассматриваются случаи, справедливые для ядра версии 2.X.X. А в 2025 году третьему изданию Linux Device Drivers исполняется 20 лет!
На сегодняшний день большинство устройств используют ядра 5.X.X или 6.X.X, в которых многое изменилось. Так и появилась идея этой статьи — адаптировать информацию из LDD под современные ядра.
Под катом рассмотрим следующие классы устройств: char device, block device и network device.
Статические таблицы нужны, чтобы хранить в них неизменяемые данные. Это означает, что данные, записанные в статическую таблицу, нельзя модифицировать в произвольном месте — их можно либо перезаписать полностью, либо дополнить, сделав запись в конец таблицы.
Основная боль при работе с такой таблицей возникает при росте количества хранимых в ней данных. Время чтения или записи возрастает пропорционально её объёму. Из‑за этого может настать момент, когда взаимодействовать с таблицей становится просто невозможно, и пользователям приходится придумывать ухищрения, чтобы справиться с этим.
В этой статье мы разберём механизм мёрджа чанков с помощью мастер‑серверов, который мы реализовали для статических таблиц YTsaurus — нашей платформы распределённого хранения и обработки больших данных с открытым исходным кодом.
Миллионы пользователей ежедневно заходят на Яндекс Маркет. И одна из ключевых задач сервиса — показывать им точные сроки доставки на поиске и в корзине. При пиковых нагрузках это около 40 тысяч запросов в секунду. Как обеспечить столь быструю и точную обработку данных о доставке?
Привет, Хабр! Меня зовут Никита Деревянко. Я руковожу разработкой логистической платформы Яндекс Маркета. Люблю играть в шахматы, бильярд и программировать. Изучаю японский язык, чтобы тренировать мозг и смотреть аниме в оригинале. Расскажу о том, как построить логистический runtime на Go, не являясь Golang-разработчиком. Рассмотрим, как справиться с большим объёмом данных и какие преимущества может (или не может) предложить Golang для масштабной задачи.
Как разработчик я ежедневно сталкиваюсь с большим количеством данных, которые нужны для принятия каких‑либо решений. Логи, конфиги, данные профилирования, аналитические выгрузки из БД и даже сведения о том, когда был написан данный код — это всё данные. Иногда бывает достаточно посмотреть глазами, и картина станет ясной. Но чем больше данных, тем меньше помогает «метод пристального взгляда», и тем нужнее какие‑то инструменты анализа.
Иногда можно собрать нужную информацию, просто скомбинировав несколько линуксовых команд пайпом (cat data.log | grep … | awk … | sort | uniq -c | sort -r | head), иногда пригодятся электронные таблицы, иногда проще написать небольшую программку для анализа данных. Но когда я освоился с языком R и его экосистемой, то всё это стало ненужным.
В этой статье я хотел бы рассказать о задаче, решение которой легло в основу моей дипломной работы. На момент ноября 2023 года я был студентом Физтеха — учился на базовой кафедре Яндекса, программа обучения которой реализуется совместно с ШАДом. Задача заключалась в переводе парсера языка запросов YQL (диалект SQL для YDB и YTsaurus) с ANTLR3 на ANTLR4. Мой наставник в ШАД и руководитель команды разработки клиентских библиотек YDB в Яндексе к. т. н. Алексей Мясников @asmyasnikovотметил еёе как особо сложную. Но меня это не отпугнуло:, тема работы из всех тем, предложенных в ШАД, эта показалась самой интересной и близкой мне.
Привет, Хабр! Меня зовут Асхат, я работаю в Yandex Infrastructure — инженерной команде, которая делает фундаментальные технологии для работы Яндекса. Иногда натренированный взгляд инженера может пригодиться и в личных делах. Позапрошлой осенью на мой День рождения автомобиль Tesla model S сделал мне подарок. Он просто перестал ехать и сыпал ошибками. Утром ничего не предвещало беды, а вечером сел в автомобиль, и на экране замелькало: «Низкое напряжение», «Требуется обслуживание», «Невозможно ехать».
Это превратилось в историю непростого инженерного расследования, отчаяния, поиска очевидных и неочевидных решений. Но всё‑таки дело завершилось новогодним чудом: благодаря моим стараниям машина ожила. Если и вам хоть раз приходилось самостоятельно чинить подобное и хочется побольше историй со счастливым концом — добро пожаловать под кат.
Но осторожно, не пытайтесь повторять это самостоятельно!
Привет! Меня зовут Иван, я разработчик из Яндекс 360. Делаю Телемост — сервис для видеозвонков.
В этой статье я расскажу, как мы тестируем Телемост под нагрузкой, почему нам пришлось разработать для этого свой инструмент и что у него под капотом. Но сперва поделюсь, с какими сложностями в тестировании мы столкнулись.
Привет! Сегодня предлагаю поговорить о том, как мы проверяем, понимает ли YandexGPT специфичные для нашей культуры явления: отсылки к фильмам и песням, цитаты, традиции, анекдоты, мемы. Для нас это очень важная задача, ведь YandexGPT используют такие большие продукты, как Поиск и Алиса, с которыми ежедневно взаимодействуют миллионы людей — она обязана понимать культурные отсылки самого разного уровня.
В статье про бенчмарки для LLM уже упоминался бенчмарк культурного кода. В него мы вложили много сил и души, и думаю пришло время рассказать о нём подробнее — как же мы придумали замерять культурный код, из чего собрали бенчмарк, как тестировали YandexGPT и каким мемам её учили.
Привет! Меня зовут Михаил Мазанов, я отвечаю за технологический стек работы с медиаданными в Кинопоиске: от съёмок оригинальных проектов до доставки и просмотра видео на всех экранах. Для нашей пятой ежегодной конференции про стриминг PlayButton 2024 я готовил большой доклад про оптимизацию качества видео Кинопоиска, а для Хабра решил пересобрать его в виде статьи — для тех, кому текстовый формат предпочтительнее видео.
Кроме технических графиков, вас ждёт ещё и наглядная разница в работе алгоритмов сжатия на примере «Рика и Морти» и «Джона Уика».
YTsaurus — платформа для распределённого хранения и обработки данных. С помощью неё пользователи могут производить вычисления с данными, которые хранятся на кластере. За запуск этих вычислений отвечает один из центральных компонентов системы — планировщик. Зачастую ресурсов кластера не хватает, чтобы одновременно запустить все желаемые вычислительные задачи. Поэтому одна из важных задач планировщика — умение грамотно распределять вычислительные ресурсы между пользователями.
Меня зовут Егор Щербин, я работаю в Yandex Infrastructure, в команде планировщика YTsaurus. О нём и расскажу в этой статье. А также о запуске вычислений в кластере YTsaurus, распределении ресурсов между вычислениями и о том, как управлять распределением, чтобы все операции получали ровно столько, сколько требуется.
Так уж вышло, что раз в несколько лет мы переписываем сервис, отвечающий за диалоговое взаимодействие в Алисе. В прошлый раз мы распиливали монолит на микросервисы, переходили от концепции интента к концепции сценария и улучшали качество классификации. Этот рефакторинг позволил нам научиться горизонтально масштабироваться, ускорил выпуск фичей и дал возможность существенно улучшить качество работы диалогового движка. На этой инфраструктуре мы жили 5 лет.
Совсем недавно мы начали новый виток развития Алисы: мы хотим поместить в самое сердце (точнее, в самый мозг) нашего диалогового движка большую языковую модель. В этом году мы уже добавили в Алису возможность отвечать с помощью LLM на любые вопросы, а теперь взялись за то, чтобы Алиса стала более универсальной и могла выполнять любые задачи пользователя.
Например, пользователь может сказать: «Алиса, выключи телевизор, когда закончится этот матч». До появления смарт‑функций Алиса ответила бы, что «этого пока не умеет», так как подобной задаче её не обучали. Теперь нейросеть сама разложит запрос на два действия — посмотрит, сколько осталось до конца, и поставит таймер выключения на это время. Или если в запросе будут разного типа задачи, например одна про контент, а другая — про звук, Алиса тоже разложит их на понятные для нее части и выполнит: «Алиса, включи первый фильм на громкости 20».
Дальше я расскажу, как мы это собираемся делать.
Привет! Меня зовут Петр Зайдель и я — старший разработчик в Музыке. Вместе с другими ребятами из Яндекса, которые развивают рекомендательные системы в разных сервисах, я в октябре побывал на международной конференции ACM RecSys — 2024 в итальянском городе Бари. Сегодня хочу поделиться с Хабром впечатлениями, трендами и, конечно, обзорами самых интересных научных статей с конференции. Думаю, мой рассказ будет полезен всем специалистам в сфере рекомендательных систем, которые следят за трендами и готовы пробовать в своей работе что‑то новое и интересное.