Impala SQL的Join优化，Explain执行计划分析

最新推荐文章于 2023-06-01 16:23:13 发布

九州Pro

最新推荐文章于 2023-06-01 16:23:13 发布

阅读量822

点赞数

分类专栏： Impala 文章标签： sql 数据库 hadoop 大数据数据仓库

本文链接：https://blog.csdn.net/lang830349821/article/details/130425839

版权

Impala 专栏收录该内容

2 篇文章 1 订阅

订阅专栏

1. 第一段SQL

查询1：

SELECT t1.id, t1.name, t2.salary, t3.department
FROM employee t1
JOIN salary t2 ON t1.id = t2.emp_id
JOIN department t3 ON t1.dept_id = t3.id
WHERE t1.age > 30 AND t2.salary > 50000;

Text Plan结果如下：

1. SELECT STATEMENT
2. |-- HASH JOIN (t1.dept_id = t3.id)
3. |   |-- AGGREGATE
4. |   |   |-- HASH JOIN (t1.id = t2.emp_id)
5. |   |       |-- SCAN HDFS (employee t1)
6. |   |       |   |-- PREDICATES (t1.age > 30)
7. |   |       |-- SCAN HDFS (salary t2)
8. |   |           |-- PREDICATES (t2.salary > 50000)
9. |   |-- SCAN HDFS (department t3)

接下来，我们逐句分析Text Plan结果，并根据分析结果来进行JOIN优化。

1. 行5和行7：SCAN HDFS操作表示在employee和salary表上进行全表扫描。全表扫描可能会导致大量数据读取，从而影响查询性能。为了减少扫描的数据量，可以考虑使用分区表或在表上创建索引。

2. 行6和行8：此处表示在employee表上应用了年龄过滤条件，以及在salary表上应用了薪水过滤条件。如果这些条件过滤掉了大量数据，说明查询条件有效。但如果过滤效果不佳，说明查询条件可能需要优化，例如使用更精确的条件进行过滤。

3. 行4：此行表示使用HASH JOIN进行连接操作，连接employee表和salary表。HASH JOIN可能会消耗较多的CPU和内存资源。根据查询的数据量和系统资源情况，可以考虑调整JOIN策略（例如，使用SORT MERGE JOIN）或者调整Impala的相关参数以优化性能。

4. 行2：此行表示使用HASH JOIN进行连接操作，连接前面JOIN的结果和department表。类似于第3点的讨论，可以考虑调整JOIN策略或参数以优化性能。

通过以上分析，我们可以尝试以下JOIN优化策略：

1. 如果可能，为employee表和salary表创建分区或索引，以减少全表扫描的数据量。
2. 优化查询条件以提高过滤效果，从而减少JOIN操作的数据量。
3. 根据数据量和系统资源情况，调整JOIN策略或Impala参数以优化HASH JOIN的性能。

优化后的SQL如下：

SELECT p.product_id, p.name, SUM(oi.quantity) AS total_quantity
FROM products p
JOIN (
    SELECT order_item.product_id, order_item.quantity
    FROM order_items order_item
    JOIN orders o ON order_item.order_id = o.order_id
    WHERE o.order_date BETWEEN '2021-01-01' AND '2021-12-31'
) oi ON p.product_id = oi.product_id
GROUP BY p.product_id, p.name

优化后的Text Plan结果如下：

1. SELECT STATEMENT
2. |-- AGGREGATE
3. |   |-- HASH JOIN (t1.product_id = t2.product_id)
4. |       |-- SCAN HDFS (products t1)
5. |       |-- SCAN HDFS (order_items t2)
6. |           |-- NESTED LOOP JOIN (t2.order_id = t3.order_id)
7. |               |-- SCAN HDFS (orders t3)
8. |                   |-- PREDICATES (t3.order_date BETWEEN '2021-01-01' AND '2021-12-31')

我们对优化后的Text Plan结果进行逐句分析：

1. 行4、行5、行7：SCAN HDFS操作表示在products表、order_items表、orders表上进行全表扫描。全表扫描可能会导致大量数据读取，从而影响查询性能。为了减少扫描的数据量，可以考虑使用分区表或在表上创建索引。

2. 行8：此处表示在orders表上应用了订单日期过滤条件。如果这个条件过滤掉了大量数据，说明查询条件有效。但如果过滤效果不佳，说明查询条件可能需要优化，例如使用更精确的条件进行过滤。

3. 行6：此行表示使用NESTED LOOP JOIN进行连接操作，连接order_items表和orders表。NESTED LOOP JOIN在处理大数据量时性能可能较差，可以考虑调整JOIN策略（例如，使用HASH JOIN）或者调整Impala的相关参数以优化性能。

4. 行3：此行表示使用HASH JOIN进行连接操作，连接products表和前面JOIN的结果。HASH JOIN通常在大数据量时性能较好，但需要足够的内存资源。如果内存资源有限，可以考虑调整JOIN策略（例如，使用SORT MERGE JOIN）或者调整Impala的相关参数以优化性能。

通过以上分析，我们可以看到优化后的查询结构和JOIN策略对性能可能有所改善。然而，为了进一步提高查询性能，还需要关注全表扫描的问题，通过使用分区表或创建索引来减少数据量。

3. 第二段SQL

查询2：

SELECT t1.id, t1.product_name, t2.category_name, t3.brand_name, t4.vendor_name
FROM products t1
JOIN categories t2 ON t1.category_id = t2.id
JOIN brands t3 ON t1.brand_id = t3.id
JOIN vendors t4 ON t1.vendor_id = t4.id
WHERE t2.category_name = 'Electronics' AND t3.brand_name = 'Apple';

Text Plan结果如下：

1. SELECT STATEMENT
2. |-- NESTED LOOP JOIN (t4.customer_id = t1.customer_id)
3. |   |-- SCAN HDFS (orders t4)
4. |   |   |-- PREDICATES (t4.status = 'COMPLETE')
5. |   |-- SORT MERGE JOIN (t1.product_id = t3.product_id)
6. |       |-- AGGREGATE
7. |       |   |-- SORT MERGE JOIN (t1.order_id = t2.order_id)
8. |       |       |-- SCAN HDFS (order_items t1)
9. |       |       |-- SCAN HDFS (shipping t2)
10.|       |           |-- PREDICATES (t2.shipping_type = 'EXPRESS')
11.|       |-- SCAN HDFS (products t3)

我们逐句分析Text Plan结果，并根据分析结果来进行JOIN优化。

1. 行3和行8：SCAN HDFS操作表示在orders表、order_items表上进行全表扫描。全表扫描可能会导致大量数据读取，从而影响查询性能。为了减少扫描的数据量，可以考虑使用分区表或在表上创建索引。

2. 行4和行10：此处表示在orders表上应用了订单状态过滤条件，以及在shipping表上应用了快递类型过滤条件。如果这些条件过滤掉了大量数据，说明查询条件有效。但如果过滤效果不佳，说明查询条件可能需要优化，例如使用更精确的条件进行过滤。

3. 行7：此行表示使用SORT MERGE JOIN进行连接操作，连接order_items表和shipping表。SORT MERGE JOIN可能会导致较多的磁盘I/O操作。可以根据查询的数据量和系统资源情况，调整JOIN策略（例如，使用HASH JOIN）或者调整Impala的相关参数以优化性能。

4. 行5：此行表示使用SORT MERGE JOIN进行连接操作，连接前面JOIN的结果和products表。类似于第3点的讨论，可以考虑调整JOIN策略或参数以优化性能。

5. 行2：此行表示使用NESTED LOOP JOIN进行连接操作，连接orders表和前面JOIN的结果。NESTED LOOP JOIN在处理大数据量时性能可能较差，可以考虑调整JOIN策略（例如，使用HASH JOIN）或者调整Impala的相关参数以优化性能。

通过以上分析，我们可以尝试以下JOIN优化策略：

1. 如果可能，为orders表、order_items表创建分区或索引，以减少全表扫描的数据量。
2. 优化查询条件以提高过滤效果，从而减少JOIN操作的数据量。
3. 根据数据量和系统资源情况，调整JOIN策略或Impala参数以优化SORT MERGE JOIN和NESTED LOOP JOIN的性能。

优化后的SQL如下：

SELECT c.customer_id, c.name, SUM(o.total_amount) AS total_amount
FROM customers c
JOIN (
    SELECT o.customer_id, o.total_amount
    FROM orders o
    WHERE o.order_date BETWEEN '2021-01-01' AND '2021-12-31'
) o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name

优化后的Text Plan结果如下：

