В случае с SEMrush бессмысленно спрашивать «какие языки и технологии использует компания»: здесь каждой команде предоставляют максимальную степень автономности, сводя «общее для всех» к минимуму. А вот конкретную команду вполне есть о чём расспросить.
Мы узнали, что в одном из проектов используют Scala, C++, Spark и ClickHouse. Выбор Scala сам по себе нестандартный, сочетание с C++ можно встретить ещё реже, СУБД ClickHouse от Яндекса тоже не самый распространённый выбор — поэтому мы решили задать несколько вопросов о том, как со всем этим живётся. На них нам ответил Александр Морозов.
— Для начала расскажите, в какой команде вы в SEMrush, и на какой должности?
— Backend developer, команда Maroon, проект Traffic Analytics. Делаем что-то вроде Google Analytics наоборот — всякими хитрыми статистическими методами вангуем метрики сайтов по всему интернету.
— Почему решено было использовать Scala — в связи с тем, что у вас Spark, или и по другим причинам? Существует мнение, что сейчас для использования Spark обычная Java подходит не хуже, а что ваш опыт говорит об этом?
— Если объективно, конечно же, потому что Spark написан на Scala. Java подходит вполне, но когда стандартного функционала начинает не хватать, свои модули удобнее дописывать на Scala. Лично я не совсем представляю, как легко и просто написать имплисит-классы, расширяющие функционал структур Spark — мне бы всяко пришлось тащить скалу в проект.
Ну и да, лучшая документация — это код. Заглядывать в код Spark иногда приходится, и тут без знания языка, на котором этот код написан, никак. Пример из жизни — определить и зарегистрировать в спарке SQL диалект, чтобы он мог через jdbc вставлять данные в ClickHouse. Явно этот момент задокументирован не был, пришлось ковыряться в коде спарка, чтобы понять, где ошибка, и что требуется реализовать для ее устранения.
А если говорить про субъективную сторону — долгая история. Предыдущий опыт работы у меня был в телекомах, оттуда я вынес любовь к акторам, и там же начал интересоваться функциональным программированием: начал с Erlang, потом уже Haskell, а потом и Scala. Scala, как пересечение ООП и ФП, да еще имеющая Akka — выбор очевидный :)
— Поскольку в России Scala используют немногие, хочется расспрашивать: каким оказался практический опыт, что радует, а что причиняет боль?
— В целом меня устраивает лаконичность кода, скорость разработки, количество библиотек (в том числе и тех, которые на Java написаны). После эрланга очень не хватает нормального паттерн матчинга. Не то чтобы боль, но разбираться с ошибками порой проблематично. С одной стороны, имплиситы позволяют писать лаконично и гибко, с другой — иногда трудно понять, что пошло не так даже на этапе компиляции. Тут я, правда, с содроганием вспоминаю, какие портянки выводит gcc на ошибки в шаблонных классах.
Больше всего боли, на самом деле, доставляют чисто инфраструктурные вещи. Вычислительный кластер — достаточно капризная штука. То расчёт упадёт посередине из-за нехватки памяти. То место на каком-то из дисков внезапно закончится. То из-за сетевых лагов в ДЦ нода отвалится. Баги в распределённой системе — вообще отдельный разговор. Диагностировать и устранять такие проблемы — достаточно муторное занятие.
— И у Scala, и у C++ репутация языков «не для слабых духом». Каково живётся с таким сочетанием в одном проекте? Оказывается ли он гораздо «хардкорнее» типичных, сложно ли джуниору в таком?
— Мне кажется, C++ похардкорнее будет. Чего стоит иногда отдебажить «double free or corruption», или утечку памяти. Много чего приходилось делать, включая ручной разбор дампов памяти в hex-editor. В Scala, пожалуй, способов отстрелить себе ногу поменьше будет, хотя своих тонкостей тоже хватает, конечно.
А для джуна иногда труднее всего бывает не писать на С++ в стиле С с классами, а на Scala — в стиле Java со странным синтаксисом :)
— А приходится ли расплачиваться за выбор языков/технологий тем, что технологически-то всё мощно, но вот находить людей на такой проект сложно?
— Безусловно. У нас сейчас как раз открыта вакансия на второго бэкендщика. Но так как проблема найти людей на не самый мейнстримный язык стоит достаточно остро, ищем не прямо 100% совпадение. Вполне подойдёт человек, знающий, например, С++ и Scala. Или Scala/Java и Spark, но без С++. Остальному — научим.
— Перейдём к ClickHouse: а там какими были причины для выбора?
— Нам нужна была база, способная хранить и обрабатывать за приемлемое время сотни миллиардов событий. ClickHouse — та самая база.
— Яндекс произносит красивые слова вроде «в рамках своей узкой ниши у ClickHouse нет альтернатив» — а насколько ваш практический опыт подтверждает подобные слова? Кому можете порекомендовать использовать ClickHouse?
— Ну, мы в своё время всерьез думали о Vertica. Еще у меня был рабочий прототип аналитической части нашей текущей системы исключительно на Spark/Hive, но он требовал много промежуточных «ручных» действий, и в итоге работал значительно медленнее. Скажем так, в каком-то виде альтернативы есть, тут нужно выбирать баланс плюсов и минусов под конкретный проект. ClickHouse отлично подходит для проектов, так и или иначе связанных с web-аналитикой.
— ClickHouse — относительно молодая разработка (по крайней мере, если отсчитывать от перехода в опенсорс). Не мешает ли это? Оказываетесь ли с ней «пионерами», которые набивают шишки и отправляют баг-репорты?
— Иногда ставит в тупик отсутствие, казалось бы, очевидного функционала. Что-то есть в роадмапах на грядущие кварталы. На некритичные баги натыкались, но пионерами не были — все уже были зарепорчены. В целом, основной функционал на месте, баги фиксятся достаточно оперативно.
— Влияет ли как-то на использование ClickHouse то, что он создан в России? Есть ли ощущение, что его разработчики «на расстоянии вытянутой руки», коммуницируете ли с ними?
— У ClickHouse есть русскоязычный Telegram-чат, в котором можно очень оперативно получить ответы на вопросы от разработчиков. Для меня это было приятной неожиданностью: даже в корпоративных продуктах с крайне недешёвой поддержкой диагностика и решение проблемы могут вылиться в недельную переписку «Re[100500]:». Пользуясь случаем, хотелось бы поблагодарить команду Яндекса вообще, и Алексея Миловидова за помощь лично.
— По-вашему, насколько на вашем выборе технологического стека сказалась «независимость команд» в SEMrush, позволяющая «взять и выбрать» нестандартное?
— Думаю, почти никак. Мы не проснулись в один прекрасный день и не сказали себе «а давайте с сегодняшнего дня писать на Scala». Такая незрелость, как разработчика, была бы непозволительной. Сначала у нас был проект исключительно на С++. В какой-то момент написали прототип для исследований, который никак не использовался в продакшене. Однако, написать его получилось так быстро, параллелиться вычисления стали настолько проще, и в разработке получился такой буст, что приняли решение внедрять. По опыту предыдущих мест работы, в более «традиционной» компании процесс был бы аналогичным: написать прототип, дать оценку плюсов и минусов, что называется «продать» его руководству, внедрить. Разумеется, важным условием является обеспечение поддержки и дальнейшей разработки — то есть несколько человек в компании должны быть знакомы со стеком и иметь возможность «подхватить» проект.
— При том, что команда выбирала стек самостоятельно, хочется понять, насколько сказывается опыт «соседей». Когда формировался ваш стек, использовали ли активно его компоненты другие команды в SEMrush, и повлияло ли это на решение?
— Естественно, интересуемся, что там у соседей. Spark использовала R&D-команда, когда она ещё у нас была, для собственных исследований и подсчёта статистики. У них и переняли опыт. ClickHouse начали изучать и внедрять совместно с другой командой, когда встал вопрос о хранилище данных.
— А насколько активно вы сами теперь влияете на других? Часто ли случается делиться внутри компании своей экспертизой в тех же Scala и ClickHouse, и приводит ли это к «о, мы тоже хотим»?
— На Scala еще одна команда писать начала. А ClickHouse у нас вообще, что называется, «зашёл». С другими командами активно общаемся и обмениваемся опытом. Не то, чтобы целенаправленно продвигали, но разговоры в духе «Слышал, у вас кликхаус? А расскажи, мы тоже думаем» возникают регулярно.
isopov
>как раз открыта вакансия на второго бэкендщика
>команда выбирала стек самостоятельно
>Мы не проснулись в один прекрасный день…
Размер команды заинтриговал.
ArchimeD
Команда в разные времена была от четырех, до 6 (сейчас) человек.