使用Kimball的星型模式和数据集市的数据湖

Question

目标

术语让我有点困惑:我基于Kimball的数据建模方法构建了database (而不是DW)，现在不确定是否可以使用数据集市定义来命名MPP数据库层。

我的假设是，对于mid+大小的组织报告，仍然需要维度建模和星型模式，这与这篇文章中的推理相同。

问题

1. 在https://learn.microsoft.com/en-gb/azure/architecture/solution-ideas/articles/advanced-analytics-on-big-data将Synapse称为数据集市(见下图)是正确的吗？
2. 我可以说我没有DW (即使我有星型)，而是数据湖+数据集市？
3. 我是否应该基于业务/报告子域(多个数据集市)将Synapse拆分为多个模式？

建筑细节

​

​

更具体地说，在我的例子中：

2-3) ADLS +数据库形成数据湖。所有ETL和星型架构构建都发生在数据湖层。所有逻辑都在这里。尽管如此，它仍然有原始层的结构化和非结构化数据，使用廉价的ADLS存储，缺乏治理，有ML，并将在未来有流。另一方面，除了raw之外，我们在所有DL区域中都有模式在写，我们有预先建模的表(在这个过程中有很多需求变化)。我叫它数据湖是对的吗？

4.)Synapse是ETL/Lake结果的一个微小的投影/模型，以加快报告的响应时间。这里的逻辑几乎为零，几乎没有聚合。只有最终模型被加载到Synapse。数据不是由业务子域分割的，我们只是在一个DATAMART模式中加载所有的数据。这是个好办法吗？

Answer 1

首先，我不会太拘泥于定义，因为这些术语有很多(稍微)不同的定义。不过，在这情况下，我会对这些字眼作出以下的高层次定义：

1. Data :这是加载到数据存储中的源数据，您可以在那里开始分析它。它通常以与源系统中相同的方式构造(即它是“原始”数据)，另外还可以选择一些审计列，以显示数据的来源、加载时间等。一些数据湖有多个层，例如原始数据层，然后是受治理的数据层，其中的数据已被清理、标准化等，但与原始数据层的结构基本相同。
2. 数据仓库:这是您所有事实和维度表(加上其他表，如桥)的Kimball模型。它将根据您的数据湖中的数据构建。
3. 数据集市:这是一个主题区域，来源于您的数据仓库。这可能是一个逻辑定义(例如，Sales是销售事实表和相关维度)，也可能是物理化的，例如从事实及其维度生成的单一宽表。您如何定义您的数据记录通常取决于谁/什么正在使用它们以及它们的需求是什么。例如，您可能有多个销售数据集市，它们都基于相同的Sales，因为您有多个工具，它们更喜欢使用以特定方式构造的数据。

希望这能帮上忙？