Добро Пожаловать В Spark… На Java: Интервью С Евгением Борисовым

Большие данные — это проблема.

Объем информации растет с каждым днем и накапливается как снежный ком.

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

Фреймворк был выпущен в 2012 году.

Апач Спарк , разработанный на языке Scala и предназначенный для повышения производительности определенных классов задач при работе с большими данными.

Проекту уже 4 года, он повзрослел и дорос до версии 2.0, к которой (фактически уже начиная с версии 1.3-1.5) имеет мощный и удобный API для работы с Java. Чтобы понять, кому все это нужно, какие проблемы следует решать с помощью Spark, а чего делать не следует, мы поговорили с Евгением.

Евгений Борисов Борисов, автор Тренинг «Добро пожаловать в Spark» , который пройдет 12-13 октября в Санкт-Петербурге.

JUG.RU: Евгений, привет! Начнем с самого начала.

Расскажите вкратце, что такое Искра и с чем ее едят? Евгений: Прежде всего, Apache Spark — это фреймворк: своего рода API, который позволяет обрабатывать большие данные с неограниченным количеством ресурсов, машин и является самомасштабируемым.

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

И тут возникает резонный вопрос: а куда писать и откуда писать? Вы можете написать Апач Хадуп , можно работать с HDFS, можно работать с Amazon S3. В общем, распределенных хранилищ много, и API для Spark для многих уже написано, для других пишется.

Например, в Апач Кассандра для этого есть коннектор (в DataStax Enterprise), позволяющий писать Spark с помощью Cassandra. В конце концов, можно и с локальной файловой системой: хотя здесь это и не обязательно (масштабировать некуда), но эта возможность обычно используется для тестирования.

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

Означает ли это, что проект чисто «корпоративный» или его в принципе можно использовать в каких-то личных проектах? Евгений: Сегодня это скорее корпоративный фреймворк, но Big Data сейчас распространяется такими темпами, что скоро без них будет никуда: с каждым годом информации накапливается все больше, и соответственно, появляется желание обрабатывать ее неограниченно долго.

количество ресурсов.

Сегодня у вас мало информации, и у вас есть код, который только ее обрабатывает, а когда вы накопите больше, вам придется все переписывать.

Так? А если изначально все обрабатывалось на Spark, то можно просто увеличить кластер на несколько машин, и код менять вообще не нужно.

JUG.RU: Вы говорите, что Spark — это всё-таки корпоративный класс.

Вот важный вопрос: а как насчет стабильности и обратной совместимости? Евгений: Поскольку Spark написан на Scala, а обратная совместимость Scala довольно плохая, Spark от этого тоже немного страдает. Бывает, что вы обновились, и вдруг отвалился какой-то функционал, но происходит это в гораздо меньшей степени, чем в Scala. Все-таки API здесь гораздо стабильнее и все не так критично: «поломки» обычно решаются локально, по пунктам.

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

К обучению я успею подготовить какую-нибудь тему-обзор и показать, что изменилось и обновилось.

Здесь стоит добавить, что несмотря на то, что сам Spark написан на Scala, а я небольшой сторонник так что те, кто пишет на Scala кто ее не знает .

Меня часто упрекают: «Ну ты на Scala упираешься».

Я не выбиваю Скалу! Я просто считаю, что если кто-то не знает Scala, но хочет писать на Spark, то это не повод изучать Scala. JUG.RU: Окей, мы решили, что в принципе для Spark лучше писать на Scala, но если ты не умеешь писать на Scala, то можно писать на Ja. Евгений: Нет нет нет! Я не говорил, что лучше писать на Scala. Я сказал, что люди, которые хорошо знают Скалу и пишут на ней под Спарком, совершенно нормальны.

Но если человек говорит: «Ну, я не знаю Scala, но мне нужно написать в Spark, потому что я понял, какая это классная штука.

Неужели я единственный, кому сейчас нужно преподавать рокЭ» Я говорю, что это совершенно бессмысленно! И мне было смешно читать комментарии людей , который написал «так мы пробовали писать на Java, так как Scala мы не знали, но Java знали, но потом все стало настолько плохо, что в конце концов нам пришлось перейти на Scala, и теперь мы счастливы».

Сегодня это совсем не так: это было бы верно, если бы мы говорили о Java 7, а Spark был старый, еще с RDD — да, тогда действительно выходили такие трехэтажные конструкции, в которых было совершенно невозможно разобраться.

