什么是查询驱动的数据建模？
查询驱动的数据建模 你需要了解的基础知识
如果你错过了，几周前我与《数据工程基础》的一位共同作者有过一次直播节目，介绍了查询驱动的数据建模概念。
现在他参考的是标准的数据建模概念，包括：
- 概念性建模
- 逻辑建模
- 物理建模
- 还有第四个——查询驱动建模
根据Reis的说法，很多公司不再执行前两个步骤，经常直接开发查询来支持一次性的请求。因此，我们很可能甚至没有使用星型模式的任何形式，甚至没有询问我们是否在构建数据集市或数据仓库。
相反，我们很可能只是构建表来支持单个请求。或者，正如Joe所说的，查询驱动的建模。
但是，查询驱动建模是什么，它在数据世界中有何作用呢？
查询驱动建模
来源：作者
现在，并没有官方的QDM或JIT数据模型定义，尽管我们以前有过“按需读取模式”的术语，与之有些相似。
但我想很多人都知道它是什么。
这是根据单个利益相关者的请求构建表或数据集。可能会有一些需求收集，但只针对一个利益相关者。
查询驱动建模的好处
现在，就像作为工程师的你所做的任何选择一样，有利有弊。
- 快速获得初步洞察 — 使用查询驱动方法开发的最明显好处就是在短期内获得洞察（至少在短期内）。
- 自服务 — 工具 像dbt 对许多团队来说是一个很好的数据入口。它们也有助于加快分析师和SQL熟练人士从查询到数据表的能力。反过来，这也使得团队更快地达到了“圣杯”自服务的目标。当我刚开始接触数据领域时，我记得曾与EDW团队联系，询问我构建的查询何时可以部署…作为一个视图。这不是什么疯狂的事情。许多分析团队可能无法在这种环境中有效运作，结果可能会创建一个影子IT团队，反过来又可能创建一个数据仓库。
- 短期内利益相关者将感到满意 — 许多数据团队陷入不断开发JIT的循环中，因为利益相关者常常面临开发的压力。经理和主管需要数据给他们的副总裁，副总裁需要数据给C-Suite，C-Suite又需要数据给董事会。不断加大的压力使新晋分析师或工作过度的数据工程师被迫提供他们的经理要求的内容。
因此，使用查询驱动建模是答案。您可以从原始数据集查询，对数据进行一些初步检查，然后迅速获得结果。
答案。
每个人都会感到满意。
查询驱动建模的缺点
团队决定使用即时交付方法（JIT）来应对数据模型时，总是会付出一定的代价。不管这是否是一个有意的决策，它已经做出了。这其中存在明显的权衡。
- 需要更改时敏捷性减弱 — 尽管开发时间更短，但随着模型、依赖关系和技术债务的积累，系统的转向和更改能力将变得更加困难。在开发的复杂系统中，每个新的弱环节都可能成为潜在的失败点，而无人察觉。
- 缺乏一致的指标 — 数据团队采用即时交付方法时，很有可能由多个团队使用稍有不同的方法开发相同的指标，导致团队数字不匹配的典型问题。我见过很多公司，包括Facebook，都会创建某种形式的指标层或门户，用于定义关键指标并指明其使用情况。
- 绕圈子的数据管道 — 当过度依赖即时交付时，创建的数据管道系统很容易变成绕圈子的数据管道。你会发现自己已经走过18个有向无环图（DAGs），然后才发现你原以为是从来源A获取的customer_category字段实际上是由目标B填充，并最终返回来源A的（我见过这种情况）。
- 数据集不够稳定 — 除了自依赖的风险之外，另一个问题是对一个管道进行即使是被认为微小的更改可能会产生重大后果。由于没有将某个表定义为核心，并且管理较少，很难完全了解更改的权重。现在我们确实针对这个问题提供了一些解决方案，比如数据血统；但在某种程度上，如果你过分依赖数据血统来追踪数据集的重要性，那么你很可能已经有一个问题。
- 成本 — 当我第一次进入数据领域时，我的利益相关者告诉我他们想要实时数据看板。所以我在我的Tableau看板上点击了“实时数据”并发布了它们。
嗯，正如你可能能想象到的，如果你在数据领域已经待了两三年，就不会过多久，我们就会有两名顾问找我解释这导致服务器出现了一个相当大的峰值。事实上，像Tableau和dbt这样的工具可以解决问题，但它们也可能引发新问题。它们太容易使用，不仅可以提高见解的速度，还可能加快错误决策和计算机使用速度，从而导致更大的成本。
鉴于这些缺点，查询驱动建模在数据世界中是否有存在的价值呢？
查询驱动模型在数据世界中有何位置
我确实认为有一些场景适合更加即时交付的方法来创建数据集。这就是为什么Analytics Engineer这个角色对某些团队来说是合理的。
当公司有较大的数据团队并且每个部门都有明确的数据使用目标时，使用即时交付方法结合传统的核心数据模型是有意义的。
这基本上就是我们在Facebook所做的。
我所在的团队创建了我认为是“数据即为基础设施”。也就是说，我们构建的表格被Facebook许多其他团队所依赖。其他数据工程师根据我们构建的内容构建他们的洞察和分析。
到了某个时候，我们无法手动地进行理解对小的更改造成了什么影响。这意味着我们不得不将我们的数据看待为基础设施，而不仅仅是因为单个利益相关者的需求而进行更改的表格。
然而，如果离我们只有一个团队的距离，你会发现一个由非常技术的分析师或以业务为重点的数据工程师组成的团队，他们需要创建更多支持明确业务要求的一次性数据集（现在，这有时会使我们很难直接指出我们的影响，因为它是非常综合的）。但是，将核心表格视为基础设施，并制定政策和治理措施以确保小的更改不会破坏所有的依赖关系是有道理的。显然，这并不是一个完美的模型，我见过很多小型组织通过运用即时交付模型或其他方式运行良好，但没有一个真正讨论概念建模。
但一般来说，你最终会需要为技术债务付出代价，无论是通过代码重写还是继续前进，并发现你达到了这个网络流行语成为现实的地步。
如果你需要帮助评估你的数据基础设施或数据战略，请立即咨询！
<p这在许多现代数据团队中经常发生，通常是因为分析师和数据科学家被迫开发自己的数据流水线。他们通常专注于回答一组特定的请求。
不开发强大的数据集可以支持多种用例。
设计只是事后的思考
<p当需求不断变化时，根据需求构建数据集和工作流程具有一些好处，就像极限原型设计具有一些好处一样。但是对于每一个好处，都会有相应的权衡。
数据集成为复杂的依赖树的一部分，业务需求不断变化，并且查询不断恶化，达到了可能比最初测试时更多的使用权重。
以建筑物中承受新压力的梁为例。
最终，它会坍塌并可能连同其他几根梁一起倒下。
查询驱动建模是一种数据建模吗？当然是。
但是你最好知道风险。
文章原始发布在这里。重新发布已获得许可。
</p当需求不断变化时，根据需求构建数据集和工作流程具有一些好处，就像极限原型设计具有一些好处一样。但是对于每一个好处，都会有相应的权衡。</p这在许多现代数据团队中经常发生，通常是因为分析师和数据科学家被迫开发自己的数据流水线。他们通常专注于回答一组特定的请求。
