Reprint Notice（转载提示）：本文转载自 https://lance.org/format/。 原文标题：Lance Format Specification。 原文语言：English。本文为中文翻译版本，并将规范下级文档链接改写为本站预留文章链接。Lance 格式规范 Lance 是一种 Lakehouse Format（湖仓格式），覆盖三个规范层：文件格式（file format）、表格式（table format）和目录规范（catalog spec）。理解湖仓技术栈 要理解 Lance 在数据生态中的位置，我们先看完整的湖仓技术栈。 现代湖仓架构通常包含六个相互区分的层次： Lakehouse 技术栈1. 对象存储（Object Store） 最底层是 对象存储。这类存储系统以对象为核心、层级结构相对简单，通常提供高耐久保障，并通过基于 HTTP 的协议进行数据传输。 典型系统包括 S3、GCS 和 Azure Blob Storage。2. 文件格式（File Format） 在存储层之上，文件格式定义了单个文件在磁盘上的组织方式。 Apache Parquet 等格式就在这一层工作，规定单文件内部结构、编码方式和压缩策略。3. 表格式（Table Format） 表格式这一层描述多个文件如何协同构成一张逻辑表。 现代表格式的关键价值，是通过事务提交与读隔离，让多写者、多读者能够安全地并发访问同一张表。 Iceberg、Lance 等主流开源表格式都通过 MVCC（多版本并发控制）实现这些能力：每次提交都会原子地产生一个新版本，所有版本形成该表可串行化的历史。 这也让时间旅行（time travel）以及模式演进（schema evolution）等能力更容易实现。4. 目录规范（Catalog Spec） 目录规范定义任意系统如何在存储中发现并管理一组表。 这是底层“存储与格式栈”和上层“服务与计算栈”的连接点。 表格式至少需要能列出所有可用表，并能描述、添加、删除表。 这是计算引擎构建连接器（connectors）的前提，连接器据此发现表并按对应格式执行操作。 历史上，Hive MetaStore 规范已足以支持包括 Delta Lake、Hudi、Paimon、Lance 在内的多数表格式。 Iceberg 则提供了自己的 Iceberg REST Catalog 规范。 从更上层看，Apache Polaris、Unity Catalog、Apache Gravitino 等项目通常还会扩展面向“表衍生对象”的规范， 例如视图、物化视图、用户自定义表函数，以及表操作中使用的对象（如 UDF、策略等）。 这也是“上下层交汇”的原因：目录服务通常既会提供格式侧的 catalog 规范接口，便于计算引擎对接， 也会提供自身 API 以支持更丰富的管理能力。 另外，目录规范和目录服务的一个重要差异在于：同一规范可以由多个厂商实现。 例如 Polaris REST 规范就有开源 Apache Polaris Server、Snowflake Horizon Catalog，以及 AWS Glue、Azure OneLake 等兼容实现。5. 目录服务（Catalog Service） 目录服务会实现一种或多种目录规范，提供表元数据，并可选提供持续后台维护能力（如压实、优化、索引更新）， 以保证表格式在生产环境中的性能稳定。 目录服务通常会同时实现多种规范，以支持不同表格式。 例如 Polaris、Unity、Gravitino 都支持 Iceberg REST Catalog 规范来服务 Iceberg 表，并提供各自通用表 API 来支持其他表格式。 由于表格式本身是静态规范，目录服务负责补足生产落地所需的“持续运维动作”。 这也常常是开源与商业化分野所在：开源项目通常聚焦元数据能力，商业方案则进一步提供自动维护等完整运维体验。 也有 Apache Amoro 这样的开源项目在补齐这类能力，提供兼顾元数据访问和持续优化的完整开源目录服务实现。6. 计算引擎（Compute Engine） 最后，计算引擎是执行者：它访问目录服务，利用其对文件格式、表格式和目录规范的认知， 来执行复杂数据工作流，包括 SQL 查询、分析计算、向量检索、全文检索和机器学习训练。 在计算引擎之上，可以构建面向分析、ML 与 AI 的各类上层应用。湖仓整体架构 在湖仓架构中，计算能力主要位于对象存储、目录服务和计算引擎。 中间三层（文件格式、表格式、目录规范）本质上是“规范”，不承担计算。 这种分层有助于实现可移植性与互操作性。理解 Lance 作为湖仓格式 Lance 横跨三个规范层：文件格式（File Format）：Lan…