你收到一批云端数据，往往还会同时收到一串文件地址，以及一份“该用哪些列、怎样拼表、哪些记录要过滤”的说明。数据没有搬家，使用方法却散落在聊天记录和文档里。DuckDB 官方博客介绍了一种很轻的整理办法：把这些规则装进一个 DuckDB 文件，再把真正的大表留在原处。分享数据时，发一个目录文件即可。
这里的“空库”并不是空文件。它仍保存数据库元数据和视图定义，只是不保存被查询的数据行。本文的数字和效果均来自 DuckDB 官方博客这一处信源，尚无独立交叉验证。
不搬仓库，只发目录
DuckDB 是一种面向分析查询的嵌入式数据库——它通常直接运行在电脑或应用里，不要求团队另外维护一台数据库服务器。
传统数据库表会把数据行存进数据库文件。视图则不同：视图是保存好的查询定义，本身可以不存数据。等用户查询视图时，DuckDB 才执行其中的查询，返回当时读到的结果。
这就像给仓库做一本目录。目录里写着“列车服务数据在哪里、该显示哪些字段、字段叫什么”，货物仍留在仓库。这里的“货物”可以是 Parquet 文件。Parquet 是按列保存数据的文件格式，查询通常只需读取所用的列；数据团队常把它放在对象存储中。对象存储则是按对象保存文件的云存储，Amazon S3 是常见例子。
官方示例先安装 httpfs 扩展，让 DuckDB 能通过网络读取远程 Parquet。随后创建一个持久化数据库文件，并在其中定义视图：
ATTACH 'rail_catalog.duckdb' AS rail;
USE rail;
CREATE VIEW services AS
SELECT * FROM 'https://blobs.duckdb.org/train_services.parquet';
services 看起来像一张可查询的表，实际只保存了查询文本。每次查询，它都会去读取远程文件。官方示例中的 train_services.parquet 有 380,959 行，而引用它的目录文件只有几百 KB。
这个数字不能泛化成“所有此类文件都只有几百 KB”。目录仍会随着视图数量、定义长度和其他元数据变化。更准确的说法是：只保存视图定义时，目录大小原则上不会跟着底层数据行数增长。
真正有用的是那层翻译
如果它只是把一个网址换成一个表名，价值还不算大。关键在于，视图可以把连接、过滤和列名规则一起固定下来，形成一层“语义层”——也就是把原始文件翻译成使用者真正要查的数据入口。
例如，发布者可以把多个文件拼成一个名为 services 的关系。这里的“关系”可以简单理解为一张可查询的表。使用者只需查询 rail.services，不必知道背后有多少文件，也不必记住每个文件的位置。
视图还能隔开数据的物理布局和用户的查询方式。假设原来只有一个 Parquet 文件，后来改成按年份拆分。发布者只要修改目录里的视图，让它读取整组文件；使用者仍查询同一个名字。若新文件把 station_name 改成 station，视图也可以在输出时映射回旧列名，让已有查询继续工作。
换句话说，目录文件不只是地址簿，也是适配层。底层文件可以重新分区、改名或迁移，面向使用者的入口则尽量保持稳定。
为什么值得现在看
这种做法把“共享数据”拆成两件事：大体量数据继续留在对象存储，轻量的组织规则则进入一个可以分发和版本管理的 DuckDB 文件。团队不必为了建立统一入口，再复制一份底层数据。
它也让目录本身变得具体。过去，一套数据的使用约定可能写在说明文档里；现在，连接、过滤和列名可以直接成为可执行的视图定义。接收者拿到的不是一份“请照着操作”的说明，而是一组已经命名、可以直接查询的入口。
视图查询时会重新执行查询，因此稳定地址所指向的远程内容更新后，结果可以反映当时读到的数据。但这不等于系统会自动发现任意版本变化。地址是否稳定、对象如何更新、缓存和访问权限，都会影响所谓的“当前结果”。
还有一个容易忽略的工程细节：视图里应使用完整的远程 URL 或绝对路径。否则，同一份目录在不同电脑上打开时，可能因为当前工作目录不同而指向不同位置。
局限与未知
- 使用者必须同时有权读取目录文件和视图引用的所有数据源。实际运行通常还涉及扩展加载、网络连通、凭据和远程文件可用性。
- 远程查询的速度取决于网络和文件布局。DuckDB 可以只读取查询所需的列和行组，但这不意味着远程查询没有传输与延迟成本。
- 官方博客只给出一个 380,959 行、目录为几百 KB 的示例，未披露具体目录大小、DuckDB 版本、平台和完整建库过程，因此不能据此推断所有场景的文件体积与性能。
这套做法没有发明新的存储系统。它做的是一件更朴素的事：把散落在云端的文件，包装成一套有名字、有规则、能共享的查询入口。所谓 DuckDB“空库”，空的是数据行，不是组织能力。