如何支撑区块链技术发展的
|
路核心在于：既然按照seller_id分发会倾斜，那么再人工增加一列进行分发，这样之前倾斜的值的倾斜程度会减少为原来的1/10。可以通过配置numbers表修改放大倍数来降低倾斜程度，但弊端就是B表会膨胀N倍。 专有方案 通用方案思路是把B表的每条数据都放大了相同的倍数，实际上只需要把大卖家放大倍数即可。 首先需要知道大卖家的名单，即先建立一个临时表动态存放每日最新的大卖家(比如dim_big_seller)，同时此表的大卖家要膨胀预先设定的倍数(比如1000倍)。
在A表和 B表中分别新建一个 join 列，其逻辑为：如果是大卖家，那么 concat 一个随 机分配正整数(0到预定义的倍数之间，本例为0~1000 );如果不是，保持不变。 此方案在一些情况下可以起作用，但很多时候还是无法解决上述问题，因为大部分卖家尽管 90 买家不多 ，但还是有一些的，过滤后的 B 表仍然很大。 方案 2：join 时用 case when 语句 应用场景为: 倾斜的值是明确的而且数量很少，比如null值引起的倾斜。
将这些引起倾斜的值随机分发到Reduce，其主要核心逻辑在于 join 时对这些特殊值concat 随机数,从而达到随机分发的目的。核心逻辑如下： 但是此 SQL 会引起数据倾斜，原因在于卖家的二八准则。某些卖家 90 天内会有几百万甚至上千万的买家，但是大部分卖家 90 天内的买家数目并不多， join table_A 和table_B 的时候 ODPS 会按照 Seller_id 进行分发， table_A 的大卖家引起了数据倾斜。 「但是本数据倾斜问题无法用 mapjoin table_B 解决，因为卖家有超过千万条、文件大小几个GB ，超过了 mapjoin 表最大 1GB 的限制。」 方案 1：转化为 mapjoin 大表无法直接mapjoin，那么是否可以间接呢?实际上此思路有两种途径：限制行和限制列。
mapjoin 优化是在 Map 阶段进行 join ，而不是像通常那样在 Reduce 阶段按照 join 列进行分发后在每个 Reduce 任务节点上进行 join ，不需要分发也就没有倾斜的问题，相反 Hive 会将小表全量复制到每个 Map 任务节点(对于本例是 dim_seller ，当然仅全量复制 b表 sql 指定的列)，然后每个 Map 任务节点执行 lookup 小表即可。 「从上述分析可以看出，小表不能太大，否则全量复制分发得不偿失。」
五、大表 Join 大表优化如果上述 mapjoin 中小表 dim_seller 很大呢?比如超过了 1GB 的大小?这种就是大表join 大表的问题 。 这类问题相对比较复杂，我们首先引入具体的问题场景，然后基于此介绍各种优化方案。 问题场景 我们先假设一个问题场景：
要获得的结果是每个买家在各个级别卖家的成交比例信息，比如：
正如 mapjoin 中的例子一样，我们的第一反应是直接 join 表并统计：  （编辑：淮南站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
