时间戳

首页 > 解决方案 > Spark SQL 临时视图的最佳实践

hive - Spark SQL 临时视图的最佳实践

问题描述

我是新手Spark。我们使用 Spark-SQLHive在AWS EMR.

我正在通过逐步构建几个临时视图来运行复杂的查询。

例如，第一个临时视图是通过在步骤 1 中连接几个表来创建的，然后在下一步中使用这个临时视图作为源，依此类推，直到最后一步，最后一步的结果被持久化到磁盘. 下面给出一个例子：

create temporary view test1 as
select a.cust_id, b.prod_nm
from a 
inner join b
on a.id = b.id;

create temporary view test2 as
select t1.*, t2.*
from test1 t1
inner join c t2
on t1.cust_id = t2.cust_id;

请注意，第一步的结果视图 (test1) 在第二步中用作 Join with another table 中的源C。

现在，由于lazySpark 的评估，即使在每一步都创建了临时视图，但直到最后一步才会提取数据。因此，我们经常在实现复杂转换的查询中遇到性能问题（例如，连接多个表）。

基本上我有2个问题：

  1. 如何估计这种临时视图的大小（在任何给定步骤），以便在下一步中将此视图连接到另一个表/视图时，我可以在下一步中选择正确的连接策略
  2. 使用这样的框架来提高性能的最佳实践是什么。

注意：我们使用 Spark 2.4。我无权访问 PySpark，但只能访问 SparkSQL（查询配置单元表）。

任何帮助表示赞赏。谢谢。

标签： hiveapache-spark-sql

解决方案

  1. 您无法确定您创建的临时视图的大小。
  2. 当使用像 spark 这样的分布式框架时，你的连接策略不应该基于数据的大小，而是数据/连接键如何分布在多个分区上。如果你多次使用同一个临时视图，最好缓存它，这样应用程序就不会每次都从 hdfs/s3 读取它。

在 SQL 中缓存的代码CACHE TABLE cache_view AS SELECT * from table;

推荐阅读