hive任务reduce步骤卡在99%原因及解决

这篇具有很好参考价值的文章主要介绍了hive任务reduce步骤卡在99%原因及解决。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

   我们在写sql的时候经常发现读取数据不多,但是代码运行时间异常长的情况,这通常是发生了数据倾斜现象。数据倾斜现象本质上是因为数据中的key分布不均匀,大量的数据集中到了一台或者几台机器上计算,这些数据的计算速度远远低于平均计算速度,从而拉慢了整个计算过程速度。

本文将介绍如何通过日志分析,判断数据中的哪个key分布不均,从而导致了数据倾斜问题。

任务是否发生了倾斜

hive判断

hive任务到一半卡住了,hive,hadoop,大数据

hive运行日志

当我们在hive作业运行日志中,发现reduce任务长时间卡在99%时,即可判断任务发生了数据倾斜。

其原理是这样的:

hive任务到一半卡住了,hive,hadoop,大数据

分布式处理逻辑

分布式处理实际上是按数据中的key将数据分摊到多个机器上运行,假如出现了数据倾斜问题,如上图。可以想象,当1min过去后,我们的任务完成率只有67%,并且在接下来的9min时间内,任务完成率将持续卡在67%上。因此,当我们发现任务完成率长时间卡在99%时,即判断发生了数据倾斜。

spark判断

hive任务到一半卡住了,hive,hadoop,大数据

spark UI界面

我们进入spark UI界面,发现第2个job的运行时间长达1.8h,而其他job运行时间不超过2min,判断该job有可能发生数据倾斜。

hive任务到一半卡住了,hive,hadoop,大数据

进一步分析job,可以看到该job只存在一个stage(9)

hive任务到一半卡住了,hive,hadoop,大数据

stage界面

进一步分析stage,发现不管是duration还是shuffle的数据量,max和median都有明显的差距,可以肯定是job(5)的stage(9)发生倾斜。

hive输出也可以帮助排查

hive数据倾斜表象:Table 0 has 10000 rows for join key [0,0]
有hive任务发生数据倾斜,reduce端一直99%,有一个reduce任务卡主了。
打开这个reduce任务的log日志,发现如下日志:

[INFO] org.apache.hadoop.hive.ql.exec.JoinOperator: Table 0 has 10000 rows for join key [0,0]


打开hive源码定为输入日志行:

if (sz == nextSz) {
    LOG.info("Table {} has {} rows for join key {}", alias, sz, keyObject);
    nextSz = getNextSize(nextSz);
}


输出的类是org.apache.hadoop.hive.ql.exec.JoinOperator,是hive中join运算符的实现类,具体运行机制尚不清楚。
查询资料得知,当一个key关联了超过1000行时,会输出一条该警告日志,此后每1000会输出一条。所以这条日志的目的在于警告可能存在的Join数据倾斜的风险。
 

寻找倾斜key

当我们发现任务倾斜了,自然而然就希望找到倾斜的key,从而修复数据倾斜的现象。当然,这部分我也会分为hive和spark两个部分进行介绍。

hive识别

step1:确认是哪个Job出现了严重的倾斜问题

hive任务到一半卡住了,hive,hadoop,大数据

hive运行日志

通过搜索tracking的方式,我们发现第3个job的reduce任务一直卡在99%上,判断其发生了倾斜问题。

step2:进入相应的Tracking URL,查看SUCCESSFUL REDUCE

hive任务到一半卡住了,hive,hadoop,大数据

很明显,其他的taske都在2min之内完成,只有000000_1需要耗费1个多小时的时间完成。

另外注意,这里面需要排除一种特殊情况。有时候,某个task执行的节点可能有问题,导致任务跑的特别慢。这个时候,mapreduce的推测执行,会重启一个任务。如果新的任务在很短时间内能完成,通常则是由于task执行节点问题导致的个别task慢。如果推测执行后的task执行任务也特别慢,那更能说明该task可能会有倾斜问题。

step3:进入log日志,查看syslog

hive任务到一半卡住了,hive,hadoop,大数据

hive的syslog日志

可以从log日志中看到,该job仅仅运行了file和group操作后,就将数据写入至hive表中。那么,我们可以确认的是,该job运行的是最后一个group by操作。

step4:对照运行sql

hive任务到一半卡住了,hive,hadoop,大数据

运行sql

我们可以看到,在group by阶段,count(distinct)的出现造成了数据倾斜。

spark识别

step1:找到该任务运行的stage

hive任务到一半卡住了,hive,hadoop,大数据

spark UI界面

我们看到该运行任务,可以发现第2个job运行时间长达1.8h,远大于其他job,可以判定倾斜发生在job(5)。

