23、OGSA–DAI：分布式数据管理的未来与总结

OGSA–DAI：分布式数据管理的未来与总结

1. OGSA–DAI及其分布式数据管理方法

OGSA–DAI（Open Grid Services Architecture - Data Access and Integration）提供了一个强大的框架，用于管理和处理分布式数据。它通过工作流来表示和执行涉及多个分布式异构数据源的复杂数据相关操作场景。这些工作流不仅可以封装复杂的分布式数据管理场景，还可以访问、更新、组合和转换来自一个或多个来源的数据。OGSA–DAI还提供了一个抽象层，使用户能够专注于数据分析和处理，而不必担心数据的位置、模型、传输以及集成优化策略等后勤和技术问题。

1.1 工作流的强大功能

OGSA–DAI的工作流功能非常强大，它不仅能够处理复杂的分布式数据管理场景，还能通过分布式查询处理器和关系视图组件进一步增强数据处理能力。这些组件允许将分布式数据源视为单一资源进行查看和查询，从而简化了数据访问和处理的过程。例如，用户可以通过一个单一的查询来获取来自多个数据源的数据，并对其进行聚合和转换。

2. 抽象层的重要性

OGSA–DAI在客户端和感兴趣的数据之间提供了一个抽象层。这个抽象层不仅仅是简单的数据访问接口，它还隐藏了数据的物理位置、连接复杂性和数据源的具体类型。这种抽象使得用户可以专注于数据的逻辑处理，而不需要关心底层的技术细节。例如，用户可以通过一个统一的接口访问关系型数据库、XML数据库、文件系统、RDF三元组存储或SPARQL端点，而不需要为每个数据源编写特定的访问代码。

2.1 数据源的多样性

OGSA–DAI支持多种类型的数据源，包括但不限于：
- 关系型数据库 ：如MySQL、PostgreSQL、Oracle等。
- XML数据库 ：如eXist-db、BaseX等。
- 文件系统 ：如本地文件系统、HDFS等。
- RDF三元组存储 ：如Apache Jena、Virtuoso等。
- SPARQL端点 ：如Fuseki、Blazegraph等。

数据源类型	示例
关系型数据库	MySQL, PostgreSQL
XML数据库	eXist-db, BaseX
文件系统	本地文件系统, HDFS
RDF三元组存储	Apache Jena, Virtuoso
SPARQL端点	Fuseki, Blazegraph

3. 安全性和性能优化

尽管OGSA–DAI提供了一层抽象，但这并不意味着忽视了安全性和性能问题。事实上，OGSA–DAI在设计时充分考虑了这些因素，并提供了一系列机制来确保数据的安全性和高效处理。

3.1 安全性

OGSA–DAI的安全性主要体现在以下几个方面：
- 安全上下文 ：OGSA–DAI框架提供了一个通用容器，用于传递任何与安全相关的信息。例如，Globus Toolkit安全凭证可以被添加到安全上下文中，以确保数据访问的安全性。
- 登录提供者 ：OGSA–DAI提供了示例登录提供者，可以将包含Globus Toolkit凭证的安全上下文映射到用户名和密码。其他实现（例如来自VOMS属性）也是可能的。

graph TD;
    A[安全上下文] --> B[客户端凭证];
    B --> C[登录提供者];
    C --> D[数据库凭证];
    D --> E[数据访问];

3.2 性能优化

OGSA–DAI的性能优化主要集中在以下几个方面：
- 数据传输 ：通过Web服务传输数据，尤其是二进制数据，可能会比直接方法（如FTP或GridFTP）慢。OGSA–DAI提供了多种数据传输方法，以提高传输效率。例如，数据可以通过电子邮件地址、HTTP GET从URL、FTP服务器、GridFTP服务器等方式传输。
- 并发执行 ：所有活动并发执行，这意味着它们的操作是多线程的，从而提高了处理效率。流式传输减少了服务器上的内存占用，并缩短了执行时间。

4. 应用案例

OGSA–DAI已经在多个领域得到了广泛应用，包括天文学、地球科学、地理空间信息系统、化学、生物化学、医学、社会科学、交通、环境、古典学等。以下是几个典型的应用案例：

4.1 健康信息学

