活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式

# GBase 8a 加载失败后先把坏数据链路查完整

我最近看 GBase 8a 加载功能和调优资料时，注意到一个很容易被忽略的点：加载失败不只是 SQL 写错或者文件不可达，更多时候是“坏数据、加载参数、错误日志、任务结果”这几段信息没有串起来。现场里经常有人只截取一句 `Too many bad records`，然后让数据库侧给结论。其实这种报错只是结果，不是原因。

GBase 8a 的 `LOAD DATA INFILE` 能从 FTP、HTTP、HDFS、SFTP、本地文件等多种数据源拉取数据，也支持加载状态查询和错误数据溯源。能力比较全，但排障时如果没有固定顺序，就会在数据文件、分隔符、字符集、字段映射、加载节点之间来回跳。

我自己更倾向于把一次加载拆成四层：入口 SQL、数据文件、加载任务、错误溯源。只要这四层能串起来，多数加载失败都能定位到比较明确的位置。

## 加载失败不要先改 max_bad_records

很多现场处理坏数据的第一反应，是把 `MAX_BAD_RECORDS` 调大，让任务先过去。这种做法在补数压力很大的时候可以理解，但我不太建议把它当成常规方案。原因很简单：错误行被跳过以后，业务侧未必马上发现数据缺口，后续对账反而更麻烦。

我一般先区分三种加载失败。

| 失败类型 | 常见表现 | 优先排查点 | 处理倾向 |
| --- | --- | --- | --- |
| 数据源不可达 | 连接失败、登录失败、文件不存在 | URL、账号、端口、防火墙、文件路径 | 先验证数据源 |
| 格式不匹配 | 字段数不一致、日期转换失败、编码异常 | 分隔符、换行符、NULL 表达、字符集 | 先抽样校验文件 |
| 坏数据超限 | Too many bad records | 错误日志、源文件行号、字段映射 | 先定位坏行再决定是否放行 |

`MAX_BAD_RECORDS` 的价值在于给加载容忍度，不是替代数据质量治理。资料里提到，这个参数用于设定错误数据行数上限，0 表示只要存在错误数据就报错退出，加载任务自动回滚。我在生产环境里更常用两套值：联调和验收阶段设小一点，正式增量任务根据源系统质量设置可接受上限，并把跳过行数写入作业审计。

```sql
LOAD DATA INFILE 'sftp://etl_user:******@192.168.50.21/data/order_20260512.csv'
INTO TABLE dw_ods.ods_order
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
MAX_BAD_RECORDS 0;
```

如果这是第一次接入某个源系统，我会坚持先用 `MAX_BAD_RECORDS 0` 跑一轮。它看起来严格，但能最快暴露字段格式和脏数据问题。

## 先拿到 task_id 再谈溯源

GBase 8a 的加载任务有自己的任务编号。很多排障记录只有 SQL，没有 task_id，后面查日志会很费劲。执行加载以后，我会第一时间保存任务 ID、成功行数、跳过行数、开始结束时间、发起 coordinator。

如果是会话内执行，可以结合变量和信息表查看。

```sql
-- 当前会话最近一次加载任务编号
SELECT @@gbase_loader_last_task_id;

-- 正在运行的加载任务
SELECT *
FROM information_schema.load_status;

-- 当前 coordinator 上的加载结果
SELECT *
FROM information_schema.load_result
ORDER BY start_time DESC
LIMIT 10;

-- 所有 coordinator 上的加载结果
SELECT *
FROM information_schema.cluster_load_result
ORDER BY start_time DESC
LIMIT 20;
```

我会把这些信息落到运维表里，避免作业平台、数据库、文件服务器三边对不上。

```sql
CREATE TABLE IF NOT EXISTS ops_load_audit (
    biz_date        date,
    target_table    varchar(128),
    load_task_id    bigint,
    source_uri      varchar(512),
    start_time      datetime,
    end_time        datetime,
    status          varchar(32),
    success_rows    bigint,
    skipped_rows    bigint,
    remark          varchar(512)
);
```

