注意:以下翻译的准确性尚未经过验证。这是使用 AIP ↗ 从原始英文文本进行的机器翻译。

虚拟表

虚拟表允许您在支持的数据平台中查询表,而无需先将数据存储在Foundry的数据集中。

虚拟表在Foundry外部的源系统中充当指向表的指针。虚拟表抽象掉了底层的源系统和存储格式,使您能够无缝地搭建结合不同源系统数据的工作流。虚拟表还可以与存储在Foundry中的数据集结合使用,作为一种灵活架构的一部分,数据无需在一个地方集中。

虚拟表图示

虚拟表由以下内容定义:

  • 与源存储系统的连接(例如,源URL或凭据)。此连接通过在Foundry的数据连接应用程序中设置源来建立。
  • 标识源系统中表的定位器(例如,数据库、模式和表名)。

与Foundry中的任何资源一样,虚拟表受Foundry的安全性和权限模型管理,可以在各种Foundry应用程序中打开或使用。

支持的来源

以下来源支持虚拟表。有关如何配置连接以及支持的功能的详细信息,请参阅来源文档

来源状态支持的格式手动注册自动注册
Amazon S3🟢 一般可用Avro ↗, Delta ↗, Iceberg ↗, Parquet ↗✔️
Azure Data Lake Storage Gen2 (Azure Blob Storage)🟢 一般可用Avro ↗, Delta ↗, Iceberg ↗, Parquet ↗✔️
BigQuery🟢 一般可用Table, View, Materialized View✔️✔️
Google Cloud Storage🟢 一般可用Avro ↗, Delta ↗, Iceberg ↗, Parquet ↗✔️
Snowflake🟢 一般可用Table, View, Materialized View✔️✔️

Iceberg目录

加载由Apache Iceberg表支持的虚拟表需要一个Iceberg目录。要了解有关Iceberg目录的更多信息,请参见Apache Iceberg文档 ↗。虚拟表支持不同的目录选项,具体取决于所使用的来源。下表突出显示了支持的目录。有关如何配置每个目录的详细信息,请参阅来源文档

来源AWS GlueObject StorageUnity Catalog
Amazon S3🟢 一般可用🟢 一般可用🟢 一般可用
Azure Data Lake Storage Gen2 (Azure Blob Storage)🔴 不可用🟢 一般可用🟢 一般可用
Google Cloud Storage🔴 不可用🟢 一般可用🔴 不可用

支持的Foundry工作流

虚拟表被支持作为以下应用程序和工作流中的输入:

支持的应用程序支持的工作流不支持
数据连接配置来源
注册虚拟表
基于代理的连接
Contour在Contour中分析保存为数据集
Ontology通过Pipeline Builder进行Object创建通过Ontology Manager进行Object创建
数据沿袭查看Foundry沿袭
Pipeline Builder管道输入
Object & 数据集输出
快照搭建
增量搭建(仅追加)
流式搭建
代码库Python变换

快照搭建
增量搭建(仅追加)
Java变换
SQL变换

注意某些来源类型可能不支持所有这些功能。有关详细信息,请参阅来源特定文档了解更多关于在代码库中使用虚拟表时如何配置来源的信息。

一般来说,可以通过以下方式在大多数常见的Foundry工作流中使用虚拟表:

  • 直接与上述描述的虚拟表进行交互,或
  • 创建一个由虚拟表支持的变换管道,输出Foundry数据集或Object。这些输出可以在平台中正常使用。

为虚拟表设置连接

支持虚拟表的来源在数据连接应用程序中设置。选择您要使用的来源,然后导航到来源配置中的虚拟表选项卡。按照来源文档和使用虚拟表的任何要求进行操作。

虚拟表注册

虚拟表的手动与自动注册

所有来源支持手动注册,允许您在Foundry中从源系统注册单个表。某些来源还支持自动注册,这将定期在指定项目中注册可通过配置凭据访问的来源中的所有表。

