¿Cuál es la diferencia entre el punto de control de chispa y persistir en un disco?

Esta pregunta se puede solucionar de variadas maneras, sin embargo te mostramos la que en nuestra opinión es la resolución más completa.

Solución:

Hay pocas diferencias importantes pero la fundamental es lo que sucede con el linaje. Persist / cache mantiene el linaje intacto mientras checkpoint rompe el linaje. Consideremos los siguientes ejemplos:

import org.apache.spark.storage.StorageLevel

val rdd = sc.parallelize(1 to 10).map(x => (x % 3, 1)).reduceByKey(_ + _)

• cache / persist:

  val indCache  = rdd.mapValues(_ > 4)
  indCache.persist(StorageLevel.DISK_ONLY)
  
  indCache.toDebugString
  // (8) MapPartitionsRDD[13] at mapValues at :24 [Disk Serialized 1x Replicated]
  //  |  ShuffledRDD[3] at reduceByKey at :21 [Disk Serialized 1x Replicated]
  //  +-(8) MapPartitionsRDD[2] at map at :21 [Disk Serialized 1x Replicated]
  //     |  ParallelCollectionRDD[1] at parallelize at :21 [Disk Serialized 1x Replicated]
  
  indCache.count
  // 3
  
  indCache.toDebugString
  // (8) MapPartitionsRDD[13] at mapValues at :24 [Disk Serialized 1x Replicated]
  //  |       CachedPartitions: 8; MemorySize: 0.0 B; ExternalBlockStoreSize: 0.0 B; DiskSize: 587.0 B
  //  |  ShuffledRDD[3] at reduceByKey at :21 [Disk Serialized 1x Replicated]
  //  +-(8) MapPartitionsRDD[2] at map at :21 [Disk Serialized 1x Replicated]
  //     |  ParallelCollectionRDD[1] at parallelize at :21 [Disk Serialized 1x Replicated]
  

• checkpoint:

  val indChk  = rdd.mapValues(_ > 4)
  indChk.checkpoint
  
  indChk.toDebugString
  // (8) MapPartitionsRDD[11] at mapValues at :24 []
  //  |  ShuffledRDD[3] at reduceByKey at :21 []
  //  +-(8) MapPartitionsRDD[2] at map at :21 []
  //     |  ParallelCollectionRDD[1] at parallelize at :21 []
  
  indChk.count
  // 3
  
  indChk.toDebugString
  // (8) MapPartitionsRDD[11] at mapValues at :24 []
  //  |  ReliableCheckpointRDD[12] at count at :27 []
  

Como puede ver, en el primer caso, el linaje se conserva incluso si los datos se recuperan del caché. Significa que los datos se pueden volver a calcular desde cero si algunas particiones de indCache Esta perdido. En el segundo caso, el linaje se pierde por completo después del puesto de control y indChk ya no lleva la información requerida para reconstruirlo.

checkpointa diferencia de cache / persist se calcula por separado de otros trabajos. Es por eso que RDD marcado para puntos de control debe almacenarse en caché:

Se recomienda encarecidamente que este RDD se conserve en la memoria; de lo contrario, será necesario volver a calcular si se guarda en un archivo.

Finalmente checkpointed los datos son persistentes y no se eliminan después SparkContext Esta destruido.

En cuanto al almacenamiento de datos SparkContext.setCheckpointDir usado por RDD.checkpoint requiere DFS ruta si se ejecuta en modo no local. De lo contrario, también puede ser un sistema de archivos local. localCheckpoint y persist sin replicación debe usar el sistema de archivos local.

Nota IMPORTANTE:

El punto de control de RDD es un concepto diferente al de un punto de control en Spark Streaming. El primero está diseñado para abordar el problema del linaje, el último tiene que ver con la confiabilidad de la transmisión y la recuperación de fallas.

Creo que puedes encontrar una respuesta muy detallada aquí.

Si bien es muy difícil resumir todo en esa página, diré

Persistir

• La persistencia o el almacenamiento en caché con StorageLevel.DISK_ONLY hacen que la generación de RDD se calcule y almacene en una ubicación tal que el uso posterior de ese RDD no vaya más allá de esos puntos al volver a calcular el linaje.
• Después de llamar a persistir, Spark aún recuerda el linaje del RDD aunque no lo llame.
• En segundo lugar, después de que finaliza la aplicación, se borra el caché o se destruye el archivo.

punto de control

• Los puntos de control almacenan el rdd físicamente en hdfs y destruyen el linaje que lo creó.
• El archivo del punto de control no se eliminará incluso después de que finalice la aplicación Spark.
• Los archivos de punto de control se pueden usar en la ejecución de trabajos posteriores o en el programa del controlador
• La verificación de un RDD provoca un doble cálculo porque la operación primero llamará a un caché antes de realizar el trabajo real de computación y escritura en el directorio del punto de verificación.

Es posible que desee leer el artículo para obtener más detalles o aspectos internos de los puntos de control o las operaciones de caché de Spark.

1. Persist(MEMORY_AND_DISK) almacenará el marco de datos en el disco y la memoria temporalmente sin romper el linaje del programa, es decir, df.rdd.toDebugString() devolvería el mismo resultado. Se recomienda usar persistir

   df = df.persist(StorageLevel.MEMORY_AND_DISK)
   calculation1(df)
   calculation2(df)
   

   en un cálculo, que se va a reutilizar para evitar el recálculo de resultados intermedios:

2. Tenga en cuenta que el almacenamiento en caché del marco de datos no garantiza que permanecerá en la memoria hasta que lo llame la próxima vez. Dependiendo del uso de la memoria, el caché se puede descartar.

checkpoint(), por otro lado, rompe el linaje y obliga a que el marco de datos se almacene en el disco. A diferencia del uso de cache()/persist(), las comprobaciones frecuentes pueden ralentizar su programa. Se recomienda usar puntos de control cuando a) se trabaja en un entorno inestable para permitir una recuperación rápida de fallas b) se almacenan estados intermedios de cálculo cuando las nuevas entradas del RDD dependen de las entradas anteriores, es decir, para evitar volver a calcular una larga cadena de dependencia en caso de falla

Eres capaz de añadir valor a nuestro contenido colaborando tu experiencia en las observaciones.

---

---

Utiliza Nuestro Buscador