一.前言 公司实用Hadoop构建数据仓库,期间不可避免的实用HiveSql,在Etl过程中,速度成了避无可避的问题.本人有过几个数据表关联跑1个小时的经历,你可能觉得无所谓,可是多次Etl就要多个小时,非常浪费时间,所以HiveSql优化不可避免. 注:本文只是从sql层面介绍一下日常需要注意的点,不涉及Hadoop.MapReduce等层面,关于Hive的编译过程,请参考文章:http://tech.meituan.com/hive-sql-to-mapreduce.html 二.准备数据…

前言: 最近发现hivesql的执行速度特别慢,前面我们已经说明了left和union的优化,下面咱们分析一下增加或者减少reduce的数量来提升hsql的速度. 参考:http://www.cnblogs.com/liqiu/p/4873238.html 分析: and o.create_time = '2015-10-10'; 上一篇博文已经说明了,需要8个map,1个reduce,执行的速度:52秒.详细记录参考:http://www.cnblogs.com/liqiu/p/4873238…

相信在Etl的过程中不可避免的实用union all来拼装数据,那么这就涉及到是否并行处理的问题了. 在hive中是否适用并行map,可以通过参数来设定: set hive.exec.parallel=true; 那么还是实用上一篇博客的数据,链接:http://www.cnblogs.com/liqiu/p/4873238.html 如果咱们需要一些数据: union all ) a; 就是模拟分别从两个表里面获取数据,如果不开启并行,实用的时间是开启时间的两倍,所以这个地方多加注意!…

目录 综述 1.严格模式 1.1 参数设置 1.2 查看参数 1.3 严格模式限制内容及对应参数设置 2.实际操作 2.1 分区表查询时必须指定分区 2.2 order by必须指定limit 2.3 限制笛卡尔积 3.搭配使用 3.1 参数 3.2 搭配使用案例 综述 在同样的集群运行环境中,hive调优有两种方式,即参数调优和sql调优. 本篇讲涉及到的Hive严格模式. 前两天在优化一个前人遗留下的sql,发现关于严格模式参数是这样使用的,严重错误. set hive.strict.che…

背景 在刚使用hive的过程中,碰到过很多问题,任务经常需要运行7,8个小时甚至更久,在此记录一下这个过程中,我的一些收获 join长尾 背景 SQL在Join执行阶段会将Join Key相同的数据分发到同一个执行Instance上处理.如果某个Key上的数据量比较多,会导致该Instance执行时间比其他Instance执行时间长.其表现为:执行日志中该Join Task的大部分Instance都已执行完成,但少数几个Instance一直处于执行中,这种现象称之为长尾 长尾类别&优化方法 小表…

如在上篇文章<ETL调优的一些分享(上)>中已介绍的,ETL是构建数据仓库的必经一环,它的执行性能对于数据仓库构建性能有重要意义,因此对它进行有效的调优将十分重要.ETL业务的调优可以从若干思路开展,上文我们已经介绍了其中三点,本文我们将再分享如下几点建议. 减少不必要的事务表的使用 减少事务性操作的窗口时间 从最影响总体性能的case开始分析 步骤迭代,直至最优 减少不必要的事务表的使用 由于ORC事务表读取和操作较慢,为确保执行效率,对于业务中不涉及事务操作的表,建议使用普通ORC表,而非…

ETL是构建数据仓库的重要一环.通过该过程用户将所需数据提取出来,并按照已定义的模型导入数据仓库.由于ETL是建立数据仓库的必经过程,它的效率将影响整个数据仓库的构建,因此它的有效调优具有很高的重要性.在实际应用中我们通常建议把ETL业务的调优分为若干思路,从而保证调优充分有序进行,避免遗漏,最大化提升ETL的执行效率. 我们将分上下两篇文章介绍ETL业务的调优手段.本文将首先介绍以下三个:检查资源是否有效配置:收集数据特征,确定分区分桶:以及Task运行情况收集和监控.并对每个步骤中的调优原则…

  DBA发来一个线上慢查询问题. SQL例如以下(为突出重点省略部分内容): select distinct article0_.id, 等字段 from article_table article0_, hits_table articlehit1_ where article0_.id=articlehit1_.id order by hits; EXPLAIN结果:耗时4.03S 出乎意料. 居然会有Using temporary, order by仅仅用到了一张表. 正常情况下不会出现…

[使用场景] 两个RDD进行join的时候,如果数据量都比较大,那么此时可以sample看下两个RDD中的key分布情况.如果出现数据倾斜,是因为其中某一个RDD中的少数几个key的数据量过大,而另一个RDD中的所有key都分布比较均匀,此时可以考虑采用本解决方案. [解决方案] 对有数据倾斜那个RDD,使用sample算子采样出一份样本,统计下每个key的数量,看看导致数据倾斜数据量最大的是哪几个key. 然后将这几个key对应的数据从原来的RDD中拆分出来,形成一个单独的RDD,并给每个ke…

[使用场景] 对RDD使用join类操作,或者是在Spark SQL中使用join语句时,而且join操作中的一个RDD或表的数据量比较小(例如几百MB或者1~2GB),比较适用此方案. [解决方案] 小表join大表转为小表broadcast+map大表实现.具体为: 普通的join是会shuffle的,而一旦shuffle,就相当于会将相同key的数据拉取到一个shuffle read task中再进行join,此时就是reduce join,此时如果发生数据倾斜,影响处理性能,而此时恰好一…