AI那些趣事系列121：智能问数场景中使用ClickHouse处理离线3G大文件

01 背景介绍

之前在做智能问数智能体项目，输入是用户的问题和各类不同的数据源，这个数据源可能是JDBC这一类(包括PostGreSql、Mysql、Oracle、SQLServer)等，利用大模型的能力来生成SQL语句进行查询获得相关数据，输出就是用户问题对应的SQL语句、执行SQL语句查询的结果还有对应的推荐的图表。之前接触的数据源主要是JDBC这一类数据源，现在有个新的需求是支持2-3G离线CSV大文件。这种和之前的数据源有点不一样

02 业内如何实现离线大文件智能问答

调研到帆软已经有支持，所以主要做一个调研，看看帆软是如何实现的：

https://demo.fanruan.com/webroot/decision#/fanruanHome

帆软通过前端断点续传 + 后端异步解析 + 分布式存储 + 弹性计算 + 离线缓存的全链路架构，支撑 2-3G 级大文件的稳定上传、高效提取与离线分析，适配智能问数场景下的大规模数据处理需求。以下从核心流程、技术架构、关键模块、性能优化、安全与元数据管理、落地路径六方面完整拆解。

2.1 核心流程：大文件全链路处理

(1)前端上传（解决大文件传输稳定性）

分片上传 + 断点续传
- 前端将 2-3G 文件按 4-8MB 分片切割，生成唯一文件 ID 与分片索引。
- 支持暂停 / 续传：网络中断后，下次上传从已完成分片继续，避免全量重传。
- 进度实时反馈：前端展示上传进度、剩余时间、失败分片重试。
拖拽 / 批量上传 + 格式校验
- 支持 Excel、CSV、TXT、Parquet 等主流格式，前端预校验文件头、编码、大小上限。
- 批量上传时自动排队，控制并发数（默认 3-5 个），避免服务器压力过载。
上传状态管理
- 上传中、成功、失败、暂停状态可视化；失败分片自动重试 3 次，仍失败则标记并提示手动处理。

(2)后端接收与存储（解决大文件存储与可靠性）

分布式对象存储
- 上传文件不存本地磁盘，直接写入 MinIO分布式存储，支持水平扩展。
- 原始大文件：永久存于对象存储（S3/MinIO/HDFS），
- - 适合大文件
  - 无限扩容
  - 不占数据库资源
  - 支持分片上传、断点续传
  - 成本极低
- 解析后用于分析的数据：写入 ClickHouse/Doris/StarRocks 等 OLAP 引擎，供分析查询。
- - 为大数据分析、亿级秒查设计
  - 3GB CSV 导入：1～3 分钟
  - 聚合查询：100ms～1 秒
  - 完美支撑智能问数大模型
- 元数据：存于 MySQL/PostgreSQL，记录文件 ID、路径、字段信息等
- 按用户 / 任务 / 时间戳生成目录结构，文件元数据（ID、名称、大小、分片数、存储路径）存入 MySQL/PostgreSQL 元数据库。

这是帆软、阿里云、腾讯云、网易有数全部统一的架构。

分片合并与校验
- 所有分片上传完成后，后端按索引合并文件，生成 MD5/SHA256 校验码，确保文件完整性。
- 合并失败自动回滚，清理无效分片，释放存储资源。
临时存储 + 生命周期管理
- 大文件先存临时目录，解析成功后移入正式存储；7 天未解析自动清理，避免存储浪费。

其中大文件数据存储方案：

核心存储选型（官方推荐），帆软在 FineBI/FineReport 官方文档中，明确推荐大文件（含 2--3G 级上传文件）使用以下存储：

S3 兼容对象存储（首选，官方主推）

MinIO：开源、高性能、兼容 S3，适合自建私有化部署。

云厂商 S3 存储：阿里云 OSS、华为云 OBS、AWS S3 等。
HDFS（大数据场景）

用于超大规模数据、高并发、高可用的集群环境。

需安装「HDFS 资源仓库」插件。
NAS/NFS（文件共享场景）

适合集中管理、多节点共享访问。

参考文档：https://help.fanruan.com/finebi/doc-view-383

(3)数据提取与解析（解决大文件高效读取）

