技术面试
sql如何进行优化&sql的优化经历和数据去重排序
sql优化看运⾏环境,可以分为mysql和Hive,前者是数据库查询优化,后者基于MapReduce。
互联⽹分析师更多是基于Hive查询数据,所以下⽂针对Hive如何优化进⾏分析。
- 理解数据仓库的分层和数据粒度是⾸要的。因为相⽐于与数据库是为了数据的储存,更新⽽设计的,数据仓库则是更多为了数据的查询。针对具体的业务需求,选择合适的数据粒度,是sql优化的基础。例如选择⽤户粒度的Hive表,比起访问pv粒度的Hive表,数据量要⼩很多,sql查询也更快。
- 针对典型的问题,例如数据倾斜。
产⽣原因
- group by维度过小,某值的数量过多(后果:处理某值的reduce⾮常耗时) 2.去重 distinct count(distinct xx) 某特殊值过多(后果:处理此特殊值的reduce耗时) 3.连接 join,count(distinct),group by,join等操作,这些都会触发Shuffle动作,⼀旦触发,所有相同key的值就会拉到⼀个或⼏个节点上,就容易发⽣单点问题。
解决方案
- 业务逻辑:例如我们从业务上就知道在做group by时某些key对应数据量很⼤,我们可以单独对这些key做计算,再与其他key进行join
- Hive参数设置: 设置hive.map.aggr = true 在map中会做部分聚集操作,效率更高但需要更多的内存设置hive.groupby.skewindata=true 数据倾斜时负载均衡,当选项设定为true,⽣成的查询计划会有两个MRJob。第⼀个MRJob中,Map的输出结果集合会随机分布到Reduce中,每个Reduce做部分聚合操作,并输出结果,这样处理的结果是相同的GroupBy Key有可能被分发到不同的Reduce中,从⽽达到负载均衡的⽬的;第⼆个MRJob再根据预处理的数据结果按照GroupBy Key分布到Reduce中(这个过程可以保证相同的GroupBy Key被分布到同⼀个Reduce中),最后完成最终的聚合操作。
- 查询语句优化: 1.在count(distinct) 操作前先进⾏⼀次group by,把key先进⾏⼀次reduce,去重 2.map join:使⽤map join让⼩的维度表(1000 条以下的记录条数)先进内存,在map端完成reduce.
大表关联大表怎么优化?
接触到的数仓模型和架构
情境面试
举一个具体的例子,在工作中分析了什么问题,对公司有哪些影响和风险,你是怎么给出方案去改善去落地的?
解题思路
- (项目背景)在xx实习的时候,我们全量上线了一个短视频流的功能,但是全量上线后的数据表现没有达到预期,所以我们做了关于这个短视频流稿件的分析。
- (分析过程)我们分别从近一周被消费的短视频情况、高粉博主发布的视频消费情况以及消费情况好的视频的详情分析。
- (分析结论)结果发现虽然我们有好的视频但是好的视频并没有得到好的消费。
- (策略落地)所以我们去与运营团队沟通分析什么是符合我们app特色的视频,并与算法团队沟通推荐策略。
- (落地影响)在我们推进后一周,xx数据和xx数据得到了显著的提高。
架构面试
项目有多少人,人员分配
项目数据量有多大
项目用到了什么技术