开放数据产品标准：首选比较

开放数据产品标准是一种已发布的、版本化的规范，定义了如何跨组织描述、发现和使用数据产品。到 2026 年，三个系列将占据主导地位：2.0 版的开放数据产品规范 (ODPS)、Bitol 开放数据产品标准以及更轻量级的元数据约定，例如数据产品描述符规范 (DPDS)，每个规范都针对数据的可移植合约。

开放数据产品标准是一种已发布且版本化的规范，描述了如何跨组织定义、发现和使用数据产品。到 2026 年，三个系列将占据主导地位：2.0 版的开放数据产品规范 (ODPS)、Bitol 开放数据产品标准（与 ODPS 相邻，沿袭 v0.9.0）以及更轻量级的元数据约定，例如数据产品描述符规范 (DPDS)。每个标准都解决了同一问题的不同方面——数据的可移植合约——而在这之间做出选择取决于您是否需要完整的商业合约、机器可读的描述符或治理友好的模式。

企业数据架构师很少孤立地选择一个标准。选择受到现有资产中平台的限制：Snowflake、Databricks、Google Cloud、AWS 和 Microsoft Fabric 各自提供自己的元数据和目录约定，而共享模型只有在能够连接它们的情况下才能赢得一席之地。这就是本次比较要解决的核心矛盾：不是哪个规范在抽象层面是“最好的”，而是哪个规范能够在与您现有的工具链、治理流程和供应商的接触中幸存下来。

开放数据产品标准 ODPS

开放数据产品规范 (ODPS) 是当前开放数据产品标准选项中最全面的。ODPS 作为开放数据产品计划 (Open Data Product Initiative) 的一部分进行维护，已达到 2.0 版本并发布在 opendataproducts.org 上。它的范围有意设计得非常广泛：它将数据产品建模为商业和运营工件，而不是简单的数据集。

ODPS 围绕几个更高级别的对象构建产品。典型的文档包括：

• 架构 (Schema) — 产品的结构定义，包括字段、类型和约束。
• 产品详细信息 (Product details) — 名称、描述、版本和生命周期状态。
• 数据访问 (Data Access) — 消费者如何访问数据，包括端点和访问方法。
• 数据质量 (Data quality) — 声明的质量维度和预期。
• 定价 (Pricing) — 商业条款，这在数据标准中并不常见，也是 ODPS 设计的核心。
• SLA — 服务级别承诺。
• 许可证 (License) — 使用权。
• 治理 (Governance) — 所有权、管理权和政策。

定价和 SLA 对象是 ODPS 与纯元数据规范的区别所在。如果您的组织在内部对数据进行货币化或内部计费 (charge back)，ODPS 为您提供了表达这些内容的空间，而无需发明私有模式。如果您只需要发现元数据，那么这些对象就是您无论如何都会承担的额外开销。

Related: Fivetran — The fully managed ELT pipeline that just keeps running.

一个实际的警告：ODPS 是一个规范，而不是运行时。采用它意味着您需要自己编写验证器、生成器和目录映射，或者从社区中寻找。该规范定义了有效文档的形式，但并不提供从现有流水线生成文档的工具。

开放数据产品标准 Bitol

Bitol 开放数据产品标准是一项具有重叠目标的独立工作，托管在 GitHub 的 bitol-io 组织下，并记录在 bitol-io.github.io/open-data-product-standard。v0.9.0 文档集是引用最广泛的公开版本。Bitol 的框架面向一个随数据一起传输的描述符：一个平台可以读取以注册、验证和公开产品的 YAML 或 JSON 文档。

Bitol 的结构更接近于平台描述符，而非商业合约。其文档围绕少量强制性和可选属性组织，且版本控制纪律明确：规范的版本独立于任何实现，重大更改被锁定在主版本号递增之后。

If you are shopping: Boomi AtomSphere — Enterprise iPaaS for hybrid cloud-to-on-prem integration.

这种区别在实践中很重要。ODPS 询问“这个产品价值多少，我们承诺什么？”Bitol 询问“这个产品是什么，我如何将其连接起来？”许多团队最终会同时使用两者：使用 Bitol 风格的描述符进行平台注册，使用 ODPS 风格的文档用于业务和治理层。如果两者都是从单一事实来源生成的，那么这不是重复；如果手动并行维护，则会产生问题。

社区治理对两者来说都是一个开放性问题。由单一供应商控制的标准其实就是贴了标准标签的供应商格式。Bitol 基于 GitHub 的流程（具有公开 Issue 和 Pull Request）比封闭规范更开放，但其采用程度仍决定了它会成为真正的数据互操作性标准还是一个小众约定。请评估贡献者列表、发布频率以及竞争平台是否已实施它——而不仅仅是看许可证是否宽松。

什么是产品数据

在数据管理的意义上，产品数据 (Product data) 是描述产品的结构化信息：标识符、属性、类别、关系和生命周期状态。在零售和制造业中，这意味着 SKU、物料清单 (BOM) 和目录属性。在数据平台的意义上，这指的是描述数据产品的元数据：其架构、所有者、质量和访问条款。

