摘要（ABSTRACT）
数据是我们手中最强大的决策工具。然而，尽管全球产生的数据量呈指数级增长，要将其有效利用仍面临诸多挑战：在需要时，关键数据常常“缺位”——被困于数据孤岛，难以发现、难以访问、陈旧且质量不佳。其结果是，政府、机构与企业在开展数据驱动决策方面的能力受到严重限制。
与此同时，数据科学正经历一场可复现性危机。绝大多数研究成果无法被其他研究者复现，且往往难以建立数据的来源（溯源），即便是那些影响数百万生命的医学研究所用数据亦不例外。在最迫切需要对数据进行重大改进的当下，我们却正在丧失协作能力。
我们认为，根本原因在于现代数据管理流程与协作与信任的基本原则背道而驰。本领域需要在“如何看待数据、如何共享数据以及如何转换数据”的方法上进行根本性转变。
我们必须不再把数据视作静态体，不再以“贫瘠的二进制包”方式进行交换；相反，应把重点放在让多方数据管理更具可持续性：例如可复现性、可验证性、溯源性、自治性以及低时延。
为此，本文提出 Open Data Fabric（开放数据织体） ——一种自底向上设计的去中心化数据交换与转换协议，旨在简化数据管理，并使围绕数据的协作达到与当今开源软件相当的规模。
1 引言（INTRODUCTION）
现代数据科学与数据工程正迅速发展，并为医学、社会科学等诸多学科提供支撑；在这些领域，操控大型数据集早已成为许多研究者的常态。然而，这些社群对上述进展的可持续性提出了越来越多的担忧，尤其集中在可复现性与数据溯源问题上［5, 19］。
这些问题在科学界并不新鲜［16］，但在新冠疫情期间变得尤为明显。面对全球性紧急事件的研究，需要在持续的时间压力以及更高的关注与审查之下，围绕迅速增长的数据集开展高效协作［4］。在这种条件下，维持结果的可复现性（而这一过程当下愈发耗费人力）很难成为优先事项。其一个触目惊心的后果，是经同行评审期刊发表的新冠相关论文出现了令人担忧的高撤稿率［22］。
一个典型案例是发表于权威期刊《柳叶刀》的羟氯喹研究［17］。该研究声称使用了来自全球 671 家医院、超过 9.6 万名新冠患者的数据。论文发表后不久，期刊便收到了大量关于结果准确性的质疑，因为一些基础数字对不上。随后，当部分被列为数据提供方的医院表示他们并未与任何人达成提供此类数据的安排，且越来越多的迹象表明无法建立源数据的溯源时，该论文被撤回。然而彼时损害已造成——一个未得到及时核查的数据溯源问题，严重干扰了挽救生命的工作，使许多其他研究偏离轨道，并在这一关键时刻进一步加剧了困惑。
对这些问题的认识不断加深，促使科学界多次发出行动呼吁，倡议建设更好的协作平台，并以可靠的方式管理数据［11, 28, 31］。
我们可以轻易指出现代数据供给链中导致这些问题的诸多因素：以非机器可读格式发布源数据、数据孤岛、数据质量不佳、格式异构、基础设施薄弱、发布方缺乏激励、发布者与使用者之间缺少反馈闭环等。这些问题迫使数据使用者为获取数据并将其处理为可用状态投入与产出极不相称的时间与资源。更糟的是，由于目前缺乏让这类改进可复现、可验证的机制，这一整套过程最终只会产出另一份与其来源完全脱离的数据集。只要存在从可信来源下载数据、加以修改再重新发布的循环，这一问题就会反复出现。另一位研究者要证明这类数据集的有效性，所需时间往往与从零重做全部工作相当。因此，即便再严谨的研究项目起步于可信数据源，最终仍常常产出一份难以被直接信任与复用的数据。
在本文中，我们将详细审视建立信任与协作所需的前提条件，并介绍我们如何据此构建 Open Data Fabric 协议以满足这些前提。
2 设计考量（DESIGN CONSIDERATIONS）
Open Data Fabric（ODF） ［14］是一份面向去中心化的半结构化数据交换与转换的开放协议规范，旨在整体性地解决现代数据管理系统与工作流中的诸多缺陷。我们的目标是提出一种数据交换方法，能够：
- 解决现代数据供给链中的可复现性、可验证性与溯源问题。 2 设计考量（DESIGN CONSIDERATIONS）
Open Data Fabric（ODF） ［14］是一份面向去中心化的半结构化数据交换与转换的开放协议规范，旨在整体性地解决现代数据管理系统与工作流中的诸多缺陷。我们的目标是提出一种数据交换方法，能够：
- 解决现代数据供给链中的可复现性、可验证性与溯源问题。 2 设计考量（DESIGN CONSIDERATIONS）
Open Data Fabric（ODF） ［14］是一份面向去中心化的半结构化数据交换与转换的开放协议规范，旨在整体性地解决现代数据管理系统与工作流中的诸多缺陷。我们的目标是提出一种数据交换方法，能够：
- 解决现代数据供给链中的可复现性、可验证性与溯源问题。
• 在无需中心权威的前提下，为参与方创建一种可验证的信任环境。
• 促成围绕数据清洗、丰富与派生的全球协作。
• 实现高度的数据复用，使高质量数据可以随时可用。
• 通过缩短从发布者到消费者的数据传播时间，提升数据的“流动性”。
• 闭合数据消费者与发布者之间的反馈回路，使双方能够就数据的可用性、时效性与设计展开协作改进。
在本节中，我们将展示这些目标如何被纳入系统设计之中。
2.1 数据流（Data Flow）
原始数据很少以其原貌被直接消费——通常需要经过一系列转换、聚合与丰富步骤之后，才能被实际使用。在 ODF 中，我们明确区分如下两类数据：
- 源数据（Source data） ：在 ODF 中以根数据集（Root Datasets）表示，直接来自外部系统。发布此类数据的组织对其拥有完全的权威，并对其真实性负全部责任。
- 派生数据（Derivative data） ：在 ODF 中以派生数据集（Derivative Datasets）表示，由对其他数据进行转换与组合而产生。它相对于源数据是次级的，但同等重要，因为呈现给决策者、用于训练模型、或输入到各类自动化流程中的，往往正是这些派生数据。
把源数据转化为可付诸行动的（派生）数据的多阶段过程可以有多种形态：既可能表现为报表链（人员周期性地进行分析与汇总，例如薪酬、公司管理报表），也可能是复杂的自动化工作流（如企业数据流水线）。在 ODF 中，我们认为将这些过程视为计算图（见图 1）更直观且有效：数据通过多个转换阶段，持续地从其源头流向消费者。
2.2 协作的基础（The Foundation of Collaboration）
如前所示，相较于从零开始重做，验证派生数据的有效性往往成本高得令人却步。正因如此，复杂的多阶段数据处理链主要存在于组织内部——在那里，员工之间可以形成隐性的相互信任。当今跨组织的数据协作常常走向中心化：建立可以强制实施访问控制、审计与用户权限的数据空间。但中心化耗时、昂贵，且往往不可行，因为不同参与方希望对其数据保持完全的控制权与所有权。
在去中心化环境（如科研）中进行的数据协作问题依然未解。论文使用的源数据有效性在审稿过程中常常未被核查，信任多半取决于作者或其所在机构的声誉。这在成果发表方面，可能对青年研究者和知名度较低的高校造成不公。
因此，ODF 的目标之一，是将消费者确立派生数据有效性所需的时间缩短到分钟级，并在参与方无法建立完全信任的去中心化环境中实现数据协作。
独立各方有效协作的现代典范是开源软件生态。最初在小型、紧密社区内的思想交流，很快演变为全球性运动。分布式版本控制系统（DVCS） ［24］的出现，保证了在迅速扩张的规模下协作依然可行。许多新近的数据管理系统尝试将 DVCS 背后的理念（如基于差异的历史与分支）直接应用到数据之上［3，15］。
改用“性质”而非“方案”来借鉴 DVCS
在 ODF 中，我们并未直接照搬某些具体的技术决策，而是试图理解：是什么性质让分布式版本控制系统（DVCS）在协作方面如此出色。我们的答案是：它们有助于建立信任。DVCS 甚至能在素未谋面、语言各异的人之间建立信任——其凭借的性质包括：完整变更历史的追踪、任何变更可归因到具体作者、可安全回滚任意历史变更，以及轻易暴露并修复恶意行为。
将这些理念迁移到数据领域，我们提出了支撑信任、也是数据协作所必需的三大支柱：
- 可复现性（Reproducibility） ：复现实验结果的能力是科学方法的基石；没有它，一方的过程与发现就无法被他人跟随与验证。
- 可验证性（Verifiability） ：在决定使用某份数据之前，必须能判断其是否来自可靠发布者，并且真实声明了经历过哪些转换。
- 溯源性（Provenance） ：无论数据经历多少级转换，均应能将任一具体取值追溯回其来源，并弄清是哪些上游数据促成了它的存在与数值。
2.3 源数据层面的可复现与可验证
通往更高可复现性与可验证性的道路必须从源头开始。要求其实很简单：不同的两个参与方在不同时间能够访问到完全相同的数据，并且能够验证这些数据是未经篡改、确实来自可信来源。令人意外的是，如今大多数数据源都难以满足这些基本要求。
例如，GeoNames¹ 与 NaturalEarth² 是开放 GIS 数据的重要发布者。它们周期性地发布包含其领域“最新已知状态”的数据集。这类“状态快照”以覆盖式方式发布——直接覆写先前的全部数据。因此，使用同一 URL在不同时刻下载数据的人，很可能得到并不相同的内容。
再如 NYC Open Data Catalog³，其中一些数据集包含特定事件的完整历史。这类“账本（ledger） ”会随着新事件的追加而不断增长。该做法显然优于快照（从不丢数据），但两方想拿到相同数据仍很困难：先下载的一方通常只拿到了后来者所获账本的子集。消费者只得依赖其它方式来协调他们将使用账本的哪一段（例如数行数、用时间戳或记录 ID），而这些方式都相当不可靠（见第 3.4 节）。
归根结底，现代数据的可复现与可验证问题始于源数据：诸如状态快照与破坏式更新等不良实践在许多主流数据发布者那里仍属“常态”。针对我们的目标，我们归纳出两条至关重要的性质：
- 必须能获得可在参与方之间共享、并可在任何将来时刻用来取得同一份数据的稳定引用（stable reference） ；
- 数据源必须提供机制，确保按此方式取得的数据未被恶意或偶然篡改。
目前较为常见的一种策略是：把整个数据集从来源复制到耐久存储，并赋予一个版本号或唯一标识。这种做法在企业数据科学中很普遍，也被诸如 Quilt⁴、DVC⁵ 等数据管理工具所推广。在封闭且可信的企业环境中它或许有效，但在分布式场景、开放数据与快速变化的数据源面前，它就并不适用。一旦复制完成，这些带版本的快照实际上就变成了完全独立的数据集，因为并无可靠机制将其稳定关联回可信源。此类拷贝只会增加噪声、加剧溯源难题，应尽量避免。
类似问题也出现在许多现代的数据枢纽与数据门户尝试中，例如 Dataverse⁶、DataWorld⁷、Knoema⁸，以及在 Kaggle⁹、GitHub¹⁰ 等平台上日益流行的数据分享。尽管简化发现与联邦式汇聚数据的目标值得肯定，但若缺少把数据链接回可信源的机制，它们实际上只是在制造更多彼此割裂且不可信的数据集。
为满足上述性质，ODF 选择重新审视“数据”的含义，并对其下定义得更为严格。
2.4 数据模型（Data Model）
事件（Events）。 ODF 主要面向关键任务（mission-critical）数据设计。当数据用于洞察与决策时，丢弃或修改数据等同于重写历史，因此系统所观测到的全部数据历史都必须被保留。
在 ODF 中，数据被视为历史记录的账本（ledger） ：历史只会增长，永不删除或修改——进入系统的所有数据皆为不可变。ODF 将数据中的每条记录视为事件或在某一时刻被认为为真的关系命题。基于此视角，我们完全摒弃“状态快照”的存储方式，因为它缺乏必要性质。借鉴 Event Sourcing（事件溯源） ［10］与 Stream-Table Duality（流-表二元性） ［23］的思想，我们把状态数据视为历史的副产物：通过把事件投影到时间轴上，状态总是可以被重建；因此，状态仅是针对“以当前时间投影进行查询”的一种查询优化。
双时态（Bitemporality）。 仅存储历史事件并不足以实现稳定引用。如前所述，数据消费者可以尝试利用数据集的一些内部属性（如事件时间戳、标识符或记录计数）来约定使用历史的某个子集，但这极易出错。
设想两方约定用事件时间来分割数据，取“截至当前时间 T 的所有事件”。此时，可复现性会受到多种因素的破坏：例如，数据出现于数据集的延迟、发布者对 T 之前某段时间的回填、或在发现旧数据错误后发出事件时间小于 T 的更正事件。
为避免此类情况并发布稳定的数据引用，ODF 将 Bitemporal Data Modelling（双时态数据建模） ［9, 12］应用于事件记录：在模式中新增“系统时间（System Time） ”列，记录事件首次进入系统的时间。系统时间被保证单调递增，因此，指向数据的稳定引用可以简单到“数据集 ID + 系统时间戳”。注意：事件时间并不需要满足这一单调性要求。
由此可见，事件时间表征的是“从外部世界视角某事发生的时间”，通常更适合用于查询与关联；而系统时间表征的是“从系统视角某事被系统观测到的时间”，它使我们能够在同一数据集内部以及同一计算图内的不同数据集之间建立清晰的先后关系。
2.5 派生数据中的可复现与可验证（Reproducibility and Verifiability in Derivative Data）
对通过转换与组合其他数据集而获得的派生数据而言，可复现性可理解为：能够重复全部转换步骤，并得到与原始一致的结果。相应地，可验证性是指：能够确保呈现给你的某个转换结果并未被偶然或恶意篡改。可验证性让我们可以通过两步来评估可信度：确认所有源数据来自可靠发布者，以及审计所有施加过的转换。
由此可以提炼两条要求：确定性（determinism） ——给定相同输入，所有转换应保证产出相同输出；透明性（transparency） ——所有转换都应是可知的。
这些要求虽简洁，但在现代数据科学中极难满足。一个典型项目可能包含数百个动态部件：框架与库、操作系统、硬件等。其中多数组件并非以“确定性”为目标而构建，于是实现可复现的负担完全落在实施者身上。实现确定性并非易事，它要求对执行环境有深入理解，并消除一切随机性来源。不难理解，为了满足项目进度，这样一项浩大的工程常被完全省略；结果就是现代数据科学处于可复现性危机之中［5, 19］。
我们认为，此问题无可回避：数据处理系统必须在设计之初就将可复现性作为内在属性。在“确定性”尚未成为此类系统内生属性之前，我们会采用一系列技术来尽可能减轻确保可复现性的负担（见第 4 节）。
派生数据的“瞬态性”（Derivative Data Transience）。 鉴于源数据不可变且所有派生转换确定性成立，在 ODF 中，任意转换图的派生数据都可以通过“从源数据出发、重新应用全部转换”而完全重建。因此，派生数据可被视为一种缓存。正如我们稍后讨论的，这种做法在全局上有望降低总体数据存储成本，因为此类数据无须长期持久化，也不必进行大量复制。
2.6 将流处理应用于历史数据（Applying Stream Processing to Historical Data）
当下的数据科学主要由批处理工作流主导，其关键特征是把数据视作有限的记录集合。但相当一部分数据并非静态——新的数据点在不断产生，数据集也持续更新。我们越是数据驱动，就越会把数据处理推向实时。然而，把同样的批处理技术套用到近期数据上，是一种有害的过度简化：它让我们暴露在与时态数据相关的诸多问题之下——例如迟到数据、乱序到达、对已处理数据的更正、以及参与关联的多个数据集之间到达节奏不一致等。批处理对“数据完整性”的依赖，常常导致错误结果，而这些错误往往集中在大家最关心的最新数据上。更糟的是，随着新数据到来，批处理工作流可能对同一时间区间反复产出不同结果，从而重写历史——因此必须显式地对这类更正进行处理。
要用传统批处理逻辑在大规模上正确覆盖所有时间边界情况几乎不可行。即便写得出来，其复杂性也会抵消可验证性的价值——如果转换代码复杂到难以完全理解，审计它又有何意义？
过去几年，流式数据处理领域取得了重大进展。诸如 Google Dataflow［1］、Apache Spark［30］、Apache Flink［7］、以及 Naiad/Timely Dataflow［21］等系统，提供了一套直观且强大的机制来应对上述问题。流处理范式承认一个简单事实：数据处理本质上是在延迟与正确性之间进行权衡；它让用户能够以全自动的方式掌控这组取舍。
流处理中的一个关键机制是水位线（watermark） 。水位线是一种沿着数据流与普通数据共同传播的元数据：它表示在某个系统时间 (T_s) 下，系统以较高概率 (P) 已经观测到了所有事件时间早于 (T_e) 的事件。图 2 将水位线表示为双时态事件图中的一条曲线，用以区分“按预期量迟到”的数据与“异常严重迟到”的数据。水位线既可以是预测式（系统据“事件时间—系统时间”差异的观测不断自适应调整），也可以由人手动设定（例如数据集所有者向所有消费者“提示”：早于 (T_e) 的时间段数据已完全录入）。借助水位线，流处理系统能恰到好处地延迟处理，以便应对乱序与迟到，并让用户在事件时间空间中进行计算——这比按到达时间来推理更加自然、也更易理解。对于极端迟到与回填等异常情况，系统也可通过发布更正（correction）或撤回（retraction）事件、或记录某些数据点被忽略来自动且显式地处理。所有这些，都使得流处理相比批处理更自主、更可靠、也更可组合。
传统上，流处理多用于构建对近实时数据高度响应的系统。而在 ODF 中，我们发现即便是更新极不频繁的历史数据，引入流处理语义同样大有裨益。ODF 将每一个数据集都视作一条潜在无限的事件流。在“批是流的特例”这一理念［29］之上，我们把流处理作为主要的数据转换方式。
ODF 并不规定特定的语言或框架，目标是支持多种实现。我们将在第 4.3 节介绍的两个原型转换引擎，均采用了流式 SQL 方言。下面是一个使用流—流反连接（anti-join）来检测迟发货的示例查询：
SELECT o.order_time, o.order_id
FROM orders AS o
LEFT JOIN shipments AS s
ON o.order_id = s.order_id
AND s.shipment_time BETWEEN
o.order_time AND o.order_time + INTERVAL '1' WEEK
WHERE s.shipment_id = NULL
这种做法的好处包括：
- 用户可以一次性定义查询，并“长期运行”。 这有助于最小化数据在系统中的传播延迟。
- 表达力强，关注“问什么”而非“怎么算”。 相比“如何计算结果”，流式查询更贴近“提出了什么问题”，通常也比等价的批处理查询更简洁。
- 与数据到达方式/频率无关。 无论数据是每月按 GB 级批量摄入、每小时微批，还是近实时流入——处理逻辑都可以保持不变、产出一致结果，并确保尽可能短的数据传播时延。
- 声明式特性。 流式查询是声明式的，而批处理通常是命令式的。声明式带来可对查询进行静态分析的能力，在许多场景下无需额外跟踪数据就能自动推导溯源（provenance） 。
- 高层抽象（窗口、水位线、触发器）。 这些机制让用户在可配置的延迟窗口内产出尽可能正确的结果，避免在类似批处理工作流中常见的级联误差。
值得强调的是，由数据模型 + 流处理结合所带来的低时延属性。当下我们常见到这样的情形：关键数据（例如就业形势报告，或疫情早期的新增病例报告）发布得极不频繁，以至于每次发布都会对股市造成剧烈影响，或促使决策层采取过度纠偏的行动。我们认为，批处理工作流的普遍存在是重要诱因之一——它为各个数据转换环节都平添了显著延迟，无论这些环节自动化程度多高。通过采用流处理并允许人们以与到达频率无关的方式定义转换，数据的端到端传播时间可从数周/数月缩短到数秒。新数据一抵达，即以最可用的形态提供给消费者。这符合 ODF 的一条核心设计原则：向消费者呈现数据的频率应围绕体验与可用性优化，而不应被数据流水线的限制所支配。
2.7 元数据追踪（Metadata Tracking）
在 ODF 中，数据从不会单独出现在系统里——否则我们无法判断它是否可信。因此，元数据是数据集不可或缺的一部分。元数据记录了数据的来源、如何被转换，以及在其全生命周期内影响数据外观的一切因素（见图 3）。我们将元数据视为数据的数字护照，它对可复现性、可验证性与溯源至关重要。
到目前为止，在讨论数据集时，我们假定输入、转换、结果模式（schema）等都是不变的；虽然新事件会被摄入并在系统中传播，但处理图本身被定格在某一时刻。这是一种有意的简化。随着业务性质演变、新需求出现、缺陷被发现并修复——“是否需要改动”不是问题，何时改动才是问题。若称数据为潜在无限的事件流，却不给出其随时间改进与演化的方法，便毫无意义。若每次需要更改模式或更新转换都要新建一个数据集，就意味着整个下游处理图都得从头重建。
为支持向后兼容的模式变更、转换逻辑的演进，并提供修正历史数据与查询错误的机制，我们设计了一种基于账本（ledger）的机制来记录数据集随时间演化的元数据。有关该机制的详细内容，将在讨论**元数据链（Metadata Chain）**时展开（见第 3.2 节）。
2.8 溯源（Provenance）
能够轻松理解某个具体数据点是如何产生的，对于建立信任、证明数据可依赖至关重要。可验证性可以告诉我们：为了得到结果使用了哪些数据源、执行了哪些转换，但这往往粒度过粗。而溯源则要求：能够将某一条具体数据追溯到其最终来源，理解究竟是哪些事件直接贡献了它的取值，以及为了判断其是否应出现在输出中考虑了哪些数据。
溯源［8］是现代数据科学中的一个被广泛研究的问题［26］，但在实践中，它尚未在任何广泛应用的系统或业界一流的企业数据流水线中得到充分体现。多数方案只在数据集层面实现一种简化形态——血缘（lineage） 。细粒度溯源要困难得多，因为它几乎需要贯穿数据流水线中的每个组件，并可能跨越多个彼此独立的系统。即便完全实现，由于许多现代数据系统中的数据可变这一事实，它的价值也会被限制。
我们认为，无法快速回答溯源问题，会削弱即便是完全可信的数据的公信力。因此，ODF 在设计之初就将完整溯源作为目标，并在多个层面予以支持。
首先，元数据追踪会在每次转换迭代中为输出与输入数据块建立链接。这使 ODF 能将溯源的搜索空间从整个数据集收缩到其中较小的数据块。由于数据与元数据都是不可变的，这些链接永不丢失。
其次，流式转换的声明式特性让我们能够更容易地分析查询结构。对于简单的映射类（map-style）查询，无需额外追踪信息即可自动推导溯源。
第三，对更复杂的查询，我们要求底层数据处理引擎提供溯源支持［20］。ODF 定义了溯源查询 API，具体的引擎实现需予以实现（见第 3.3 节）。
2.9 数据共享（Data Sharing）
作为一种分布式协议，ODF 在设计之初便将数据共享效率纳入考量，且前述诸多特性也直接服务于这一目标。
按定义，源数据是不可约的。ODF 不假设在源数据丢失时可以从他处取回；因此，发布根数据集的各个节点（参与方）必须对其进行持久化存储，并具备副本与高可用能力。相对地，如前所述，派生数据被视为瞬态；因此，发布派生数据集的各方可以使用成本最低的托管（甚至无需托管），不必追求持久化或重复制。
数据与元数据的不可变属性确保它们能够在无需复杂同步机制的情况下被安全、便捷地复制。由于元数据与原始数据之间通过加密方式（如哈希）绑定，除非需要保持数据私密，否则无需对数据本身加密或通过安全通道分发。通常只需安全分发元数据，并据此验证下载数据的真实性即可。元数据的体量通常比其关联的数据小几个数量级，因而易于托管与广泛分享。
综合上述性质，与普遍采用的“复制 + 版本化”做法相比（后者常导致同一数据集在不同时间点被复制出成千上万份相似拷贝），ODF 有潜力显著降低全球范围内的数据存储与分发成本。
3 实现（IMPLEMENTATION）
我们已在 Kamu CLI 工具中提供了 ODF 协议的原型实现［13］。数据转换可由我们基于 Apache Spark［30］与 Apache Flink［7］实现的两种流处理引擎完成。本节将介绍 ODF 的若干关键组件及其实现所用技术。
3.1 数据摄取（Data Ingestion）
根数据集是外部数据进入系统的入口。我们的愿景是：最终，所有根数据集都将由对某类数据拥有完全权威的组织（即可信发布者）所有，并直接以符合 ODF 规范的格式提供。作为兜底机制，我们也提供了一种方式：将根数据集链接到某个外部来源（例如通过 URL），并周期性地将其数据摄入系统。此类配置会产生数据副本，但这对于保证数据属性得以保留，并使系统其余部分免受当前数据发布中各种不良实践的影响，仍是必要的。
对于始终保留完整历史的数据源，ODF 只需将新数据复制进来，并与先前已摄取的记录进行去重即可。对于以破坏式方式发布数据的来源（如周期性状态快照），ODF 则承担“历史化（historization） ”任务——利用 变更数据捕获（Change Data Capture, CDC） 技术［2, 25］将状态数据转换为事件形式。
3.2 元数据链（Metadata Chain）
元数据链的目的是记录一切影响当前数据外观的信息与事件，包括：数据来源、处理方式、模式（schema）以及当前水位线（watermark）（见图 4）。
其设计大量借鉴了基于账本（ledger）的现有系统，如区块链［32］与版本控制系统［24］。与 ODF 中所有数据一样，元数据链是仅追加（append-only）且不可变的。它由一系列通过密码学方式相互链接的区块组成，并在区块中包含关联数据切片的哈希，整体数据结构类似于 Merkle 树［18］。
元数据链按可扩展性设计，可承载其他类型的信息，例如：
- 知识的额外语义与结构（语义、本体）；
- 相关的策略、条款、规则、合规与监管（治理）；
- 许可证、隐私与安全事项（数据托管/保管）；
- 有助于发现的数据（可检索性相关信息）；
- 用于将 ODF 连接到其他基于账本的系统的互操作性数据。
我们将其视为关键的构件：通过对最佳的数据科学与工程实践进行标准化与自动化，它将帮助我们共同提升数据质量。
3.3 引擎（Engine）
数据处理技术发展迅速。作为一个数据交换协议，我们希望 ODF 的寿命长于多数具体技术，并能随新技术出现而适配。我们也希望 ODF 能兼容数据科学不同分支所使用的各种语言与方言。因此，ODF 被设计为对“用哪种语言定义转换、由哪种框架执行转换”不持预设立场，只要它们满足协议运行所需的各项准则（如确定性）即可。
ODF 的数据处理契约的具体实现称为引擎（Engine） 。引擎负责对输入数据执行数据集中定义的查询并返回结果。比如，我们基于 Apache Spark［30］与 Apache Flink［7］的两个原型引擎，支持用一系列 Streaming SQL［6］语句来转换数据。由于引擎完全掌控所有数据转换，它们同时也负责响应溯源查询。
为保证引擎执行的转换具备确定性与可复现性，ODF 采取了若干额外措施。
3.3.1 执行环境（Execution Environment）。
引擎在一个完全隔离的环境中运行，即“沙箱（sandbox） ”，以 OCI 容器［27］实现（见图 5）。沙箱旨在阻止引擎访问当前转换输入与输出之外的任何外部资源（例如互联网或用户文件系统），以免引入非期望的非确定性来源。
这听起来很受限——确实如此。毕竟，许多常见的数据处理任务（如地理定位）依赖外部 API，而在沙箱模型下将无法访问。然而，我们坚信这是正确管理数据的必要步骤。外部资源（如 API）由公司运营，可能一夜之间消失，且常常缺乏严格的版本策略——在这样的环境下不可能实现可复现结果。若运行任何“黑盒”操作（如 API 调用），我们就必须把派生数据集重新归类为源数据，并承认其不可复现。
相反，我们设想：此类转换所用的软件算法与机器学习模型将作为引擎扩展或纯数据被纳入 ODF；推动这类转变将是我们后续研究的重点之一。
3.3.2 引擎版本化（Engine Versioning）。
为进一步强化系统的可复现性保证，我们将每一次转换与执行它的引擎的精确版本关联起来。这排除了“引擎代码变化导致结果与最初观察不一致”的可能性。为此，我们使用引擎 OCI 镜像的完整 SHA 摘要进行绑定。
随着数据集随时间演化，它可能会依赖过多不同版本的某个引擎，从而使用户为完全校验该数据集需要下载的镜像数量不可持续地增长。我们通过引擎升级流程来缓解这一问题。
3.3.3 检查点与水位线（Checkpoints & Watermarks）。
对输入数据的某些计算（如窗口聚合或时态连接）需要引擎维护状态。鉴于引擎在一次转换中必须完全消费输入数据（之后将不再见到它），部分状态需要在多次查询调用之间予以持久化。为此，ODF 允许引擎维护检查点（checkpoint） ——这是一段不透明且完全由引擎定义的数据，用于存储中间状态。与数据与元数据一起，检查点是数据集的组成部分；如果检查点丢失，相关计算就必须从头开始重跑。
ODF 中的每个数据集还拥有一个水位线［1］——即我们先前描述的元数据二元组 ((T_s, T_e))。例如，如果某个根数据集按月接收新数据，其水位线可能会落后于墙钟时间一个月以上。水位线会阻止所有派生处理越过该时间点，直到数据真正到达，从而确保计算正确性。图 2 与图 6 展示了水位线如何在事件流中防止迟到处理错误。
水位线既可在根数据集上通过固定偏移或手动设定，也会依据转换的性质在派生数据集中自动传播。由于水位线是面向消费者的重要属性，它被从检查点“提升”为元数据进行管理。
3.4 协调器（Coordinator）
协调器负责维护系统的不变量与事务语义。它处理与元数据链相关的全部操作，并保证其完整性与有效性。协调器实现数据摄取与数据共享逻辑，但将所有数据处理工作委托给引擎完成。由此，元数据管理的复杂性被完全收拢在协调器之内；从引擎的视角看，各类转换就像传统的流处理，底层数据处理框架无需定制或做成“ODF 感知”。因此，将既有的数据处理库改造成 ODF 的引擎，只需为其包一层轻量适配，使之符合 ODF 的引擎接口即可。
除查询执行外，协调器还要求引擎实现与数据集生命周期相关的若干附加操作，例如输入模式（schema）变更、查询变更以及引擎升级等处理器。
4 结论（CONCLUSION）
数据管理的未来，是一个由流式转换构成的分布式网络：来自可信发布者的数据在计算图中快速传播，始终以可直接使用的形态提供给决策者、自动化系统与 AI/ML。实现这一愿景所需的大多数技术已然可用或触手可及，但我们也认为，数据中心学科还需要一次思维方式的转变——告别那些局部最优做法：忽视数据的时间维度、把数据当作贫瘠的二进制包、不断丢失与重写我们的数字历史。
Open Data Fabric（ODF）的尝试，是先明确我们期望从数据中获得的系统性质，再围绕这些性质设计系统。我们看到，若干关键抉择——数据不可变、确定性转换、以及流处理与基于账本的元数据追踪的结合——会形成正反馈回路，显著提升数据共享效率与协作潜力。我们相信，其采纳将成为迈向更优数据状态的里程碑。这不会轻松：它要求一套比我们习惯更严格的数据处理规则——不再手工微调，不再调用“黑盒”API——但我们认为，这样的代价是值得的。同时，现代数据处理框架也必须迎接挑战：提供更强的流式与时态处理能力，并让确定性成为其内生属性。
从长期看，我们期待 ODF 成为新一代数字民主的支柱之一——作为结构化数据的主供应链，既能被点对点 Web 协议直接消费，又能为区块链智能合约提供可靠的事实数据，以建设一个更好、更互联的世界。我们也希望，即便他人未必完全认同我们的愿景，仍能从本文的若干思想中获得有益启发，共同推动这一复杂而迷人的领域不断前行。
参考文献（REFERENCES）
[1] Tyler Akidau 等. 2015. Dataflow 模型：在大规模、无界、乱序数据处理中平衡正确性、时延与成本的实用方法（The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing）. Proceedings of the VLDB Endowment 8: 1792–1803.
[2] Itamar Ankorion. 2005. 变更数据捕获：面向实时 BI 的高效 ETL（Change Data Capture: Efficient ETL for Real-Time BI）. Information Management 15(1): 36.
[3] Michael Armbrust 等. 2020. Delta Lake：云对象存储之上的高性能 ACID 表存储（Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores）. Proceedings of the VLDB Endowment 13(12): 3411–3424.
[4] Dannon Baker 等. 2020. 非常时期不再“照常营业”：应对新发病原体威胁需要开放数据与开放分析（No more business as usual: Agile and effective responses to emerging pathogen threats require open data and open analytics）. PLoS Pathogens 16(8): e1008643.
[5] Monya Baker. 2016. 可复现性危机（Reproducibility crisis）. Nature 533(26): 353–366.
[6] Edmon Begoli 等. 2018. Apache Calcite：面向异构数据源优化查询处理的基础框架（Apache Calcite: A Foundational Framework for Optimized Query Processing over Heterogeneous Data Sources）. Proceedings of the 2018 International Conference on Management of Data: 221–230.
[7] Paris Carbone 等. 2015. Apache Flink：在单一引擎中统一流与批处理（Apache Flink: Stream and Batch Processing in a Single Engine）. Bulletin of the IEEE Computer Society Technical Committee on Data Engineering 36(4): 28–38.
[8] James Cheney, Laura Chiticariu, Wang-Chiew Tan. 2009. 数据库中的溯源：为何、如何、何处（Provenance in Databases: Why, How, and Where）. Foundations and Trends in Databases 1(4): 379–474. doi.org/10.1561/190…
[9] Christopher J. Date, Hugh Darwen, Nikos Lorentzos. 2002. 时态数据与关系模型（Temporal Data & the Relational Model）. Elsevier.
[10] Martin Fowler. 2005. 事件溯源（Event Sourcing）. martinfowler.com/eaaDev/EventSourcing.html（访问日期：2020-09-10）.
[11] RDA COVID-19 工作组. 2020. RDA 关于新冠数据共享的建议与指南（RDA COVID-19 Recommendations and Guidelines on Data Sharing）. doi.org/10.15497/rd…
[12] Tom Johnston. 2014. 双时态数据：理论与实践（Bitemporal Data: Theory and Practice）. Elsevier Science & Technology, San Francisco.
[13] Kamu Data Inc. 2020. Kamu CLI——ODF 协调器的参考实现（Kamu CLI - Reference implementation of ODF coordinator）. github.com/kamu-data/k…
[14] Kamu Data Inc. 2020. Open Data Fabric——协议规范（Open Data Fabric - Protocol Specification）. opendatafabric.org
[15] Liquidata Inc. [无日期]. Dolt——面向数据的 Git（Dolt - Git for data）. github.com/liquidata-i…
[16] Vivien Marx. 2013. 大数据的巨大挑战（The Big Challenges of Big Data）. Nature 498(7453): 255. arXiv:www.nature.com/articles/49… ；www.nature.com/articles/49…
[17] Mandeep R. Mehra 等. 2020. （已撤稿）羟氯喹或氯喹联合或不联合大环内酯用于治疗 COVID-19：一项多国登记分析（RETRACTED: Hydroxychloroquine or chloroquine with or without a macrolide for treatment of COVID-19: a multinational registry analysis）. The Lancet（2020年5月）. doi.org/10.1016/S01… （撤稿：2020-06-05；勘误：2020-05-30；PMID: 32450107；PMCID: PMC7255293）.
[18] Ralph C. Merkle. 1988. 基于常规加密函数的数字签名（A Digital Signature Based on a Conventional Encryption Function）. 见 Advances in Cryptology — CRYPTO ’87. Springer, 369–378.
[19] Tsuyoshi Miyakawa. 2020. 没有原始数据，就没有科学：可复现性危机的另一潜在来源（No raw data, no science: another possible source of the reproducibility crisis）. Molecular Brain 13(1): 24.
[20] Tobias Müller, Benjamin Dietrich, Torsten Grust. 2018. 你说“是什么”，我听成“哪里/为什么”：通过（误）解 SQL 推导细粒度溯源（You Say ‘What’, I Hear ‘Where’ and ‘Why’: (Mis-)Interpreting SQL to Derive Fine-Grained Provenance）. Proceedings of the VLDB Endowment 11(11): 1536–1549. doi.org/10.14778/32…
[21] Derek G. Murray 等. 2013. Naiad：一种及时数据流系统（Naiad: A Timely Dataflow System）. Proceedings of the 24th ACM Symposium on Operating Systems Principles: 439–455.
[22] Yeo-Teh Nicole Shu Ling, Tang Bor Luen. 2020. 针对 COVID-19 科研出版物的令人担忧的撤稿率（An alarming retraction rate for scientific publications on COVID-19）. Accountability in Research 0(0): 1–7. doi.org/10.1080/089… （PMID: 32573274）.
[23] Michael Noll. 2020. Apache Kafka 中的流与表：入门（Streams and Tables in Apache Kafka: A Primer）. www.confluent.io/blog/kafka-…
[24] Stefan Otte. 2009. 版本控制系统（Version Control Systems）. Computer Systems and Telematics: 11–13.
[25] Kevin Petrie, Dan Potter, Itamar Ankorion. 2018. 流式变更数据捕获（Streaming Change Data Capture, 1st ed.）. O’Reilly Media.
[26] Yogesh L. Simmhan, Beth Plale, Dennis Gannon. 2005. 电子科学中的数据溯源综述（A Survey of Data Provenance in e-Science）. ACM SIGMOD Record 34(3): 31–36.
[27] The Linux Foundation. [无日期]. 开放容器倡议（Open Container Initiative）. opencontainers.org/
[28] The White House. 2020. 向科技社区发出号召：构建新的机器可读 COVID-19 数据集（Call to Action to the Tech Community on New Machine Readable COVID-19 Dataset）. www.whitehouse.gov/briefings-s…
[29] Kostas Tzoumas. 2015. 批处理是流处理的特例（Batch is a Special Case of Streaming）. www.ververica.com/blog/batch-…
[30] Matei Zaharia 等. 2016. Apache Spark：大数据处理的统一引擎（Apache Spark: A Unified Engine for Big Data Processing）. Communications of the ACM 59(11): 56–65.
[31] Andrew J. Zahuranec. 2020. 行动呼吁：构建我们所需的数据基础设施与生态，以应对大流行等动态的社会与环境威胁（Call for Action: Toward Building the Data Infrastructure and Ecosystem We Need to Tackle Pandemics and Other Dynamic Societal and Environmental Threats）. thegovlab.org/call-for-ac…
[32] Zibin Zheng 等. 2017. 区块链技术综述：架构、共识与未来趋势（An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends）. 2017 IEEE International Congress on Big Data (BigData Congress) : 557–564. doi.org/10.1109/Big…
