从 Arrow 到 Iceberg 到 Polaris 到 Ossie：语义标准化的最后一块拼图

上个月我在 Obsidian 里翻到一张 2018 年的架构图。那时候我们给甲方画"企业大数据平台"，底层标着 Hadoop，中间标着一堆 ETL 箭头，顶层标着 Tableau。数据格式五花八门，Avro、ORC、Parquet 混在一起，每个工具之间靠点对点 connector 硬接。

七年后的今天，我再看这张图，突然意识到一件事：这张图上的每一层，已经被 Apache 开源标准一块一块吃掉了。

从下往上数：Parquet 吃了文件层、Arrow 吃了内存交互层、Iceberg 吃了表管理层、Polaris 吃了目录层——2026年7月，最后一块拼图来了：Apache Ossie，吃掉了语义层。

这不是巧合。这是一个酝酿了十年的产业共识。今天把这条线捋清楚。

开放标准吃掉数据栈的十年语义层2026 · Ossie你的数据什么意思？目录 & 治理层2025 · Polaris数据在哪？谁能看？表格式层2020 · Iceberg表怎么管？怎么改？内存交换层2016 · Arrow数据怎么传？格式是啥？文件格式层2013 · Parquet数据存成什么？怎么读？← 最稳固← 成熟← 快速增长← 刚毕业← 刚进场 🔥以上是应用层（BI / Agent / 业务系统）

十年，五层，一个逻辑：每层一旦稳定，行业就把下一层也交出去做成开放标准

■ 第一块：Arrow——"你传数据给我，别让我猜格式"

2016 年，我在一家数据公司做工程师。那时候最头疼的事不是算得慢，是传数据。Spark 读个 Pandas DataFrame，要序列化成 JSON 再反序列化——几百 GB 的数据，70% 时间花在来回翻译格式上。

这个痛点被 Wes McKinney（Pandas 作者）看透了。他和一帮人搞了 Apache Arrow：一种跨语言、跨进程的列式内存格式。关键设计很聪明——Arrow 的数据在内存里是标准布局，Python 能读、Java 能读、C++ 能读，同一个指针传过去就行，不需要序列化。

一句话：Arrow 解决的问题是——"我跟你说数据是什么样的"，不是"我给你发一个 CSV 你自己猜"。

Arrow 后来还推出了 Flight（数据怎么传）、ADBC（数据库驱动怎么接）、DataFusion（查询引擎），但它们的内核没变：先统一数据在内存里的形态，再谈怎么用。

这层现在是整个数据生态的基础。Polars、DuckDB、InfluxDB 3.0 都在底层用 Arrow。Parquet 文件读出来是 Arrow、传进 GPU 是 Arrow、在分布式系统里 shuffle 也是 Arrow。这层的标准已经稳了，没人再问"我们该用哪个内存格式"。

■ 第二块：Iceberg——"别让我管那一堆文件，给我一张表"

Parquet 解决了文件格式，但没解决"表"的问题。

你可以想象一下：一个数仓里有一张"订单表"，底层是 S3 上十万个 Parquet 文件。跟这张表打交道——加一列、删几行、回滚到昨天的版本——意味着你要操作一堆文件，每次操作都得小心别把数据搞丢。

Netflix 比谁都先感受到这个疼。他们 2017 年开始搞 Iceberg，核心洞察是：别让用户管文件，让他们管表。Iceberg 在 Parquet 文件上面加了一层抽象——定义了表的 schema（字段定义）、partition（怎么分区）、snapshot（版本快照）。你改一个列 Iceberg 自动帮你处理底层文件；你查昨天下午三点的数据 Iceberg 直接用快照恢复，不用恢复整个库。

2025 年 Iceberg Spec v3 发布，加了三个狠东西：二进制删除向量（删行不再需要重写整个文件）、行级血缘（每一行数据都能追溯到来源）、Variant 类型（JSON 半结构化数据不用先解压全字段）。

一句话：Iceberg 解决的问题——"表是一个逻辑概念，不是一堆文件的别名"。Schema 演变、时间旅行、增量查询，都应该是表格式内置的东西，不是你自己写的脚本。

■ 第三块：Polaris——"表我知道在哪了，但目录谁管"

Iceberg 统一了"表"的定义，但留下一个坑：表多了，怎么找。

我在 2019 年那个数据中台项目里，Iceberg 表在 Snowflake 里有一套、在 Databricks 里有一套、在 Dremio 里还有一套。同一个"客户表"三份，同步靠 Airflow 定时任务。更烦的是权限——谁能在哪个表上做什么，得在三套系统里各配一遍。

这就是目录层要啃的骨头。Iceberg 社区先出了一个 Iceberg REST Catalog 协议——不要求你统一平台，只要求你同意一个查询目录的接口标准。有了这个协议之后，Snowflake 在 2024 年把自研的 Polaris 开源，并且和 Databricks 联手推进 Apache 孵化。2026 年 7 月，Polaris 从孵化器毕业，成为 Apache 顶级项目。

一句话：Polaris 解决的问题——"你的 Iceberg 表我可以直接读，不用先同步到我的系统里"。目录是共享的，权限跟着目录走，不用每套工具各搞一套。

说个有意思的细节。Polaris 之所以能成，不是因为它技术多牛——是因为 Snowflake 和 Databricks 这对冤家同时认了它。两个最主要的 Iceberg 生产用户都同意用一个标准做目录，这事的意义远超技术本身。

■ 第四块：Ossie——"数据目录有了，但数据的含义呢"

