【详述】通过streamload导入数据量为30亿行的表
【背景】AP数据库性能测试，将数据从业务库里通过脚本导出，每100W行导出到一个文件中，然后通过脚本调用streamload，将数据文件（一个文件导入耗时5s左右，文件近1.2G）依次导入到starrocks中，导入10多亿行后，导入报Failed to load data into tablet 13024, because of too many versions, current/limit: 1002/1000. You can reduce the loading job concurrency, or increase loading data batch size. If you are loading data with Routine Load, you can increase FE configs routine_load_task_consume_second and max_routine_load_batch_size,: be:xxx.xxx.xxx.xxx"
尝试解决
1、查看官网文档里的解决方案:
上述报错是因为导入频率太快，数据没能及时合并 (Compaction) ，从而导致版本数超过支持的最大未合并版本数。默认支持的最大未合并版本数为 1000。可以通过如下方法解决上述报错：
- 增大单次导入的数据量，降低导入频率。
- 在 BE 的配置文件 be.conf 中修改以下配置，通过调整合并策略实现加快合并的目的：
cumulative_compaction_num_threads_per_disk = 4
base_compaction_num_threads_per_disk = 2
cumulative_compaction_check_interval_seconds = 2
配置了如上参数，并在每次导入后sleep 10秒，仍然只能完成不到15亿行的数据。
通过show tablet from tableName查看，VersionCount在用满1000后，缓慢下降，过了一晚后，降低到700多后，不再下降。
mysql> show tablet from test;
±---------±----------±----------±-----------±--------±------------±------------------±----------------------±-----------------±---------------------±--------------±---------±-----------±-------±------------------------±-------------±-----------------±-------------±--------------------±----------------------------------------------±------------------------------------------------------------+
| TabletId | ReplicaId | BackendId | SchemaHash | Version | VersionHash | LstSuccessVersion | LstSuccessVersionHash | LstFailedVersion | LstFailedVersionHash | LstFailedTime | DataSize | RowCount | State | LstConsistencyCheckTime | CheckVersion | CheckVersionHash | VersionCount | PathHash | MetaUrl | CompactionStatus |
±---------±----------±----------±-----------±--------±------------±------------------±----------------------±-----------------±---------------------±--------------±---------±-----------±-------±------------------------±-------------±-----------------±-------------±--------------------±----------------------------------------------±------------------------------------------------------------+
| 13024 | 13025 | 10007 | 0 | 2215 | 0 | 2215 | 0 | -1 | 0 | NULL | 1.3TB | 1505000000 | NORMAL | NULL | -1 | 0 | 753 | 3278712077335169428 | http://xxx.xxx.xxx.xxx:8040/api/meta/header/13024 | http://26.84.214.5:8040/api/compaction/show?tablet_id=13024 |
±---------±----------±----------±-----------±--------±------------±------------------±----------------------±-----------------±---------------------±--------------±---------±-----------±-------±------------------------±-------------±-----------------±-------------±--------------------±----------------------------------------------±------------------------------------------------------------+
1 row in set (0.00 sec)
建表语句：
CREATE TABLE test (
id varchar(65533) NOT NULL,
user_id varchar(65533) NULL,
arrange_id varchar(65533) NULL,
org_id varchar(65533) NULL,
group_org_id varchar(65533) NULL,
dept_id varchar(65533) NULL,
dept_id_full_path varchar(65533) NULL,
position_id varchar(65533) NULL,
ques_id varchar(65533) NULL ,
exam_ques_id varchar(65533) NULL,
sub_ques smallint(6) NULL ,
parent_id varchar(65533) NULL ,
q_type smallint(6) NULL,
content varchar(65533) NULL ,
level_type smallint(6) NULL,
point_names varchar(65533) NULL,
ques_score decimal64(18, 2) NULL,
correct_answer varchar(65533) NULL,
explain_text varchar(65533) NULL,
score decimal64(18, 2) NULL ,
faulted smallint(6) NULL ,
judge_answer tinyint(4) NULL ,
submit_content varchar(65533) NULL,
db_create_time datetime NULL,
db_update_time datetime NULL ,
dw_status smallint(6) NULL DEFAULT “0” ,
update_time datetime NULL ,
create_time datetime NULL ,
compose_ques_id varchar(65533) NULL ,
create_user_id varchar(65533) NULL,
update_user_id varchar(65533) NULL ,
ue_batch_id varchar(65533) NULL,
batch_id varchar(65533) NULL,
ue_id varchar(65533) NULL ,
db_dts_data_create_time datetime NULL ,
db_dts_data_update_time datetime NULL,
db_biz_data_create_time datetime NULL,
db_biz_data_update_time datetime NULL,
db_batch_uptime_time datetime NULL,
db_stream_update_time datetime NULL ,
uq_id varchar(65533) NULL
) ENGINE=OLAP
PRIMARY KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 1
PROPERTIES (
“replication_num” = “1”,
“in_memory” = “false”,
“storage_format” = “DEFAULT”,
“enable_persistent_index” = “false”,
“replicated_storage” = “true”,
“compression” = “LZ4”
);
问题：
1、对10亿级以上数据量的表，是否只有增大单次导入数据量这个方式？单次导入加大到500w条？这个对内存是不是有很高的要求？
2、数据版本数tablet_max_versions的默认值1000是否能够调大？社区群里有专家建议可以调大版本数，但调大版本数会影响查询的性能和compaction
3、表的版本数为啥合并到700多后无法继续下降？
4、当前的表的版本数限制，是否限定starrocks无法支持秒级的数据同步时延。若每10秒钟一次，则1000个版本只能支持2，3个小时。社区宣传的秒级时延的实践是如何做的。
【业务影响】无
【是否存算分离】否
【StarRocks版本】3.1.6
【集群规模】1fe+1be 单机部署
【机器信息】80C/384G/万兆
【表模型】主键模型
【导入或者导出方式】streamload
【联系方式】StarRocks社区群8-陈华
【附件】