这两种含义在这个领域发生了碰撞，并造成了真正的混乱。“数据产品 (data product)”与“产品数据 (product data)”不同。数据产品是一个受管理的、可发现的、带有合约、拥有所有者和消费者的数据单元。产品数据则是目录的内容。当供应商推销“产品数据标准”时，在将其映射到您的架构之前，请检查他们指的是哪一种。

对于企业互操作性，有用的定义是第二种：一种元数据信封，允许系统充分描述数据集，以便另一个系统无需人工协商即可消费它。这种信封正是开放数据产品标准所形式化的内容。

什么是 Open Data Kit

Open Data Kit (ODK) 是一套用于移动数据采集的开源工具，最初为实地研究和人道主义用途而开发。ODK Collect 在 Android 设备上运行，ODK Central 处理服务器端提交管理，该生态系统支持离线表单输入及随后的同步。

Related: Airbyte — Open-source ELT with a managed cloud option.

ODK 经常与开放数据产品标准混淆，因为两者都包含“open”和“data”这两个词。但它们解决的是不相关的问题。ODK 是一个在低连接环境下用于结构化表单的数据采集平台。而开放数据产品标准是针对已存在于平台中的数据的描述格式。人道主义组织可以使用 ODK 采集实地数据，然后将生成的数据集作为由 ODPS 或 Bitol 描述的数据产品发布——两者是互补的，而非竞争关系。

如果搜索“开放数据产品标准”出现了 ODK，原因就在于此。请注意区分并忽略它。

数据产品标准

数据产品标准是指任何定义数据产品描述的强制性和可选元素的规范。这个术语是通用的；ODPS 和 Bitol 就是例子。一个有用的数据产品标准能回答四个问题：产品中包含什么、谁拥有它、如何访问它以及附带什么保证。

Where we would start: Matillion — Push-down ELT built for cloud data warehouses.

此类标准的主要区别在于其严谨程度。有些定义了最低要求集——名称、描述、所有者、架构引用——并将其他所有内容设为可选。而像 ODPS 这样的一些标准则定义了一个包含许多可选部分的大型对象模型。最低标准更容易采用，但也更容易定义不足。丰富的标准更难采用，但一旦采用，能产生更有用的目录。正确的选择取决于您的治理成熟度，而非您的野心。

开放产品数据

开放产品数据 (Open product data) 指的是在开放许可下发布以供重复使用的产品信息：无限制条款发布的目录数据、定价、规格和标识符。Open Food Facts 和类似项目就是例子。这是一个内容许可概念，与作为结构性概念的数据产品标准截然不同。

当组织将开放产品数据作为数据产品发布时，就会产生重叠。在这种情况下，发布内容将受益于标准描述符：消费者可以通过编程方式发现数据集、理解其架构并验证其许可证，而无需阅读 README。开放许可和标准描述是正交的，且结合良好。

开放数据产品规范 (Open data product spec)

“Open data product spec”是规范文档本身的简写——即定义有效产品描述的规范性文本。ODPS 和 Bitol 都发布带有版本号的规范，并且都将规范视为合约：实现必须符合规范，且一致性是可测试的。

规范的有用程度取决于其验证器。在决定采用之前，请检查是否存在 JSON Schema 或等效的机器可读工件，检查它是否与正文同步版本化，以及社区是否维护测试用例。没有验证器的规范就变成了文档练习；带有验证器的规范则变成了基础设施。

开放数据产品规范 (Open data product specification)

全称“开放数据产品规范 (open data product specification)”与开放数据产品计划的 ODPS 2.0 联系最紧密。该规范定义了一个具有上述对象模型的 YAML 或 JSON 文档，并使用版本化 URL 发布，以便消费者可以固定到特定修订版本。

版本控制的纪律是这里的实际考验。在次要版本之间更改必填字段的规范会破坏所有消费端。而将重大更改保留在主版本中并记录迁移指南的规范才是安全可采用的。在针对任何修订版本构建生成器之前，请检查变更日志。

比较：在主要选项之间做出选择

标准	ODPS 2.0	Bitol ODPS	DPDS 风格描述符
主要目的	商业 + 运营合约	平台描述符	元数据注册
定价 / SLA 对象	是	有限	否
机器可读架构	是	是	是
治理模式	倡议主导	GitHub 社区	因项目而异
最适合	货币化或内部计费数据	平台入驻	目录发现
采用风险	中等	中等	低但碎片化

一个在实践中有效的决策规则：从您的目标平台已经能够读取的描述符开始，如果您需要商业业务条款，再叠加开放数据产品标准 (ODPS)。在拥有能够存储丰富开放数据标准的目录之前，不要采用它：一个未填充的对象模型比最小模型更糟糕，因为它涉及您实际上并未执行的治理。这种方法通过利用开放标准的社区治理来确保可持续的数据互操作性标准。无论是使用云数据的开源互操作性标准还是特定的云数据互操作性标准，目标都是实际实施而非理论上的丰富。

