• Spark性能调优案例-优化spark估计表大小失败 和 小表关联 走 broadcast join


    背景

    A任务中关联一张表,该表经过过滤和去重,数据量小于10MB,实际任务耗时较长。
    B任务关联一张小表,实际任务耗时较长

    排查思路

    A任务排查

    查看spark UIsql界面:
    问题1:发现并没有走广播join
    观察此处join,对于76条数据的表,估计的大小超过10M,实际76条数据大小小于spark.sql.autoBroadcastJoinThreshold的值,导致这个问题的原因在对于broadcast join的官方介绍中提到,

    参数名默认值说明
    spark.sql.autoBroadcastJoinThreshold10485760 (10 MB)Configures the maximum size in bytes for a table that will be broadcast to all worker nodes when performing a join. By setting this value to -1 broadcasting can be disabled. Note that currently statistics are only supported for Hive Metastore tables where the command ANALYZE TABLE COMPUTE STATISTICS noscan has been run.

    由于脚本中存在中间的计算,导致不能正确的估算表的大小,

    B任务排查

    由于是关联小表,预期会走广播join,于是查看spark UIsql界面:
    问题2:发现并没有走广播join
    由于小表是直接读取,大小为15M,超过了广播join默认大小10M,所以没有走广播join

    解决方法

    问题1:先将select查到的数据生成为中间临时表,再去join起来,可以正常估算表的大小
    问题2:

    // 调大广播变量为50M, 使原本join变成走广播变量方式
    spark.sql.autoBroadcastJoinThreshold = 52428800
    
    • 1
    • 2

    优化后效果

    都走了广播join, 任务耗时减少

  • 相关阅读:
    关于我博客付费专栏:写给粉丝的致歉信
    ApiPost7使用介绍 | HTTP && Websocket
    C++:类与对象完结篇
    Java和JavaScript是一样的技术吗?
    趣学算法:贪心算法
    我的Windows10下的WSL的使用经历
    使用Python实现对word的批量操作
    工厂管理软件中的计划排产是什么
    4-7:用Redis优化登陆模块
    解决shardingsphere SQLFeatureNotSupportedException: isValid
  • 原文地址:https://blog.csdn.net/u014034497/article/details/127821811