Welcome to Spark… on Java: Интервью с Евгением Борисовым
В 2012 году увидел свет фреймворк Apache Spark, разработанный на Scala и рассчитанный на повышение производительности определенных классов задач в работе с Big Data. Проекту уже 4 года он повзрослел и дорос до версии 2.0, к которой (на самом деле уже начиная с версии 1.3–1.5) имеет мощный и удобный API для работы с Java. Чтобы понять, для кого это все надо, какие именно задачи стоит решать при помощи Spark, а какие не стоит, мы поговорили с Евгением EvgenyBorisov Борисовым, автором тренинга «Welcome to Spark», который пройдет 12–13 октября в Петербурге.
JUG.RU: Евгений, приветствую! Давай с начала. Расскажи вкратце, что такое Spark и с чем его едят?
Евгений: Прежде всего Apache Spark — это фреймворк: некий API, позволяющий обрабатывать Big Data неограниченным количеством ресурсов, машин, самостоятельно масштабирующийся. Чтобы Java-разработчикам было совсем понятно, представьте себе старый злобный JDBC, при помощи которого можно общаться с базой данных: что-то из нее читать, что-то в нее писать, — так и Spark позволяет что-то писать в базу и читать, но ваш код будет неограниченно масштабироваться.
И тут возникает резонный вопрос:, а куда можно писать и откуда можно писать? Можно писать в Hadoop, можно работать с HDFS, можно с Amazon S3. Вообще, есть очень много распределенных хранилищ, и для многих уже написан API для Spark, для других пишется. Например, у Cassandra есть свой инструмент для этого, DataStax называется, который дает возможность писать Spark с Кассандрой. В конце концов, можно и с локальной файловой системой: хотя тут это получается не нужно (масштабироваться некуда), обычно эта возможность используется для тестирования.
Информации с каждым годом накапливается все больше и больше, соответственно, возникает желание обрабатывать ее неограниченным объемом ресурсов
JUG.RU: Получается, Spark крутится на распределенной инфраструктуре. Это значит, что проект больше enterprise-класса, или в принципе его можно использовать и в каких-то личных проектах?
Евгений: Сегодня это скорее энтерпрайзный фреймворк, но Big Data распространяется сейчас такими темпами, что скоро без нее будет вообще никуда: информации с каждым годом накапливается все больше и больше, соответственно, возникает желание обрабатывать ее неограниченным объемом ресурсов. Сегодня у тебя информации мало, и есть код, который только ее обрабатывает, а когда накопится больше, придется все переписывать. Так? А если все изначально обрабатывалось на Spark, то можно просто кластер увеличить на несколько машин, а код вообще не надо менять.
JUG.RU: Ты говоришь, что Spark — это все-таки enterprise-класс. Вот важный вопрос, а как обстоят дела со стабильностью и обратной совместимостью?
Евгений: Поскольку Spark написан на Scala, а у Скалы с обратной совместимостью все достаточно плохо, то Спарк тоже от этого немного страдает. Бывает, ты обновился, и какая-то функциональность вдруг отвалилась, но это происходит в значительно меньшей степени, чем в Scala. Все-таки API здесь намного стабильнее и все не так критично: «поломки» обычно решаются локально, точечно.
Сейчас вышла вторая версия Spark, она выглядит очень классно, но пока я не могу сказать, насколько там все развалилось, глобально на него пока никто не перешел. К тренингу я успею подготовить какую-то обзорную тему и показать, что изменилось, обновилось.
Тут стоит добавить, что несмотря на то, что сам Spark на Scala написан, а я небольшой сторонник того, чтобы на Scala писали те, кто ее не знают. Меня часто упрекают «вот, мол, ты наезжаешь на Scala». Я не наезжаю на Scala! Я просто считаю, что если кто-то Scala не знает, но хочет писать на Spark«е, то это не повод учить Scala.
JUG.RU: Окей, решили, что в принципе-то под Spark лучше писать на Scala, но если не можешь в Scala, то можно и на Ja…
Евгений: Нет-нет-нет! Я не сказал, что лучше писать на Scala. Я сказал, что люди, которые хорошо знают Скалу и пишут под Spark на ней — это совершенно нормально.
Но если человек говорит: «Вот, я Scala не знаю, а мне надо писать на Spark потому что я понял, какая это крутая штука. Только мне что, теперь надо Скалу учить?» Я говорю, что в этом нет совершенно никакого смысла! И мне было забавно почитать комменты людей, которые писали «вот мы пытались писать на Java, так как мы Скалу не знали, а Джаву знали, но потом все стало так плохо, что в итоге на Scala все-таки пришлось перейти, и теперь-то мы счастливы».
Сегодня это совсем не так: это было бы верно, если бы мы говорили о Java 7, а Спарк был старый, еще с RDD, — да, тогда действительно выходили такие трехэтажные структуры, которые было совершенно невозможно понять.
Сегодня, Java — восьмая, а в Spark«е появились датафреймы (с версии 1.3 еще), которые дают API, которому без разницы на чем запускать: на Scala, на Java, — можно прекрасно жить без Скала.
Сегодня, Java — восьмая, а в Spark«е появились датафреймы (с версии 1.3 еще), которые дают API, которому без разницы на чем запускать: на Scala, на Java, — можно прекрасно жить без Скала.
JUG.RU: Если я умею писать на Java 8, какой порог входа у меня будет для Spark? Придется ли мне много чего учить, читать умные книжки?
Евгений: Очень низкий, особенно если вы уже имеете практический опыт с Java 8. Взять вот стримы восьмой джавы: там идеология очень похожая, даже большинство методов называются так же. Можно самому начать и разобраться.
Тренинг нужен скорее для того, чтобы разобраться со всякими тонкостями, хитростями и нюансами. Кроме того, поскольку тренинг будет для Java-разработчиков, я буду показывать, как можно все кастомизировать при помощи Spring«a, как можно написать при помощи него инфраструктуру, чтобы связанные с перфомансом фокусы Spark можно было делать при помощи аннотаций, чтобы все работало само «из коробки».
JUG.RU: Везде пишут и говорят о том, что Spark прекрасен для работы с Big Data, и это понятно. А вот вопрос, который звучит уже не так часто: для чего Spark не подходит? Какие есть ограничения и под какие задачи брать его точно не стоит?
Евгений: Точно нет смысла брать Спарк под задачи, которые не масштабируются, в том смысле, что если задача по своей идеологии не масштабируется, то Spark тут ничем не поможет.
Как пример: оконные функции, несмотря на то, что в Sparke они есть (вообще, на Spark можно все делать), но работают они реально медленно. Со временем и тут должно стать лучше, они в этом направлении двигаются.
JUG.RU: Вот это кстати хорошая история, куда двигается Spark? Понятно, сейчас уже можно какие-то данные процессить быстро и хорошо.
Евгений: В первом Спарке был RDD (Resilient Distributed Dataset), который дает возможность обрабатывать данные при помощи кода. Так как данные обычно имеют column-based структуру, а тут получается, что к названиям колонок ты обратиться не можешь, в API RDD такого просто нет. И если у тебя файл с огромным количеством столбцов и огромным количеством строк, а ты пишешь логику, которая все это обрабатывает, то получается очень нечитабельный код.
Датафреймы позволили данные обрабатывать c сохранением структуры, используя названия колонок: код стал намного более читабельным, людям, знакомым с SQL стало совсем хорошо в этом мире. С другой стороны, стало не хватать возможности более тонкой настройки логики.
В итоге получилось так, что определенные вещи стало удобно делать при помощи RDD, а какие при помощи датафреймов. Второй Spark это все дело объединил в структуре, которая называется DataSet, и в ней можно и так работать, и так, не выходя и одного API. Плюс к этому все стало намного быстрее работать. Соответственно, если говорить, куда движется Spark, то можно сказать, что они делают множество различных оптимизаций, и фреймворк работает все быстрее и быстрее.
Фреймворк работает все быстрее и быстрее
JUG.RU: Понятно, движение в сторону скорости и гибкости. Тут самое время спросить про инфраструктуру: какие инструменты работают со Spark? В докладе на JPoint ты подробно рассказываешь, что можно работать с Hadoop, можно без Hadoop и так далее.
Но вот в комментариях к прошлой статье прозвучало мнение, что Spark без Yarn это моветон и никакого нормального управления ресурсами там не получить.
Евгений: Не соглашусь с этим мнением. Давай сначала посмотрим на то, как это запускается: есть что-то, координирующее работу worker«ов, на которые рассылается наш код, запускающийся параллельно. Так вот Yarn, конечно, координирует все это намного быстрее, а еще он умеет мониторить состояние worker«ов и, если надо, их перезапускать. Но можно работать и без Yarn«а, если надо. Есть Spark Standalone, который, конечно, медленнее и не такой мощный, но, кроме этого, есть еще альтернативы: Apache Mesos, и пилят сейчас еще новый. Я уверен, лет через пять их будет полно, далеко не все на YARN завязано. Тем более для распределенных хранилищ тоже есть куча инструментов, как я в начале уже говорил.
JUG.RU: С теорией более-менее разобрались. Для чего Спарк не нужен, тоже понятно. А можешь привести примеры применения Spark из своего опыта? Наверняка в области Big Data что-то интересное находилось.
Евгений: Насчет «интересного» не знаю, все-таки я в основном enterprise-проекты внедрял, там прикольного немного. Другое дело, что писать было интересно, быстро и удобно.
Из интересных кейсов могу вспомнить сервис для телефонных компаний: представь, ты прилетел в другую страну, не стал менять симку, и нужно выбрать роуминг. Как он выбирается, на основании чего? Дешево, дорого, выгодно, невыгодно — для того, чтобы подобные решения принимать, телефонные компании должны все свои данные анализировать: каждый звонок, кто, кому, куда, откуда звонил, хорошая ли была связь — все фиксируется. Конкретно этот проект обсчитывал такие данные по всем звонкам по всему миру: анализировал это все и выводил разные статистики.
Второй пример — компания Slice. Есть люди, которые открывают доступ к своим почтовым ящикам, чтобы из почты анализировать какие-то покупки, заказы, билеты и прочее, чтобы лучше таргетировать рекламу и получать какие-то предложения. Тут, опять же, есть обработка дикого количества писем, они все это хранят в Redshift«e на Amazon«e: все нужно структурировать, обсчитать, как-то еще быстро процессить, чтобы тоже выдавать какую-то статистику, на основе которой клиентам уже давать направленную рекламу или рекомендации. Тут Spark мы прикручивали для улучшения перфоманса, без него все работало очень медленно.
JUG.RU: Spark данные в реалтайме процессит?
Евгений: И в реалтайме можно, и batch«ами.
JUG.RU: Понятно, а что насчет валидации данных? Какие-то инструменты, упрощающие проверку данных на целостность или корректность есть?
Евгений: Ну это все решается на уровне кода: ты берешь миллион строк кода и первое, что ты делаешь — выкидываешь невалидные. По ним, кстати, обычно собирается статистика: много ли таких данных, почему они некорректны, — это тоже делается Spark«ом.
JUG.RU: Напоследок не могу не затронуть еще раз вопрос «Java vs Scala в Spark». Даже больше из любопытства. Ты на чьей стороне?
Евгений: Я тут скорее встану на сторону Java, хотя меня многие за это не любят. Меня можно понять — я пятнадцать лет писал на Java, несколько лет писал на Groovy, который, конечно, является следующим шагом по сравнению с Джавой, но с выходом восьмой версии Java все стало не так однозначно. Сейчас, начиная новый проект, я каждый раз думаю, начинать мне его на Java 8 или на Groovy.
А вот Scala — это вообще другой мир! И в нем сложнее разбираться, как в инструменте. Каких-то макропаттернов там нет. Был период, когда я должен был писать на Scala — я ужасно страдал. Естественно, когда ты страдаешь, ты идешь к другим людям советоваться. Советуешься с одним человеком, как архитектуру построить, он говорит одно. Спросишь другого — получаешь совершенно иной ответ! В мире Java все намного более ровно, намного больше опыта, больше людей, коммьюнити: у меня есть сервисы, у меня есть дао, у меня есть dependency injection, есть Spring, для этого есть Spring Data или, там, Spring MVC, — выбрасывать всю эту тонну информации, которую люди собрали, и переходить на Scala, учить все с нуля? Зачем? Если на Java все работает не хуже. Я понимаю, если бы на Scala работало в два-три раза быстрее, или API был бы в 10 раз удобнее, я бы согласился поучиться год-полтора.
Вспомнился забавный случай. Во Львове ко мне после доклада подошел человек и говорит:
— Слушай, ты ведь Scala не любишь, а?
— Я этого не говорил, — отвечаю.
— Ну чувствуется же.
— Ну, я просто считаю, что для проекта, в котором уже есть Java-программисты, тратить время, чтобы переводить их на Scala нет смысла.
— А ты сам на Скале писал?
— Ну писал, немножко.
— Сколько?
— Полгода где-то.
— Ха, полгода… За полгода ты не мог Scala понять! Надо хотя бы года два-три.
Вот в тот момент я понял, что я был совершенно прав. Вот где порог входа высокий, на уровне 2–3 лет. Ведь вопрос не в том, хороший язык или плохой. Правда в том, что если вы умеете писать на Java — пишите на Java, со Spark, во всяком случае, это легко и просто. Все реже у разработчиков на моих проектах возникают ситуации, когда они ищут какие-то решения в Google и на Scala находят, а на Java нет. Раньше такого было много, а сейчас практически нет.
Собственно, еще раз скажу, что миссия Scala не так давно изменилась: вместо того, чтобы пересадить разработчиков на Scala (чего за 12 лет так и не произошло), теперь их цель в том, чтобы на Java можно было использовать все Scala-продукты, — это уже чувствуется очень сильно: теперь с каждой новой версией того же Spark он все больше становится заточен в том числе и под Java, с каждой версией разница все меньше.
Если год назад на GitHub я сравнивал количество проектов под Spark на Java и на Scala, и распределение было в районе 3000 и 7000, то сейчас эти цифры сблизились
Если год назад на GitHub я сравнивал количество проектов под Spark на Java и на Scala, и распределение было в районе 3000 и 7000, то сейчас эти цифры сблизились. Да и тогда разрыв был не так велик, это огромное количество программистов, которые пишут на Java под Spark, и у них все прекрасно работает.
JUG.RU: Евгений, спасибо, и до встречи на тренинге!
В общем, если вам тема Java на Spark кажется интересной, то мы будем рады видеть вас на нашем тренинге. Будет много заданий, live coding-а, и в конечном итоге вы выйдете с этого тренинга с достаточными знаниями, чтобы начать самостоятельно работать на Spark-e в привычном мире Java. Подробности о котором вы можете прочитать на соответствующей странице.
А если тренинг вам не интересен, то можно встретиться с Евгением на конференции Joker, где он выступит с двумя докладами:
— Мифы о Spark, или Может ли пользоваться Spark обычный Java-разработчик (очень краткая версия тренинга);
— Мавен против Грейдла: На заре автоматизации (с Барухом Садогурским);
