Revelando Spark_checkpoint

¿Qué es el punto de control?

(1) Spark a menudo enfrenta una gran cantidad de RDD con transformaciones en entornos de producción (por ejemplo, un trabajo contiene 10,000 RDD) o RDD con transformaciones específicas. El cálculo en sí es particularmente complejo o requiere mucho tiempo (por ejemplo, el tiempo de cálculo excede 1 hora). En este momento, es necesario considerar la posibilidad de conservar los datos del resultado del cálculo;

(2) Spark es bueno). en iteración de varios pasos y al mismo tiempo Bueno en la reutilización basada en trabajos. En este momento, si los datos generados por el proceso de cálculo se pueden reutilizar, la eficiencia se puede mejorar enormemente;

(3. ) Si se usa persist para almacenar datos en la memoria, aunque es rápido, también es el menos confiable si los datos se colocan en el disco, ¡no es completamente confiable! Por ejemplo, el disco puede estar dañado y el administrador del sistema puede borrarlo.

(4) Checkpoint se crea para datos persistentes relativamente más confiables. Durante Checkpoint, puede especificar que los datos se coloquen localmente en forma de copia múltiple, pero en un entorno de producción Se coloca en HDFS. que naturalmente aprovecha la alta tolerancia a fallas y las características de alta confiabilidad de HDFS para lograr la forma más confiable de persistir datos;

Si se realiza una operación de 10,000 operadores, al persistir con 9000 operadores, los datos aún pueden ser perdido, pero si se controla, la probabilidad de pérdida de datos es casi 0.

Mecanismo de principio de punto de control

1. Cuando RDD usa el mecanismo de caché para leer datos de la memoria, si los datos no se leen, se utilizará el mecanismo de punto de control para leer los datos. Si no existe un mecanismo de punto de control en este momento, entonces debe encontrar el RDD principal y recalcular los datos, por lo que el punto de control es un mecanismo de tolerancia a fallas muy importante. El punto de control es para una cadena RDD. Si algún RDD de resultado intermedio necesita usarse repetidamente más adelante y los datos intermedios pueden perderse debido a algunas fallas, entonces se puede iniciar el mecanismo de punto de control para el RDD. Para usar el punto de control, primero debe hacerlo. llame al método setCheckpoint de sparkContext Configure un directorio del sistema de archivos tolerante a fallas, como hdfs, y luego llame al método de punto de control en el RDD. Una vez finalizado el trabajo donde se encuentra el RDD, se iniciará un trabajo separado para escribir los datos marcados en el sistema de archivos previamente configurado para persistencia y alta disponibilidad. Por lo tanto, cuando se utiliza el RDD en cálculos posteriores, si los datos se pierden, aún se pueden leer desde su punto de control sin volver a calcularlos.

2. La diferencia entre persistir o caché y punto de control es que la primera persistencia solo guarda los datos en el BlockManager pero su linaje permanece sin cambios, pero en el segundo después de ejecutar el punto de control, el RDD ya no depende en el RDD solo hay un punto de controlRDD. Después del punto de control, el linaje del RDD cambia. Es más probable que los datos conservados mediante persist o caché se pierdan porque el disco o la memoria pueden borrarse, pero los datos del punto de control generalmente se guardan en HDFS y se colocan en un sistema de archivos altamente tolerante a fallas.

Pregunta: ¿Qué RDD deben almacenarse en caché?

Será reutilizado (pero no demasiado grande).

Pregunta: ¿Cómo configuran los usuarios qué RDD almacenar en caché?

Debido a que el usuario solo interactúa con el programa controlador, solo puede usar rdd.cache() para almacenar en caché el RDD que el usuario puede ver.

El llamado visible se refiere al RDD generado después de llamar a la transformación (), y algunos RDD generados por el propio Spark en la transformación () no pueden ser almacenados en caché directamente por el usuario. Por ejemplo, el ShuffledRDD y MapPartitionsRDD generados en reduceByKey () no se pueden almacenar en caché. directamente por el usuario.

RDD que requieren un tiempo de cálculo prolongado o demasiado cálculo, o RDD que tienen una cadena informática larga o dependen de muchos otros RDD. De hecho, almacenar los resultados de salida de ShuffleMapTask en el disco local también se considera un punto de control, pero el objetivo principal de este punto de control es enviar datos a la partición.

Pregunta: ¿Cuándo realizar el control?

El mecanismo de caché consiste en almacenar en caché una partición directamente en la memoria cada vez que calcula una partición que se almacenará en caché. Pero el punto de control no utiliza este método para almacenarlo después de calcularlo por primera vez, sino que espera hasta que finaliza el trabajo e inicia un trabajo especial para completar el punto de control. En otras palabras, el RDD que requiere punto de control se calculará dos veces. Por lo tanto, cuando se usa rdd.checkpoint (), se recomienda agregar rdd.cache (), de modo que el trabajo que se ejecuta por segunda vez no necesita calcular el RDD, sino que lee directamente el caché y escribe en el disco. De hecho, Spark proporciona un método como rdd.persist (StorageLevel.DISK_ONLY), que es equivalente al almacenamiento en caché en el disco. Esto puede almacenar el rdd en el disco cuando se calcula por primera vez. persistir y controlar. Se discutirá más adelante.

RDD necesita pasar por las etapas de [Inicializado --> marcado para puntos de control --> puntos de control en curso --> puntos de control] antes de poder ser marcado.