使用手动注册时,您可以选择创建虚拟表,浏览源系统中可用的表,并选择要注册的单个表。除非您选择其他位置,否则这些将注册到来源的连接设置中配置的Foundry位置。

虚拟表手动注册

启用自动注册时,您将在Foundry中创建一个新的项目,其中虚拟表将自动创建。此项目中的文件夹层次结构将反映源系统的结构,并在源中创建新表时定期更新。删除源表时,相关的虚拟表不会在项目中自动删除,但访问它们时不会加载任何数据。

要启用自动注册,您必须在Foundry中拥有项目创建权限

虚拟表自动注册屏幕

该项目由Foundry管理,用户无法在其中手动创建或更新资源。在此项目中注册的虚拟表可以导入其他项目中以用于工作流开发。

启用自动注册可以设置项目的权限和访问权限,之后可以由项目所有者通过访问侧栏进行管理。

显示虚拟表项目的资源截图

代码库中的虚拟表

当虚拟表在代码库中使用时,消耗它们的变换将自动根据来源上配置的出口策略获得网络出口。配置在来源上的凭据将必要地用于连接到来源。这与外部变换的行为类似。

来源上必须启用以下设置:

  1. 代码导入:这允许来源被导入并在代码库中使用。有关此设置及如何启用的更多详细信息,请参见此处
  2. 导出控制:这控制哪些权限标记和组织将被允许作为Python变换中使用虚拟表的输入。有关此设置及如何启用的更多详细信息,请参见此处

一旦来源已配置并导入到代码库中,虚拟表可以作为Python变换的输入使用,与数据集的使用方式相同,使用transforms.api.Input增量计算具有与数据集一致的API,并由部分来源支持。有关更多信息,请参阅来源特定文档

使用虚拟表与同步到数据集

使用虚拟表还是同步到Foundry数据集的决定取决于您的架构目标和要支持的目标工作流。我们建议在工作流的基础上考虑适当的集成模式。这两种方法可以结合使用,以相辅相成。

以下是关于使用虚拟表与同步数据到数据集的一些潜在好处、缺点和限制的考虑。

使用虚拟表的好处

虚拟表提供了许多好处,包括:

  • 通过不在Foundry中存储源数据来减少重复存储。请注意,Foundry仍将存储所有下游创建的资源的数据,例如从Foundry管道输出的数据集和Object。
  • 查询可以下推到源系统以限制总数据传输。请注意,下推计算的可用性因源系统和查询类型而异。
  • 对于非常大的表,虚拟表可能尤其有益,因为重复存储成本变得显著。
  • 使用虚拟表,数据在使用时直接查询,无需同步数据或考虑数据陈旧的可能性。
  • 虚拟表提供可选性,有助于将Foundry实施与目标架构模式对齐。

使用虚拟表的缺点

虚拟表可能并不是在所有情况下的最佳选择。一些考虑因素包括:

  • 交互性能可能比使用存储在Foundry数据集中的数据要慢。
  • 计算使用量可能会增加,具体取决于在虚拟表上运行的查询类型。例如,用作计划管道输入的表可能会生成有限的计算,而在Contour分析中频繁交互访问的表可能会产生较高的计算量。
  • 虚拟表无法从Foundry数据集功能中受益,例如数据集版本控制或分支。

使用虚拟表的限制

虚拟表的限制包括:

  • 并非所有来源都提供虚拟表。
  • 虚拟表需要与源进行直接连接。使用代理的连接不支持。
  • 并非所有Foundry应用程序和功能都支持使用虚拟表作为输入。然而,任何虚拟表下游创建的物化资源,如从管道输出的数据集和Object,均在Foundry生态系统中得到全面支持。

虚拟表查询的计算

对于直接在虚拟表上运行的查询,计算可能在Foundry和源系统之间分配。具体行为取决于查询以及源系统支持的下推计算程度。有关更多信息,请参阅来源特定文档