《Delta Lake Up & Running》第九章：Delta Sharing-灵析社区

攻城狮无远

今天经济的数据中心特性需要组织与其客户、供应商和合作伙伴之间进行广泛的数据交流。虽然效率和即时可访问性至关重要，但它们常常与安全性的考虑发生冲突。组织需要一种开放而安全的数据共享方法，以在数字经济中蓬勃发展。

通常情况下，数据共享需要在组织内部进行。组织拥有地理分散的位置和本地云解决方案。这些公司通常希望实施数据网格架构，其中所有权是分散的，数据管理是分布式和联合的。高效而安全的数据共享是有效地在整个组织中共享数据产品的关键推动因素。

企业中的不同业务组需要访问数据以做出关键的业务决策。数据团队希望集成他们的解决方案，以创建业务的全面企业视图。

传统的数据共享方法

过去，在不同平台、公司和云之间共享数据一直是一个复杂的挑战。由于担心安全风险、竞争以及实施数据共享解决方案的巨大成本，组织不愿意共享数据。

传统的数据共享技术在满足现代需求方面面临困难，例如与多个云环境兼容，支持开放格式，同时提供所需的性能。许多数据共享解决方案与特定供应商绑定，这对于在不兼容平台上运作的数据提供者和消费者造成了问题。

数据共享解决方案以三种格式发展起来：传统的和自制（定制构建）的解决方案、现代云对象存储和专有商业解决方案。每种方法都有其利弊。

传统和自制的解决方案

组织已经构建了基于传统技术（如电子邮件、SFTP或自定义API）的自制系统来实现数据共享解决方案，如图9-1所示。

这些解决方案的优势包括：

  1. 供应商无关： FTP、电子邮件和API是有着良好文档记录的协议，使数据使用者能够利用各种客户端访问提供给他们的数据。
  2. 灵活性： 许多自定义解决方案基于开源技术，使它们能够在本地和云环境中都能运行。

这些解决方案的劣势包括：

  1. 数据移动： 从云存储中提取数据、进行转换，并将其托管在FTP服务器上供不同接收方使用需要大量工作。这种方法还导致数据重复，阻碍组织即时访问实时数据。
  2. 数据共享的复杂性： 自制解决方案通常涉及复杂的体系结构，因为涉及到复制和供应。这种复杂性会在数据共享活动中增加相当多的时间，并可能导致最终用户使用过时的数据。
  3. 数据接收方的运营开销： 数据接收方需要执行数据提取、转换和加载（ETL）以适应其特定用例，进一步延迟了获取见解的时间。每当提供者更新数据时，消费者必须反复运行ETL管道。
  4. 安全性和治理： 随着现代数据要求变得更加严格，保护和管理自制和传统技术变得越来越具有挑战性。
  5. 可扩展性： 管理和维护这样的解决方案是昂贵的，它们缺乏处理大型数据集的可扩展性。

专有供应商解决方案

商业数据共享解决方案被广泛选择，是企业寻求在不建设内部解决方案的情况下寻找替代方案的一种选择。这些解决方案在不愿意为开发专有解决方案分配大量时间和资源的同时，又希望获得比云对象存储提供的更大控制力的情况下提供了一种平衡，如图9-2所示。

这种解决方案的优势：

  • 简便性

商业解决方案为用户提供了一种轻松的方式，使他们可以与同一平台上的其他用户共享数据。

这种解决方案的劣势：

  • 供应商锁定

商业解决方案通常缺乏与其他平台的互操作性，使得与使用竞争性解决方案的用户共享数据变得困难。这种限制降低了数据的可访问性，导致供应商锁定。此外，数据提供方和接收方之间的平台差异引入了数据共享的复杂性。

  • 数据移动

数据需要加载到特定的平台上，这涉及额外的步骤，如ETL和创建数据副本。

  • 可扩展性

商业数据共享解决方案可能受到供应商强加的扩展限制。

  • 成本

上述挑战为与潜在客户共享数据增加了额外的成本，因为数据提供方需要在各种云平台上为不同的接收方复制数据。

云对象存储

