Архитектура сложных задач Dataflow

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

Есть ли у вас какие-либо рекомендации по проектированию таких видов работ? Любые показатели, поведение или что-то еще, что мы должны рассмотреть в другом, чтобы принять решение?

Вот пара вариантов, которые мы имеем в виду и как мы это сравниваем:

Вариант 1: одно большое задание

Реализуйте все в одной большой работе. Фактор общих показателей, а затем вычислить специфические для модели показатели.

Pros

  • Проще написать.
  • Нет зависимости между заданиями.
  • Меньше вычислить ресурсы?

Против

  • Если одна часть ломается, обе модели не могут быть вычислены.

Большая работа

Вариант 2: Несколько заданий, связанных с Pub/Sub

Извлеките общее вычисление показателей на заданное задание, таким образом, получив 3 задания, подключенные вместе с помощью Pub/Sub.

Pros

  • Более устойчив в случае отказа одного из модельных заданий.
  • Возможно, проще выполнить текущие обновления.

Против

  • Все задания необходимо запустить, чтобы иметь полное управление конвейером: управление зависимостями.

3 задания

Ответы

Ответ 1

Вы уже упоминали многие из основных компромиссов здесь: модульность и меньшие домены отказа от операционных издержек и потенциальная сложность монолитной системы. Еще один момент, который следует учитывать, - это затраты - трафик Pub/Sub будет увеличивать цену решения нескольких трубопроводов.

Не зная специфики вашей операции лучше, я бы посоветовал пойти с опцией №2. Похоже, что есть хотя бы частичное значение в том, что у вас есть подмножество моделей, и в случае критической ошибки или регрессии вы сможете сделать частичный прогресс при поиске исправления.