Блог

В настоящее время у меня есть только один компьютер, и другого у меня не будет.

1. Я запускаю Spark на ядрах своего процессора: master=local[5] , используя его напрямую: я устанавливаю spark-core и spark-sql для зависимостей, не делаю никакой другой конфигурации, и мои программы запускаются немедленно. Конечно, это удобно.

2. Но должен ли я попытаться создать архитектуру с master и некоторыми workers с помощью контейнеров Docker или minikube (Kubernetes) на моем компьютере?

Будет ли решение # 2 — со всеми требуемыми настройками — вознаградит меня лучшей производительностью, потому что Spark действительно предназначен для работы таким образом, даже на одном компьютере,

или я потеряю некоторое время, потому что режим, в котором я сейчас его запускаю, без использования сети, без необходимости в местоположении данных, всегда даст мне лучшую производительность, а решение # 1 всегда будет лучшим на одном компьютере?

Моя гипотеза заключается в том, что # 1 подходит. Но у меня нет истинного измерения для этого. Нет источника для сравнения. Кто испытал два способа выполнения операций на компьютере sigle?

Это действительно зависит от ваших целей — если вы всегда будете запускать свой Spark-код на одном узле с локальным мастером, то просто используйте его. Но если вы собираетесь запускать полученный код в распределенном режиме на нескольких компьютерах, то эмуляция кластера с помощью Docker может быть полезной, так как вы получите действительно распределенный код и сможете обнаружить проблемы, которые не всегда обнаруживаются при запуске вашего кода с локальным мастером.

Вместо прямого использования Docker (это может быть сложно настроить, хотя это все еще возможно), возможно, вы можете рассмотреть возможность использования Spark в Kubernetes, например, через minikube — в Google есть множество статей на эту тему.

Проведя тестирование этого с размером исполнителя, разница с тем, когда имеет смысл использовать больше нескольких исполнителей, равна # CPUs > 32. Во время выполнения AWS EMR spark по умолчанию используется не менее 4 процессоров на исполнителя, а Databricks всегда использует исполнители fat, что означает > 32 ЦП на экземплярах 8xl. Вашим самым большим ограничением, как правило, является сборка мусора JVMs, которая ограничивает размер кучи. Локальный режим имеет пару преимуществ в производительности по сравнению с кластерным режимом.

1. полный этап генерации кода должен выполняться как на диске, так и на каждом исполнителе. Для коротких запросов это может добавить несколько 100 МС на этап.
2. связь с драйвером <-> исполнителем имеет задержку.
3. общая память между драйвером и исполнителями. Это снижает вероятность ООМ и уменьшает объем загрузки на диск.

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

Если вы чувствуете себя амбициозным, есть инструмент тестирования производительности под названием TPC-DS, который запускает набор запросов обработки данных к стандартизированному набору данных

https://github.com/databricks/spark-sql-perf
https://github.com/maropu/spark-tpcds-datagen

Также, если вы чувствуете себя предприимчивым, в коде spark есть скрипт для запуска мини-кластера на minikube, если вам нужен быстрый и простой способ протестировать это.