Спросив у ОП причину запроса, который затем был указан в качестве ответа, я собираюсь предложить следующее в качестве потенциального ответа:
Сила потока данных заключается в достижении высокой степенипараллелизм при обработке конвейеров данных.Предыстория первоначального запроса заключалась в том, что «что-то» работало при запуске в качестве локального бегуна, но не работало должным образом при использовании Dataflow в качестве бегуна.Тогда это, по-видимому, привело к тому, что OP подумал: «Мы просто запустим Dataflow с использованием локального бегуна».На мой взгляд, это не очень хорошая идея.Один использует localrunner для разработки и модульного тестирования.Локальный бегун не обеспечивает какую-либо форму горизонтального масштабирования ... он буквально работает только на одной машине.
Когда выполняется конвейерное задание в распределенном потоке данных, он создает столько рабочих, сколько необходимо для разумного распределенияработа на многих машинах.Если задание затем желает сгенерировать результат в виде файла ... тогда возникает вопрос «Куда будут записываться эти данные?».Ответом не может быть локальный файл относительно того, где было выполнено задание Dataflow, потому что по определению задание было запущено на нескольких машинах, и в качестве «выходных данных» отсутствует понятие одного компьютера.Чтобы решить эту проблему, данные должны быть выведены в облачное хранилище Google, которое является общей областью хранения, видимой для всех компьютеров.Соответствующий вопрос, заданный OP, описывает потенциальную проблему с записью данных в GCS, а не с локальным файлом (как обнаружено с локальным бегунком), но я считаю, , что - это проблема, которая должна быть решена (т.е. как записать вправильно хранить централизованное хранилище GCS), а не пытаться использовать одну виртуальную машину.Поток данных обеспечивает нулевой контроль над механизмами обработки потоков данных (работниками).Они логически эфемерны и «просто существуют» для обработки работы потока данных.