step2:点击SQL,查看Details for Query

hive任务到一半卡住了,hive,hadoop,大数据

Details for Query

可以从sort time total/peak memory total/spill size total看出来,左表的package_name分布不均匀,此时可以通过查看scan parquet了解具体是哪张表。

step3:对照运行sql

hive任务到一半卡住了,hive,hadoop,大数据

运行sql代码

查询package_name的分布情况

select package_name,count(1) as cnt from test1 where date=20220619 group by package_name order by cnt desc limit 10;

hive任务到一半卡住了,hive,hadoop,大数据

package_name的分布验证了我们的猜想,test1.package_name造成了数据倾斜

过滤掉倾斜数据

当少量key重复次数特别多,如果这种key不是业务需要的key,可以直接过滤掉。

比如一张埋点日志表ods.page_event_log,

需要和订单表dw.order_info_fact做join关联。

在执行Hive的过程中发现任务卡在map 100%、reduce 99%,最后的1%一直运行不完。考虑应该是在join的过程中出现了数据倾斜,下面进行排查。

对于ods.page_event_log表查看出现次数最多的key:

select cookieid,
           count(*) as num
    from ods.page_event_log
   where data_date = "20190101"
group by cookieid
distribute by cookieid
sort by num desc limit 10

hive任务到一半卡住了,hive,hadoop,大数据

同样的,对另一张join表也做对应的排查

select cookieid,
    count(*) as num
from dw.order_info_fact
group by cookieid
distribute by cookieid
sort by num desc limit 10

hive任务到一半卡住了,hive,hadoop,大数据

从sql统计的结果可以看出,日志表和订单表通过cookieid进行join,当cookieid为0的时候,join操作将会产生142286×142286条数据,数量如此庞大的节点系统无法处理过来。同样当cookieid为NULL值和空值时也会出现这种情况,而且cookieid为这3个值时并没有实际的业务意义。因此在对两个表做关联时,排除掉这3个值以后,就可以很快计算出结果了,所以做好前期的数据清洗对一个大数据平台是至关重要的,生产无小事。

引入随机数

当我们用sql对数据group by时,MR会将相同的key拉取到同一个节点上进行聚合,如果某组的数据量很大时,会出现当前节点任务负载过重,从而导致数据倾斜。这时候可以考虑引入随机数,将原来的一个key值拆分成多组进行聚合。

比如现在需要统计用户的订单量,sql如下:

select t1.user_id,
       t2.order_num
    from (select user_id
          from dim.user_info_fact   # 用户维度表
       where data_date = "20190101"            
          and user_status_id=1
       ) t1 
  join ( select user_id,
            count(*) as order_num 
       from dw.dw_order_fact      # 订单表
       where site_id in (600, 900)
          and order_status_id in(1,2,3)
     group by user_id

        ) t2 
    on t1.user_id = t2.user_id

其中,用户维度表有2000w条数据,订单表有10亿条数据,任务在未优化前跑了一小时还没跑完,怀疑出现了数据倾斜。这里可以把key值加上一定的前缀转换成多个key,这样原本一个task上处理的key就会分发到其他多个task,然后去掉前缀再进行一次聚合得到最终结果。

hive任务到一半卡住了,hive,hadoop,大数据

优化后的sql如下: 这里把原来可能1个task执行的任务并行成了1000个随机数task做聚合,再把聚合的结果通过user_id做sum,在集群的整体性能不受影响的情况下,可以有效提高整体的计算速度。

select t1.user_id,
       t2.order_num
    from (select user_id
       from dim_user_info_fact
       where data_date = "20190101"                           
       ) t1 
  join (   select t.user_id,
            sum(t.order_num) as order_num
       from (select user_id,
                round(rand()*1000) as rnd,
                count(1) as order_num 
           from dw.order_info_fact
           where pay_status in (1,3)
           group by user_id,round(rand()*1000)
             ) t 
         group by t.user_id
    ) t2 
  on t1.user_id = t2.user_id

还有一种可能 

可能仅仅是因为你给的资源太少了 ,适当增加map和reduce的内存和个数,以及小文件合并之类的文章来源地址https://www.toymoban.com/news/detail-620837.html

