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

例行导入

如何提高导入性能？​

方法一：增加实际导入任务的并行度，即将一个导入作业拆分为尽可能多的并行导入任务。

注意

此方法可能会消耗更多的 CPU 资源，并导致 Tablet 版本过多。

实际导入任务的并行度由以下公式确定，该公式由多个参数组成，上限为存活 BE 节点的数量或要消费的分区数量。

min(alive_be_number, partition_number, desired_concurrent_number, max_routine_load_task_concurrent_num)

参数说明

  • alive_be_number：存活 BE 节点的数量。
  • partition_number：要消费的分区数量。
  • desired_concurrent_number：例行导入作业所需的导入任务并行度。默认值为 3。您可以为此参数设置更高的值以增加实际导入任务的并行度。
    • 如果您尚未创建例行导入作业，则在使用 CREATE ROUTINE LOAD 创建例行导入作业时需要设置此参数。
    • 如果您已创建例行导入作业，则需要使用 ALTER ROUTINE LOAD 修改此参数。
  • max_routine_load_task_concurrent_num：例行导入作业的默认最大任务并行度。默认值为 5。此参数是 FE 动态参数。有关更多信息和配置方法，请参阅 参数配置。

因此，当要消费的分区数量和存活 BE 节点的数量大于其他两个参数时，您可以增加 desired_concurrent_number 和 max_routine_load_task_concurrent_num 参数的值以增加实际导入任务的并行度。

例如，要消费的分区数量为 7，存活 BE 节点的数量为 5，max_routine_load_task_concurrent_num 为默认值 5。此时，如果您需要将导入任务并行度增加到上限，则需要将 desired_concurrent_number 设置为 5（默认值为 3）。然后，计算实际任务并行度 min(5,7,5,5) 为 5。

有关更多参数说明，请参阅 CREATE ROUTINE LOAD。

方法二：增加例行导入任务从一个或多个分区消费的数据量。

注意

此方法可能会导致数据导入延迟。

例行导入任务可以消费的消息数量上限由参数 max_routine_load_batch_size（表示导入任务可以消费的最大消息数量）或参数 routine_load_task_consume_second（表示消息消费的最大持续时间）决定。一旦导入任务消费了满足任一要求的足够数据，消费即完成。这两个参数都是 FE 动态参数。有关更多信息和配置方法，请参阅 参数配置。

您可以通过查看 be/log/be.INFO 中的日志来分析哪个参数决定了导入任务消费的数据量上限。通过增加该参数，您可以增加导入任务从一个或多个分区消费的数据量。

I0325 20:27:50.410579 15259 data_consumer_group.cpp:131] consumer group done: 41448fb1a0ca59ad-30e34dabfa7e47a0. consume time(ms)=3261, received rows=179190, received bytes=9855450, eos: 1, left_time: -261, left_bytes: 514432550, blocking get time(us): 3065086, blocking put time(us): 24855

通常，日志中的字段 left_bytes 大于或等于 0，表示导入任务消费的数据量在 routine_load_task_consume_second 内没有超过 max_routine_load_batch_size。这意味着一批调度的导入任务可以消费来自 Kafka 的所有数据，而不会造成消费延迟。在这种情况下，您可以为 routine_load_task_consume_second 设置更大的值，以增加导入任务从一个或多个分区消费的数据量。

如果字段 left_bytes 小于 0，则表示导入任务消费的数据量在 routine_load_task_consume_second 内已达到 max_routine_load_batch_size。每次来自 Kafka 的数据都会填满一批调度的导入任务。因此，极有可能存在尚未在 Kafka 中消费的剩余数据，导致消费延迟。在这种情况下，您可以为 max_routine_load_batch_size 设置更大的值。

如果 SHOW ROUTINE LOAD 的结果显示导入作业处于 PAUSED 状态，我该怎么办？​

  • 检查字段 ReasonOfStateChanged，它报告错误消息 Broker: Offset out of range。

    原因分析： 导入作业的消费者偏移量在 Kafka 分区中不存在。

    解决方案： 您可以执行 SHOW ROUTINE LOAD 并检查参数 Progress 中导入作业的最新消费者偏移量。然后，您可以验证相应的消息是否在 Kafka 分区中存在。如果不存在，可能是因为

    • 创建导入作业时指定的消费者偏移量是未来的偏移量。
    • Kafka 分区中指定的消费者偏移量处的消息在被导入作业消费之前已被删除。建议根据导入速度设置合理的 Kafka 日志清理策略和参数，例如 log.retention.hours and log.retention.bytes。

  • 检查字段 ReasonOfStateChanged，它没有报告错误消息 Broker: Offset out of range。

    原因分析： 导入任务中的错误行数超过了阈值 max_error_number。

    解决方案： 您可以使用字段 ReasonOfStateChanged 和 ErrorLogUrls 中的错误消息来排查并解决问题。

    • 如果是数据源中数据格式不正确造成的，您需要检查数据格式并解决该问题。成功解决问题后，您可以使用 RESUME ROUTINE LOAD 恢复暂停的导入作业。

    • 如果是 StarRocks 无法解析数据源中的数据格式，您需要调整阈值 max_error_number。您可以先执行 SHOW ROUTINE LOAD 查看 max_error_number 的值，然后使用 ALTER ROUTINE LOAD 增加阈值。修改阈值后，您可以使用 RESUME ROUTINE LOAD 恢复暂停的导入作业。

如果 SHOW ROUTINE LOAD 的结果显示导入作业处于 CANCELLED 状态，我该怎么办？​

原因分析： 导入作业在导入过程中遇到异常，例如表被删除。

解决方案： 在排查和解决问题时，您可以参考字段 ReasonOfStateChanged 和 ErrorLogUrls 中的错误消息。但是，解决问题后，您无法恢复已取消的导入作业。

从 Kafka 消费并写入 StarRocks 时，例行导入是否可以保证一致性语义？​

例行导入保证了精确一次语义。

每个导入任务都是一个单独的事务。如果在事务执行过程中发生错误，则事务中止，并且 FE 不会更新导入任务的相关分区的消费进度。当 FE 下次从任务队列中调度导入任务时，导入任务将从分区的上次保存的消费位置发送消费请求，从而确保精确一次语义。