Попытка распределить обработку данных по кластеру, а затем объединить ее в master

Question

Сейчас у меня есть Python Приложение, которое запускает 50 потоков для обработки данных. Он берет файл xlsx, обрабатывает список значений и выводит простое csv.

Я сказал себе, поскольку это простое приложение Python с 50 потоками. Как я могу создать кластер? распределить обработку данных еще больше? ПРИМЕР: пусть каждый рабочий узел обрабатывает подмножество, данное ему мастером. Ну, это звучит просто, просто возьмите мастер-приложение и срежьте созданный набор данных, а затем отправьте его sh рабочим с балансировкой нагрузки.

Как мне получить результаты? Я хотел бы взять все результаты (в данном случае out.csv) и вернуть их мастеру и объединить их, чтобы создать 1 master_out.csv

Сначала я думал о рое Docker, но никто я знаю, использует их, все, кроме простого docker контейнера выгружается в K8.

Сейчас у меня есть простая файловая структура:

app/
  __init__.py (everything is in this file)
  dataset.xlxs
  out.csv

Я думал создать docker образа, чтобы я мог переместить это приложение в образ, обновить / обновить, установить python3, если это еще не сделано, а затем просто запустить это приложение.

Я начал углубляться в обработку и понял, что, вероятно, есть некоторые встроенные способы справиться с этим. создайте приложение flask для обработки проглатывания, а затем приложение flask на главном компьютере для приема файлов по завершении и т. д. c .... Но тогда ведущему необходимо знать всех рабочих и т. д. c.

• Я думал о создании кластера.
• Главный узел имеет доступ к тому, который содержит файл, который мне нужно обработать.
• Балансировка нагрузки выдвигает части каждого файла ( ROWS / NUM_WORKERS) к каждому узлу.
• После окончания WORKERS FINI SH мастер объединяет полученные CSV-файлы, чтобы создать мастер-файл.
• Master_OUT.csv будет существовать в папке для использования.

Таким образом, кластер включится, и когда все будет готово, все запустится, а затем завершится. Поскольку они хотят, чтобы кластер, вероятно, был распределен, я не уверен, как это будет работать, хотя обработка имеет ограничения IP-адресов. Кажется, что это не будет работать в локальном кластере, потому что машины, используемые для ссылки, будут сталкиваться с облачной вспышкой (или подобной) после достаточного количества запросов, поэтому я пытаюсь придумать УНИКАЛЬНОЕ IP-решение.

У меня есть идея для архитектуры, но я не уверен, должен ли я создать dockerfile для этого, а затем выяснить, как kube может справиться со всем этим для меня. Хотя я думаю, что в конфигурационных файлах kube мы можем поместить удаленные aws экземпляры для входа в систему, чтобы он раскручивал все удаленные серверы.

Пока я что-то делал с Swarms, кажется, что kube - это где настоящая работа сделана, поскольку рои, кажется, лучше подходят для других вещей.

Я пытаюсь придумать, как бы я подошел к этому с точки зрения куба (или роя).

Учитывая информация, эта концепция напоминает мне меньше о балансировке нагрузки из-за агрегации данных и больше напоминает Kubeflow, где вы создаете CLOUD специально для ML, но вместо ML это будет ЛЮБОЙ распределенная обработка.

Answer 1

Интересные проблемы в этом вопросе не имеют ничего общего с Docker; Давайте пока отложим это в сторону.

Вы ожидаете, что у вас будет куча компьютеров, которые все обрабатывают кусок этого большого набора данных. Вы уже структурировали проблему так, чтобы вы могли работать с небольшими частями входных данных и создавать небольшие куски выходных данных. Основные проблемы, которые вам нужно спроектировать:

1. Где вы храните ввод, чтобы задачи могли его прочитать, если это необходимо?
2. Как вы передаете единицы работы для рабочих? Что произойдет, если работник выйдет из строя?
3. Как вы сообщаете результаты? Где вы храните их? Должны ли они быть в том же порядке, что и входные данные?

Полезным инструментом здесь является рабочая очередь; RabbitMQ - популярная реализация с открытым исходным кодом. Вы запускаете его как отдельный сервер, и работники могут подключаться к нему и читать и писать сообщения из очередей. До тех пор, пока каждый может связаться с сервером RabbitMQ, ни одному из отдельных рабочих или других процессов в системе на самом деле не нужно знать друг о друге.

Для некоторых масштабов проблемы простой подход заключается в том, чтобы сказать исходный ввод и окончательный вывод - отдельные файлы в одной системе. Вы разбиваете это на части, которые достаточно малы, чтобы они могли уместиться в полезной нагрузке сообщения, а ответы также уместились в полезной нагрузке сообщения. Запустите один процесс, чтобы прочитать ввод и заполнить рабочие очереди; запустить некоторое количество рабочих и запустить процесс для считывания выходных данных.

Input handler      +------+ --> worker --> +------+
dataset.xlsx  ---> +------+ --> worker --> +------+ --> Output handler
                   +------+ --> worker --> +------+     out.csv
                   +  ... +      ...       + ...  +

Если вы используете Python в качестве языка реализации, также рассмотрите Celery в качестве фреймворка чтобы управлять этим.

Чтобы запустить это, вам нужно запустить три отдельных процесса.

export RABBITMQ_HOST=localhost RABBITMQ_PORT=5672
./input_handler.py dataset.xlsx
./output_handler.py out.csv
./worker.py

Вы можете запустить несколько рабочих; RabbitMQ позаботится о том, чтобы задачи распределялись по рабочим, а задача повторялась в случае сбоя рабочего. Нет особого требования, чтобы все они выполнялись на одном хосте, если они все могут обращаться к брокеру RabbitMQ.

Если вы не можете сохранить входные или выходные данные в сообщении, вам понадобятся некоторые своего рода общее хранилище, доступное для всех узлов. Если вы находитесь в облачной среде, сервис хранилища объектов, такой как Amazon S3, является популярным выбором. Во входных и выходных сообщениях вы затем указали бы путь соответствующего файла в S3 вместо данных.

Как бы Docker или Kubernetes вписались бы в эту картину? Важно отметить, что ни одна из технологий не предоставляет ничего похожего на рабочую очередь, и совместно используемые файловые системы могут быть нечеткими. Тем не менее, где я упомянул три разных процесса выше, вы могли бы упаковать их в три Docker образа и развернуть их в Kubernetes. Там, где я сказал, что вам не нужно запускать только одного работника, развертывание Kubernetes позволит вам запустить 5, 10 или 50 идентичных копий работника, а RabbitMQ возьмет на себя ответственность за то, чтобы у всех была работа.