Набор данных Spark - NumberFormatException: нулевая длина BigInteger - PullRequest
1 голос
/ 18 марта 2019

Я сталкиваюсь со странным исключением, когда пытаюсь создать набор данных и просто собирать из него данные.

Exception in thread "main" java.lang.NumberFormatException: Zero length BigInteger
    at java.math.BigInteger.<init>(BigInteger.java:302)
    at org.apache.spark.sql.catalyst.expressions.UnsafeRow.getDecimal(UnsafeRow.java:405)
    at org.apache.spark.sql.catalyst.expressions.GeneratedClass$SpecificUnsafeProjection.writeFields_3_3$(generated.java:298)
    at org.apache.spark.sql.catalyst.expressions.GeneratedClass$SpecificUnsafeProjection.apply(generated.java:35)
    at org.apache.spark.sql.execution.LocalTableScanExec$$anonfun$unsafeRows$1.apply(LocalTableScanExec.scala:41)
    at org.apache.spark.sql.execution.LocalTableScanExec$$anonfun$unsafeRows$1.apply(LocalTableScanExec.scala:41)
    at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234)
    at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234)
    at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
    at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
    at scala.collection.TraversableLike$class.map(TraversableLike.scala:234)
    at scala.collection.AbstractTraversable.map(Traversable.scala:104)
    at org.apache.spark.sql.execution.LocalTableScanExec.unsafeRows$lzycompute(LocalTableScanExec.scala:41)
    at org.apache.spark.sql.execution.LocalTableScanExec.unsafeRows(LocalTableScanExec.scala:36)
    at org.apache.spark.sql.execution.LocalTableScanExec.executeCollect(LocalTableScanExec.scala:67)
    at org.apache.spark.sql.Dataset.org$apache$spark$sql$Dataset$$collectFromPlan(Dataset.scala:3278)
    at org.apache.spark.sql.Dataset$$anonfun$collectAsList$1.apply(Dataset.scala:2739)
    at org.apache.spark.sql.Dataset$$anonfun$collectAsList$1.apply(Dataset.scala:2738)
    at org.apache.spark.sql.Dataset$$anonfun$52.apply(Dataset.scala:3259)
    at org.apache.spark.sql.execution.SQLExecution$.withNewExecutionId(SQLExecution.scala:77)
    at org.apache.spark.sql.Dataset.withAction(Dataset.scala:3258)
    at org.apache.spark.sql.Dataset.collectAsList(Dataset.scala:2738)
    at com.temp.SparkTest.execute(SparkTest.java:85)
    at com.temp.SparkTest.main(SparkTest.java:104)

Выполнение кода выглядит следующим образом:

List<SimplePojo> list ...
Dataset<SimplePojo> ds = sparkSession.createDataset(list, Encoders.bean(SimplePojo.class))
ds.collectoAsList();

Класс SimplePojo содержит один метод getSomething () , который, очевидно, вызывает исключение. Когда я это комментирую, все отлично работает.

public class SimplePojo {

   private int id;
   private OtherPojo otherPojo = new OtherPojo();

   @Deprecated // required by park serialization. Use builder
   public SimplePojo(){}

   publi int getId(){
      return id;
   }

   public String getSomething() {
      return otherPojo.getSomething();
   }

   // sets ...
}

Кто-нибудь знает, что может происходить?

Заранее спасибо!

UPDATE

ПРИЧИНА: Код выше не имеет атрибута что-то . Это вызывает исключение, когда анализатор компонентов (Introspector или что-то подобное) находит get без соответствующего атрибута (например, getSomething без атрибута что-то ). Создание атрибута и его набора решило исключение, но не решило мою проблему. В моем реальном коде «only get» получает значение из составного атрибута (OtherPojo).

Есть идеи, как "сказать" анализатору игнорировать этот метод? (Я пытался @Transiente выше метода, но он не работал)

1 Ответ

0 голосов
/ 20 марта 2019

Оказывается, я не могу получить получает , которые не принадлежат бобу.Я предполагаю, что это "бобовый формат", ожидаемый анализаторами. Introspector сходит с ума (по-разному в зависимости от версии Java), когда он находит получение без соответствующего атрибута.

Так как я не мог найти что-либо, чтобы сказать анализатору «игнорировать этот метод», решение состоит в том, чтобы избежать получает и наборов , которые не связаны с биноматрибуты.

...