Существует миф, что банки — это очень закостенелые структуры, в которых нет места эксперименту. Чтобы опровергнуть этот миф, мы провели небольшое интервью с Валерием Выборновым — начальником отдела разработки лабораторного кластера супермассивов в Сбербанк-Технологиях. У себя в команде они не боятся пользоваться всей мощью Scala, Akka, Hadoop, Spark, и даже пишут прототипы на Rust.

Основные вопросы:

• Обсуждение примера экспериментального проекта (работа с социальным графом) с техническими подробностями;
• Используемые языки и технологии (Scala, Akka, Hadoop, Spark, Rust, и т.п.);
• Можно ли прийти в Сбертех сразу на руководящую должность? Как там внутри всё организовано, какие есть грейды?
• Как живётся простому разработчику? Подробности внедрения Сберджайла;

— Расскажите о себе немного?

— Пришел я в Сбертех почти три года назад, занимался тем, что строил Big Data, принимал участие в построении инфраструктуры больших данных. Работали мы в единой команде, в том числе со специалистами из самого Сбербанка.

Какие задачи нам приходилось решать? Всё что угодно, включая рекрутинг. Сейчас в отделе штатная численность — 47 человек. Я нанял сотрудников, построил работу в отделе. Принял участие в строительстве кластера, разработке пилота и прототипа (это была первая фаза строительства Big Data).

— Откуда ты пришел в Сбербанк?

— Из компании Видео Интернешнл. Занимались мы, по сути, технической поддержкой интернет-рекламы. Делали рекламную крутилку, которая какое-то время там использовалась. Построением там Big Data тоже занимался, участвовал в создании платформы — которая потом отделилась, и до последнего времени была известна на рынке как Amber Data. Cейчас их купила NMG.

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

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

— Вы этим занимались в свободное время? Сколько времени уходило на программирование?

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

— Не скучаете по программированию?

— Наблюдается небольшая ностальгия. С другой стороны, те задачи, которые здесь на более высоком уровне, они тоже достаточно интересные. Управленческие задачи.

— Когда вы занимались программированием, какие задачи больше нравились? У вас же получилось не просто какое-то подразделение, а подразделение Big Data. Это как-то связано с личными предпочтениями?

— Разумеется. В результате развития подразделения и получилось то, что есть сейчас – IT Area разработки приложений Big Data.

— Это что такое, IT Area?

— В Sbergile матричная структура. По вертикали есть «трайбы», по горизонтали — «IT Areas» и бизнес-чаптеры. По сути, IT Area — это группа людей одной IT-компетенции, работающих в разных командах.

— Люди, когда слышат о Сбертехе, им интересны не только конкретные технологии. Тем более что этими технолгиями сложно воспользоваться, потому что у вас они все свои и очень специальные. Давай обсудим хайповые темы, в том числе аджайл. После доклада Германа Оскаровича об этом только ленивый не знает. Вот вы как к нему относитесь (если вообще как-то относитесь)?

— Это сложная тема, есть много интересных проблем. О чём конкретней рассказать?

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

— Конкретно это означает несколько вещей. Например, дебоссинг. Руководители — уже не настолько «руководители» как были раньше.

— «Дебоссинг». Берем босса и его уменьшаем. Устраняем!

— Да :-) Это то, что сейчас происходит. Наверное, это лучше сформулировать по-другому. ИТ-специалисты раньше сидели отдельно от бизнеса, а теперь сидим вместе с бизнесом. Это меняет наши условия работы и какие-то задачи. Мы вместе работаем над пониманием потребностей клиентов и улучшением продуктов.

— На жизни конкретного разработчика это как сказывается? Становятся более строгими правила, или наоборот, мягче, или — что?

— Ни строже, ни мягче. Увеличивается степень ответственности каждой команды и отдельного сотрудника. Некому задать вопрос и не на кого скинуть согласование – ты сам принимаешь решения и сам несешь за это ответственность.

Если до Sbergile ИТ-специалисты сидели в одной локации, в одном офисе, то сейчас даже в Москве они разбросаны по нескольким офисам. Если раньше люди сидели внутри отдела, то теперь они сидят по командам вместе с бизнесом.

— Кто у вас product manager?

— Есть product owner, и если речь идёт о бизнесовых проектах — то обычно, это человек из бизнеса. Он занимается развитием этого продукта, приоритизирует бэклог, помогает решать проблемы, с которыми сталкивается команда. Концепция такова, что команда создаётся вместе с продуктом, на всё время жизни продукта. Раньше команда формировалась только на время проекта.