1. SELECT STATEMENT
2. |-- AGGREGATE
3. |   |-- HASH JOIN (t1.customer_id = t2.customer_id)
4. |       |-- SCAN HDFS (customers t1)
5. |       |-- SCAN HDFS (orders t2)
6. |           |-- PREDICATES (t2.order_date BETWEEN '2021-01-01' AND '2021-12-31')

我们对优化后的Text Plan结果进行逐句分析：

1. 行4、行5：SCAN HDFS操作表示在customers表和orders表上进行全表扫描。全表扫描可能会导致大量数据读取，从而影响查询性能。为了减少扫描的数据量，可以考虑使用分区表或在表上创建索引。

2. 行6：此处表示在orders表上应用了订单日期过滤条件。如果这个条件过滤掉了大量数据，说明查询条件有效。但如果过滤效果不佳，说明查询条件可能需要优化，例如使用更精确的条件进行过滤。

3. 行3：此行表示使用HASH JOIN进行连接操作，连接customers表和前面的子查询结果。HASH JOIN通常在大数据量时性能较好，但需要足够的内存资源。如果内存资源有限，可以考虑调整JOIN策略（例如，使用SORT MERGE JOIN）或者调整Impala的相关参数以优化性能。

4. 第三段SQL

查询3：

SELECT t1.customer_id, t1.order_date, t2.product_id, t2.quantity, t3.product_name, t4.vendor_name
FROM orders t1
JOIN order_items t2 ON t1.id = t2.order_id
JOIN products t3 ON t2.product_id = t3.id
JOIN vendors t4 ON t3.vendor_id = t4.id
WHERE t1.order_date BETWEEN '2023-01-01' AND '2023-01-31';

Text Plan结果如下：

1. SELECT STATEMENT
2. |-- HASH JOIN (t1.customer_id = t2.customer_id)
3. |   |-- SCAN HDFS (customers t1)
4. |   |-- HASH JOIN (t2.store_id = t3.store_id)
5. |       |-- SCAN HDFS (orders t2)
6. |       |   |-- PREDICATES (t2.order_date BETWEEN '2021-01-01' AND '2021-12-31')
7. |       |-- SCAN HDFS (stores t3)

我们逐句分析Text Plan结果，并根据分析结果来进行JOIN优化。

1. 行3、行5、行7：SCAN HDFS操作表示在customers表、orders表、stores表上进行全表扫描。全表扫描可能会导致大量数据读取，从而影响查询性能。为了减少扫描的数据量，可以考虑使用分区表或在表上创建索引。

3. 行4：此行表示使用HASH JOIN进行连接操作，连接orders表和stores表。HASH JOIN通常在大数据量时性能较好，但需要足够的内存资源。如果内存资源有限，可以考虑调整JOIN策略（例如，使用SORT MERGE JOIN）或者调整Impala的相关参数以优化性能。

4. 行2：此行表示使用HASH JOIN进行连接操作，连接customers表和前面JOIN的结果。类似于第3点的讨论，可以根据系统资源情况调整JOIN策略或参数以优化性能。

通过以上分析，我们可以尝试以下JOIN优化策略：

1. 如果可能，为customers表、orders表、stores表创建分区或索引，以减少全表扫描的数据量。
2. 优化查询条件以提高过滤效果，从而减少JOIN操作的数据量。
3. 根据系统资源情况，调整JOIN策略或Impala参数以优化HASH JOIN的性能。

优化后的SQL如下：

SELECT c.customer_id, c.name, s.store_id, s.name
FROM customers c
JOIN (
    SELECT o.customer_id, o.store_id
    FROM orders o
    WHERE o.order_date BETWEEN '2021-01-01' AND '2021-12-31'
) o2 ON c.customer_id = o2.customer_id
JOIN stores s ON o2.store_id = s.store_id

九州Pro

关注

0
点赞
踩
6

收藏

觉得还不错? 一键收藏
0
评论
Impala SQL的Join优化，Explain执行计划分析

我们逐句分析Text Plan结果，并根据分析结果来进行JOIN优化。1. 行5和行7：SCAN HDFS操作表示在employee和salary表上进行全表扫描。全表扫描可能会导致大量数据读取，从而影响查询性能。为了减少扫描的数据量，可以考虑使用分区表或在表上创建索引。2. 行6和行8：此处表示在employee表上应用了年龄过滤条件，以及在salary表上应用了薪水过滤条件。如果这些条件过滤掉了大量数据，说明查询条件有效。
复制链接

扫一扫