Высокая доступность и географическая c избыточность для потока данных

Question

Какая архитектура является лучшей с точки зрения высокой доступности для потока данных в Google Cloud? Мои рабочие нагрузки выполняются в двух регионах. Dataflow читает из одного мультирегионального сегмента и записывает результаты в другой мультирегиональный сегмент.

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

Вопрос в том, жизнеспособна ли эта архитектура, особенно с точки зрения записи результатов в одни и те же мультирегиональные сегменты. Pipeline использует TextIO, который заменяет файлы, если они существуют. Вы предвидите возможные проблемы с этим?

Спасибо!

Answer 1

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

Нет, вероятно, это не нормально .

Точный поток элементов через ваш конвейер не детерминирован c. Следовательно, выходные данные двух конвейеров не обязательно будут побайтно идентичными. Они могут даже привести к разному количеству файловых фрагментов, в зависимости от того, как вы настроили TextIO. Таким образом, особенно в ситуации сбоя, вы можете оказаться в ситуации, когда некоторые сегменты относятся к одному конвейеру, некоторые - к другому конвейеру или даже к несогласованному количеству сегментов. (вы увидите некоторые файлы с именами как 0000-of-0250, а другие как 0000-of-0242).

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

Answer 2

Пока GCP Dataflow распределяет рабочих в зональных экземплярах GCE в одном конкретном регионе, управляемых как группы MIG , при любой аварии в зоне расположения потребуется пользователь, чтобы перезапустить задание и указать зону в отдельном регионе.

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

В упомянутом варианте использования я предполагаю, что для пакетного задания потока данных, которое не потребляет никаких поступающих данных в реальном времени, вы можете просто перезапустите это задание в любое время без потери данных в случае сбоя. Если цель по-прежнему заключается в приеме данных, постоянно обнаруживающем появление файлов fre sh в ведре GCS, то, вероятно, вам потребуется запустить выполнение streaming для этого конкретного конвейера.

Я бы порекомендовал вам посмотреть на Google Cloud Functions , что дает вам возможность составить пользовательскую функцию срабатывание определенное c действие, основанное на возникновении некоторого облачного события. Я предполагаю, что таким образом вы сможете получить вредоносное событие для конвейера пакетного потока данных в основной региональной зоне и на основе этого выполнить то же задание в отдельной области вычислений.

Было бы даже больше Сообществу выгодно подать запрос функции поставщику через трекер проблем с учетом реализации многорегиональной высокой доступности Dataflow.