作者：

吴刚，Apache Parquet/Arrow/ORC PMC member，Apache Iceberg Committer，iceberg-cpp 项目发起人和核心维护者

邹泽桦，Apache Arrow Committer，Parquet/Iceberg 等项目的活跃贡献者

本文整理自 Community Over Code 大会上的主题分享《Is Parquet Dead? The Evolution of a Columnar Giant in the AI Era》。

我们在参与 Parquet、Arrow 和 Iceberg 社区讨论时，经常会被问到一个问题：Parquet 是不是已经老了？甚至，它是不是快要死了？

这个问题并非空穴来风。

Parquet 诞生于十多年前。它成长于 HDD、Hadoop 和长时间批处理查询占据主流的时代；而今天的数据基础设施已经全面进入 NVMe、100GbE 网络和 GPU 加速的时代，工作负载也从以 SQL 扫描为主，扩展到向量检索、RAG、多模态数据、超宽特征表和低延迟点查。

与此同时，Lance、Vortex、Nimble、FastLanes、BtrBlocks 等新格式和研究项目不断出现。它们带着更激进的编码方式、更轻量的元数据、更灵活的随机访问能力，以及面向 AI 负载重新设计的数据布局，对 Parquet 发起了挑战。

如果只看这些变化，Parquet 确实像一个背着历史包袱的“列式巨人”。

但我们的判断恰恰相反：Parquet 并没有死。真正发生的事情是，新的硬件和负载正在迫使它完成诞生以来最重要的一次进化。

对我们来说，这不是一个旁观者的问题。我所在的团队从一开始就把 Apache Iceberg 和 Apache Parquet 作为 Lakehouse 的开放存储底座；我也长期参与这些社区的规范、实现和兼容性讨论。使用 Parquet 与参与 Parquet 的演进，本来就是同一件事的两面。

Parquet 今天的核心价值，已经不只是某一种编码算法或者某一项性能指标。经过十多年的发展，它已经成为开放数据生态的共享互操作层：上层连接 Iceberg、Hudi、Delta Lake 等表格式，下层连接对象存储和新一代硬件，横向服务 Spark、Trino、DuckDB、ClickHouse 以及越来越多的原生计算引擎。

一个成为行业标准的格式，不能像初创项目一样推倒重来。它必须一边解决历史问题，一边保持数以 EB 计的数据和大量既有引擎仍然可读。这也是理解 Parquet 演进的关键：它不是站着不动，而是在兼容性约束下谨慎地向前走。

我们把这轮演进概括为三个方向：更快（Faster）、更广（Broader）和可演进（Evolvable）。

图 1：Parquet 的设计起点与今天的硬件、工作负载变化。

Parquet 为什么赢，又为什么开始显老

Parquet 的故事始于 2010 年 Google 发表的 Dremel 论文。2011 至 2012 年，Twitter 为了解决大规模分析的高成本问题开发了 Red Elm 原型，随后与 Cloudera 合作，正式形成 Parquet 项目。2013 年，Parquet 1.0.0 发布；2015 年，项目成为 Apache 顶级项目。

Parquet 能够胜出，并不是因为它在每一个局部指标上都做到了最好，而是因为它抓住了开放数据生态最重要的需求：用一种跨语言、跨引擎的数据表示，把存储和计算连接起来。

它支持 Avro、Thrift、Protocol Buffers 等不同对象模型，先后被 Spark、Presto、Drill 等主流引擎采用。2016 年以后，Parquet 与 Arrow 分别成为磁盘和内存中的列式标准，二者实现了自然衔接。到了湖仓时代，Iceberg、Delta Lake 和 Hudi 又共同选择 Parquet 作为主要的数据文件格式。

这种广泛采用，最终形成了 Parquet 最深的护城河：数据不再被某一个引擎或厂商独占，同一份文件可以被不同计算框架读取和处理。

在云器科技（Singdata），我们选择 Parquet，正是因为不希望增量计算建立在一套只能被单一引擎理解的私有格式之上。云器团队目前在 Apache Arrow 贡献超过 200 个 Commit，在 Apache Parquet 贡献超过 90 个 Commit；我们主导的 iceberg-cpp 项目，约一半的贡献来自云器工程师。

但当年的正确设计，不一定能够天然适应今天的硬件和负载。

Parquet 最初针对机械硬盘优化，强调顺序读，并通过较大的 Page 和 Row Group 摊薄高延迟网络与磁盘访问成本。它面向的是长时间运行的 MapReduce 和批量 SQL 扫描，而不是今天的高并发点查、向量检索和多模态数据访问。