— Обычному человеку реально перейти из одного продукта в другой продукт? Как дела с Internal Mobility? Например, отработал ты три года на одном продукте, можно как-то от туда…

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

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

— Разумеется, есть эксперты во всех IT area. Если брать их знания, то разрыв между экспертом 12 грейда и начинающим разработчиком 8 грейда — именно такой, о каком ты сказал. Мы стараемся на уровне IT area всячески стимулировать такие процессы. В первую очередь, в виде обмена знаниями, обмена компетенциями. Как раз вчера на эту тему была встреча: на ней решили запустить периодические встречи по основным фазам продуктов, в которых участвует наша IT area. Плюс решили запустить внутренний мессенджинг свой, чтобы стимулировать обмен знаниями и следующий из этого рост компетенций.

— Кстати, как вы смотрите на то, чтобы сделать пару митапов в Москве? Сможете найти туда интересных спикеров с интересными историями?

— Да, смотрим положительно. Спикеры найдутся. Наши спикеры будут участвовать, в том числе, на таких конференциях как JBreak и JPoint. У нас частенько имеются внутренние доклады, но уровнь таков, что с ними можно и наружу выходить.

— Возвращаясь к теме, какая у разработчика прогрессия в компании? Вот ты сказал, 8 грейд — начинающий разработчик. Как он там называется, обычный «инженер», без приставок «старший» и «главный». Какая дальше может строиться карьера?

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

— После 12 грейда есть жизнь?

— Есть 13 грейды — ведущий руководитель направления и эксперт-стратег по разработке. Грейды выше — это управленческие компетенции.

— Мы обсудили Sbergile и организационные вопросы. Расскажи о вашем отделе? Чем вы занимаетесь?

— Мы разрабатываем приложения, которые занимаются различного рода обработкой данных на платформе Hadoop. Map-Reduce, Spark, Hive, и так далее. Ну и ко-нечно, машинное обучение тоже. Мы берем задачи и превращаем в код, который ра-ботает на этих платформах.

— Ты сказал, что у вас IT area разработки приложений?

— Да, IT Area — по сути, объединение людей с одинаковыми компетенциями. Это то, во что в Sbergile превращается «отдел» в Центре Компетенций.

— То есть, вы разрабатываете приложения, автоматизирующие какие-то бизнес-процессы?

— Это приложения, которые просто что-то делают для бизнеса либо для инфра-структуры, прицельно решают для них различные задачи. Возможно, это несколько искусственный термин, обозначающий нашу команду. Вначале так получилось, что у нас есть два больших отдела в центре компетенций, разделившихся по очень простому признаку — основному инструменту разработки. Платформы одни и те же, а язык программирования — разный. У меня это Scala, а у отдела Вадима Сурпина — Java. Его подразделение называется IT area разработки платформы Big Data, а мое — IT area разработки приложений. Но надо понимать, что деление это связано с нашими внутренними вопросами, и обе IT area занимаются приблизительно одинаковыми задачами. Например, мы немного различаемся по бизнес-клиентам: у меня есть «безопасность», а у него — «риски». Но опять же, сейчас эта граница стирается.

— А трайб какой?

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

— Теперь понятно, где вы находитесь в общих координатах: мы поговорили и о горизонтальной оси чартеров, и о трайбах. Теперь давайте немного обсудим технологии. Ты сказал, что вы везде используете Scala. Почему Scala, а не Java? У всех же Java обычно?

— Не уверен, что у всех только Java, есть достаточно большие компании, у которых Scala один из основных инструментов разработки, тот же Тинькофф, QIWI…

— Ну просто в Сбербанке основной инструмент — Java, он везде прописан. А вы взяли и заюзали Scala. Что происходит?

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

— А почему именно Scala? Чем она вам нравится? Чем она хороша для вас как для руководителя отдела, например?

— Во-первых, она совместима с Java, а весь Hadoop, Spark — они все работают на JVM. Это серьезное требование, сильно сужающее набор возможных вариантов. Поэтому, это должна была быть или Java, или JVM-совместимый язык. JVM-совместимых языков не так много. Например, нам интересен был ещё и Clojure, но реально он у нас не взлетел потому, что там есть особенность — на нём сложно писать действительно большие приложения большой командой. Кроме того, Scala была выбрана как наиболее динамично развивающийся язык, предоставляющий нужные нам возможности.

