Welcome to Spark… on Java: Интервью с Евгением Борисовым

    Big Data – это проблема. Количество информации растет с каждым днем, и она накапливается как снежный ком. Прекрасно то, что проблема эта имеет решения, только в мире JVM больший данных процессят десятки тысяч проектов.

    В 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 позволяет что-то писать в базу и читать, но ваш код будет неограниченно масштабироваться.

    И тут возникает резонный вопрос: а куда можно писать и откуда можно писать? Можно писать в Apache Hadoop, можно работать с HDFS, можно с Amazon S3. Вообще, есть очень много распределенных хранилищ, и для многих уже написан API для Spark, для других пишется. Например, у Apache Cassandra есть свой коннектор для этого (в DataStax Enterprise), который дает возможность писать Spark с Кассандрой. В конце концов, можно и с локальной файловой системой: хотя тут это получается не нужно (масштабироваться некуда), обычно эта возможность используется для тестирования.

    Информации с каждым годом накапливается все больше и больше, соответственно, возникает желание обрабатывать ее неограниченным объемом ресурсов


    JUG.RU: Получается, Spark крутится на распределенной инфраструктуре. Это значит, что проект сугубо «энтерпрайзный», или в принципе его можно использовать и в каких-то личных проектах?

    Евгений: Сегодня это скорее энтерпрайзный фреймворк, но 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, – можно прекрасно жить без Скала.

    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-разработчик (очень краткая версия тренинга);
    Мавен против Грейдла: На заре автоматизации (с Барухом Садогурским);
    JUG.ru Group
    1163,00
    Конференции для взрослых. Java, .NET, JS и др. 18+
    Поделиться публикацией

    Комментарии 10

      +3
      переходить на Scala, учить все с нуля? Зачем? Если на Java все работает не хуже.

      Весь мой опыт конвертации Java-разработчиков в Scala-разработчиков показывает, что если человек сидит на своем теплом ламповом спринге-хибернейте и ему ничего больше не нужно для счастья — надо просто оставить его в покое.

      Кстати об этом же, но в гораздо менее толерантной манере уже давно написал David Pollak. Позволю себе процитировать:

      Мы живем в мире, где средний разработчик пишет 3250 строк кода в год (около 20 в день). Это происходит в Eclipse, нажатием кнопки «дай мне шаблон X» с подстановкой кода в предложенные средой разработки места. Потом поход на несколько митингов. И они называют это рабочим днем. Мы не можем уволить всех этих разработчиков. Мы не можем обучить их, чтобы они стали лучше. Это Середняки. Это именно те, кто использует Java. У таких программистов нет той самой комбинации врожденных способностей и желания стать лучше.


      Не то, чтобы 100% случаев, но очень часто те, кто отказываются от изучения Scala, мотивируют это тем, что им и так хорошо, их и так все устраивает.

      Несколько обидно, что голоса таких людей преобладают на некоторых популярных у нас в стране конференциях, но и от них есть польза. А имеющие глаза увидят сами, на каком языке удобнее разрабатывать под Spark.
        +1
        Все люди делятся на два типа: тех, кто делит людей на типы и остальных
          +3
          Я бы не очень доверял мнению человека, который использует Eclipse :)
          А если серьёзно, меня раздирают противоречивые чувства. С одной стороны, да правильно, человеку надо двигаться вперед, но когда он достигает зоны комфорта, это желание пропадает. И всё происходит как у David Pollak-a, но если смотреть не с точки зрения человека, а с точки зрения компании, то время затрачиваемое на постоянное обучение, не всегда себя оправдывает в разработке. Потратить пару дней, чтобы выучить спринг бут, а потом экономить кучу времени при написании проектов это имеет смысл, с точки зрения энтерпрайза, а влкадывать месяцами в обучение Скалы, ради просто саморазвитие работника, это им вряд ли надо.
          А я просто пытаюсь искать золотую середину. Вперед двигаться надо, поэтому спринг, спарк, и джава 8, со всеми её плюсами, где можно груви. А вот скала, это уж только если её знают изначально, но поскольку таких мало, то я лучше буду тратить время, чтобы улучшить мир джавы.
            +1
            всё происходит как у David Pollak-a, но если смотреть не с точки зрения человека, а с точки зрения компании

            Там смысл статьи как раз в том, что он признает, что с точки зрения бизнеса как минимум половину Java-проектов невыгодно переводить на Scala. И пытается уколоть технарей, хочешь ли конкретно ты как технарь прозябать на таких проектах. Ведь это как продолжать копать палкой-копалкой, когда рядом стоит экскаватор. «Там столько непонятных кнопочек и рычажков, и вообще большинство копают палками...»

            я лучше буду тратить время, чтобы улучшить мир джавы

            Можно только пожелать удачи, потому что тренинги по спарку принесут пользу и самому спарку, и джаве, и даже скале.

            И да, а что не так с Eclipse?
              +1
              Я думал Россию эти споры миновали, но я в любом случае зарёкся обьяснять почему Идея лучше, и дело не в том, кто к чему привык.
                0
                Тут, к сожалению, не то что экскаватор, но и даже не лопата, наверное.
            +2
            У меня у одного такое ощущение, что Apache Spark неоправданно захайпована? Вот сейчас начал читать и подумал: «ну сейчас наконец-то технически грамотно объяснят самую суть, мякотку этой технологии — что же на самом деле в ней стоящего и нового». Но с первых же строк очередной «MongoDB is web scale». Интернеты растут, IoT наступает, Big Data, неограниченное (буквально экспоненциальное) масштабирование! Если без хайпа, рекомендую вот это http://www.redbook.io/ от Стоунбрейкера: пройись по страничкам по ключевому слову Spark.
              +3
              Например, у Cassandra есть свой инструмент для этого, DataStax называется, который дает возможность писать Spark с Кассандрой.

              Это фича в продукте DataStax Enterprise (DSE), а сам DataStax — контора, которая его производит. Это не инструмент Cassandra, а сторонний софт. Также можно использовать https://github.com/datastax/spark-cassandra-connector, который open sourse от тех же DataStax.

                0
                Да, я в курсе, просто этот проект всплыл в контексте, а где ещё можно бы использывать Spark, и я хотел подчеркнуть как развивыется мир Spark-a для различных распределённых хранилищ
                +4
                Мне кажется, что в последнее время языки программирования начали возводить в какой-то абсолют. Ощущение, что выбор языка для написания кода под spark — самая большая проблема. Выбрал язык — 90% работы сделано. С моей точки зрения, понимание принципов работы spark'a куда важнее. Ведь при работе с распределенными системами за непонимание того, как они устроены, приходится платить порой очень большую цену. Непонимание работы StreamAPI, порой, обходится довольно дешево (а, порой, и нет), а вот необдуманное использование spark API может вызвать: перемещение огромного количества данных по сети, OOM, увеличение времени обработки данных в несколько раз, повышения в несколько раз требования к ресурсам кластера. Поэтому очень обидно, что основное внимание в статье уделяется не тому, что надо понимать механизм, с которым работаешь, а тому, что между написанием reduce(_ + _) и reduce((a, b) -> a + b) нет особой разницы.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое