单个查询与阶段的连接性能

Question

[目前，我使用ETL在DWH Spark SQL项目中工作。我们通过在阶段中构建几个temporary views来进行数据转换，每个阶段都使用在上一个阶段中创建的临时视图来进行。下面是一个示例：

create temporary view tab_1 AS
select c.cust_id, p.prod_id, p.prod_name, p.region_id
from cust c
inner join prod p
on c.cust_id = p.cust_id;

create temporary view tab2_final AS
select t.cust_id, p.prod_name, r.region_name
from tab_1 t
inner join region r
on t.region_id = p.region_id;

实际上，这些查询通过多次联接到大表而变得更加复杂。

我的问题是：如果我们将多个表连接在一起，将连接表分成较小的块并在每个步骤中创建临时视图，然后最后将所有此类临时视图最终合并，是否更有效？获得预期的结果？还是在同一个sql中一次执行所有联接会更有效？

例如我有一个查询，它在单个步骤中有25个带有Left Join的庞大联接表。尽管联接逻辑非常简单，但是性能却很差，最终要花费数小时才能一次性处理所有表。

那么将它们分成较小的可管理组并最终合并视图最终会更有效吗？

在这种情况下，请您分享您对拇指法则的想法？

PS：我们使用Spark SQL，而不是PySpark-SQL。

谢谢

Answer 1

如果性能是问题，则应该对数据进行测试。

通常，临时表会产生开销：

• 数据需要明确地作为表写入。即使查询需要临时存储，它也不会为bona fide表带来额外的开销。
• 将中间体材料化会丢失诸如分区之类的信息。在其他数据库中，丢失的索引可能更为重要。
• SQL优化器会考虑信息以确定join的顺序。实例化中间表排除了这种优化。

就是说，在某些情况下，此类临时表可能会有所帮助。这是两种情况：

1. 中间结果需要由多个目标表使用。临时表使您可以在多个查询中共享这样的结果。
2. 优化器的工作不如预期。

就是说，我倾向于发现带有中间表的脚本很难维护。由于没有重新创建中间表并且进入最终表的数据不是我期望的最新信息，因此我花了数小时的时间调试代码。