环境已经发生了根本变化：

• NVMe SSD 可以提供海量并行 I/O 和超过 85 万 IOPS 的吞吐；

• 100GbE 网络让云原生存算分离获得了更高带宽；

• GPU 能够直接对数据执行大规模并行计算；

• AI 负载带来了数千乃至数万列的特征表、固定维度向量和大量图片、音频、文档等非结构化对象。

在这种环境下，Parquet 暴露出了五类典型问题。

第一，CPU 开销过高 。传统的 Snappy、Zstd 等块压缩需要先完整解压，再进入计算。在 NVMe 和高速网络环境中，数据可能已经到达，CPU 却还在忙着解码，最终带宽没有成为瓶颈，CPU 反而先被打满。

第二，读取放大 。Parquet 的最小读取粒度通常是 Page，常见大小可达到 1MB 左右。为了点查一条记录，系统可能需要读取并解压整个 Page，这与低延迟随机访问的目标天然冲突。

第三，元数据膨胀 。AI 特征表往往拥有数千甚至数万列。Parquet 的 Thrift Footer 是一个整体，读取少量列时仍可能需要解析庞大的元数据树，Footer 本身的加载和反序列化成本变得不可忽略。

第四，硬件流水线不够友好 。部分可变长度编码带有严格的数据依赖，难以充分利用 SIMD 和 GPU 的并行能力。

第五，现代数据类型缺口 。传统 Parquet 并未原生面向高维向量索引和多模态对象设计，在向量、半结构化数据、地理空间数据和非结构化文件等场景中，需要新的类型表达和生态协同。

这些问题给了新格式机会，也为 Parquet 指出了下一步的方向。

挑战者提供了新的参照系

近几年出现的新格式和研究项目，值得 Parquet 社区认真研究。它们未必都会成为下一代统一标准，但它们清晰地揭示了传统列式存储需要补齐的能力。

Lance 面向 AI 与多模态场景，采用自适应编码，放弃传统的文件级 Row Group，并通过 4KB 至 8KB 的 Miniblock 平衡扫描与点查性能。它原生集成 IVF-PQ、HNSW 和 BM25 等索引，同时支持图片、视频等大对象的延迟加载。对持续增加特征列的场景，Lance 还强调按列独立演进，避免反复重写历史数据。

Vortex 则把“在压缩数据上直接计算”推到了更激进的位置。它通过代价模型为不同数据分布叠加 Dictionary、RLE、Frame-of-Reference、Bit-packing、Delta 等轻量编码，并大量吸收 FastLanes、ALP、BtrBlocks、FSST 等研究成果。配合原生 mmap 和零拷贝设计，查询引擎可以尽量避免反序列化和无效的数据搬运。

FastLanes 试图通过统一转置布局打破解码过程中的数据依赖，让编译器能够更自然地利用 SIMD 和 GPU。Nimble 面向数万列的机器学习特征表，用 FlatBuffers 替代传统 Thrift 元数据，并通过合并读取多个特征列提高训练吞吐。BtrBlocks 证明，在 NVMe 和 100GbE 时代，轻量编码级联可能比重型块压缩更符合现代硬件。F3 更进一步，将文件视为“运行时契约”，甚至提出在文件中嵌入 WebAssembly 解码器，以解决格式升级带来的前后兼容问题。

这些方案看起来非常不同，但它们共同传递了几个信号：

1. 元数据必须支持更快的随机访问，而不是每次完整解析；

2. 编码必须理解数据类型和分布，而不是对所有数据统一套一层重型压缩；

3. 文件格式需要为 SIMD、GPU 和高并发 I/O 提供足够的并行度；

4. AI 数据不应继续被勉强塞进为传统关系数据设计的抽象中；

5. 格式必须具备持续演进能力，同时维持跨引擎兼容。

因此，这些挑战者更像是一组压力测试，帮助 Parquet 看清下一步该往哪里走。Parquet 不需要照搬某一个新格式，但必须吸收其中已经被证明有效的思想。

先解决 Footer 的“解析税”

几乎每一次 Parquet 读取，都从 Footer 开始。Schema、Row Group、Column Chunk 和统计信息都存放在这里。

在列数和 Row Group 数量较少时，这套设计没有明显问题。但在超宽表中，Thrift Compact Protocol 的顺序、可变长编码会形成一个典型的 O(C × R) 解析陷阱，其中 C 是列数，R 是 Row Group 数量。即使查询只需要一列，Reader 也可能需要扫描并物化完整的元数据树。

