Arrow 结果传输：如何启用、如何配置、哪些环节会变快¶
Dosi 可以用 Apache Arrow 传输查询结果。对于线上格式本来就是列式的引擎 （DuckDB、ClickHouse、StarRocks/Doris、Databricks），能做到端到端列式。 这一页是使用指南：要配置什么、要构建什么、哪些 API 会变快。背后的调研、 支持矩阵和推进计划见 design/arrow-adbc.md； 连接器的配置细节见 connectors.md。
0. 已锁定的范围（2026-07-12）¶
本轮支持 Arrow 通路的：DuckDB（第一优先级，内置 crate 的磁盘占用问题已解决）、
ClickHouse、StarRocks、Doris、Databricks。
Snowflake 与 BigQuery 合并成一个待办：两者都会走未来的通用 exec-adbc 通道。
它们的 ADBC 驱动由同一个组织（ADBC Driver Foundry）以 Go .so 的形式维护，
Snowflake 的已 Stable，BigQuery 的仍是 Experimental，所以只是在等 BigQuery。
Trino/MySQL/TiDB/Redshift：没有 Arrow 通路，已放弃。
它们的线上格式面向行，在客户端做一次列转置毫无收益。
1. 我需要改配置吗？¶
基本不用。 现有的连接配置文件原样继续可用；行通路在各处仍是默认，行为完全一致。
| 引擎 | 为启用 Arrow 需要的配置改动 |
|---|---|
| DuckDB | 无。进程内 Arrow 自动成为该引擎的原生通路 |
| ClickHouse | 无。还是那份 HTTP 配置，适配器会自己请求 FORMAT ArrowStream |
| Databricks | 除常规配置（host、warehouse、password: = PAT）外无需改动，该执行器从第一天起就是 Arrow 优先 |
| StarRocks | 加一个键：arrow_flight_port: 9408（FE 的 arrow_flight_port；需要 SR ≥ 3.5.1）。有这个键 = 走 Flight SQL；没有 = 完全和今天一样走 MySQL 协议 |
| Doris | 加一个键：arrow_flight_port: 8070（FE 的 arrow_flight_sql_port；建议 Doris ≥ 2.1.5）。同样的显式启用规则 |
示例：
datasources:
prod-sr:
type: starrocks
host: sr.internal
port: 9030 # MySQL-wire port, still used as fallback/seeding
arrow_flight_port: 9408 # presence opts this profile into Arrow Flight SQL
username: osi
password: ${SR_PASSWORD}
database: analytics
这里刻意没有 result_format: 这类开关：每个适配器只有一种原生解码方式，
而出口格式是按请求选择的（Accept 头／CLI 参数），不是按数据源选择的。
2. 构建时如何启用？¶
| Feature | 它开启了什么 | 在默认构建里？ |
|---|---|---|
exec-duckdb |
内置 libduckdb，进程内，原生 Arrow | 是（新的默认；--no-default-features = 今天那种通过 CLI 外调的精简构建） |
exec-http-arrow |
ClickHouse 的 FORMAT ArrowStream |
否（隐含 exec-http） |
exec-flightsql |
StarRocks/Doris 的 Arrow Flight SQL 客户端（tonic/tokio，按开关引入） | 否 |
exec-databricks |
Databricks Statement Execution API，INLINE JSON_ARRAY 行 | 否 |
exec-databricks-arrow |
Databricks 的 ARROW_STREAM + EXTERNAL_LINKS（arrow-ipc） |
否（隐含 exec-databricks） |
exec-all |
以上全部 | — |
dosi-server 的 arrow |
/v1/query/execute 上的 Arrow IPC 响应 |
是（服务端默认） |
3. 哪些 API 会变快，快多少？¶
POST /v1/query/execute且带Accept: application/vnd.apache.arrow.stream： 最大的收益点。批次从数仓适配器直接以 Arrow IPC 流进 HTTP body， 服务端不再逐值做 JSON 编码，客户端不再做 JSON 解析，列式消费方 （Polars/pandas/DataFusion/另一个 Dosi）零解析就能读。既有客户端拿到的 JSON 响应逐字节不变。收益随结果规模放大：10 行的聚合可以忽略不计， 高基数分组和明细／导出类查询（10⁵ 行以上）则是决定性的。dosi query --execute --format arrow：在 stdout 上给出 Arrow IPC， 可直接管进 DuckDB、Polars 或任何工具，完全跳过表格／JSON 渲染。- StarRocks/Doris 的大结果读取：Flight SQL 绕开了 FE 的行转发， 客户端并行地从各 BE 拉列式结果。厂商测得大结果集上相比 MySQL 协议有 20–160 倍差距；小聚合基本无变化。
- ClickHouse：服务端的 Arrow 序列化（lz4 分帧）取代了两端的 JSON 编解码， 也省掉了 float/decimal 的文本往返转换。
- DuckDB（默认引擎）：进程内零拷贝取代了"每次查询启一个 CLI + 解析 JSON"，
每一次
--execute的延迟都更低，内存数据库也终于能在一个会话的多条语句间 保持存在。 - 哪些不会变快：只做编译的 API（
/v1/query/compile、explain）根本不接触结果； 面向行协议的引擎（MySQL/TiDB/Postgres/Trino）上的小指标查询按设计就不变。
每条 Arrow 通路在发布前都要通过语料一致性校验：同样的 45 个用例， Arrow 结果 ≡ 行结果 ≡ DuckDB 参考结果。