Знакомство с командой больших данных

Семь человек и десятки тысяч событий в секунду. Groot — корневая система Иви: команда работает с данными, которые нужны для рекомендаций, персонализации и обучения ML-моделей. В этом интервью Вова Петухов, руководитель отдела больших данных, рассказал, как ребята собирают real‑time события, строят сервисы поверх хранилищ, вместе учатся на ошибках, радуются, ходят на каток и придумывают стартапы за обедом.

Чем занимается твоя команда и с каким технологическим стеком вы работаете?

Наша команда — Groot, отдел больших данных. Сейчас в ней семь человек. Мы не только собираем и храним данные, но и разрабатываем сервисы, которые помогают использовать их в продукте. В нашу зону ответственности входит приём большого потока real-time событий: их нужно доставить без потерь и максимально быстро сохранить в аналитических хранилищах.

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

Мы не заменяем рекомендательную систему, а даём ей дополнительный контекст о пользователе. Она использует наши данные и обращается к нашим сервисам, чтобы уточнять рекомендации.

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

Работаем с Java, Go, Python, ClickHouse, Redis, Postgres и Kubernetes. Мы можем использовать любые инструменты, которые подходят нашим задачам, но смотрим и на технологический радар компании: стараемся не тащить новую технологию ради одной узкой задачи, особенно если внутри компании мало кто сможет её поддерживать.

Придерживаемся in-house разработки ключевых для нашего бизнеса систем и сохраняем экспертизу внутри компании. Например, у нас есть свой CDN для доставки видео. Это даёт нам больше контроля над их работой и снижает зависимость от внешних поставщиков. При этом мы учитываем и время команды на разработку, и затраты на дальнейшую поддержку.

Почему команда называется Groot?

В Иви есть традиция брать названия команд и сервисов из кино — так у нас появился Groot. Грут — живое дерево из «Стражей галактики». Мне нравится, что у этого персонажа за немногословностью скрывается гораздо больше, чем кажется на первый взгляд. С нашей работой похожая история: со стороны всё выглядит просто — отправил данные, получил данные. А внутри нужно собрать большой поток событий, ничего не потерять, обработать и предоставить данные разным командам в нужном им виде.

Образ дерева подходит и к тому, как мы взаимодействуем с другими подразделениями: наши корни прорастают почти в каждый отдел компании. Аналитики — наши главные заказчики и потребители данных. Команды рекомендаций, видео и ML используют эти данные для своих метрик и моделей. Ещё взаимодействуем с бэкенд-командами, которые генерируют события, и многими другими.

Главный плюс такого положения — мы видим, что происходит в разных частях компании. Узнаём о новых фичах и потребностях, когда коллеги приходят к нам обсуждать отправку событий и данных. Это позволяет планировать разработку на шаг вперёд. Когда мы видим, что несколько отделов хотят похожих вещей, можем сделать один общий сервис вместо нескольких отдельных решений, экономя ресурсы компании. При этом мы не превращаемся в конвейер — каждый новый проект ставит перед нами новые архитектурные задачи. Это помогает ребятам в команде не заскучать и набираться опыта.

Какими своими достижениями за последний год вы гордитесь?

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

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

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

Как относишься к AI-инструментам в работе?

Мы уже активно используем нейросети. Но прежде чем браться за изменение, всё равно нужно разобраться в задаче и понять, что требуется заказчику.

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

Ещё мы разрабатываем внутренние MCP-сервисы, чтобы аналитикам, менеджерам и разработчикам из других команд было проще работать с нашими сервисами через AI-инструменты.

Как в команде принято отмечать успехи?

У нас нет традиции выкатить фичу и сразу пойти, условно, посидеть в бар. Но раз в квартал мы устраиваем командный день тимбилдинга: идём в компьютерный клуб, на каток, в караоке или ещё куда-то. А иногда можем просто за обедом посидеть, порадоваться тому, чего удалось достичь.

Как в команде относятся к ошибкам?

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

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

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

Главное правило в нашей команде — не переходить на личности. Мы обсуждаем не «кто виноват», а «что мы сделаем, чтобы в будущем такого не случилось». Это наш способ сохранять здоровую атмосферу и расти вместе.

Как стать частью такой команды?

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

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

Как поддерживаешь инициативу и профессиональный рост сотрудников?

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

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

За обедом мы часто обсуждаем архитектуру или фантазируем об очередном стартапе. Старюсь делать так, чтобы у ребят было время вот так вместе подумать о чём-то за пределами текущих задач. Если не даёшь себе фантазировать в жизни, трудно придумать что-то новое и в работе.

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

5 советов, как стать самой крутой командой, от Вовы Петухова, и больше о жизни сотрудников Иви — в телеграм-канале и группе в VK!