CoGroupByKey всегда терпел неудачу при работе с большими данными (PythonSDK)

#debugging #google-cloud-dataflow #google-dataflow

#отладка #google-cloud-поток данных #google-поток данных

Вопрос:

У меня около 4000 входных файлов (в среднем ~ 7 МБ каждый).

Мой конвейер всегда терпел неудачу на шаге CoGroupByKey, когда размер данных достигает около 4 ГБ. Я попытался ограничить использование только 300 файлов, тогда он работал нормально.

В случае сбоя журналы в потоке данных GCP показывают только:

 Workflow failed. Causes: S24:CoGroup Geo data/GroupByKey/Read CoGroup Geo data/GroupByKey/GroupByWindow CoGroup Geo data/Map(_merge_tagged_vals_under_key) failed., The job failed because a work item has failed 4 times. Look in previous log entries for the cause of each one of the 4 failures. For more information, see https://cloud.google.com/dataflow/docs/guides/common-errors. The work item was attempted on these workers: 
  store-migration-10212040-aoi4-harness-m7j7
      Root cause: The worker lost contact with the service.,
  store-migration-xxxxx
      Root cause: The worker lost contact with the service.,
  store-migration-xxxxx
      Root cause: The worker lost contact with the service.,
  store-migration-xxxxx
      Root cause: The worker lost contact with the service.
  

Я просматриваю все журналы в Logs Explorer. Ничто другое не указывает на ошибку, кроме приведенной выше, даже мой logging.info и try...except код.

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

Спасибо.

Комментарии:

1. это интересно! Спасибо, что поделились. The worker lost contact with the service. сообщения являются общими, когда рабочий испытывает высокую нагрузку на память. Можете ли вы поделиться более подробной информацией о вашем конвейере и о функции, следующей за CoGBK?

2. Согласен с Пабло, это похоже на проблему с памятью. У вас есть горячие клавиши? Вы пробовали машины с большим объемом памяти?

3. @Pablo Я попробовал n1-highmem-4 , -8 и все равно произошел сбой. groupByKey внутри него сказал, что у него ~ 15 ГБ данных памяти, что меньше, -8 и он все равно падает там.