— Там ещё Groovy и Kotlin есть. Что с ними?

— Kotlin тогда, можно считать, ещё и не было, он был в детском возрасте. Groovy был, но Groovy это всё-таки в своем первоначальном предназначении — скриптовый язык, и его применимость для больших проектов вызывала вопросы.

— Вы выбрали Scala потому, что всё остальное отвалилось, дедуктивным образом? Или потому, что у Scala есть какие-то крутые фичи?

— Крутые фичи. Я давно за ним наблюдал, ещё начиная с работы в Билайне. На прошлой работе в Видео Интернешнл подумывал использовать, но тогда ещё не было достаточного предложения на рынке труда. После того как пришёл в Сбербанк, понял, что пора начинать, потому что появилось уже достаточно много специалистов.

— Вы не думали делать какие-то свои мероприятия, посвящённые Scala? Внутри компании, чтобы нести слово Scala в корпоративные массы. Или вообще для всей России.

— Мы думаем, и, скорей всего, будем этим заниматься.

— Каким образом может развиваться программист, условный начинающий разработчик 8-ого грейда, когда ему в руки дали Scala? Что там лучше изучить? Может, какие-то фреймворки…

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

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

— Конечно. Опыт показывает, что даже если человек в совершенстве выучит что-то небольшое, типа как делается JOIN внутри Spark, он сильно продвигается в своих компетенциях вообще, и в восприятии со стороны коллег.

— Помню вашу презентацию в Иннополисе. Там было про социальные графы.

— Да, это было год назад. У нас был проект лабораторного кластера, и был челленж… пилотный проект по Big Data, когда руководство решало, Big Data созрела ли настолько, что её можно у нас использовать, или ещё нужно подождать. И один из прототипов был связан с соцграфом, с которым возникли трудности, на которые пришлось навалиться всем коллективом. Это работа со сверхбольшим графом в интерактиве. Прототип был сделан, и благодаря этому состоялся проект «Лабораторный кластер», он был признан успешным, и после этого началось то, что сейчас про-исходит. Вот такая предыстория.

— Какой там масштаб задачи, и в чём она состоит?

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

— А в чём бизнес-задача?

— Очень простая: поиск людей в социальных сетях для решения проблемных задолженностей.

— Речь идет только о проблемных задолженностях, или есть еще применения?

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

— Насколько большая задача? Грубо говоря, надо десять человек проанализи-ровать, или весь Фейсбук целиком?

— Нет, собственно, вся проблема в том, что граф — большой. Там миллиарды узлов. Значительная часть большой соцсети.

— Вы кроссджойнили между разными соцсетями, или оставались внутри одной сети?

— Там было несколько сетей, и мы пытались сопоставить данные из них.

— Просто если ты используешь какой-то условный GraphQL по Фейсбуку, можно оставаясь внутри него самому делать запросы делать бесплатно. А тут вам пришлось для каждой соцсеточки написать свой адаптер, привести к одному универсальному виду, так?

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

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

— И соцсети, и также участвовала база Сбера.

— То есть она именно «участвовала», а не являлась источником. Была равноправной в этом графе?

— Да.

— Какие данные собирались?

— Данные публичных профилей. Никакой закрытой информации не было.

— Как в целом, оказался ли этот прототип успешным?

— В общем, да. Он был признан успешным, удалось добиться интерактива, был написан пользовательский интерфейс. Когда показали результат и интерфейс — все сказали, что получилось здорово, и нужно продолжать. Но продолжение пока не началось :-)

— А как это технически реализовано?

— Бинарный файл графа формировался из исходников, дальше эти бинарные данные загружались в оперативную память через Unsafe интерфейс JVM. Понятно, что в JVM массив индексируется интом, то есть это два миллиарда максимум, а у нас цифры были сильно больше, и пришлось их вынести в off-heap. Дальше подключили Akka, разработали некую свою модель обмена сообщениями. Похожую на Bulk Synchronous Processing, использующийся в Giraph и HANA. Реализовали распределенный алгоритм Дийкстры, Crauser — Meyer — Mehlhorn — Sanders. На основании него добились очень неплохих результатов по производительности. Как задача выгляде-ла: есть точка A, точка B, найти кратчайший путь в интерактиве (то есть, быстро до-статочно). Интерактива добиться удалось.