Сегодня Java занимает восьмое место, и в Spark появились датафреймы (начиная с версии 1.3), которые предоставляют API, которому не важно, на чем он работает: Scala, Java — без Scala можно прекрасно жить.

JUG.RU: Если я умею писать на Java 8, какой у меня порог входа в Spark? Придется ли мне многому учиться, читать умные книги? Евгений : Очень низко, особенно если у вас уже есть практический опыт работы с Java 8. Возьмите стримы восьмой Явы: идеология там очень похожа, даже большинство методов называются одинаково.

Вы можете начать и разобраться сами.

Обучение Он нужен скорее для того, чтобы разобраться со всякими тонкостями, хитростями и нюансами.

Кроме того, поскольку обучение будет для Java-разработчиков, я покажу, как можно все настроить с помощью Spring, как с его помощью можно написать инфраструктуру, чтобы трюки Spark, связанные с производительностью, можно было делать с помощью аннотаций, чтобы все работало на нем.

собственный "из коробки".

JUG.RU: Везде пишут и говорят, что Spark отлично подходит для работы с большими данными, и это понятно.

Но вот вопрос, который возникает уже не так часто: для чего не подходит Spark? Какие ограничения и для каких задач использовать точно не стоит? Евгений: Использовать Spark для задач, которые не масштабируются, однозначно нет смысла, в том смысле, что если задача не масштабируется по своей идеологии, то Spark здесь не поможет. Как пример: оконные функции, несмотря на то, что они есть в Sparke (в общем, на Spark можно делать всё), но работают они очень медленно.

Со временем здесь дела должны наладиться, они движутся в этом направлении.

JUG.RU: Кстати, это хорошая история, куда движется Spark? Понятно, что теперь уже можно быстро и хорошо обрабатывать некоторые данные.

Евгений: В первом Спарке было RDD (устойчивый распределенный набор данных) , что позволяет обрабатывать данные с помощью кода.

Поскольку данные обычно имеют структуру на основе столбцов, и тут получается, что к именам столбцов нельзя получить доступ, в RDD API такого просто нет. А если у вас есть файл с огромным количеством столбцов и огромным количеством строк, и вы пишете логику, которая все это обрабатывает, то в итоге вы получаете очень нечитаемый код. Кадры данных позволял обрабатывать данные с сохранением структуры, используя имена столбцов: код стал гораздо читабельнее, люди, знакомые с SQL, чувствовали себя в этом мире очень хорошо.

С другой стороны, стала отсутствовать возможность тонкой настройки логики.

В результате оказалось, что некоторые вещи стало удобно делать с помощью RDD, а некоторые — с помощью датафреймов.

Вторая Искра объединила всё это дело в структуру под названием Набор данных , и работать в нем можно в любом случае, не оставляя ни одного API. Плюс все стало работать гораздо быстрее.

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

Фреймворк становится все быстрее и быстрее

Евгений: Я не согласен с этим мнением.

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

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

Но при необходимости можно работать и без Yarn. Есть Spark Standalone, который, конечно, медленнее и не такой мощный, но кроме этого есть и другие альтернативы: Apache Mesos, например, другие сейчас еще пилят. Я уверен, что через пять лет их будет много, не все завязаны на ПРЯЖЕ.

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

JUG.RU: С теорией мы более-менее разобрались.

Почему Spark не нужен, тоже понятно.

Можете ли вы привести примеры использования Spark из своего опыта? Наверняка было что-то интересное в сфере Big Data. Евгений: Насчет «интересного» не знаю, все-таки я в основном реализовал энтерпрайзы, там не так уж и много крутого.

Другое дело, что писать было интересно, быстро и удобно.

Из интересных кейсов могу вспомнить услугу для телефонных компаний: представьте, вы прилетели в другую страну, не поменяли сим-карту, и вам нужно выбрать роуминг.

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

Именно этот проект посчитал такие данные по всем звонкам по всему миру: проанализировал все это и вывел различную статистику.

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

Тут опять обработка дикого количества писем, они это все хранят в Redshift на Amazon: все нужно структурировать, посчитать и как-то быстро обработать, чтобы еще и выдать какую-то статистику, на основе какие клиенты уже могут предоставлять таргетированную рекламу или рекомендации.

Здесь мы добавили Spark для повышения производительности; без него все работало очень медленно.

JUG.RU: Spark обрабатывает данные в режиме реального времени? Евгений: Это возможно как в реальном времени, так и в пакетном режиме.

