GBase 8a 大批量导入时，哪些地方最容易把吞吐拖下来

做 GBase 8a 这类分析型集群，真正到了现场，我自己比较容易先盯住两件事：一是导不进去，二是导得进去但速度越来越不稳。 很多时候业务侧看到的是“同样 500G 数据，这次两小时，下次五小时”，表面像网络波动，往深一点看，常常是加载并行度、文件切分、小文件数量、错误行控制和节点负载没配平。GBase 8a 的加载链路本身就不是单点执行，而是由 gcluster 接收任务、解析数据源、把文件或逻辑块分配给多个 gnode 并行处理，再把合法数据按表和 hash 列归到对应分片里。它支持本地、FTP/SFTP、HTTP/HTTPS、HDFS、Kafka、S3 等多种数据源，也支持普通文本、定长、宽松模式以及多节点并行解析。

从落地角度看，这个方向和“慢 SQL 联动优化”不是一回事，和“统计信息、执行计划、参数联动调优”也不是一回事。加载问题更像一类入口侧的吞吐治理问题。 我自己更倾向把它拆成四段：源文件组织是不是合理、任务切块是不是合适、节点并行度是不是过头或偏小、错误数据和状态监控是不是做得过粗。GBase 8a 的 LOAD DATA INFILE 语法本身就暴露了不少关键控制项，比如 NOSPLIT、PARALLEL、MAX_DATA_PROCESSORS、MIN_CHUNK_SIZE、MAX_BAD_RECORDS、TRACE、TRACE_PATH，这些参数其实已经把现场里最常见的几个矛盾点摆出来了。

先别急着调参数，先判断问题是在“文件”、在“节点”，还是在“错误数据”

我自己处理大批量导入问题时，一般不会一上来就改全局参数。因为同样是“导入慢”，根因可能完全不同。

第一类是文件组织问题。比如目录里堆了大量小文件，或者压缩文件太多、单文件又太碎，这种场景下计划阶段和连接开销本身就会放大。GBase 社区资料提到，在 862.33R39、953 及以上版本里，对大量小文件加载做过优化，相同数据量下，文件数越多，优化收益越明显，但这恰恰也说明小文件场景本身就是需要重点关注的负载类型。

第二类是节点并行配置问题。GBase 8a 支持多点传输和多节点并行解析，理论上加载性能可以随着集群节点数增加而扩展；但并不是把并行度拉满就一定更快。官方社区给出的经验值里，gcluster_loader_max_data_processors 默认 16，在加载并发较高、节点较多场景下更建议配到 4 到 8；gbase_loader_parallel_degree 默认 0，实际使用 CPU 核数一半，也更建议落在 4 到 6。这个思路我自己很认同，因为现场里最怕的不是“线程太少”，而是线程很多、磁盘和网络已经扛不住、结果队列更堵。

第三类是错误数据控制太粗。有些导入任务不是纯性能问题，而是边导边报错、重复回滚，最后表现出来像吞吐很差。MAX_BAD_RECORDS 用来控制错误数据上限，取值 0 表示只要有错误就退出并回滚；超过限制时，所有节点的加载任务都会终止。这个参数如果配得过于激进，导入质量是守住了，但任务稳定性会非常差；配得过于宽松，又容易把坏数据放大成后续治理成本。

大文件和小文件，处理思路最好分开

我自己比较在意的一点是：不要把“大文件加载优化”和“小文件加载优化”混成一套动作。 这两类场景看起来都叫“导入慢”，但打法其实不一样。

对于大文件场景，GBase 8a 会把文件切成逻辑块分给多个 data 节点并行加载，文件服务器本身并不实际切文件。按社区资料的描述，data 节点会按行处理分配到自己的逻辑块，跳过开头不完整的上一块尾部数据，再把本块末尾补到完整行。这个机制很适合大体量文本的并行导入。此时我更倾向先看 MIN_CHUNK_SIZE、MAX_DATA_PROCESSORS 和 PARALLEL 是否匹配。

而对于小文件场景，我个人更倾向于先控制“文件个数”和“是否强行切块”。GBase 8a 资料里明确提到，NOSPLIT 会关闭分块并行；同时也提到像 .gz、.snappy 这类压缩文件场景本身就不会做文件切分，更建议打包小文件。这个点在现场里很关键：文件本来就小，再切块，调度成本未必划算；文件本来就压缩，再指望分块并行，也不现实。

一个比较接近真实环境的写法可以是这样：

LOAD DATA INFILE 'sftp://198.51.100.18/data/ods/trade_20260327_*.txt'
INTO TABLE ods_trade_detail
FIELDS TERMINATED BY '|'
LINES TERMINATED BY '\n'
MAX_BAD_RECORDS 100
PARALLEL 4
MAX_DATA_PROCESSORS 6
MIN_CHUNK_SIZE 64
TRACE 1;

如果换成大量压缩小文件，我自己反而更愿意先做减法：

