精华内容
下载资源
问答
  • Hive优化-大表join大表优化

    千次阅读 2020-08-10 15:13:33
    5、大表join大表优化  如果Hive优化实战2中mapjoin中小表dim_seller很呢?比如超过了1GB大小?这种就是大表join大表的问题。首先引入一个具体的问题场景,然后基于此介绍各自优化方案。  5.1、问题场景  ...

    原文链接:http://www.520mwx.com/view/5677

     

      5、大表join大表优化

          如果Hive优化实战2中mapjoin中小表dim_seller很大呢?比如超过了1GB大小?这种就是大表join大表的问题。首先引入一个具体的问题场景,然后基于此介绍各自优化方案。

       5.1、问题场景

          问题场景如下:

          A表为一个汇总表,汇总的是卖家买家最近N天交易汇总信息,即对于每个卖家最近N天,其每个买家共成交了多少单,总金额是多少,假设N取90天,汇总值仅取成交单数。

          A表的字段有:buyer_id、seller_id、pay_cnt_90day。

          B表为卖家基本信息表,其字段有seller_id、sale_level,其中sale_levels是卖家的一个分层评级信息,比如吧卖家分为6个级别:S0、S1、S2、S3、S4和S5。

          要获得的结果是每个买家在各个级别的卖家的成交比例信息,比如:

          某买家:S0:10%;S1:20%;S2:20%;S3:10%;S4:20%;S5:10%。

          正如mapjoin中的例子一样,第一反应是直接join两表并统计:

          select
             m.buyer_id,
            sum(pay_cnt_90day)  as pay_cnt_90day,
            sum(case when m.sale_level = 0  then pay_cnt_90day  end)  as pay_cnt_90day_s0,
            sum(case when m.sale_level = 1  then pay_cnt_90day  end)  as pay_cnt_90day_s1,
            sum(case when m.sale_level = 2  then pay_cnt_90day  end)  as pay_cnt_90day_s2,
            sum(case when m.sale_level = 3  then pay_cnt_90day  end)  as pay_cnt_90day_s3,
            sum(case when m.sale_level = 4  then pay_cnt_90day  end)  as pay_cnt_90day_s4,
            sum(case when m.sale_level = 5  then pay_cnt_90day  end)  as pay_cnt_90day_s5
          from (
            select  a.buer_id,  a.seller_id,  b.sale_level, a.pay_cnt_90day
            from (  select buyer_id,  seller_id,  pay_cnt_90day   from table_A)  a
            join
                   (select seller_id,  sale_level  from table_B)  b
            on  a.seller_id  = b.seller_id
            )  m
          group by m.buyer_id

          但是此SQL会引起数据倾斜,原因在于卖家的二八准则,某些卖家90天内会有几百万甚至上千万的买家,但是大部分的卖家90天内买家的数目并不多,join table_A和table_B的时候,

        ODPS会按照seller_id进行分发,table_A的大卖家引起了数据倾斜。

          但是数据本身无法用mapjoin table_B解决,因为卖家超过千万条,文件大小有几个GB,超过了1GB的限制。

       5.2、优化方案1:转为mapjoin

          一个很正常的想法是,尽管B表无法直接mapjoin, 但是是否可以间接mapjoin它呢?

          实际上此思路有两种途径:限制行和限制列。

          限制行的思路是不需要join B全表,而只需要join其在A表中存在的,对于本问题场景,就是过滤掉90天内没有成交的卖家。

          限制列的思路是只取需要的字段。

          加上如上的限制后,检查过滤后的B表是否满足了Hive  mapjoin的条件,如果能满足,那么添加过滤条件生成一个临时B表,然后mapjoin该表即可。采用此思路的语句如下:

          

          select
             m.buyer_id,
            sum(pay_cnt_90day)  as pay_cnt_90day,
            sum(case when m.sale_level = 0  then pay_cnt_90day  end)  as pay_cnt_90day_s0,
            sum(case when m.sale_level = 1  then pay_cnt_90day  end)  as pay_cnt_90day_s1,
            sum(case when m.sale_level = 2  then pay_cnt_90day  end)  as pay_cnt_90day_s2,
            sum(case when m.sale_level = 3  then pay_cnt_90day  end)  as pay_cnt_90day_s3,
            sum(case when m.sale_level = 4  then pay_cnt_90day  end)  as pay_cnt_90day_s4,
            sum(case when m.sale_level = 5  then pay_cnt_90day  end)  as pay_cnt_90day_s5
          from ( 
            select  /*+mapjoin(b)*/
              a.buer_id,  a.seller_id,  b.sale_level, a.pay_cnt_90day
            from (  select buyer_id,  seller_id,  pay_cnt_90day   from table_A)  a
            join
                   (
               select seller_id,  sale_level  from table_B b0
               join 
               (select seller_id from table_A group by seller_id) a0
                 on b0.seller_id = a0.selller_id
              )  b
            on  a.seller_id  = b.seller_id
            )  m
          group by m.buyer_id

          此方案在一些情况可以起作用,但是很多时候还是无法解决上述问题,因为大部分卖家尽管90天内买家不多,但还是有一些的,过滤后的B表仍然很多。

      5.3、优化方案2:join时用case when语句

          此种解决方案应用场景是:倾斜的值是明确的而且数量很少,比如null值引起的倾斜。其核心是将这些引起倾斜的值随机分发到Reduce,其主要核心逻辑在于join时对这些特殊值concat随机数,

        从而达到随机分发的目的。此方案的核心逻辑如下:

    select a.user_id, a.order_id, b.user_id
    from table_a a join table_b b
    on (case when a.user_is is null then concat('hive', rand()) else a.user_id end) = b.user_id

          Hive 已对此进行了优化,只需要设置参数skewinfo和skewjoin参数,不修改SQL代码,例如,由于table_B的值“0” 和“1”引起了倾斜,值需要做如下设置:

          set hive.optimize.skewinfo=table_B:(selleer_id) [ ( "0") ("1") ) ] 
          set hive.optimize.skewjoin = true;

          但是方案2因为无法解决本问题场景的倾斜问题,因为倾斜的卖家大量存在而且动态变化。

       

      5.4 、优化方案3:倍数B表,再取模join

         1、通用方案

          此方案的思路是建立一个numbers表,其值只有一列int 行,比如从1到10(具体值可根据倾斜程度确定),然后放大B表10倍,再取模join。代码如下:      

          select
             m.buyer_id,
            sum(pay_cnt_90day)  as pay_cnt_90day,
            sum(case when m.sale_level = 0  then pay_cnt_90day  end)  as pay_cnt_90day_s0,
            sum(case when m.sale_level = 1  then pay_cnt_90day  end)  as pay_cnt_90day_s1,
            sum(case when m.sale_level = 2  then pay_cnt_90day  end)  as pay_cnt_90day_s2,
            sum(case when m.sale_level = 3  then pay_cnt_90day  end)  as pay_cnt_90day_s3,
            sum(case when m.sale_level = 4  then pay_cnt_90day  end)  as pay_cnt_90day_s4,
            sum(case when m.sale_level = 5  then pay_cnt_90day  end)  as pay_cnt_90day_s5
          from (
            select  a.buer_id,  a.seller_id,  b.sale_level, a.pay_cnt_90day
            from (  select buyer_id,  seller_id,  pay_cnt_90day   from table_A)  a
            join
                   (
              select  /*+mapjoin(members)*/
                seller_id,  sale_level ,member
              from table_B
                join members
              )  b
            on  a.seller_id  = b.seller_id
              and mod(a.pay_cnt_90day,10)+1 = b.number 
            )  m
          group by m.buyer_id

             此思路的核心在于,既然按照seller_id分发会倾斜,那么再人工增加一列进行分发,这样之前倾斜的值的倾斜程度会减少到原来的1/10,可以通过配置numbers表改放大倍数来降低倾斜程度,

          但这样做的一个弊端是B表也会膨胀N倍。

        2、专用方案

            通用方案的思路把B表的每条数据都放大了相同的倍数,实际上这是不需要的,只需要把大卖家放大倍数即可:需要首先知道大卖家的名单,即先建立一个临时表动态存放每天最新的大卖家(

          比如dim_big_seller),同时此表的大卖家要膨胀预先设定的倍数(1000倍)。

            在A表和B表分别新建一个join列,其逻辑为:如果是大卖家,那么concat一个随机分配正整数(0到预定义的倍数之间,本例为0~1000);如果不是,保持不变。具体代码如下:

          

          select
             m.buyer_id,
            sum(pay_cnt_90day)  as pay_cnt_90day,
            sum(case when m.sale_level = 0  then pay_cnt_90day  end)  as pay_cnt_90day_s0,
            sum(case when m.sale_level = 1  then pay_cnt_90day  end)  as pay_cnt_90day_s1,
            sum(case when m.sale_level = 2  then pay_cnt_90day  end)  as pay_cnt_90day_s2,
            sum(case when m.sale_level = 3  then pay_cnt_90day  end)  as pay_cnt_90day_s3,
            sum(case when m.sale_level = 4  then pay_cnt_90day  end)  as pay_cnt_90day_s4,
            sum(case when m.sale_level = 5  then pay_cnt_90day  end)  as pay_cnt_90day_s5
          from (
            select  a.buer_id,  a.seller_id,  b.sale_level, a.pay_cnt_90day
            from (  
              select  /*+mapjoin(big)*/
                 buyer_id,  seller_id,  pay_cnt_90day,
                 if(big.seller_id is not null, concat(  table_A.seller_id,  'rnd',  cast(  rand() * 1000 as bigint ), table_A.seller_id)  as seller_id_joinkey
                  from table_A
                   left outer join
                 --big表seller_id有重复,请注意一定要group by 后再join,保证table_A的行数保持不变
                 (select seller_id  from dim_big_seller  group by seller_id)big
                 on table_A.seller_id = big.seller_id
            )  a
            join
                   (
              select  /*+mapjoin(big)*/
                seller_id,  sale_level ,
                --big表的seller_id_joinkey生成逻辑和上面的生成逻辑一样
                coalesce(seller_id_joinkey,table_B.seller_id) as seller_id_joinkey
              from table_B
                left out join
              --table_B表join大卖家表后大卖家行数扩大1000倍,其它卖家行数保持不变
              (select seller_id, seller_id_joinkey from dim_big_seller) big
              on table_B.seller_id= big.seller_id
              )  b
            on  a.seller_id_joinkey= b.seller_id_joinkey
              and mod(a.pay_cnt_90day,10)+1 = b.number 
            )  m
          group by m.buyer_id

          相比通用方案,专用方案的运行效率明细好了许多,因为只是将B表中大卖家的行数放大了1000倍,其它卖家的行数保持不变,但同时代码复杂了很多,而且必须首先建立大数据表。

       5.5 、方案4:动态一分为二

          实际上方案2和3都用了一分为二的思想,但是都不彻底,对于mapjoin不能解决的问题,终极解决方案是动态一分为二,即对倾斜的键值和不倾斜的键值分开处理,不倾斜的正常join即可,倾斜的把他们找出来做mapjoin,最后union all其结果即可。

          但是此种解决方案比较麻烦,代码复杂而且需要一个临时表存放倾斜的键值。代码如下:

          --由于数据倾斜,先找出90天买家超过10000的卖家

          insert overwrite table  temp_table_B
          select 
            m.seller_id,  n.sale_level
          from (
            select   seller_id
            from (
              select seller_id,count(buyer_id) as byr_cnt
              from table_A
              group by seller_id
              ) a
            where a.byr_cnt >10000
            ) m
          left join 
          (
           select seller_id, sale_level  from table_B
          ) n
            on m.seller_id = n.seller_id;
          --对于90天买家超过10000的卖家直接mapjoin,对其它卖家直接正常join即可。
          select
             m.buyer_id,
            sum(pay_cnt_90day)  as pay_cnt_90day,
            sum(case when m.sale_level = 0  then pay_cnt_90day  end)  as pay_cnt_90day_s0,
            sum(case when m.sale_level = 1  then pay_cnt_90day  end)  as pay_cnt_90day_s1,
            sum(case when m.sale_level = 2  then pay_cnt_90day  end)  as pay_cnt_90day_s2,
            sum(case when m.sale_level = 3  then pay_cnt_90day  end)  as pay_cnt_90day_s3,
            sum(case when m.sale_level = 4  then pay_cnt_90day  end)  as pay_cnt_90day_s4,
            sum(case when m.sale_level = 5  then pay_cnt_90day  end)  as pay_cnt_90day_s5
          from (
            select  a.buer_id,  a.seller_id,  b.sale_level, a.pay_cnt_90day
            from (  select buyer_id,  seller_id,  pay_cnt_90day   from table_A)  a
            join
                   (
              select seller_id,  a.sale_level 
               from table_A  a
               left join temp_table_B b
              on a.seller_id = b.seller_id
              where b.seller_id is not null
              )  b
            on  a.seller_id  = b.seller_id
           union all
           select  /*+mapjoin(b)*/
              a.buer_id,  a.seller_id,  b.sale_level, a.pay_cnt_90day
            from ( 
               select buyer_id,  seller_id,  pay_cnt_90day   
              from table_A
              )  a
            join
                   (
               select seller_id,  sale_level  from table_B 
              )  b
            on  a.seller_id  = b.seller_id
         )  m  group by m.buyer_id
         ) m
         group by m.buyer_id
    

        总结:方案1、2以及方案3中的同用方案不能保证解决大表join大表问题,因为它们都存在种种不同的限制和特定使用场景。

        而方案3的专用方案和方案4是推荐的优化方案,但是它们都需要新建一个临时表来存储每日动态变化的大卖家。相对方案4来说,方案3的专用方案不需要对代码框架进行修改,但是B表会被放大,所以一定要是是维度表,不然统计结果会是错误的。方案4最通用,自由度最高,但是对代码的更改也最大,甚至修改更难代码框架,可以作为终极方案使用。

     

     

    原文链接:http://www.520mwx.com/view/5677

    展开全文
  • [Hive]Hive数据倾斜(大表join大表)

    万次阅读 多人点赞 2015-05-12 10:23:36
    Hive数据倾斜(大表join大表)的现象、思路以及解决方案

    业务背景

    用户轨迹工程的性能瓶颈一直是etract_track_info,其中耗时大户主要在于trackinfo与pm_info进行左关联的环节,trackinfo与pm_info两张表均为GB级别,左关联代码块如下:

    from trackinfo a 
    left outer join pm_info b 
    on (a.ext_field7 = b.id) 

    使用以上代码块需要耗时1.5小时。

    优化流程

    第一次优化

    考虑到pm_info表的id是bigint类型,trackinfo表的ext_field7是string类型,其关联时数据类型不一致,默认的hash操作会按bigint型的id进行分配,这样会导致所有string类型的ext_field7集中到一个reduce里面,因此,改为如下:

    from trackinfo a 
    left outer join pm_info b 
    on (cast(a.ext_field7 as bigint) = b.id) 

    改动为上面代码后,效果仍然不理想,耗时为1.5小时。

    第二次优化

    考虑到trackinfo表的ext_field7字段缺失率很高(为空、字段长度为零、字段填充了非整数)情况,做进行左关联时空字段的关联操作实际上没有意义,因此,如果左表关联字段ext_field7为无效字段,则不需要关联,因此,改为如下:

    from trackinfo a 
    left outer join pm_info b 
    on (a.ext_field7 is not null 
    and length(a.ext_field7) > 0 
    and a.ext_field7 rlike '^[0-9]+$' 
    and a.ext_field7 = b.id)

    上面代码块的作用是,如果左表关联字段ext_field7为无效字段时(为空、字段长度为零、字段填充了非整数),不去关联右表,由于空字段左关联以后取到的右表字段仍然为null,所以不会影响结果。
    改动为上面代码后,效果仍然不理想,耗时为50分钟。

    第三次优化

    想了很久,第二次优化效果效果不理想的原因,其实是在左关联中,虽然设置了左表关联字段为空不去关联右表,但是这样做,左表中未关联的记录(ext_field7为空)将会全部聚集在一个reduce中进行处理,体现为reduce进度长时间处在99%。
    换一种思路,解决办法的突破点就在于如何把左表的未关联记录的key尽可能打散,因此可以这么做:若左表关联字段无效(为空、字段长度为零、字段填充了非整数),则在关联前将左表关联字段设置为一个随机数,再去关联右表,这么做的目的是即使是左表的未关联记录,它的key也分布得十分均匀

    from trackinfo a 
    left outer join pm_info b 
    on (
        case when (a.ext_field7 is not null 
            and length(a.ext_field7) > 0 
            and a.ext_field7 rlike '^[0-9]+$') 
        then 
            cast(a.ext_field7 as bigint) 
        else 
            cast(ceiling(rand() * -65535) as bigint) 
        end = b.id
    ) 

    第三次改动后,耗时从50分钟降为了1分钟32秒,效果显著!

    展开全文
  • spark-大表join优化方案

    万次阅读 2017-06-09 14:04:03
    1~2G左右的与3~4T的大表进行Join拆分 将任务数据分为多个结果RDD,将各个RDD的数据写入临时的hdfs目录,最后合并调整并行度和shuffle参数 spark-submit 参数#提高shuffle阶段的任务并行度,降低单个任务的内存...

    数据量:
    1~2G左右的表与3~4T的大表进行Join

    拆分
    将任务数据分为多个结果RDD,将各个RDD的数据写入临时的hdfs目录,最后合并

    取所需的字段和数据,并去重,减少data shuffle的规模

    调整并行度和shuffle参数

    spark-submit 参数

    #提高shuffle阶段的任务并行度,降低单个任务的内存占用
    --conf spark.default.parallelism=2000 
    #提高shuffle 缓冲区大小
    --conf spark.shuffle.file.buffer=128k 
    #增加堆外内存大小
    --conf spark.yarn.executor.memoryOverhead=1g

    增加资源

    这就不细说了,num-executors 不是越多越好 有边界

    优化数据倾斜

    检查数据是否是skewed data,即join出的key value pair大小极度不均,解决方案可以参考:
    https://zhuanlan.zhihu.com/p/21483985

    展开全文
  • hive大小表join优化性能

    万次阅读 2018-12-12 20:18:37
    摘要: MAPJOIN 当一个大表和一个或多个小JOIN时,最好使用MAPJOIN,性能比普通的JOIN要快很多。 另外,MAPJOIN 还能解决数据倾斜的问题。 MAPJOIN的基本原理是:在小数据量情况下,SQL会将用户指定的小全部...

    摘要: MAPJOIN 当一个大表和一个或多个小表做JOIN时,最好使用MAPJOIN,性能比普通的JOIN要快很多。 另外,MAPJOIN 还能解决数据倾斜的问题。 MAPJOIN的基本原理是:在小数据量情况下,SQL会将用户指定的小表全部加载到执行JOIN操作的程序的内存中,从而加快JOIN的执行速度。

    1、小、大表 join

    在小表和大表进行join时,将小表放在前边,效率会高。hive会将小表进行缓存。

    2、mapjoin

    使用mapjoin将小表放入内存,在map端和大表逐一匹配。从而省去reduce。

    样例:

    select /*+MAPJOIN(b)*/ a.a1,a.a2,b.b2 from tablea a JOIN tableb b ON a.a1=b.b1
    
    缓存多张小表:
    select /*+MAPJOIN(b,c)*/ a.a1,a.a2,b.b2 from tablea a JOIN tableb b ON a.a1=b.b1 JOIN tbalec c on a.a1=c.c1
    
    mapjoin的join发生在map阶段,join的join发生在reduce阶段,mapjoin可以提高效率

    使用

    方法一:

    在Hive0.11前,必须使用MAPJOIN来标记显示地启动该优化操作,由于其需要将小表加载进内存所以要注意小表的大小

    SELECT /*+ MAPJOIN(smalltable)*/  .key,value
    FROM smalltable JOIN bigtable ON smalltable.key = bigtable.key

    方法二

    在Hive0.11后,Hive默认启动该优化,也就是不在需要显示的使用MAPJOIN标记,其会在必要的时候触发该优化操作将普通JOIN转换成MapJoin,可以通过以下两个属性来设置该优化的触发时机

    hive.auto.convert.join

    默认值为true,自动开户MAPJOIN优化

    hive.mapjoin.smalltable.filesize

    默认值为2500000(25M),通过配置该属性来确定使用该优化的表的大小,如果表的大小小于此值就会被加载进内存中

     

    注意:使用默认启动该优化的方式如果出现默名奇妙的BUG(比如MAPJOIN并不起作用),就将以下两个属性置为fase手动使用MAPJOIN标记来启动该优化

    hive.auto.convert.join=false(关闭自动MAPJOIN转换操作)
    hive.ignore.mapjoin.hint=false(不忽略MAPJOIN标记)

     

    对于以下查询是不支持使用方法二(MAPJOIN标记)来启动该优化的

    select /*+MAPJOIN(smallTableTwo)*/ idOne, idTwo, value FROM
      ( select /*+MAPJOIN(smallTableOne)*/ idOne, idTwo, value FROM
        bigTable JOIN smallTableOne on (bigTable.idOne = smallTableOne.idOne)                                                  
      ) firstjoin                                                            
      JOIN                                                                 
      smallTableTwo ON (firstjoin.idTwo = smallTableTwo.idTwo)  

    但是,如果使用的是方法一即没有MAPJOIN标记则以上查询语句将会被作为两个MJ执行,进一步的,如果预先知道表大小是能够被加载进内存的,则可以通过以下属性来将两个MJ合并成一个MJ

    hive.auto.convert.join.noconditionaltask:Hive在基于输入文件大小的前提下将普通JOIN转换成MapJoin,并是否将多个MJ合并成一个
    hive.auto.convert.join.noconditionaltask.size:多个MJ合并成一个MJ时,其表的总的大小须小于该值,同时hive.auto.convert.join.noconditionaltask必须为true

    MAPJOIN

    当一个大表和一个或多个小表做JOIN时,最好使用MAPJOIN,性能比普通的JOIN要快很多。 另外,MAPJOIN 还能解决数据倾斜的问题。
    MAPJOIN的基本原理是:在小数据量情况下,SQL会将用户指定的小表全部加载到执行JOIN操作的程序的内存中,从而加快JOIN的执行速度。
    使用MAPJOIN时,需要注意:

    • LEFT OUTER JOIN的左表必须是大表;
    • RIGHT OUTER JOIN的右表必须是大表;
    • INNER JOIN左表或右表均可以作为大表;
    • FULL OUTER JOIN不能使用MAPJOIN;
    • MAPJOIN支持小表为子查询;
    • 使用MAPJOIN时需要引用小表或是子查询时,需要引用别名;
    • 在MAPJOIN中,可以使用不等值连接或者使用OR连接多个条件;
    • 目前ODPS在MAPJOIN中最多支持指定6张小表,否则报语法错误;
    • 如果使用MAPJOIN,则所有小表占用的内存总和不得超过512M(解压后的逻辑数据量)。

    MAPJOIN 判定逻辑:

    同时满足下面2个条件:
    1) Join阶段 max(join instance 运行时间) > 10分钟 && max( join instance 运行时间 ) > 2 * avg( join instance 运行时间 )
    2) 参与join 的最小表数据量小于100M (解压前的逻辑数据量)

    MAPJOIN 内存自定义设置:

    set odps.sql.mapjoin.memory.max=512
    设置mapjoin时小表的最大内存,默认512,单位M,[128,2048]之间调整

    举例

    这个例子比较综合,既涉及到了数据倾斜问题,又涉及到当“小表”不是很小时(>512M)如何利用mapjoin.
    场景:

      select * from log a
      left outer join users b
      on a.user_id = b.user_id;

    日志表(log)通常来说是记录数比较多的,但用户表(users)也不小,600W+ 的记录,把 users 分发到所有的 map 上也是个不小的开销,而且 map join 不支持这么大的小表。如果用普通的 join,又会碰到数据倾斜的问题。
    解决方法:

      select /*+mapjoin(b)*/
      * 
      from log a
      left outer join (
        select  /*+mapjoin(c)*/
        d.*
        from ( select distinct user_id from log ) c
        join users d
        on c.user_id = d.user_id
        ) b
      on a.user_id = b.user_id;

    这种解决方法的前提场景是:每日的会员uv不会太多,即 log 表中的 count(distinct user_id) 不会太大。

    展开全文
  • SparkSql MAPJOIN优化之小left join大表

    千次阅读 2020-09-03 11:16:52
    首先我们要了解MAPJOIN优化原理,这里简要说明下 Spark Broadcast hash join(Hive map join同理) 1,把小广播到所有大表分布的节点上,...sql场景小需要leftjoin大表150M左右 大表1T左右 原始sql(广播...
  • hive的大表join小表

    千次阅读 2018-08-03 15:24:51
    1、小、大表 join 在小大表进行join时,将小放在前边,效率会高。hive会将小进行缓存。 2、mapjoin 使用mapjoin将小放入内存,在map端和大表逐一匹配。从而省去reduce。 样例: select /*+MAPJOIN(b...
  • Hive大表JOIN优化

    千次阅读 2018-08-29 09:06:25
    用户轨迹工程的性能瓶颈一直是etract_track_info,其中耗时大户主要在于trackinfo与pm_info进行左关联的环节,trackinfo与pm_info两张均为GB级别,左关联代码块如下: [SQL] 纯文本查看 复制代码 fr...
  • Spark 大表之间的join

    千次阅读 2019-05-23 16:14:07
    最近在处理两份大表之间的join优化。 1 数据量是 8.1G 2 数据量是 24.1G spark.sql.shuffle.partitions 800 5个Executor,每个Executor 10G内存,每个Executor CPU的cores是 4 制定了3中优化措施。 1:...
  • 记得5年前遇到一个SQL,就是一个简单的两关联,SQL跑了差不多一天一夜,这两个都非常巨大,每个都有几十个G,数据量每个有20多亿,的字段也...遇到这种超级大表与超级大表怎么优化呢?这篇文章将告诉你答案。
  • 0.Hive中的优化分类 真正想要掌握Hive的优化,要熟悉相关的MapReduce,Yarn,hdfs底层源码,明晰Hive的底层执行流程。真正让你明白Hive调优系列,会征对下面分类逐一介绍。... 是否将common-join转换成...
  • hive join 优化 --小表join大

    万次阅读 2014-10-25 21:49:25
    1、小、大表 join 在小大表进行join时,将小放在前边,效率会高,hive会将小进行缓存。 2、mapjoin 使用mapjoin将小放入内存,在map端和大表逐一匹配,从而省去reduce。 例子: select /*+MAPJOIN(b)*/ a....
  • Spark中做两个hivejoin操作,先读取过来处理成两个数据量很的RDD,如果两个RDD直接进行join操作,势必会造成shuffle等导致运行非常缓慢,那么怎么优化呢?方法如下: 首先,对每个hive生成RDD进行优化...
  • 大表join小表之mapjoin详解

    千次阅读 2020-12-23 09:45:50
    在Hive调优里面,经常会问到一个很小的和一个大表进行join,如何优化。 Shuffle 阶段代价非常昂贵,因为它需要排序和合并。减少 Shuffle 和 Reduce 阶段的代价可以提高任务性能。 MapJoin通常用于一个很小的...
  • 基于Flink1.11.2 多表join与维表join

    千次阅读 2020-09-29 14:57:26
    离线业务是多个表join,因为接入的myslqbinlog的数据,所以数据存在修改跟删除,这个是跟日志分析最大的区别,因为日志分析啥的数据只有新增,相对来说考虑的东西就少了很多。 2,首先我们要实现的是多表join,这...
  • Hive中小大表关联(join)的性能分析

    万次阅读 多人点赞 2018-06-30 11:14:07
    经常看到一些Hive优化的建议中说当小大表做关联时,把小写在前面,这样可以使Hive的关联速度更快,提到的原因都是说因为小可以先放到内存中,然后大表的每条记录再去内存中检测,最终完成关联查询。...
  • 在大小表join的时候,即一个比较小的表和一个较的表joining,如果使用mapjoin的话,就可以极的节省时间,甚至达到只需要正常joining的一半时间。 使用mapjoin的话会把小表直接放到内存,然后在map段跟表进行...
  • 网上有种说法是:由于一般是采用小表join大表的方式(可以提高效率),所以有人说将小表放在左边,让它先执行,记住,这种说法是错误的!!!有例为证: 我们看上例: film inner join film_actor using(film_...
  • flink维表join的几种方式(1)

    千次阅读 2020-03-14 22:28:23
    表join的几种方式 一 将维表预加载到内存关联 实现方式: 定义一个类实现RichFlatMapFunction在open()方法中读取全部数据加载到内存中。 优缺点: 因为存在内存中,所以仅支持小数据量维表;因为open方法中读取,...
  • hive中大表join小表情况

    千次阅读 2019-02-15 18:55:33
    和join相关的优化主要分为mapjoin可以解决的优化(即大表join小表)和mapjoin无法解决的优化(即大表join大表),前者相对容易解决,后者较难,比较麻烦。  首先介绍大表join小表优化。以销售明细表为例来说明大表...
  • sql 描述:通过订单明细关联订单项和商品 ``` SELECT * from order_info left join order_item on order_info.id = order_item.order_num left join goods on goods.id = order_item.goodsId ...
  • hive小表与大表join提升运行效率

    千次阅读 2017-06-23 13:45:52
    大表 60w row 方案一: 在运行的时候发现会自动转为map join 本以为会很快,但是只起了一个map ,join 的计算量 : 单机计算6 亿次,结果一直map 0% 最后运行 1800s  方案二: 采用关闭map join : 但是依旧会很...
  • SELECT s.id,s.nick,s.userId,s.sid,s.session_key,s.retoke,s.shouquantime,s.refresh_token_timeout,s.timezone,t.endtime from taobao_session as s LEFT JOIN taobao_productrepost_set as t on t.memberId...
  • 在 Spark 的物理计划(physical plan)阶段,Spark 的 JoinSelection 类会根据 Join hints 策略、Join 的大小、 Join 是等值 Join(equi-join) 还是不等值(non-equi-joins)以及参与 Join 的 key 是否可以排序等...
  • phoenix 大表 顺序 join查询

    千次阅读 2018-11-10 17:36:04
    T_EXTENSION_ALL_DATAS_LOGIN 大表,200W+数据。 T_EXTENSION_ALL_DATAS_SHOW 小,几十条数据。   select T1.LOGIN_DATE,T1.COUNTRY,T1.IP,T1.BROWSER,T1.USER_NAME,T1.GENDER,T1.EMAIL,T2.TIME_SPEND,T2....
  • Hive MapJoin(小大表

    千次阅读 2019-04-04 14:49:13
    MapJoin是Hive的一种优化操作,其适用于小表JOIN大表的场景,由于表的JOIN操作是在Map端且在内存进行的,所以其并不需要启动Reduce任务也就不需要经过shuffle阶段,从而能在一定程度上节省资源提高JOIN效率 ...
  • join大表和小对查询性能的影响和索引类型的选择 示例数据库采用PostgreSQL 1.创建数据和相关函数 drop function if exists gen_random_gps(bigint); drop function if exists gps_save(bigint,bigint,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 497,565
精华内容 199,026
关键字:

大表join大表