Архитектура DataPipline Best Practice

Question

Дано:

Somekind импорта данных внешнего источника. Данные можно читать в кусках определенного размера. Например, 10 предметов одновременно. Для примеров писем.

Теперь каждый кусок должен пройти несколько шагов, которые преобразуют данные, фильтруют элементы и т. Д.

Нет никакой связи между кусками или деталями кусков. Кроме того, порядок обработки не важен

Вопрос

Сейчас я думаю о том, какая структура будет правильным, если я делаю это с Акки, чтобы иметь лучший распараллеливания и производительность.

1.) Я бы скорее создал всех актеров как цепь детей. Так что у importActor есть ребенок, который является первым шагом. и на первом этапе второй шаг - ребенок и сын.
Или, скорее всего, есть один ImportActor, который имеет все шаги и вызывает один за другим?

2.) Теперь один актер может теперь обрабатывать только одно сообщение. Для Parallize процесса импорта я думаю об использовании механизма PipeTo. Это хорошая идея? есть ли лучшие варианты?

3.) Я бы создал для каждого фрагмента актера типа «Import_ Chunk1 _Actor», или я бы нажал все сообщения на единственный «ImportActor»?

Answer 1

Если вы задали такой вопрос в любом месте на SO, вы бы забили. Его немного расплывчато и легко быть самоуверенным, поэтому постарайтесь быть объективными

Id сказать просто попробуйте несколько способов, не тратя время на код, который выполняет работу. Его действительно быстро сделать работу в стиле лесов.

1) из того, что вы описали, у вас будет вход, а затем несколько актеров, представляющих «10 элементов одновременно», они, вероятно, будут только за маршрутизатором. Таким образом, пока вы развиваете, вы не будете беспокоиться о том, что 10, просто сделайте это для одного, а затем используйте конфигурацию и крошечную настройку, чтобы увеличить ее - поскольку вы предполагаете, что у вас может быть только 1 актер, выполняющий всю работу, если вы используете задачи. Тогда в каждом из них у меня будут процессы на одном уровне. так много зависит от того, есть ли у вас какое-либо состояние на данный момент. Вы можете использовать семантику, чтобы зафиксировать актера в определенном рабочем процессе, вы могли бы просто обрабатывать сообщения, которые пинают следующее состояние в задаче, которая продолжает рассказывать актеру о следующем этапе. Я думаю, что ваше предложение о детских актерах является наименее привлекательным.

2. Актер обрабатывает только одно сообщение за раз, поэтому вы сокращаете время обработки, если хотите, чтобы он имел высокую пропускную способность. Вы либо делаете это через задание, либо передаете другому актеру, например, работнику или агрегатору. PipeTo полезен в сценариях, где вещь, производящая сообщение в задаче, создает сообщение правильного типа для отправки другому актеру, и вы не хотите ничего с ним делать. Это просто продолжение. Ничего плохого в этом, части системы актеров, где вы, в конце концов, выполняете какую-то работу, которую вы, вероятно, собираетесь обернуть в задачу, и если сможете, то используйте ее. Некоторая форма продолжения лучше, чем актер, блокирующий - но если актер будет делать что-то сразу, это имеет значение? Блокировка потока - это блокировка потока.Дело в том, что вы начали использовать что-то вроде akka, вероятно, из-за ловушек задачи/параллельного программирования - вы можете легко купить все это обратно.

3. , когда вы доберетесь до этого момента, это будет очевидно. вы, вероятно, использовали бы маршрутизатор, если у вас было несколько участников, или если вы начнете запускать множество задач, вы, вероятно, можете сделать большую часть этого с участием 1-2 актеров и нескольких цепочек сообщений. Что касается того, что лучше - я знаю 3 человека, которые используют актерские системы, которые могли бы спорить весь день об относительных достоинствах. Вы могли бы просто использовать 1 актера, который обрабатывает сообщения и запускает задачи, если вы исключите все состояние в актере. У вас может быть 2-3 слоя, у вас может быть что-то, что бы заполнить 3 задачи и/или 10 работников. World is your oyster

Дело в том, что все зависит от требований, которые не указаны.