在健康信息学领域，OGSA–DAI被用于聚合和分析来自多个诊所的患者数据。例如，通过聚合不同诊所的患者数量，可以识别潜在的传染病爆发。具体步骤如下：
1. 从每个诊所获取出现相关症状的患者数量以及患者的邮政编码。
2. 将这些数据合并或联合起来。
3. 确定每个邮政编码的最终总次数。

SELECT SUM(count) AS total, postcode 
FROM (
    SELECT COUNT(*) AS count, postcode 
    FROM patients 
    WHERE symptom = 'FLU' 
    GROUP BY postcode
) 
GROUP BY postcode;

4.2 地理空间信息系统

在地理空间信息系统中，OGSA–DAI被用于处理和分析来自多个传感器的数据。例如，通过聚合不同传感器的数据，可以生成详细的地理空间分布图。具体步骤如下：
1. 从每个传感器获取数据。
2. 将这些数据合并或联合起来。
3. 生成地理空间分布图。

graph TD;
    A[传感器1] --> B[数据合并];
    C[传感器2] --> B;
    B --> D[地理空间分布图];

5. 关系视图和分布式查询处理

OGSA–DAI提供了关系视图和分布式查询处理（DQP）功能，这些功能极大地增强了数据处理能力。

5.1 关系视图

关系视图是一种命名的虚拟表，由存储查询的结果集组成。OGSA–DAI视图资源允许在OGSA–DAI公开的任何资源之上创建关系视图，并能够执行SQL查询。视图资源看起来像是只读的关系型资源，提供表结构并执行查询。

5.2 分布式查询处理

DQP是一组OGSA–DAI数据资源、活动和其他组件，它们在OGSA–DAI框架内运行，以支持跨关系数据源的分布式查询处理。DQP资源是一种OGSA–DAI数据资源，是DQP的核心组件。从客户端的角度来看，它是一个只读的关系型资源，能够回答用SQL表达的声明式查询。

---

---

下一部分将继续探讨OGSA–DAI的互操作性、性能评估、相关工作以及未来发展方向等内容。

6. 互操作性

OGSA–DAI能够与其他应用程序或中间件协同工作，这对于分布式计算、网格和云计算环境非常重要。这种互操作性促进了OGSA–DAI被现有基础设施采纳，并允许OGSA–DAI与其他产品一起使用，以构建解决复杂分布式计算问题的解决方案。

6.1 中介者和替代展示层

OGSA–DAI的互操作性可以通过使用中介者或通过替代的展示层来实现。中介者组件位于应用程序和OGSA–DAI之间，将应用程序的请求转换为OGSA–DAI的调用，并将OGSA–DAI的响应转换为其他应用程序可以消费的响应。例如，OGSA–DAI的JDBC驱动程序将Java JDBC API调用转换为通常的SQL调用，将数据库元数据的查询和请求转换为OGSA–DAI工作流，并将结果转换回JDBC API响应。

另一种方法是使用替代的OGSA–DAI展示层。尽管OGSA–DAI附带了一个网络服务展示层，但OGSA–DAI的设计使得底层框架不依赖于网络服务，因此可以被替换。例如，SEE-GEO项目用符合OGC标准的地理链接服务替换了OGSA–DAI服务，这些服务将请求映射到OGSA–DAI工作流中。

6.2 Web服务编排引擎

OGSA–DAI能够暴露可以通过HTTP访问的数据，这促进了互操作性。例如，Google Map API允许在互联网浏览器中渲染的Google地图上覆盖在KML文档中指定的功能。OGSA–DAI服务器可以查询数据并将其转换为KML文档，然后返回提供访问此文档的servlet的URL。此URL可以传递给Google Map API以进行渲染。使用servlet和提供数据访问的URL也允许OGSA–DAI在Web服务编排引擎的上下文中使用，例如Taverna。这些通常会传递数据引用，使用URL意味着这些引擎不必扩展OGSA–DAI特定组件。

7. 性能评估

OGSA–DAI组件在数据生产者和数据消费者之间进行调解，因此性能是一个重要的考虑因素。执行复杂的分布式数据管理操作的好处是否能够抵消访问和更新数据时增加的时间，是评估的关键。

7.1 性能测试结果