到了这里,关于hive任务reduce步骤卡在99%原因及解决的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Hive数据倾斜的原因以及常用解决方案

    在Hadoop平台的hive数据库进行开发的时候,数据倾斜也是比较容易遇到的问题,这边文章对数据倾斜的定义以及产生的原因、对应的解决方案进行学习。 数据倾斜:数据分布不均匀,造成数据大量的集中到一点,造成数据热点。主要表现为任务进度长时间维持在 99%或者 100%的

    2024年02月15日
    浏览(49)
  • Spring的定时任务不生效、不触发,一些可能导致定时任务没有生效的原因,和具体的解决方法。Spring框架的定时任务不生效或者不触发的原因

    1. 未开启定时任务 : 原因 :未在Spring Boot应用主类上添加 @EnableScheduling 注解或未在XML配置文件中配置定时任务的启用。 解决方法 :确保在应用的配置类上添加 @EnableScheduling 注解,启用定时任务。 2. 定时任务方法的访问权限问题 : 原因 :定时任务的方法可能被设置为私有

    2024年02月03日
    浏览(55)
  • hive中map和reduce个数的是如何计算的

    可以直接通过参数mapred.map.tasks(默认值2)来设定mapper数的期望值,但它不一定会生效,下面会提到。 设输入文件的总大小为total_input_size。HDFS中,一个块的大小由参数dfs.block.size指定,默认值64MB或128MB。在默认情况下,mapper数就是: default_mapper_num = total_input_size / dfs.block.si

    2024年02月13日
    浏览(33)
  • PyTorch: 基于【MobileNet V2】处理MNIST数据集的图像分类任务【准确率99%+】

    PyTorch: 基于【VGG16】处理MNIST数据集的图像分类任务【准确率98.9%+】 在深度学习和计算机视觉的世界里,MNIST数据集就像一颗璀璨的明珠,被广大研究者们珍视并广泛使用。这个数据集包含了大量的手写数字图像,为图像分类任务提供了丰富的素材。今天,我们将带您一同探索

    2024年02月04日
    浏览(44)
  • FreeRTOS CubeMX卡在只运行第一个任务

    1. 在用CubeMX创建的FreeRTOS,任务中如果使用HAL_Delay(1000);这样会导致无法切换任务,所以只能使用    osDelay(500);来延时 osDelay 是FreeRTOS(Real-Time Operating System)中的一个函数,用于实现任务的延时。FreeRTOS是一个开源的实时操作系统,专门用于嵌入式系统。 osDelay 函数允许任务

    2024年02月05日
    浏览(29)
  • Hive 基于Tez引擎 map和reduce数的参数控制原理与调优经验

    主要对基于Tez的map数和reduce数测试与调优 如果需要查看基于MapReduce的调优可以看这篇: Hive 基于MapReduce引擎 map和reduce数的参数控制原理与调优经验 https://blog.csdn.net/qq_35260875/article/details/110181866?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22110181866%22%2C

    2024年02月04日
    浏览(32)
  • 【DolphinScheduler】datax读取hive分区表时,空分区、分区无数据任务报错问题解决

    最近在使用海豚调度DolphinScheduler的Datax组件时,遇到这么一个问题:之前给客户使用海豚做的离线数仓的分层搭建,一直都运行好好的,过了个元旦,这几天突然在数仓做任务时报错,具体报错信息如下: com.alibaba.datax.common.exception.DataXException: Code:[HdfsReader-08], Description:[您尝

    2024年01月16日
    浏览(67)
  • keycloak~登录步骤页login-actions/authenticate出现无限次302跳转的原因与解决

    keycloak通过k8s部署,并进行了集群部署,共2个节点 通过域名解析后,直接到外网LB,在LB上配置了k8s-ingress的IP,端口是80和443 在keycloak应用的ingress配置中,对域名进行了keycloak服务的绑定 有时间无法完成登录,点登录后,刷新了一次登录页,未完成登录行为 有时在登录时,出

    2024年02月05日
    浏览(40)
  • jenkins汉化一部分问题(一半中文一半英文)解决

    安装中文插件“Locale plugin”和“Localization: Chinese (Simplified)后,先设置为zh_US重新启动,再设置回来 其他插件重启Jenkins后,又出现了部分中文简体不翻译的情况。 方法如下,可以临时完美修复。 1. 将语言设定为zh_US,Jenkins切换为英文。 2. 调用restart重启Jenkins:http://jenkisn网址

    2024年02月11日
    浏览(61)
  • 常见Linux 命令,可以解决日常99%的问题

    1、基本命令 2、关机 3、文件和目录 4、文件搜索 5、挂载一个文件系统 6、磁盘空间 7、用户和群组 8、文件的权限 9、文件的特殊属性 使用 “+” 设置权限,使用 “-” 用于取消 10、打包和压缩文件 11、RPM 包 (Fedora, Redhat及类似系统) 12、YUM 软件包升级器 (Fedora, RedHat及类

    2024年01月22日
    浏览(42)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包