20亿数据的导入,tispark

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
Ti server 32GX3 16v核
Ti pd 32Gx3 16v核
Ti kv 32GX3 16核

【概述】 场景 + 问题概述

24小时内要导入20亿数据,字段53个,一个string主键,没有autoincrement。
insert跟update比例各半。QPS上不去。

存在大量 spilling in-memory map of 5.4 GB to disk (1 time so far)。spark的storage界面显示磁盘使用超过76G

【背景】 做过哪些操作
tikv tiserver 做了最大内存限制,其他的配置没有改。

【现象】 业务和数据库现象
tispark 的demo跟jdbc比,tispark只能有7k的qps。jdbc方式能到9k的qps。
表目前15亿,4500个region。

我能不能事先切好数据,再用tispark

【问题】 当前遇到的问题

写了20小时,spark的界面显示 mapping 的步骤跑了4遍,超过8小时 和 count超过3小时。
问题1:
我能预先切数据到500个分区,然后每个分区起一个tispark任务来跑。并发写能行吗?

问题2:
tispark有没有commit机制,我跑了20个小时,没有查到数据写进去。
500w的数据21分钟能写跑成功。
1000w的数据21分钟能写跑成功。

【业务影响】
qps上不去。
【TiDB 版本】
4.0.x
【应用软件及版本】
spark 2.4.1集群,excutor 200个、32G
【附件】 相关日志及配置信息

  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息

监控(https://metricstool.pingcap.com/)

  • TiDB-Overview Grafana监控
  • TiDB Grafana 监控
  • TiKV Grafana 监控
  • PD Grafana 监控
  • 对应模块日志(包含问题前后 1 小时日志)

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

是不是热点问题,导致了写的瓶颈? 你可以看看热力图

JDBC的时间点: 7月22日 18点24到 18点35
Performance-Write_2021-07-23T02_07_52.728Z.zip (277.7 KB)

你给的监控太少(这个建议你先看一下 ,写流程慢,直接 asktug 上搜就OK)TiDB 写入慢流程排查系列(一)— 前言

我是批量导入30亿数据的需求,每条数据约几个或十几个字段,需要在15h左右导入。采用的切分成小数据,然后依次串行导入的方案。求更好更合适的方案

spark本身是个批处理框架,先切成500个分区,然后用tispark导入,spark任务的提交时间就会是很大的麻烦。
我见过的程序中,一般都是在spark内部做重分区,例如:
image
如图中的repartion(500)
按照我的理解,底层的分布更多,spark写入的写入更好,我的测试中,8C32G的16个节点的tikv,2000千万写入时间在7分钟左右。程序测试过程中我发现tispark仍然也有保持事务,只不过很多环节,是spark批量在做,所以是存在commit的。
建议是不是开启乐观事务和异步提交事务,能够提高一些效率。

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。