异步解析 + 任务队列
- 上传完成后，不阻塞前端，立即创建后台解析任务，放入消息队列（Kafka/RocketMQ）。
- 解析引擎（Java/Python）从队列消费任务，流式读取大文件，避免一次性加载到内存导致 OOM。
智能格式解析
- CSV/TXT
  
  ：按分隔符、编码（UTF-8/GBK）、换行符自动识别，支持自定义配置。
- Excel
  
  ：分 Sheet 解析，支持百万行级大 Excel，跳过空行 / 合并单元格，自动识别表头与字段类型。
- Parquet/ORC
  
  ：列式存储文件，按列批量读取，大幅提升解析速度。
元数据自动提取
- 解析时同步提取字段名、类型、长度、注释、样本数据，生成结构化元数据，供智能问数系统使用。将这些元数据拼接好提供给大模型作为上下文。
- 支持字段映射：自动匹配标准字段名，不一致时提示用户修正。

(3)数据预处理与落库（解决数据质量与查询效率）

流式清洗与转换
- 空值填充、异常值剔除、格式标准化（日期 / 数值 / 字符串）、去重、关联补全。
- 支持自定义清洗规则：通过可视化界面或 SQL 脚本配置，适配业务需求。
批量落库 + 分布式写入
- 清洗后数据按 1-5 万条批次，批量写入 ClickHouse、Doris、StarRocks 等 OLAP 引擎，或 Hive 数据仓库。
- 支持分区 / 分桶：按日期、用户、业务线分区，提升后续查询性能。
增量更新 + 去重
- 同一文件重复上传时，自动识别增量数据，仅更新新增 / 修改部分，避免全量重算。

(4)离线分析与查询（支撑智能问数）

多模式计算引擎
- 小数据（<1000 万行）
  
  ：内存计算（Spark SQL/Pandas），秒级响应。
- 大数据（>1000 万行）
  
  ：分布式计算（Spark/Flink），按分片并行处理，支撑 TB 级数据。
- 智能问数适配
  
  ：解析用户自然语言问题，生成 SQL，下发至计算引擎，返回结构化结果。
离线缓存 + 预计算
- 高频查询结果、指标、数据集预计算并缓存（Redis / 本地磁盘），下次查询直接命中，无需重算。
- 支持定时更新缓存：按天 / 小时刷新，保证数据新鲜度。
结果导出与可视化
- 分析结果支持导出为 CSV/Excel/Parquet，供用户下载；同时生成可视化图表（柱状 / 折线 / 饼图），辅助理解。

2.2 技术架构：分层解耦，支撑大规模处理

1.整体架构图（分层设计）

go 复制代码

用户前端（Web/后台）
        ↓
【上传层】自定义分片 + 断点续传（8~16M分片）
        ↓
API网关/权限校验 → 不落地应用服务器本地磁盘
        ↓
【原始文件存储层】MinIO/S3对象存储（存3G CSV原文件）
        ↓
消息队列Kafka/RabbitMQ（触发异步解析任务）
        ↓
【计算解析层】Spark/Dask/流式Python（逐块读CSV，不OOM）
        ↓
1.清洗/类型推断/字段脱敏/去重
2.自动提取数据表元信息（字段名、类型、样本、值域）
        ↓
【分析存储层】ClickHouse/Doris/StarRocks（列式OLAP，存明细分析数据）
        ↓
【元数据管理层】MySQL/PostgreSQL（只存文件&表元数据，不存二进制大文件）
        ↓
【智能问数核心】大模型NL2SQL → 读取元数据+生成可执行SQL → 查询OLAP → 返回可视化结果

2.核心组件分工

|-----|-------------------|----------------------|---------------------------------------|
| 层级 | 核心组件 | 功能 | 技术选型 |
| 前端层 | 大文件上传组件 | 分片、断点续传、进度展示 | Vue/React + WebUploader / 自定义分片逻辑 |
| 接入层 | API 网关 | 路由、限流、认证、日志 | Spring Cloud Gateway/Nginx |
| 任务层 | 消息队列、任务中心 | 异步解耦、任务调度、重试 | Kafka/RocketMQ + XXL-Job |
| 存储层 | 对象存储、元数据库、OLAP、缓存 | 文件存储、元数据管理、分析存储、结果缓存 | MinIO/S3 + MySQL + ClickHouse + Redis |
| 计算层 | 解析引擎、分布式计算 | 大文件解析、数据清洗、并行计算 | Java/Python + Spark/Flink |
| 应用层 | 智能问数引擎 | NL2SQL、查询优化、结果返回 | 大模型（如 Qwen）+ SQL 生成引擎 |

