В чем разница между контрольной точкой искробезопасности и упорством на диске

Ответ 1

Есть несколько важных различий, но фундаментальное - это то, что происходит с родословной. Persist/cache сохраняет целостность линии, а checkpoint ломает линию. Рассмотрим следующие примеры:

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 <console>:24 [Disk Serialized 1x Replicated]
  //  |  ShuffledRDD[3] at reduceByKey at <console>:21 [Disk Serialized 1x Replicated]
  //  +-(8) MapPartitionsRDD[2] at map at <console>:21 [Disk Serialized 1x Replicated]
  //     |  ParallelCollectionRDD[1] at parallelize at <console>:21 [Disk Serialized 1x Replicated]
  
  indCache.count
  // 3
  
  indCache.toDebugString
  // (8) MapPartitionsRDD[13] at mapValues at <console>:24 [Disk Serialized 1x Replicated]
  //  |       CachedPartitions: 8; MemorySize: 0.0 B; ExternalBlockStoreSize: 0.0 B; DiskSize: 587.0 B
  //  |  ShuffledRDD[3] at reduceByKey at <console>:21 [Disk Serialized 1x Replicated]
  //  +-(8) MapPartitionsRDD[2] at map at <console>:21 [Disk Serialized 1x Replicated]
  //     |  ParallelCollectionRDD[1] at parallelize at <console>:21 [Disk Serialized 1x Replicated]
  

• checkpoint:

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

Как вы можете видеть в первом случае, линия сохраняется, даже если данные извлекаются из кеша. Это означает, что данные могут быть пересчитаны с нуля, если некоторые разделы indCache будут потеряны. Во втором случае линейка полностью потеряна после контрольной точки, а indChk не несет информацию, необходимую для ее перестройки.

checkpoint, в отличие от cache/Persist вычисляется отдельно от других заданий. Для этого необходимо кэшировать RDD, отмеченный для контрольной точки:

Настоятельно рекомендуется, чтобы этот RDD сохранялся в памяти, иначе сохранение его в файле потребует перерасчета.

Наконец checkpointed данные сохраняются и не удаляются после уничтожения SparkContext.

Что касается хранения данных SparkContext.setCheckpointDir, используемого RDD.checkpoint, требуется DFS path, если он работает в нелокальном режиме. В противном случае это может быть и локальная файловая система. localCheckpoint и Persist без репликации следует использовать локальную файловую систему.

Примечание

Контрольная точка RDD - это другое понятие, чем чек-точка в Spark Streaming. Первый из них предназначен для решения проблемы линейки, последняя касается надежности потоковой передачи и восстановления отказа.

Ответ 2

Я думаю, вы можете найти очень подробный ответ здесь

Пока очень сложно суммировать все на этой странице, я скажу

Упорство

• Сохранение или кэширование с помощью StorageLevel.DISK_ONLY приводит к тому, что генерация RDD должна быть вычислена и сохранена в местоположении, так что последующее использование этого RDD не будет выходить за пределы этих точек при пересчете линии.
• После того, как вызывается persist, Spark все еще помнит линейку RDD, даже если она не вызывает его.
• Во-вторых, после завершения приложения кеш очищается или уничтожается файл

Checkpointing

• Контрольная точка хранит rdd физически в hdfs и уничтожает созданную им линию.
• Файл контрольной точки не будет удален даже после прекращения приложения Spark.
• Файлы контрольных точек могут использоваться в следующем запуске задания или программе драйвера
• Контрольная точка RDD вызывает двойное вычисление, потому что операция сначала вызовет кеш, прежде чем выполнять фактическую работу по вычислению и записи в каталог контрольной точки.

Вы можете прочитать статью для получения дополнительной информации о деталях или внутренних элементах контрольной проверки Spark или операций кэширования.

Ответ 3

Если вы проверите соответствующую часть документации, в нем говорится о записи данных в надежную систему, например. HDFS. Но вам стоит сказать Apache Spark, где писать информацию о контрольных точках.

С другой стороны, сохраняются данные кэширования в основном в памяти, поскольку эта часть документации четко указывает.

Итак, это зависит от того, какой каталог вы предоставили Apache Spark.

Ответ 4

• Persist (MEMORY_AND_DISK) будет хранить фрейм данных на диск и временную память без разрыва линии программы, то есть df.rdd.toDebugString() вернет тот же результат. Рекомендуется использовать persist (*) для расчета, который будет использоваться повторно, чтобы избежать пересчета промежуточных результатов:

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

  Обратите внимание, что кеширование фрейма данных не гарантирует, что оно останется в памяти, пока вы не вызовете его в следующий раз. В зависимости от использования памяти кеш может быть отброшен.

• checkpoint(), с другой стороны, ломает линию и заставляет кадр данных хранить на диске. В отличие от использования cache()/persist(), частая проверка может замедлить вашу программу. Контрольные точки рекомендуется использовать, если: a) работать в нестабильной среде, чтобы обеспечить быстрое восстановление после сбоев; b) хранить промежуточные состояния вычисления, когда новые записи RDD зависят от предыдущих записей, т.е. Чтобы избежать перерасчета длинной цепи зависимостей в случае отказа