跳到主要内容
版本: 最新版本-3.5

数据加载常见问题

1. 如果出现“close index channel failed”或“too many tablet versions”错误，该怎么办？​

您运行加载任务的频率太高，并且数据没有及时压缩。 因此，加载期间生成的数据版本数量超过了允许的最大数据版本数（默认为 1000）。 使用以下方法之一来解决此问题

  • 增加每个单独任务中加载的数据量，从而降低加载频率。

  • 修改每个BE的BE配置文件 be.conf 中的一些配置项，以加速压缩

    • 对于 Duplicate Key 表、Aggregate 表和 Unique Key 表，您可以适当增加 cumulative_compaction_num_threads_per_disk、base_compaction_num_threads_per_disk 和 cumulative_compaction_check_interval_seconds 的值。 例子

      cumulative_compaction_num_threads_per_disk = 4
      base_compaction_num_threads_per_disk = 2
      cumulative_compaction_check_interval_seconds = 2

    • 对于 Primary Key 表，您可以适当增加 update_compaction_num_threads_per_disk 的值，并减少 update_compaction_per_tablet_min_interval_seconds 的值。

    修改上述配置项的设置后，您必须观察内存和 I/O，以确保它们正常。

2. 如果出现“Label Already Exists”错误，该怎么办？​

发生此错误是因为加载任务与同一 StarRocks 数据库中已成功运行或正在运行的另一个加载任务具有相同的标签。

Stream Load 作业是根据 HTTP 提交的。 通常，请求重试逻辑嵌入在所有编程语言的 HTTP 客户端中。 当 StarRocks 集群收到来自 HTTP 客户端的加载任务请求时，它会立即开始处理该请求，但不会及时将作业结果返回给 HTTP 客户端。 因此，HTTP 客户端再次发送相同的加载任务请求。 但是，StarRocks 集群已经在处理第一个请求，因此为第二个请求返回 Label Already Exists 错误。

执行以下操作以检查使用不同加载方法提交的加载作业是否具有相同的标签并且没有重复提交

  • 查看 FE 日志并检查失败的加载作业的标签是否记录了两次。 如果标签记录了两次，则客户端已提交了两次加载作业请求。

    注意

    StarRocks 集群不区分基于加载方法的加载作业的标签。 因此，使用不同加载方法提交的加载作业可能具有相同的标签。

  • 运行 SHOW LOAD WHERE LABEL = "xxx" 以检查具有相同标签并且处于 FINISHED 状态的加载作业。

    注意

    xxx 是您要检查的标签。

在提交加载作业之前，我们建议您计算加载数据所需的大概时间，然后相应地调整客户端请求超时时间。 这样，您可以防止客户端多次提交加载作业请求。

3. 如果出现“ETL_QUALITY_UNSATISFIED; msg:qualitynot good enough to cancel”错误，该怎么办？​

执行 SHOW LOAD，并使用返回的执行结果中的错误 URL 查看错误详细信息。

常见的数据质量错误如下

  • "convert csv string to INT failed."

    源列中的字符串无法转换为匹配的目标列的数据类型。 例如，abc 无法转换为数值。

  • "the length of input is too long than schema."

    源列中的值长度超过了匹配的目标列支持的长度。 例如，CHAR 数据类型的源列值超过了创建表时指定的目标列的最大长度，或者 INT 数据类型的源列值超过了 4 个字节。

  • "actual column number is less than schema column number."

    在基于指定的列分隔符解析源行后，获得的列数小于目标表中的列数。 一个可能的原因是在加载命令或语句中指定的列分隔符与在该行中实际使用的列分隔符不同。

  • "actual column number is more than schema column number."

    在基于指定的列分隔符解析源行后，获得的列数大于目标表中的列数。 一个可能的原因是在加载命令或语句中指定的列分隔符与在该行中实际使用的列分隔符不同。

  • "the frac part length longer than schema scale."

    DECIMAL 类型源列的值的小数部分超过了指定的长度。

  • "the int part length longer than schema precision."

    DECIMAL 类型源列的值的整数部分超过了指定的长度。

  • "there is no corresponding partition for this key."

    源行的分区列中的值不在分区范围内。

4. 如果 RPC 超时，该怎么办？​

检查每个 BE 的 BE 配置文件 be.conf 中 write_buffer_size 配置项的设置。 此配置项用于控制 BE 上每个内存块的最大大小。 默认最大大小为 100 MB。 如果最大大小过大，远程过程调用 (RPC) 可能会超时。 要解决此问题，请调整 BE 配置文件中 write_buffer_size 和 tablet_writer_rpc_timeout_sec 配置项的设置。 有关更多信息，请参见 BE 配置。

5. 如果出现“Value count does not match column count”错误，该怎么办？​

在我的加载任务失败后，我使用任务结果中返回的错误 URL 检索了错误详细信息，并找到了“Value count does not match column count”错误，这表明源数据文件中的列数与目标 StarRocks 表中的列数不匹配

Error: Value count does not match column count. Expect 3, but got 1. Row: 2023-01-01T18:29:00Z,cpu0,80.99
Error: Value count does not match column count. Expect 3, but got 1. Row: 2023-01-01T18:29:10Z,cpu1,75.23
Error: Value count does not match column count. Expect 3, but got 1. Row: 2023-01-01T18:29:20Z,cpu2,59.44

此问题的原因如下

在加载命令或语句中指定的列分隔符与源数据文件中实际使用的列分隔符不同。 在前面的示例中，CSV 格式的数据文件由三列组成，这些列用逗号 (,) 分隔。 但是，在加载命令或语句中将 \t 指定为列分隔符。 因此，源数据文件中的三列被错误地解析为一列。

在加载命令或语句中将逗号 (,) 指定为列分隔符。 然后，再次提交加载任务。