数仓面试求教

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端拉取的文件进行归并排序 #数仓开发#

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 而是小时级别 每一个小时做一次 到时候如果再数据倾斜再考虑上面的方法  #数仓开发#

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