Acabo de escribir una clase de juguete a prueba de chispa trama de datos (en realidad conjunto de datos ya que estoy usando Java).
Dataset<Row> ds = spark.sql("select id,name,gender from test2.dummy where dt='2018-12-12'");
ds = ds.withColumn("dt", lit("2018-12-17"));
ds.cache();
ds.write().mode(SaveMode.Append).insertInto("test2.dummy");
//
System.out.println(ds.count());
De acuerdo a mi entender, hay 2 acciones , "InsertInto" y "Count".
Puedo depurar el código paso a paso, cuando se ejecuta "InsertInto", veo varias líneas de:
19/01/21 20:14:56 INFO FileScanRDD: Reading File path: hdfs://ip:9000/root/hive/warehouse/test2.db/dummy/dt=2018-12-12/000000_0, range: 0-451, partition values: [2018-12-12]
Cuando se ejecuta "recuento", todavía veo registros similares:
19/01/21 20:15:26 INFO FileScanRDD: Reading File path: hdfs://ip:9000/root/hive/warehouse/test2.db/dummy/dt=2018-12-12/000000_0, range: 0-451, partition values: [2018-12-12]
Tengo 2 preguntas:
1) Cuando hay 2 acciones en misma trama de datos como la de arriba, si no llaman ds.cache o ds.persist explícitamente, será la segunda acción siempre causa la re-ejecución de la consulta SQL?
2) Si entiendo correctamente el registro, ambas acciones desencadenan hdfs archivo de lectura, ¿significa que el ds.cache () en realidad no funciona aquí? Si es así, ¿por qué no funciona aquí?
Muchas gracias.
Esto se debe a anexar a la mesa en la que dsse crea a partir, por lo que dsnecesita ser recalculado porque cambian los datos subyacentes. En tales casos, la chispa invalida la memoria caché. Si usted lee este ejemplo Jira ( https://issues.apache.org/jira/browse/SPARK-24596 ):
Cuando invalidar una memoria caché, que no válidas otras cachés que dependen de esta memoria caché para asegurar que los datos almacenados en caché está actualizada. Por ejemplo, cuando la tabla subyacente ha sido modificada o la mesa se ha caído en sí, todas las cachés que utilizan esta tabla debe ser invalidado o refrescado .
Intente ejecutar el ds.countantes de insertarlo en la tabla.