Rdd spark что это
Apache Spark: что там под капотом?
Вступление
Небольшая предыстория:
Spark — проект лаборатории UC Berkeley, который зародился примерно в 2009г. Основатели Спарка — известные ученые из области баз данных, и по философии своей Spark в каком-то роде ответ на MapReduce. Сейчас Spark находится под «крышей» Apache, но идеологи и основные разработчики — те же люди.
Spoiler: Spark в 2-х словах
Spark можно описать одной фразой так — это внутренности движка массивно-параллельной СУБД. То есть Spark не продвигает свое хранилище, а живет сверх других (HDFS — распределенная файловая система Hadoop File System, HBase, JDBC, Cassandra,… ). Правда стоит сразу отметить проект IndexedRDD — key/value хранилище для Spark, которое наверное скоро будет интегрировано в проект.Также Spark не заботится о транзакциях, но в остальном это именно движок MPP DBMS.
RDD — основная концепция Spark
Ключ к пониманию Spark — это RDD: Resilient Distributed Dataset. По сути это надежная распределенная таблица (на самом деле RDD содержит произвольную коллекцию, но удобнее всего работать с кортежами, как в реляционной таблице). RDD может быть полностью виртуальной и просто знать, как она породилась, чтобы, например, в случае сбоя узла, восстановиться. А может быть и материализована — распределенно, в памяти или на диске (или в памяти с вытеснением на диск). Также, внутри, RDD разбита на партиции — это минимальный объем RDD, который будет обработан каждым рабочим узлом.
Ну и уже исходя из этого понимания следует Spark рассматривать как параллельную среду для сложных аналитических банч заданий, где есть мастер, который координирует задание, и куча рабочих узлов, которые участвуют в выполнении.
Давайте рассмотрим такое простое приложение в деталях (напишем его на Scala — вот и повод изучить этот модный язык):
Пример Spark приложения (не все включено, например include)
Мы отдельно разберем, что происходит на каждом шаге.
А что же там происходит?
Теперь пробежимся по этой программе и посмотрим что происходит.
Ну во-первых программа запускается на мастере кластера, и прежде чем пойдет какая-нибудь параллельная обработка данные есть возможность что-то поделать спокойно в одном потоке. Далее — как уже наверное заметно — каждая операция над RDD создает другой RDD (кроме saveAsTextFile). При этом RDD все создаются лениво, только когда мы просим или записать в файл, или например выгрузить в память на мастер — начинается выполнение. То есть выполнение происходит как в плане запроса, конвеером, где элемент конвеера — это партиция.
Что происходит с самой первой RDD, которую мы сделали из файла HDFS? Spark хорошо синтегрирован с Hadoop, поэтому на каждом рабочем узле будет закачиваться свое подмножество данных, и закачиваться будет по партициям (которые в случае HDFS совпадают с блоками). То есть все узлы закачали первый блок, и пошло выполнение дальше по плану.
После чтения с диска у нас map — он выполняется тривиально на каждом рабочем узле.
Дальше идет groupBy. Это уже не простая конвеерная операция, а настоящая распределенная группировка. По хорошему, лучше этот оператор избегать, так как пока он реализован не слишком умно — плохо отслеживает локальность данных и по производительности будет сравним с распределенной сортировкой. Ну это уже информация к размышлению.
Давайте задумаемся о состоянии дел в момент выполнения groupBy. Все RDD до этого были конвеерными, то есть они ничего нигде не сохраняли. В случае сбоя, они опять бы вытащили недостающие данные из HDFS и пропустили через конвеер. Но groupBy нарушает конвеерность и в результате мы получим закэшированный RDD. В случае потери теперь мы вынуждены будем переделать все RDD до groupBy полностью.
Чтобы избежать ситуации, когда из-за сбоев в сложном приложении для Spark приходится пересчитывать весь конвеер, Spark позволяет пользователю контролировать кэширование оператором persist. Он умеет кэшировать в память (в этом случае идет пересчет при потере данных в памяти — она может случится при переполнении кэша), на диск (не всегда достаточно быстро), или в память с выбросом на диск в случае переполнения кэша.
После, у нас опять map и запись в HDFS.
Ну вот, теперь более менее понятно что происходит внутри Spark на простом уровне.
А как же подробности?
Например хочется знать как именно работает операция groupBy. Или операция reduceByKey, и почему она намного эфективнее, чем groupBy. Или как работает join и leftOuterJoin. К сожалению большинство подробностей пока легче всего узнать только из исходников Spark или задав вопрос на их mailing list (кстати, рекомендую подписаться на него, если будете что-то серьезное или нестандартное делать на Spark).
Еще хуже с понимаем, что творится в различных коннекторах к Spark. И насколько ими вообще можно пользоваться. Например нам на время пришлось отказаться от идеи интегрироваться с Cassandra из-за их непонятной поддержки коннектора к Spark. Но надежда есть что документация качественная в скором будущем появится.
Apache Spark: оптимизация производительности на реальных примерах
Apache Spark – фреймворк для обработки больших данных, который давно уже стал одним из самых популярных и часто встречаемых во всевозможных проектах, связанных с Big Data. Он удачно сочетает в себе скорость работы и простоту выражения своих мыслей разработчиком.
Разработчик работает с данными на достаточно высоком уровне и, кажется, что нет ничего сложного в том, чтобы, например, соединить два набора данных, написав всего одну строку кода:
Но только задумайтесь: что происходит в кластере при соединении двух наборов данных, которые могут и не находится целиком на каком-либо из узлов кластера? Обычно Spark со всем справляется быстро, но иногда, а особенно, если данных действительно много, необходимо все-таки понимать – что происходит уровнем ниже и использовать это знание, чтобы помочь Spark работать в полную силу.
Сегодня мы поговорим о том, как сделать так, чтобы ваше приложение работало быстро и использовало все ресурсы, которые вы запросили для него. В этой статье рассмотрим в основном модуль Spark SQL, запуск приложения Spark в кластере с Yarn со статическим выделением ресурсов. Но общие идеи можно применять и с другими начальными данными. Мы рассматриваем здесь Spark 2.3/2.4, чтобы лучше понять все нововведения Spark 3.X с его Adaptive Query Execution (AQE) (хотя некоторые функции уже присутствуют и в Spark 2.4) и почему они так важны.
Данные и где они обитают
Начнем с абстракции, которую нам предоставляет Spark для работы с данными – это RDD (Resilient Distributed Dataset). Для цели нашей статьи не важно, что мы работаем с DataFrame или DataSet.
RDD (Resilient Distributed Dataset)
Таким образом, для разработчиков набор данных представлен в виде единого объекта, а обрабатывается он порциями (блоками) отдельно в каком-то потоке на каком-то исполнителе (executor) в кластере. Блок является минимальной единицей обработки, исполнитель получает блок и инструкцию, которая сообщает ему о том, что необходимо сделать с этим блоком данных.
Как работает приложение Spark в кластере
На высоком уровне каждое приложение Spark в момент своей работы состоит из драйвера – программы, которая исполняет функцию main() и исполнителей, которые работают на узлах кластера. Исполнители – универсальные солдаты, они получают порцию данных (блок) и инструкцию, исполняют ее и докладывают драйверу о завершении, чтобы получить следующую инструкцию. В каждом исполнителе может быть запущено более одного потока обработки, и в этом случае каждый поток обрабатывает свой блок данных независимо от других. Таким образом, если мы при запуске нашего приложения заказали у менеджера кластера пять исполнителей по четыре ядра (потока), то в каждый момент времени мы располагаем 5*4 = 20 потоками и в лучшем случае можем обрабатывать 20 блоков данных одновременно.
Итак, каждая задача получает для выполнения:
num_executors – к-во отдельных процессов JVM, в которых будут запущена потоки обработки данных (они могут быть расположены как на одной узле кластера, так и на разных). Процессы будут работать до конца работы приложения;
executor_cores – количество параллельных потоков, выполняемых в каждом executor. Один поток в каждый момент времени обрабатывает один блок данных.
Схема работы приложения Spark
В Spark History (Web сервер для отображения логов выполнения приложений Spark в удобном виде) это выглядит так:
Spark History: Stage
Мы здесь видим два исполнителя, в каждом из которых работает по четыре потока обработки.
Перетасовка (Shuffle)
Итак, мы разобрались в том, что у нас есть N блоков данных и P потоков (работников), которые эти блоки данных могут перерабатывать параллельно.
И все у нас было бы хорошо, если бы эти блоки жили до конца приложения, но почти в любом приложении будет обработка, которая влечет за собой полную перетасовку наших блоков. Это, например, соединение двух таблиц по ключу (JOIN), группировка по ключу (GROUP BY). В этом случае работает всем хорошо известный паттерн MapReduce, при котором происходит перераспределение данных всего набора по ключу на новые блоки данных, так, чтобы строки с одним и тем же ключом находились только в одном блоке. Этот процесс в Spark называется Shuffle. Почему я написал его с большой буквы? Потому что это очень сложный и дорогостоящий процесс, при котором увеличивается потребление памяти на исполнителях, потребление дисковой памяти на узлах кластера и сетевой обмен между узлами кластера. Очень напоминает превращение гусеницы в бабочку – все разваливается на куски, чтобы потом собраться в новом обличии, и так же энергозатратно.
Задание делится на этапы
В Spark обработка блоков от одной перетасовки (Shuffle) до другой называется этапом (Stage). Заметим, что до перетасовки все блоки обрабатываются параллельно, после перетасовки они тоже обрабатываются параллельно, но новый этап не начнется пока этот процесс не пройдут все блоки в конце предыдущего этапа. Таким образом, граница между этапами – это место ожидания при параллельной обработке блоков. Заметим также, что в рамках одного этапа все задачи (task) над одним блоком происходят последовательно в рамках одного потока. То есть блок никуда не передается по сети, но все блоки обрабатываются параллельно. Получается, что количество блоков в границах этапа неизменно.
Задание делится на этапы
Мы пришли к следующей картине: все задания делятся на этапы, а в рамках каждого этапа количество блоков неизменно и равно …. И вот здесь начинается самое интересное. Количество работников у нас известно (P = executors*cores), а вот сколько блоков будет на каждом этапе – это вопрос, от которого напрямую зависит производительность нашего приложения. Ведь если блоков много, а исполнителей мало, то каждый исполнитель будет обрабатывать последовательно несколько блоков и наоборот: если блоков мало, а исполнителей больше, то некоторые исполнители будут простаивать, когда остальные трудятся не покладая рук. Самое интересное здесь – то, что, когда приложение работает медленно, пытаются выдать ему больше исполнителей, но производительность в этом случае не увеличивается.
Мы читаем небольшой файл из HDFS, в котором 150 тысяч записей. Весь файл помещается в один блок HDFS. Таким образом, на первом этапе у нас всего один блок данных, поэтому работать с ним сможет только один исполнитель. Но по логике работы трансформации в каждой строке находится поле duration (количество секунд просмотра), и нам необходимо размножить каждую строку на выходе на столько строк, сколько секунд смотрения у нас в этой строке.
Трансформация на тестовых данных работает не быстро. Глядя в Spark History, видим:
На первом этапе один блок данных
Смотрим Spark History:
Теперь обработка идет параллельно
Приведу пример, когда у нас данных мало, а spark.sql.shuffle.partitions = 200 по умолчанию. Вырожденный случай и не используем broadcast. Глядя на Spark History, видим, что наш набор данных состоит всего из 185 строк, и был поделен при перетасовке на 200 блоков (но тут и на 200 блоков не хватит). Заметим, что реальная полезная работа исполнителя окрашена здесь в зеленый цвет. То есть получается, что из всего времени работы исполнителя на обработку одного блока данных из одной записи полезное время составило
Что же у нас происходит на последнем этапе? Это опять зависит от того, куда мы выводим данные нашей трансформации. Например, мы хотим записать все в директорию в виде parquet файлов. Если мы сделаем это после перетасовки, ничего не предприняв, то обнаружим 200 файлов в этой директории после выполнения нашей программы. Почему? Потому что после перетасовки у нас получилось по умолчанию spark.sql.shuffle.partitions = 200 блоков, а так как один блок обрабатывается одним потоком, то и записывать его он будет сам в отдельный файл.
Кстати, один из интересных моментов применения метода разрыва последнего этапа при сохранении, описанного в предыдущем параграфе:
Если сравнивать показатели перед и после разрыва последнего этапа, то все кажется отлично: время работы трансформации сократилось в несколько раз (так как последние вычисления выполнялись параллельно всеми исполнителями), исчез Shuffle Spill (это когда исполнителю не хватает памяти и он устраивает своеобразный swap с локальным диском. Конечно, в этом случае все данные пришли несколькими большими блоками и исполнители с трудом их переварили).
СТОП! Приглядимся к размеру файлов, полученных при сохранении. Было 5.9 Гб, стало 10.3 Гб, количество записей одно и то же, состав данных тот же. Почему? Вот и ложка дегтя!
Обратите внимание на размер Output
Функция sortWithinPartitions() производит сортировку по полю или нескольким полям внутри каждого блока, т.е. никакой перетасовки не происходит все работает в рамках одного исполнителя в его памяти. После применения этой функции к нашей трансформации для сортировки по нескольким полям, общий размер файлов на выходе стал даже немного меньше, чем изначально. Теперь у нас все работает быстро, размер файлов на выходе нас устраивает. Кроме того, в этом случае мы записали в HDFS файлы примерно одинакового размера (это следствие repartition() ), что может быть удобно для дальнейшей обработки.
О работе оптимизатора
Раз уж мы коснулись файла формата parquet, на нем и посмотрим, как работает оптимизатор Spark на примере такого правила оптимизатора, как predicate pushdown и projection pushdown.
Рассмотрим правило оптимизатора – спуск условия (predicate pushdown). Принцип этой оптимизации достаточно прост: данных у нас много и ни к чему их обрабатывать, если они в конце концов не пригодятся, например должны быть отфильтрованы в конце выполнения нашего дерева запроса. Все условия и фильтры оптимизатор старается по возможности спустить на уровни ниже – ближе к источникам данных, в идеале до непосредственного чтения файла (или, например, запроса к RDBMS).
Вот физический план выполнения запроса, который при этом генерируется:
Обратим внимание на блок непосредственного чтения из файла (FileScan parquet) и блок PushedFilters – это те условия, которые будут накладываться при физическом чтении файла. Видим, что сюда попали три условия:
Файл parquet внутри
Важно понимать, что условие можно спустить на уровни ниже только, если оно заранее известно перед началом выполнения запроса.
Пример из реальной жизни.
Из HDFS читаются все партиции
Странно, но на первом этапе Spark вычитывает все партиции ( PartitionCount =121 ), хотя мы передаем фильтр, который состоит только из одного значения. Это как раз тот случай, когда при построении дерева запроса Spark не знает о фильтре вообще, ведь он скрыт за JOIN.
То есть фильтр у нас теперь представляет простое выражение:
И если посмотреть на план выполнения запроса, так как при его построении оптимизатор уже знает строку фильтра и условие, он спускает это условие на уровень чтения из файла. Кроме того, зная, что это партицирующее поле, применяет правило partition pruning, то есть выкидывает из рассмотрения партиции, не удовлетворяющие фильтру.
Читается из HDFS только одна партиция
Обратите внимание, что наше условие теперь находится в блоке PartitionFilters, так как поле партицирующее, из HDFS вычитывается только нужная нам партиция ( PartitionCount = 1 ).
Поэтому, если у вас есть большая таблица с партицированием и вы отбираете некоторые партиции через JOIN, то возможно будет лучше отдельным действием сформировать список значений из этой таблицы фильтра в виде строки и передать его в виде константы в условие основного запроса.
Когда оптимизатор может навредить
Отличная работа оптимизатора… Но иногда его стремление спустить условие как можно ниже к источнику может навредить. На сцену выходит UDF (user defined function). Функция, определенная пользователем, это черный ящик для оптимизатора Spark.
Рассмотрим следующий пример:
Имеем большой файл с несколькими миллиардами строк. Мы хотим отобрать только уникальные id и применить к ним нашу UDF, далее отобрать только те результаты, которые будут Null. Последовательность запросов:
Уникальных значений id в таблице всего несколько тысяч, а наша UDF работает не быстро – ходит в HBase. То есть мы, построив такое дерево запроса, рассчитываем, что наша UDF будет вызвана несколько тысяч раз. Запускаем запрос и долго-долго ждем.
Смотрим план выполнения запроса:
Условие с UDF спустилось почти на самы нижний уровень
… ой! Оптимизатор постарался на славу: он честно спустил наше условие isNull(UDF(id)) на уровень сразу после непосредственного чтения файла, даже до того момента, когда мы отбираем только уникальные id. А это значит, что наша тяжелая UDF пыталась выполниться миллиарды раз вместо тысяч.
Получили то, что и хотели в начале – UDF вычисляется только для уникальных id:
Заключение
За рамками этой статьи остались вопросы, связанные с оптимизацией JOIN: broadcast, data skew, с плюсами и минусами coalesce и repartition. Некоторые моменты достаточно подробно описаны на Хабр, а некоторые – нет. Возможно, это будет темой следующей статьи. Спасибо за внимание.
Знакомство с Apache Spark
Здравствуйте, уважаемые читатели!
Мы наконец-то приступаем к переводу серьезной книги о фреймворке Spark:
Сегодня мы предлагаем вашему вниманию перевод обзорной статьи о возможностях Spark, которую, полагаем, можно с полным правом назвать слегка потрясающей.
Я впервые услышал о Spark в конце 2013 года, когда заинтересовался Scala – именно на этом языке написан Spark. Несколько позже я принялся ради интереса разрабатывать проект из области Data Science, посвященный прогнозированию выживаемости пассажиров «Титаника». Оказалось, это отличный способ познакомиться с программированием на Spark и его концепциями. Настоятельно рекомендую познакомиться с ним всем начинающим Spark-разработчикам.
Сегодня Spark применяется во многих крупнейших компаниях, таких, как Amazon, eBay и Yahoo! Многие организации эксплуатируют Spark в кластерах, включающих тысячи узлов. Согласно FAQ по Spark, в крупнейшем из таких кластеров насчитывается более 8000 узлов. Действительно, Spark – такая технология, которую стоит взять на заметку и изучить.
В этой статье предлагается знакомство со Spark, приводятся примеры использования и образцы кода.
Что такое Apache Spark? Введение
Spark – это проект Apache, который позиционируется как инструмент для «молниеносных кластерных вычислений». Проект разрабатывается процветающим свободным сообществом, в настоящий момент является наиболее активным из проектов Apache.
Spark предоставляет быструю и универсальную платформу для обработки данных. По сравнению с Hadoop Spark ускоряет работу программ в памяти более чем в 100 раз, а на диске – более чем в 10 раз.
Кроме того, код на Spark пишется быстрее, поскольку здесь в вашем распоряжении будет более 80 высокоуровневых операторов. Чтобы оценить это, давайте рассмотрим аналог “Hello World!” из мира BigData: пример с подсчетом слов (Word Count). Программа, написанная на Java для MapReduce, содержала бы около 50 строк кода, а на Spark (Scala) нам потребуется всего лишь:
При изучении Apache Spark стоит отметить еще один немаловажный аспект: здесь предоставляется готовая интерактивная оболочка (REPL). При помощи REPL можно протестировать результат выполнения каждой строки кода без необходимости сначала программировать и выполнять все задание целиком. Поэтому написать готовый код удается гораздо быстрее, кроме того, обеспечивается ситуативный анализ данных.
Кроме того, Spark имеет следующие ключевые черты:
Ядро Spark дополняется набором мощных высокоуровневых библиотек, которые бесшовно стыкуются с ним в рамках того же приложения. В настоящее время к таким библиотекам относятся SparkSQL, Spark Streaming, MLlib (для машинного обучения) и GraphX – все они будут подробно рассмотрены в этой статье. Сейчас также разрабатываются другие библиотеки и расширения Spark.
Ядро Spark
Ядро Spark – это базовый движок для крупномасштабной параллельной и распределенной обработки данных. Ядро отвечает за:
Трансформации в Spark осуществляются в «ленивом» режиме — то есть, результат не вычисляется сразу после трансформации. Вместо этого они просто «запоминают» операцию, которую следует произвести, и набор данных (напр., файл), над которым нужно совершить операцию. Вычисление трансформаций происходит только тогда, когда вызывается действие, и его результат возвращается основной программе. Благодаря такому дизайну повышается эффективность Spark. Например, если большой файл был преобразован различными способами и передан первому действию, то Spark обработает и вернет результат лишь для первой строки, а не станет прорабатывать таким образом весь файл.
По умолчанию каждый трансформированный RDD может перевычисляться всякий раз, когда вы выполняете над ним новое действие. Однако RDD также можно долговременно хранить в памяти, используя для этого метод хранения или кэширования; в таком случае Spark будет держать нужные элементы на кластере, и вы сможете запрашивать их гораздо быстрее.
SparkSQL – это компонент Spark, поддерживающий запрашивание данных либо при помощи SQL, либо посредством Hive Query Language. Библиотека возникла как порт Apache Hive для работы поверх Spark (вместо MapReduce), а сейчас уже интегрирована со стеком Spark. Она не только обеспечивает поддержку различных источников данных, но и позволяет переплетать SQL-запросы с трансформациями кода; получается очень мощный инструмент. Ниже приведен пример Hive-совместимого запроса:
Spark Streaming поддерживает обработку потоковых данных в реальном времени; такими данными могут быть файлы логов рабочего веб-сервера (напр. Apache Flume и HDFS/S3), информация из соцсетей, например, Twitter, а также различные очереди сообщений вроде Kafka. «Под капотом» Spark Streaming получает входные потоки данных и разбивает данные на пакеты. Далее они обрабатываются движком Spark, после чего генерируется конечный поток данных (также в пакетной форме) как показано ниже.
API Spark Streaming точно соответствует API Spark Core, поэтому программисты без труда могут одновременно работать и с пакетными, и с потоковыми данными.
MLlib – это библиотека для машинного обучения, предоставляющая различные алгоритмы, разработанные для горизонтального масштабирования на кластере в целях классификации, регрессии, кластеризации, совместной фильтрации и т.д. Некоторые из этих алгоритмов работают и с потоковыми данными — например, линейная регрессия с использованием обычного метода наименьших квадратов или кластеризация по методу k-средних (список вскоре расширится). Apache Mahout (библиотека машинного обучения для Hadoop) уже ушла от MapReduce, теперь ее разработка ведется совместно с Spark MLlib.
GraphX – это библиотека для манипуляций над графами и выполнения с ними параллельных операций. Библиотека предоставляет универсальный инструмент для ETL, исследовательского анализа и итерационных вычислений на основе графов. Кроме встроенных операций для манипуляций над графами здесь также предоставляется библиотека обычных алгоритмов для работы с графами, например, PageRank.
Как использовать Apache Spark: пример с обнаружением событий
Теперь, когда мы разобрались, что такое Apache Spark, давайте подумаем, какие задачи и проблемы будут решаться с его помощью наиболее эффективно.
Недавно мне попалась статья об эксперименте по регистрации землетрясений путем анализа потока Twitter. Кстати, в статье было продемонстрировано, что этот метод позволяет узнать о землетрясении более оперативно, чем по сводкам Японского Метеорологического Агентства. Хотя технология, описанная в статье, и не похожа на Spark, этот пример кажется мне интересным именно в контексте Spark: он показывает, как можно работать с упрощенными фрагментами кода и без кода-клея.
Во-первых, потребуется отфильтровать те твиты, которые кажутся нам релевантными – например, с упоминанием «землетрясения» или «толчков». Это можно легко сделать при помощи Spark Streaming, вот так:
Затем нам потребуется произвести определенный семантический анализ твитов, чтобы определить, актуальны ли те толчки, о которых в них говорится. Вероятно, такие твиты, как «Землетрясение!» или «Сейчас трясет» будут считаться положительными результатами, а «Я на сейсмологической конференции» или «Вчера ужасно трясло» — отрицательными. Авторы статьи использовали для этой цели метод опорных векторов (SVM). Мы поступим также, только реализуем еще и потоковую версию. Полученный в результате образец кода из MLlib выглядел бы примерно так:
Если процент верных прогнозов в данной модели нас устраивает, мы можем переходить к следующему этапу: реагировать на обнаруженное землетрясение. Для этого нам потребуется определенное число (плотность) положительных твитов, полученных в определенный промежуток времени (как показано в статье). Обратите внимание: если твиты сопровождаются геолокационной информацией, то мы сможем определить и координаты землетрясения. Вооружившись этими знаниями, мы можем воспользоваться SparkSQL и запросить имеющуюся таблицу Hive (где хранятся данные о пользователях, желающих получать уведомления о землетрясениях), извлечь их электронные адреса и разослать им персонализированные предупреждения, вот так:
Другие варианты использования Apache Spark
Потенциально сфера применения Spark, разумеется, далеко не ограничивается сейсмологией.
Вот ориентировочная (то есть, ни в коем случае не исчерпывающая) подборка других практических ситуаций, где требуется скоростная, разноплановая и объемная обработка больших данных, для которой столь хорошо подходит Spark:
В игровой индустрии: обработка и обнаружение закономерностей, описывающих игровые события, поступающие сплошным потоком в реальном времени; в результате мы можем немедленно на них реагировать и делать на этом хорошие деньги, применяя удержание игроков, целевую рекламу, автокоррекцию уровня сложности и т.д.
В электронной коммерции информация о транзакциях, поступающая в реальном времени, может передаваться в потоковый алгоритм кластеризации, например, по k-средним или подвергаться совместной фильтрации, как в случае ALS. Затем результаты даже можно комбинировать с информацией из других неструктутрированных источников данных — например, с отзывами покупателей или рецензиями. Постепенно эту информацию можно применять для совершенствования рекомендаций с учетом новых тенденций.
В финансовой сфере или при обеспечении безопасности стек Spark может применяться для обнаружения мошенничества или вторжений, либо для аутентификации с учетом анализа рисков. Таким образом можно получать первоклассные результаты, собирая огромные объемы архивированных логов, комбинируя их с внешними источниками данных, например, с информацией об утечках данных или о взломанных аккаунтах (см., например, https://haveibeenpwned.com/), а также использовать информацию о соединениях/запросах, ориентируясь, например, на геолокацию по IP или на данные о времени
Итак, Spark помогает упростить нетривиальные задачи, связанные с большой вычислительной нагрузкой, обработкой больших объемов данных (как в реальном времени, так и архивированных), как структурированных, так и неструктурированных. Spark обеспечивает бесшовную интеграцию сложных возможностей – например, машинного обучения и алгоритмов для работы с графами. Spark несет обработку Big Data в массы. Попробуйте – не пожалеете!