旦建立了 Snowflake 用户/数据库/仓库环境，我们的团队经理 Emilie 便启动了一个 GitHub 问题，概述了项目应如何分解：
先做简单的事情- 将 Snowflake 连接到我们所有其他数据工具，例如 Fivetran、Segment、Census、Mode、Transform。
移植数据源- 创建所有数据源的清单。许多数据源已由 Fivetran 处理，但我们也有用于生产和计费数据的自定义提取管道。我们根据数据源迁移的“难易程度”（即 Fivetran 比在 Spark 上运行的自定义脚本更容易）和它们对下游模型的“中心程度”（即团队和站点的生产数据优先于更外围的数据源）来组织数据源。
关注水平切片- 如果您查看dbt 中的典型数据转换 DAG，则每个数 美国电报号码数据库 源都有一组相应的基础和暂存模型。我们称这些为“水平切片”，我们每个人都负责迁移一组这样的切片（通常基于我们对这些数据集的熟悉程度）。我们还对每个暂存模型进行了数据检查，以便尽早捕获和解决数据差异（并且在它们影响下一组下游模型之前）。快照模型被视为这些切片的一部分。
迁移业务逻辑- 迁移足够多的基础和暂存模型后，我们便转向事实、维度和集市模型。我们将这些模型划分为业务领域：核心实体（用户/团队/站点）、财务、产品、营销、人力资源等，并根据我们通常合作的业务团队进行分配。与基础和暂存模型一样，我们要求在 PR 审查期间对所有表进行数据检查，以确保我们的 DBX 和 Snowflake 数字一致。
更新报告和仪表板- 一旦迁移了足够多的事实/维度/市场模型，我们就可以开始更新我们的模式报告并将它们重新指向 Snowflake 模型。为了确定这些报告的优先级，我们首先迁移了使用率最高的 20 个报告，然后依靠我们的经验来决定我们需要迁移或存档哪些剩余报告。在某种程度上，这一步也充当了仪表板清理工作！此外，整个业务中都有报告 URL 链接（Slack 对话、Google 幻灯片、Notion 文档），我们不想破坏其中任何一个，因此我们对每个