Week 2

Курс Scalable Machine Learning.

В прошлый раз я рассказал о том, что было на первой неделе – вводная часть.

Теперь материал второй недели – Introduction to Apache Spark.

Topics:

• Big data and hardware trends,
• history of Apache Spark,
• Spark's Resilient Distributed Datasets (RDDs),
• transformations, and actions.

Lab 2: Learning Apache Spark.

... you will learn about the Spark data model, transformations, and actions, and write a word counting program to count the words in all of Shakespeare's plays.

BigData.

Начали с того, что рассказали нам (а то мы не знаем) как количество данных растет такими темпами, что сохранять не успеваем, не то что обрабатывать.

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

Кстати, никто не почесался задать вопрос: а как оптимизировать отношение количество узлов кластера/мощность отдельного узла.

Хорошо, кластер. Но как справляться с отказами узлов, слабой пропускной способностью сети и, в общем случае, с различающимися характеристиками узлов? Ответ: создать фреймворк, берущий на себя все эти заботы. Сеть это компьютер.

MapReduce.

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

Если какой-то узел отвалился, его задача перезапускается на другом узле, всего делов-то.

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

Hadoop MapReduce, как нам сказали, отличается тем, что для каждой задачи на каждом узле данные считываются и выводятся через диск – долговременную память.

А вот Spark победил эту проблему (проблема с итеративными задачами, частыми в ML – постоянный I/O с диском = тормоза) тем, что датасеты держит в оперативке. И это на некоторых задачах дает возможность получать результат в сто раз быстрее.

Apache Spark.

Короче, в двух словах, как работает Spark:

Берем датасет, разделяем его на коллекции объектов, распределенные по сети, получаем RDD.

Пишем программы обработки в терминах операций над распределенными данными.

Эти операции манипулируют RDD и состоят из трансформаций (превращение одного датасета в другой) и действий (финальная сборка результата).

RDD автомагически восстанавливаются при сбоях узлов.

Больше деталей.

Программа для Spark состоит из двух частей: driver и workers. Драйвер запускает задачу и собирает результаты. Воркеры обрабатывают части датасета на узлах.

Все крутится вокруг RDD и SparkContext. Контекст определяет конфигурацию кластера, что-то вроде коннекта к БД.

RDD – это основной примитив. Датасет иммутабельный, отслеживаемый с целью восстановления при сбое узлов, параллелизуемый.

РДД создается из коллекций (в нашем случе списки Python), трансформацией других РДД или загрузкой файлов с данными из HDFS или из других хранилищ.

Трансформации РДД ленивы. Они не выполняются до тех пор, пока действие (акция) не потребует вычисленных данных.

Spark может выполнять операции с элементами данных в виде key-value. В нашем случае (Python) это tuple (key, value).

Самые известные трансформации с парами, это

• reduceByKey
• sortByKey
• groupByKey

При этом последняя, groupByKey, самая тупая – приводит к перетасовке всего датасета так, чтобы на воркерах оказались записи с одинаковыми ключами. Грубо говоря, через сеть будет пропущен весь датасет. А это очень долго – терабайты и петабайты данных.

Коммуникации.

Проблема: как передавать данные данные между узлами, помимо датасетов RDD?

PySpark создает для каждого воркера, для каждой задачи closure. Это функции, выполняемые над RDD и используемые в функциях глобальные переменные. Но воркеры не могут писать в глобальные переменные. Опять же, глобальные переменные каждый раз засылаются на воркеры, дорого делать их большими.

Решение проблемы. Есть shared variables. Broadcast and Accumulators.

Бродкасты предназначены для отсылки на воркеров больших объемов данных. Только чтение.

Аккумуляторы нужны для сбора данных на драйвере от воркеров.

Что-то много выходит. Про лабораторку напишу в следующий раз.

original post http://vasnake.blogspot.com/2015/08/week-2.html