数仓面试求教

1. HashPartitioner 是默认的分区器，也可以用别的， 比如TotalOrderPartitioner， 也可以自定义开发。  第一个问题， 先回答为什么要分区  就是数据shuffle过程中的一种打散策略。   Hash散列化是最容易想到的。   2. 在MR当中会用到多次排序过程  特别是map输出到内存再溢写到磁盘时会产生大量的临时文件，这些小文件是不能直接交给Reducer处理的，而要进行一个合并的过程， 这个过程是带着map-key进行操作的 所以要用到归并排序。   在环形缓冲的内存区 使用快排， 原因我还没想到。  （https://blog.csdn.net/u010737756/article/details/114198358 ） 3.  先定义和回顾数据倾斜的概念， 然后再思考join这个过程的实现  （reduce把相同key分组做笛卡尔积）  如果大表小表的差异巨大， 表现为小表的数据量比较少但key却比较集中，导致分发到某一个或几个reduce上的数据比其他reduce多很多，易造成数据倾斜。  常常会采用mapjoin  优化这类问题

1为了散列化分区（猜的） 2map端排序没有顺序所以是快排，之后分区合并后分区有顺序了所以归并 3小表在前大表在后

  1.mapreduce中为何要hash partition分区 默认是hash分区 为了打散数据 分布式处理  分区方式可以自己定义 实现分区器自定义实现； public class CustomPartitioner extends Partitioner<Text，Object>{ @Override  public int getPartition(Text key，Object value，int numPartitions){ //控制分区代码逻辑  返回int即可 return partition； } }   2.mapreduce中为何使用快拍和归并排序 快排：因为内存中排序比较快    数据在内存中是按照 entry1(k1v1),entry(k2v2),entry(k3v3) 这种方式排列的, kv组成一个entry 快排效率高 归并：对多个有序的小文件进行排序，不能单靠内存排，得借助磁盘 比如三个小文件分别是 1，4，6，8 1，5，8，8 0，3，7，11 同时打开所有小文件 分别使用迭代器取出第一个数 即1，1，0  此时0最小 将0追加写入新文件 并从三号文件通过迭代器拿出下一个数3 此事1最小 将1追加写入新文件 并从一号文件通过迭代器拿出下一个数4 直到所有文件都被迭代完 总的排序也就完成了 感觉会问你哪里用到排序了    1.map端的环形缓冲区用到快排    2.map端的小文件合并用到归并排序   3.reduce端将从map端拉取的文件进行归并排序 #数仓开发#

2 一般来说小表join大表就把小表broadcast 出去，即mapjoin 。但是你这里说维表也挺大，可能需要走shuffle hash join. Join 过程中过滤好null 和空串的情况，如果还是会倾斜就需要具体分析. 倾斜不大就不用管了嘛，倾斜太大可以考虑对于这部分单独处理，使用加盐等策略

3. 事实表关联维表 一般是大小表join 即事实表大维表小 或者 维表大 事实表属于增量数据 比较小 楼主说的情况 事实表很大 维表也很大 大数据处理其实不怕数据量大 而怕分布不均匀  数据倾斜是说事实表中数据有集中分布 情况1：   数据其实比较均匀 但经过hash后 某个分区数据就很多 可以尝试下调整分区数可能有效 虽然大多情况下没用 情况2：   事实表存在长尾效应 头部严重集中 比如淘宝的全体店铺的销售流水表 关联 店铺维表 头部店铺的销量一定是非常大的    对于这种的 可以分开处理   select     t1.*,t2.*   from    (     select * from fact_table where id in (1,2,3) -- 这三家店铺是头部单独处理    )t1    left join     (     select * from dim_table where id in (1,2,3) -- 此时维表就很小了 可以用mapjoin    )t2 on t1.id = t2.id   union all   select     t1.*,t2.*   from    (     select * from fact_table where id not in (1,2,3)    )t1    left join     (     select * from dim_table where id not in (1,2,3)   )t2 on t1.id = t2.id; 情况3:   数据量相当大 且不止是头部 头身都很大 只有少数数据比较少  想象的场景是物联网中 某个机具当天的心跳信息 关联 机具的基础信息 几乎每个机具的心跳信息都有上千万条  1.维表能不能先过滤 可能维表1kw条 但关联用到的只有100w 转为大小表join    select * from dim_table  where id in (select id from fact_table group by id)  2.如果两个表都很大 那不是数据倾斜 而是数据堆积 每个任务处理时间都很长     这种的不要以天级别做join 而是小时级别 每一个小时做一次 到时候如果再数据倾斜再考虑上面的方法  #数仓开发#