Подсказка Google dataprep (clouddataprep от trifacta): задания не смогут выполняться, если они слишком большие
Во время моих приключений в облачном хранилище я столкнулся с еще одной очень раздражающей ошибкой.
Проблема возникает при создании сложных структур потоков, которые должны быть связаны через наборы эталонных данных. Если определенный предел пересекается при выполнении ряда объединений или объединений с этими наборами, поток данных не может начать задание.
У меня было много контактов с поддержкой, и они работают над проблемой:
"Наша команда системного инженера смогла определить причину, которая привела к неудачной работе. Они отметили, что работа слишком велика. Это означает, что рецепт (объединенный из всех наборов данных) слишком велик, и Dataflow отклоняет его. Наша команда инженеров все еще исследует подходы к решению этой проблемы.
Обходной путь - разделить работу на две меньшие работы. Сначала запустите поток для обогащения данных, а затем используйте вывод в качестве входных данных в другом потоке. Хотя это и не идеально, на данный момент это будет рабочим решением ".
1 ответ
Я столкнулся с той же проблемой, и у меня есть достаточно обоснованное предположение относительно ответа. Имейте в виду, что DataPrep просто берет все ваши входные данные на основе графического интерфейса и переводит их в код Apache Beam. Когда вы передаете набор справочных данных, он, вероятно, записывает некоторый код AB, который превращает набор справочных данных в боковой ввод ( https://beam.apache.org/documentation/programming-guide/). DataFlow выполнит функцию Parellel Do (ParDo), где он берет каждый элемент из PCollection, вставляет его в рабочий узел, а затем применяет данные бокового ввода для преобразования.
Так что я уверен, что если наборы ссылок станут слишком большими (что может случиться с Joins), базовый код возьмет элемент из набора данных A, передаст его функции с боковым вводом B... но если боковой ввод B очень большой, он не сможет вписаться в рабочую память. Посмотрите журналы Stackdriver для вашей работы, чтобы выяснить, так ли это. Если вы видите "GC (Allocation Failure)" в ваших журналах, это признак нехватки памяти.
Вы можете попробовать сделать это: предположим, у вас есть два CSV-файла для чтения и обработки, файл A имеет размер 4 ГБ и файл B также имеет размер 4 ГБ. Если вы запускаете задание для выполнения какого-либо типа присоединения, оно очень быстро перерастет рабочую память и рвет. Если вы МОЖЕТЕ, посмотрите, можете ли вы предварительно обработать таким образом, чтобы один из файлов находился в диапазоне МБ, и просто увеличьте другой файл.
Если ваши структуры данных не поддаются этому варианту, вы можете сделать то, что предложили Sys Engs, разбить один файл на множество маленьких кусков и затем итеративно подать его в рецепт для другого файла большего размера.
Другой вариант для тестирования - указание типа вычислений для рабочих. Вы можете итеративно увеличивать тип вычислений все больше и больше, чтобы увидеть, как он все-таки продвинется.
Другой вариант заключается в том, чтобы кодировать все это самостоятельно в Apache Beam, тестировать локально, а затем переносить в Google Cloud DataFlow.
Надеюсь, что эти парни скоро решат проблему, им непросто задать им вопросы, это точно.