Как заставить inferSchema для CSV рассматривать целые числа как даты (с опцией dateFormat)?

Я использую Spark 2.2.0

Я читаю файл csv следующим образом:

val dataFrame = spark.read.option("inferSchema", "true")
                          .option("header", true)
                          .option("dateFormat", "yyyyMMdd")
                          .csv(pathToCSVFile)

В этом файле есть один столбец даты, и все записи имеют значение, равное 20171001 для этого конкретного столбца.

Проблема в том, что искра делает вывод, что тип этого столбца integer, а не date. Когда я удаляю параметр "inferSchema", тип этого столбца - string.

В этом файле нет значений null или неверно отформатированных строк.

В чем причина / решение этой проблемы?


person Rami    schedule 02.10.2017    source источник
comment
Вы можете попробовать отключить (inferSchema, true) и предоставить настраиваемую схему для чтения файла csv   -  person Avishek Bhattacharya    schedule 02.10.2017
comment
Могу, но полагаю, что опция dateFormat создана, чтобы не делать то, что вы предложили, верно?   -  person Rami    schedule 02.10.2017
comment
Если у меня все еще хорошая память, его нужно заключить в двойные кавычки.   -  person eliasah    schedule 02.10.2017


Ответы (2)


Если я правильно понял, code подразумевает следующий порядок вывода типов (с первыми типами проверено сначала):

  • NullType
  • IntegerType
  • LongType
  • DecimalType
  • DoubleType
  • TimestampType
  • BooleanType
  • StringType

При этом, я думаю, проблема в том, что 20171001 совпадает с IntegerType, прежде чем даже рассматривать TimestampType (который использует параметр timestampFormat, а не dateFormat).

Одним из решений было бы определить схему и использовать ее с оператором schema (из DataFrameReader) или позволить Spark SQL вывести схему и использовать оператор cast.

Я бы выбрал первое, если количество полей невелико.

person Jacek Laskowski    schedule 02.10.2017

В этом случае вы просто не можете зависеть от вывода схемы из-за неоднозначности формата.

Поскольку ввод может быть проанализирован как IntegerType (или любой числовой формат с более высокой точностью), так и как TimestamType, а первый имеет более высокий приоритет (внутренне Spark пытается IntegerType -> LongType -> DecimaType -> DoubleType -> TimestampType), механизм вывода никогда не достигнет TimestampType дело.

В частности, с включенным выводом схемы Spark вызовет tryParseInteger, который правильно проанализирует ввод и person zero323    schedule 02.10.2017

comment
Это держится. Порядок предложений в сопоставлении с шаблоном, который вы связали, не имеет значения. - person zero323; 03.10.2017