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