Назад | Перейти на главную страницу

Рекомендации по распределенной обработке / распределенным системам хранения

В моей организации есть система обработки и хранения, распределенная на двух дюжинах Linux-машин, которая обрабатывает петабайт данных. Система сейчас очень специальная; автоматизация обработки и управление данными осуществляется с помощью набора больших программ Perl на независимых машинах. Я ищу распределенные системы обработки и хранения, чтобы упростить их обслуживание, равномерно распределить нагрузку и данные с помощью репликации, а также увеличить объем дискового пространства и вычислительную мощность.

Система должна иметь возможность обрабатывать миллионы файлов, размер которых варьируется от 50 мегабайт до 50 гигабайт. После создания файлы не будут добавлены, а будут заменены полностью, если это необходимо. Файлы должны быть доступны через HTTP для загрузки клиентом.

Прямо сейчас обработка автоматизирована с помощью сценариев Perl (которые я полностью контролирую), которые вызывают ряд других программ (которые я не контролирую, поскольку они являются закрытым исходным кодом), которые по существу преобразуют один набор данных в другой. Здесь не происходит интеллектуального анализа данных.

Вот краткий список того, что я ищу:

Вот что я до сих пор рассматривал:

Управление хранилищем:

Распределенная обработка:

Обе:

Есть ли у кого-нибудь мнения или рекомендации по технологиям, которые подходят для моей проблемы? Будем очень признательны за любые предложения или советы.

Спасибо!

Похоже, вы почти достигли того, что вам нужно. Существующие технологии (GlusterFS, GPFS) имеют функции, которые вы ищете, но не функцию локализации данных. В зависимости от того, что вы делаете с данными, это может быть встроено в диспетчер заданий.

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

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


Первая идея, когда данные поступают из вашего источника, они копируются в Gluster / GPFS / любую распределенную файловую систему. Затем запустите процесс индексации, описанный выше. Затем, когда рабочие обрабатывают данные, обработанные наборы данных возвращаются на другую группу серверов, роль которых заключается в обслуживании обработанных данных по HTTP. Метод обратного отчета может даже быть выполнен через HTTP PUT, который затем отбрасывает данные в другую реплицированную файловую систему. Недостатком этого метода является то, что он сохраняет ваши данные дважды (исходные и измененные), но я не знаю, что вы уже делаете. Это позволяет значительно масштабировать инфраструктуру обработки, сохраняя при этом инфраструктуру обслуживания клиентов разумно небольшой.


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


Третья идея: если выяснить местонахождение данных GPFS / Gluster на самом деле невозможно (я их не использовал, поэтому я не уверен), вы можете захотеть создать свой собственный тип хранилища. Это большая работа, но, если вам действительно нужна местность, она того стоит. По мере приема данных каждый набор данных индексируется в базе данных и HTTP PUT PUTED на несколько узлов по мере необходимости. Когда происходит обработка, для отдельных узлов создаются задания для данных, которые в первую очередь являются локальными для них самих. Когда рабочий получает задание, он HTTP ПОЛУЧАЕТ данные из узла, указанного в базе данных (который должен быть самим собой, но не обязательно). Когда работа завершена, он уведомляет базу данных и получает инструкции о том, куда ПОСТАВИТЬ результаты.

Для обслуживания обработанных наборов данных клиентам вам, вероятно, придется ввести некоторый код приложения для преобразования файлов для выборки в прокси-запросы HTTP GET с ваших узлов.

Это действительно представляет часть процесса с высокой пропускной способностью в виде этой базы данных. Перед ним может быть несколько веб-серверов с балансировкой нагрузки для логики обработки, но сама база данных в конечном итоге становится единственной точкой отказа (хотя люди, более осведомленные о способах баз данных, могут знать способы решения этой проблемы) . База данных, по сути, действует как таблица размещения файлов для большой файловой системы на основе HTTP. Поскольку ваша обработка, похоже, требует очень простой семантики файловой системы (выборка / установка, возможно, блокировка / разблокировка для узла, обрабатывающего набор данных), которая может быть опосредована такой базой данных. Очевидно, что эта БД будет очень большой, поэтому некоторые технологии NoSQL могут лучше подходить по соображениям производительности.


Я знаю, что это не те конкретные технологии, которые вам нужны, это больше о методах устранения недостатков на рынке. Похоже, локальность данных и репликация - это своего рода крайний случай. Так получилось, что мы делаем что-то похожее на вас, только с небольшими наборами данных, поэтому я тоже думаю об этом.