bigquery中是否有事实和维度之类的概念

is there concept like fact and dimension in bigquery

因为我们计划将数据从 Teradata 迁移到 google 云 (Bigquery)。 在 Teradata 中,我们拥有主要和外部等关键概念,借助这些键,我们能够定义维度和事实之间的关系。

举例来说,我有 3 个维度 tables 和一个事实 table,如下所示。

D1 D2 D3

F1

借助 Teradata 中的键或索引,我们可以从事实中获取数据 table。

在使用 Bigquery 时,我们没有键或索引等任何概念,那么我们将如何进行 定义维度和事实之间的关系

注意:如果没有主键或索引概念,我们将如何消除重复项

主键、事实和维度是上一代数据仓库性能需要依赖的概念。

例如,在 Teradata 中,需要一个主索引键来在节点之间分发数据。这种分布将是以后启用快速执行查询的关键 - 但在 BigQuery 世界中,不需要这种类型的节点间预先计划的分布。

与事实、维度、星型模式、OLAP 多维数据集相同......它们存在的主要原因是为了以后能够更快地查询 - 通过限制可以查询的内容和维度。使用 BigQuery,您无需担心这一点。

与其划分为正常形式,不如将所有维度纳入 BigQuery 的平面 table 是有意义的。任意 JOIN 也会很快 - 但扁平 tables 和嵌套数据在这里很容易处理。

现在您不再受旧技术需求的限制 - 成为一种不同类型的操作。

想一想当涉及到 SCD1 和 SCD3 时,您是如何处理公寓 table 的。

对于这两个,您需要 运行 更新目标平面 table 或从头开始生成新的平面 table 与仅更新维度 table。

当前一代的 DWH 不像旧的 DWH 那样保持一致性和历史数据。当前这一代仍然可以做到 tables 的唯一原因是他们要么考虑 immutable 数据,要么不遵循一致性规则。一旦数据再次增长基础设施和这些建模方式,这将在几年内结束,我们将再次回到维度模型。如果您使用 PB 数据,就已经是这样了,您不会一遍又一遍地重新加载该数据,这会花费太多,因此您尝试将其拆分为增量批次,将 immutable 拆分为 none immutable 又名事实和维度。

如果您有超过几 TB 的数据,或者如果您需要每小时加载 DWH,我会一直这样做。如果您的数据量低于 1 TB,并且只需要在 DWH 中进行每日更新,那么最简单的方法可能是每次都重新加载。