длительная работа в облаке GCP run

Question

Я читаю 10 миллионов записей из BigQuery и выполняю некоторые преобразования и создаю файл .csv, те же данные потока CSV, которые я загружаю на SFTP-сервер, используя Node.JS.

Эта работа занимает приблизительно 5 до 6 часов, чтобы выполнить запрос локально.

Решение было заблокировано при запуске GCP Cloud, но после 2-3-секундного запуска облака закрывает контейнер с ошибкой 503.

Ниже приведена конфигурация GCP Cloud Run.

Автоматическое масштабирование: до 1 экземпляра контейнера. Распределение ЦП: по умолчанию. Распределение памяти: 2Gi. Параллельность: 10 Тайм-аут запроса: 900 секунд

Является ли GCP Cloud Run хорошим вариантом для продолжительного фонового запуска процесс

Answer 1

Вы можете использовать экземпляр виртуальной машины с развернутым контейнером и выполнять на нем свою работу. В конце убейте или остановите свою виртуальную машину.

Но лично я предпочитаю безсерверное решение и подход, такой как Cloud Run. Тем не менее, долгая работа на Cloud Run придет, день! До этого вам придется иметь дело с лимитом в 15 минут или использовать другой сервис.

В качестве обходного пути, Я предлагаю вам использовать Cloud Build. Да, Cloud Build для запуска любого контейнера в нем. Я написал статью об этом . Я запускал контейнер Terraform в Cloud Build, но в действительности вы можете запустить любой контейнер.

Установите тайм-аут правильно, позаботьтесь о учетной записи службы по умолчанию и назначенной роли , и, если вещь еще не доступна в Cloud Run, выберите количество Процессоры (1, 8 или 32) для обработки и ускорения вашего процесса.

Хотите бонус? У вас есть 120 минут бесплатно в день и на расчетный счет ( будьте осторожны, это не для проекта! )

Answer 2

Является ли GCP Cloud Run хорошим вариантом для продолжительного фонового процесса?

Не очень хороший вариант, потому что ваш контейнер «оживает» по входящему HTTP-запросу и как только Контейнер отвечает (например, отправляет что-то обратно), Google предполагает, что обработка запроса завершена, и отключает процессор.

Что может объяснить это:

Решение было отложено на GCP Работа в облаке выполняется, но после 2-3 секунд запуска в облаке происходит закрытие контейнера с ошибкой 503.

Answer 3

Вы можете попробовать использовать Apache Луч конвейер , развернутый через Облачный поток данных . Используя Python, вы можете выполнить задачу, выполнив следующие действия:

Этап 1. Считывание данных из таблицы BigQuery.

beam.io.Read(beam.io.BigQuerySource(query=your_query,use_standard_sql=True))

Этап 2. Загрузка результатов этапа 1 в CSV файл в корзине GCS.

beam.io.WriteToText(file_path_prefix="", \
                    file_name_suffix='.csv', \
                    header='list of csv file headers')

Этап 3. Вызовите функцию ParDo, которая затем возьмет файл CSV, созданный на этапе 2, и загрузит его на сервер SFTP. Вы можете сослаться на эту ссылку.

Answer 4

Я попытаюсь использовать Dataflow для создания CSV-файла из Big Query и загрузить его в GCS.

Answer 5

Вы можете рассмотреть безсерверный подход, основанный на событиях:

• настройка функции облачного триггера хранения Google, выполняющая преобразование
• извлечение / экспорт BigQuery в буфер триггера CF - это самый быстрый способ получения данных BigQuery

Иногда экспортируемые данные таким образом могут быть слишком большими и не подходить для этой формы для обработки в облачной функции из-за таких ограничений, как максимальное время выполнения (9 минут в настоящее время) или объем памяти ограничение 2 ГБ. В этом случае вы можете разделить исходный файл данных на более мелкие части и / или pu sh, а затем на Pub / Sub с зеркалом хранения

Все, что было сказано, мы использовала CF для обработки миллиарда записей от создания фильтров Блума до публикации данных в аэроспайке за несколько минут до конца.