用DuckDB直接查RustFS上的数据

AI 团队常见的一个割裂训练样本、特征表、推理结果都写进了对象存储数据以 Parquet 加 Iceberg 元数据的方式直接落在 S3 端点上而做分析的人不想写 Spark 作业只想SELECT一下看看分布于是把数据先拉到本地再开 pandas一来一回半天没了。DuckDB 正好补上这一段。它一个进程就是查询引擎httpfs扩展能把 S3 请求直接发到自建端点桶里的 Parquet 不用下载就能查iceberg扩展再顺着 Iceberg 元数据把整张表读出来。训练流水线写、分析师读共用同一个桶数据不用搬来搬去。下面把接自建 S3 端点的配置和几种查询姿势走一遍。httpfs 把 S3 端点变成查询目标核心是装httpfs、把 endpoint 指到存储的 9000 端口、用 path-style、内网 http 时关掉 SSLINSTALL httpfs;LOADhttpfs;SETs3_endpointrustfs:9000;SETs3_access_key_idaccess key;SETs3_secret_access_keysecret key;SETs3_regionus-east-1;-- region 参与签名计算自定义端点下无法自动推断-- 填一个与服务端一致的值即可SETs3_use_sslfalse;SETs3_url_stylepath;-- S3 兼容存储用 path-styles3_url_stylepath是接 S3 兼容存储最容易漏的一项AWS 默认走 virtual-hosted 风格把桶名拼进域名自建端点没有这套 DNS 解析路径式访问才对。配好这六行S3 上的文件就已经是可查的表了。默认的网络行为也值得知道一遍免得查询卡住时一脸茫然。httpfs 的这几个参数是全局的默认值是超时 30 秒、I/O 出错重试 3 次、重试间隔 100 毫秒起、按 4 倍指数退避SEThttp_timeout30;-- 单位秒读/写/连连接/重试都算SEThttp_retries3;SEThttp_retry_wait_ms100;SEThttp_retry_backoff4;-- 退避因子这套默认值对单次 GET 够用但一次查询要扫几百个文件时重试叠加会把慢查询拖成看起来没在动。内网自建端点通常比公网还快超时可以往下调、重试压到 1 到 2 次。写入侧另有并发上限s3_uploader_thread_limit默认 50传大文件分片上传时它就是那个并发旋钮。查 Parquet通配与分区目录-- 直接 SELECT 桶里的一个 ParquetSELECTCOUNT(*)ASrows,AVG(latency_ms)ASavg_latencyFROMread_parquet(s3://ai-lake/training-samples/2026-08/part-*.parquet);-- 多文件通配、Hive 分区目录都能扫SELECTdate,SUM(bytes)AStotalFROMread_parquet(s3://ai-lake/features/year2026/month08/*.parquet)GROUPBYdateORDERBYdate;read_parquet支持通配和 Hive 分区目录分区列会被自动识别成查询字段。对一次性探查、出个数、算个分布这类活比拉数据到本地快得多也省一份本地盘。查 Iceberg 表顺着元数据走Iceberg 表的数据是 Parquet元数据是桶里的metadata/*.metadata.json。装iceberg扩展把路径指向元数据文件整张表的当前视图就出来了INSTALL iceberg;LOADiceberg;-- 看表的清单文件与数据文件构成SELECT*FROMiceberg_metadata(s3://ai-lake/tables/samples/metadata/v1.metadata.json)LIMIT100;-- 读当前快照的数据SELECTproduct,COUNT(*)ASnFROMiceberg_scan(s3://ai-lake/tables/samples/metadata/v1.metadata.json)GROUPBYproduct;这里有一个官方文档写得明白、但很多人撞上才知道的边界iceberg 扩展默认要求元数据目录里有version-hint.text或者你在调用时显式传version参数两者都没有就直接报错。直接指定v1.metadata.json这样的具体文件路径可以绕开这个要求想让它自动猜最新版本得显式打开unsafe_enable_version_guessing官方注明这可能违反 ACID 约束探查场景再用。时序回溯也支持用iceberg_snapshots列出快照再给iceberg_scan传snapshot_from_id或snapshot_from_timestamp就能读历史时点的数据。两条路怎么选看你要的是读某张表还是用一套表。直接给iceberg_scan传metadata/vN.metadata.json本质是顺着文件路径读快照好处是任何能连 S3 的地方都能跑不依赖 catalog 服务探查、出数、生成报告这类一次性任务用它最轻代价是元数据版本得自己管表结构或数据布局变了要跟着改路径也拿不到按表名引用的便利。另一条路是 catalog 方式ATTACH ... (TYPE iceberg)挂一个 Iceberg REST catalog 之后表可以按catalog.schema.table引用写入、MERGE INTO这些操作也解锁多表统一元数据、多写手协作时省事代价是多一个要运维的服务探查小任务没必要为它增加复杂度。RustFS 1.0.0 起内置了 Apache Iceberg REST Catalog需要后者就走这条路配置细节见官方文档的 catalog 章节。边界与代价网络要通。DuckDB 在查询机执行得能访问存储的 9000 端口跨网段就在前面挂 TLS 反向代理把s3_use_ssl改true。大表走扫描不是传输。DuckDB 会下推过滤、只拉需要的列和行组但超大的 Iceberg 表做重 ETL 还是交给 Spark / Trino 这类引擎DuckDB 的位置是交互式探查和小到中型分析。内存花在查询机上。DuckDB 是进程内引擎查询跑在哪台机器上内存就吃在哪台机器上row group、中间结果、排序哈希都在本地memory_limit默认按系统可用内存的八成算。无过滤全表扫一张大 Iceberg 表查询机可能先撑到交换而不是先报内存错。交互式探查先加过滤、限制返回行数重活交给集群引擎。凭据走 IAM。给 DuckDB 用的 access key最好是权限收在ai-lake一个桶上的专用身份别拿管理员账号连查询端。元数据路径要对。iceberg_scan指向的是metadata/*.metadata.json或表目录不是随便一个数据文件路径写错会报找不到表。DuckDB 接 S3 兼容存储的全部秘密就是httpfs那六行设置加s3_url_stylepath剩下的是 SQL 功底。训练写入和分析读取共用同一个桶Lakehouse 的一份数据多处读在自建存储上也成立。RustFS 1.0.0 已于 2026 年 9 月 16 日 GA源码和 issue 在 github.com/rustfs/rustfsDuckDB 两个扩展的文档分别在 duckdb.org 的 httpfs 与 iceberg 章节。