— Вы обычно рассказываете про разные алгоритмы, Дийкстру, Bidirectional Shortest Path, итп. Как они используются на этом большом графе?

— Это всё вариации на тему, как найти кратчайшее расстояние между двумя точками, причем как можно скорее. Это решения одной и той же проблемы.

— А как это помогает в поиске людей, которые между собой связаны?

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

— Вот эти «пространства», по которому строится граф, это что — имена-фамилии, или еще что-то?

— «Пространства»? В графе есть вершины и связи.

— ОК, что такое расстояние в этом графе?

— У нас есть рёбра (связи), и у каждой есть вес. Кратчайший путь — это набор ребер между вершинами, у которых наименьший суммарный вес.

— Как определяется вес для ребра? Из чего он состоит?

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

— Эти веса в конце концов редуцируется до одного числа, или остаются в виде вектора?

— Нет, мы ищем путь и смотрим его. Нам нужен путь целиком. Если в задаче нужно схлопывание, его можно сделать.

— Уже несколько раз звучало слово «интерактив». Можете расшифровать, что это такое?

— Это когда перед компьютером сидит человек, ставит задачу, и рассчитывает получить ответ за приемлемое для него время. С задержкой, измеряемой секундами. Максимум, минуту. Понятно, что это отличается от того, как обычно работает Hadoop: там пакетные задания, большие батчи, которые могут часами-сутками крутиться. Важно понимать, что здесь пришлось в сторону уйти от основной парадигмы Hadoop.

— Но отвечает на запросы всё равно Hadoop?

— Нет, Spark здесь используется только для подготовки данных. Он делает бинарный файл, который затаскивается в оперативную память, и дальше уже что работает — в принципе, это тоже можно считать Big Data, но там не используется Hadoop, основное что там использовалось — Akka.

— Hadoop работает интернет-краулером, я правильно понял?

— В общем, да. Он готовит данные, собирает, обрабатывает…

— Вытягивает из интернета и укладывает в ту структуру?

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

— А краулил кто?

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

— Какие-нибудь интересные задачи возникали при реализации всей этой штуки?

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

— Время ожидания в каком сценарии?

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

— А почему от Rust отказались?

— Во-первых, Hadoop написан не на Rust. И нельзя сказать, что полностью отказались, потому что в будущем, возможно мы ещё будем писать на нём. Писать на нём приложения под Hadoop, мягко говоря, неудобно, потому что это не JVM-язык. В данном случае Rust использовался просто потому, что наши сотрудники, которые писали прототип, хорошо владели Rust.

— Всё равно ведь нужно данные получать из хадуповского стека и переклады-вать их в Rust. Как организовать интероп?

— Данные готовит Spark. Приложение на Spark, разумеется, ни на каком Rust не было написано. Оно было написано на Scala. Подготовленные данные перекладываются в оперативную память.

— То есть, они общались между собой с помощью файла?

— Да. Spark генерил бинарный файл, очень большой, и потом это приложение — сначала написанное на Rust, и потом переписанное под JVM, на Scala с Akka — этот файл хватало, засасывало, и работало по нему.

— При переходе с Rust на Scala и JVM, изменилась скорость выполнения?

— Изменилась, но незначительно. На сто процентов точно сказать невозможно, потому что то приложение, которое изначально было сделано на Rust, существовало очень недолго. Это был такой proof of concept. Чтобы убедиться, что этот подход в принципе работает. Никто его толком не бенчмаркил относительно готового приложения на Scala. Стало ясно, что если мы будем делать промышленное решение конкретно этой задачи, мы всё-таки будем делать на Scala, потому что у нас пока нет людей с опытом в Rust. На тот момент уже был вопрос, насколько такие люди доступны на рынке труда. Сейчас эти вопросы тоже остаются, хотя язык развивается весьма динамично, но всё равно, непонятно, насколько доступна эта компетенция на рынке. Тогда мы просто договорились, что раз надо быстро проверить, сделаем вот так, на Rust, а впоследствии переделаем, чтобы другие люди могли прийти и сопровождать, исходя из принятых стандартов по инструментам разработки.

— Ты сказал, что в будущем вы его можете применить снова. Чем он так понравился, что вы его вообще запомнили среди всех этих экспериментов?

— Это некое развитие той же ветки, на которой сидят C и C++. Системная разработка. Но он лишен большинства всех тех значительных проблем, которые имеют C и С++. И более того, у него нет ряда значительных проблем, которые имеют его более современные конкуренты, как например Golang. Лучше производительность, нет оверхеда в виде GC, есть языковые абстракции, позволяющие эффективно делать большие приложения. Если вдруг потребуется делать системную низкоуровневую разработку, то скорей всего, это будет на Rust.

