之前我记得有一个sql 修改成了shuffle join ，还是报错hash join 没有报相关内存的问题
select n_name, sum(l_extendedprice * (1 - l_discount)) as revenue
from customer, orders, lineitem, supplier, nation, region
where
c_custkey = o_custkey
and l_orderkey = o_orderkey
and l_suppkey = s_suppkey
and c_nationkey = s_nationkey
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'ASIA'
and o_orderdate >= date '1994-01-01'
and o_orderdate < date '1994-01-01' + interval '1' year
group by n_name
order by revenue desc;
``` hash join 的问题 sql 是不是拆分成两个就会好- Shuffle Join：将左右表的数据根据哈希计算分散到集群的节点之中
那我增加两个节点是不是就会解决，这样数据会更加分散
增加节点，可以提高性能，不一定能解决那个问题。
优化器是走了Shuffle Hash Join，在进行 Join 之 前，还会对小表的分区构建 Hash Map，由于小表orders也有150亿了，并不是所谓的“小表”，所以出现那个报错了。
如果增加节点 BUCKETS也调整一下吧 大表都设置为BE节点*CPU核数吧。
select n_name, sum(l_extendedprice * (1 - l_discount)) as revenue
from customer, orders, lineitem, supplier, nation, region
where
c_custkey = o_custkey
and l_orderkey = o_orderkey
and l_suppkey = s_suppkey
and c_nationkey = s_nationkey
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = ‘ASIA’
and o_orderdate >= date ‘1994-01-01’
and o_orderdate < date ‘1994-01-01’ + interval ‘1’ year
group by n_name
order by revenue desc;
这个sql 建议怎么优化一下好呢
SQL都很简单，只能将时间减少至1个月来查询，查询12次，生成中间表算一年结果。
或者用colocate join，通常订单倾斜不会很严重，数据分布影响不大的。
现在我们不是以月来生成分区吗？按照天来生成分区的话，是不是性能会更好呢
如果是你查询一天，那么按天来分区是会好。如果是你按一个月来查询，那么按天分区就更慢，按月分区好。
目前看来 关于hash join 这个问题没有更好的解决办法
select l_orderkey , count(*) from lineitem group by l_orderkey order by desc 2 limit 50;
看看数据是不是倾斜很严重
目前在重新导入数据，我们中午的时候从新建表了，这个重新建表的话，有没有办法保留数据呢
您那个情况 变动较大 需要重新导入 新数据覆盖通常会有以下的方法
因为10T的数据 如果我们导入数据的话，测试时间上会花费很多
不好意思，针对这个情况，暂时没有快速的方法。
可以通过调整参数来提升导入效率吗
请问你是如何导入？