云对象存储被认为是云环境中非常合适的解决方案，因为它具有弹性和无缝可扩展性，可以处理大量数据并轻松适应无限增长。领先的云提供商，如Amazon S3、Azure Data Lake Storage (ADLS)和Google Cloud Storage (GCS)，提供了经济高效的对象存储服务，具有卓越的可扩展性和可靠性。 云对象存储的一个显著特点是能够生成带有签名的URL。这些URL为下载特定对象提供了有限时间的权限。通过共享预签名的URL，任何持有该URL的人都可以方便地访问指定的对象，促进了高效的数据共享。

这种解决方案的优势有：

  • 就地共享数据：对象存储可以就地共享，使消费者能够访问最新的可用数据。
  • 可扩展性：云对象存储受益于通常在本地无法实现的可用性和耐久性保证。数据消费者直接从云提供商检索数据，为提供商节省了带宽。

这种解决方案的缺点有：

  • 限于单一云提供商：接收方必须在同一云上才能访问这些对象。
  • 繁琐的安全性和治理：分配权限和管理访问存在复杂性。需要自定义应用程序逻辑来生成带有签名的URL。
  • 复杂性：管理数据共享的角色（数据库管理员、分析师）发现很难理解身份和访问管理策略以及数据是如何映射到底层文件的。对于拥有大量数据的公司，通过云存储共享是耗时、繁琐且几乎不可能扩展的。对于数据接收方来说，必须在原始文件上运行ETL管道，然后才能用于其最终用例。

这种解决方案的不完整性和繁琐性阻碍了数据提供方和接收方轻松共享数据。

开源 Delta Sharing

不同于专有解决方案，开源数据共享不涉及特定厂商技术，不引入不必要的限制和财务负担。开源 Delta Sharing 对任何需要大规模共享数据的人都是可用的。

Delta Sharing 的目标

Delta Sharing 是一个开源协议，旨在实现以下目标：

  1. 开放的跨平台数据共享： Delta Sharing 提供了一个开源、跨平台的解决方案，避免了供应商锁定。它允许在 Delta Lake 和 Apache Parquet 格式中与任何平台共享数据，无论是在本地还是在其他云上。
  2. 在不移动数据的情况下共享实时数据： 数据接收方可以直接连接到 Delta Sharing，无需复制数据。这个特性实现了现有数据的轻松实时共享，避免了不必要的数据复制或移动。
  3. 支持各种客户端： Delta Sharing 支持多种客户端，包括流行的工具如 Power BI、Tableau、Apache Spark、pandas 和 Java。它为使用不同用例的首选工具消费数据提供了灵活性，如商业智能、机器学习和人工智能。实现 Delta Sharing 连接器是快速而简单的。
  4. 集中的治理： Delta Sharing 提供强大的安全性、审计和治理功能。数据提供方可以对数据访问进行细粒度控制，允许他们共享整个表或表的特定版本或分区。对共享数据的访问从单一执行点进行管理和审计，确保了集中的控制和合规性。
  5. 大规模数据集的可扩展性： Delta Sharing 被设计用于处理大规模的结构化数据集，并支持共享非结构化数据以及未来的数据派生物，如机器学习模型、仪表板、笔记本和表格数据。Delta Sharing 利用云存储系统的经济性和可扩展性，实现了大规模数据集的经济可靠共享。

Delta Sharing 的内部机制

Delta Sharing 是一个开放的协议，定义了 REST API 端点，使得能够安全地访问云数据集的特定部分。它利用现代云存储系统（如Amazon S3、ADLS或GCS）的能力，以确保可靠地传输大型数据集。这个过程涉及到两个关键的角色：数据提供方和接收方，如图 9-3 所示。

数据提供方和接收方

作为数据提供方，Delta Sharing 允许您共享存储在云数据湖中的 Delta Lake 格式的现有表或其部分（例如，特定表的版本或分区）。数据提供方决定要共享的数据，并在其前端运行一个实现 Delta Sharing 协议并管理接收方访问权限的共享服务器。开源的 Delta Lake 包含一个参考共享服务器，Databricks 为其平台提供了一个，其他供应商预计很快也会跟进。