JUG.RU: Понятно, а как насчет проверки данных? Существуют ли инструменты, упрощающие проверку данных на целостность и корректность? Евгений: Ну, это все решается на уровне кода: вы берете миллион строк кода и первым делом выкидываете невалидные.

Кстати, по ним обычно собирается статистика: много ли таких данных, почему они неверные? Это также делает Spark.



JUG.RU: Наконец, не могу не затронуть еще раз вопрос «Java vs Scala в Spark».

Тем более из любопытства.

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

Теперь, начиная новый проект, я каждый раз думаю, начинать ли мне его на Java 8 или Groovy. Но Scala — это совершенно другой мир! И его сложнее понять как инструмент. Макропаттернов там нет. Был период, когда мне приходилось писать на Scala — я ужасно страдал.

Естественно, когда вы страдаете, вы идете за советом к другим людям.

Консультируешься с одним человеком, как строить архитектуру, он говорит одно.

Если вы спросите кого-то другого, вы получите совершенно другой ответ! В мире Java все гораздо проще, гораздо больше опыта, больше людей, сообщества: у меня есть сервисы, у меня есть Дао, у меня есть внедрение зависимостей, у меня есть Spring, для этого есть Spring Data или, если уж на то пошло, Spring MVC, выбросить всю эту тонну информации, которую собрали люди, и перейти на Scala, изучить всё с нуля? За что? Если на Java все работает так же хорошо.

Я понимаю, что если бы Scala работала в два-три раза быстрее или API было бы в 10 раз удобнее, я бы согласился учиться полтора года.

Я помню забавный случай.

Во Львове после репортажа ко мне подошел мужчина и сказал: – Слушай, тебе не нравится Scala? «Я этого не говорил», — отвечаю я.

- Ну, ты это чувствуешь.

— Ну я просто считаю, что для проекта, в котором уже есть Java-программисты, нет смысла тратить время на их перевод на Scala. – Вы сами писали на Скале? - Ну, я немного написал.

- Сколько? - Около шести месяцев.

– Ха, полгода.

Полгода ты не мог понять Скалу! Это займет как минимум два-три года.

Именно в тот момент я понял, что Я был абсолютно прав .

Здесь порог входа высок, на уровне 2-3 лет. Ведь вопрос не в том, хорош язык или плох.

Правда в том, что если вы умеете писать на Java, то пишите на Java, в любом случае с помощью Spark, это легко и просто.

Все реже у разработчиков моих проектов возникают ситуации, когда они ищут какие-то решения в Google и находят их в Scala, но не в Java. Раньше этого было много, а сейчас практически нет. На самом деле, я еще раз скажу, что миссия Scala не так давно изменилась: вместо перевода разработчиков на Scala (чего не было уже 12 лет), теперь их цель — сделать возможным использование всех продуктов Scala на Java. , — это уже очень сильно чувствуется: теперь с каждой новой версией того же Спарка он становится все более заточенным, в том числе и под Java, с каждой версией разница все меньше и меньше.

Если год назад на GitHub я сравнивал количество проектов Spark на Java и в Scala, и раздача была в районе 3000 и 7000, то сейчас эти цифры стали ближе.

И даже тогда разрыв был не так уж велик, есть огромное количество программистов, которые пишут на Java под Spark, и у них все прекрасно работает. JUG.RU: Евгений, спасибо и до встречи на тренинге!

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

А если обучение вам не интересно, то с Евгением можно познакомиться на конференции «Джокер», где он выступит с двумя докладами: – Мифы о Spark, или Может ли обычный Java-разработчик использовать Spark (очень краткий вариант обучения) ; – Maven против Gradle: Рассвет автоматизации (совместно с Барухом Садогурским) ; Теги: #Большие данные #java #конференция #искра #обучение #джокер #Джокер #jokerconf

• Деревянные Usb-Накопители – Обязательно Попробуйте

  19 Oct, 24

• Как Он Это Сделал?

  19 Oct, 24

• Как Запустить Проект Без Релизов

  19 Oct, 24

• Предпроектная Документация: Что Это Такое И Почему Она Так Важна?

  19 Oct, 24

• Ваш Код Имеет Решающее Значение

  19 Oct, 24

• Приглашение В Команду Переводчиков Opera

  19 Oct, 24

• Подходит Ли К Концу Эра «Толстого» Программного Обеспечения?

  19 Oct, 24

• Расстановка Самодельных Маркеров Для Списков

  19 Oct, 24

• Мой Детский Бизнес... Украден?

  19 Oct, 24

• Microsoft, Вероятно, Купит Yahoo

  19 Oct, 24