由于节点故障和源上更改的数据，从原始源一直重新计算Spark分区

Question

我无法模拟此情况，因此可以快速检查非流式传输情况，仅是DF或RDD常规处理：

• 如果Spark Worker节点失败
  • ，因此丢失了给定的RDD计算/计算
    • ，并且没有应用任何缓存，检查点等，
      • 然后进行重新计算，
        • 如果源处的数据已更改，这如何显示出来？这可能意味着实际上其他节点由于重新分区而需要一些额外的数据？
        • 就初始读取的性能而言，这可能意味着大量数据，然后进行了重新分区，这意味着什么？

即我们在这里谈论的是不确定性情况。

Answer 1

更新-如果我们考虑类似JDBC的源，则在重新计算期间将对数据库执行查询[1]。如果记录发生更改，将导致结果偏斜。我认为这项工作不会失败。

[1]-这是基于JdbcRDD代码的。

---

关于第一个问题，Spark的分区非常相似（实际上是从InputFormat的Hadoop InputSplit构建的）。每个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 <现有分区）。在重新评估的情况下，将从源头再次读取它们。

如果在重新分区期间有shuffling=true，则Spark会进行簿记以查找丢失的分区并重新运行任务。您可以阅读有关该in here的更多信息。因此，在从输入中重新读取分区时，适用与上述相同的情况。

PS：我假设源是与Hadoop兼容的文件系统。