2.3 关键技术模块深度解析

1.大文件上传核心技术

分片上传协议
- 前端：File.slice() 切割文件，生成 fileId + chunkIndex 唯一标识。
- 后端：提供 initUpload（初始化，返回 fileId）、uploadChunk（上传分片）、mergeChunks（合并分片）三个接口。
断点续传实现
- 上传前调用 checkChunk 接口，查询已上传分片列表，前端跳过已完成分片。
- 本地存储（LocalStorage）记录上传进度，页面刷新后可恢复。
性能优化
- 并发控制：前端限制同时上传分片数（3-5），避免带宽抢占。
- 压缩传输：文本文件（CSV/TXT）前端 gzip 压缩，减少传输体积。

2.大文件解析引擎

流式解析
- 不加载整个文件到内存，按行 / 按块读取，内存占用控制在 100MB 以内。
- 示例：CSV 解析用 BufferedReader 逐行读取，Excel 用 Apache POI 的 SXSSF 模式（低内存）。
多线程并行解析
- 大文件按大小 / 行数切分，分配给多个线程并行解析，提升速度 3-5 倍。
错误容忍机制
- 解析出错时，记录错误行号与原因，跳过错误行继续解析，最终生成错误报告供用户修正。

3.分布式存储与计算

对象存储选型
- MinIO
  
  ：开源、高性能、兼容 S3 协议，适合中小规模部署。
- HDFS
  
  ：适合超大规模数据（TB/PB 级），与 Hadoop 生态无缝集成。
- 云存储
  
  ：阿里云 OSS、腾讯云 COS，无需自建，弹性扩展。
OLAP 引擎选型（分析核心）
- ClickHouse
  
  ：列式存储，单表亿级数据查询秒级响应，适合大文件分析。
- StarRocks/Doris
  
  ：支持高并发、实时更新，适配智能问数的交互式查询。
- Spark SQL
  
  ：灵活的分布式计算，支持复杂分析与自定义逻辑。

4.离线分析与缓存策略

多级缓存
- 一级缓存（内存）
  
  ：Redis 存储高频查询结果，过期时间 5-30 分钟。
- 二级缓存（磁盘）
  
  ：本地磁盘存储大结果集，过期时间 1-7 天。
预计算优化
- 针对智能问数高频问题（如 "销售额 Top10 产品""月度趋势"），提前预计算并存储结果。
- 数据更新时，增量刷新预计算结果，避免全量重算。

2.4 性能与稳定性保障

1.性能指标（2-3G 文件）

上传速度

：百兆带宽下，2G 文件约 3-5 分钟完成（含分片、合并）。
解析速度

：2G CSV（约 5000 万行），流式解析约 10-20 分钟。
查询速度

：亿级数据查询，ClickHouse 下 1-5 秒返回结果。

2.稳定性保障

重试机制

：上传 / 解析失败自动重试 3 次，仍失败则告警并记录日志。
限流熔断

：API 网关限制单用户上传并发数，防止服务器雪崩。
监控告警

：监控上传成功率、解析耗时、存储使用率、查询延迟，异常时邮件 / 短信告警。
高可用

：服务集群部署，无单点故障；存储多副本，数据不丢失。

2.5 安全与元数据管理

1.安全控制

认证授权

：用户登录后才可上传，按角色控制文件访问 / 分析权限。
数据加密

：传输用 HTTPS，存储文件加密，敏感字段脱敏。
审计日志

：记录所有上传、解析、查询、下载操作，可追溯帆软。

2.元数据管理（适配智能问数）

统一元数据中心
- 存储所有文件的元数据：ID、名称、大小、字段列表、类型、样本、创建时间、更新时间、存储路径、关联任务帆软。
- 支持元数据检索：按文件名、字段名、时间范围筛选，快速定位数据帆软。
元数据同步
- 文件解析 / 更新后，自动同步元数据至智能问数系统，确保大模型获取最新数据结构帆软。

