DATAX 导HBASE 数据导SR,总是报错

【详述】DATAX 导HBASE 数据导SR,总是报错,没办法进行下去
【背景】DATAX 导HBASE 某张大表数据(大概5亿左右)导SR,总是报错
【业务影响】
【StarRocks版本】例如:3.5.2
【集群规模】例如:3fe(1 follower+2observer)+3be(fe与be混部)
【机器信息】CPU虚拟核/内存/网卡,例如:16C/32G/千兆
【联系方式】784830900@qq.com
现在导的速度也不快,才5000条/秒左右!结果每次到5千万-1亿之间就报错。
报错后再查看tablet 也没问题

报错如下:
2023-06-01 22:59:16 [AnalysisStatistics.analysisStatisticsLog-53] 2023-06-01 22:59:16.319 [job-0] INFO StandAloneJobContainerCommunicator - Total 66536352 records, 7593211726 bytes | Speed 810.02KB/s, 7289 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 66,105.383s | All Task WaitReaderTime 11,600.075s | Percentage 0.00%
2023-06-01 22:59:26 [AnalysisStatistics.analysisStatisticsLog-53] 2023-06-01 22:59:26.320 [job-0] INFO StandAloneJobContainerCommunicator - Total 66592256 records, 7599613065 bytes | Speed 625.13KB/s, 5590 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 66,147.234s | All Task WaitReaderTime 11,610.298s | Percentage 0.00%
2023-06-01 22:59:46 [AnalysisStatistics.analysisStatisticsLog-53] 2023-06-01 22:59:46.321 [job-0] INFO StandAloneJobContainerCommunicator - Total 66711040 records, 7613188605 bytes | Speed 662.87KB/s, 5939 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 66,240.344s | All Task WaitReaderTime 11,631.891s | Percentage 0.00%
2023-06-01 22:59:56 [AnalysisStatistics.analysisStatisticsLog-53] 2023-06-01 22:59:56.321 [job-0] INFO StandAloneJobContainerCommunicator - Total 66776480 records, 7620634755 bytes | Speed 727.16KB/s, 6544 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 66,288.297s | All Task WaitReaderTime 11,642.315s | Percentage 0.00%
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] 2023-06-01 23:00:01.813 [0-0-2-writer] WARN CommonRdbmsWriter$Task - 回滚此次写入, 采用每次写入一行方式提交. 因为:Too many versions. tablet_id: 2953891, version_count: 1001, limit: 1000, replica_state: 0: be:10.0.40.27
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] 2023-06-01 23:00:01.815 [0-1-3-writer] ERROR StdoutPluginCollector -
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Too many versions. tablet_id: 2953891, version_count: 1001, limit: 1000, replica_state: 0: be:10.0.40.27
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at sun.reflect.GeneratedConstructorAccessor16.newInstance(Unknown Source) ~[na:na]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:1.8.0_251]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[na:1.8.0_251]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.mysql.jdbc.Util.handleNewInstance(Util.java:425) ~[mysql-connector-java-5.1.47.jar:5.1.47]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.mysql.jdbc.Util.getInstance(Util.java:408) ~[mysql-connector-java-5.1.47.jar:5.1.47]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:944) ~[mysql-connector-java-5.1.47.jar:5.1.47]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3978) ~[mysql-connector-java-5.1.47.jar:5.1.47]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3914) ~[mysql-connector-java-5.1.47.jar:5.1.47]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2530) ~[mysql-connector-java-5.1.47.jar:5.1.47]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2683) ~[mysql-connector-java-5.1.47.jar:5.1.47]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2495) ~[mysql-connector-java-5.1.47.jar:5.1.47]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1903) ~[mysql-connector-java-5.1.47.jar:5.1.47]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1242) ~[mysql-connector-java-5.1.47.jar:5.1.47]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.alibaba.datax.plugin.rdbms.writer.CommonRdbmsWriter$Task.doOneInsert(CommonRdbmsWriter.java:382) [plugin-rdbms-util-0.0.1-SNAPSHOT.jar:na]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.alibaba.datax.plugin.rdbms.writer.CommonRdbmsWriter$Task.doBatchInsert(CommonRdbmsWriter.java:362) [plugin-rdbms-util-0.0.1-SNAPSHOT.jar:na]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.alibaba.datax.plugin.rdbms.writer.CommonRdbmsWriter$Task.startWriteWithConnection(CommonRdbmsWriter.java:291) [plugin-rdbms-util-0.0.1-SNAPSHOT.jar:na]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.alibaba.datax.plugin.rdbms.writer.CommonRdbmsWriter$Task.startWrite(CommonRdbmsWriter.java:319) [plugin-rdbms-util-0.0.1-SNAPSHOT.jar:na]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.alibaba.datax.plugin.writer.mysqlwriter.MysqlWriter$Task.startWrite(MysqlWriter.java:78) [mysqlwriter-0.0.1-SNAPSHOT.jar:na]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at com.alibaba.datax.core.taskgroup.runner.WriterRunner.run(WriterRunner.java:56) [datax-core-0.0.1-SNAPSHOT.jar:na]
2023-06-01 23:00:01 [AnalysisStatistics.analysisStatisticsLog-53] at java.lang.Thread.run(Thread.java:748) [na:1.8.0_251]

be.conf 也做了配置:FE 内存设置12G
base_compaction_check_interval_seconds = 10
cumulative_compaction_num_threads_per_disk = 4
base_compaction_num_threads_per_disk = 2
cumulative_compaction_check_interval_seconds = 2

enable_new_load_on_memory_limit_exceeded = true

