Arrow Flight SQL 是什么？为什么比 JDBC 拉大结果集快？
面试怎么回答
JDBC 拉大结果集慢，主要不是网络，而是格式转换：列存数据库要先列转行，逐行序列化，客户端逐行反序列化，到了 Pandas 又要行转列，而且结果通常从一个节点串行返回。Arrow Flight SQL 是基于 Arrow 列式格式和 gRPC 的 Flight 框架，再加上执行 SQL、取元数据等标准接口，相当于 Arrow 版的 JDBC。快在三点：端到端都是列式，服务端直接输出 Arrow，客户端直接给 Pandas、Polars 用，几乎没有转换；按批传输；执行后返回多个 Endpoint，可以从多个节点并行拉取。Python 用 ADBC 驱动，Java 有 Flight SQL 的 JDBC 驱动。适合大结果集导出、机器学习取数和系统间批量交换，小查询和事务场景 JDBC 就够了，用之前要确认数据库和工具的支持情况。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
数据科学和 AI 场景下，经常要从 Doris、StarRocks、Dremio 这类数据库里一次拉几百万到上亿行数据到 Python 里做分析或训练，用 JDBC / ODBC 慢得让人怀疑人生。Arrow Flight SQL 就是为此而生的协议，Doris、Dremio 等已经支持。面试官问这题，想看你懂不懂数据传输里的性能瓶颈到底在哪。
JDBC 拉大结果集为什么慢
以一个列存数据库为例，数据在内部本来是按列存的：
- 列转行：服务端要把列式数据转换成一行一行的结果；
- 逐行序列化：按 MySQL 协议或其他行式协议，一行一行编码发送；
- 逐行反序列化：客户端一行一行解析，再创建大量对象；
- 行转列：到了 Python 里，Pandas / Polars 又要把数据转回列式。
数据量一大，时间大部分花在格式转换和序列化上，而不是网络传输。而且结果集通常只能从一个连接、一个节点串行返回。
Arrow Flight SQL 怎么做
- Apache Arrow：一种标准的内存列式格式，各语言、各系统都能直接认；
- Arrow Flight：基于 gRPC 的高性能数据传输框架，直接传输 Arrow 格式的数据批（RecordBatch）；
- Flight SQL：在 Flight 之上定义了执行 SQL、获取元数据、预编译语句等标准接口，相当于「Arrow 版本的 JDBC 协议」。
为什么快：
- 端到端列式，几乎零转换：服务端内部的列式数据直接转成 Arrow 发出，客户端收到的就是 Arrow，Pandas / Polars 可以直接使用，省掉了列转行和行转列；
- 批量传输：一次传一大批数据，而不是一行一行；
- 并行拉取：执行查询后返回多个 Endpoint，客户端可以从多个节点并行拉取结果，而不是全部经过一个节点汇总。
官方和社区的测试中，大结果集的读取速度相比 MySQL 协议往往有数倍到数十倍的提升，具体取决于数据量、列类型和网络。
客户端怎么用
- Python 可以用 ADBC（Arrow Database Connectivity）的 Flight SQL 驱动，直接拿到 Arrow Table，再转 Pandas 或 Polars；
- Java 有 Flight SQL 的 JDBC 驱动，已有工具可以平滑接入；
- 服务端要单独开启 Flight SQL 端口，注意网络和权限配置。
适用场景和局限
- 适合：大结果集导出、数据科学和机器学习取数、数据库之间的大批量数据交换；
- 不适合也没必要：小查询、点查和事务型场景，JDBC 已经足够；
- 局限：不同数据库支持的程度和版本不同，部分 BI 工具还不支持；结果集太大时要注意客户端内存。