2.6 落地路径：从 0 到 1 实现帆软式大文件处理

阶段 1：基础能力搭建

搭建前端分片上传组件，实现 2-3G 文件断点续传。
部署 MinIO 分布式存储，配置文件存储与生命周期。
开发后端上传接口（init/upload/merge），实现分片合并与校验。

阶段 2：解析与落库

开发流式解析引擎，支持 CSV/Excel/Parquet 格式，处理 2-3G 大文件。
集成消息队列（Kafka），实现异步解析与任务调度。
对接 ClickHouse，实现数据批量落库与分区存储。

阶段 3：离线分析与智能问数集成

开发分布式计算模块，支持亿级数据查询。
实现多级缓存与预计算，提升查询性能。
集成大模型，将文件元数据与分析能力接入智能问数系统，支持自然语言查询大文件数据。

阶段 4：优化与运维

性能调优：调整分片大小、并发数、批处理大小，提升上传 / 解析 / 查询速度。
监控告警：搭建 Prometheus + Grafana 监控体系，保障系统稳定。
功能扩展：支持更多文件格式、自定义清洗规则、增量更新等。

2.7 对比与借鉴：帆软方案的核心优势

全链路异步化

：上传、解析、分析全流程异步，不阻塞用户，提升体验。
流式处理

：大文件不加载内存，解决 OOM 问题，支撑 2-3G 甚至更大文件。
弹性架构

：存储与计算分离，可水平扩展，适配数据量增长。
智能适配

：自动识别格式、提取元数据，无缝对接智能问数系统帆软。

03 简化方案

业内主流方案整体来说相对比较复杂，对于我们最关注的也就是离线大文件如何存储和查询，帆软是讲**原文件放 MinIO，解析明细进 ClickHouse，元数据管在 MySQL，大模型靠元数据生成 SQL 查 OLAP。**这里涉及到的组件太多，需要MinIO、ClickHouse和MySQL等，整体来说非常复杂。主要适合：

多格式文件（Excel/JSON/PDF/ 图片）
数据脱敏、权限、版本管理
多引擎分析
海量用户并发

但是对应到我们实际的项目中，我们只需要对离线大CSV文件进行智能问数查询，所以为了后续更好的维护，我们思考使用更少的组件。对应我们的智能问数场景，其实可以只使用ClickHouse。相当于把离线大CSV文件存储到ClickHouse中，然后获取ClickHouse的元数据信息，用于大模型生成查询语句，最后直接去ClickHouse查询即可。

方案	极简方案	行业标准架构（帆软）
大文件存储	直接导入 ClickHouse	对象存储 (S3/MinIO) 永久存原文件
分析数据	ClickHouse（唯一存储）	ClickHouse/Doris
元数据	使用ClickHouse的元数据	MySQL/PG + 对象存储路径
开发量	极低（1-2 人天搞定）	高（分片上传、解析、调度、同步）
适用场景	智能问数、内部使用、快速上线	商用 BI 平台、多租户、全格式支持
3G CSV 导入	1~3 分钟（同行业水平）	1~3 分钟
查询速度	100ms~1s（完美支撑大模型）	100ms~1s

3.1 ClickHouse 处理 2-3G CSV 文件的真实能力

1. 导入性能

3GB CSV 文件

：普通服务器（8 核 16G）1～3 分钟完成导入
支持：本地文件上传、HTTP 上传、分片上传
支持：断点续传、错误重试、去重

2. 存储能力

3GB CSV 导入 ClickHouse 后，压缩后仅 300MB~800MB（列式存储 + 极致压缩）
单表支持百亿行无压力，远超过你的需求

3. 查询性能（完全适配智能问数）

简单查询：10ms~50ms
聚合 / 分组查询：50ms~500ms
大模型生成的自然语言转 SQL，延迟完全无感

3.2 极简方案完整架构图

go 复制代码

用户上传 2-3G CSV
       ↓
后端解析 → 直接在 ClickHouse 建表 + 导入数据
       ↓
