Spark и 100000k последовательных HTTP-вызовов: драйвер против рабочих

Question

Мне нужно сделать 100000 последовательных HTTP-запросов с Spark.Я должен хранить ответы в S3.Я сказал «последовательно», потому что каждый запрос возвращает около 50 КБ данных, и мне нужно держать 1 секунду, чтобы не превышать ограничения скорости API.

Где выполнять HTTP-вызовы: из кода Spark Job (выполняется на узле драйвера / мастера) или из преобразования набора данных (выполняется на рабочем узле)?

Временные решения

1. Сделайте HTTP-запрос из моего задания Spark (на узле Driver / Master), создайте набор данных каждого HTTP-ответа (каждый содержит 5000 элементов json) и сохраните каждый набор данных в S3 с помощью spark.Вам не нужно хранить набор данных после того, как вы сохранили его
2. Создать набор данных из всех 100000 URL-адресов (перенести все дальнейшие вычисления на рабочих), сделать HTTP-запросы внутри map или mapPartition, сохранить один набор данных в S3.

Первый вариант

Он проще и отражает характер моих вычислений - они последовательные из-за задержки в 1 секунду.Но:

1. Плохо ли делать 100_000 HTTP-вызовов от узла Driver / Master?
2. * Более эффективно создавать / сохранять один 100_000 * 5_000чем создание / сохранение 100_000 небольших наборов данных размером 5_000 *
3. Каждый раз, когда я создаю набор данных из ответа HTTP - я перемещаю ответ на рабочий, а затем сохраняю его в S3, верно? Doubleshuffling than ...

Второй вариант

На самом деле параллельная обработка не принесет пользы, поскольку при запросе необходимо сохранять интервал в 1 секунду.Единственным бонусом является перемещение вычислений (даже если они не слишком сложные) от водителя.Но:

1. Стоит ли переносить вычисления на рабочих?
2. Хорошая идея сделать вызов API внутри преобразования?

Answer 1

Сохранение файла <32 МБ (или любого другого размера файла fs.s3a.block.size) на S3 составляет ~ 2xGET, 1xLIST и PUT;AWS платит вам немного за каждый из этих вызовов, плюс затраты на хранение. </p>

Для больших файлов - POST для инициирования многоэтапной загрузки после этого первого блока, один POST на 32 МБ (очевидно, 32 МБ) иокончательный POST JSON-файла для завершения.Итак: немного более эффективный

Там, где в счетах от AWS и последующих спарк-запросов важны малые размеры S3: все, что вы используете в spark, pyspark, SQL и т. Д., Много маленьких файлов медленнее: в листинге стоит дорогофайлы в S3, и каждая задача, выдаваемая работнику Spark, требует определенных затрат на настройку / принятие / завершение.

в отношении выполнения вызовов HTTP API внутри работника, ну, вы можете делать там забавные вещи.Если результат не может быть воспроизведен, то сбои и повторные попытки могут дать неверные ответы, но для GET все должно быть в порядке.Трудно душить работу;Я оставлю вас, чтобы придумать стратегию там.

Вот пример загрузки файлов в S3 или другое хранилище объектов в рабочих ;сначала создается СДР операций копирования src / dest, затем они передаются рабочим.Результат рабочего кода включает в себя информацию о продолжительности загрузки, если кто-то когда-либо хотел попытаться агрегировать статистику (хотя там вам, вероятно, понадобится временная метка для просмотра некоторого временного ряда)

Учитывая, что вам нужно сериализовать работуна один запрос / секунду, 100 000 запросов будут занимать более одного дня.если каждый запрос занимает <1 секунду, вы можете запустить его на одной машине.Важным является постепенное сохранение работы, чтобы в случае сбоя вашей работы на полпути вы могли перезапустить с последней контрольной точки.Я бы лично сосредоточился на этой проблеме: как можно выполнить эту операцию так, чтобы каждые 15-20 минут работы были сохранены, и при перезапуске вы могли бы продолжить оттуда. </p>

Spark не обрабатывает восстановлениепроваленная работа, только провалы задачи.Потерять драйвер и вы перезапустите свой последний запрос.Разбейте все на части.

Что-то, что приходит на ум, может быть следующим: * сначала СДР берет список запросов и некоторую сводную информацию о любых существующих данных контрольных точек, вычисляет следующие 15 минут работы, * формирует список вызовов GETделегировать 1+ работнику.Либо 1 URL / строка, либо несколько URL в одной строке * запустите это задание, сохраните результаты * тестовое восстановление работает с меньшим окном и убивает вещи.* однажды довольный: сделайте полный прогон

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