因为我们计划将数据从 Teradata 迁移到谷歌云 (Bigquery)。 在 Teradata 中，我们拥有主要和外来等关键概念，借助这些键，我们能够定义维度和事实之间的关系。
例如，我有 3 个维度表和一个事实表，如下所示。
D1 D2 D3
F1
借助 Teradata 中的键或索引，我们可以从事实表中获取数据。
当我们来到 Bigquery 时，我们没有键或索引之类的任何概念，那么我们将如何 定义维度和事实之间的关系
注意：如果没有主键或索引概念，我们将如何消除重复项
【问题讨论】：
标签： google-bigquery fact
主键、事实和维度是上一代数据仓库性能需要依赖的概念。
例如，在 Teradata 中，需要一个主索引键来在节点之间分配数据。这种分布将是稍后启用快速执行查询的关键 - 但在 BigQuery 世界中，不需要这种类型的节点之间的预先计划分布。
事实、维度、星型模式、OLAP 多维数据集也是如此……它们存在的主要原因是为了在以后启用更快的查询 - 通过限制可以查询的内容以及在哪些维度之间进行查询。使用 BigQuery，您无需担心这一点。
与其将其划分为正常形式，不如使用包含 BigQuery 中所有维度的平面表。任意 JOIN 也会很快 - 但在这里可以轻松处理平面表和嵌套数据。
现在您不再受旧技术需求的限制 - removing duplicates 成为一种不同类型的操作。
【讨论】：
想一想当涉及到 SCD1 和 SCD3 时，您是如何处理该平面表的。
对于这两种情况，您需要在目标平面表上运行更新或从头开始生成新的平面表，而不是只更新维度表。
当前一代的 DWH 不像旧的 DWH 那样保持一致性和历史数据。当前一代仍然可以做平面表的唯一原因是因为他们要么考虑不可变数据，要么不遵循一致性规则。一旦数据输出增加基础设施和这些建模方式，这将在几年内结束，我们将再次回到维度模型。就像这样，如果您使用 PB 的数据，您不会一遍又一遍地重新加载该数据，因此您尝试将其拆分为增量批次，将不可变拆分为不可变的事实和维度。
如果您有超过几个 TB 的数据，或者您需要每小时加载 DWH，我会一直这样做。如果您的数据低于 1 TB 并且只需要在 DWH 中每日更新，那么最简单的方法可能是每次都重新加载。
【讨论】：