用户提问（智能问数）
       ↓
后端**从 ClickHouse 实时查询表结构/字段信息**
       ↓
把「用户问题 + CK 表元数据」传给大模型
       ↓
大模型生成 ClickHouse 可执行 SQL
       ↓
直接去 ClickHouse 执行 → 返回结果

3.3 该方案的优点和缺点

1.优点（对你的项目非常友好）

开发极快

不用对接对象存储、不用做分片上传、不用做数据同步，直接入库直接查。
查询链路最短

大模型生成 SQL → 直接查 CK，无中间层，速度最快。
维护成本最低

只需要维护：ClickHouse + MySQL，没有其他组件。

2. 小局限

不保留原始 CSV 文件

导入 CK 后，原始文件丢弃。如果未来需要重新下载原始文件，就没有了。

→ 你的需求是数据分析，不是文件管理，完全不影响。
不支持非结构化 / 复杂格式

只支持 CSV/Excel 结构化数据。

→ 你的需求明确是 CSV，无影响。

3.4 详细实现

1.创建表 SQL

go 复制代码

-- 推荐使用MergeTree引擎（ClickHouse默认高性能引擎）
CREATE TABLE IF NOT EXISTS sample_data
(
    id UInt32,
    timestamp DateTime,
    value1 Float64,
    value2 Float64,
    value3 UInt32,
    category String,
    score UInt16,
    flag Boolean,
    description String
)
ENGINE = MergeTree
ORDER BY id  -- 按id排序，优化查询性能
PARTITION BY toYYYYMM(timestamp)  -- 按月份分区，大文件查询更快
SETTINGS index_granularity = 8192;

说明：

MergeTree 是 ClickHouse 的核心引擎，专为大数据分析设计，3GB 文件秒级导入

ORDER BY id 是排序键，优化按 id / 时间范围的查询

PARTITION BY 按月份分区，适合时间序列数据，大表查询性能提升 10 倍 +

类型选择：用最小的类型存储（如UInt16存 score，比Int32省一半空间）

2. 离线大CSV(2-3GB ) 导入 ClickHouse

本地文件导入：

go 复制代码

-- 直接从本地CSV文件导入，3GB文件1-3分钟完成
INSERT INTO sample_data
FROM INFILE '/path/to/your/large_file.csv'  -- 替换为你的CSV文件绝对路径
FORMAT CSV
WITH HEADER;  -- 表示CSV第一行是表头，自动跳过

WITH HEADER：必须加！因为你的 CSV 第一行是表头（id,timestamp...）

支持断点续传：如果导入中断，重新执行会自动跳过已导入数据（需开启input_format_csv_allow_skip_duplicates）

大文件优化：SET max_insert_block_size = 1048576;（分块导入，避免内存溢出）

HTTP 接口导入：

go 复制代码

# 用curl命令通过HTTP接口上传，适合3GB大文件分片上传
curl -X POST 'http://clickhouse-host:8123/?query=INSERT%20INTO%20sample_data%20FORMAT%20CSV%20WITH%20HEADER' \
  --data-binary @/path/to/your/large_file.csv \
  -H 'Content-Type: text/csv'

3.获取元数据信息

go 复制代码

SELECT 
  name AS 字段名, 
  type AS 字段类型, 
  comment AS 字段注释
FROM system.columns 
WHERE database = 'default' 
  AND table = '你上传的csv表名'

4.利用大模型生成SQL语句

go 复制代码

-- 示例：查询category为'D'，score>50的所有数据
SELECT id, timestamp, value1, value2, score, description
FROM sample_data
WHERE category = 'D' AND score > 50
LIMIT 100;

总结

对于算法测来说，我重点关注的是如何如何获取离线大文件的元数据信息，将用户问题和元数据信息等通过prompt工程调用大模型来生成可执行的SQL语句，从而进行查询。帆软等主流的方案是，对于3G 大文件，**原文件放 MinIO，解析明细进 ClickHouse，元数据管在 MySQL，大模型靠元数据生成 SQL 查 OLAP。**但是对于我们实际的应用场景来看，其实是需要使用ClickHouse组件就可以了，这个方案可以满足当前的应用场景，并且也比较简单容易实现，后期也易于维护。