DeepSeek总结的数据库外部表

来源https://motherduck.com/blog/internal-vs-external-storage-whats-the-limit-of-external-tables/本文系统回顾了外部表External Tables25年来的发展历程、核心价值、适用场景及现代演进并给出了使用建议。外部表的核心概念与历史外部表是一种不存储在数据库内部、而是指向外部数据如CSV、Parquet、JSON等文件的表结构。用户通过DDL定义其结构后即可像查询普通表一样用SQL直接查询外部数据实现“数据原地访问无需迁移”。最早可追溯到1992年Microsoft Access的链接表2001年Oracle 9i正式引入外部表随后被IBM、SQL Server、Hive、Snowflake、BigQuery等广泛采用。其持久生命力源于“数据在哪里读哪里比移动它更高效”的基本原则。工作原理与类比外部表本质上是一个“指针”或“符号链接”指向外部存储如文件系统、S3、GCS。执行查询时数据库通过访问驱动如Oracle的ORACLE_LOADER读取外部文件并解析成表格形式。删除外部表仅删除元数据不影响原始数据。它与临时表的区别在于临时表是会话级、可写、快速但短暂外部表是持久元数据、只读、无限容量、成本优化。内部存储 vs. 外部表关键权衡维度内部存储外部表数据温度热数据频繁查询冷数据归档、偶尔查询典型场景仪表板、低延迟查询数据湖增强、一次性分析查询速度快毫秒级慢1.3~1.7倍但对冷数据可接受存储成本较高如Snowflake ~$23/TB/月极低S3 Glacier Deep Archive ~$1/TB/月数据新鲜度依赖ETL刷新可能滞后始终最新无需刷新运维负担可预测由仓库管理小文件问题、影响上游源系统结论高频、低延迟的“热”数据放在内部低频、归档、探索性的“冷”数据用外部表成本优势巨大。现代演进从CSV到湖仓一体外部表已从最初只能读CSV演进到支持Parquet、Avro、ORC等列式格式并融入开放表格式如Iceberg、Delta Lake、Hudi。这些格式提供ACID事务、时间旅行、模式演进等数据库特性使外部表成为湖仓架构的基石。DuckDB等新引擎甚至无需显式创建外部表通过read_parquet()、ATTACH等语法即可实现“零拷贝”外部查询。此外开放数据目录如INFORMATION_SCHEMA和ADBC列式API替代传统ODBC进一步降低了外部数据的连接和访问成本。性能基准与关键发现作者基于TPC-H SF1数据600万行进行测试内部DuckDB中位数23.8ms外部Parquet / DuckLake / Iceberg4156ms1.31.7倍开销冷数据场景每周查询一次差异可忽略存储压缩Parquet比DuckDB原生格式小40%元数据开销Iceberg在50次单行插入时产生352个文件DuckLake不产生数据文件行内嵌于目录避免了“小文件问题”流式负载查询快926倍。使用建议应该使用外部表的场景冷数据归档、一次性或低频分析希望利用廉价对象存储降低成本最高可节省20倍需要直接查询数据湖中的开放格式文件而不搬运数据结合物化视图或dbt如dbt-external-tables包使用不适合使用外部表的场景事务型OLTP负载每次查询都需要亚秒级延迟数据极小外部管理的开销超过加载收益最终结论外部表并非“过时技术”反而在湖仓一体时代重新成为核心模式。从最早读取CSV到如今支持ACID表格式其“数据原地访问”的本质始终未变。Lindy效应表明一项技术存在越久预计未来还能存在同样久。外部表已历经25年并不断被重写未来仍将长期活跃。正如作者所言“现代外部表已经不‘外部’了——它正重新成为数据库语义的一部分。”