我是一个大型Scala项目的新开发人员,在这个项目中,所有代码都存储在笔记本中,并在Databricks集群中运行.
每个笔记本都定义了类和方法,我们有“主”记事本,它们只有很少的代码行,但是在诸如%run ./myPackage/Foo这样的单元格中执行所有需要的Scala笔记本(即这个项目中几乎所有的笔记本)。然后,这些“主”笔记本有一个小小的Scala代码单元,如下所示:
import com.bar.foo.Main
Main.main()此外,每个笔记本都导入它所需的包,作为Scala指令import com.bar.foo.MyClass。
我觉得这很烦人:
%run path/Notebook命令。你知道另一个工作流程吗?是否有更简单的方法来处理Databricks中的多个Scala笔记本?
发布于 2019-12-12 18:03:13
我认为,当用户和公司将笔记本视为软件工程原则的替代品时,就会出现这些问题。软件世界为了解决这些问题,创建并广泛使用了设计模式,这是很难(如果不是不可能的)应用于笔记本的。因此,我认为用户不应该将笔记本作为开发最终用户解决方案的工具。笔记本的主要角色过去是用于原型化和ML测试,因此根据定义,它们不适合于模块化和可伸缩性是重要因素的情况。
至于您的情况,并假定笔记本的使用是不可避免的,我建议尽量减少笔记本的使用,并开始将代码组织到JAR库中。如果笔记本在它们之间共享代码的很大一部分,这将是有用的。
例如,让我们考虑一下笔记本N1和N2都在使用笔记本、N3和N4的情况。然后,您可以将N3和N4的实现放置到JAR中,让我们将其命名为common_lib.jar,然后通过将其附加到运行它们的集群(假设您运行了笔记本作业),使common_lib.jar对N1和N2都可用。通过遵循这一方法,您可以实现:
dbutils.widget.text(...)和dbutils.widget.get(...)肯定比用scala/java所能实现的要少得多。更新
对于您的情况(不可能重构到JAR库)的一个解决方案是将笔记本组织到模块中,每个模块将使用一个负责模块所有依赖项的__includes_文件。_includes__文件看起来可能是下一个片段:
%run "myproject/lib/notebook_1"
%run "myproject/lib/notebook_3"
...现在让我们假设笔记本、X1和X2它们共享相同的依赖项myproject/lib/notebook_1和myproject/lib/notebook_3,为了使用所提到的依赖项,您应该将__includes__文件放在同一个文件夹下并执行:
%run "_includes_"在X1和/或X2笔记本的第一个单元格中。通过这种方式,您可以使用一种通用的方法来包含项目的所有依赖项,并且避免重复复制/粘贴所有包含的情况。
这并没有提供一种自动的方法来检查和包含项目中依赖项的正确路径,尽管这可能是一个重大的改进。顺便说一句,我不知道有这样一种自动的方式来查看文件并动态地更改导入。不过,一种方法是编写外部自定义脚本。尽管这个脚本不应该通过您的工作来调用。
注意:您必须确保依赖关系的层次结构定义得很好,并且没有任何循环依赖关系。
https://stackoverflow.com/questions/59214940
复制相似问题