hive笛卡尔积优化、join或left join 无on条件优化

最新推荐文章于 2026-02-25 16:51:03 发布

原创

最新推荐文章于 2026-02-25 16:51:03 发布 · 4.1k 阅读

标签

#hadoop #hive

在大数据处理中，笛卡尔积可能导致数据膨胀，影响计算效率。本文介绍了如何处理imeis_table（40亿条）与dim_table（800+条）的笛卡尔积场景。常规的Python脚本写法在数据量大时会导致单个reduce任务过载。通过改进写法，使用LATERAL VIEW EXPLODE进行列转行，可以在map阶段完成并行处理，提高执行效率，避免reduce端的数据倾斜问题。

正常业务中我们是不希望看见笛卡尔积的，因为它会造成数据膨胀，数据成倍增长，极有可能使得计算崩溃。但是有时因为业务需要，我们又不可避免笛卡尔积，那我们该如何做呢？接下来我们来看一种场景。

业务背景

imeis_table表中只有imei字段数据量40亿条左右

dim_table表一张维表，数据量800+条

目的是的imeis_table表与dim_table表做笛卡尔积，结果就是40亿*800+条，显然数据量是非常大

常规写法(pyhton脚本)

import os

CMD = "beeline -e \" {conf} %s \"".format(conf=conf)

sql = """
select
    t2.imei, alias_name as class_en, t1.feature
from (select feature, alias_name from dim_table where data_date=20200909 and type=0) t1
join imeis_table t2
on 1 = 1
"""
status = os.system(CMD % sql)
if status == 0:
    return status
else
    print("sql执行异常")

在数据量较少时，此种写法并没有什么问题，一旦数据达到一定量级，reduce将无法处理。

现在说下一以上写法存在的主要隐患，首先我们要了解MapReduce原理，知道join或left join是如何工作的。以上写法会造成MapReduce计算只有一个reduce处理数据，造成和数据倾斜一样的现象，reduce长时间执行，最终挂掉。原因reduce端repartition是按照key值进行hash取模，所以只分配一个reduce。（on 1=1与忽略不写等效或其他恒等关系）

最低0.47元/天解锁文章