第25章 代码位置最佳实践：如何组织 Dagster 项目

如何组织代码位置以实现清晰、可维护与复用。

代码位置是 Dagster 中最独特且功能强大的特性之一。它支持你维护多个彼此隔离的环境，每个环境拥有独立的 Python 库和依赖项。这让你能够轻松确保任务在正确的上下文中执行。更棒的是，Dagster 支持在单一部署中运行多个代码位置，同时仍提供统一的资产图和端到端的数据血缘。

这种灵活性极为实用，但也引发了一个常见问题：“我该如何构建我的代码位置？” 坦率地说，答案是：“视情况而定。” 没有放之四海而皆准的方案。理想的设置因团队结构、工作流以及组织管理代码的方式而异。

话虽如此，我们在实践中（包括内部团队和 Dagster 社区）观察到几种常见模式。你可能会发现其中一种（或几种组合）符合你所在组织组织 Dagster 项目的需求。

单一代码位置

使用单一代码位置完全没有问题。事实上，你的首个 Dagster 部署很可能就是这样开始的。单一代码位置有多重优势：只需管理一个环境，所有资产集中在一起，且跨项目追踪变更更加容易。当所有组件都位于同一上下文中时，端到端测试管道也会更简单。

单一代码位置最适合早期阶段的项目或专业化程度较低的小团队。例如，团队可能包含数据分析师和数据工程师，但角色界限灵活。分析师可能会调整 ETL 任务，工程师可能会构建仪表板。在这种情况下，将所有内容集中在一处有助于协作并减少开销。

按团队划分的代码位置

随着 Dagster 项目的发展或贡献者增多，可能就需要考虑将代码拆分到多个代码位置。最常见的方式之一是按团队划分。

按团队拆分的一个关键原因是开发节奏的差异。例如，分析师可能频繁更新建模逻辑，而数据工程师对核心 ETL 管道的变更则较少。虽然在单一仓库和代码位置中也能管理这种情况，但创建独立的代码位置能更好地让每个环境与用户的具体需求和工作流保持一致。

基于团队的代码位置也是引导新团队接入 Dagster 的好方法。例如，如果一个新的 AI 或 ML 团队希望开始尝试 Dagster，你可以为他们分配一个独立的代码位置。这样他们就能独立进行构建、测试，甚至失败，而不会影响项目的其他部分。

基于工具划分的代码位置

另一种方法是使用基于工具的代码位置来组织项目。在实际操作中，这看起来可能类似于按团队组织的结构。但区别在于，你是按功能和底层依赖项来分组代码，而不是按使用人群。

例如，与其创建一个名为 “data_analyst” 的代码位置，不如为 dbt 创建一个专门的代码位置。这能明确该代码位置负责你的建模层，并帮助将该功能与管道的其他部分隔离开来。通过保持依赖项精简，避免不必要的包，还能简化环境管理。

当不同的工具或框架需要特定的配置或运行时环境时，基于工具的代码位置尤为有用。这种架构有助于增强清晰度，并在摄入、转换和报告等关注点之间建立清晰边界。

专用代码位置

一种稍不常见但完全可行的做法是为特定管道创建独立的代码位置。这在某些流程比其他流程更关键时特别有用。如果你需要对一组特定资产进行精细调整、隔离或严格管控，将它们放入独立的代码位置能提供极大的灵活性。

想象一下，你的数据科学团队管理着多个模型，但预计到达时间（ETA）模型直接驱动了网站大部分流量。与其将所有模型放入共享依赖的单个代码位置，不如将 ETA 模型提取到其专属的代码位置中。这样，你可以锁定依赖项，应用更严格的测试或部署标准，并独立于其他建模代码进行管理。这种方法允许你在更新或迭代大多数管道的同时，保持最关键工作流的稳定，并将其与无关变更隔离开来。

解耦共享代码

如果你发现资产之间存在大量共享的 Dagster 代码，不必感到有压力将所有内容保留在同一代码位置中。在许多情况下，将通用逻辑（如自定义 Dagster 资源、工具或助手函数）与特定资产定义解耦是更好的选择。

例如，假设你想将 Dagster 项目拆分到多个代码位置，但它们都依赖于同一个用于与公司内部 API 交互的自定义 Dagster 资源。与其将所有内容保留在一个单体代码位置中，或在每个代码位置中分别维护该资源，更干净的解决方案是将共享资源提取到一个独立的 Python 模块中。你可以单独发布和版本化管理该模块，并将其作为依赖项引入到需要它的各个 Dagster 代码位置中。

管理此模式的常见方法是将其上传到私有软件包仓库，例如 AWS CodeArtifact。这样既保留了库的内部属性，又便于通过 `pip` 在各环境中轻松安装。

现在，每个代码位置都可以通过 CI/CD 构建其 Docker 镜像或虚拟环境，对 CodeArtifact 进行身份验证，并像安装其他依赖项一样安装共享库。这种方法的另一个重大优势是版本控制。通过发布具有特定版本的共享库，每个代码位置可以锁定其特定使用版本，从而更容易协调升级并降低跨团队破坏性变更的风险。以这种方式解耦代码还有助于在多个开发 Dagster 的团队之间强制执行一致的标准。

哪种方式最适合你？

这些只是设计代码位置时可以考虑的几种模式。好消息是没有硬性规则。由于 Dagster 的架构使代码位置实际上非常轻量且隔离，你可以拥有任意数量的代码位置，并以最适合你组织的任意组合方式使用它们。

你可能会发现某些团队更倾向于拥有独立代码位置带来的自主权，或者某些 Python 库存在版本冲突，而这些冲突在隔离环境下更容易管理。

因此，不要害怕尝试不同的布局，看看哪种最符合你的工作流。目标在于创建一个能随团队扩展的结构，使数据平台的管理更加轻松。

有反馈或问题？在 Slack 或 Github 发起讨论。

有兴趣与我们共事？查看我们的开放职位。

想要更多类似内容？关注我们的 LinkedIn。