更糟糕的是，Footer 中还存在大量重复信息。以 path_in_schema 为例，在极端宽表中，它可能占据 Footer 体积的一半以上。针对 10 万字符串列、20 个 Row Group 的测试，使用生成的 Thrift 代码解析元数据需要约 3380ms；经过 arrow-rs 的定制优化后，可以下降到约 1016ms；进一步去掉统计信息后约为 367ms。这个结果说明，代码层面的优化虽然有效，但很快就会碰到协议本身的天花板。

社区正在讨论用 FlatBuffers 为 Footer 建立一条新的快速路径。核心思路不是直接废弃 Thrift，而是采用双轨兼容方案：Writer 仍然生成包含 Thrift Footer 的标准 Parquet 文件，同时把 FlatBuffer 元数据写入一个保留字段；旧 Reader 会安全忽略未知字段，新 Reader 识别特定 UUID 后，直接进入 FlatBuffer 的随机访问路径。

这种设计非常符合 Parquet 的演进哲学：新能力不能以破坏旧生态为代价。

在 Databricks 的一组包含 2.9 万列、78 个 Row Group 的生产案例中，新的元数据表示将 Footer 从 367MB 压缩到约 50.4MB，体积减少约 86%，解析速度提升约 40 倍。这里需要特别说明，40 倍是未叠加压缩时的读取对比；即使再叠加 LZ4，FlatBuffers 的解析路径仍然快于原来的 Thrift 路径。它解决的不只是“序列化换一种协议”，而是让 Reader 能够从完整物化转向按需访问。

如果这条路线最终成熟，Parquet 在超宽表上的元数据瓶颈将得到根本缓解。

图 2：通过保留字段写入 FlatBuffers 元数据，旧 Reader 继续读取 Thrift，新 Reader 走随机访问路径。

从通用压缩走向数据感知编码

随着 I/O 速度不断提升，传统编码和解码的 CPU 成本正在成为新的关键瓶颈。下一代 Parquet 编码不能只问“压缩率有多高”，还要问“解码需要多少指令”“能否并行”“能否直接在编码数据上执行过滤和聚合”。

目前社区正在讨论的编码方向很多，这里只挑 ALP 和 FSST 两个说明。

ALP 面向 FLOAT 和 DOUBLE。现实中的浮点列经常保存价格、评分、遥测值、坐标和指标，这些数据虽然以浮点数表示，却具有明显的十进制特征。ALP 会识别这类数值，在保证无损往返的前提下将其缩放为整数，再使用 Frame-of-Reference 和 Bit-packing 编码；不能精确往返的少量值则单独存入异常列表。

这样做的价值在于，它把浮点数压缩转化成了处理器更擅长的整数运算。这组测试显示，ALP 的解压吞吐相较 ByteStream Split 约快 3 倍；与 Zstd 组合时，它在测试数据上的压缩率也优于现有方案，即使不叠加 Zstd，也能获得约 1.5 倍的压缩收益。截至我分享这项工作时，ALP 提案已经完成社区投票，C++ 实现仍在 Review，预计一到两个月内发布版本。

FSST（Fast Static Symbol Table）面向中等长度、具有高频子串的字符串，尤其适合 URL、路径、日志、JSON 片段和 RAG 文本。它会为一个 Column Chunk 训练最多 256 个、长度为 1 至 8 字节的静态符号，再用单字节代码替换反复出现的子串。与传统 Dictionary Encoding 只处理完整字符串不同，FSST 能够利用字符串内部的重复结构。

它还可以叠加在 Dictionary Encoding 之上，并支持在压缩字节上进行过滤下推。由于符号替换之间没有数据依赖，Reader 可以并行解码。相关测试中，FSST 的压缩率可达到 Plain 加 Dictionary 的约 2.45 倍，并且在部分场景下无需再叠加 Zstd。

这些编码背后的共同逻辑是：先理解数据，再决定如何编码；重型通用压缩从默认答案，变成可选的最后一步。

让 Parquet 真正跑在 GPU 上

GPU 并不天然排斥 Parquet。很多时候，问题不是格式完全无法被 GPU 处理，而是传统 Writer 生成的文件没有给 GPU 足够的信息和并行任务。

首先，GPU 在启动解码前需要知道输出数据大约占用多少显存，但压缩后的 Page 大小无法直接告诉 Reader 解码后的大小。Parquet 的 SizeStatistics 可以提供 BYTE_ARRAY 原始负载大小，帮助 Reader 在 Column Chunk 或 Page 粒度估算解码结果，合理选择批次并减少保守的显存预留。