这个表不复杂，但对后面复盘很有用。特别是跨部门排查时，能明确某一天某个文件到底是全部入库、部分跳过，还是回滚失败。

## 错误日志要和源文件行号绑定

GBase 8a 支持加载错误数据溯源，这个能力我觉得要用起来。只看最终报错，最多知道坏数据太多；能看到错误行、字段位置、源文件路径，才有可能判断是源系统导出问题，还是目标表设计和加载参数问题。

常用查看方式如下。

```sql
-- 查看某个任务的错误数据，limit 从第 1 条开始取 20 条
SHOW LOAD LOGS 18273645 LIMIT 1,20;

-- 查看集群所有 coordinator 维度的加载错误
SHOW GCLUSTER LOAD LOGS 18273645;
```

我在现场会要求错误日志至少保留以下几类信息：

| 信息 | 用途 |
| --- | --- |
| task_id | 关联加载结果和作业平台记录 |
| source_file | 定位具体源文件 |
| line_no | 让源系统能复现那一行 |
| raw_record | 判断字段数、引号、转义、换行 |
| error_reason | 判断是格式、类型、长度还是约束问题 |
| node/coordinator | 判断是否和加载节点有关 |

如果开启了错误日志汇总，可以把错误数据与溯源信息集中到加载发起节点，便于统一查看。相反，如果关闭汇总，错误日志可能分散在加载节点上，排查时就需要同步确认日志所在位置。

```sql
-- 示例：会话级开启错误日志汇总，目录根据现场规范指定
SET gbase_loader_logs_collect = ON;
SET gbase_loader_logs_dir = '/data/gbase/load_error/ods_order';
```

目录不要随便写到系统盘。坏数据很多时，错误日志本身也会增长，日志目录要纳入清理策略。

## 几类坏数据我会分开处理

加载失败时，最容易混在一起的是“格式坏”和“业务坏”。格式坏一般是数据库无法解析，比如列数不一致、日期非法、字符串没闭合；业务坏是能解析但不符合约束或规则，比如金额为负、状态码不存在。这两类要分开治理。

| 坏数据类型 | 示例 | 数据库侧处理 | 源头处理 |
| --- | --- | --- | --- |
| 字段数不一致 | 多一个逗号或少一个字段 | 调整分隔符、引号、转义参数 | 修复导出程序 |
| 日期非法 | `2026-02-31` | 暂存为字符串后清洗，或直接拒绝 | 修复源字段规则 |
| 字符集问题 | 中文乱码、非法字节 | 检查加载字符集参数 | 统一文件编码 |
| 长度超限 | varchar 字段截断失败 | 评估字段长度是否合理 | 修正异常值 |
| NULL 表达差异 | 空串、`\N`、`NULL` 混用 | 明确 null_value 或预处理 | 统一导出约定 |

我更倾向于先加载到“接入暂存表”，再做类型转换和业务校验。特别是第一次迁入或新接口上线，不要直接把外部文件灌进核心明细表。暂存表字段可以先按字符串接住，后面用 SQL 把错误分类打出来。

```sql
CREATE TABLE ods_stage_order_raw (
    order_id_raw       varchar(64),
    user_id_raw        varchar(64),
    order_time_raw     varchar(64),
    amount_raw         varchar(64),
    status_raw         varchar(32),
    src_file           varchar(256),
    load_batch_no      varchar(64)
);

-- 暂存表加载，先降低类型转换失败的影响
LOAD DATA INFILE 'sftp://etl_user:******@192.168.50.21/data/order_*.csv'
INTO TABLE dw_stage.ods_stage_order_raw
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
MAX_BAD_RECORDS 10;
```

后续清洗时再把问题分门别类。