作为数据接收方，您只需使用支持该协议的众多 Delta Sharing 客户端之一。开源的 Delta Lake 已发布了 pandas、Apache Spark、Rust 和 Python 的开源连接器，并正在与合作伙伴合作开发更多的客户端。

实际的交换经过精心设计，通过利用云存储系统和 Delta Lake 的功能，确保了其效率。Delta Sharing 协议的工作方式如下（参见图 9-4）：

  1. 接收方的客户端进行身份验证到共享服务器（通过令牌或其他方法），并请求查询特定表。客户端还可以提供数据过滤器（例如，“country = US”）作为读取数据子集的提示。
  2. 服务器验证客户端是否被允许访问数据，记录请求，然后确定要发送回的数据。这将是组成表的 ADLS（在 Azure 上）、S3（在 AWS 上）或 GCS（在 GCP 上）中的 Parquet 文件的子集。
  3. 为了传输数据，服务器生成短暂的预签名 URL，允许客户端直接从云提供商读取这些 Parquet 文件，以便传输可以并行进行，具有大带宽，而无需通过共享服务器进行流式传输。这一功能在所有主要云中都可用，使得共享非常大型的数据集变得快速、便宜和可靠。

设计的好处

Delta Sharing 的设计为提供方和消费方带来了许多好处：

  1. 数据提供方可以轻松共享整个表，或者仅表的某个分区的版本，因为客户端只能访问其中的特定子集对象。
  2. 数据提供方可以使用 Delta Lake 上的 ACID 事务可靠地实时更新数据，接收方始终看到一致的视图。
  3. 数据接收方不需要与提供方在同一平台上，甚至不需要在云中，共享可以在云之间甚至从云到本地用户之间进行。
  4. Delta Sharing 协议对于已经使用 Parquet 的客户端来说很简单实现。
  5. 使用底层的云系统进行数据传输是快速、便宜、可靠且可并行化的。

delta-sharing 代码仓库

delta-sharing 代码仓库可以在 GitHub 上找到。其中包含以下组件：

  • Delta Sharing 协议规范。
  • Python 连接器。这是一个实现 Delta Sharing 协议的 Python 库，用于将共享的表读取为 pandas 或 PySpark 数据框。
  • Apache Spark 连接器。该连接器实现了 Delta Sharing 协议，用于从 Delta Sharing 服务器读取共享的表。然后，您可以使用 SQL、Python、Scala、Java 或 R 访问这些表。
  • Delta Sharing 协议的参考实现在 Delta Sharing 服务器中。用户可以部署此服务器来共享存储在 Azure、AWS 或 GCP 存储系统中的现有 Delta Lake 和 Parquet 格式的表。

接下来，让我们使用 Python 连接器访问由 delto-io 提供的示例 Delta Sharing 服务器中的 Delta 表。

第一步：安装 Python 连接器

Python 连接器以 delta-sharing 作为 PyPi 库提供，因此我们只需将此库添加到我们的集群中，如图 9-5 所示。

步骤 2：安装配置文件

Python 连接器根据配置文件访问共享表。您可以通过访问链接下载示例 Delta Sharing Server 的配置文件。该文件将下载为名为 open-datasets.share 的文件。这是一个包含服务器凭据的简单 JSON 文件（在此示例中，令牌已模糊处理）：

