全部， 我试图找出最有效的方式将数据存储到Hive表中，从而使查询引擎能够充分利用Bloom筛选器和存储索引。该表中有数十亿行，并且已被分区为目前为止最好的
我有一个Hive ORC表，该表带有在高级结构以下的customer_id字段上定义的Bloom过滤器
表名交易 领域 客户ID 。 。 。 180列以上
按业务部门划分
为了充分利用布隆过滤器和ORC存储索引 我希望将表中的数据存储在文件中，其中每个文件仅包含特定的递增的customer_id集，而这些记录均由customer_id排序
还有一个具有相同结构但没有任何分区或排序的登台表，可以用作加载此表的源。
我已经找到了解决问题的方法，但是数据偏斜使我的查询无法正常运行。可以说我想将我的ID分成127个桶
这是我的伪查询
-- getting the range of id's which i will use later to create a bucket for each id
with customer_id_range as (
select max(customer_id) - min(customer_id) as range_customer_id,
business_unit
from transactions_staging
group by business_unit
)
select t.* from transactions t
inner join customer_id_range cr on t.business_unit = cr.business_unit
distribute by floor(t.customer_id / ( cr.range_customer_id / 127))
sort by customer_id
这最终将我的数据分配到127个reducer中，以将输出存储到127个文件中，每个文件将具有一组不重叠的客户ID，并在每个文件中进行排序。这样，如果查询带有客户ID或出于联接目的，则可以充分利用ORC存储索引和Bloom过滤器
我想很好，但是此表中基于customer_id的数据有很大的倾斜。因此，查询在完成之前会在几个减速器上停留数小时。它会将大量行分配到这些约简器中，因为该表具有特定范围的customer_id的行数不成比例
还有其他方法可以实现我想要实现的目标吗？如何才能更有效地处理数据偏斜？