apache spark - resultado - ¿Por qué tengo que decirle explícitamente a Spark qué almacenar en caché?

spark almacena el resultado de las operaciones intermedias

Question

En Spark, cada vez que realizamos alguna acción en un RDD, el RDD se vuelve a calcular. Entonces, si sabemos que el RDD se va a reutilizar, debemos almacenarlo en caché explícitamente.

Digamos que Spark decide almacenar en caché de forma diferida todos los RDD y usa LRU para mantener los RDD más relevantes en la memoria automáticamente (que es la forma en que la mayoría del almacenamiento en caché funciona de cualquier manera). Será de gran ayuda para el desarrollador, ya que no tiene que pensar en el almacenamiento en caché y concentrarse en la aplicación. Además, no veo cómo puede afectar negativamente el rendimiento, ya que es difícil hacer un seguimiento de cuántas veces se usa una variable (RDD) dentro del programa, la mayoría de los programadores decidirán almacenar en caché la mayoría de los RDD de cualquier manera.

El almacenamiento en caché generalmente ocurre automáticamente. Tome los ejemplos de un sistema operativo / plataforma o un marco o una herramienta. Pero con las complejidades del almacenamiento en caché en la computación distribuida, podría extrañar por qué el almacenamiento en caché no puede ser automático o las implicaciones de rendimiento.

Así que no entiendo por qué tengo que almacenar en caché explícitamente como,

1. Se ve feo
2. Se puede perder fácilmente
3. Se puede usar con exceso / falta

Answer 1

Una lista subjetiva de razones:

• En la práctica, el almacenamiento en caché rara vez se necesita y es útil principalmente para algoritmos iterativos, rompiendo largos linajes. Por ejemplo, las tuberías ETL típicas pueden no requerir almacenamiento en caché. Caché la mayoría de los RDD definitivamente no es la opción correcta.
• No existe una estrategia de almacenamiento en caché universal. La elección real depende de los recursos disponibles, como la cantidad de memoria, discos (locales, remotos, servicio de almacenamiento), sistema de archivos (en memoria, en disco) y una aplicación particular.
• la persistencia en el disco es costosa, en la memoria la persistencia pone más estrés en una JVM y está utilizando el recurso más valioso en Spark

• Es imposible almacenar en caché automáticamente sin hacer suposiciones sobre la semántica de la aplicación. En particular:

  • comportamiento esperado cuando la fuente de datos cambia. No hay una respuesta universal y en muchas situaciones puede ser imposible rastrear automáticamente los cambios
  • diferenciar entre transformaciones deterministas y no deterministas y elegir entre el almacenamiento en caché y la recálculo
• comparar el almacenamiento en caché de Spark con el almacenamiento en caché a nivel del sistema operativo no tiene sentido. El objetivo principal del almacenamiento en caché del sistema operativo es reducir la latencia. En Spark, la latencia no suele ser el factor más importante y el almacenamiento en caché se utiliza para otros fines, como la consistencia, la corrección y la reducción del estrés en diferentes partes del sistema.
• si el caché no usa almacenamiento fuera del montón, el almacenamiento en caché introduce una presión adicional sobre el recolector de basura. El costo de GC puede ser en realidad más alto que el costo de volver a calcular los datos.
• dependiendo de los datos y el método de almacenamiento en caché, la lectura de datos desde el caché puede ser significativamente menos eficiente en cuanto a memoria.
• El almacenamiento en caché interfiere con las optimizaciones más avanzadas disponibles en Spark SQL, deshabilitando efectivamente la poda de particiones o el empuje de predicados y proyecciones.

También vale la pena señalar que:

• la eliminación de datos en caché se maneja automáticamente usando LRU
• algunos datos (como los datos aleatorios intermedios) se conservan automáticamente. Reconozco que hace que algunos de los argumentos anteriores sean al menos parcialmente inválidos.
• El almacenamiento en caché de chispa no afecta a los mecanismos de nivel de sistema o nivel de JVM