Можно ли использовать искру для обработки сложных объектов со сложными зависимостями? - PullRequest
0 голосов
/ 16 апреля 2019

Рассмотрим сценарий (объекты и зависимости Scala классов):

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

Текущий рабочий процесс состоит из:

  1. Загрузка данных о зависимостях из базы данных и их создание (довольно сложным способом с взаимозависимостями).
  2. Загрузка объекта данные из базы данных и создания объектов с использованием ранее загруженные зависимости.
  3. Выполнение операций со списком объектов, таких как:

    a. Search with a complex predicate
    b. Transform
    c. Filter
    d. Save to the database
    e. Reload from the database
    

Мы рассматриваем возможность выполнения этих операций на нескольких машинах. Один из вариантов - использовать Spark, но не ясно, как правильно поддерживать сериализацию данных и распространять / обновлять зависимости.

Даже если мы сможем отделить логику в объектах от данных (делая объекты легко сериализуемыми), функции, которые мы хотим запустить над объектами, будут по-прежнему полагаться на сложные зависимости, упомянутые выше.

Кроме того, по крайней мере, на данный момент у нас нет планов использовать какие-либо операции, требующие перетасовки данных между компьютерами, и все, что нам нужно, это в основном сегментирование.

Выглядит ли Spark подходящим для такого сценария?

  • Если да, как обрабатывать сложные зависимости?
  • Если нет, был бы признателен за любые указатели на альтернативные системы, которые могут обрабатывать рабочий процесс.

1 Ответ

2 голосов
/ 16 апреля 2019

Я не совсем понимаю, что вы подразумеваете под "сложными взаимозависимостями", но кажется, что если вам нужен только шардинг, вы не получите много пользы от искры - просто запустите несколько, независимо от того, что у вас есть, используйте очередь для синхронизации работы. и раздайте каждой копии осколок, с которым нужно работать.

Мы сделали что-то похожее, преобразовав pySpark jot в настройку Kubernetes, где в очереди содержится список идентификаторов, а затем у нас есть несколько модулей (мы контролируем масштаб с помощью kubectl), которые читают из этой очереди и получают гораздо лучшую производительность и более простое решение. - см https://kubernetes.io/docs/tasks/job/coarse-parallel-processing-work-queue/

...