Inicializado: primero, el programa controlador necesita usar rdd.checkpoint() para establecer qué RDD deben tener puntos de control. Después de la configuración, el RDD aceptará la administración de RDDCheckpointData. El usuario también debe configurar la ruta de almacenamiento del punto de control, generalmente en HDFS.

marcado para puntos de control: después de la inicialización, RDDCheckpointData marcará el rdd como MarkedForCheckpoint.

puntos de control en progreso: se llamará a finalRdd.doCheckpoint() después de que se ejecute cada trabajo. finalRdd escaneará hacia atrás a lo largo de la cadena informática. Cuando encuentre el RDD que se va a controlar, se marcará como CheckpointingInProgress. luego escrito Los archivos de configuración (como core-site.xml, etc.) necesarios para el disco (como escribir en HDFS) se transmiten a blockManager en otros nodos trabajadores. Una vez completado, inicie un trabajo para completar el punto de control (use rdd.context.runJob(rdd, CheckpointRDD.writeToFile(path.toString, broadcastedConf))).

punto de control: una vez que el trabajo completa el punto de control, borre todas las dependencias del RDD y establezca el estado del RDD en punto de control. Luego, imponga una dependencia en el rdd y configure el rdd principal del rdd en CheckpointRDD. CheckpointRDD es responsable de leer el archivo de punto de control en el sistema de archivos y generar la partición del rdd.

Lo interesante es que verifiqué dos RDD en el programa del controlador, y solo uno (el resultado a continuación) se verificó exitosamente. Pairs2 no fue verificado. No sé si es un error o porque. solo marcó el RDD descendente a propósito:

checkPoint es un mecanismo tolerante a fallas. Cuando nuestro programa requiere muchas operaciones de transformación, si nos preocupamos por algunos RDD clave que se usarán repetidamente más adelante. debe a una falla del nodo. Si se pierden datos persistentes, se puede iniciar un mecanismo de punto de control adicional para que el RDD logre tolerancia a fallas y alta disponibilidad.

Primero, llame al método setCheckPointDir() de SparkContext para configurar un directorio en un sistema de archivos tolerante a fallas, como HDFS, luego llame al método checkpoint() en el RDD; Más tarde, una vez finalizado el trabajo donde se encuentra el RDD, se iniciará un trabajo separado para escribir los datos del RDD de checkPoint en el sistema de archivos configurado previamente para realizar operaciones de persistencia de clase tolerantes a fallas y de alta disponibilidad.

En este momento, incluso si sus datos persistentes se pierden accidentalmente al usar RDD más adelante, sus datos aún se pueden leer directamente desde su archivo de punto de control, por lo que no es necesario volver a calcular. (CacheManager)

Respuesta: Primero use SparkContext.setCheckpointDir() para configurar el directorio del punto de control y luego use RDD.checkpoint para realizar el punto de control.

Análisis, cuando usamos checkpoint, ocurren una serie de operaciones:

1. Después de llamar al método checkpoint () en el RDD, acepta la administración del objeto RDDCheckpointData.

2. El objeto RDDCheckpointData es responsable de establecer el estado del RDD que llama al método checkpoint() en MarkedForCheckpoint.

3. Una vez finalizado el trabajo donde se encuentra el RDD, se llamará al método doCheckPoint() del último RDD en el trabajo. Este método busca hacia arriba a lo largo del linaje del RDD final para encontrar el RDD marcado. MarkedForCheckpoint y márquelo como CheckpointingInProgress.

4. Luego, inicie un trabajo separado para verificar el RDD marcado como CheckpointingInProgress en el linaje, es decir, escriba este RDD en el sistema de archivos establecido por el método Sparkcontext.setCheckpointDir().

Respuesta: La principal diferencia:

Es la persistencia, que solo guarda los datos en BlockManager, pero el linaje del RDD no ha cambiado.

Pero después de ejecutar el punto de control, el rdd ya no tiene la llamada dependencia del rdd, sino que solo tiene un punto de controlRDD que se establece a la fuerza. En otras palabras, después del punto de control, el linaje. de los cambios rdd.

En segundo lugar, es más probable que se pierdan los datos persistentes, ya sea en el disco o en la memoria; sin embargo, los datos de los puntos de control generalmente se almacenan en un sistema de archivos tolerante a fallas y de alta disponibilidad. Por ejemplo, HDFS se basa en dicho sistema. Sistemas de archivos altamente tolerantes a fallas, por lo que la posibilidad de pérdida de datos de puntos de control es muy baja.

Respuesta: Si un RDD no está almacenado en caché y se establece un punto de control, dicha operación es muy trágica. Si lo piensa bien, el trabajo del RDD actual se ha ejecutado, pero el RDD intermedio no. persistente, entonces si el trabajo de punto de control quiere escribir los datos del RDD en un sistema de archivos externo, debe volver a calcular todos los RDD antes del RDD, y luego puede calcular los datos del RDD y luego asignarlos al sistema de archivos externo. p>

Por lo tanto, generalmente recomendamos usar persist (StorageLevel_DISK_OMLY) para que el RDD tenga un punto de control. Después de calcular el RDD, se conserva directamente en el disco y luego la operación del punto de control se realiza directamente desde Simplemente lea los datos del RDD. desde el disco y apúntelo al sistema de archivos externo. No es necesario volver a calcular el RDD.