AWS Клей: невозможно определить схему при дельта-загрузке с закладками заданий - PullRequest
0 голосов
/ 11 февраля 2020

Я работаю над AWS Glue Job, который использует секционированные данные в S3 (файлы паркета) с закладками заданий. У меня возникли проблемы при попытке использовать функцию закладок для ежедневной дельта-загрузки. Вот как я читаю данные:

val push: String = "p_date > '" + start + "' and (attribute=='x' or attribute=='y')"
logger.info("Using pushdown predicate: " + push)
val source = glueContext
      .getCatalogSource(database = "testbase", tableName = "testtable", pushDownPredicate = push,
transformationContext = "source").getDynamicFrame()

Это AWS Клеевые сгенерированные входные файлы. json, которые создаются после использования logi закладок задания c сразу после начальной полной загрузки , Не нужно обрабатывать новые данные, которые, как представляется, правильно отображаются с пустыми частями «файлов».

[{
        "path": "s3://path/to/bucket/attribute=x",
        "files": []
    }, {
        "path": "s3://path/to/bucket/attribute=y",
        "files": []
    }]

Однако вместо регистрации того, что файлы были пропущены, происходит следующее:

After final job bookmarks filter, processing 0.00% of 0 files in partition DynamicFramePartition(com.amazonaws.services.glue.DynamicRecord@7d679e8a,s3://path/to/bucket/attribute=x,1578972694000). 
After final job bookmarks filter, processing 0.00% of 0 files in partition DynamicFramePartition(com.amazonaws.services.glue.DynamicRecord@7d679e8a,s3://path/to/bucket/attribute=y,1578972694000).

Полагаю, теперь Glue пытается создать пустой DynamicFrame, который затем завершается ошибкой со следующим сообщением:

ERROR ApplicationMaster: User class threw exception: org.apache.spark.sql.AnalysisException: Unable to infer schema for Parquet. It must be specified manually.;
org.apache.spark.sql.AnalysisException: Unable to infer schema for Parquet. It must be specified manually.;
    at org.apache.spark.sql.wrapper.SparkSqlDecoratorDataSource$$anonfun$3.apply(SparkSqlDecoratorDataSource.scala:38)
    at org.apache.spark.sql.wrapper.SparkSqlDecoratorDataSource$$anonfun$3.apply(SparkSqlDecoratorDataSource.scala:38)
    at scala.Option.getOrElse(Option.scala:121)
    at org.apache.spark.sql.wrapper.SparkSqlDecoratorDataSource.getOrInferFileFormatSchema(SparkSqlDecoratorDataSource.scala:37)
    at org.apache.spark.sql.wrapper.SparkSqlDecoratorDataSource.resolveRelation(SparkSqlDecoratorDataSource.scala:53)
    at com.amazonaws.services.glue.SparkSQLDataSource$$anonfun$getDynamicFrame$8.apply(DataSource.scala:640)
    at com.amazonaws.services.glue.SparkSQLDataSource$$anonfun$getDynamicFrame$8.apply(DataSource.scala:604)
    at com.amazonaws.services.glue.util.FileSchemeWrapper$$anonfun$executeWithQualifiedScheme$1.apply(FileSchemeWrapper.scala:63)
    at com.amazonaws.services.glue.util.FileSchemeWrapper$$anonfun$executeWithQualifiedScheme$1.apply(FileSchemeWrapper.scala:63)
    at com.amazonaws.services.glue.util.FileSchemeWrapper.executeWith(FileSchemeWrapper.scala:57)
    at com.amazonaws.services.glue.util.FileSchemeWrapper.executeWithQualifiedScheme(FileSchemeWrapper.scala:63)
    at com.amazonaws.services.glue.SparkSQLDataSource.getDynamicFrame(DataSource.scala:603)

Вы сталкивались с подобным поведением, подобным этому, с AWS Glue раньше? Я думаю о реализации «нулевой проверки» для «динамически создаваемого» динамического кадра, чтобы предотвратить сбой задания. Или у вас есть какие-нибудь AWS собственные решения, которые могли бы обеспечить надлежащую функциональность закладок работы?

...