其次，GPU 需要大量彼此独立的工作。传统 CPU 导向的 Parquet 文件可能在一个 Column Chunk 中只有一个较大的 Page，最终无法形成足够多的 GPU Kernel Block。通过调整 Row Group、Page 数量和编码方式，同一批数据可以产生上百个并发 Page，为 GPU 提供足够的执行网格。

DaMoN 2026 论文《Do GPUs Really Need New Tabular File Formats?》给出了一个很有启发性的方向：在针对 GPU 重写 Parquet 文件后，通过增加 Page 数量、优化 Row Group 大小、选择合适编码并跳过无关数据，读取带宽可以从约 1GiB/s 提升到 125GiB/s，并跑满 4 块 NVMe SSD。这篇论文的实验方法和数据仍有值得商榷之处，它关于“提高并发度、重新调参”的思路，却与我们的工程经验是一致的。

这说明一个重要事实：面对新硬件，Parquet 既需要格式层面的演进，也需要 Writer 和数据布局的重新调优。不能拿十年前的默认参数测试 GPU，再得出“格式不适合 GPU”的结论。

图 3：Size Statistics 与 Page、Row Group 调优共同决定 GPU 并行度。图源：本文所据演讲材料。

AI 不只需要 FLOAT16，更需要原生 Vector

在 AI 模型中，FLOAT16 已经被广泛使用。它用少量精度损失换取更小的内存占用和更高的计算吞吐。Parquet 已经可以基于 2 字节的 FIXED_LEN_BYTE_ARRAY 表示 IEEE-754 FLOAT16，并支持严格的全序语义，从而正确处理 NaN、-0.0 和 +0.0 等边界情况。

但支持 FLOAT16，只解决了元素类型的问题，并没有解决向量本身的结构问题。

Embedding 和特征向量通常具有固定、已知的维度，例如 768 维。由于 Parquet 缺少原生固定长度向量抽象，现有实现往往把它存成三层可变长 LIST。这样做虽然兼容，却会为每个元素额外写入 Repetition Level 和 Definition Level。对于固定形状数据，这些元数据本来没有必要；Reader 仍要走可变长列表的解码路径，相关测试显示，读取性能可能只有 FixedSizeList 的约三分之一。

社区目前讨论过三类 Vector 表示方案。

第一种是在 FIXED_LEN_BYTE_ARRAY 上增加 FIXED_SIZE_LIST Logical Type。它最容易兼容旧 Reader，也利于零拷贝，因为一个向量可以作为连续字节块存在。但元素被封装成原始二进制后，现代列式编码很难继续发挥作用，也不适合复杂嵌套和元素级 Null。

第二种是引入新的 VECTOR Repetition Type。它的模型最干净，元素仍是正常的 Parquet Column，可以充分使用各种编码，也能够自然表达嵌套结构；更重要的是，不再需要为固定长度数组额外存储 Repetition Level 和 Definition Level。但它几乎没有向后兼容性，旧引擎遇到新的 Repetition Type 可能直接失败，实施成本也非常高。就目前的讨论来看，我个人认为方案 B 最有希望，但它仍然是社区提案，不是已经发布的标准。

第三种是在现有 LIST 上增加 FIXED_SIZE_LIST 注解。旧 Reader 仍能按普通 LIST 读取，新 Reader 则可以根据固定长度跳过部分 Level 处理，并继续使用现代编码。这条混合路线保留了少量冗余元数据，却在兼容性、压缩效率和实施成本之间取得了更现实的平衡。方案 A 和方案 C 的共同优点，是旧 Reader 仍然可以读取；代价是无法获得方案 B 那样彻底的性能收益。

这也是 Parquet 社区经常面对的取舍：最优雅的新模型未必是最负责任的工程方案。对于一个拥有海量历史数据和众多实现的标准，兼容不是负担之外的附加项，而是设计本身的一部分。

图 4：Vector 类型的三种候选路径。

从结构化列走向半结构化、空间和多模态数据

AI 时代的数据远不止关系表和向量。半结构化事件、地理空间对象、图片、音频和文档正在成为湖仓中的一等公民。Parquet 与 Iceberg 的边界也因此不断向外扩展。

Variant：让半结构化数据获得列式性能

传统 JSON 的问题非常明显：Schema 灵活，但查询代价高；如果强制提前定义完整 Schema，又无法适应大规模流数据中不断变化的字段。

