У меня есть вопрос об инфраструктуре Apache Spark, который я собираюсь развернуть в новом проекте с (максимум) примерно 4 ТБ данных, используемых для моделирования в любой момент времени. Областью применения будет аналитика, и обучение моделей, вероятно, будет выполняться в пакетном режиме в одночасье, а не в реальном времени.
Традиционные трехуровневые приложения разделяют рабочую нагрузку со стороны базы данных и приложения, что означает, что два разных сервера могут быть оптимизированы для выполнения задач хранения и вычислений соответственно. Это упрощает создание архитектуры системы, поскольку различные поставщики (например, Dell например) имеют предложения, оптимизированные для каждого приложения.
Новые фреймворки, такие как Spark, похоже, объединяют оба аспекта, чтобы избежать перемещения данных между узлами - и вызываемой этим сетевой нагрузки - но мне интересно, как это работает на уровне инфраструктуры.
Объединяют ли люди большие объемы памяти и вычислительные мощности в одной машине? Как может выглядеть стандартная топология системы для моего приложения и какие факторы следует учитывать при ее планировании? Наконец, есть ли какие-либо блейд-серверы, предлагающие высокую плотность хранения, а также хорошую вычислительную мощность?
В идеале я бы хотел работать не более чем с 5 узлами, но я не знаю каких-либо руководящих ресурсов, которые помогли бы спланировать такую реализацию. Любые предложения приветствуются в этом отношении.
Я собираюсь ответить на свой вопрос, так как нашел некоторые ресурсы, однако я также отмечу любые качественные ответы, которые также являются ответами, так что не стесняйтесь вносить свой вклад. Комментарии к моим мыслям здесь также более чем приветствуются.
это link содержит некоторую информацию о предоставлении оборудования для Spark, и насколько я понимаю, вы можете рассматривать Spark как уровень приложения в трехуровневом стеке. Таким образом, вы можете запустить (например) Cassandra или HBase на своих узлах хранения и оставить Spark на узлах «приложений» с более мощными процессорами и памятью, но с меньшим объемом доступной памяти. Ethernet 10 Гбит / с между узлами звучит так, как будто это будет важно в этих случаях использования.
Я полагаю, это поднимает вопрос о том, как обрабатывать очень большой набор данных, учитывая, что в конечном итоге вы все равно можете передавать данные из базы данных Hbase для обработки, но я думаю, что это сводится к архитектуре приложения, поэтому он будет выходят за рамки этого сайта.