YDB — это разработанная в Яндексе распределённая СУБД с открытым исходным кодом, предназначенная для построения высоконагруженных систем. YDB поддерживает одновременное выполнение транзакционных (OLTP), аналитических (OLAP) и потоковых нагрузок и помогает компаниям создавать и обслуживать неограниченно масштабируемые и высокодоступные продукты и сервисы. YDB используется в Yandex Cloud, Практикуме, Маркете, Алисе, Метрике, Auto.ru и многих других проектах. В числе корпоративных клиентов, использующих YDB, — российский сервис для управления бизнесом «Битрикс24» и крупные российские банки.
Разработка СУБД, особенно таких масштабных, как YDB, считается одной из самых сложных и ресурсоёмких задач в IT‑индустрии. Для её решения от программиста требуется большой опыт и разносторонние знания в области алгоритмов, операционных систем и компьютерного железа. Тем не менее у студентов есть возможность внести свой вклад в развитие различных подсистем YDB. Для многих подобные проекты становятся первым серьёзным опытом инфраструктурной разработки и способствуют быстрому старту карьеры.
Меня зовут Виталий Исаев, я занимаюсь разработкой федеративных возможностей YDB — в этой области вклад студентов в развитие YDB чувствуется особенно сильно. В статье я расскажу о том, как в Яндекс Образовании удалось выстроить процесс совместной работы со студентами: они получают ценный, реальный опыт работы над сложным продуктом, а опенсорс‑сообщество YDB — новые фичи. А ещё опишу задачи, которые им приходится решать, и, конечно, поделюсь наиболее яркими их результатами.
Краткий экскурс в федеративные возможности YDB
Федеративными запросами называют SQL‑запросы, адресованные к внешним (по отношению к системе, обрабатывающей такой запрос) источникам данных. Исполняться такие запросы могут либо особыми федеративными СУБД, либо распределёнными движками обработки запросов с федеративными возможностями. В отличие от ETL‑систем федеративные системы не переносят данные внешнего источника в своё внутреннее хранилище для перманентного хранения и дальнейшего анализа, но каждый раз извлекают актуальные данные из внешнего источника, что делает их весьма удобными для оперативного анализа данных.
Потребность в федеративных запросах возникает в сценариях, когда необходимо проанализировать данные, относящиеся к одной предметной области, но распределённые по различным системам хранения. Сегодня в бэкендах веб‑проектов и энтерпрайзе весьма часто встречаются гетерогенные хранилища.
Например, хорошо структурированные пользовательские данные принято хранить в виде таблиц в классических реляционных СУБД, данные с произвольной структурой (например, пользовательская корзина в интернет‑магазине, которая наполняется товарами с разными характеристиками) — в документоориентированных базах, информацию о пользовательском поведении и активности — в оптимизированных на запись колоночных хранилищах, пользовательские сессии и иные «горячие» данные — в in‑memory базах типа «ключ — значение», а логи и информацию для аудита — в S3. Все эти системы хранения очень сильно отличаются с точки зрения используемой модели данных, интерфейса, языка запросов, особенностей системы типов, производительности и стоимости хранения.
В этой ситуации федеративная система может выступить в качестве единой точки входа в гетерогенное хранилище: используя один‑единственный SQL‑запрос, пользователь может извлечь данные сразу из нескольких разнородных источников, консолидировать и проанализировать их.
Конкурентоспособность федеративной системы во многом определяется количеством поддерживаемых источников данных. Такие известные продукты, как движки обработки запросов Trino и AWS Athena, а также аналитическая СУБД ClickHouse, на сегодняшний день поддерживают свыше 30 внешних источников. От них не слишком сильно отстаёт ещё одна аналитическая СУБД — Greenplum. YDB стремится достичь паритета с этими системами и активно расширяет спектр поддерживаемых источников данных.
Добавление поддержки нового источника в YDB сводится к реализации коннектора — особого компонента федеративной СУБД, абстрагирующего движок обработки федеративных запросов от специфики внешнего источника данных. Изначально коннекторы были реализованы у нас в виде С++ библиотек: именно так и была добавлена поддержка S3, Yandex Data Streams и Yandex Monitoring.
Однако по ряду причин («утяжеление» исполняемого файла YDB, увеличение времени компиляции, линковка YDB с кодом сторонних библиотек неизвестного качества, низкая скорость разработки на С++) этот подход был переосмыслен. Новые коннекторы сегодня реализуются в виде отдельных приложений‑микросервисов, с которыми YDB взаимодействует по сети по протоколу GRPC, используя Apache Arrow в качестве формата представления данных. Например, коннектор с открытым исходным кодом fq‑connector‑go поддерживает все популярные реляционные СУБД, а также некоторые NoSQL базы данных.
С более подробным обзором архитектуры федеративных систем и коннекторов к внешним источникам данных можно ознакомиться в моём докладе «Как объединять данные из разных СУБД и делать это эффективно» на Highload++ 2024. А дальше я расскажу, как студенты вузов помогают нам развивать федеративные возможности YDB.
Вклад студентов в разработку YDB
У команды YDB есть возможность привлекать к работе студентов ведущих российских IT‑вузов. Наша миссия — приобщение молодых разработчиков к инженерной культуре Яндекса. Студенты, в свою очередь, приходят к нам для обретения опыта практической разработки, развития гибких навыков, формирования новых контактов и связей. Мы же ценим их не только за вклад в развитие опенсорс‑сообщества и продуктов, но и за свежий и непредвзятый взгляд на наши процессы разработки, которые всегда можно улучшать.
Студенты попадают в YDB двумя путями:
Если они учатся в вузе на программах Яндекса, то могут выбрать в качестве тем своих квалификационных работ (курсовых, дипломов или магистерских диссертаций) задачи, предлагаемые различными сервисами компании, и реализовывать их под руководством экспертов бигтеха. Такой подход внедряют в Яндекс Образовании — обучение ориентировано на практику, а преподают действующие IT‑специалисты.
Они могут прийти на оплачиваемую стажировку с полной или частичной занятостью по программе Young&&Yandex. В случае успешного прохождения стажировки они могут перейти в штат.
Прежде всего, мы стараемся подбирать задачи так, чтобы студент в ходе их решения получил максимально полное представление о профессии. Ведь программиста уже давным‑давно нельзя рассматривать просто как исполнителя, работающего строго по ТЗ. Современный программист — это профессионал с широким спектром технических и организационных навыков. Он может выполнять задачи на любом этапе жизненного цикла ПО — от проектирования решения до его эксплуатации в продакшне. Во всяком случае, так на профессию программиста смотрят в Яндексе, где нечасто можно встретить специально выделенных системных аналитиков, сисадминов или тестировщиков: многие из этих ролей или даже все роли, как правило, сочетаются в одном разработчике.
В связи с этим решение любой студенческой задачи начинается с исследования предметной области. Проектируя новую функциональность или занимаясь разработкой нового алгоритма, студент читает литературу (в том числе white papers), изучает рыночную нишу продукта, над которым он работает, проводит сравнительный анализ конкурентов и тем самым формирует правильный контекст для решения задачи.
Итогом этого анализа становится дизайн‑документ, в котором описывается архитектура предлагаемого решения. Он проходит обязательное ревью у команды разработки. Этот предварительный этап в целом направлен на формирование у молодого программиста правильного способа мышления, который позволит ему в будущем избегать одной из самых досадных ошибок — траты сил и времени на разработку никому не нужной функциональности.
После того как архитектура утверждена, наступает этап разработки. Сам кодинг для студентов, как правило, не является проблемой (хотя некоторые из них в ходе работы над задачей изучают ещё и новые языки программирования). Поэтому мы в большей степени акцентируем их внимание на лучших практиках программирования.
Прежде всего, речь о тестировании собственного кода. Вся разрабатываемая функциональность покрывается интеграционными тестами, для работы которых требуется особое окружение. Студенты учатся конструировать его с помощью популярных DevOps‑инструментов, таких как Docker. Написанные тесты включаются в корпус тестов и регулярно прогоняются в системе CI.
Кроме того, для многих студентов становится настоящим открытием наличие стилевых линтеров в CI. Не имея опыта командной разработки, студенты поначалу воспринимают подобные инструменты как ограничение свободы и нередко пытаются отключить линтер либо игнорировать его замечания. Но в итоге они осознают, что единообразие кодовой базы в проекте с большим количеством разработчиков во многом держится именно «на плечах» линтеров. Если бы не чётко сформулированные стилевые правила, в проекте быстро бы сформировались целые области write‑only‑кода, что крайне неблагоприятно сказывается на развитии проекта в долгосрочной перспективе.
Также в силу highload‑специфики для проектов Яндекса чрезвычайно важна производительность кода. Поэтому студенты достаточно быстро вооружаются различными профилировщиками, осваивают фреймворки для бенчмарков, а ещё учатся писать код без лишних аллокаций и экономить операции IO.
А завершается работа над задачей написанием документации (конечно же, и на русском, и на английском языке). Для работы с документацией в парадигме Documentation as a Code в YDB используется ещё один опенсорсный продукт Яндекса — Diplodoc. Особо заинтересованные студенты могут пойти ещё дальше и рассказать о результатах своей работы на Хабре.
Как итог, в ходе работы над задачей студент пробует себя сразу в нескольких ролях: системного аналитика, разработчика, тестировщика (или, скорее, SDET), DevOps (впрочем, до продакшна студентов мы, конечно, не допускаем) и даже технического писателя. Условно каждый из них последовательно проходит по ступенькам классической каскадной модели разработки. На всех перечисленных этапах студента сопровождает ментор, который координирует его работу и помогает решать разнообразные проблемы.
Почему тема федеративных запросов в YDB идеально подходит для студентов
Начнём с того, что само по себе участие в разработке опенсорсной базы данных, уже получившей широкое признание в индустрии, — действительно редкая удача для разработчика. Однако секрет успеха здесь не только в амбициозности поставленных задач, но и в выстроенном нами процессе их решения.
Опытные программисты знают, что в проекте с многолетней историей больше всего времени тратится не на разработку нового кода, а на его интеграцию в имеющуюся кодовую базу. Проблемы интеграции часто вызывают большие затруднения, особенно в плохо задокументированном легаси‑коде, и могут быстро демотивировать молодого разработчика. Поэтому мы стараемся минимизировать количество интеграционных проблем и формулируем задачи так, чтобы студент мог творчески проявить себя в написании нового кода и при этом не буксовал на интеграции своей разработки в уже сложившуюся систему.
Приходя работать в YDB Federated Query, студент обычно получает типовую задачу на добавление поддержки какого‑то нового источника данных. Так, именно благодаря студентам в YDB уже появилась интеграция с MySQL, MS SQL Server и Greenplum, а также продолжает добавляться поддержка Oracle, MongoDB, Redis, Prometheus и OpenSearch.
С продуктовой точки зрения подобные задачи можно отнести к категориям challenge или nice‑to‑have — мы стараемся не возлагать на плечи студентов критичные для проекта задачи. При этом у них есть чёткие критерии приёмки, а решения включают написание бизнес‑логики на Go (fq‑connector‑go) и С++ (ydb), тестов на Go и Python и, конечно, знание SQL.
Прелесть же предлагаемых нами задач заключается в том, что они являются и творческими, и шаблонными одновременно. С одной стороны, студент может глубоко изучить одну из широко используемых в индустрии СУБД, проявить себя в системном анализе, проектировании архитектуры и написании оптимального кода. С другой — для решения подобных задач уже сложился хорошо задокументированный фреймворк, облегчающий их реализацию и увеличивающий степень переиспользования кода.
Например, в коде fq‑connector‑go чётко обозначена точка интеграции нового кода: чтобы добавить поддержку нового источника, студент должен реализовать интерфейс, инкапсулирующий в себя специфику внешней системы. А всё остальное (например, логика запуска и конфигурации коннектора, сетевое взаимодействие с YDB по протоколу GRPC) заработает «из коробки».
Такая архитектура очень удобна для студента, поскольку он получает возможность сфокусироваться на достаточно изолированной задаче взаимодействия с внешним источником данных. В свою очередь, YDB получает высокие темпы добавления поддержки новых источников и, вследствие этого, интенсивное продуктовое развитие.
А теперь я поделюсь описаниями студенческих проектов, которые вошли в кодовую базу YDB.
Успехи наших студентов
Вот небольшой дайджест основных достижений студентов, которые сделали свой вклад в развитие федеративных возможностей YDB за последние годы. Большая часть их разработок сконцентрирована в Go‑коде сервиса fq‑connector‑go.
Студент МФТИ Максим Цой присоединился к команде на раннем этапе развития проекта и вложился в развитие коннекторов YDB к PostgreSQL и ClickHouse. Основными его задачами были дизайн общего интерфейса и построение гибкой архитектуры, позволяющей легко подключать новые источники. Для реализации MVP ему удалось подключить в качестве источников PostgreSQL и ClickHouse. Максим внёс значительный вклад в логику транспонирования внешних строковых таблиц в блоки Arrow, а также помог с организацией мониторинга сервиса. После завершения стажировки он перешёл в Яндекс Финтех и сейчас, продолжая обучение в бакалавриате, занимает позицию тимлида в одной из продуктовых команд.
Довольно сложно, но интересно было обобщать взаимодействие YDB с гетерогенными источниками данных, например PostgreSQL и ClickHouse. Дело в том, что типы данных с одинаковой семантикой у различных источников сильно различаются в представлении (особенно сложные типы, например время и дата), поэтому мне необходимо было свести все типы к единому общему виду. Но в итоге всё удалось!
Максим Цой
Студент МФТИ, тимлид в Яндекс Финтехе
Студент МГТУ им. Баумана Григорий Папашвили взял на себя задачу интеграции YDB с флагманом мира баз данных — Oracle. Сложность этой задачи лежала не только в технологической, но и в юридической плоскости. Дело в том, что YDB — продукт с открытой лицензией Apache 2.0. А клиентские библиотеки Oracle, необходимые для работы с этой СУБД, распространяются под коммерческой лицензией и зависят на бинарном уровне от проприетарных библиотек, написанных на C. После длительного общения с юристами и бенчмарков выбор был сделан в пользу альтернативной библиотеки с открытым исходным кодом. Сейчас Григорий — разработчик в ML‑инфраструктуре Яндекс Поиска.
Детальный анализ клиентских библиотек достался студенту магистерской онлайн‑программы Яндекса и ИТМО Михаилу Еленскому. Он занимался интеграцией YDB и MySQL. Казалось бы, в Go нет задачи проще, чем работа с реляционными СУБД через интерфейс database/sql. Однако после бенчмаркинга был сделан выбор в пользу не самой популярной и достаточно низкоуровневой библиотеки, которая тем не менее давала отличную производительность в сценариях потокового чтения данных. Сегодня Михаил — старший SRE в Т‑Банке.
Глеб Соломенников, ещё один магистрант ИТМО по той же программе, в рамках курсовой работы добавил в YDB поддержку Microsoft SQL Server. Основным вызовом для Глеба стала необходимость быстро изучить язык Go для написания бизнес‑логики. Однако на этом он не остановился: через год в качестве темы уже дипломной работы он выбрал поддержку Redis. Это сложная задача, требующая интеграции в реляционную YDB источника с моделью данных типа «ключ — значение». Поскольку в качестве значений в Redis могут использоваться композитные типы данных, для решения задачи пришлось детально разобраться в формате Apache Arrow. Глеб успел поработать аналитиком данных в Яндекс Директе, а сейчас он Go‑разработчик в Avito.
Раньше в YDB в качестве внешних источников поддерживались только реляционные СУБД и объектное хранилище S3, которое также может содержать данные с табличной структурой. В рамках моего проекта я придумал, как представить в YDB данные, хранящиеся в Redis в формате «ключ — значение», а также отображать типы данных Redis в систему типов YDB и работать с ними.
Глеб Соломенников
Магистрант ИТМО, Go‑разработчик в Avito
Студентка бакалаврской программы Яндекса и факультета компьютерных наук НИУ ВШЭ «Прикладная математика и информатика» Нина Гулевич реализовала в YDB поддержку документоориентированной MongoDB. Основная сложность этой задачи заключалась в выводе типов колонок таблицы YDB, использующейся для отображения документов из коллекции в MongoDB.
В отношении структуры таблиц YDB ничем не отличается от классических реляционных СУБД: состав, названия и типы колонок жёстко зафиксированы для всех строк таблицы. Иными словами, YDB не является wide‑column store, в таблицах которого в каждой строке может храниться произвольный набор столбцов. Данные в MongoDB, напротив, динамичны по своей природе: в одной и той же коллекции могут храниться документы с набором полей произвольного типа. Поэтому Нине пришлось реализовать алгоритм их схематизации. Также для поддержки пушдауна предикатов запросов (важной оптимизации, позволяющей серьёзно ускорить выполнение аналитических запросов) Нине потребовалось написать транслятор, конвертирующий фрагменты YQL‑запросов, выраженные в терминах API коннектора, в BSON‑структуры запросов к MongoDB. Сейчас Нина — разработчица на С++ в Яндекс Лавке.
Сложнее всего было начать проект: придумать способ представления данных из NoSQL‑источника MongoDB в реляционную модель YDB. MongoDB использует JSON‑подобные документы без строго определённой структуры, поэтому её необходимо вывести или придумать, чтобы YDB смогла с ними работать. Для этого был разработан алгоритм, который по небольшому скану коллекции выводит схему таблицы для YDB, наиболее подходящую прочитанной выборке.
Нина Гулевич
Студентка НИУ ВШЭ, разработчица на С++ в Яндекс Лавке
YDB интенсивно наращивает свою функциональность в самых разных областях, в том числе — в обработке федеративных запросов к внешним источникам данных. При этом, будучи системой с открытым исходным кодом, YDB активно пользуется возможностью привлечения сторонних разработчиков. Коннектор к внешним источникам данных fq‑connector‑go активно развивается за счёт вклада студентов, обучающихся в вузах, в том числе на программах Яндекса. И это выгодно для всех: студенты накапливают опыт промышленной разработки на востребованных задачах, а YDB получает продуктовое развитие.
Поэтому, если вы развиваете технически сложный проект, вероятнее всего, помощь студентов будет не лишней — присмотритесь к такой возможности. А если вы получаете сейчас высшее образование и мечтаете заниматься базами данных (и в целом инфраструктурной разработкой), приходите в YDB писать дипломную работу!