Parquet 与 Iceberg 引入原生 Variant Type，希望同时保留 NoSQL 式的 Schema 灵活性和分析数据库的过滤性能。它的关键不是简单地在一列中塞入 JSON，而是使用 Shredding 技术，把经常访问的路径自动拆分为独立、强类型的物理列。未被拆分的部分继续保留在 Variant 中，常用路径则可以使用原生列式编码、统计信息和谓词下推。

Variant 的落地也体现了开放社区的协作方式。它最初由 Databricks 在 Spark 的开发分支中实现，随后 Snowflake 的同事建议把这套能力推回 Iceberg 社区。但问题很快出现了：这个类型到底应该归 Spark、Iceberg，还是另起一个项目？我当时在讨论中提出了把实现直接搬进某个仓库可能带来的问题，促成了更多社区参与。经过大约两个月的讨论，Spark、Iceberg 和 Parquet 社区最终达成共识，把 Variant 的物理表示收敛到 Parquet，使它成为跨表格式、跨引擎共享的底层类型。

这不是某一个项目“赢了”，而是开放生态避免重复造轮子的共同选择。

图 5：Variant 类型通过 Shredding 把高频路径拆分为强类型列。

Geospatial：把空间过滤下推到文件级

自动驾驶、物流和地图分析都依赖地理空间数据。Parquet 已经引入原生 GEOMETRY 和 GEOGRAPHY Logical Type，底层可使用 WKB 表示，为跨引擎读取提供统一基础。

Iceberg 则在表格式层记录空间统计信息。例如，在写入多边形时计算 Minimum Bounding Rectangle，并把 Bounding Box 写入元数据。执行空间查询时，系统无需打开真实几何数据，就可以先利用边界值完成文件级 Data Skipping 和空间谓词下推。

GeoParquet 社区与 Parquet 社区围绕这套能力进行了约十个月的协作。最终把通用物理类型放入 Parquet，把更高层的空间语义和生态规范交给 GeoParquet 与 Iceberg，是一个典型的分层设计：文件格式解决可移植的物理表示，表格式和领域规范解决查询与治理语义。到我分享这项工作时，GeoParquet 社区已经明确将在 2.0 版本采用 Parquet 原生 Geometry 类型。

File Type：让非结构化对象进入列式语义

图片、音频、文档和模型文件不适合全部直接内嵌到 Parquet 中，但如果数据表只能保存一个不透明的字符串路径，系统又无法统一表达偏移、长度、内容类型和完整性信息。

到我分享这项工作时，File Logical Type 已经被社区接受。它使用一个字段均可选的结构，提供三种解析方式：

• Inline：把原始字节直接保存在单元格中，适合 4KB 以下的小图标、短元数据或轻量 Embedding；

• Self-reference：通过 Offset 和 Size 指向当前 Parquet 文件内的一段字节，让大负载与关系索引保存在同一文件中；

• Remote：通过 s3:// 等路径引用对象存储中的外部文件。

这里尤其需要厘清 Parquet 与 Iceberg 的职责。Parquet File Type 定义的是物理表示、字节范围和内容完整性，它让一个文件值能够被不同引擎理解和迁移。Iceberg 的 FileRef（提案） 则位于表格式层，负责快照语义、对象身份与版本、允许访问的存储位置以及表级授权；REST Catalog 可以进一步提供短期凭证或签名 URL。

换句话说：Parquet 让这个值可移植，Iceberg 让对它的访问可治理。两者不是重复建设，而是完成了不同层次的拼图。

列级更新不应强迫重写整张宽表

AI 特征表还带来了另一个典型问题：大量列很少变化，但模型分数或新 Embedding 可能每天更新。如果每次只更新少量列，却必须重写包含所有列的巨大 Parquet 文件，会产生严重的写放大。

Iceberg V4 正在讨论 Column File 机制。它不试图把所有问题都塞回 Parquet 文件内部，而是在表格式层引入独立列文件：基础数据仍保存在不可变的 Base Parquet 文件中，新特征写入较小的 Column Parquet 文件；读取时，执行引擎利用隐藏位置列 _pos，在内存中把基础列和更新列拼接成完整的逻辑视图。这里可以看到 Lance 和 Iceberg 的共同方向：把列更新放到表格式的 Fragment 或 Column File 层解决，而不是要求底层文件格式为每次列修改重写整张宽表。

这种设计以很小的元数据代价换取了真正的列级独立更新，避免为了更新一个特征而重写整行乃至整个文件。