关键要点

• 到 2026 年，三个系列将至关重要：ODPS 2.0（商业合约）、Bitol 标准（平台描述符）和更轻量级的元数据约定（发现）。
• ODPS 是唯一被广泛引用的、将定价和 SLA 建模为一流对象的开放数据产品标准选项。
• Bitol 基于 GitHub 的流程使其开放标准的社区治理比封闭规范更透明，但采用程度仍决定了它是否能成为真正的数据互操作性标准。
• Open Data Kit 是一套数据采集工具，而非数据产品的开放数据标准；名称重叠导致了持续的混淆。
• 根据您的目录和平台实际能够存储和验证的内容进行选择，而非根据云数据互操作性标准对象模型的完整性来选择。
• 从单一事实来源生成描述符；手动并行维护 ODPS 和 Bitol 文档会导致您的云数据开源互操作性标准出现偏差。

资料来源和进一步阅读

• 开放数据 — 维基百科：开放数据是任何人出于任何目的均可公开访问、利用、编辑和共享的数据。开放数据通常根据开放许可证获得许可…
• 数据产品 — 维基百科：在数据管理和产品管理中，数据产品是一种可重用、活跃且标准化的数据资产，旨在为其用户提供可衡量的价值，无论…
• 开放标准 — 维基百科：开放标准是任何人都可以公开访问和使用的标准。开放标准使用提供…的开放许可证也是一个常见的先决条件。
• 开源 — 维基百科：开源是指在公开发布数字资源的同时提供其源代码或源文件的实践，以便于使用、研究、修改和重新分发…

常见问题

什么是开放数据产品标准 ODPS？

ODPS 是开放数据产品规范（Open Data Product Specification），由开放数据产品计划（Open Data Product Initiative）维护并发布了 2.0 版本。它定义了一个涵盖架构（schema）、产品详情、访问、质量、定价、SLA、许可和治理的结构化文档。其特殊之处在于它将数据产品视为一种商业工件，而非数据集的简单描述。

什么是 Bitol 开放数据产品标准？

Bitol 标准是一个独立治理的规范，托管在 GitHub 的 bitol-io 组织下，公共文档版本为 v0.9.0。它定义了一个机器可读的描述符，平台可以通过读取该描述符来记录和公开数据产品。其范围更接近于平台布线（platform cabling）而非商业合同，这就是为什么许多团队将其与 ODPS 配对使用，而不是在两者之间做出选择。

什么是产品数据？

产品数据是描述产品的结构化信息：标识符、属性、类别和生命周期状态。在数据平台上下文中，这也指描述数据产品的元数据。这两个含义是不同的：数据产品是一个拥有所有者和消费者的管理数据单元，而产品数据则是目录内容。

什么是 Open Data Kit？

Open Data Kit 是一款用于移动数据采集的开源套件，包括 ODK Collect 和 ODK Central，广泛应用于实地研究和人道主义工作。它处理离线表单输入和服务器端提交管理。尽管使用了相同的“开放数据”措辞，但这与数据产品标准无关。

什么是数据产品标准？

数据产品标准是任何定义数据产品描述中强制性和可选元素的规范。它通常回答产品包含什么、谁拥有它、如何访问以及适用哪些保证。ODPS 和 Bitol 是两个例子；该类别比其中任何一个都更广泛。

我如何在 ODPS 和 Bitol 之间做出选择？

当您的优先级是平台上的注册和集成时，请选择 Bitol 风格的描述符；当您需要正式表达的定价、SLA 和许可条款时，请选择 ODPS。如果您两者都需要，请从单一事实来源（single source of truth）生成它们，以免文档出现偏差。在提交之前，请根据发布的架构进行验证，并检查变更日志中的破坏性变更（breaking change）策略。

这些标准真的具有互操作性吗？

互操作性取决于实现的程度，而非规范的质量。由单一平台实现的标准实际上是供应商格式。在采用之前，请检查哪些平台和供应商已交付合规的实现、贡献者群体的活跃程度以及是否存在验证器。开放标准的社区治理是必要的，但还不够：采用率才是真正的考验。

一般而言，云数据的开源互操作性标准如何？

除了数据产品描述符之外，云数据互操作性领域还包括 Apache Iceberg 和 Delta Lake 等表格式、目录规范和查询引擎协议。它们的操作层面与产品描述符不同：它们管理数据的存储和读取方式，而产品标准则管理数据的描述和发现方式。一个完整的架构通常同时使用这两层，且描述符层应引用存储层而非重复其内容。

对于依赖共享企业模型的团队，实际的顺序是先确定存储和目录层，然后采用引用该层的产品描述符。云信息模型（Cloud Information Model）及类似努力的存在，正是为了给这个描述符层提供一个稳定的、独立于应用程序的词汇表，使得在一个平台上定义的产品可以在另一个平台上被理解，而无需为每对系统进行定制映射。