语兴

12-10 01:45 网易_数据开发工程师

发布于上海

关注

Spark Web UI及任务优化实战-Spark Web Ui 实际应用

问题定位流程

常见案例

案例一：执行失败OOM

现象：任务执行失败
UI排查：点击失败的job

点击job id 查看失败的stage

点击失败的stage查看失败原因

报错

 ExecutorLostFailure (executor 1497 exited caused by one of the running tasks) 
 Reason: (Exit reason: JVM exception - Java heap space OOM, 
 Suggestion: Increase spark.executor.memory)

解决办法：

查看当前运行的参数：

1.参数优化-加参数、加分区数等等
set spark.executor.memory = 25 g;
2.代码优化：减少输入数据量，是否有大字段。

案例二：执行失败-数据文件损坏

现象：任务执行失败
UI排查：

报错：

One possible cause: Parquet column cannot be converted in the corresponding files.
Another possible cause: File is corrupted or there are corrupt replicas in hdfs.
The potential damaged file is hdfs: hdfs//xxxx
The rootCause of exception is NegativeArraySizeException: -1951179625.

解决办法：

Parquet文件读取失败。根因:数据中数组字段长度超限导致读取失败，数组size太大
   a): 如果允许数据少量丢失(跳过超限的数据)，添加参数:
    set spark.sql.files.ignoreCorruptFiles=true; --跳过文件的开关
    set spark.sql.files.ignoreCorruptFiles.maxAllowedCorruptSizePercentage=0.01; --容忍度(最大 1)
    set spark.blacklist.enabled=true; --黑名单开关(预防坏节点)
    set spark.hadoop.hdfs.client.read.retry.count=20; --hdfs客户端读文件重试次数
 b): 只能通过自行优化逻辑的手段，过滤掉数组超限的数据
    排查sql字段的 json array字段，必要保留。可按需保留

案例三：执行时间长-资源不足-未申请到资源

现象：平时20min执行的任务，突然执行了1个多小时
UI排查：点击duration倒排，找到时长最长的job => job id 0

点击job id 0 查看stage详情

发现整个job id0 只有一个stage，执行时间并不长

点击 stage 0 详情，查看task最早启动时间

Stage0 在 07:02提交，但是第一个task在08:08启动，未申请到资源

点击AM日志，查看任务启动

-- 开始启动
24/11/20 07:00:52.686 main INFO ApplicationMaster: Started progress reporter thread with (heartbeat : 7500, initial allocation : 200) intervals
2024-11-20 07:00:52.000
24/11/20 07:00:52.545 main INFO YarnAllocator: Yarn scheduler type is FAIR_SCHEDULER

--申请资源
24/11/20 08:07:21.331 task-starvation-timer WARN YarnClusterScheduler: Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient resources

通过AM日志，可以很清晰的看到在08:08之前一直没有申请资源

解决办法

1.提升任务优先级
2.迁移资源充足的集群或队列

案例四：执行时间长-数据量大-未倾斜

现象：任务执行时间长，3-5h执行完成
UI排查：寻找最长的job对应stage

job1 和 job2 执行约3.4h

查看 job1的stage

数据量大：输入了160T，150亿数据
task执行情况较为均匀，非倾斜引起的执行慢
解决办法

1.参数优化：资源允许的条件下，增加资源
  set spark.dynamicAllocation.minExecutors=100;
  set spark.dynamicAllocation.maxExecutors=1500;
  set spark.executor.memory=20G;
  set spark.executor.cores=4;
  set spark.sql.shuffle.partitions =12000;
  set spark.default.parallelism = 12000;
2.代码逻辑优化：减少输入的数据量、全量改增量、剔除大字段

案例五：执行时间长-数据量大-数据倾斜

查看最长耗时的stage

查看stage的task执行情况

max的task 是median各指标的数倍，很明显的数据倾斜

继续定位倾斜发生在代码的位置

倾斜的stage发生在 Stage 712，去ui的sql模块搜索关键字 “stage 712”

如果对代码较为熟悉，可以通过关键字搜索任务的代码，这里关键字key 是order_id

如果对代码不熟悉，或者关键字出现多次，可以用DAG向上找 scan的表

用关键字定位任务代码：

搜索订单表，找到对应发生倾斜代码

select  t1.order_id,
        t1.order_number,
        t1.sku_id,
        t1.privilege_id,
        t2.privilege_name,
        t2.privilege_type
from    (
            select  order_id,
                    order_number,
                    sku_id,
                    user_id
            from    y_life.dws_order_sku_df
            where   date='${date}'
        ) t1
left join
        (--订单权益表
            select  
                    order_id,
                    privilege_id,
                    privilege_name，
                    privilege_type
            from    y_life.dws_order_privilege__df
        ) t2
on      t1.order_id=t2.order_id

确定key的分布

select  order_id,
        count(*) as cnt
from     y_life.dws_order_sku_df
where   date='${date-1}'
group by
        order_id
order by
        cnt desc;