它再次说明，文件格式和表格式需要协同演进。Parquet 负责高效、开放的列式数据表示，Iceberg 负责跨文件组织、快照和更新语义。不是所有需求都应该由某一层单独承担。

图 6：基础 Parquet 与独立 Column File 在读时拼接为逻辑视图。

可演进：标准真正困难的不是发明，而是达成共识

新格式可以快速决定一个 API 或者一种编码，成熟标准却必须回答更多问题：旧 Reader 会怎样？不同语言的实现是否一致？Spark、Trino、DuckDB 等引擎是否能用同一种方式解释？规范升级后，过去十年的文件是否仍然有效？

从外部看，社区讨论似乎总是很慢。一个提案可能经过邮件列表、设计文档、多个 PR 和实现验证，反复修改数月甚至更久。但这并不是低效，而是开放标准必须支付的成本。

Variant 最终进入 Parquet，是因为社区不希望 Spark、Iceberg 和不同引擎分别维护互不兼容的物理格式。Geometry 与 Geography 的落地，同样经历了 GeoParquet、Iceberg 和 Parquet 多方讨论，最终确定由 Parquet 承担通用的底层 Logical Type，由上层生态维护更丰富的领域语义。

这些过程让我更加确信：Parquet 最难复制的能力，不是某一种 Encoding，而是它已经成为一台“共识构建机器”。

它能够让云厂商、数据库公司、开源引擎、表格式社区和研究机构在同一套规范上协作，把局部创新转化为整个开放生态可以共同使用的能力。

这种机制有时显得克制，却避免了另一个更危险的结果：每一个新负载都诞生一种专有格式，每一个引擎都维护自己的扩展，最终用户的数据再次被实现细节锁定。

所以，Parquet 死了吗？

没有。

但如果 Parquet 只是依靠历史地位，拒绝正视 Footer 解析、读取放大、CPU 解码、GPU 并行度和 AI 数据类型这些问题，它当然会逐渐失去生命力。

Parquet 的未来，不是守住十年前的设计，而是沿着三个方向继续向前。首先是更快：通过 FlatBuffers 快速元数据路径、ALP、FSST 等数据感知编码，以及 GPU 友好的统计信息和数据布局，减少解析、解码和无效 I/O。其次是更广：在已有 FLOAT16、Variant 和 Geospatial 能力的基础上，继续推进固定长度 Vector 与 File Type，并与 Iceberg 协作解决列级更新和非结构化对象治理，让列式存储进入 AI 与多模态时代。最后是可演进：用双轨兼容、清晰分层和社区共识吸收创新，既让新 Reader 获得更高性能，也让旧 Reader 和历史数据继续工作。

新格式的出现是一件好事。Lance、Vortex、Nimble、FastLanes、BtrBlocks 和 F3 提醒我们，现代硬件和工作负载已经改变，过去的默认答案需要被重新审视。Parquet 社区不应该害怕挑战者，更不应该把生态规模当作停止创新的理由。

但我们也要看到，文件格式的最终价值从来不只是一张 Benchmark。对于数据基础设施来说，性能决定它能跑多快，开放与兼容决定它能走多远。

这也是云器 Lakehouse 从一开始选择 Apache Iceberg 和 Apache Parquet 的原因。我们不希望再用一套私有格式把用户的数据关在单一引擎里，而是把增量计算和统一的数据处理能力建立在开放底座之上。云器真正需要做的，也不是替 Parquet 另造一个封闭的替代品，而是在真实的 Lakehouse 负载中发现问题，再把这些问题和解决方案带回 Arrow、Parquet、Iceberg 以及 iceberg-cpp 社区。

对用户而言，这种关系最终体现为两件事：数据文件保持开放和可迁移，云器 Lakehouse 则在此基础上提供更高效的计算与更新能力。底层标准越成熟，开放生态越繁荣，云器能够承载的 Data + AI 场景也就越多。

十多年前，Parquet 通过开放列式存储连接了 Hadoop 时代的不同计算引擎；今天，它正在连接湖仓、AI 数据和新一代硬件。它仍然是开放数据生态的共享互操作层——不是因为它站着不动，而是因为它在谨慎而持续地进化。

Parquet 没有死。这个列式巨人的下一轮演进，才刚刚开始。

---

🎁 新用户专享福利

✅  1 TB 存储 · 1 CRU时/天计算 · 1 年全托管体验

➤ 即刻访问云器官网领取：https://www.yunqi.tech/product/one-year-package