在当今信息驱动的工作场所中,数据不断地被移动和转换。典型的日常业务方法是使用电子邮件附件、共享网络位置、数据库,以及最近的云。通常情况下,数据的多个版本位于不同的位置,而这些数据的用户因缺乏描述其出处(换句话说,其沿革)的元数据而感到困惑。本文描述的橡树岭国家实验室(ORNL)的 ProvDMS 项目旨在解决传感器数据环境中的这个问题。
ORNL 的建筑技术研究和集成中心在 FRP(柔性研究平台)上部署了可重构的商业建筑。图 1 是一个中型商业办公楼的 Google Earth 模型,它是 ORNL 的 FRP 装置的一部分。这些建筑物(金属仓库和办公室)配备了大量传感器,用于测量 HVAC 效率、相对湿度以及门、窗户和墙壁的温度梯度等变量。传感器从数百个通道获取亚分钟分辨率的数据。科学家进行实验、运行模拟并分析数据。传感器数据也用于精细的质量保证工作中,以研究系统故障的影响。构成 FRP 的两种类型的商业建筑以 30 秒的分辨率流式传输数据,两个建筑物总共有 1,071 个通道。
从 FRP 收集的传感器数据被保存到研究人员可以访问的共享网络位置。显然,适当的科学控制不仅需要管理数据采集和交付,还需要管理与传感器数据的时间子集相关的元数据。FRP 的 ProvDMS 或出处数据管理系统允许研究人员检索感兴趣的数据,并追溯其沿革。大多数对象的生命周期包括创建、管理、转换、存档以及可能的删除。出处是对这些信息的跟踪。8
ProvDMS 为研究人员提供了一个用于所有数据转换的一站式平台,使他们能够有效地追溯其数据的来源,从而可以重用和重现实验及其衍生结果,而无需重复每个实验的开销。
有许多现有的软件系统用于出处数据收集,并具有强大的工作流程集成。Chimera6 是一个面向过程的出处系统,用于管理协作环境中数据对象的派生和分析。它存储出处信息,这些信息可用于在系统中重新生成、比较和审核数据派生。Karma 出处系统7 允许用户收集和查询科学数据过程的出处,并且能够独立运行或作为更大规模的网络基础设施设置的一部分运行。由于其紧密的工作流程集成,Karma 系统与其数据紧密相连。VisTrails4,5 为科学数据探索和可视化提供支持,重点是将工作流程作为出处对象来表示复杂的计算。VisTrails 中的工作流程可以可视化为程序序列的管道,这些程序序列导致计算输出。欧盟出处项目1 为网格系统使用开放的出处架构,并采用面向服务的方法,已用于航空航天工程和器官移植管理。该出处系统用于跟踪患者-医生互动单元中的医疗信息。该项目试图在收集的数据量与最小化收集工作的侵入性之间找到平衡,以保持医疗质量。
虽然许多这些系统都是完整的软件解决方案,但 CPL(核心出处库)3 被设计为独立于应用程序,并且易于集成到新的或现有系统中。由于其独立性,CPL 在 ProvDMS 中被用作出处后端。这使得 ProvDMS 的用户界面可以与 CPL 的对象约束分离,从而产生积极的用户体验。
出处的特定实现可能因一些重要属性而差异很大。ProvDMS 的重点是研究人员的需求、出处的粒度、工作流程需求和对象设计。其设计原则强调用户需求的重要性,对出处与用户工具的集成采取一致但独立的立场。
• 粒度。 大多数系统都结合了细粒度和粗粒度,以避免限制用户可用的数据类型和数量。2 ProvDMS 实施了一个细粒度系统,但为用户提供了混合粒度界面,以便使用可视化跟踪沿革是上下文相关的。用户会看到概括性的粗粒度出处对象,这些对象可以在上下文中展开以提供更细粒度的信息。这允许用户看到仍然更精细的、准确的出处对象,这些对象专门映射到系统中的逻辑对象,但用户在查看出处时不会因不必要的信息而负担过重。
• 工具与工作流程的集成。 ProvDMS 的设计很大程度上取决于与现有工具集成的“何时”和“如何”。大多数工具的出处跟踪能力有限或没有。ORNL 的研究人员通常使用来自各个供应商的各种专用工具,这些工具没有出处支持。因此,ProvDMS 不能有太多限制。虽然具有挑战性,但这促使重点转向数据基础设施需求,以在促进软件接口开发以支持未来系统集成的同时,实现出处跟踪。为了实现工作流程的感觉,ProvDMS 使用用户实验的概念,传感器数据一旦从系统导出就驻留在其中。用户可以选择任何工具,并可以选择将其实验的不同状态导入回 ProvDMS。
• 出处的出处。 出处系统跟踪其如何创建和跟踪出处对象的能力不是 ProvDMS 的初始设计要求,而是从 CPL 的能力中产生的。通过跟踪 PoP(出处的出处),ProvDMS 提供了关于出处系统何时创建新对象或对象版本、哪个用户负责创建对象、执行跟踪功能的进程 ID 以及系统信息(例如执行环境)的具体信息。该系统的管理员现在可以跟踪系统随时间的使用情况,并可以检测系统和出处数据存储的使用方式中的模式。
• 唯一性。 出处系统本质上涉及对象之间的分层连接。使用 CPL 作为出处后端允许用户轻松访问出处对象的祖先。此外,CPL 的版本控制系统确保每个对象都是唯一可识别的,这解决了用户多次定义实验的设计问题。
• 对象设计。 对象设计塑造了 ProvDMS 的整体,并且可以说是最难做出的一组决策。第一个挑战是确定用户将如何与数据交互,这将决定所需的出处对象。对于一个仍在纸上的系统来说,这很难衡量。我们不确定要存储和公开的出处粒度级别,因为很可能大部分出处数据都可能未使用。我们倾向于更精细的粒度,同时提供跨越粒度范围的支持,以应对 ProvDMS 中尚未发现的未知数。
CPL 中的出处对象使用三个主要属性唯一定义:名称、类型和创建者。在 ProvDMS 对 CPL 的使用中,名称描述对象,类型确定其粒度。创建者旨在以类似于 Java 的包命名约定的方式使用,通过分层域名空间。ProvDMS 使用系统名称作为顶级域,用户作为下一级,接口作为最终域。这确保了可理解且唯一的创建者的存在,从而区分了基于身份验证用户的实验(以及相应的出处对象)。
FRP 使用 Campbell Scientific 的数据记录器从设施中的 1,071 个通道收集数据。Campbell Scientific 的 LNDB(Loggernet 数据库)在专用服务器上运行,并将原始传感器输出填充到 MySQL 数据库中。ProvDMS 在另一台专用服务器上运行,并从 MySQL 数据库检索数据以满足用户需求,从而提供原始数据存储与出处跟踪的完全分离。LNDB 在数据服务器上创建所需的模式,并且 ProvDMS 的架构旨在感知模式及其与 FRP 的逻辑关系,以便向用户呈现简洁明了的界面。已采取检查措施以确保数据备份、安全性和隔离,因为许多数据都是专有的。
图 2 显示了 FRP 数据的物理布局的逻辑表示。这影响了 ProvDMS 的出处对象设计。如图所示,传感器数据分为站点,每个站点包含一组数据记录器。这些数据记录器由多组数据通道组成。物理上,这些通道与放置在整个测试设施中不同位置的传感器相关。
出处系统的最终目标是跟踪传感器数据的时间子集在用户实验中的参与情况。ProvDMS 将这些视为对象。研究人员将选定的传感器通道的时间子集导出为实验,然后该实验可以在用户的工作区中进行各种转换。一旦研究人员感觉准备就绪,他们可以将其实验的“状态”以及任何其他派生数据、支持文件、结果或其他元数据提交给系统。ProvDMS 允许用户将上传的文件映射为原始实验的派生。
FRP 数据的逻辑表示旨在对应于出处对象。每种类型的出处对象都与其逻辑表示相关。这些对象具有相似的表示形式,但有一些差异。重要的是,从数据记录器到其关联文件还有额外的链接。对于用户定义的实验,这些是保存传感器数据通道的文件。对于派生实验,这些是派生中使用的任何关联文件。图 3 说明了它们表示形式的差异。使用了两种类型的链接:版本依赖性和数据流依赖性。这些链接之间的差异对于 CPL 中的循环避免算法很重要。
此外,对象之间存在两种类型的链接:版本依赖性用于作为先前对象的新版本创建的对象;数据流依赖性用作不同对象之间的祖先链接,表示它们之间的数据转换。这两种类型的链接之间的差异对于 CPL 的循环避免算法非常重要(稍后将在介绍出处可视化的部分中更详细地讨论)。
在架构上,ProvDMS 采用分层设计。图 4 是一个图表,显示了其层和组件。兼容性层包括两个包装器:PHP 包装器和 C++ 包装器,PHP 包装器与之交互。C++ 包装器抽象了出处后端交互。不同的组件协同交互
• ProvDMS 层表示用于出处交互的用户界面。图 5 显示了实验创建界面,该界面允许用户选择数据子集用于实验对象,并与托管的传感器数据交互、可视化出处信息以及定义或派生实验。
• 兼容性层抽象了 CPL 的 API 调用,因此 ProvDMS 可以与底层系统交互。使用 PHP 包装器,系统可以将来自耦合软件的查询传递到数据库后端,并共享这些结果。
• 出处数据库是 ProvDMS 的存储层。数据库和兼容性层之间的交互允许在用户定义或派生实验对象同时与 ProvDMS 交互时收集出处信息。
• 传感器数据库存储 FRP 传感器数据,以及在需要时进行快速查询的存储过程。从此层检索的大多数数据在传输之前都与特定的 FRP 站点或数据记录器连接。它独立于出处系统,以便于解耦的可扩展性和与其他为 FRP 开发的软件组件的接口。
使用 CPL 允许 ProvDMS 在信息必须保存到出处数据库时独立于出处调用 API 挂钩而运行。抽象层处理用户操作到 CPL API 调用的转换,以插入或查询出处信息。这封装在一个包含 PHP 和 C++ 包装器的兼容性层中。
图 6 中的 PHP 代码演示了包装器与 C++ 的交互,以便存储或检索出处数据。
CPL 是用 C 编写的,已经包含了一些 C++ 功能。C++ 包装器通过高度面向对象的界面抽象了与 CPL 的交互。图 7 中的代码片段说明了出处对象的创建。如图所示,PHP 使用以下方式与 C++ 包装器通信exec调用。放弃 PHP 扩展的决定基于以下几个驱动因素
• 权衡。 解耦通用性与exec调用(尤其是少量调用)的性能开销之间的权衡,倾向于使用 PHPexec框架,而不是完整的 PHP 扩展。
• 简洁性。 使用exec调用外部 C++ 可执行文件,可以保持类似于bash.
的基于参数的简单调用• 来源。 将 C++ 包装器作为外部可执行文件包含在内,同时提供源代码,允许管理员根据组织需求修改包装器。
• 实施时间。 ProvDMS 的设计和实施在八到九周内完成,我们充分利用了快速开发。完整的 PHP 扩展实施超出了该项目分配的时间和预算范围。
与 CPL 的集成是 ProvDMS 实施过程中最顺利的部分之一。在不同的客户端和服务器平台上测试和使用 CPL 集成系统存在一些细微差异。Open-SUSE 12.3 用于 ProvDMS 的开发和测试,Red Hat Enterprise Linux 6 用于生产版本。
最早的障碍之一涉及 PHP 和exec的 C++ 调用的交互。为了使 CPL 提供 PoP,它必须从执行环境中提取一些信息。这对于客户端执行 CPL 代码非常有效,但是一旦 CPL 代码通过 PHPexec调用执行,某些环境变量将不再可检索。这些变量对于保存有关出处会话的信息是必要的,因此出处后端无法继续运行。快速修复以传入正确的环境信息避开了从环境变量的提取。
ProvDMS 的构建不仅是为了跟踪实验的出处,而且还是 FRP 所有传感器数据相关活动的一站式访问点。它提供以下界面功能
• 实验创建。 ProvDMS 允许用户选择站点、数据记录器和通道的子集作为新实验的定义。此信息被解析并保存为服务器上的 CSV 文件。根据请求,用户可以导出此数据。在创建时,每个实验都被出处后端定义为出处对象,出处后端还会创建所有更细粒度的对象。
• 实验派生。 用户上传并将实验定义为先前实验的派生。这意味着用户可以将他们的数据状态和任何关联文件保存在 ProvDMS 中,从而使他们能够在将来跟踪派生。
• 数据状态。 系统提供了一个仪表板,其中包含迷你图9,这有助于总结服务器上数据的状态。迷你图是小的趋势图,没有轴标签,允许它们与文本内嵌,从而允许用户轻松地挑选出数据中的趋势。迷你图可以显示来自不同传感器的关键通道的状态,以便快速评估和检测系统中的故障。
• 出处可视化。 系统提供可视化功能,以便用户可以轻松地可视化其数据的沿革。出处可视化主题值得单独讨论,并在下一节中更详细地介绍。
ProvDMS 的早期开发工作大部分都花在了确保其自然且易于使用上。例如,实验创建功能(图 5)的设计采用了有效的用户交互原则,以实现简单的“流程”,并强调在管理用户数据时效率的重要性。
任何人在开始可视化时都应该问的第一个问题类似于设计出处系统时应该问的第一个问题:“什么信息是重要的?”
CPL 的开发人员建议使用他们的 Orbiter 工具来可视化使用 CPL 的出处。Orbiter 是一个用 Java 开发的外部可视化程序。它从 CPL 数据库(在本例中为 SQL 后端)提取信息,并使用节点链接图对其进行可视化。它包括用于基于时间的可视化和节点分组的功能,用于具有公共链接的节点。它是可视化来自 CPL 数据库的信息的绝佳工具。
尽管使 Orbiter 成为 ProvDMS 的可视化工具很容易,但还是存在一些问题。其中最主要的是 CPL 使用循环避免算法来对对象进行版本控制和链接,而不会在对象出处中创建循环。上下文信息必须作为可视化的一部分显示。这意味着从 CPL 的祖先查询中删除特定信息。图 8 显示了 ProvDMS 创建的出处信息子集及其与 CPL 的集成。由于数据流依赖性和循环避免算法,存在两个版本的更细粒度对象。必须删除这些额外的节点才能清晰地可视化出处。此信息在其表示形式中是正确的,但是许多对象对用户并不重要,并且可能会在可视化中混淆数据的沿革。为了更清晰地表示出处,必须删除通过作为循环避免结果的转换对象创建的双重版本。
重要的是要注意这些解析案例的特定性。在图中,实验对象缺少额外的转换版本,因为这些实验仅通过版本依赖性链接。这意味着用户创建了一个与先前实验具有相同标识的新实验。这是 ProvDMS 与 CPL 集成以创建此实验新版本的提示。此过程绕过了通过数据流依赖性手动链接对象的需要。这种情况增加了为可视化解析各个案例的难度。
ProvDMS 的可视化是 Web 启用的,使用了各种 JavaScript 可视化库,例如 JIT(JavaScript InfoVis Toolkit)和 D3.js(数据驱动文档)。ProvDMS 包括几种类型的可视化
• 非唯一节点链接树。 由于名称、类型、创建者对象约定,CPL 出处实现中的对象本质上是唯一的。尽管对象最初是唯一创建的,但出处的性质是提供数据的分层流。对象在其生命周期中的某个时刻无疑会有多个版本。多版本对象不会将其标识从一个版本更改为另一个版本。由于只有它们的版本发生变化,因此使用此类型的可视化方法的相同约定,节点不再是唯一标识的。
• 基于力的节点链接布局。 可视化出处的经典方法侧重于从顶级出处对象(通常是选定的一个)扎根的树状视图。CPL 的对象也被设计为使用这种类型的继承,依靠后代和祖先来遍历出处信息。即便如此,以不同的方式可视化对象的沿革也可能很有用,例如采用基于力的布局。此布局仍使用节点链接格式(与其他布局一样),但它使用作用于每个节点的力系统来确定其位置。这使得系统感觉更具交互性,因为用户可以通过拖动来对图中的节点施加力。
图 9 和图 10 展示了这种类型的可视化的一些有趣结果。在图 9 中,可以看到数据沿革的可追溯流程,以及具有相似粒度的对象的自然分组。实心灰线表示出处对象之间的分层连接,这些对象分组在一起,作为与用户定义或导入的实验的单个版本相关的信息。橙色节点表示顶级实验对象,它们是所有关联的更细粒度对象(例如站点、数据记录器和通道,分别着色为蓝色、红色和绿色)的父对象。在图 10 中,最内层节点和所有更细粒度节点的连接创建了一个伪“权重”,该权重包含对象分组的整体。每个对象都有其关联的权重,这会影响所有连接节点的布局。分组倾向于在可视化中充当单个节点。
• 唯一的上下文节点链接树。 ProvDMS 中当前的可视化实现在其出处可视化模块中使用这种方法。与第一种方法类似,这种方法使用节点链接树以分层方式可视化出处。节点异步展开,在展开时从出处数据库中提取信息。可以显示某些对象的上下文信息。通过这种方式,除了对象本身之外,还可以通过处理出处对象属性来可视化更精细的粒度。图 11 是使用上下文节点链接树的这种可视化的示例。展开了两个节点以显示比其父节点更细粒度的元信息。实验节点是最粗糙的对象,而矩形中显示的特定于出处对象的信息处于最精细的粒度级别。
将出处引入科学研究的这项尝试突出了将出处应用于广义数据流的一些挑战和潜在解决方案。尽管我们成功构建了一个系统来处理 ORNL 的 FRP 的出处,但这种特定的用例使其不如许多其他出处系统通用。CPL 作为库的可用性一直是有益的。使用 CPL 取得的成功可以归因于 ProvDMS 独立于出处后端,从而在系统设计中提供了所需的灵活性。该项目期间开发的 C++ 和 PHP 包装器代码已贡献回 CPL 的作者,以供将来集成。
自动化传感器数据验证、缺失或损坏数据的估计以及传感器健康状况的机器学习估计方面的研究正在进行中,并计划将工作流程与 ProvDMS 集成。这些系统将连接到 ProvDMS 的底层,从而实现对数据有效性、故障检测和质量保证的出处进行集成跟踪。
尽管设计决策具有挑战性,但可用性既指导又限制了 ProvDMS 的能力。我们限制了收集的出处的功能和粒度,以确保最小的限制并最大限度地减少研究人员所需的额外培训。结果是一个简单的界面,供用户手动跟踪其数据和实验。ProvDMS 的模块化设计将允许随着系统的发展添加更新的出处收集方法。从我们在 ProvDMS 的设计和使用经验中获得的知识应该很快就会带来进一步的改进。
最后,ProvDMS 可以作为在通常缺乏信息跟踪方法的环境中实施和使用常见数据原型出处的示例。ProvDMS 应证明此类系统在实现可重复科学方面的强大功能。
作者感谢哈佛大学的 Peter Macko 和 Margo Seltzer,CPL 的作者,感谢他们在项目期间对 CPL 使用的支持和指导。这项工作由能源部建筑技术活动编号 EB3603000 下的实地考察提案 RAEB006 资助。我们要感谢 Edward Vineyard 对本项目的大力支持和审查。
橡树岭国家实验室由 UT-Battelle, LLC 管理,代表美国能源部,合同号为 DE-AC05-00OR22725。本手稿由 UT-Battelle, LLC 在与美国能源部的合同编号 DEAC05-00OR22725 下撰写。美国政府保留并且出版商通过接受本文发表,承认美国政府保留非独占、已付清、不可撤销的全球许可,以出版或复制本文的已发表形式,或允许他人这样做,用于美国政府目的。
1. Alvarez-Napagao, S., Vazquez-Salceda, J., Kifor, T., Varga, L. Z., Willmott, S. 2006. 在分布式器官移植管理中应用出处。在数据出处和注释中:28-36。施普林格。
2. Chapman, A., Jagadish, H. V. 构建实用出处系统中的问题。2007. IEEE 数据工程公告 30(4): 38-43。
3. Macko, P., Seltzer, M. 2012. 通用出处库。在第 4 届 Usenix 出处理论与实践研讨会上。
4. Scheidegger, C., Koop, D., Santos, E., Vo, H., Callahan, S., Freire, J., Silva, C. 2008. 一次解决一个层次的出处挑战。并发与计算:实践与经验 20(5): 473-483。
5. Silva, C. T., Freire, J., Callahan, S. P. 2007. 可视化的出处:可重复性及其他。科学与工程计算 9(5): 82-89。
6. Simmhan, Y. L., Plale, B., Gannon, D. 2005. 电子科学中数据出处调查。 Sigmod 记录 34(3): 31-36。
7. Simmhan, Y. L., Plale, B., Gannon, D. 2008. Karma 出处框架的查询功能。并发与计算:实践与经验 20(5): 441-451。
8. Szomszor, M., Moreau, L. 2003. 记录和推理 Web 和网格服务中的数据出处。在2003 年迈向有意义的互联网系统:CoopIS、DOA 和 ODBASE 中:603-620。施普林格。
9. Tufte, E. 2004. 迷你图:理论与实践;http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR&topic_id=1。
喜欢它,讨厌它? 让我们知道
Zachary Hensley 是田纳西理工大学的一名主修软件和科学应用程序的高年级计算机科学专业学生。过去两个夏天,他都在橡树岭国家实验室实习,第一个夏天在 Neutron Data Analysis and Visualization Group 工作,第二个夏天在 Energy and Transportation Sciences Division 工作。ProvDMS 项目是他第一次广泛研究数据出处,这进一步激发了他对实用应用程序应用研究的兴趣。
Jibonananda (Jibo) Sanyal 是橡树岭国家实验室建筑技术研究和集成中心的职员科学家。他目前的研究重点包括高性能计算系统上的大规模并行和可扩展能源模拟以及随后的大数据分析。他拥有密西西比州立大学计算机科学博士和硕士学位,以及印度加尔各答大学和东北山大学的两个理学学士学位。他之前的研究重点是开发和评估气象和水文领域的不确定性可视化技术和工具。
Joshua New 自 2009 年以来一直是橡树岭国家实验室的计算机科学家。他协调 ORNL 建筑技术研究集成中心在 EnergyPlus、OpenStudio 和高级模拟能力方面的能源建模工作,利用高性能计算和人工智能通过集成模拟和大数据挖掘进行建筑能源模型建模。他于 2009 年获得田纳西大学计算机科学博士学位。他拥有计算机系统和软件设计硕士学位,以及杰克逊维尔州立大学计算机科学和数学双学位理学学士学位,包括物理学辅修学位。
© 2013 1542-7730/13/1200 $10.00
最初发表于 Queue vol. 11, no. 12—
在 数字图书馆 中评论本文
Ethan Miller, Achilles Benetopoulos, George Neville-Neil, Pankaj Mehra, Daniel Bittman - 远内存中的指针
有效利用新兴的远内存技术需要考虑在父进程上下文之外操作丰富连接的数据。正在开发中的操作系统技术通过公开抽象(例如内存对象和全局不变指针)来提供帮助,这些抽象可以由设备和新实例化的计算遍历。这些想法将允许在具有分离内存节点的未来异构分布式系统上运行的应用程序利用近内存处理以获得更高的性能,并独立扩展其内存和计算资源以降低成本。
Simson Garfinkel, Jon Stewart - 磨砺你的工具
本文介绍了我们在最初发布十年后更新高性能数字取证工具 BE (bulk_extractor) 的经验。在 2018 年至 2022 年期间,我们将程序从 C++98 更新到 C++17。我们还进行了完整的代码重构并采用了单元测试框架。DF 工具必须经常更新,以跟上其使用方式的变化。对 bulk_extractor 工具更新的描述可以作为可以而且应该做什么的示例。
Pat Helland - 自主计算
自主计算是一种业务工作模式,它使用协作来连接领地及其使者。这种基于纸质表格的模式已经使用了几个世纪。在这里,我们解释了领地、协作和使者。我们研究了使者如何在自主边界之外工作,并且在保持局外人的同时也很方便。我们还研究了如何启动跨不同领地的工作,长时间运行,并最终完成。
Archie L. Cobbs - 持久性编程
几年前,我的团队正在为一个用于增强型 911 (E911) 紧急呼叫中心的商业 Java 开发项目工作。我们对尝试使用基于 SQL 数据库的传统 Java 模型来满足该项目的数据存储要求感到沮丧。在对项目的特定要求(和非要求)进行一些反思之后,我们深吸一口气,并决定从头开始创建我们自己的自定义持久性层。