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

Data Lake with Kimball's Star Schema and Data Mart

Objective

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

我假设您仍然需要维度建模和星型模式来制作中型以上规模的组织报告,与 this article 中的推理相同。

问题

  1. the following architecture 将 Synapse 称为数据集市是否正确(见下图)?
  2. 我能说我没有数据仓库(即使我有星型模式),而是有数据湖 + 数据集市吗?
  3. 我是否可以根据 business/reports 个子域(多个数据集市)将 Synapse 拆分为多个模式?

架构细节

更具体地说,就我而言:

2-3) ADLS + Databricks 形成数据湖。所有 ETL 和星型模式构建都发生在数据湖层。所有逻辑座位都在这里。它仍然在原始层有结构化和非结构化数据,使用廉价的 ADLS 存储,缺乏治理,有 ML 并且将来会有流媒体。另一方面,我们在除原始之外的所有 DL 区域中都有写时模式,我们有预先建模的表(在此过程中有很多需求更改)。 我称它为数据湖对吗?

4.) Synapse 用作 ETL/Lake 个微小的 projection/model 结果,以加快报告响应时间。这里的逻辑几乎为零,聚合很少。只有最终模型被加载到 Synapse。 数据未按业务子域拆分,我们只是将所有内容加载到单个 DATAMART 模式中。 这是个好方法吗?

首先,我不会太拘泥于定义,因为这些术语有很多(略有)不同的定义。但是,鉴于此,我将对这些术语给出如下 high-level 定义:

  1. 数据湖:这是加载到数据存储中的源数据,您可以在其中开始分析它。它的结构通常与源系统中的结构相同(即它是“原始”数据),另外还可以选择一些审计列来显示数据的来源、加载时间等。 一些数据湖有多层,例如原始数据层,然后是数据已被清理、标准化等的受控数据层——但仍与原始数据层的结构基本相同

  2. 数据仓库:这是您所有事实和维度 table 的 Kimball 模型(加上其他 table,例如桥梁)。它将根据您的数据湖中存在的数据构建

  3. 数据集市:这是一个来自您的数据仓库的主题区域。这可能是一个逻辑定义(例如,销售集市是销售事实 table 和相关维度)或者它可能是物理化的,例如从事实及其维度生成的单个宽 table。您如何定义数据集市通常取决于 who/what 正在使用它们以及它们的要求是什么。例如,您可以拥有多个销售数据集市,所有这些都基于同一个 Sales Star,因为您有多个工具更喜欢使用以特定方式结构化的数据

希望这有帮助吗?