【问题标题】：DBT - best practices to create staging views for the final business modelDBT - 为最终业务模型创建暂存视图的最佳实践
【发布时间】：2021-11-26 06:50:08
【问题描述】：
我正在研究一个业务模型/视图，其原始 SQL 定义包含对源表的非常复杂的查询。
我的问题是 - 我需要在源表上创建多个暂存模型，因为同一源上有不同的特定选择查询（无法在源上的单个暂存模型中处理）。处理这种情况的最佳做法应该是什么。
一种方法是直接在源代码上创建所有不同的暂存模型，并在我的最终业务模型中使用它们。
第二种方法是在源上创建一个暂存模型，该模型将包含源中的所有字段（在我的特定情况下不需要转换），然后使用此暂存模型创建具有特定sql查询。
如果有其他更好的方法，请告诉我。
【问题讨论】：
标签：
structure
etl
data-modeling
dbt
fishtown-analytics
【解决方案1】：
我很欣赏你的想法！我的回答真的比什么都更有意见。
我认为您应该遵循每个来源一个登台模型的做法。暂存模型仅用于翻译和轻度清洁。当源数据发生变化时，它们最能派上用场。在这种情况下，您只需要更改暂存模型，而不必触及任何下游模型。
因此，为您的相关来源提供了一个暂存模型，并且（显然）为最终用户提供了一个决赛桌。至于黑白中的内容，如果你喜欢的话！您可以选择拥有：
- 您的 3 个
SELECTs 是从您的暂存模型中选择的所有视图，以及从该视图中选择的最终模型。
- 只有一个直接从暂存模型构建的表模型，但您的 3 个
SELECTs 是最终模型查询中的 CTE，或者，
- 您的 3 个
SELECTs 都是从您的暂存模型中选择的临时模型（如果您的数据库适配器支持它们），以及从这些模型中选择的最终模型。这是上述两种方法的综合。
还有很多方法可以向最终用户隐藏中间模型。
您只需在以下方面做出对您和您的用户有意义的事情：
- 可观察性（阅读和理解您已实现的逻辑的最简单方法是什么？）
- 性能（对您的最终用户和您的开发而言最快的）
- 长期维护（随着项目的发展，什么能让您灵活地快速进行调整和改进？）