ETL - 视图或持久表？

Question

在构建数据仓库时，我通常会看到 ETL 流程的两种主要方法：

1.视图 - 视图视图 - 视图视图 - ...

方法一显然是在数据库中，其优点是您没有那么多冗余数据，但可能会导致性能问题。

2。 stage table（数据副本）- clear table（数据副本）- dwh table（数据副本）- ...

方法二可以通过许多工具来完成，例如存储过程和作业，或者像 SSIS 这样的 ETL 工具。 这里的优点是很容易理解这个过程，因为你可以很好地可视化它。您通常还具有非常好的整体 ETL 性能和许多预定义任务等。 例如，一个问题可能是，由于必须更改持久表，因此流程的更改更加复杂。

在现实世界中，您通常会看到两者兼而有之，尤其是在很多人都参与过该流程的情况下。 当然，这也取决于具体情况（表的大小、该公司如何设计类似的流程、ETL 流程的复杂程度……）。

我个人更喜欢复制表，保持 ETL 过程简单，并尽可能在为此目的设计的 ETL 工具（在我的情况下通常是 SSIS）中做所有事情。

但最佳实践是什么？为什么？

Answer 1

views 视图的视图不会随着 DWH 中的数据量而扩展。当谈到 dwh 时，我的意思是我们正在谈论大量数据。来自多个来源的数据集成是 dwh 的常见用例。 Stage->transform-->fact/dim 是构建 dwh 来存储数据的最常见方式之一。是的，当我们谈论 hdfs 和其他技术时，这会有所改变，但是视图无法在 dwh 中为您提供所需的性能。 我见过很多系统，它们都有一个多步骤的 etl 过程，您首先将数据从源中获取到 dwh，然后通过 ETL/其他清理/处理/符合/转换这些数据到您的维度/其他模型中。

Answer 2

如果您想知道时间点参考数据关系，在维度 DW 中实现为类型 2 或类型 3 缓慢变化的维度，您可能不会在源系统中找到它。

garpitmzn 提到的规模问题不仅与数据量有关，而且还涉及重构和非规范化数据以进行维度分析所需的连接。使用视图（除非具体化），您将为每个查询重复可能复杂的连接。最好在加载维度时执行一次。