— Если внезапно представить, что специалистов по Rust станет столько же, сколько скалистов. Rust против Scala. Что лучше и когда?

— Вопрос так не стоит, потому что есть Hadoop. Основное для нас, всё-таки, не инструмент разработки, а платформа. Если Hadoop со Spark перепишут на Rust, то тогда, действительно, такой вопрос поднимется. Но пока этого не произошло, и вопроса никакого нет.

— В результате проекта, о котором мы сейчас говорим, что получилось кроме прототипа? Там был какой-то некий FastGraph. Что это такое, можно пару слов?

— Да, было приложение, которое быстро искало кратчайший путь, был написан пользовательский интерфейс (которое называлось, кажется «рабочее место исследователя проблемных активов» — подробней можно спросить Вадима Сурпина). В общем, его сдали в рамках проекта лабораторного кластера. По нему уже было принято решение строить большой промышленный кластер. Руководство решило, что направление Big Data созрело, и его нужно запускать.

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

— Какие интересные технические выводы, решения вы извлекли из всей этой истории?

— Мы поняли, что выбор стека (в том числе Scala в виде инструмента) был сделан абсолютно правильно. Этот инструмент вполне созрел, чтобы использовать его в промышленной разработке, даже в такой серьезной и большой компании как Сбер. Тот проект, что мы изучали, ждёт своего часа — как появится возможность, мы его тут же продолжаем развивать. По сути дела мы поняли, что наш подход правильный.

— Это был такой, бизнес-уровень выводов. А технический уровень? Вы написали систему, которая использует алгоритм Дийкстры на социальных графах, и это ре-ально работает?

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

— А что за подход?

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

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

— Вы принесли туда Akka. Зачем нужна Akka, как она себя зарекомендовала?

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

— Сообщениями обменивается кто и кто?

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

— Распределённость на каком уровне? На уровне машины, на уровне кластера?

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

— Распределённость внутри одной машины означает, что вы прибили шестьде-сят четыре процесса к шестидесяти четырём ядрам, или…

— Нет, процесс один, но использует все ядра. Он многопоточный.

— То есть вы используете джавовые треды. Или вы используете Akka, и она автоматически всё делает?

— Разумеется, мы сами тредами не управляем, это всё на уровне Akka происходит.

— Вот вижу в ваших презентациях термин «коническая модель обмена сообщениями», что это?

— Да, вот эта та самая модель обмена сообщениями. Это некая формализация, которая говорит, как воркеры должны обмениваться сообщениями, чтобы организовать параллельные вычисления. Это аналог Bulk Synchronous Processing — такой термин, использующийся в Giraph и HANA.

— Это её клон?

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

— Ты что-то говорил про PageRank и MPI. Как они вообще относятся к проекту?

— Это были экспериментальные вещи, которые мы сделали в факультативном порядке, чтобы обеспечить полноту фич в прототипе, чтобы в будущем показать это кому-то.

— Понятно. Нам нужно уже закругляться, поэтому последний вопрос. Для тех людей, которые сейчас читают нас на Хабре, есть ли у тебя какие-то напутствия, пожелания, и так далее? Может, вам нужны в команду люди кодить на Scala? Что-то такое.

— Да, нам всегда нужны толковые скалисты, и есть куча интересных проектов, чтобы получить опыт с Big Data и ML. Например, исполнение моделей machine learning в проде. Это тема для отдельного разговора!

— Раз уж коснулись темы найма. Опиши профиль разработчика, которого ты хочешь видеть у себя?

— Разработчик, знающий Scala. Или тот, кто хочет её изучить — но при этом имеющий опыт разработки. Хотелось бы в каком-то виде знание инструментов Big Data, Hadoop, Spark. Специалисты, которые готовые делать задачи по пользовательскому интерфейсу тоже нужны — мы используем ScalaJS.

— Выделенные специализированные математики, data scientist’ы — они вам нужны?

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

— Спасибо, Валерий! Это было очень насыщенное интервью, которое, надеюсь, понравится нашим читателям. Надеюсь, ещё встретимся с вами на наших конфереци-ях, например на JPoint/JBreak/Joker или SmartData. Приезжайте с докладами!

Автор: olegchir

Источник