¿Por qué no se utiliza el pushdown de predicados en la API de conjunto de datos con tipo (frente a la API de marco de datos sin tipo)?
Siempre pensé que las API de dataset / dataframe son las mismas ... y la única diferencia es que la API de dataset le dará seguridad en el tiempo de compilación. Correcto
Entonces, tengo un caso muy simple:
case class Player (playerID: String, birthYear: Int)
val playersDs: Dataset[Player] = session.read
.option("header", "true")
.option("delimiter", ",")
.option("inferSchema", "true")
.csv(PeopleCsv)
.as[Player]
// Let's try to find players born in 1999.
// This will work, you have compile time safety... but it will not use predicate pushdown!!!
playersDs.filter(_.birthYear == 1999).explain()
// This will work as expected and use predicate pushdown!!!
// But you can't have compile time safety with this :(
playersDs.filter('birthYear === 1999).explain()
Explain del primer ejemplo mostrará que NO está haciendo pushdown predicado (Note PushedFilters vacío):
== Physical Plan ==
*(1) Filter <function1>.apply
+- *(1) FileScan csv [...] Batched: false, Format: CSV, Location: InMemoryFileIndex[file:People.csv], PartitionFilters: [], PushedFilters: [], ReadSchema: struct<playerID:string,birthYear:int,birthMonth:int,birthDay:int,birthCountry:string,birthState:s...
Mientras que la segunda muestra lo hará correctamente (Aviso PushedFilters):
== Physical Plan ==
*(1) Project [.....]
+- *(1) Filter (isnotnull(birthYear#11) && (birthYear#11 = 1999))
+- *(1) FileScan csv [...] Batched: false, Format: CSV, Location: InMemoryFileIndex[file:People.csv], PartitionFilters: [], PushedFilters: [IsNotNull(birthYear), EqualTo(birthYear,1999)], ReadSchema: struct<playerID:string,birthYear:int,birthMonth:int,birthDay:int,birthCountry:string,birthState:s...
Así que la pregunta es ... ¿cómo puedo usar DS Api, y tener seguridad en el tiempo de compilación ..., y el empuje de predicados funcionando como se espera ????
Es posible ? Si no ... ¿significa esto que DS api le brinda seguridad en el tiempo de compilación ... pero a costa del rendimiento! ??? (DF será mucho más rápido en este caso ... especialmente cuando se procesan archivos grandes de parquet)