DATAX配置的json配置:
{
“job”: {
“setting”: {
“speed”: {
“channel”: 1,
“byte”: 1048576000
},
“errorLimit”: {
“record”: 0,
“percentage”: 0.02
}
},
“content”: [
{
“reader”: {
“name”: “hbase11xreader”,
“parameter”: {
“hbaseConfig”: {
“hbase.zookeeper.quorum”: “10.0.20.201:2181”
},
“table”: “uat_cs_anso_tension_data_point_new”,
“splitPk”: “rowkey”,
“mode”: “normal”,
“sliceRecordCount”: 20000,
“column”: [
{
“name”: “rowkey”,
“type”: “string”
},
{
“name”: “f1:16”,
“type”: “string”
},
{
“name”: “f1:16pid”,
“type”: “string”
},
{
“name”: “f1:17”,
“type”: “string”
},
{
“name”: “f1:17pid”,
“type”: “string”
},
{
“name”: “f1:26”,
“type”: “string”
},
{
“name”: “f1:26pid”,
“type”: “string”
},
{
“name”: “f1:createTime”,
“type”: “string”
},
{
“name”: “f1:dsn”,
“type”: “string”
},
{
“name”: “f1:meterSize”,
“type”: “string”
},
{
“name”: “f1:pointId”,
“type”: “string”
},
{
“name”: “f1:readTime”,
“type”: “string”
},
{
“name”: “f1:receiveTime”,
“type”: “string”
},
{
“name”: “f1:source”,
“type”: “string”
}
]
}
},
“writer”: {
“name”: “mysqlwriter”,
“parameter”: {
“username”: “yRjwDFuoPKlqya9h9H2Amg==”,
“password”: “C09ZRn8u6krcDC/rnfb5Cw==”,
“maxBatchRows”: 500000000,
“maxBatchSize”: 10485760000,
“flushInterval”: 20000,
“column”: [
row_key”,
16”,
16pid”,
17”,
17pid”,
26”,
26pid”,
createTime”,
dsn”,
meterSize”,
pointId”,
readTime”,
receiveTime”,
source
],
“connection”: [
{
“table”: [
“uat_cs_tension_data_point”
],
“jdbcUrl”: “jdbc:mysql://10.0.40.25:9030/dev_data_static?sessionVariables=MAX_EXECUTION_TIME=68400000&useCompression=true&useCursorFetch=true”,
“loadUrl”: [
“10.0.40.25:8030”,
“10.0.40.26:8030”,
“10.0.40.27:8030”
]
}
]
}
}
}
]
}
}

sr官方不是有starrockswriter 吗 你用mysqlwriter这个能导入starrocks?

现在已经改为 starrockswriter,先看看结果。。后续回复。。

嗯嗯 参考这个文档 https://docs.starrocks.io/zh-cn/latest/loading/DataX-starrocks-writer 用StarRocks Writer 插件导入

1赞

配置信息


报错页面

建表语句

已经按文档配置了,结果导入时候,导2亿多时候就报错了。。。
HBASE 库里有5亿左右数据,这个有什么办法,能把所有数据导入进去!
各位大神,请帮忙看看。。。

datax完整的日志发下,看起来你导入频率太高了,一次只写了9m数据

datax报错日志.txt (1.1 MB)
你好,这是报错日志。。。

麻烦帮忙看下,万分感谢!

看日志还是导入频率太高导致的 ,修改下对应的参数,增大单词导入数据量,降低导入频次, datax相应参数:

参考文档:https://docs.starrocks.io/zh-cn/main/loading/DataX-starrocks-writer

  • maxBatchRows
    • 描述:单次StreamLoad导入的最大行数
    • 必选:否
    • 默认值:500000 (50W)
  • maxBatchSize
    • 描述:单次StreamLoad导入的最大字节数。
    • 必选:否
    • 默认值:104857600 (100M)
  • flushInterval
    • 描述:上一次StreamLoad结束至下一次开始的时间间隔(单位:ms)。
    • 必选:否
    • 默认值:300000 (ms)


之前你们技术员,有说 三个条件之一符合就写数据,让频率改为15秒一次,另外两个条件设置大,不让触发
“maxBatchRows”: 50000000,
“maxBatchSize”: 1048576000,
“flushInterval”: 15000,

每次到2亿就不行了,不管是插入快还是慢。结果都是这样!


后面又一直不中断的,但是一直读取,和写入树数都是0.一直都没变化!
有大神们,帮忙看下吗!

请问下最新的报错还是too many tablet versions 吗

另外确认下读取hbase有超时设置吗

另外可以把hbase的scan也调大,目前看起来一个channel里面拆分成了7个task,每个task写入才不到10m数据,太小了
https://github.com/alibaba/DataX/blob/master/hbase11xreader/doc/hbase11xreader.md

datax sr写的参数配置:
sr写参数

按照官网的配置说明:

最后到5亿多时候报错信息:

真的是崩溃啊,到了5亿多居然挂了。。导一天的数据了!
麻烦帮忙看下,应该怎么设置才对! 连续几天这么导数据都这样!

到5亿多时候,25那台磁盘空间达到85%。。。
SR有没有要求,磁盘必须剩下多少才行?

你把flushInterval调大吧,目前看你的数据每个批次太小了,另外看着你的配置byte没生效,实际只有1m

目前有限制,

问题已经解决,感谢大家帮助。

maxBatchRows:5000000
MaxBatchSize:10485760000 (10G)
flushInterval:50000 (50秒)
解决版本报错问题

报JVM GC,增加datax服务器内存到16G,设置启动参数限制内存
-Xms8196M -Xmx8196M -XX:+HeapDumpOnOutOfMemoryError

解决JVM GC问题。

最后达到每秒平均90000条/秒左右。。。

1赞