Работая над проектами, которые часто называют «средними данными», я смог распараллелить мой код (в основном для моделирования и прогнозирования в Python) в одной системе в любом месте от 4 до 32 ядер. Сейчас я смотрю на масштабирование до кластеров в EC2 (возможно, с помощью StarCluster / IPython, но также и для других предложений) и был озадачен тем, как согласовать распределение работы по ядрам в экземпляре и экземплярах в кластере.
Является ли практичным даже распараллеливание между экземплярами, а также между ядрами в каждом экземпляре? Если да, может ли кто-нибудь кратко рассказать о плюсах и минусах запуска множества экземпляров с несколькими ядрами в каждом по сравнению с несколькими экземплярами со многими ядрами? Существует ли эмпирическое правило для выбора правильного соотношения между экземплярами и ядрами для каждого экземпляра?
Пропускная способность и оперативная память - нетривиальные проблемы в моих проектах, но легко заметить, когда это узкие места и перестройка. Я полагаю, гораздо сложнее сравнить правильное сочетание ядер с экземплярами без повторного тестирования, и мои проекты слишком сильно различаются, чтобы какой-либо отдельный тест можно было применять при любых обстоятельствах. Заранее спасибо, и если я только что не смог правильно его найти, не стесняйтесь указывать мне правильный ответ где-нибудь еще!
Общее правило - не распространять, пока не придется. Обычно более эффективно иметь N серверов определенной емкости, чем 2N серверов вдвое меньше. Доступ к данным будет в большей степени локальным и, следовательно, быстрым в памяти по сравнению с медленным в сети.
В определенный момент масштабирование одной машины становится неэкономичным, поскольку стоимость дополнительных ресурсов масштабируется более чем линейно. Однако эта точка все еще удивительно высока.
В частности, на Amazon экономия каждого типа экземпляра может сильно различаться, если вы используете экземпляры спотового рынка. Цены по умолчанию более или менее означают, что один и тот же объем ресурсов стоит примерно одинаково, независимо от типа экземпляра, который может сильно различаться; большие экземпляры могут быть дешевле, чем маленькие, или N маленьких экземпляров могут быть намного дешевле, чем один большой компьютер с эквивалентными ресурсами.
Одним из важных соображений здесь является то, что вычислительная парадигма может сильно измениться при переходе с одной машины на несколько машин. Компромиссы, возникающие из-за накладных расходов на связь, могут заставить вас, например, принять параллельную для данных парадигму для масштабирования. Это означает другой выбор инструментов и алгоритмов. Например, SGD выглядит совсем иначе в памяти и в Python, чем в MapReduce. Таким образом, вы должны рассмотреть это перед распараллеливанием.
Вы можете распределить работу по кластеру, даже если для надежности вам подходит один узел и нераспределенная парадигма. Если один узел выходит из строя, вы теряете все вычисления; распределенное вычисление может потенциально восстановить и завершить только ту часть вычислений, которая была потеряна.
источник
При всех равных условиях (стоимость, производительность процессора и т. Д.) Вы можете выбрать наименьший экземпляр, который может хранить весь мой набор данных в памяти и масштабироваться. Сюда
Предполагая, что вы используете какую-то схему перекрестной проверки, чтобы оптимизировать некоторые мета-параметры вашей модели, назначьте каждому ядру значение для тестирования и выберите множество экземпляров по мере необходимости, чтобы охватить все пространство параметров всего за несколько раундов, как вы считаете нужным.
Если ваши данные не помещаются в памяти одной системы, вам, конечно, нужно распределить их по экземплярам. Затем необходимо сбалансировать задержку памяти (лучше во многих случаях) с задержкой в сети (лучше с меньшим количеством экземпляров), но, учитывая природу EC2, держу пари, что вы часто предпочитаете работать с несколькими жирными экземплярами.
источник