Как убедиться, что созданный мной сканер AWS Glue использует OpenCSV SerDe вместо LazySimpleSerDe? - PullRequest
0 голосов
/ 19 декабря 2018

Для контекста: я просмотрел этот предыдущий вопрос , но был недоволен ответом по двум причинам:

  • Я ничего не пишу на Python;на самом деле я не пишу для этого никаких пользовательских сценариев, поскольку полагаюсь на сканер , а не на скрипт Glue.
  • Ответ не настолько полный, как мне требуетсяпоскольку это всего лишь ссылка на какую-то библиотеку.

Я хочу использовать AWS Glue для приема некоторых CSV-файлов в схему, а с помощью Athena преобразовать эту таблицу CSV в несколько форматов, отформатированных в Parquet.таблицы для целей ETL.В данных, с которыми я работаю, есть встроенные кавычки, что было бы неплохо, за исключением того факта, что одна моя запись имеет значение:

"blablabla","1","Freeman,Morgan","bla bla bla"

Кажется, что Glue срабатывает сам по себе, когда онвстречается с "Freeman,Morgan" частью данных.

Если я использую стандартный сканер Glue, я получаю таблицу, созданную с помощью LazySimpleSerDe, которая усекает приведенную выше запись в своем столбце до:

"Freeman,

... что явно нежелательно.

Как заставить сканер выводить файл с правильным SerDe?

[Неприятно] Ограничения:

  • Глядя на , а не , выполните это с помощью скрипта Glue, так как для этого я считаю, что мне нужно заранее иметь таблицу, тогда как сканер создаст таблицу от моего имени.

Если бы мне пришлось делать это через Амазонку Афина, я бы чувствовал, что это в значительной степени победит цель, но это надежное решение.

Ответы [ 2 ]

0 голосов
/ 26 декабря 2018

Используйте glueContext.create_dynamic_frame_from_options () при преобразовании csv в паркет, а затем запустите сканер для данных паркета.

df = glueContext.create_dynamic_frame_from_options("s3", {"paths": [src]}, format="csv")

Разделитель по умолчанию - «Default quoteChar». Если вы хотите изменить, установите флажок https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format.html

0 голосов
/ 19 декабря 2018

Это превратится в очень скучный ответ, но, очевидно, AWS предоставляет свой собственный набор правил для классификации, если файл является CSV.

Для классификациикак CSV, схема таблицы должна иметь как минимум два столбца и две строки данных.Классификатор CSV использует ряд эвристик для определения наличия заголовка в данном файле.Если классификатор не может определить заголовок из первой строки данных, заголовки столбцов отображаются как col1, col2, col3 и т. Д.Встроенный классификатор CSV определяет, выводить ли заголовок, оценивая следующие характеристики файла:

  • Каждый столбец в потенциальном заголовке анализируется как тип данных STRING.

  • За исключением последнего столбца, каждый столбец в потенциальном заголовке имеет содержимое, длина которого не превышает 150 символов.Чтобы использовать конечный разделитель, последний столбец может быть пустым по всему файлу.

  • Каждый столбец в потенциальном заголовке должен соответствовать требованиям регулярного выражения AWS Glue для имени столбца.

  • Строка заголовка должна существенно отличаться от строк данных.Чтобы определить это, одна или несколько строк должны быть проанализированы как отличные от типа STRING.Если все столбцы имеют тип STRING, то первая строка данных недостаточно отличается от последующих строк, которые будут использоваться в качестве заголовка.

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

Однако, несмотря на мое убеждение, что это удовлетворитРегулярное выражение AWS Glue (для которого я нигде не могу найти определения), я решил вместо удалить от запятых и до каналов.Данные теперь загружаются так, как я ожидаю.

...