20亿数据的导入，tispark

🛸 其他技术问题 TiSpark
1

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 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 小时日志）

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

2

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

3

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

4

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

5

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

6

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

7

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