性能评估得出了一些发现：
- 与JDBC对比 ：OGSA–DAI使用JDBC，因此其速度不可避免地会比JDBC慢。然而，随着结果中行数的增加，OGSA–DAI的开销比JDBC增加得更快。
- 传输格式 ：WebRowSet XML只应作为小数据集的传输格式使用。除非客户端特别需要数据作为XML，否则其他表示形式（例如逗号分隔值或自定义二进制格式）在交付时间和服务器可以在单个Web服务调用中返回给客户端的数据量方面都会更快。
- 传输方法 ：Web服务不是传输大量数据的最佳方式，尤其是二进制数据。其他传输方法（例如SOAP附件、FTP或GridFTP）在交付时间和数据量方面可以提高性能。
- 并发访问 ：对于特定部署，并且取决于OGSA–DAI服务器宿主机器的具体质量，存在一个临界并发客户端数量，超过这个数量后，OGSA–DAI的性能将显著下降，无论是在CPU消耗还是内存使用方面。
- 安全性开销 ：使用Globus Toolkit安全会增加开销，但通常这是恒定的，并且在处理大量数据时，它在OGSA–DAI调用的往返时间中只占很小的一部分。

7.2 性能优化建议

为了优化性能，OGSA–DAI提供了多种灵活性：
- 非基于Web服务的交付活动 ：支持FTP、GridFTP等传输方法。
- 配置并发请求数量 ：允许配置DRER可以执行的并发请求数量。
- 替代展示层 ：允许使用REST端点或直接Java连接替代Web服务展示层。

8. 相关工作

已经开发了许多工具来解决分布式数据管理中的问题。这些工具根据它们被设计来解决的特定分布式数据管理挑战，在细微或显著的方式上有所不同。

8.1 AMGA

AMGA（Advanced Metadata Grid Architecture）是一个主要针对网格环境中处理元数据的元数据目录。它已经为处理来自大型强子对撞机的输出而开发的环境。AMGA实现了自己的查询语言，该语言类似于SQL，尽管从1.9版本开始，有一些SQL-92的支持。AMGA有一个符合OGF WS-DAIR标准的Web服务前端，以及一个专有客户端API。尽管AMGA可以作为数据库的通用包装器，但其主要目的是作为元数据目录。

8.2 GRelC

GRelC（Grid Relational Catalog）可以为关系型、XML和基于文件的资源提供一个Web服务封装。这允许从如何连接到这些类型资源的具体细节中抽象出来，但并不从被访问的底层数据资源类型中抽象出来。GRelC还通过使用其GRelC数据收集服务支持数据集成，该服务允许将SQL查询传播到其他各种GRelC介导的服务，并将结果在原始提交节点合并。这与OGSA–DAI的分布式查询处理器类似，尽管功能较为简单。

8.3 iRODS

iRODS（Integrated Rule-Oriented Data System）提供了一个虚拟化层，可以联合和复制许多不同类型的数据，但主要是在文件空间领域。它们有一种服务模式的操作方式，其中微服务可以组合在一起形成规则，这些规则有效地充当服务器端工作流，由事件触发。iRODS与SRB一样，在许多社区得到了广泛采用，尽管它可以访问数据库，但其优势在于文件访问，因此其应用空间与OGSA–DAI重叠。

8.4 其他DQP解决方案

已经开发了各种产品来支持分布式查询处理（DQP）能力，如SkyQuery、MOBIUS项目和XAware。这些解决方案采用中介器-包装器架构，用于整合特定领域的数据。商业产品如IBM WebSphere Information Integrator和Virtuoso Virtual Database也提供了类似的数据联邦功能。

9. 结论与未来方向

OGSA–DAI提供了一个强大的框架，用于管理和处理分布式数据。它通过工作流来表示和执行涉及多个分布式异构数据源的复杂数据相关操作场景，提供了强大的分布式数据管理能力，如DQP和SQL视图组件。OGSA–DAI已经被广泛应用于多个领域，提供了创新的数据管理解决方案。

9.1 未来发展方向

OGSA–DAI的未来发展将集中在以下几个方面：
- 扩展DQP能力 ：将DQP能力从关系领域扩展到RDF领域，以支持更多类型的数据源。
- 提升性能 ：通过优化数据传输方法、并发执行机制和安全机制，进一步提升性能。
- 增强互操作性 ：继续改进与其他应用程序和中间件的互操作性，以适应不断变化的计算环境。
- 社区支持 ：继续扩大社区支持，鼓励更多开发者和用户参与OGSA–DAI的开发和应用。

总之，OGSA–DAI在分布式数据管理领域已经取得了显著成就，并将继续推动该领域的发展，为用户提供更强大、更灵活的数据管理解决方案。