LOAD DATA INFILE 'sftp://198.51.100.18/data/ods/archive_20260327_*.gz'
INTO TABLE ods_trade_detail
FIELDS TERMINATED BY '|'
LINES TERMINATED BY '\n'
NOSPLIT
MAX_BAD_RECORDS 50
TRACE 1;

这里不是说 NOSPLIT 一定更快，而是我个人更倾向于把它看成一个减少无效切分和计划开销的选择。

现场里最常见的，不是“参数不会配”，而是几个参数一起打架

单独看某个参数，通常都说得通；难的是几个参数叠在一起之后，系统到底会往哪边偏。

常用加载参数，我自己更关注这几个

这些参数的默认值和经验调优区间，社区资料已经给得比较明确。比如 gcluster_loader_max_data_processors 默认 16，建议 4 到 8；gbase_loader_parallel_degree 建议 4 到 6；gcluster_loader_min_chunk_size 默认 64M，小于 128M 的文件默认不切分；gbase_loader_buffer_count 默认 16，gbase_loader_line_length 默认 4M。

我自己更在意的是它们之间的组合关系。比如节点很多、任务并发也高的时候，如果 MAX_DATA_PROCESSORS 给得太大，调度范围确实扩大了，但每个任务抢到的节点会更多，整体并发下反而更容易互相挤压。又比如 PARALLEL 抬高以后，CPU 利用率也许上来了，但如果 _gbase_dc_sync_size 太大、磁盘落地和转发节奏偏重，最终可能看到的是 IO 繁忙、CPU 反而不满。社区文章里就提到，当 data 节点磁盘 IO 繁忙、加载慢、CPU 利用率低时，可以考虑把 _gbase_dc_sync_size 从默认 1TB 调小，推荐到 10M 这种量级。

我更喜欢把监控分成“跑的时候看状态”和“跑完了看结果”

很多环境里，大家只在失败后去翻日志。我自己现在不太愿意这么干了，因为加载任务一旦持续几个小时，只在末尾看结果，经常已经错过最佳判断窗口。

GBase 8a 提供了 information_schema.load_status 查看正在运行的加载状态，也可以通过 information_schema.load_result 查看结果；如果要看所有 coordinator 节点的信息，还可以看 CLUSTER_LOAD_RESULT。不过社区资料也专门提醒了一个点：information_schema 这类表查询会占用内存，load_result 在会话之间也不共享，并发扫得太频繁会增加额外压力。

所以我自己的习惯通常是：

SELECT *
FROM information_schema.load_status;

任务结束后再有选择地看结果：

SELECT *
FROM information_schema.load_result
ORDER BY task_id DESC
LIMIT 20;

这个思路比“全程高频轮询”更稳一点。真正落地时，状态表是拿来定位方向的，不是拿来当秒级监控系统猛刷的。

有些导入问题，根因根本不在数据库里

这个点我自己吃过亏，所以现在比较敏感。社区资料里提到，如果用 FreeNAS 之类的软件做文件服务器，最好用同一种文件访问接口，不要同时通过 NFS 和 FTP 去操作同一个数据文件，否则容易出现读写不一致。这个提醒看起来像边角料，但在真实场景里很实用。

我自己更愿意把这类问题提前拎出来，因为很多“加载偶发失败”“同一批文件结果不一致”，最后不是数据库参数的问题，而是外围文件系统、网络路径、源文件生成流程不稳定。这个时候再去拧 PARALLEL 或者 MAX_DATA_PROCESSORS，基本都治不到根上。

真正到现场，我一般按这个顺序处理

下面这套顺序，不一定是唯一正确答案，但我自己用下来比较顺手：

配合命令行，我自己常用的巡检动作大概会这么写：

gccli -uroot -p'***' -e "SELECT * FROM information_schema.load_status;"
gccli -uroot -p'***' -e "SELECT * FROM information_schema.load_result ORDER BY task_id DESC LIMIT 10;"
ssh 198.51.100.18 "find /data/ods/ -type f | wc -l"
ssh 198.51.100.18 "find /data/ods/ -type f -name '*.gz' | wc -l"

这些动作都不花哨，但很适合先把问题定性。

收个尾

我自己最近再看 GBase 8a 的加载链路时，一个感觉很明显：大批量导入的稳定性，很多时候比单次峰值吞吐更重要。 峰值做高不难，难的是下一批、下下批、多个任务并发起来以后还能稳。

所以我更倾向于把 GBase 8a 的加载优化理解成三件事：

第一，把文件组织和任务类型分清楚，别拿大文件的思路去套小文件。
第二，把并行参数当成平衡器，不是油门，别指望一路加大就一定更快。
第三，把状态监控和结果复盘做细一点，这样问题才不会总在导入窗口里临时救火。

真正在生产里，能把这三件事做好，加载这块 usually 就不会再那么飘。

参考资料

[1] GBase 8a MPP Cluster 数据加载功能及性能调优介绍
https://www.gbase.cn/community/post/4649

[2] GBase 8a 集群加载数据LOAD的方法
https://www.gbase.cn/community/post/278

[3] 南大通用GBase 8a数据库数据加载功能及调优（一）
https://www.gbase.cn/news/3688