这才是今天真正要说的。

到 2025 年底，Parquet + Arrow + Iceberg + Polaris 这条线已经把数据基础设施从磁盘管到了目录。你可以在 Snowflake 建表、Databricks 查、Dremio 分析，目录权限一致，数据不用搬。看上去很完美。

但我跟你说个场景。

假设你的 BI 工具读到了 Iceberg 表 sales.orders，字段名叫 o_sts_cd，值是 3。Polaris 告诉你这个表在哪、谁能读、最新的快照号是几——全对。然后你的 AI Agent 要回答"上个月有多少已完成订单？"Agent 不知道 o_sts_cd=3 就是"已完成"。更不知道"已完成"的定义是"已发货、已签收、已入账"三个��件同时成立。

Polaris 管好了"数据在哪"，但没管"数据是什么意思"。这就是语义层最后一块拼图要补的窟窿。

Ossie 做的，就是给你们企业里的所有数据表加一份 "翻译说明书"——用 YAML 把字段映射到业务概念，定义指标怎么算，标注同义词。Polaris 负责你找到这张表，Ossie 负责让 Agent 和 BI 工具理解这张表。

Ossie 和 Polaris 的关系：Polaris 说"订单表在 S3 的 bucket-xyz，最新快照是 snapshot-456"。Ossie 说"o_sts_cd=3 叫'已完成'，'已完成'的定义是发货+签收+入账，等价词是'OrderComplete'、'订单完成'、'状态3'"。两个东西在同一张表的不同维度。

■ 为什么顺序不是偶然的

这五层不是谁规划好的。是行业自己一层一层"交"出来的。每层的逻辑都差不多：

重点在于 ④ 这一步。开放标准最难的从来不是技术，是让竞争对手坐下来一起签字。Iceberg 当年最难的不是 Spec v3 的删除向量——是 Databricks 认了，Snowflake 也认了。Polaris 也一样。Ossie 现在也在过这道坎——50+ 家公司签了字，但长期能不能维持共识，要看第一个大分歧出现时怎么处理。

上层依赖下层这个道理也很有意思。没有 Parquet 统一文件格式，Iceberg 的抽象就没法建——你得同时支持 ORC、Avro、CSV，复杂度爆炸。没有 Iceberg 统一表格式，Polaris 的目录就没有统一口径——你管的是表还是文件？物化视图还是快照？没有 Polaris 统一目录，Ossie 的语义模型就不知道该挂在哪——字段定义该跟着表走还是跟着目录走？

每一层的开放标准，都让下一层的问题变得清晰可见。不是谁先见之明——是问题一层一层暴露，行业一层一层摊牌。

Parquet文件格式 · 2013Arrow内存格式 · 2016Iceberg表格式 · 2020Polaris目录 · 2025Ossie语义层 · 2026下层稳定 → 上层问题暴露 → 行业交出来做标准★每一层都是上一层的"编译目标"

一条链穿起来：每层的开放标准让上一层的问题变得必须解决

■ Ossie 为什么意义特殊

前面四层都是"数据基础设施"——解决存储、传输、管理、权限。这些都很重要，但说到底对齐的是"机器跟机器怎么说话"。

Ossie 不一样。它解决的是"人跟机器之间怎么对齐含义"。这个问题之前一直被回避——因为太难。同一个"收入"在财务、销售、运营各有定义，你让 50 家公司坐下来签一份"什么是收入"的协议，比让他们签一份"文件怎么存"的协议难十倍。

那为什么 2026 年这事成了？两个原因。

第一个，AI Agent 倒逼。以前 BI 工具查数据，出错了人还能纠——分析师看"客单价 3000"会觉得不对劲然后去查 SQL。但 AI Agent 不一样——Agent 直接根据查询结果做决策，如果口径错了没人检查。没有人"复核"的时候，"含义"就变成了一个必须标准化的问题，不能再靠人工兜底。

第二个，生态成熟了。2025 年之前，连 Iceberg 的表格式标准都还没稳、Polaris 的目录协议还在讨论，你说要再叠一层语义标准，没人理你——下面还没稳，谁敢在上面盖。现在 Parquet / Iceberg / Polaris 三层都稳了，行业可以抬头看下一层了。

■ 对数据架构师意味着什么

如果你现在正在设计企业的 AI 数据底座，我建议你这么想：

Parquet + Iceberg 是地基，这个没啥好说的，现在已经没有争议了。文件用 Parquet、表用 Iceberg——这是 2026 年的起点线，不是附加分。

Polaris 是围墙，决定谁能进、能看到什么。如果你内部已经有 Snowflake Horizon 或 Databricks Unity Catalog，可以先不换 Polaris——但要开始把权限模型往 Iceberg REST 协议的方向靠，因为迁移成本会越来越低。

Ossie 是门牌号，决定每个房间里放的是什么东西、叫什么名字。这块现在还没人敢上生产——我自己也没。但我已经把一个项目的本体模型转成了 Ossie 格式，放在仓库里跟着表结构一起维护。这相当于先把"语义源码"写了，等 Ossie 的工具链和生态成熟，编译一下就能用。

你现在怎么管"数据含义"这件事？靠 dbt docs 写注释？靠 Excel 记口径？还是已经上了语义层？

来留言聊聊——另外回复关键词 "标准栈"，发你一份我整理的 Parquet→Arrow→Iceberg→Polaris→Ossie 五层技术对照表，含每层的核心协议、关键时间节点和选型建议。