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

OceanBase 技术问题
#1

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

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

1 个赞
#3

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

  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 个赞
#4

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

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';
#5

我的语句和这个类似
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’;

#6

根据您提供的 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. 监控系统资源：

    • 使用系统监控工具（如 top、iostat、vmstat 等）监控 CPU、内存和磁盘 I/O 的使用情况，确保资源充足。

  5. 检查网络状况：

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

结论

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

更多信息请查看:

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

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

1 个赞
#7

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

要绕的话有两个办法：

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

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