DuckDB 高效导入 IPv6 地址数据的实践与性能对比
使用 DuckDB 高效导入 IPv6 地址：从逐行插入到批量加载的性能对比
背景
在进行 IPv6 网络探测实验时，需要将一份包含超过 1 亿行 IPv6 地址的 .txt 文件导入本地数据库。初期采用了常规的 Python 逐行插入方法，但在处理大规模数据时效率极低。随后尝试使用 DuckDB 的原生批量导入机制，数据导入时间从数十小时缩短至数分钟，性能提升显著。
本文对这两种方法进行对比，提供推荐的高效加载方式，并解释其性能差异原因。
方法一：Python 逐行插入（低效）
最初使用如下方式逐行读取 .txt 文件并写入 DuckDB：
from tqdm import tqdmdef slow_load_hitlist(filepath, conn, source='hitlist'):with open(filepath, 'r') as f:for line in tqdm(f, desc="导入 IPv6 地址（逐行）"):ip = line.strip()if ':' in ip:conn.execute("""INSERT OR IGNORE INTO ip_addresses (ip, source)VALUES (?, ?);""", (ip, source))
特点
- 每次执行
conn.execute()会触发一轮 SQL 编译与执行； - DuckDB 的查询优化与批处理特性无法被利用；
- 实测处理速度约为 300 行/秒，处理一亿行约需 92 小时；
- 对于大规模导入任务，不具备实用性。
方法二：DuckDB 批量导入（推荐）
DuckDB 支持直接通过 SQL 语句读取 CSV 文件并以向量化方式批量处理数据，以下为推荐实现方式：
Step 1：读取文件为临时表
con.execute(f"""
CREATE OR REPLACE TEMP TABLE temp_hitlist AS
SELECT * FROM read_csv_auto('{filepath}',delim='\n',columns={{'ip': 'VARCHAR'}},header=False
);
""")
该语句将文本文件加载为临时表 temp_hitlist，每行作为一条 VARCHAR 类型的 ip 字段。
Step 2：插入主表并过滤非法格式
con.execute("""
INSERT INTO ip_addresses (ip)
SELECT DISTINCT ip FROM temp_hitlist
WHERE strpos(ip, ':') > 0;
""")
此语句对数据进行筛选（过滤掉不符合 IPv6 格式的地址），并去重后插入主表。
对比分析
| 项目 | Python 逐行插入 | DuckDB 批量导入 |
|---|---|---|
| 实现方式 | Python 循环，每行一条 SQL | SQL 批处理，读取整个文件为表 |
| DuckDB 引擎利用 | 否，主要工作由 Python 主导 | 是，执行计划由 DuckDB 优化器主导 |
| 数据处理速度 | 约 300 行/秒 | 约 5,000,000 行/秒（视磁盘/CPU 而定） |
| 预计处理时间（1 亿行） | 超过 90 小时 | 几分钟内完成 |
| 错误处理机制 | Python 端需自行 try/except 实现 | DuckDB 支持容错参数（如跳过非法行） |
| 代码简洁性与可维护性 | 操作冗长、调试困难 | SQL 简洁、逻辑清晰 |
性能提升原理分析
1. 执行模型差异
- 逐行插入：每条数据需单独构建 SQL 语句 → 编译 → 执行 → 写入日志，过程冗余；
- 批量导入：文件整体加载为表，DuckDB 可在内存中完成解析、筛选、插入的整个管道操作。
2. 内核优化差异
DuckDB 的执行引擎具备以下优势：
- 列式存储：适合大批量数据压缩与读取；
- 向量化执行：批量处理数据，提升 CPU 利用率；
- 零配置导入接口：
read_csv_auto()可自动识别格式，减少预处理负担； - 全表优化：DuckDB 优化器可整体处理 DISTINCT、WHERE 等操作，无需手动优化循环逻辑。
推荐使用场景与实践建议
该方案适用于如下场景：
- 本地或边缘设备中需高效处理大规模文本数据（如 IP 地址、日志、指标）；
- 使用 DuckDB 作为分析引擎进行数据预处理、清洗或探索；
- 对数据导入效率有明确要求，且不希望引入复杂 ETL 框架。
实践建议：
- 使用
read_csv_auto()可快速部署，若数据字段复杂可显式指定列名与类型； - 插入操作建议在筛选后进行（如
WHERE strpos(ip, ':') > 0）避免无效数据写入； - 可结合
read_parquet()读取压缩格式，进一步降低 I/O 成本； - 所有中间表建议使用
TEMP TABLE保持数据处理流程可复用且不污染主表空间。
总结
通过本次对比实验可得出结论：
DuckDB 原生批量导入机制在面对大规模结构化数据时具备显著优势，能够充分利用其列式存储与向量化执行引擎，实现数量级的性能提升。
在 IPv6 地址探测等大规模网络测量场景中，应优先采用批量 SQL 方案，避免传统逐行插入方法带来的性能瓶颈。