load data旁路导入单张700G的大表,效率非常低,耗时3天才完成,这个是合理的吗

【 使用环境 】测试环境
【 OB or 其他组件 】
【 使用版本 】4.3.4
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
直接使用700G的大文件做旁路导入报了超时,切分成100个小文件依次load,速度越来越慢,一开始可能3-4分钟1个文件,到最后单个文件耗时1小时左右

@论坛小助手
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手] 即可召唤小助手,欢迎试用!

1 个赞

根据文档库中的信息,旁路导入的效率受多种因素影响,包括但不限于数据量大小、硬件资源配置、网络状况等。针对您提到的情况,这里有几个可能的原因和建议:

  1. 数据量过大:您提到的数据量为700GB,这确实是一个非常大的数据量。根据文档片段4中的描述,当导入的数据量小于Memtable时,旁路导入没有优势。因此,对于如此大的数据量,旁路导入的优势可能没有完全发挥出来。此外,文档片段8中提到,如果数据文件大小为TB以上,建议使用旁路导入以提高效率。虽然您的数据量接近这个阈值,但仍然需要注意其他因素的影响。

  2. 硬件资源配置:文档片段4中提到,全量旁路导入适用于CPU和内存都不是特别充裕的场景。如果您的测试环境中CPU和内存资源较为充足,那么旁路导入的效率可能会受到影响。建议检查测试环境的硬件资源配置,确保有足够的资源支持高效的数据导入。

  3. 网络状况:旁路导入通过连接RPC端口进行数据传输,网络状况对导入效率有很大影响。如果网络带宽较低或者网络延迟较高,都会导致导入速度变慢。建议检查网络状况,确保网络连接稳定且带宽足够。

  4. 数据文件切分:您提到将700GB的大文件切分成100个小文件进行导入,速度逐渐变慢。这可能是由于随着导入过程的进行,系统资源逐渐紧张,导致后续文件的导入速度变慢。建议尝试调整切分后的文件大小,找到一个合适的平衡点,既不会因为文件过大而导致导入效率低下,也不会因为文件过小而频繁切换文件导致额外的开销。

  5. 并行度设置:文档片段8中提到,可以通过增加并行度来提高导入效率。您可以尝试调整--thread参数和--parallel参数的值,以充分利用多核CPU的计算能力,提高导入速度。

综上所述,700GB的大表旁路导入耗时3天确实较长,但考虑到数据量巨大、硬件资源配置、网络状况等因素,这种情况并非完全不合理。建议您根据上述建议进行优化,以提高导入效率。如果问题依然存在,建议联系OceanBase的技术支持团队获取进一步的帮助。

检索到的文档如下:

  1. 设置并行执行参数
  2. 旁路导入概述
  3. 全量旁路导入
  4. 使用 LOAD DATA 语句导入数据
  5. obcdc 支持增量旁路导入
  6. 使用 OBLOADER 旁路导入数据
  7. 体验并行导入和数据压缩
1 个赞

可以参考小助手的建议排查下,加并行试下呢,例如

obclient [test]> LOAD DATA /*+direct(true,1024)  parallel(32) */ INFILE '/backup/csv/bmsql_order_line.csv' INTO TABLE bmsql_order_line FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n';

我的语句和这个类似
LOAD DATA /*+direct(false,1024,full) parallel(64) */ INFILE ‘/backup/csv/bmsql_order_line.csv’ INTO TABLE bmsql_order_line FIELDS TERMINATED BY ‘,’ ENCLOSED BY ‘"’ LINES TERMINATED BY ‘\n’;

根据您提供的 LOAD DATA 语句和文档中的信息,我们可以分析一下可能导致导入效率低下的几个原因,并提出相应的优化建议。

分析

  1. 并行度设置

    • 您的语句中设置了 PARALLEL(64),这表示使用64个线程并行加载数据。根据文档片段2,PARALLEL 的建议取值范围是 0 到租户的最大 CPU 数。如果您的测试环境中 CPU 核数较少,设置过高的并行度可能会导致资源竞争,反而降低效率。
    • 建议检查测试环境的 CPU 核数,并适当调整 PARALLEL 的值。例如,如果您的 CPU 核数为 32,可以尝试将 PARALLEL 设置为 32 或更低。
  2. 数据文件切分

    • 您提到将700GB的大文件切分成100个小文件进行导入,速度逐渐变慢。这可能是由于随着导入过程的进行,系统资源逐渐紧张,导致后续文件的导入速度变慢。
    • 建议尝试调整切分后的文件大小,找到一个合适的平衡点。例如,可以尝试将每个文件的大小调整为 500MB 或 1GB,而不是 7GB。
  3. Hint 设置

    • 您的语句中使用了 direct(false, 1024, full),这表示使用直接路径加载数据,但不启用旁路导入。根据文档片段9,旁路导入通过并行处理技术优化 LOAD DATA 的数据导入速率。如果您的表没有主键,数据写入顺序可能与原文件中的顺序不同。
    • 建议尝试启用旁路导入,即将 direct 设置为 true,例如:direct(true, 1024, full)
  4. 硬件资源配置

    • 确保测试环境的硬件资源配置足够,特别是 CPU 和内存。如果资源不足,可能会导致导入效率低下。
    • 检查磁盘 I/O 性能,确保磁盘读写速度足够快。
  5. 网络状况

    • 如果数据文件存储在远程服务器上,网络带宽和延迟也会影响导入速度。确保网络连接稳定且带宽足够。

优化建议

  1. 调整并行度

    LOAD DATA /*+direct(true, 1024, full) parallel(32) */ INFILE '/backup/csv/bmsql_order_line.csv' INTO TABLE bmsql_order_line FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n';
    

    PARALLEL 调整为与 CPU 核数相匹配的值。

  2. 调整数据文件大小

    • 尝试将每个文件的大小调整为 500MB 或 1GB,重新进行导入。
  3. 启用旁路导入

    • direct 设置为 true,启用旁路导入。
  4. 监控系统资源

    • 使用系统监控工具(如 topiostatvmstat 等)监控 CPU、内存和磁盘 I/O 的使用情况,确保资源充足。
  5. 检查网络状况

    • 如果数据文件存储在远程服务器上,使用 pingiperf 等工具检查网络带宽和延迟。

结论

根据文档库中的信息,700GB的大表旁路导入耗时3天确实较长,但考虑到数据量巨大、硬件资源配置、网络状况等因素,这种情况并非完全不合理。建议您根据上述优化建议进行调整,以提高导入效率。如果问题依然存在,建议联系OceanBase的技术支持团队获取进一步的帮助。

更多信息请查看:

  1. LOAD DATA
  2. 并行执行分类与优化
  3. ETL 加速
  4. 执行计划管理
  5. 全量旁路导入
  6. 插入数据
  7. INSERT
  8. LOAD INDEX INTO CACHE

(小助手的答复已结束,如未能解决您的问题,请继续提问并等待其他同学的回复,谢谢!)

1 个赞

看样子你应该是分了多次执行旁路导入,目前旁路导入的hint里面如果指定full的话,表示全量旁路导入,全量旁路导入的逻辑里面,每次都会带上已有的数据重新排序后,再整体写入,所以会越往后越慢。

要绕的话有两个办法:

  1. 如果一定要做全量旁路导入,尽量搞成一次。2.或者可以用增量旁路导入,但增量旁路导入目前有一些限制,不能支持带索引表的增量旁路导入。

或者使用obloader完成全量旁路导入,应该会更稳定一些