如何在 Databricks 中正确构建 Spark 代码？

Question

我在 Azure Databricks 中有一个比较大的项目，很快就会投入生产。该代码当前组织在存储库中的几个文件夹中，并且使用 ADF 触发任务，并且作业集群一个接一个地执行笔记本。 笔记本有一些硬编码值，如输入路径、输出路径等。

我认为这不是最好的方法。

我想摆脱硬编码的值并依赖一些环境变量/环境文件/环境类或类似的东西。

我正在考虑创建一些类，这些类将具有具有单独转换和转换之外的保存操作的方法。 你能给我一些建议吗？如何在 Databricks 中从另一个引用一个 scala 脚本？我应该创建一个 JAR 吗？

或者你能把我推荐给一些文档/好的公共存储库，在那里我可以看到应该如何做？

Answer 1

很难就如何去 prod 编写一个易于理解的指南，但这里有一些我希望我早点知道的事情。

生产时：

1. 一旦您拥有完善的流程，请尝试迁移到 jar jobs。
   笔记本用于探索性任务，不推荐用于长时间运行的工作。
   你可以pass params to your main，阅读环境变量或阅读火花配置。如何传递配置取决于您。
2. 选择New Job Cluster，避免使用All Purpose Cluster。
   在生产中，Databricks 建议使用新集群，以便每个任务在完全隔离的环境中运行。 New Job Cluster 的定价不同。我会说它最终会更便宜。
3. 这里是如何处理secrets

.. 以及其他一些离题的想法：

4. 我建议您查看CI\CD Jenkins recipes
5. 使用Databricks cli 自动部署

Answer 2

如果您在代码中使用笔记本，那么最好将代码分成以下几部分：

1. 带有“库函数”（“库笔记本”）的笔记本 - 仅定义将转换数据的函数。这些函数通常只是接收 DataFrame + 一些参数，执行转换并返回新的 DataFrame。这些函数不应该读/写数据，或者至少不应该有硬编码的路径。
2. 作为作业入口点的笔记本（我们称它们为“main”）——它们可能会通过widgets 接收一些参数，例如，您可以传递环境名称（prod/dev/staging）、文件路径等。这些“主”笔记本可能包括使用 %run 和相对路径的“库笔记本”，例如 %run ./Library1、%run folder/Libray2（参见 doc）
3. 用于测试的笔记本 - 它们还包括“图书馆笔记本”，但添加了调用函数和检查结果的代码。通常你需要有专门的库，比如spark-testing-base（Scala 和 Python）、chispa（仅限 Python）、spark-fast-tests（仅限 Scala）等来比较 DataRrames、模式等的内容（这里是examples of using different libraries) 这些测试笔记本可以作为常规作业或从 CI/CD 管道触发。为此，您可以使用Databricks CLI 或dbx tool（Databricks CLI 的包装器）。我有一个demo of CI/CD pipeline with notebooks，虽然它是用于 Python 的。

对于笔记本，建议使用Repos 功能，该功能允许同时对多个笔记本执行版本控制操作。

根据您的代码大小以及更改频率，您还可以将其打包为一个库，该库将附加到集群中，并从“主笔记本”中使用。在这种情况下，测试该库函数可能会更容易一些 - 您可以使用标准工具，如 Maven、SBT 等。

附：您还可以联系分配给您帐户的解决方案架构师（如果有的话），并更详细地讨论该主题。