一个构建实际使用的dbt模型的简单框架。
当我在研究dbt的终极指南时，我对实际从头构建模型的材料缺乏感到震惊。并不是工具中要采取的确切步骤 – 这些都在无数的博客和教程中都有涵盖。我指的是如何知道正确的设计？如何确保您的利益相关者将使用该模型？如何确保它将被信任和理解？
当我们在不采取这些步骤的情况下部署新模型时，可能会产生重大后果：
- 我们面临来自利益相关者的一连串问题和后续请求
- 我们会从其他数据工程师或分析工程师那里得到代码改进的建议
- 我们必须回过头来添加新功能，进行改进，并在完成工作之前回答所有问题
如果我们一次又一次地重复这个过程，数据和业务团队之间的信任就会开始瓦解，因为双方都因为这种反馈狂潮而变得越来越疲惫，这是一件非常具有挑战性的事情。
这凸显了仔细思考如何设计模型的重要性，不仅在dbt中独自进行，而是与所有利益相关者共同进行，以确保模型准确有效，不浪费时间构建每个模型4-5次，直到它有用。
本文是对如何最佳设计和实现dbt模型的研究和实验的结果。它不会有任何在dbt中执行的命令，但会讲述如何思考您的模型以及如何构建工作流程，以确保您不会浪费时间。
一种不同的方法
幸运的是，我不是第一个思考这个问题的人。许多其他领域也面临类似的挑战，并已经创建了自己的框架和流程，我可以在考虑如何进行数据建模时借鉴。例如：
敏捷原则反对瀑布式开发方法，这与需求快速变化的环境相矛盾[1]。相反，敏捷方法支持快速迭代，并承认能够快速响应变化需求的竞争优势。
设计原则同样承认在设计项目中如何与多个利益相关者合作时需要谨慎[2]。该框架优先考虑人员，并鼓励在开发的每个阶段进行反馈，以便尽快找到最佳解决方案。
甚至数据建模之父Ralph Kimball在他的数据建模4步骤过程中也强调了在建模过程中从利益相关者那里获得高质量输入的重要性[3]。其中的第一步是在构建模型之前尽可能多地了解业务流程。
然而，在思考这个问题时，我发现最有影响力的来源是系统工程启发法则 – 这是一组关于在涉及多个利益相关者的复杂问题上工作的真理[4]：
- 不要假设原始问题陈述一定是最好的，甚至是正确的。
- 在项目的早期阶段，未知问题比已知问题更重要。
- 在可能的情况下，先建模再构建。
- 大多数严重错误都是在早期阶段发生的。
这些来源帮助塑造了从零开始设计数据模型的以下过程。
数据建模设计过程
因此，我想构建一个符合这些原则的流程，它是可重复的，并且能确保我的模型第一次就构建得很好。
这是我想出来的方法：
我们将在下面逐步详细介绍每个步骤。
以下示例将展示 count.co 的屏幕截图，count.co 是我负责的数据画布。然而，重要的是要注意，这个流程是与工具无关的。您可以在这里的示例截图中跟随操作。
第一步：发现
目标：了解您要建模的业务流程。
参与者：您、业务利益相关者
活动：
- 绘制业务流程图
- 确定利益相关者希望在最终表格中做什么（例如他们需要计算哪些指标，需要添加哪些筛选器等）
- 了解他们目前是如何做到这一点的（如果他们在做的话）。现有解决方案有什么问题？
- 还有谁会使用这个？还有其他次要利益相关者需要与之交流吗？
- 还有其他相关业务背景吗？例如，某人下周有一个关于这个主题的重要演讲
第二步：设计（并迭代！）
目标：绘制构建模型的可能方法
参与者：您
活动：
- 绘制最终表格
- 选择什么粒度？
- 包括哪些列？
- 如果有多个最终表格设计的选项，请绘制它们，并在继续之前征求利益相关者的反馈
第三步：原型（并迭代！）
目标：绘制达到协商一致的最终表格的方法。包括代码和说明。
参与者：您、数据团队成员、利益相关者
活动：
- 绘制模型的每个步骤，包括每个阶段的代码和结果
- 确保数据团队的另一成员审查您的代码
- 与利益相关者一起讨论逻辑，确保其与他们的期望和背景一致
- 验证原型模型的结果
- 迭代，直到业务利益相关者和数据团队都理解并批准方法和结果
第四步：部署
目标: 在dbt中部署模型
参与者: 您
活动:
- 将最终的原型代码部署到您的dbt代码库中
- 确保通过所有测试
步骤 5: 交付
目标: 让利益相关者知道该表现在可用，并说明如何与该表进行交互
参与者: 您，商业利益相关者
活动:
- 创建文档（可以在dbt中或其他地方）
- 将表格和文档的链接发送给利益相关者
- [可选] 使用该表格创建示例分析，以便他们有一个起点
- [可选] 为任何想要了解新表格的人组织一个简短的介绍会议
下一步
下次您开始从头开始构建一个dbt模型时，请尝试使用这个过程。这对您和利益相关者来说都是一个重大变革，但它已被证明可以显著减少部署新模型所需的时间，并提高这些模型的整体接受度。
将更多的人纳入您的数据建模过程，并展示透明度的简单行为有助于促进信任，并快速交付有价值的数据模型。
如果您尝试了这个过程，请给我留下评论，让我知道进展如何以及对改进的任何想法！毕竟这些事情必须不断迭代…
资源
[1] 敏捷宣言。 (2001). 敏捷宣言背后的原则。2023年7月1日检索自https://agilemanifesto.org/principles.html
[2] 设计委员会。 (2004). 创新框架。2023年7月1日检索自https://www.designcouncil.org.uk/our-resources/framework-for-innovation/
[3] Holistics。 Kimball的维度数据建模。2023年7月1日检索自https://www.holistics.io/books/setup-analytics/kimball-s-dimensional-data-modeling/
[4] Peter Brook. “系统工程启发法。”于SEBoK编辑委员会。2023.《系统工程知识库指南》（SEBoK），v. 2.8，R.J. Cloutier（主编）。Hoboken, NJ:史蒂文斯理工学院信托基金。[DATE]访问www.sebokwiki.org。BKCASE由史蒂文斯理工学院系统工程研究中心、国际系统工程委员会和电气和电子工程师学会系统委员会管理和维护。