Сообщение Re: Что могут облака, а что нет от 01.04.2018 16:21
Изменено 01.04.2018 16:22 Gt_
Re: Что могут облака, а что нет
Здравствуйте, GhostCoders, Вы писали:
GC>Например, у моего пользователя есть большой файл (несколько GB).
GC>Он хочет его как-то обработать с использованием моей службы, запущенной, скажем в Azure (или где-то еще).
GC>Обработка этого файла, скажем, на одном компе (локальном) заняла бы несколько суток. Допустим, там тяжелые вычисления.
GC>Хотелось бы это дело ускорить используя несколько (или несколько десятков\сот\тысяч) узлов в облаке.
GC>Естественно, алгоритм должен быть параллельным.
GC>Вижу проблемы:
GC>1) В передачи входных данных от пользователя на все запущенные узлы. Это случай когда входные данные дублируются.
GC>2) В случае если входные данные распиливать на небольшие части, проблема в распилке. Кто это будет делать? Допустим, будет какой-то выделенный для
GC> этого узел, "монитор". Монитор, собственно, должен синхронизировать работу остальных узлов.
GC>Вопрос: Вообще, синхронизация, обмен данными между узлами предусмотрены в "облаках"?
GC>Или "облака" для этого не предназначены? И тогда нужен "кластер"?
на такую задачу проситься hadoop кластер. допустим в google cloud заказываешь 400 VMs с предустановленным хадупом и запускаешь map-reduce таск после расчета убиваешь кластер. счет будет лишь за затраченное кластером время. файл порубит и раскидает по нодам map-reduce фреймворк по сути автоматом. файл кластер может читать/писать прямо с гугловского сториджа, через какие-то коннекторы.
альтернативный вариант hadoop + spark, еще есть варианты server less: spark или map-reduce job можно запускать не создавая отдельный кластер.
GC>Например, у моего пользователя есть большой файл (несколько GB).
GC>Он хочет его как-то обработать с использованием моей службы, запущенной, скажем в Azure (или где-то еще).
GC>Обработка этого файла, скажем, на одном компе (локальном) заняла бы несколько суток. Допустим, там тяжелые вычисления.
GC>Хотелось бы это дело ускорить используя несколько (или несколько десятков\сот\тысяч) узлов в облаке.
GC>Естественно, алгоритм должен быть параллельным.
GC>Вижу проблемы:
GC>1) В передачи входных данных от пользователя на все запущенные узлы. Это случай когда входные данные дублируются.
GC>2) В случае если входные данные распиливать на небольшие части, проблема в распилке. Кто это будет делать? Допустим, будет какой-то выделенный для
GC> этого узел, "монитор". Монитор, собственно, должен синхронизировать работу остальных узлов.
GC>Вопрос: Вообще, синхронизация, обмен данными между узлами предусмотрены в "облаках"?
GC>Или "облака" для этого не предназначены? И тогда нужен "кластер"?
на такую задачу проситься hadoop кластер. допустим в google cloud заказываешь 400 VMs с предустановленным хадупом и запускаешь map-reduce таск после расчета убиваешь кластер. счет будет лишь за затраченное кластером время. файл порубит и раскидает по нодам map-reduce фреймворк по сути автоматом. файл кластер может читать/писать прямо с гугловского сториджа, через какие-то коннекторы.
альтернативный вариант hadoop + spark, еще есть варианты server less: spark или map-reduce job можно запускать не создавая отдельный кластер.
Re: Что могут облака, а что нет
Здравствуйте, GhostCoders, Вы писали:
GC>Например, у моего пользователя есть большой файл (несколько GB).
GC>Он хочет его как-то обработать с использованием моей службы, запущенной, скажем в Azure (или где-то еще).
GC>Обработка этого файла, скажем, на одном компе (локальном) заняла бы несколько суток. Допустим, там тяжелые вычисления.
GC>Хотелось бы это дело ускорить используя несколько (или несколько десятков\сот\тысяч) узлов в облаке.
GC>Естественно, алгоритм должен быть параллельным.
GC>Вижу проблемы:
GC>1) В передачи входных данных от пользователя на все запущенные узлы. Это случай когда входные данные дублируются.
GC>2) В случае если входные данные распиливать на небольшие части, проблема в распилке. Кто это будет делать? Допустим, будет какой-то выделенный для
GC> этого узел, "монитор". Монитор, собственно, должен синхронизировать работу остальных узлов.
GC>Вопрос: Вообще, синхронизация, обмен данными между узлами предусмотрены в "облаках"?
GC>Или "облака" для этого не предназначены? И тогда нужен "кластер"?
на такую задачу проситься hadoop кластер. допустим в google cloud заказываешь 400 VMs с предустановленным хадупом и запускаешь map-reduce таск, после расчета убиваешь кластер. счет будет лишь за затраченное кластером время. файл порубит и раскидает по нодам map-reduce фреймворк по сути автоматом. файл кластер может читать/писать прямо с гугловского сториджа, через какие-то коннекторы.
альтернативный вариант hadoop + spark, еще есть варианты server less: spark или map-reduce job можно запускать не создавая отдельный кластер.
GC>Например, у моего пользователя есть большой файл (несколько GB).
GC>Он хочет его как-то обработать с использованием моей службы, запущенной, скажем в Azure (или где-то еще).
GC>Обработка этого файла, скажем, на одном компе (локальном) заняла бы несколько суток. Допустим, там тяжелые вычисления.
GC>Хотелось бы это дело ускорить используя несколько (или несколько десятков\сот\тысяч) узлов в облаке.
GC>Естественно, алгоритм должен быть параллельным.
GC>Вижу проблемы:
GC>1) В передачи входных данных от пользователя на все запущенные узлы. Это случай когда входные данные дублируются.
GC>2) В случае если входные данные распиливать на небольшие части, проблема в распилке. Кто это будет делать? Допустим, будет какой-то выделенный для
GC> этого узел, "монитор". Монитор, собственно, должен синхронизировать работу остальных узлов.
GC>Вопрос: Вообще, синхронизация, обмен данными между узлами предусмотрены в "облаках"?
GC>Или "облака" для этого не предназначены? И тогда нужен "кластер"?
на такую задачу проситься hadoop кластер. допустим в google cloud заказываешь 400 VMs с предустановленным хадупом и запускаешь map-reduce таск, после расчета убиваешь кластер. счет будет лишь за затраченное кластером время. файл порубит и раскидает по нодам map-reduce фреймворк по сути автоматом. файл кластер может читать/писать прямо с гугловского сториджа, через какие-то коннекторы.
альтернативный вариант hadoop + spark, еще есть варианты server less: spark или map-reduce job можно запускать не создавая отдельный кластер.