数十年来，访问数据库的标准方式始终是 ODBC 和 JDBC。然而，在这些传统的面向行的连接标准，可能会成为高性能 Snowflake 客户端应用程序的瓶颈。在 Snowflake 某些要求最为严苛客户的延迟敏感型应用中，包括关键业务运营和 AI 用例，ODBC 和 JDBC 的速度实在过于缓慢。这正是 Snowflake 选择拥抱开源生态 Apache Arrow 与新一代 ADBC 连接标准的核心动因。
虽然 Snowflake 长期使用 Apache Arrow 列式格式来加速网络传输，但采用 ADBC 能使 Snowflake 客户消除客户端序列化和反序列化的开销，从而为大型结果集带来巨大的性能提升。在实践中，我们观察到使用 ADBC 相比 ODBC/JDBC 可实现 2 倍至 5 倍甚至 10 倍或更高的加速效果。
在 Build 2025 大会上，Apache Arrow PMC 成员、Columnar 联合创始人、Iceberg 项目提交者 Matt Topol 带来了一场高度工程化、干货满满的技术分享。他展示了使用多种语言（C、Go、Python、R）向 Snowflake 发起简单查询，包括使用数据框架甚至 DuckDB 等其他系统作为源，执行高效数据摄取到 Snowflake 的过程。重点将是如何轻松将 ADBC 集成到对毫秒级响应要求苛刻的应用中，以及如何利用 Snowflake 对 Apache Arrow 和 ADBC 的支持，为最关键的性能用例加速应用程序的速度。
从内存布局谈起：为什么 Apache Arrow 是关键前提
Topol 在分享一开始，并没有直接进入 ADBC，而是先用相当篇幅重新校准听众对 Apache Arrow 的理解。Arrow 并不是一个库或产品，而是一套列式、内存级的数据格式规范，其核心特征在于：内存中的数据布局，与网络传输时的字节布局完全一致。
这一设计带来的直接结果是，数据在系统之间流转时，可以绕过传统序列化与反序列化过程，直接传递原始字节。在同一进程内，甚至可以做到零拷贝或共享内存。这不是优化细节，而是从根本上改变了数据移动的成本结构。
更重要的是，Arrow 采用列式内存布局，使其天然适合向量化计算、聚合操作以及分析型工作负载。Topol 用“行式 vs 列式”的对比说明了一个事实：在分析场景下，行导向的内存访问意味着更多 I/O、更差的缓存命中率，以及无法充分利用 SIMD 等编译器优化；而列式内存恰恰相反，它与现代 CPU 架构是协同演进的。
ODBC / JDBC 的结构性矛盾
在此基础上，Topol 将问题指向了当前最主流的数据库连接方式——ODBC 与 JDBC。
它们的价值毋庸置疑：API 稳定、生态成熟、适用于事务型与逐行计算场景，并且在过去几十年中几乎成为数据库访问的事实标准。
但问题在于，这套接口体系本质上是行导向的。
而现实是，Snowflake、DuckDB、ClickHouse、BigQuery 等主流分析型数据库，内部早已全面列式化。这意味着，每一次通过 ODBC / JDBC 拉取数据，系统都要经历一次高成本的转置：从列式内存转换为行，再在下游分析中重新转回列式结构。这不仅带来了显著的 CPU 与内存开销，也让数据在系统中反复“变形”。
Topol 特别强调，这里的转置并不是抽象意义上的重排，而是真实的数据拷贝与类型转换。在数据规模扩大后，这种成本会呈指数级放大。
ADBC：把统一 API 的理念带入列式世界
ADBC（Arrow Database Connectivity）正是为解决这一结构性矛盾而设计的。
从抽象层面看，ADBC 与 ODBC / JDBC 非常相似：应用程序面对的是统一 API，通过不同驱动与不同数据库交互。但关键差异在于，ADBC 是列导向的，其数据交换格式直接采用 Apache Arrow。
当数据库本身已经以列式形式返回结果，且能够直接输出 Arrow 数据时，驱动几乎无需做任何转换，便可将结果原样交付给应用侧——零拷贝、无转置。这不仅显著提升了性能，也让数据在更早阶段就处于可分析、可计算的理想形态。
即便在数据库本身并非列式、或并未原生支持 Arrow 的情况下，ADBC 也允许在驱动层完成一次性转换，从而让应用侧始终面对统一的数据模型，而不必管理多套复杂连接器体系。
用数据说话：跨语言的性能对比与真实收益
这场分享的核心说服力，来自大量现场演示。
在 Python 示例中，Topol 对比了通过 ODBC 与 ADBC 从 Snowflake 拉取数据的耗时。即便在启用缓存、排除查询执行成本的情况下，ADBC 在 10 万行与 100 万行数据规模下，仍然表现出明显优势：数据量越大，性能差距越明显。
更关键的是，ADBC 返回的数据可以直接被 Polars 等基于 Arrow 的 DataFrame 库消费，几乎没有额外转换成本。这意味着，性能提升并不仅体现在拉数据更快，而是贯穿整个分析链路。
同样的结论，在 Go 和 R 的演示中得到了重复验证。跨语言的一致性，反过来也印证了 Arrow 与 ADBC 设计上的语言无关性——它们优化的是数据形态本身，而非某一语言生态的实现细节。
不止查询：流式摄取与系统间数据流动的新可能
在分享的后半段，Topol 将视角从查询结果返回扩展到更复杂的数据流动场景。
他展示了如何通过 ADBC，将 Snowflake 中的一百万行数据，以流式方式直接摄取到内存中的 DuckDB。整个过程无需先完整加载结果集，数据以 Arrow Record Batch 的形式持续流动，类型信息在传输过程中被完整保留，整体耗时不到四秒。
这一演示揭示了 ADBC 的另一层意义：它不仅是一种更快的查询接口，也是一种系统间高效、可组合的数据通道。当数据能够以统一、零拷贝的列式格式在系统间流动时，ETL、数据同步乃至多引擎协同分析的复杂度，都有机会被重新定义。
Topol 并没有在结尾试图宣告 ODBC / JDBC 的终结。相反，他反复强调，这些技术在事务型与行式计算场景中仍然合理且必要。但对于分析型系统而言，ADBC 所代表的，是一种更贴合现代数据架构的方向：让数据尽可能早地进入列式、分析友好的形态，并尽可能少地在系统间反复转换。
原视频地址：https://www.snowflake.com/en/build/americas/agenda/?login=ML
🔥【活动推荐】2 月 2 日-6 日，Snowflake Discover 重磅上线！这是一场免费、线上、可实时互动的技术活动，旨在帮助您全面提升数据与 AI 能力，深入了解如何更高效地管理、整合与分析数据。4 天时间 18 场技术干货分享，由来自亚太地区的一线技术专家亲自分享与讲解～
点击报名 Discover，更多 Snowflake 精彩活动请关注专区。
