Повторная установка Spark Partition полностью из исходного источника из-за сбоя узла и изменения данных в источнике

Question

Я не могу смоделировать это, поэтому быстрая проверка не потоковой ситуации, только обычная обработка DF или RDD:

• В случае сбоя узла Spark Worker
  • и, следовательно, данное вычисление / вычисления СДР потеряны
    • и кеширование, контрольные точки и т. Д. Не применяются,
      • затем для пересчета,
        • как это происходит, если данные в источнике изменились, и это может означать, что на самом деле другим узлам потребуются некоторые дополнительные данные из-за повторного разделения?
        • что это означает с точки зрения производительности первоначального чтения, что, возможно, было много данных, сопровождаемых перераспределением?

т.е. мы говорим о недетерминированной ситуации здесь.

Answer 1

Обновление - Если мы рассмотрим источник, подобный JDBC, запрос будет выполнен [1] для БД во время повторного вычисления.Если записи изменятся, это приведет к искаженным результатам.Я не думаю, что работа потерпит неудачу.

[1] - Это основано на JdbcRDD коде.

---

Что касается вашего первого вопроса, разделы Spark очень похожи (фактически построены из InputSplit Hadoop из InputFormat).Каждый FileSplit обычно содержит следующие свойства

• InputPath
• StartOffset
• Длина (обычно размер блока в кластере)

Итак, давайте рассмотрим следующие случаи, когда вы говорите, что данные в источнике изменились

+--------------------------+-------------------------------------------------------------+
|         Scenario         |                        What happens                         |
+--------------------------+-------------------------------------------------------------+
| New file get's added     | The new files are not part of the input splits              |
|                          | so they're not captured as part of the partitions.          |
| Existing file is deleted | This will cause the job to fail with FileNotFoundException. |
+--------------------------+-------------------------------------------------------------+

Относительно вашего второго вопроса. Когда вы говорите о перераспределении, снова возникают два пути.С shuffling=true и без.

Без перемешивания это просто объединение списка InputSplits в один раздел (если новый numPartitions <существующие разделы).В случае переоценки они будут зачитаны снова из источника.</p>

Если у вас было shuffling=true во время перераспределения, спарк ведет бухгалтерский учет, необходимый для поиска отсутствующих разделов и повторного запуска задач.Вы можете прочитать больше об этом здесь .Таким образом, при повторном чтении разделов из ввода применяется та же ситуация, что и выше.

PS: я предположил, что источником является Hadoop-совместимая файловая система.