Как обрабатывать изменения схемы в клее и получать ожидаемый результат в csv?

Я пытаюсь просканировать некоторые файлы с разными сахемами (совместимыми с данными) с помощью AWS Glue.
Как я читал в документации AWS, сканеры Glue обновляют таблицы каталога при любых изменениях схемы (добавляют новые столбцы и удаляют недостающие столбцы). Я проверил «Обновить определение таблицы в каталоге данных» и «Создать одну схему для каждого пути S3» при создании искателя. Пример:
скажем, у меня есть файл File1.csv, как показано ниже:

имя, возраст, место

Рави, 12, Инд

Джо, 32 года, США

Скажем, у меня есть другой файл File2.csv, как показано ниже:

имя, возраст, рост

Джек, 12,160

Джейн, 32 180

После запуска поисковых роботов схема была обновлена ​​как: имя, возраст, местонахождение, рост - это как и ожидалось но когда я попытался прочитать файлы с помощью Athena или попытался записать содержимое обоих файлов в csv с помощью задания Glue ETL, я заметил, что: вывод выглядит так:

имя, возраст, место, рост

Рави, 12, Инд ,,

Джо, 32 года, США,

Джек, 12,160,

Джейн, 32,180,

последние две строки должны быть пустыми для loc, так как во втором файле не было столбца loc.

где как и ожидалось:

имя, возраст, место, рост

Рави, 12, Инд ,,

Джо, 32 года, США,

Джек, 12`` 160

Джейн, 32`` 180

Короче говоря, клей пытается заполнить столбец непрерывным образом в комбинированном выводе. Есть ли способ получить ожидаемый результат?

2
0
3 332
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Я получил ожидаемый результат с файлами Parquet. Изначально я использовал CSV, но десериализатор csv не понимает, как разместить элементы в правильном положении при изменении схемы. Преобразование отдельных CSV в паркет и последующее сканирование их одного за другим помогло мне включить изменяющуюся схему.

Я также заметил, что парсинг CSV с помощью Serde lib org.apache.hadoop.hive.serde2.OpenCSVSerde также делает это неправильно. На полпути к моим данным, в середине набора данных был введен столбец. Вместо того, чтобы игнорировать этот столбец надлежащим образом, когда он не существует, он вместо этого заполняется неправильными значениями. Преобразование в Parquest перед сканированием звучит как много накладных расходов из-за того, что должно быть исправлено в части поискового робота.

Will B 20.02.2019 22:08

Другие вопросы по теме