```sql
-- 日期不合法
SELECT order_id_raw, order_time_raw
FROM dw_stage.ods_stage_order_raw
WHERE order_time_raw IS NULL
   OR order_time_raw = ''
   OR order_time_raw NOT REGEXP '^[0-9]{4}-[0-9]{2}-[0-9]{2} ';

-- 金额不是数字
SELECT order_id_raw, amount_raw
FROM dw_stage.ods_stage_order_raw
WHERE amount_raw NOT REGEXP '^-?[0-9]+(\\.[0-9]+)?$';
```

这样做会多一步，但换来的是错误可解释。真正落到现场时，可解释比“硬加载成功”更重要。

## 小文件多时先看加载节点和连接复用

加载坏数据之外，还有一类问题是任务没报格式错，但耗时明显不稳定。GBase 8a 的加载能力可以随着集群规模扩展提升，也有加载节点选择和负载均衡参数。资料里提到 `gcluster_loader_max_data_processors` 和 `gcluster_load_rebalance_seed` 这类参数，我一般不会直接照搬某个值，而是先看文件数量、文件大小、并发作业数。

| 场景 | 现象 | 调整方向 |
| --- | --- | --- |
| 少量大文件 | 单任务跑很久，网络持续占用 | 增加并行加载能力，确认带宽 |
| 大量小文件 | 建连和调度开销明显 | 合并文件或使用通配方式 |
| 多任务并发 | 部分节点任务堆积 | 调整加载节点选择范围 |
| 数据源较慢 | 数据库侧等待文件服务 | 先压测 FTP/SFTP/HTTP 服务 |

示例参数我会写在作业配置里，便于回滚。

```sql
LOAD DATA INFILE 'http://192.168.50.30/data/ods_order/20260512/*.csv.gz'
INTO TABLE dw_ods.ods_order
DATA_FORMAT 3
MAX_DATA_PROCESSORS 6
MAX_BAD_RECORDS 100;
```

这里的 `MAX_DATA_PROCESSORS` 不要盲目加大。加载会占用网络、CPU、内存和磁盘写入能力，和白天报表查询混跑时，参数过高反而会把集群资源压紧。

## 一套我常用的加载排障记录

为了避免每次都从聊天记录里翻截图，我会把加载排障记录按下面格式留存。

```text
加载日期：2026-05-12
目标表：dw_ods.ods_order
源文件：sftp://192.168.50.21/data/order_20260512.csv
加载SQL版本：v20260512_01
task_id：18273645
成功行数：9987321
跳过行数：17
失败原因：17行日期字段非法，其中15行为2026-02-31，2行为字段错位
处理结果：源系统重出文件，数据库保留原始错误日志
复核SQL：select count(*) from dw_ods.ods_order where biz_date='2026-05-12';
```

这类记录看起来偏流程，但对稳定性很有帮助。加载链路牵涉源系统、文件服务器、调度平台、数据库集群，越是跨系统，越需要把证据链写完整。

## 小结

GBase 8a 加载失败的处理，不建议只盯最后一行报错。我的习惯是先拿 task_id，再查 load_status/load_result/cluster_load_result，再看错误日志和源文件行号，最后才决定是否调整 `MAX_BAD_RECORDS` 或并行加载参数。

坏数据不是数据库单点问题，数据库侧能做的是把错误定位得足够清楚，让源头修复有依据。只要把加载任务、错误溯源、作业审计这几层打通，加载失败就不会变成每次都靠经验猜。

## 参考资料

```text
南大通用GBase 8a数据库数据加载功能及调优（二） https://www.gbase.cn/news/3689
南大通用GBase 8a MPP Cluster数据迁移介绍 https://www.gbase.cn/community/post/4463
南大通用GBase 8a集群加载数据LOAD的方法 https://www.gbase8.cn/121
南大通用GBase 8a加载LOAD报错Too many bad records原因 https://www.gbase8.cn/1098
```





GBase 8a 加载失败后先把坏数据链路查完整

GBase 8a 加载失败后先把坏数据链路查完整

评论

热门帖子