Операция записи Spark с использованием временных каталогов

Question

Согласно этому блогу в кирпичах данных, spark полагается на классы протоколов фиксации из Hadoop, поэтому, если задание не завершено из-за некоторого сбоя, выходной каталог не изменяется (частичные выходные файлы не появляются).

Итак, мои вопросы:

Предотвращает ли искра частичную запись в разные хранилища в случае сбоев (HDFS, S3 и т. Д.)?

Возможно ли использование разных заданий зажиганиято же самое временное местоположение перед последней операцией записи?

Возможно ли для одного и того же задания зажигания, которое отправлено более одного раза, использовать одно и то же временное местоположение?

Answer 1

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

Алгоритм Hadoop V1

HDFS: O(1) для фиксации задачиУстойчив к отказу в задаче коммита.Фиксация задания ~ 1006 * с большим количеством файлов;если он завершается неудачно на полпути, состояние вывода неизвестно.

S3: O(data) для принятия задания, очень медленное для выполнения задания (O(data) для вывода всего задания).Отсутствие атомарного переименования потенциально опасно.

Алгоритм фиксации Hadoop V2

HDFS: O(files) для фиксации задачи, не может обработать сбой.Передача задания - это вызов O (1) touch _SUCCESS.S3: O(data) для фиксации задачи, не может обработать сбой, и с более длинной операцией COPY для фиксации вероятность сбоя фиксации задачи выше.

Лично я не считаю семантику сбоя V2алгоритм работы;и MapReduce, и Spark предполагают, что задача, которая не выполняется во время процесса фиксации, может быть повторена ... этого здесь нет.

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

Для хранилищ объектов:

• Блок данных DBIO.Не видно кода, похоже, что они используют DynamoDB для XAs.
• IBM Stocator: прочитайте статью, Stocator: Высокопроизводительный коннектор хранилища объектов для Spark .Основное внимание уделяется минимизации HTTP-запросов и возможности отката от неудачных фиксаций задания / задачи.
• Коммиттеры S3A Hadoop 3.1, читайте: Коммиттер с нулевым переименованием .Время на выполнение задачи зависит от того, какой коммиттер выбран;в худшее время для загрузки данных с ВМ на S3.Сбои задач восстанавливаются.Фиксация задания: один * HTTP POST на файл создан, распараллелен, поэтому O(files/threads).Ошибка во время выполнения задания не подлежит восстановлению.

Округлить вещи;У облачных хранилищ Azure и Google есть переименования каталогов, хотя обычно это O (файлы), а не O (1), но, по крайней мере, не O (данные), как S3.Вы можете безопасно использовать коммиттер Hadoop V1.

Answer 2

Все вышеперечисленные фиксации транзакции spark могут применяться только к hdfs, поскольку существует концепция переименования каталога.В s3 нет концепции переименования, поэтому после записи данных во временную папку s3 они снова копируют эти данные в новую папку (в s3 Double copy)

Предотвращает ли искра частичную запись в различные хранилища в случае сбоев (HDFS, S3 и т. Д.)?

Нет, Spark не предотвращает отдельные записи в случае сбоя, нам нужно обрабатывать их вручную

Возможно ли для разных заданий спарка использовать одно и то же временное местоположение перед завершающей операцией записи?

Временное расположение находится в конечной папке назначения с именем temp в качестве подпапки

Возможно ли для одного и того же задания зажигания, которое отправлено более одного раза, использовать одно и то же временное местоположение?

Да, они используют outfolder / temp в качестве пункта назначения