回答思路

sql优化看运⾏环境，可以分为mysql和Hive，前者是数据库查询优化，后者基于MapReduce。互联⽹分析师更多是基于Hive查询数据，所以下⽂针对Hive如何优化进⾏分析。 (1) 理解数据仓库的分层和数据粒度是⾸要的。因为相⽐于与数据库是为了数据的储存，更新⽽设计的，数据仓库则是更多为了数据的查询。针对具体的业务需求，选择合适的数据粒度，是sql优化的基础。例如选择⽤户粒度的Hive表，比起访问pv粒度的Hive表，数据量要⼩很多，sql查询也更快。 (2) 针对典型的问题，例如数据倾斜。 产⽣原因 1.group by维度过小,某值的数量过多(后果:处理某值的reduce⾮常耗时) 2.去重 distinct count(distinct xx) 某特殊值过多(后果：处理此特殊值的reduce耗时) 3.连接 join,count(distinct),group by,join等操作，这些都会触发Shuffle动作，⼀旦触发，所有相同key的值就会拉到⼀个或⼏个节点上，就容易发⽣单点问题。 (2)解决方案 1.业务逻辑:例如我们从业务上就知道在做group by时某些key对应数据量很⼤,我们可以单独对这些key做计算,再与其他key进行join 2.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中），最后完成最终的聚合操作。 (3)查询语句优化: 1.在count(distinct) 操作前先进⾏⼀次group by,把key先进⾏⼀次reduce,去重 2.map join:使⽤map join让⼩的维度表（1000 条以下的记录条数）先进内存,在map端完成reduce.