网站建设目标与期望,品牌公司设计,照明网站模板,网站右侧信息跟随左侧菜单栏变化Spark读取JDBC调优#xff0c;如何调参一、场景构建二、参数设置1.灵活运用分区列实际问题#xff1a;工作中需要读取一个存放了三四年历史数据的pg数仓表#xff08;缺少主键id#xff09;#xff0c;需要将数据同步到阿里云
MC中#xff0c;Spark在使用JDBC读取关系型数…
Spark读取JDBC调优如何调参一、场景构建二、参数设置1.灵活运用分区列实际问题工作中需要读取一个存放了三四年历史数据的pg数仓表缺少主键id需要将数据同步到阿里云
MC中Spark在使用JDBC读取关系型数据库时默认只开启一个task去执行性能低下因此需要通过设置一些参数来提高并发度。一定要充分理解参数的含义否则可能会因为配置不当导致数据倾斜翻看了网络上好多相关介绍都沾边。下边总结一下
您是菜鸟就好好学习您是大佬欢迎提出修改意见
一、场景构建
以100行数据为例实际307983条
创建表
CREATE TABLE IF NOT EXISTS test(good_id STRING ,title STRING ,sellcount BIGINT,salesamount Double
)COMMENT 测试表
PARTITIONED BY (dt STRING COMMENT 分区字段
);插入数据
insert into test partition (dt 202001)
values (1001,卫衣,1,100.1),(1002,卫裤,2,101.2),(1003,拖鞋,3,10.3)...,(1100,帽子,100,19.23)二、参数设置
配置文件示例
jdbc: jdbcoptions.url: jdbc:postgresql://xxx.xxx.xxx.xxx:8000/postgresoptions.user: xxxxxxoptions.password: xxxxxxoptions.driver: org.postgresql.Driverinput:- moduleClass: JDBC: *jdbcoptions.dbtable: SELECT *,cast(good_id as bigint)*1%6 mo FROM test.test where dt 202001options.fetchsize: 100options.partitionColumn: mo # 分区列一般为自增id下边解释下为啥用mooptions.numPartitions: 6 #分区数options.lowerBound: 0options.mytime: ${yyyy}-${MM}-${dd}options.upperBound: 6 # 该值设置为和分区列最大值差不多的值resultDF: df提交spark配置 spark-submit \--class xx.xxx.xxx.xxx \--master local[*] \--num-executors 6 \--executor-cores 1 \--executor-memory 2G \--driver-memory 4G \/root/test/xxx.jar \-p xxx/xxx.yaml -cyctime $cyctimeoptions.fetchsize一次性读取的数据条数按集群规模例64核128G一次1000条阿里云Spark集群链接不了华为云pg数仓我开了一台独立机器8核16G一次100条 options.partitionColumn分区列必须是bigint类型 options.numPartitions设置分区数最好和spark提交的executors数一致上文中spark任务数为6分区数也为6 options.lowerBound分区开始值 options.upperBound分区结束值numPartitions、lowerBound、upperBound这三个必须同时设置每个分区的数据量计算公式为upperBound / numPartitions - lowerBound / numPartitions任务运行时间看的是最长的那个任务所以要尽可能保证每一个分区的数据量差不多
官方配置文档
1.灵活运用分区列
有的小伙伴就该思考为啥不用自增id做分区列呢
因为实际生产环境中一是不需要二是创建表忽略了自增id等等。
为啥要新做一列mo而不直接将商品id转bigint用呢
算是一个补救措施新做一个数据列在读取过程用mo做shufflemo是商品id强转为bigint后对6取膜结果为0-5共6种可能提高了shuffle的效率计算分区的数据量6 / 6 - 0 / 6 1也就是说分区值为01234大于5对应6个任务6个核心。
下面是运行shuffle结束后的截图可以看到每一个task获取的数据量都比较均匀 下面来看一个错误的案例 上图配置就会导致数据倾斜 numPartitions10 lowerBound0 upperBound100 表的数据量是1000。 根据计算公式每个分区的数据量是100/10-0/1010分10个区那么前9个分区数据量都是10但最后一个分区数据量却达到了910即数据倾斜了所以upperBound-lowerBound要和表的分区字段最大值差不多
有啥需要优化的欢迎评论纠正
