Apache spark 火花测试：值得吗？（最佳做法）

使用ApacheSpark，我想知道它是否真的有价值，在哪一级进行测试

他们建议：

管道中的业务逻辑可能会随着输入数据的变化而变化。更重要的是，您需要确保从原始数据中推断出的是您实际认为正在推断的内容。这意味着您需要使用真实的数据进行健壮的逻辑测试，以确保您真正从中得到想要的东西

这建议引入某种测试

但让我印象深刻的是：

这里需要注意的一件事是，尝试编写一系列“Spark单元测试”来测试Spark的功能。你不想那样做；相反，您希望测试您的业务逻辑，并确保您所设置的复杂业务管道实际上正在做您认为它应该做的事情

这概述了本书的作者不鼓励单元测试（如果我误解了请纠正我）

可能值得测试的是通过Spark应用的数据转换逻辑

书中再次提到：

首先，您可以维护一个临时空间，例如一个交互式笔记本或其等效物，然后在构建关键组件和算法时，将它们移动到一个更永久的位置，如库或包。笔记本电脑体验是我们经常推荐的一种体验（我们正在用它来写这本书），因为它在实验中很简单

这建议您在交互式环境中测试数据转换逻辑，例如笔记本电脑（例如用于Pyspark的Jupyter笔记本电脑）。基本上，您可以直接看到转换产生了什么

---

所以我问那些比我更有经验的人，你同意书中引用的观点吗？（或者我误解了）它们可以作为该领域的一种最佳实践吗？（例如，避免单元测试，而是促进更高级别的测试，如逻辑/集成测试）

该声明并不是说要避免单元测试。这意味着要避免在业务中没有价值的测试数据，否则您将最终测试spark API，而不是您的业务组件。例如，您已经在spark UDF中编写了一个函数来进行聚合，因此在编写单元测试时，请确保为您的函数提供模拟生产环境的真实数据

---

借助zeepline这样的笔记本体验，您可以在一个地方完成所有阶段，如数据摄取、可视化。它与数据管道真的是互动的

过了一会儿再回到你的答案，用不同的方法阅读句子，让我理解了书中句子的含义，谢谢