{
  "shareCredentialsVersion": 1,
  "endpoint": "https://sharing.delta.io/delta-sharing/",
  "bearerToken": "faaiexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}

使用 dbfs cp 命令将 share 文件上传到 Databricks 文件系统中的 dbfs:/ 位置：

C:\Users\bhael\Downloads>dbfs cp open-datasets.share dbfs:/mnt/.../delta-sharing/

C:\Users\bhael\Downloads>dbfs ls dbfs:/mnt/datalake/book/delta-sharing
open-datasets.share

C:\Users\bhael\Downloads>

步骤 3：读取共享表

在 "01 - Sharing Example" 笔记本中，我们可以引用该文件：

# Point to the profile file. It can be a file on the local
# file system or remote file system. In this case, we have
# uploaded the file to dbfs
profile_path = "/dbfs/mnt/datalake/book/delta-sharing/open-datasets.share"

接下来，我们可以创建一个 SharingClient，将配置文件路径传递给它，并列出所有共享的 Delta 表：

# Create a SharingClient and list all shared tables
client = delta_sharing.SharingClient(profile_path)
client.list_all_tables()

这将生成以下输出：

Out[22]: [Table(name='COVID_19_NYT', share='delta_sharing', 
schema='default'), Table(name='boston-housing', share='delta_sharing', 
schema='default'), Table(name='flight-asa_2008', share='delta_sharing', 
schema='default'), Table(name='lending_club', share='delta_sharing', 
schema='default'), Table(name='nyctaxi_2019', share='delta_sharing', 
schema='default'), Table(name='nyctaxi_2019_part', share='delta_sharing', 
schema='default'), Table(name='owid-covid-data', share='delta_sharing', 
schema='default')]

要创建指向共享表的URL，我们使用以下语法：

<profile file base name>#<share-name>.<schema-name>.<table-name>

我们现在可以构建URL并将共享的Delta表的内容读取为pandas DataFrame：

# Create a URL to access a shared table
# A table path is the profile path following with
# ('<share-name>.<schema_name>.<table_name>)
# Here, we are loading the table as a pandas DataFrame
table_url = profile_path + "#delta_sharing.default.boston-housing"
df = delta_sharing.load_as_pandas(table_url, limit=10)
df.head()

输出（仅显示相关部分）：

+--+-------+----+-----+-----+-----+-----+
|ID|crim   |zn  |indus| chas| nox | rm  |
+--+-------+----+-----+-----+-----+-----+
|1 |0.00632|18  | 2.31|  0  |0.538|6.575|
|2 |0.02731| 0  | 7.0 |  0  |0.469|6.421|
|4 |0.03237| 0  | 2.18|  0  |0.458|6.998|
|5 |0.06905| 0  | 2.18|  0  |0.458|7.147|
|7 |0.08829|12.5| 7.87|  0  |0.524|6.012|
+--+-------+----+-----+-----+-----+-----+

如果我们想将表加载为标准的 PySpark DataFrame，可以使用 load_as_spark() 方法：

# We can also access the shared table with Spark. Note that we have to use the
# dbfs:/ path prefix here
profile_path_spark = "dbfs:/mnt/datalake/book/delta-sharing/open-datasets.share"
table_url_spark = profile_path_spark + "#delta_sharing.default.boston-housing"

df_spark = delta_sharing.load_as_spark(table_url_spark)
display(df_spark.limit(5))

注意 URL 中的轻微更改，如前所讨论。这将产生与 pandas 示例相同的输出。

总结

利用开源技术实现数据交换为内部和外部使用打开了许多优势。首先，它提供了显著的灵活性，允许团队定制数据交换流程以满足特定的业务用例和要求。来自活跃的开源社区的支持确保持续改进、修复错误，并获得大量知识，进一步增强了团队和业务用户保持在数据共享实践前沿的能力。

在使用Delta Sharing进行数据提供者和数据接收者时，以下是最重要的几个关键优势： 可扩展性对于处理不断增长的数据集和高需求的用例至关重要。 互操作性是另一个重要的优势。Delta Sharing作为一种开源技术，旨在与数据生态系统的其他组件协同工作，促进无缝集成。 此外，与专有解决方案相比，透明度和安全性得到了提高，因为Delta Sharing的源代码可以进行审查，这允许采取更强的安全措施，并能够响应并主动解决已识别的漏洞。 通过使用Delta Sharing，团队避免了对供应商的依赖，因为他们可以自由切换工具或供应商，而无需投资于适应新架构。开源社区中创新的快速步伐使团队能够拥抱尖端功能，并迅速适应数据管理和分析领域的新趋势。 利用Delta Sharing进行数据共享使数据生态系统更加敏捷、具有成本效益，并为在不断变化的环境和数据格局中实现组织成功提供了更好的数据驱动解决方案和洞察。

在已学到的基础组件基础上，第10章将深入探讨如何构建完整的数据湖仓。

阅读量：1984

点赞量：0

收藏量:0