Русские Блоги
Архитектура и принцип работы Spark, зависимости RDD, DAG, детали этапа
оглавление
1. Архитектура и экология Spark
Обычно, когда объем данных, которые необходимо обработать, превышает размер одной машины (например, наш компьютер имеет 4 ГБ памяти, и нам нужно обработать более 100 ГБ данных), мы можем выбрать искровой кластер для расчета, иногда нам может потребоваться обработать другой объем данных Большой, но расчет очень сложен и требует много времени. Вот почему мы также можем использовать мощные вычислительные ресурсы искрового кластера для параллельных вычислений. Архитектурная диаграмма выглядит следующим образом:
Spark Core: Содержит основные функции Spark; в частности, он определяет API RDD, операции и действия для обоих. Другие библиотеки Spark построены на RDD и Spark Core.
Spark SQL: Предоставляет API для взаимодействия со Spark через Hive Query Language (HiveQL), вариант SQL Apache Hive. Каждая таблица базы данных обрабатывается как RDD, а запросы Spark SQL преобразуются в операции Spark.
Spark Streaming: Обработка и управление потоком данных в реальном времени. Spark Streaming позволяет программам обрабатывать данные в реальном времени, как обычные RDD.
MLib: Библиотека часто используемых алгоритмов машинного обучения, которые реализованы как операции Spark на RDD. Эта библиотека содержит масштабируемые алгоритмы обучения, такие как классификация, регрессия и т. Д., Которые требуют итерационных операций с большим количеством наборов данных.
GraphX: Набор алгоритмов и инструментов для контрольных диаграмм, параллельных операций с диаграммами и расчетов. GraphX расширяет API RDD, включая операции для управления графами, создания подграфов и доступа ко всем вершинам на пути.
Основные компоненты в архитектуре Spark:
1、Cluster Manager : В автономном режиме это главный узел, который контролирует весь кластер и контролирует рабочих. В режиме YARN это менеджер ресурсов.
2、Worker : Подчиненный узел отвечает за управление вычислительным узлом и запуск Executor или Driver. В режиме YARN это NodeManager, отвечающий за управление вычислительными узлами.
3、Driver : Запустите функцию приложения main () и создайте SparkContext.
4、Executor : Executor, компонент, который выполняет задачи на рабочем узле и используется для запуска пула потоков для выполнения задач. Каждое приложение имеет независимый набор исполнителей.
5、SparkContext : Контекст всего приложения, контролирующий жизненный цикл приложения.
6、RDD : Базовая вычислительная единица Spark, набор RDD может формировать исполняемый ориентированный ациклический граф RDD Graph.
7、DAG Scheduler : Создать группу обеспечения доступности баз данных на основе задания (задачи) и отправить Stage в TaskScheduler.
8、TaskScheduler : Передать задачи Исполнителю для выполнения.
9、SparkEnv : Контекст уровня потока, хранит ссылки на важные компоненты во время выполнения.
2. Spark и Hadoop
1. Hadoop имеет два основных модуля: модуль распределенного хранения HDFS и модуль распределенных вычислений MapReduce.
Сам Spark не предоставляет распределенную файловую систему, поэтому анализ Spark в основном полагается на распределенную файловую систему Hadoop HDFS.
2. MapReduce и Spark в Hadoop могут выполнять вычисления данных, и по сравнению с MapReduce Spark работает быстрее и предоставляет больше функций.
3. Как работает Spark
3.1 Рабочий процесс и характеристики
Блок-схема работы искры выглядит следующим образом:
1. Создайте рабочую среду приложения Spark и запустите SparkContext.
2. SparkContext применяется к диспетчеру ресурсов (который может быть Standalone, Mesos, Yarn) для запуска 3. ресурсов Executor и запуска StandaloneExecutorbackend.
4. Исполнитель обращается к задаче из SparkContext
5. SparkContext передает приложение исполнителю.
6. SparkContext создается в графе DAG, граф DAG разбивается на этап, набор задач отправляется в задачу 7, планировщик и, наконец, планировщик задач отправляет задачу исполнителю для выполнения
8. Задача запускается на Executor и освобождает все ресурсы после запуска.
3.2 Искровые рабочие характеристики
1. Каждое Приложение получает свой собственный процесс-исполнитель, который всегда находится во время Приложения и запускает Задачу в многопоточном режиме. Этот вид механизма изоляции приложений имеет преимущества, будь то с точки зрения планирования (каждый драйвер планирует свои собственные задачи) или с точки зрения эксплуатации (задачи из разных приложений выполняются в разных JVM), конечно, это означает, что Spark Приложение не может обмениваться данными между приложениями, если данные не записаны во внешнюю систему хранения.
2. Spark не имеет ничего общего с диспетчером ресурсов, пока он может получить процесс Executor и поддерживать связь друг с другом.
3. Клиент, отправляющий SparkContext, должен находиться близко к рабочему узлу (узлу, на котором запущен Executor), предпочтительно в той же стойке, потому что между SparkContext и Executor происходит большой обмен информацией во время работы Spark Application.
4. Задача использует механизм оптимизации локальности данных и спекулятивного исполнения.
3.3 Общие термины
Application: Приложение относится к приложению Spark, написанному пользователем, включая код функции драйвера и код исполнителя, работающие на нескольких узлах в кластере.
Cluster Manager: Относится к внешней службе, которая получает ресурсы в кластере. В настоящее время существует три типа:
1. Автономность: собственное управление ресурсами Spaark, Мастер отвечает за распределение ресурсов.
2. Apache Mesos: структура планирования ресурсов с хорошей совместимостью с hadoop MR.
3. Hadoop Yarn: в основном относится к ResourceManager в Yarn.
Worker: Любой узел в кластере, который может запускать код приложения. В автономном режиме это относится к рабочему узлу, настроенному через подчиненный файл. В режиме Spark on Yarn это узел NoteManager.
Task: Единица работы, отправляемая определенному исполнителю, но MapTask в HadoopMR такая же, как и концепция ReduceTask. Это базовая единица работы приложения. Несколько задач образуют этап. Планирование задач и управление ими осуществляется TaskScheduler.
Job: Параллельные вычисления, состоящие из нескольких задач, часто запускаются Spark Action, а несколько заданий часто создаются в одном приложении.
DAGScheduler: Построить DAG на основе этапа (направленный ациклический граф) на основе задания и отправить этап в TASKScheduler. Разделение Stage основано на соотношении зависимости между RDD для поиска наименее затратного метода планирования, как показано ниже.
TASKScheduler: Отправьте TaskSET рабочему для выполнения. Задача, которую выполняет каждый исполнитель, назначается здесь. TaskScheduler поддерживает все TaskSets. Когда тактовая частота Executor отправляется на драйвер, TaskScheduler распределяет соответствующие задачи в соответствии с оставшимися ресурсами. Кроме того, TaskScheduler также поддерживает запущенные теги всех задач, повторяя неудачные задачи.На следующем рисунке показана роль TaskScheduler:
В разных режимах работы планировщик задач:
Схема текущей иерархии, которая связывает эти термины вместе, выглядит следующим образом:
3.4 Режим работы Spark
Режимы работы Spark разнообразны и гибки. При развертывании на одной машине он может работать как в локальном, так и в псевдораспределенном режиме. При развертывании в распределенном кластере также доступно множество режимов работы. Выбор зависит от фактической ситуации в кластере.Основное планирование ресурсов может полагаться на структуру планирования внешних ресурсов или использовать автономный режим, встроенный в Spark.
Для поддержки структуры планирования внешних ресурсов текущие реализации включают относительно стабильный режим Mesos и режим HADOoop YARN.
Локальный режим: часто используется для локальной разработки и тестирования, локальный также делится на локальный и локальный кластер.
3.4.1 standalone: автономный режим работы кластера
В автономном режиме используется собственная структура планирования ресурсов Spark.
Используя типичную архитектуру Master / Slaver, выберите ZooKeeper для достижения высокой доступности Master.
Основными узлами этого режима являются клиентский узел, главный узел и рабочий узел. Драйвер может работать на главном узле или на стороне локального клиента. При использовании интерактивного инструмента Spark-Shell для отправки задания Spark драйвер запускается на главном узле;
1. SparkContext подключается к мастеру, регистрируется на мастере и запрашивает ресурсы (ядро процессора и память).
2. Мастер решает, какой воркер выделять ресурсы на основе требований к ресурсному приложению SparkContext и информации, сообщаемой в цикле пульса рабочего, затем получает ресурсы у воркера и затем запускает StandaloneExecutorBackend;
3. StandaloneExecutorBackend зарегистрирован в SparkContext;
4. SparkContext отправляет код приложения в StandaloneExecutorBackend, а SaprkContext анализирует код приложения, строит диаграмму DAG и отправляет ее планировщику DAG, чтобы разложить ее на этап (когда он встречает операцию действия, он порождает задание; каждое задание содержит 1 или более Стадия, которая обычно создается между получением внешних данных и перемешиванием), а затем отправляется в планировщик задач как стадия (или называется набором задач). Планировщик задач отвечает за назначение задачи соответствующему рабочему процессу и, наконец, отправку его на выполнение в StandaloneExecutorBackend;
5. StandaloneExecutorBackend создаст пул потоков Executor, начнет выполнение задачи и отчитается в SparkContext, пока задача не будет завершена.
6. После выполнения всех задач SparkContext выходит из системы Maxter и освобождает ресурсы.
3.5 процесс работы СДР
RDD, выполняемый в Spark, можно условно разделить на следующие три этапа:
1. Создайте объекты RDD
2. Модуль DAGScheduler вмешивается в вычисления, чтобы вычислить зависимости между RDD, а зависимости между RDD образуют DAG.
3. Каждое задание разбито на несколько этапов. Основным основанием для разделения этапа является то, определен ли ввод текущего расчетного коэффициента, и если это так, он делится на один этап, чтобы избежать накладных расходов на передачу сообщений между несколькими этапами.
Образец изображения выглядит следующим образом:
Ниже приведен пример сортировки по инициалам от A до Z и нахождения общего количества разных имен под одними и теми же инициалами, чтобы увидеть, как работает RDD.
Spark создаст план выполнения как можно более конвейерным и разделит этапы в зависимости от того, нужно ли реорганизовать данные.Например, преобразование groupBy () в этом примере разделит весь план выполнения на два этапа для выполнения. В конечном итоге DAG (направленный ациклический граф, направленный ациклический граф) будет создан как логический план выполнения.
Планирование задач. Разделите каждый этап на разные задачи (задачи), каждая задача представляет собой комбинацию данных и расчета. Прежде чем перейти к следующему этапу, необходимо выполнить все задачи текущего этапа. Поскольку первое преобразование следующего этапа должно заключаться в реорганизации данных, все данные результатов текущего этапа должны быть рассчитаны, прежде чем он сможет продолжаться.
4. Зависимости RDD
Узкая зависимость (также называемая узкой зависимостью)
С точки зрения родительского RDD: родительский RDD используется только дочерним разделом RDD. Каждый раздел родительского RDD может использоваться не более чем одним разделом дочернего RDD.
С точки зрения sub-RDD: часть раздела, которая опирается на RDD верхнего уровня.Если вы точно знаете зависимый RDD-раздел верхнего уровня, вы выберете раздел RDD верхнего уровня на том же узле, что и вы, без накладных расходов сетевого ввода-вывода и эффективно. Такие как карта, плоская карта, фильтр
Широкая зависимость (также называемая зависимостью перемешивания / широкой зависимостью)
С точки зрения родительского RDD: родительский RDD используется несколькими дочерними разделами RDD. Каждый раздел родительского RDD может зависеть от нескольких дочерних разделов RDD.
С точки зрения sub-RDD: все разделы, зависящие от RDD верхнего уровня, не могут точно определить местонахождение зависимого RDD-раздела верхнего уровня, что эквивалентно использованию всех разделов (например, reduceByKey). Расчет включает передачу данных по сети между узлами
Spark делит зависимости на узкие и случайные:
(1) Узкие зависимости могут поддерживать выполнение нескольких команд последовательно в форме конвейера на одном и том же кластере Executor.Например, после выполнения карты немедленно выполнить фильтр. Вычисление в разделах сходится, не полагаясь на данные всех разделов, и вычисления могут выполняться на разных узлах параллельно. Таким образом, его восстановление после сбоя также более эффективно, потому что ему нужно только пересчитать потерянный родительский раздел.
(2) Зависимости в случайном порядке требуют, чтобы были доступны все родительские разделы. Вычисление должно быть начато после того, как все данные родительского раздела RDD будут готовы. Также может потребоваться вызвать такие операции, как MapReduce, для передачи между узлами. С точки зрения восстановления после сбоя, случайные зависимости включают несколько родительских разделов на всех уровнях RDD.
5. Разделите сцену
Так как зависимость перемешивания должна ждать, пока все данные родительского раздела RDD RDD будут готовы, прежде чем начинать вычисление, конструкция искры состоит в том, чтобы позволить родительскому RDD записать результат локально и уведомить последующий RDD после того, как он будет полностью записан. Последний RDD сначала считывает предыдущие локальные данные в качестве входных, а затем выполняет операции.
Из-за вышеперечисленных характеристик зависимость перемешивания должна быть разделена на два этапа:
Второй этап (этап) считывает данные для обработки.
Задачи на одном этапе могут выполняться одновременно, и на следующем этапе необходимо дождаться готовности предыдущего этапа.
(Он находится в той же строке, что и сокращение mapreduce, чтобы дождаться готовности процесса карты)
(Зачем писать его локально: эту информацию должны прочитать несколько разделов следующего RDD. Если он помещен в память, если данные потеряны, все последующие шаги не могут быть выполнены, что нарушает вышеупомянутую потребность в данных родительского раздела RDD. Принцип готовности.Зачем проверять, что родительский RDD готов, как в следующем примере, если раздел не создается или теряется в памяти, результат вычисления полностью неверен:
Запись в файл более надежна. Shuffle генерирует большое количество временных файлов, чтобы избежать перерасчета в случае ошибок.Каталог на локальном диске, используемый им, указывается в spark.local.dir, а данные RDD кэшируются на диск. Лучше всего установить этот атрибут на локальный диск с высокой скоростью доступа. Вы можете настроить несколько путей к нескольким дискам для увеличения пропускной способности ввода-вывода.
После Spark 1.0 параметр SPARK_LOCAL_DIRS (автономный, Mesos) или LOCAL_DIRS (YARN) переопределит эту конфигурацию. Например, при использовании Spark On YARN локальный путь Spark Executor зависит от конфигурации Yarn, а не от этого параметра. )
Для операций преобразования, разделенных зависимостями перемешивания, они разделены на разные этапы.
6. DAG
6.1 Что такое DAG
В Spark DAG используется для описания нашей логики вычислений.
Планировщик DAG разделяет DAG на разные этапы в соответствии с действием преобразования RDD, и каждый этап делится на несколько задач, которые могут выполняться параллельно.
6.2 Какую проблему решает DAG
Появление DAG в основном связано с устранением ограничений инфраструктуры Hadoop MapReduce. Итак, каковы ограничения MapReduce?
Выделяют два основных:
Каждая операция MapReduce не зависит друг от друга, и HADOOP не знает, какая операция MapReduce последует за ней.
Выходной результат каждого шага будет сохранен на жестком диске или HDFS.
Если объединить две вышеуказанные характеристики, мы можем представить, что в некоторых итеративных сценариях инфраструктура MapReduce приведет к большим потерям при чтении и записи жестких дисков и HDFS.
И каждый шаг заблокирован на предыдущем шаге, поэтому, когда мы имеем дело со сложными вычислениями, это займет много времени, но объем данных невелик.
Таким образом, в Spark введен DAG, который может оптимизировать план вычислений, например уменьшить количество данных в случайном порядке.
6.3 Как работает DAG
Что такое dag в терминах spark
Вчера мы упоминали, что использование Spark или Tez в качестве движка исполнения SQL-запросов в Apache Hive вместо классического Hadoop MapReduce намного ускоряет аналитику больших данных. Сегодня рассмотрим подробнее, чем отличаются эти механизмы и какой из них выбирать в разных случаях использования.
Что такое Apache Tez и как он работает с Hive в экосистеме Hadoop
Начнем с определения: Apache Tez – это расширяемая open-source платформа создания высокопроизводительных приложений пакетной и интерактивной обработки данных, координируемая YARN в Apache Hadoop. Tez развивает парадигму MapReduce, увеличивая ее скорость и сохраняя способность масштабироваться до огромных размеров [1]. Можно сказать, что в Tez задачи MapReduce объединяются в одно задание, которое рассматривается как узел в DAG, обеспечивая параллелизм и сериализацию [2].
Начиная с версии 0.13, Apache Hive использует именно Tez в качестве движка исполнения SQL-подобных запросов на языке HiveQL, транслируя их в высокооптимизированные DAG-задания, которые обеспечивают эффективный баланс между производительностью, пропускной способностью и масштабируемостью. Таким образом, популярностью Tez частично вызвана распространенностью Apache Hive в качестве востребованного инструмента SQL-on-Hadoop.
Tez моделирует обработку данных как направленный ациклический граф (DAG, Directed Acyclic Graph), где вершины представляют логику приложения, а ребра – движение данных. Богатый Java API позволяет пользователям определять сложную логику запросов, сочетая их с планами выполнения, созданными декларативными приложениями более высокого уровня, такими как Apache Hive.
Таким образом, Tez моделирует пользовательскую логику в каждой вершине DAG-графа как композицию модулей ввода, процессора и вывода. Ввод и вывод определяют формат данных, как и где они читаются или записываются. Процессор содержит логику преобразования данных. Tez не требователен к форматам данных, но необходима совместимость форматов ввода, процессора и вывода.
Распределенная обработка данных носит динамический характер, не позволяя заранее определить оптимальные методы перемещения данных. Tez поддерживает подключаемые модули управления вершинами для сбора информации о времени выполнения SQL-запроса и динамического изменения DAG-графа, чтобы оптимизировать производительность и эффективно использовать ресурсы.
Tez получает ресурсы из Hadoop-менеджера ресурсов YARN и повторно использует каждый компонент в конвейере, избегая дублирования операций без необходимости. Напомним, YARN управляет ресурсами в кластере Hadoop в зависимости от его емкости и нагрузки. Tez следует традиционной модели Hadoop разделения задания на отдельные задачи, каждая из которых запускается как процессы через YARN от имени пользователя. Эта модель сопряжена с внутренними затратами на запуск и инициализацию процессов, обработку отставших задач и выделение каждого контейнера через YARN [1].
Tez предоставляет собственный пользовательский интерфейс, который взаимодействует с YARN Application Timeline Server, чтобы отразить текущий и исторический вид приложений в веб-GUI.
Для корректной работы Apache Hive с Tez нужно задать следующие конфигурации [3]:
Если RAM 256 Гб и 16 ядер CPU, размер контейнера не должен превышать 16 Гб. Также требуется задать еще ряд конфигураций [3]:
Чем похожи Tez и Spark
Фреймворки Spark и Tez имеют следующие одинаковые характеристики:
Однако, при этих общих чертах, рассматриваемые фреймворки существенно отличаются друг от друга в некоторых нюансах, что мы и покажем далее.
5 главных отличий
Ключевыми отличиями Spark от Tez являются следующие [2]:
Что касается быстроты обработки данных, то различные бечмаркинговые тесты показывают разные результаты, в которых побеждает то Spark, то Tez, в зависимости от аффилированности исследователей. Однако, в любом случае оба DAG-движка намного быстрее классического Hadoop MapReduce, который также доступен для исполнения SQL-запросов в Apache Hive [2]. Таким образом, универсального ответа на вопрос «Spark vs Tez» нет, а выбор зависит от особенностей конкретной ситуации. На практике разработчики распределенных приложений чаще выбирают Apache Spark по причине его универсальности и огромного набора функциональных возможностей. О том, зачем использовать внешнюю базу данных для хранилища метаданных Apache Hive и как ее подключить вместо Derby, читайте в нашей новой статье.
Больше подробностей про администрирование и эксплуатацию Apache Hive, а также фреймворка Spark для аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Обработка больших данных: первые шаги в понимании Hadoop MapReduce и Spark
Big Data как концепт довольно понятна, но из-за того, что она включает в себя множество процессов, сложно сказать, с чего именно нужно начать изучение. Как хранятся файлы? Или как получать эти файлы? А может, сразу — как анализировать данные? О своём опыте работе с Big Data и почему Spark лучше, чем Hadoop MapReduce в обработке данных, рассказывает Эмилия Межекова, ETL-developer в Luxoft.
Мой первый опыт
До 2020 года я, как и большинство Python-девелоперов, работала с привычным стеком Python+Django+РСУБД. В этом стеке для меня было многое понятно. Транзакции, обработка на стороне бэкенда, вывод его на фронтенд к пользователю, как РСУБД хранит данные, как подчищает от мусора, какие существуют трюки для оптимизации поиска данных и подобные вещи.
В 2020-м я получила должность ETL-девелопера (от англ. Extract, Transform, Load) в Luxoft. Изначально название этой позиции мне ни о чём не говорило, я только знала, что это связано с Big Data. Этот термин мне был лишь немного знаком, я никогда не интересовалась данным направлением, и мне казалось, что там очень много математики, графиков, расчёта вероятности и так далее. Как оказалось, в Big Data не только данные большие, но и инфраструктура, и найдутся места, где можно применить свои знания и без математики.
Сейчас я работаю в проекте, занимающемся количественными хедж-фондами — инвестиционными фондами, ориентированными на максимизацию доходности участников. Мы анализируем много данных из разных источников: соцсети, новости, транзакции и так далее. На их основе формируются «сигналы» для принятия решения о продаже или покупке акций. В основном я взаимодействую с фреймворком Spark, он служит для обработки данных (you must be joking!). Сначала я использовала его для манипулирования небольшими файлами и добавления определённой логики, это было довольно просто и понятно. Но когда меня пустили на прод, и файлы стали размером под сотни гигабайтов, а обработка этих файлов занимала всего несколько минут, мне стало интересно, как же шестерёнки крутятся внутри.
Я изучала всё довольно сумбурно. Так как я работала немного с Pandas, то команды Spark не казались сложными, потому что они в чём-то схожи. Я изначально читала про него, но очень часто авторы ссылались на Hadoop MapReduce и внесённые по сравнению с этой моделью улучшения. Поэтому я начала изучать Hadoop MapReduce. В итоге у меня есть представление о том и другом направлении, поэтому я решила рассказать, что лучше подходит для обработки данных.
Структура Big Data
Выше показана экосистема больших данных и примеры инструментов, которые можно использовать для каждой группы. Выглядит устрашающе, но нам нужно разобраться лишь в том, как именно данные обрабатываются, — вернее, рассмотреть два варианта, как это можно сделать с помощью следующих фреймворков: Hadoop MapReduce и Apache Spark.
Hadoop MapReduce и что его окружает
Apache Hadoop — инфраструктура, упрощающая работу с кластерами. Основные элементы Hadoop — это:
распределённая файловая система (HDFS);
метод крупномасштабного выполнения программ (MapReduce).
HDFS — распределённая файловая система Hadoop для хранения файлов больших размеров с возможностью потокового доступа к информации, поблочно распределённой по узлам вычислительного кластера. Здесь мы храним, читаем, записываем и перекладываем данные.
MapReduce — модель распределённых вычислений, представленная компанией Google, используемая для параллельных вычислений над очень большими, вплоть до нескольких петабайт, наборами данных в компьютерных кластерах.
Алгоритм легко понять по аналогии:
Представьте, что вам предложено подсчитать голоса на национальных выборах. В вашей стране 25 партий, 2500 избирательных участков и 2 миллиона граждан. Как это можно сделать? Можно собрать все избирательные бюллетени со всех участков и подсчитать их самостоятельно, либо приказать каждому избирательному участку подсчитать голосов по каждой из 25 партий и передать вам результат, после чего объединить их по партиям.
Ниже представлена схема выполнения данного алгоритма на примере подсчёта слов в выборке.
Разберём, что происходит, по этапам;
Input — входные данные для обработки;
Splitting — разбивка данных на порционные данные;
Mapping — обработка этих порционных данных воркерами (вычислительными процессами) в формате ключ-значение. Для этого алгоритма ключ — слово, значение — количество вхождений данного слова;
Shuffling — ключи сортируются, чтобы упростить обобщение данных и сделать всю работу в одном воркере, не раскидывая их по разным местам;
Reducing — после того, как мы посчитали количество одинаковых слов на каждом отдельном воркере, объединяем их вместе.
Между этапами происходит запись промежуточных данных на диск, воркеры и данные обособлены друг от друга. Данный алгоритм отлично подходит для кластеров. Подсчёт происходит в разы быстрее, чем на одной машине.
Но есть и недостатки, обусловленные архитектурными особенностями этой вычислительной модели:
недостаточно высокая производительность: классическая технология, в частности, реализованная в ядре Apache Hadoop, обрабатывает данные ациклично в пакетном режиме. При этом функции Reduce не запустятся до завершения всех процессов Map. Все операции проходят по циклу чтение-запись с жёсткого диска, что влечёт задержки в обработке информации;
ограниченность применения: высокие задержки распределённых вычислений, приемлемые в пакетном режиме обработки, не позволяют использовать классический MapReduce для потоковой обработки в режиме реального времени повторяющихся запросов и итеративных алгоритмов на одном и том же датасете, как в задачах машинного обучения. Для решения этой проблемы, свойственной Apache Hadoop, были созданы другие Big Data – фреймворки, в частности Apache Spark;
программисту необходимо прописывать код для этапов Map и Reduce самостоятельно.
Apache Spark
В своей работе мне приходится очень часто писать SQL-запросы и смотреть, какие данные приходят на вход и что внутри них хранится. Для этих целей мне хочется, чтобы инструмент был более интерактивным и не приходилось ждать выполнения запроса часами (но скорость зависит от количества данных, естественно). В этом поможет Spark, он работает намного быстрее Hadoop MapReduce.
Spark — инфраструктура кластерных вычислений, сходная с Hadoop MapReduce. Однако Spark не занимается ни хранением файлов в файловой системе, ни управлением ресурсами. Spark обрабатывает данные ещё быстрее с помощью встроенных коллекций RDD (Resilient Distributed Datasets), которые дают возможность выполнять вычисления в больших кластерах. Благодаря RDD можно совершать такие операции, как map, join, reduce, записывать данные на диск и загружать их.
Добавлю таблицу для сравнения Hadoop MapReduce и Spark.
Но как же достигается данное ускорение? Ниже представлены самые значимые решения в архитектуре Spark.
Промежуточные данные вычислений не записываются на диск, а образуют своего рода общую оперативную память. Это позволяет разным рабочим процессам использовать общие переменные и их состояния.
Отложенные вычисления: Spark приступает к выполнению запроса лишь при непосредственном обращении к нему (вывод на экран, запись конечных данных на диск). В этом случае срабатывает планировщик, соединяя все преобразования, написанные ранее.
Из-за некоторых архитектурных особенностей Hadoop MapReduce уступает по скорости Spark. Для своих задач я выбрала Spark, потому что при моём наборе данных и итерациях он работает быстрее. Мне было интересно посмотреть, что было до инструмента, которым я пользуюсь, и каким образом всё развивалось. Это лишь общее описание работы этих фреймворков, дающее немного понять, как всё внутри обрабатывается. Зная, как работает тот и другой алгоритм, вы теперь можете выбрать для себя подходящий.
