

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 加入 Lake Formation 权限
<a name="onboarding-lf-permissions"></a>

AWS Lake Formation 使用 AWS Glue Data Catalog （数据目录）以目录、数据库和表的形式存储 Amazon S3 数据湖和外部数据源（例如 Amazon Redshift）的元数据。Data Catalog 中的元数据按三级数据层次结构（包括目录、数据库和表）进行组织。它将各种来源的数据组织到称为目录的逻辑容器中。数据库是表的集合。数据目录还包含资源链接，这些链接是指向外部账户中共享数据库和表的链接，用于跨账户访问数据湖中的数据。每个 AWS 账户在每个 AWS 区域都有一个数据目录。

 Lake Formation 提供了关系数据库管理系统（RDBMS）权限模型，用于授予或撤销对 Data Catalog 中的目录、数据库、表和列以及 Amazon S3 中的基础数据的访问权限。

在了解 Lake Formation 权限模型的详细信息之前，查看以下背景信息会很有帮助：
+ Lake Formation 管理的数据湖位于 Amazon Simple Storage Service (Amazon S3) 中的指定位置。Data Catalog 还包含目录对象。每个目录都代表来自 Amazon Redshift 数据仓库、 Amazon DynamoDB 数据库，以及第三方数据来源（例如 Snowflake、MySQL）和 30 多个外部数据来源（它们通过联合连接器进行集成）的数据。
+ Lake Formation 维护一个数据目录，其中包含有关要导入数据湖的源数据（例如日志和关系数据库中的数据）以及有关 Amazon S3 中数据湖中的数据的元数据。Data Catalog 还包含来自 Amazon S3 以外的外部数据来源的数据的相关元数据。元数据以目录、数据库和表的形式进行组织。元数据表包含架构、位置、分区以及有关它们所表示的数据的其他信息。元数据数据库是表的集合。
+  Lake Formation 数据目录与 AWS Glue 使用的数据目录相同。您可以使用 AWS Glue 爬网程序创建数据目录表，也可以使用 AWS Glue 提取、转换、加载 (ETL) 作业来填充数据湖中的基础数据。
+ Data Catalog 中的目录、数据库和表称为“Data Catalog 资源”**。数据目录中的表称为“元数据表”，以区别于数据来源中的表或 Amazon S3 中的表格数据。**元数据表在 Amazon S3 或数据来源中指向的数据称为“基础数据”。**
+ *委托*人是指用户或角色、Amazon Quick 用户或群组、通过 SAML 提供商向 Lake Formation 进行身份验证的用户或群组，或者用于跨账户访问控制的 AWS 账户 ID、组织 ID 或组织单位 ID。
+ AWS Glue抓取工具可以创建元数据表，但您也可以使用 Lake Formation 控制台、API 或 AWS Command Line Interface (AWS CLI) 手动创建元数据表。创建元数据表时，必须指定一个位置。创建数据库时，位置是可选的。表位置可以是 Amazon S3 位置或数据来源位置，例如 Amazon Relational Database Service (Amazon RDS) 数据库。数据库位置始终是 Amazon S3 位置。
+ 与 Lake Formation 集成的服务（如 Amazon Athena 和 Amazon Redshift）可以访问数据目录以获取元数据并检查运行查询的授权。有关集成服务的完整列表，请参阅 [AWS 与 Lake Formation 的服务集成](service-integrations.md)。

**Topics**
+ [Lake Formation 权限概述](lf-permissions-overview.md)
+ [Lake Formation 角色和 IAM 权限参考](permissions-reference.md)
+ [更改数据湖的默认设置](change-settings.md)
+ [隐式 Lake Formation 权限](implicit-permissions.md)
+ [Lake Formation 权限参考](lf-permissions-reference.md)
+ [集成 IAM Identity Center](identity-center-integration.md)
+ [向数据湖添加 Amazon S3 位置](register-data-lake.md)
+ [混合访问模式](hybrid-access-mode.md)
+ [在中创建对象 AWS Glue Data Catalog](populating-catalog.md)
+ [在 Lake Formation 中使用工作流导入数据](workflows.md)

# Lake Formation 权限概述
<a name="lf-permissions-overview"></a>

 AWS Lake Formation中有两种主要类型的权限：
+ 元数据访问权限 - 对数据目录资源的权限（数据目录权限）。**

  这些权限使主体能够创建、读取、更新和删除数据目录中的元数据数据库和表。
+ 基础数据访问- Amazon Simple Storage Service （Amazon S3）中位置的权限（*数据访问权限*和*数据位置权限*）。
  + 数据湖权限使主体能够在基础 Amazon S3 位置中读取和写入数据，即数据目录资源指向的数据。**
  + 数据位置权限使主体能够创建和更改指向特定 Amazon S3 位置的元数据数据库和表。

对于这两个区域，Lake Formation 都使用了 Lake Formation 权限和 AWS Identity and Access Management (IAM) 权限的组合。IAM 权限模型由 IAM 策略组成。Lake Formation 权限模型是作为 DBMS 风格的 GRANT/REVOKE 命令实现的，例如。`Grant SELECT on tableName to userName`

当主体请求访问数据目录资源或基础数据时，请求必须通过 IAM 和 Lake Formation 的权限检查才能成功。

![\[请求者的请求必须通过两扇“门”才能访问资源：Lake Formation 权限和 IAM 权限。\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/permissions_doors.png)


Lake Formation 权限控制对数据目录资源、Amazon S3 位置以及这些位置的基础数据的访问。IAM 权限控制对 Lake Formati AWS Glue APIs on 和资源的访问。因此，尽管您可能具有在数据目录 (`CREATE_TABLE`) 中创建元数据表的 Lake Formation 权限，但如果您不具有对 `glue:CreateTable` API 的 IAM 权限，您的操作将失败。（为什么需要 `glue:` 权限？因为 Lake Formation 使用 AWS Glue Data Catalog。）

**注意**  
Lake Formation 权限仅适用于被授予这些权限的区域。

AWS Lake Formation 要求授权每个委托人（用户或角色）对 Lake Formation 托管资源执行操作。主体由数据湖管理员或其他有权授予 Lake Formation 权限的主体授予必要的授权。

当您向主体授予 Lake Formation 权限时，您可以选择授予将该权限传递给其他主体的能力。

你可以使用 Lake Formation API、 AWS Command Line Interface (AWS CLI) 或 Lake Formation 控制台**的数据权限****和数据位置**页面来授予和撤销 Lake Formation 权限。

# 精细访问控制的方法
<a name="access-control-fine-grained"></a>

使用数据湖时，目标是对数据进行精细访问控制。在 Lake Formation 中，这意味着对数据目录资源和 Amazon S3 位置进行精细访问控制。您可以使用以下方法之一实现精细访问控制。


| 方法 | Lake Formation 权限 | IAM 权限 | 评论 | 
| --- | --- | --- | --- | 
| 方法 1： | 打开 | 精细 |  **这是默认方法**，用于向后兼容 AWS Glue。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/access-control-fine-grained.html) 在 Lake Formation 控制台上，此方法显示为**仅使用 IAM 访问控制**。  | 
| 方法 2： | 精细 | 粗粒度 |  **这是推荐的方法。** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/access-control-fine-grained.html)  | 

**重要**  
请注意以下事项：  
默认情况下，Lake Formation 启用了**仅使用 IAM 访问控制**设置，以便与现有 AWS Glue Data Catalog 行为兼容。我们建议您在过渡到使用 Lake Formation 权限后禁用这些设置。有关更多信息，请参阅 [更改数据湖的默认设置](change-settings.md)。
数据湖管理员和数据库创建者具有您必须了解的隐式 Lake Formation 权限。有关更多信息，请参阅 [隐式 Lake Formation 权限](implicit-permissions.md)。

# 元数据访问控制
<a name="access-control-metadata"></a>

对于数据目录资源的访问控制，以下讨论假定使用 Lake Formation 权限进行精细访问控制，并使用 IAM 策略进行粗粒度访问控制。

有两种不同的方法可以授予对数据目录资源的 Lake Formation 权限：
+ **命名资源访问控制** - 使用此方法，您可以通过指定数据库名称或表名称来授予对特定数据库或表的权限 授予形式如下：

  [使用授予选项] 向**主体授予对**资源的权限**。

  使用授予选项，您可以允许被授权者向其他主体授予权限。
+ **基于标签的访问控制** - 使用此方法，您可以为数据目录数据库、表和列分配一个或多个 LF 标签，并向主体授予对一个或多个 LF 标签的权限。每个 LF 标签都是一个键值对，例如 `department=sales`。具有与数据目录资源上的 LF 标签匹配的主体可以访问该资源。对于包含大量数据库和表的数据湖，建议使用此方法。[Lake Formation 基于标签的访问控制](tag-based-access-control.md)中对此进行了详细说明。

主体对资源具有的权限是这两种方法授予的权限的联合。

下表汇总了对数据目录资源可用的 Lake Formation 权限。列标题表示被授予权限的资源。


| 目录 | 数据库 | 表 | 
| --- | --- | --- | 
| CREATE\$1DATABASE | CREATE\$1TABLE | ALTER | 
|  | ALTER | DROP | 
|  | DROP | DESCRIBE | 
|  | DESCRIBE | SELECT\$1 | 
|  |  | INSERT\$1 | 
|  |  | DELETE\$1 | 

例如，`CREATE_TABLE` 权限是针对数据库授予的。例如，这意味着允许主体在该数据库中创建表。

带星号 (\$1) 的权限是针对数据目录资源授予的，但它们适用于基础数据。例如，通过对元数据表的 `DROP` 权限，您可以从数据目录中删除该表。但是，通过对同一表授予的 `DELETE`权限，您可以使用 SQL `DELETE` 等语句删除 Amazon S3 中表的基础数据。通过这些权限，您还可以在 Lake Formation 控制台上查看表，并使用 AWS Glue API 检索有关表的信息。因此，`SELECT`、`INSERT` 和 `DELETE` 既是数据目录权限，也是数据访问权限。

对表授予 `SELECT` 权限时，您可以添加包含或排除一列或多列的筛选条件。这允许对元数据表列进行精细访问控制，从而限制集成服务的用户在运行查询时可以看到的列。仅使用 IAM 策略时无法使用此功能。

还有一个名为 `Super` 的特殊权限。`Super` 权限使主体能够对被授予该权限的数据库或表执行所有支持的 Lake Formation 操作。此权限可以与其他 Lake Formation 权限共存。例如，您可以授予对元数据表的 `Super`、`SELECT`、和 `INSERT` 权限。主体可以对表执行所有支持的操作，当您撤销 `Super` 时，`SELECT` 和 `INSERT` 权限将保留。

有关每项权限的详细信息，请参阅 [Lake Formation 权限参考](lf-permissions-reference.md)。

**重要**  
为了能够查看其他用户创建的数据目录表，您必须至少被授予对该表的一项 Lake Formation 权限。如果您被授予对该表的至少一项权限，则还可以查看该表中包含的数据库。

您可以使用 Lake Formation 控制台、API 或 AWS Command Line Interface (AWS CLI) 来授予或撤销数据目录权限。以下是向用户授予在`retail`数据库中创建表的`datalake_user1`权限的 AWS CLI 命令示例。

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 
 --permissions "CREATE_TABLE" --resource '{ "Database": {"Name":"retail"}}'
```

以下是粗粒度访问控制 IAM 策略的示例，该策略使用 Lake Formation 权限对精细访问控制进行了补充。它允许对任何元数据数据库或表执行所有操作。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "glue:*Database*",
                "glue:*Table*",
                "glue:*Partition*"
            ],
            "Resource": "*"
        }
    ]
}
```

------

下一个示例也是粗粒度访问控制，但在某种程度上更具限制性。它允许对指定账户和区域中数据目录中的所有元数据数据库和表进行只读操作。

------
#### [ JSON ]

****  

```
{  
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "glue:GetTables",
                "glue:SearchTables",
                "glue:GetTable",
                "glue:GetDatabase", 
                "glue:GetDatabases"
            ],
            "Resource": "arn:aws:glue:us-east-1:111122223333:*"
        } 
    ]   
}
```

------

将这些策略与以下策略进行比较，后者实现了基于 IAM 的精细访问控制。它仅授予对指定账户和区域中客户关系管理 (CRM) 元数据数据库中的部分表的权限。

------
#### [ JSON ]

****  

```
{  
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "glue:GetTables",
                "glue:SearchTables",
                "glue:GetTable",
                "glue:GetDatabase", 
                "glue:GetDatabases"
            ],
            "Resource": [
                "arn:aws:glue:us-east-1:111122223333:catalog",
                "arn:aws:glue:us-east-1:111122223333:database/CRM",
                "arn:aws:glue:us-east-1:111122223333:table/CRM/P*"
            ]
        } 
    ]   
}
```

------

有关粗粒度访问控制策略的更多示例，请参阅 [Lake Formation 角色和 IAM 权限参考](permissions-reference.md)。

# 基础数据访问控制
<a name="access-control-underlying-data"></a>

当集成 AWS 服务请求访问由控制的 Amazon S3 位置的数据时 AWS Lake Formation，Lake Formation 会提供访问数据的临时凭证。

要使 Lake Formation 能够控制对 Amazon S3 位置基础数据的访问，请向 Lake Formation 注册该位置。**

注册 Amazon S3 位置后，您即可开始授予以下 Lake Formation 权限：
+ 对指向该位置的数据目录表的数据访问权限（`SELECT`、`INSERT` 和 `DELETE)`）。
+ 对该位置的数据位置权限。

Lake Formation 数据位置权限可控制创建指向特定 Amazon S3 位置的数据目录资源的能力。数据位置权限为数据湖中的位置提供了一层额外的安全保护。当您向主体授予 `CREATE_TABLE` 或 `ALTER` 权限时，您还会授予数据位置权限，以限制主体可以为其创建或更改元数据表的位置。

Amazon S3 位置是存储桶下的存储桶或前缀，但不是单个 Amazon S3 对象。

您可以使用 Lake Formation 控制台、API 或 AWS CLI来向主体授予数据位置权限。授予的一般形式如下：

```
grant DATA_LOCATION_ACCESS to principal on S3 location [with grant option]
```

如果包含 `with grant option`，则被授权者可以向其他主体授予权限。

回想一下，Lake Formation 权限始终与 AWS Identity and Access Management (IAM) 权限结合使用，以实现精细的访问控制。对于 read/write 底层 Amazon S3 数据的权限，按如下方式授予 IAM 权限：

注册位置时，您需要指定一个 IAM 角色以授予对该位置的读/写权限。Lake Formation 在为集成 AWS 服务提供临时证书时担任该角色。典型角色可能附加了以下策略，其中注册位置为存储桶 `awsexamplebucket`。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket"
            ]
        }
    ]
}
```

------

Lake Formation 提供了一个服务相关角色，您可以在注册期间使用该角色自动创建此类策略。有关更多信息，请参阅 [在 Lake Formation 中使用服务相关角色](service-linked-roles.md)。

因此，注册 Amazon S3 位置会授予对该位置所需的 IAM `s3:` 权限，其中这些权限由用于注册该位置的角色指定。

**重要**  
避免注册启用了**请求者付费**的 Amazon S3 存储桶。对于在 Lake Formation 中注册的存储桶，用于注册存储桶的角色始终被视为请求者。如果存储桶被其他 AWS 账户访问，则如果该角色与存储桶拥有者属于同一个账户，则该存储桶拥有者需要支付数据访问费用。

要 read/write 访问基础数据，除了 Lake Formation 权限外，委托人还需要 `lakeformation:GetDataAccess` IAM 权限。获得此权限后，Lake Formation 将授权访问数据的临时凭证请求。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "lakeformation:GetDataAccess",
            "Resource": "*"
        }
    ]
}
```

------

 在上述策略中，必须将 Resource 参数设置为“\$1”（全部）。不支持为此权限指定任何其他资源。此配置确保 Lake Formation 可以高效地管理整个数据湖环境中的数据访问。

**注意**  
Amazon Athena 要求用户具有 `lakeformation:GetDataAccess` 权限。其他集成服务要求其基础执行角色具有 `lakeformation:GetDataAccess` 权限。

此权限包含在 [Lake Formation 角色和 IAM 权限参考](permissions-reference.md)中的建议策略中。

总而言之，要让 Lake Formation 主体能够通过由 Lake Formation 权限控制的访问权限读取和写入基础数据，请执行以下操作：
+ 向 Lake Formation 注册包含此类数据的 Amazon S3 位置。
+ 创建指向基础数据位置的数据目录表的主体必须具有数据位置权限。
+ 读取和写入基础数据的主体必须对指向基础数据位置的数据目录表具有 Lake Formation 数据访问权限。
+ 在向 Lake Formation 注册基础数据位置时，读取和写入基础数据的主体必须具有 `lakeformation:GetDataAccess` IAM 权限。

**注意**  
如果您可以通过 IAM 或 Amazon S3 策略访问 Amazon S3 位置，则 Lake Formation 权限模型不会阻止通过 Amazon S3 API 或控制台访问 Amazon S3 位置。您可以将 IAM 策略附加到主体以阻止此访问。

**有关数据位置权限的更多信息**  
数据位置权限控制对数据目录数据库和表的创建和更新操作的结果。规则如下：
+ 主体必须对 Amazon S3 位置具有显式或隐式数据位置权限，才能创建或更新指定该位置的数据库或表。
+ 使用控制台、API 或授予显式权限`DATA_LOCATION_ACCESS` AWS CLI。
+ 当数据库具有指向注册位置的位置属性、主体具有对数据库的 `CREATE_TABLE` 权限以及主体尝试在该位置或子位置创建表时，将授予隐式权限。
+ 如果某个主体被授予对某个位置的数据位置权限，则该主体对所有子位置都具有数据位置权限。
+ 委托人不需要数据位置权限即可对基础数据执行 read/write 操作。具有 `SELECT` 或 `INSERT` 数据访问权限就足够了。数据位置权限仅适用于创建指向该位置的数据目录资源。

请考虑下图中所示的场景。

![\[文件夹层次结构和两个数据库（数据库 A 和 B），其中数据库 B 指向 Customer service 文件夹。\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/location-permissions-example.png)


在此示意图中：
+ Amazon S3 存储桶 `Products`、`Finance` 和 `Customer Service` 已向 Lake Formation 注册。
+ `Database A` 不具有位置属性，而 `Database B` 具有指定 `Customer Service` 存储桶的位置属性。
+ 用户 `datalake_user` 具有对这两个数据库的 `CREATE_TABLE` 权限。
+ 用户 `datalake_user` 仅被授予对 `Products` 存储桶的数据位置权限。

以下是用户 `datalake_user` 尝试在特定位置的特定数据库中创建目录表时的结果。


**`datalake_user` 在其中尝试创建表的位置**  

| 数据库和位置 | 成功或失败 | Reason | 
| --- | --- | --- | 
| 位于 Finance/Sales 的数据库 A | 失败 | 无数据位置权限 | 
| 位于 Products 的数据库 A | 成功 | 具有数据位置权限 | 
| 位于 HR/Plans 的数据库 A | 成功 | 位置未进行注册 | 
| 位于 Customer Service/Incidents 的数据库 B | 成功 | 数据库在 Customer Service 处具有位置属性。 | 

有关更多信息，请参阅下列内容：
+ [向数据湖添加 Amazon S3 位置](register-data-lake.md)
+ [Lake Formation 权限参考](lf-permissions-reference.md)
+ [Lake Formation 角色和 IAM 权限参考](permissions-reference.md)

# Lake Formation 角色和 IAM 权限参考
<a name="permissions-reference"></a>

本部分列出了一些建议的 Lake Formation 角色及其建议的 AWS Identity and Access Management (IAM) 权限。有关 Lake Formation 权限的信息，请参阅 [Lake Formation 权限参考](lf-permissions-reference.md)。

## AWS Lake Formation 角色
<a name="lf-personas"></a>

下表列出了建议 AWS Lake Formation 的角色。


**Lake Formation 角色**  

| 女神异闻录 | 说明 | 
| --- | --- | 
| IAM 管理员（超级用户） | （必填）可以创建 IAM 用户和角色的用户。有AdministratorAccess AWS 托管策略。具有对所有 Lake Formation 资源的所有权限。可以添加数据湖管理员。如果未同时指定数据湖管理员，则无法授予 Lake Formation 权限。 | 
| 数据湖管理员 | （必填）可以注册 Amazon S3 地点、访问数据目录、创建数据库、创建和运行工作流程、向其他用户授予 Lake Formation 权限以及查看 AWS CloudTrail 日志的用户。与 IAM 管理员相比，具有的 IAM 权限较少，但足以管理数据湖。无法添加其他数据湖管理员。 | 
| 只读管理员 | （可选）可以查看主体、数据目录资源、权限和 AWS CloudTrail 日志但无权进行更新的用户。 | 
| 数据工程师 | （可选）可以创建数据库、创建和运行爬网程序和工作流，以及授予对爬网程序和工作流创建的数据目录表的 Lake Formation 权限的用户。我们建议您将所有数据工程师设置为数据库创建者。有关更多信息，请参阅 [创建数据库](creating-database.md)。 | 
| 数据分析人员 | （可选）可以使用 Amazon Athena等对数据湖运行查询的用户。只有足够的权限来运行查询。 | 
| 工作流角色 | （必需）代表用户运行工作流的角色。您可以在从蓝图创建工作流时指定此角色。 | 

**注意**  
在 Lake Formation 中，创建数据库后添加的数据湖管理员可以授予权限，但不会自动拥有诸如 SELECT 或 DESCRIBE 之类的数据访问权限。创建数据库的管理员将获得这些数据库的 `SUPER` 权限。这种行为是刻意设计的，尽管所有管理员都可以向自己授予所需的权限，但这些权限不会自动应用于先前存在的资源。因此，管理员必须明确向自己授予在获授管理员权限之前存在的数据库的访问权限。

## AWS Lake Formation 的托管策略
<a name="lf-managed-policies"></a>

您可以使用 AWS 托管策略和内联策略授予使用所需 AWS Lake Formation 的 AWS Identity and Access Management (IAM) 权限。以下 AWS 托管策略适用于 Lake Formation。

### AWS 托管策略：AWSLakeFormationDataAdmin
<a name="lf-data-admin"></a>

 [AWSLakeFormationDataAdmin](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationDataAdmin)策略授予对管理数据湖 AWS Lake Formation 等 AWS Glue 相关服务的管理权限。

您可以将 `AWSLakeFormationDataAdmin` 附加到您的用户、组和角色。

**权限详细信息**
+ `CloudTrail`— 允许委托人查看 AWS CloudTrail 日志。这是检查数据湖设置中的任何错误所必需的权限。
+ `Glue` - 允许主体查看、创建和更新数据目录中的元数据表和数据库。这包括以 `Get`、`List`、`Create`、`Update`、`Delete` 和 `Search` 开头的 API 操作。这是管理数据湖表的元数据所必需的权限。
+ `IAM` - 允许主体检索有关 IAM 用户、角色和附加到角色的策略的信息。这是数据管理员查看和列出 IAM 用户和角色以授予 Lake Formation 权限所必需的。
+ `Lake Formation` - 向数据湖管理员授予管理数据湖所需的 Lake Formation 权限。
+ `S3` - 允许主体检索有关 Amazon S3 存储桶及其位置的信息，以便为数据湖设置数据位置。

```
"Statement": [
        {
            "Sid": "AWSLakeFormationDataAdminAllow",
            "Effect": "Allow",
            "Action": [
                "lakeformation:*",
                "cloudtrail:DescribeTrails",
                "cloudtrail:LookupEvents",
                "glue:CreateCatalog",
		"glue:UpdateCatalog",
                "glue:DeleteCatalog",
		"glue:GetCatalog",
	        "glue:GetCatalogs",
                "glue:GetDatabase",
                "glue:GetDatabases",
                "glue:CreateDatabase",
                "glue:UpdateDatabase",
                "glue:DeleteDatabase",
                "glue:GetConnections",
                "glue:SearchTables",
                "glue:GetTable",
                "glue:CreateTable",
                "glue:UpdateTable",
                "glue:DeleteTable",
                "glue:GetTableVersions",
                "glue:GetPartitions",
                "glue:GetTables",
                "glue:ListWorkflows",
                "glue:BatchGetWorkflows",
                "glue:DeleteWorkflow",
                "glue:GetWorkflowRuns",
                "glue:StartWorkflowRun",
                "glue:GetWorkflow",
                "s3:ListBucket",
                "s3:GetBucketLocation",
                "s3:ListAllMyBuckets",
                "s3:GetBucketAcl",
                "iam:ListUsers",
                "iam:ListRoles",
                "iam:GetRole",
                "iam:GetRolePolicy"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AWSLakeFormationDataAdminDeny",
            "Effect": "Deny",
            "Action": [
                "lakeformation:PutDataLakeSettings"
            ],
                "Resource": "*"
        }
    ]
}
```

**注意**  
`AWSLakeFormationDataAdmin` 策略不会向数据湖管理员授予所有必需的权限。需要额外的权限才能创建和运行工作流并向服务相关角色 `AWSServiceRoleForLakeFormationDataAccess` 注册位置。有关更多信息，请参阅[创建数据湖管理员](initial-lf-config.md#create-data-lake-admin)和[在 Lake Formation 中使用服务相关角色](service-linked-roles.md)。

### AWS 托管策略：AWSLakeFormationCrossAccountManager
<a name="lf-cross-account-manager"></a>

[AWSLakeFormationCrossAccountManager](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationCrossAccountManager)策略提供通过 Lake Formation 对 AWS Glue 资源的跨账户访问权限，并授予对其他必需服务（例如 AWS Organizations 和）的读取权限 AWS RAM。

您可以将 `AWSLakeFormationCrossAccountManager` 附加到您的用户、组和角色。

**权限详细信息**

该策略包含以下权限。
+ `Glue` - 允许主体设置或删除用于访问控制的数据目录资源策略。
+ `Organizations` - 允许主体检索组织的账户和组织单位 (OU) 信息。
+ `ram:CreateResourceShare` - 允许主体创建资源共享。
+ `ram:UpdateResourceShare` - 允许主体修改指定资源共享的某些属性。
+ `ram:DeleteResourceShare` - 允许主体删除指定的资源共享。
+ `ram:AssociateResourceShare` - 允许主体将指定的主体列表和资源列表添加到资源共享。
+ `ram:DisassociateResourceShare` - 允许主体将指定的主体或资源从参与指定资源共享中移除。
+ `ram:GetResourceShares` – 允许主体检索有关您拥有的或与您共享的资源共享的详细信息。
+ `ram:RequestedResourceType` - 允许主体检索资源类型（数据库、表或目录）。
+ `AssociateResourceSharePermission`— 允许委托人添加或替换资源共享中包含的资源类型的 AWS RAM 权限。您只能将一个权限与资源共享中包含的每种资源类型相关联。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [{
            "Sid": "AllowCreateResourceShare",
            "Effect": "Allow",
            "Action": [
                "ram:CreateResourceShare"
            ],
            "Resource": "*",
            "Condition": {
                "StringLikeIfExists": {
                    "ram:RequestedResourceType": [
                        "glue:Table",
                        "glue:Database",
                        "glue:Catalog"
                    ]
                }
            }
        },
        {
            "Sid": "AllowManageResourceShare",
            "Effect": "Allow",
            "Action": [
                "ram:UpdateResourceShare",
                "ram:DeleteResourceShare",
                "ram:AssociateResourceShare",
                "ram:DisassociateResourceShare",
                "ram:GetResourceShares"
            ],
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "ram:ResourceShareName": [
                        "LakeFormation*"
                    ]
                }
            }
        },
        {
            "Sid": "AllowManageResourceSharePermissions",
            "Effect": "Allow",
            "Action": [
                "ram:AssociateResourceSharePermission"
            ],
            "Resource": "*",
            "Condition": {
                "ArnLike": {
                    "ram:PermissionArn": [
                        "arn:aws:ram::aws:permission/AWSRAMLFEnabled*"
                    ]
                }
            }
        },
        {
            "Sid": "AllowXAcctManagerPermissions",
            "Effect": "Allow",
            "Action": [
                "glue:PutResourcePolicy",
                "glue:DeleteResourcePolicy",
                "organizations:DescribeOrganization",
                "organizations:DescribeAccount",
                "ram:Get*",
                "ram:List*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowOrganizationsPermissions",
            "Effect": "Allow",
            "Action": [
                "organizations:ListRoots",
                "organizations:ListAccountsForParent",
                "organizations:ListOrganizationalUnitsForParent"
            ],
            "Resource": "*"
        }
    ]
}
```

------

### AWS 托管策略：AWSGlueConsoleFullAccess
<a name="glue-console-access-policy"></a>

[AWSGlueConsoleFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSGlueConsoleFullAccess)当策略所关联的身份使用时，策略会授予对 AWS Glue 资源的完全访问权限 AWS 管理控制台。如果遵循此策略中指定的资源的命名约定，则用户具有完全控制台功能。此策略通常附加到 AWS Glue 控制台的用户。

此外，AWS GlueLake Formation 还担任服务角色，`AWSGlueServiceRole`允许访问相关服务，包括亚马逊弹性计算云 (Amazon EC2)、亚马逊简单存储服务 (Amazon S3) Simple Storage S3 和亚马逊。 CloudWatch

### AWS managed policy:LakeFormationDataAccessServiceRolePolicy
<a name="lake-formation-data-access-service-role-policy"></a>

此策略附加到名为 `ServiceRoleForLakeFormationDataAccess` 的服务相关角色，以允许服务根据您的请求对资源执行操作。无法将此策略附加到 IAM 身份。

该政策允许 Lake Formation 集成 AWS 服务（例如 Amazon Athena 或 Amazon Redshift）使用服务相关角色来发现亚马逊 S3 资源。

有关更多信息，请参阅[在 Lake Formation 中使用服务相关角色](service-linked-roles.md)。

**权限详细信息**

此策略包含以下权限。
+ `s3:ListAllMyBuckets` – 返回已经过身份验证的请求发送者所拥有的所有存储桶列表。

------
#### [ JSON ]

****  

```
{
	"Version":"2012-10-17",		 	 	 
	"Statement": [
		{
			"Sid": "LakeFormationDataAccessServiceRolePolicy",
			"Effect": "Allow",
			"Action": [
				"s3:ListAllMyBuckets"
			],
			"Resource": [
				"arn:aws:s3:::*"
			]
		}
	]
}
```

------

**Lake Formation 更新 AWS 了托管政策**  
查看自该服务开始追踪 Lake Formation AWS 托管政策变更以来这些更新的详细信息。


| 更改 | 描述 | 日期 | 
| --- | --- | --- | 
| Lake Formation 更新了 AWSLakeFormationCrossAccountManager 策略。 | Lake Form [AWSLakeFormationCrossAccountManager](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationCrossAccountManager)ation 将StringLike条件运算符替换为允许 IAM 执行 ARN 格式检查的ArnLike运算符，从而增强了该策略。 | 2025 年 1 月 | 
| Lake Formation 更新了 AWSLakeFormationDataAdmin 策略。 | Lake Formation 在多目录功能中添加了 APIs 以下 AWS Glue Data Catalog CRUD，从而增强了该[AWSLakeFormationDataAdmin](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationDataAdmin)政策。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/permissions-reference.html)此托管策略变更旨在确保 Lake Formation 管理员角色在默认情况下对这些新操作拥有 IAM 权限。 | 2024 年 12 月 | 
| Lake Formation 更新了 AWSLakeFormationCrossAccountManager 策略。 | Lake Formati [AWSLakeFormationCrossAccountManager](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationCrossAccountManager)on在政策声明中添加了Sid元素，从而增强了该政策。 | 2024 年 3 月 | 
| Lake Formation 更新了 AWSLakeFormationDataAdmin 策略。 | Lake Formation 在[AWSLakeFormationDataAdmin](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationDataAdmin)政策声明中添加了 Sid 元素并删除了多余的操作，从而增强了该政策。 | 2024 年 3 月 | 
| Lake Formation 更新了 LakeFormationDataAccessServiceRolePolicy 策略。 | Lake Formation在[LakeFormationDataAccessServiceRolePolicy](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/LakeFormationDataAccessServiceRolePolicy)政策声明中添加了Sid元素，从而增强了该政策。 | 2024 年 2 月 | 
| Lake Formation 更新了 AWSLakeFormationCrossAccountManager 策略。 | Lake Formation 增加了在混合访问模式下启用跨账户数据共享的新权限，从而增强了该[AWSLakeFormationCrossAccountManager](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationCrossAccountManager)政策。 | 2023 年 10 月 | 
| Lake Formation 更新了 AWSLakeFormationCrossAccountManager 策略。 | Lake Formation 增强了[AWSLakeFormationCrossAccountManager](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationCrossAccountManager)政策，在首次共享资源时，每个接收者账户仅创建一个资源共享。此后与同一账户共享的所有资源都将附加到同一资源共享。 | 2022 年 5 月 6 日 | 
| Lake Formation 开启了跟踪更改。 | Lake Formation开始跟踪其 AWS 托管政策的变更。 | 2022 年 5 月 6 日 | 

## 角色建议的权限
<a name="lf-permissions-tables"></a>

以下是针对每个角色建议的权限。IAM 管理员不包括在内，因为该类用户具有对所有资源的所有权限。

**Topics**
+ [数据湖管理员权限](#persona-dl-admin)
+ [只读管理员权限](#persona-read-only-admin)
+ [数据工程师权限](#persona-engineer)
+ [数据分析师权限](#persona-user)
+ [工作流角色权限](#persona-workflow-role)

### 数据湖管理员权限
<a name="persona-dl-admin"></a>

**重要**  
在以下策略中，*<account-id>*替换为有效的 AWS 账号，然后*<workflow\$1role>*替换为有权运行工作流程的角色的名称，如中所定义[工作流角色权限](#persona-workflow-role)。


| 策略类型 | Policy | 
| --- | --- | 
| AWS 托管策略 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/permissions-reference.html) 有关可选 AWS 托管策略的信息，请参阅[创建数据湖管理员](initial-lf-config.md#create-data-lake-admin)。  | 
| 内联策略（用于创建 Lake Formation 服务相关角色） |  <pre>{<br />    "Version": "2012-10-17",		 	 	 <br />    "Statement": [<br />        {<br />            "Effect": "Allow",<br />            "Action": "iam:CreateServiceLinkedRole",<br />            "Resource": "*",<br />            "Condition": {<br />                "StringEquals": {<br />                    "iam:AWSServiceName": "lakeformation.amazonaws.com"<br />                }<br />            }<br />        },<br />        {<br />            "Effect": "Allow",<br />            "Action": [<br />                "iam:PutRolePolicy"<br />            ],<br />            "Resource": "arn:aws:iam::<account-id>:role/aws-service-role/lakeformation.amazonaws.com/AWSServiceRoleForLakeFormationDataAccess"<br />        }<br />    ]<br />}<br /></pre>  | 
| （可选）内联策略（工作流角色的 passrole 策略）。仅当数据湖管理员创建并运行工作流时，才需要此策略。 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/permissions-reference.html)  | 
| （可选）内联策略（如果您的账户要授予或接收跨账户 Lake Formation 权限）。此政策用于接受或拒绝 AWS RAM 资源共享邀请，以及允许向组织授予跨账户权限。 ram:EnableSharingWithAwsOrganization只有 AWS Organizations 管理账户中的数据湖管理员才需要使用。 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/permissions-reference.html)  | 

### 只读管理员权限
<a name="persona-read-only-admin"></a>


| 策略类型 | Policy | 
| --- | --- | 
| 内联策略（基本） |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/permissions-reference.html)  | 

### 数据工程师权限
<a name="persona-engineer"></a>

**重要**  
在以下策略中，*<account-id>*替换为有效的 AWS 账号，然后*<workflow\$1role>*替换为工作流程角色的名称。


| 策略类型 | Policy | 
| --- | --- | 
| AWS 托管策略 | AWSGlueConsoleFullAccess | 
| 内联策略（基本） |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/permissions-reference.html)  | 
| 内联策略（用于对受管控表的操作，包括事务中的操作） |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/permissions-reference.html)  | 
| 内联策略（用于使用 Lake Formation 基于标签的访问控制 (LF-TBAC) 方法进行元数据访问控制） |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/permissions-reference.html)  | 
| 内联策略（工作流角色的 passrole 策略） |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/permissions-reference.html)  | 

### 数据分析师权限
<a name="persona-user"></a>


| 策略类型 | Policy | 
| --- | --- | 
| AWS 托管策略 | AmazonAthenaFullAccess | 
| 内联策略（基本） |  <pre>{<br />    "Version": "2012-10-17",		 	 	 <br />    "Statement": [<br />        {<br />            "Effect": "Allow",<br />            "Action": [<br />                "lakeformation:GetDataAccess",<br />                "glue:GetTable",<br />                "glue:GetTables",<br />                "glue:SearchTables",<br />                "glue:GetDatabase",<br />                "glue:GetDatabases",<br />                "glue:GetPartitions",<br />                "lakeformation:GetResourceLFTags",<br />                "lakeformation:ListLFTags",<br />                "lakeformation:GetLFTag",<br />                "lakeformation:SearchTablesByLFTags",<br />                "lakeformation:SearchDatabasesByLFTags"                <br />           ],<br />            "Resource": "*"<br />        }<br />    ]<br />}</pre>  | 
| （可选）内联策略（用于对受管控表的操作，包括事务中的操作） |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/permissions-reference.html)  | 

### 工作流角色权限
<a name="persona-workflow-role"></a>

该角色具有运行工作流所需的权限。创建工作流时，您可以指定具有这些权限的角色。

**重要**  
在以下策略中，*<region>*使用有效的 AWS 区域标识符（例如`us-east-1`）、*<account-id>*有效的 AWS 账号、工作流程角色的*<workflow\$1role>*名称以及*<your-s3-cloudtrail-bucket>* AWS CloudTrail 日志的 Amazon S3 路径替换。


| 策略类型 | Policy | 
| --- | --- | 
| AWS 托管策略 | AWSGlueServiceRole  | 
| 内联策略（数据访问） |  <pre>{<br />    "Version": "2012-10-17",		 	 	 <br />    "Statement": [<br />        {<br />            "Sid": "Lakeformation",<br />            "Effect": "Allow",<br />            "Action": [<br />                 "lakeformation:GetDataAccess",<br />                 "lakeformation:GrantPermissions"<br />             ],<br />            "Resource": "*"<br />        }<br />    ]<br />}</pre>  | 
| 内联策略（工作流角色的 passrole 策略） |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/permissions-reference.html)  | 
| 内联策略（用于在数据湖之外提取数据， AWS CloudTrail 例如日志） |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/permissions-reference.html)  | 

# 更改数据湖的默认设置
<a name="change-settings"></a>

要保持向后兼容 AWS Glue AWS Lake Formation ，请使用以下初始安全设置：
+ 向组 `IAMAllowedPrincipals` 授予对所有现有 AWS Glue 数据目录资源的 `Super` 权限。
+ 为新的数据目录资源启用“仅使用 IAM 访问控制”设置。

这些设置实际上使对数据目录资源和 Amazon S3 位置的访问只能由 AWS Identity and Access Management (IAM) 策略控制。单个 Lake Formation 权限无效。

`IAMAllowedPrincipals` 组包括 IAM 策略允许访问数据目录资源的任何 IAM 用户和角色。`Super` 权限使主体能够对被授予该权限的数据库或表执行所有支持的 Lake Formation 操作。

要更改安全设置，以便对数据目录资源（数据库和表）的访问由 Lake Formation 权限管理，请执行以下操作：

1. 更改新资源的默认安全设置。有关说明，请参阅[更改默认权限模式或使用混合访问模式](initial-lf-config.md#setup-change-cat-settings)。

1. 更改现有数据目录资源的设置。有关说明，请参阅[升级 AWS Lake Formation 模型AWS Glue的数据权限](upgrade-glue-lake-formation.md)。

**使用 Lake Formation `PutDataLakeSettings` API 操作更改默认安全设置**  
您还可以使用 Lake Formation [PutDataLakeSettings](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_PutDataLakeSettings.html)API 操作更改默认安全设置。此操作将可选的目录 ID 和[DataLakeSettings](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_DataLakeSettings.html)结构作为参数。

要通过 Lake Formation 对新数据库和表实施元数据和基础数据访问控制，请按如下方式对 `DataLakeSettings` 结构进行编码。

**注意**  
*<AccountID>*替换为有效的 AWS 账户 ID 和*<Username>*有效的 IAM 用户名。您可以将多个用户指定为数据湖管理员。

```
{
    "DataLakeSettings": {
        "DataLakeAdmins": [
            {
                "DataLakePrincipalIdentifier": "arn:aws:iam::<AccountId>:user/<Username>"
            }
        ],
        "CreateDatabaseDefaultPermissions": [],
        "CreateTableDefaultPermissions": []
    }
}
```

您也可以按如下方式对该结构进行编码。省略 `CreateDatabaseDefaultPermissions` 或 `CreateTableDefaultPermissions` 参数等同于传递空列表。

```
{
    "DataLakeSettings": {
        "DataLakeAdmins": [
            {
                "DataLakePrincipalIdentifier": "arn:aws:iam::<AccountId>:user/<Username>"
            }
        ]
    }
}
```

此操作实际上会撤销 `IAMAllowedPrincipals` 组对新数据库和表的所有 Lake Formation 权限。创建数据库时，您可以覆盖此设置。

要仅通过 IAM 对新数据库和表实施元数据和基础数据访问控制，请按如下方式对 `DataLakeSettings` 结构进行编码。

```
{
    "DataLakeSettings": {
        "DataLakeAdmins": [
            {
                "DataLakePrincipalIdentifier": "arn:aws:iam::<AccountId>:user/<Username>"
            }
        ],
        "CreateDatabaseDefaultPermissions": [
            {
                "Principal": {
                    "DataLakePrincipalIdentifier": "IAM_ALLOWED_PRINCIPALS"
                },
                "Permissions": [
                    "ALL"
                ]
            }
        ],
        "CreateTableDefaultPermissions": [
            {
                "Principal": {
                    "DataLakePrincipalIdentifier": "IAM_ALLOWED_PRINCIPALS"
                },
                "Permissions": [
                    "ALL"
                ]
            }
        ]
    }
}
```

这将向 `IAMAllowedPrincipals` 组授予对新数据库和表的 `Super` Lake Formation 权限。创建数据库时，您可以覆盖此设置。

**注意**  
在前面的 `DataLakeSettings` 结构中，`DataLakePrincipalIdentifier` 的唯一允许值是 `IAM_ALLOWED_PRINCIPALS`，`Permissions` 的唯一允许值是 `ALL`。

# 隐式 Lake Formation 权限
<a name="implicit-permissions"></a>

AWS Lake Formation 向数据湖管理员、数据库创建者和表创建者授予以下隐式权限。

**数据湖管理员**  
+ 对数据目录中的所有资源具有 `Describe` 访问权限，但从另一个账户直接共享到其他主体的资源除外。管理员无法撤销此访问权限。
+ 在数据湖中的任何位置都具有数据位置权限。
+ 可以向任何主体（包括自身）授予或撤销对数据目录中任何资源的访问权限。管理员无法撤销此访问权限。
+ 可以在数据目录中创建数据库。
+ 可以向其他用户授予创建数据库的权限。
数据湖管理员只有在具有 IAM 权限的情况下才能注册 Amazon S3 位置。本指南中建议的数据湖管理员策略可以授予这些权限。此外，数据湖管理员没有删除他人创建的数据库或 alter/drop 表的隐式权限。但是，他们可以授予自己执行此操作的权限。
有关数据湖管理员的更多信息，请参阅[创建数据湖管理员](initial-lf-config.md#create-data-lake-admin)。

**表创建者**  
+ 拥有他们创建的目录的所有目录权限，拥有他们在目录中创建的数据库和表的权限，并且可以向同一 AWS 账户中的其他委托人授予在目录中创建数据库和表的权限。同时拥有`AWSLakeFormationCrossAccountManager` AWS 托管策略的目录创建者可以向其他 AWS 账户或组织授予对目录的权限。

  数据湖管理员可以使用 Lake Formation 控制台或 API 来指定目录创建者。
**注意**  
目录创建者对其他人在目录中创建的数据库和表不具有隐式权限。
有关创建目录的更多信息，请参阅[将您的数据带入 AWS Glue Data Catalog](bring-your-data-overview.md)。

**数据库创建者**  
+ 拥有他们创建的数据库的所有数据库权限，拥有他们在数据库中创建的表的权限，并且可以向同一 AWS 账户中的其他委托人授予在数据库中创建表的权限。同时拥有`AWSLakeFormationCrossAccountManager` AWS 托管策略的数据库创建者可以向其他 AWS 账户或组织授予数据库权限。

  数据湖管理员可以使用 Lake Formation 控制台或 API 来指定数据库创建者。
**注意**  
数据库创建者对其他人在数据库中创建的表不具有隐式权限。
有关更多信息，请参阅 [创建数据库](creating-database.md)。

**表创建者**  
+ 具有对自己创建的表的所有权限。
+ 可以向同一 AWS 账户中的主体授予对他们创建的所有表的权限。
+ 如果其他 AWS 账户或组织拥有`AWSLakeFormationCrossAccountManager` AWS 托管策略，则可以将他们创建的所有表的权限授予他们。
+ 可以查看包含自己创建的表的数据库。

# Lake Formation 权限参考
<a name="lf-permissions-reference"></a>

要执行 AWS Lake Formation 操作，委托人需要 Lake Formation 权限和 AWS Identity and Access Management (IAM) 权限。您通常使用粗粒度访问控制策略授予 IAM 权限，如 [Lake Formation 权限概述](lf-permissions-overview.md)中所述。**您可以使用控制台、API 或 AWS Command Line Interface (AWS CLI) 授予 Lake Formation 权限。

要了解如何授予或撤销 Lake Formation 权限，请参阅[授予对数据目录资源的权限](granting-catalog-permissions.md)和[授予数据位置权限](granting-location-permissions.md)。

**注意**  
本部分中的示例说明如何向同一 AWS 账户中的主体授予权限。有关跨账户授权的示例，请参阅 [Lake Formation 中的跨账户数据共享](cross-account-permissions.md)。

## 每种资源类型的 Lake Formation 权限
<a name="lf-resource-permissions-summary"></a>

以下是适用于每种资源类型的有效 Lake Formation 权限：

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/lf-permissions-reference.html)

**Topics**
+ [每种资源类型的 Lake Formation 权限](#lf-resource-permissions-summary)
+ [Lake Formation 授予和撤销命令 AWS CLI](#perm-command-format)
+ [Lake Formation 权限](#lf-permissions)

## Lake Formation 授予和撤销命令 AWS CLI
<a name="perm-command-format"></a>

本节中的每个权限描述都包括使用 AWS CLI 命令授予权限的示例。以下是 Lake Formation **grant-permissions** 和**revoke-permissions** AWS CLI 命令的提要。

```
grant-permissions
[--catalog-id <value>]
--principal <value>
--resource <value>
--permissions <value>
[--permissions-with-grant-option <value>]
[--cli-input-json <value>]
[--generate-cli-skeleton <value>]
```

```
revoke-permissions
[--catalog-id <value>]
--principal <value>
--resource <value>
--permissions <value>
[--permissions-with-grant-option <value>]
[--cli-input-json <value>]
[--generate-cli-skeleton <value>]
```

有关这些命令的详细说明，请参阅《AWS CLI 命令参考》中的 [grant-permissions](https://docs.aws.amazon.com/cli/latest/reference/lakeformation/grant-permissions.html) 和 [revoke-permissions](https://docs.aws.amazon.com/cli/latest/reference/lakeformation/revoke-permissions.html)。**本部分提供有关 `--principal` 选项的更多信息。

`--principal` 选项的值为以下值之一：
+ (IAM) 用户或角色的亚马逊资源名称 AWS Identity and Access Management (ARN)
+ 通过 SAML 提供商（例如 Microsoft Active Directory 联合身份验证服务 (AD FS) 进行身份验证的用户或组的 ARN
+ Amazon Quick 用户或群组的 ARN
+ 对于跨账户权限，需要 AWS 账户 ID、组织 ID 或组织单位 ID
+ 对于 IAM Identity Center 用户或组，IAM Identity Center 用户或组 ARN。

以下是所有 `--principal` 类型的语法和示例。

**主体为 IAM 用户**  
语法：  

```
--principal DataLakePrincipalIdentifier=arn:aws:iam::<account-id>:user/<user-name>
```
示例：  

```
--principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1
```

**主体为 IAM 角色**  
语法：  

```
--principal DataLakePrincipalIdentifier=arn:aws:iam::<account-id>:role/<role-name>
```
示例：  

```
--principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:role/workflowrole
```

**主体为通过 SAML 提供商进行身份验证的用户**  
语法：  

```
--principal DataLakePrincipalIdentifier=arn:aws:iam::<account-id>:saml-provider/<SAMLproviderName>:user/<user-name>
```
示例：  

```
--principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/idp1:user/datalake_user1
```

```
--principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/AthenaLakeFormationOkta:user/athena-user@example.com
```

**主体为通过 SAML 提供商进行身份验证的组**  
语法：  

```
--principal DataLakePrincipalIdentifier=arn:aws:iam::<account-id>:saml-provider/<SAMLproviderName>:group/<group-name> 
```
示例：  

```
--principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/idp1:group/data-scientists
```

```
--principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/AthenaLakeFormationOkta:group/my-group
```

**校长是 Amazon Quick 企业版用户**  
语法：  

```
--principal DataLakePrincipalIdentifier=arn:aws:quicksight:<region>:<account-id>:user/<namespace>/<user-name>
```
对于 *<namespace>*，您必须指定 `default`。
示例：  

```
--principal DataLakePrincipalIdentifier=arn:aws:quicksight:us-east-1:111122223333:user/default/bi_user1
```

**校长是 Amazon Quick 企业版群组**  
语法：  

```
--principal DataLakePrincipalIdentifier=arn:aws:quicksight:<region>:<account-id>:group/<namespace>/<group-name> 
```
对于 *<namespace>*，您必须指定 `default`。
示例：  

```
--principal DataLakePrincipalIdentifier=arn:aws:quicksight:us-east-1:111122223333:group/default/data_scientists
```

**本金是一个 AWS 账户**  
语法：  

```
--principal DataLakePrincipalIdentifier=<account-id>
```
示例：  

```
--principal DataLakePrincipalIdentifier=111122223333
```

**主体为组织**  
语法：  

```
--principal DataLakePrincipalIdentifier=arn:aws:organizations::<account-id>:organization/<organization-id>
```
示例：  

```
--principal DataLakePrincipalIdentifier=arn:aws:organizations::111122223333:organization/o-abcdefghijkl
```

**主体为组织单位**  
语法：  

```
--principal DataLakePrincipalIdentifier=arn:aws:organizations::<account-id>:ou/<organization-id>/<organizational-unit-id>
```
示例：  

```
--principal DataLakePrincipalIdentifier=arn:aws:organizations::111122223333:ou/o-abcdefghijkl/ou-ab00-cdefghij
```

**主体是 IAM Identity Center 身份用户或组**  
示例：用户  

```
--principal DataLakePrincipalIdentifier=arn:aws:identitystore:::user/<UserID>
```
示例：组  

```
--principal DataLakePrincipalIdentifier=arn:aws:identitystore:::group/<GroupID>
```

**主体是一个 IAM 组 - `IAMAllowedPrincipals`**  
Lake Formation 默认将数据目录中所有数据库和表的 `Super` 权限设置到名为 `IAMAllowedPrincipals` 的组。如果数据库或表上存在此组权限，则您账户中的所有主体都可以通过 AWS Glue的 IAM 主体策略访问该资源。当您开始使用 Lake Formation 权限来保护之前受 AWS Glue的 IAM 策略保护的数据目录资源时，可提供向后兼容性。  
使用 Lake Formation 管理数据目录资源的权限时，首先需要撤销资源上的 `IAMAllowedPrincipals` 权限，或将主体和资源选择为混合访问模式，这样 Lake Formation 权限才能生效。  
示例：  

```
--principal DataLakePrincipalIdentifier=IAM_Allowed_Principals
```

**主体是一个 IAM 组 - `ALLIAMPrincipals`**  
当您向 `ALLIAMPrincipals` 组授予对数据目录资源的权限时，账户中的每个主体都可以使用 Lake Formation 权限和 IAM 权限访问数据目录资源。  
示例：  

```
--principal DataLakePrincipalIdentifier=123456789012:IAMPrincipals
```

## Lake Formation 权限
<a name="lf-permissions"></a>

本部分包含您可以向主体授予的可用的 Lake Formation 权限。

### `ALTER`
<a name="perm-alter"></a>


| 权限 | 针对此项资源授予的权限 | 被授权者还需要 | 
| --- | --- | --- | 
| ALTER | DATABASE | glue:UpdateDatabase  | 
| ALTER | TABLE | glue:UpdateTable | 
| ALTER | LF-Tag | lakeformation:UpdateLFTag | 

具有此权限的主体可以更改数据目录中数据库或表的元数据。对于表，您可以更改列架构并添加列参数。您无法更改元数据表指向的基础数据中的列。

如果要更改的属性是已注册的 Amazon Simple Storage Service (Amazon S3) 位置，则主体必须对新位置具有数据位置权限。

**Example**  
以下示例向 AWS 账户 1111-2222-33 `datalake_user1` 33 `retail` 中的用户授予数据库`ALTER`权限。  

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "ALTER" --resource '{ "Database": {"Name":"retail"}}'
```

**Example**  
以下示例向用户 `datalake_user1` 授予对数据库 `retail` 中 `inventory` 表的 `ALTER` 权限。  

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "ALTER" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}'
```

### `CREATE_DATABASE`
<a name="perm-create-database"></a>


| 权限 | 针对此项资源授予的权限 | 被授权者还需要 | 
| --- | --- | --- | 
| CREATE\$1DATABASE | 数据目录 | glue:CreateDatabase | 

具有此权限的主体可以在数据目录中创建元数据数据库或资源链接。主体还可以在数据库中创建表。

**Example**  
以下示例`CREATE_DATABASE`向 AWS 账户 1111-2222-33 `datalake_user1` 33 中的用户授权。  

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "CREATE_DATABASE" --resource '{ "Catalog": {}}'
```

当主体在数据目录中创建数据库时，不会授予对基础数据的权限。将授予以下其他元数据权限（以及将这些权限授予其他人的能力）：
+ 数据库中的 `CREATE_TABLE`
+ `ALTER` 数据库
+ `DROP` 数据库

创建数据库时，主体可以选择指定一个 Amazon S3 位置。根据主体是否具有数据位置权限，`CREATE_DATABASE` 权限可能不足以在所有情况下创建数据库。请务必牢记以下三种情况。


| 创建数据库用例 | 所需权限 | 
| --- | --- | 
| 未指定位置属性。 | CREATE\$1DATABASE 已足够。 | 
| 指定了位置属性，并且该位置不由 Lake Formation 管理（未注册）。 | CREATE\$1DATABASE 已足够。 | 
| 指定了位置属性，并且该位置由 Lake Formation（已注册）管理。 | 需要 CREATE\$1DATABASE 以及指定位置的数据位置权限。 | 

### `CREATE_TABLE`
<a name="perm-create-table"></a>


| 权限 | 针对此项资源授予的权限 | 被授权者还需要 | 
| --- | --- | --- | 
| CREATE\$1TABLE | DATABASE | glue:CreateTable  | 

具有此权限的主体可以在指定数据库的数据目录中创建元数据表或资源链接。

**Example**  
以下示例授予用户使用 AWS 账户 1111-2222-3333 在`retail`数据库中创建表的`datalake_user1`权限。  

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 
 --permissions "CREATE_TABLE" --resource '{ "Database": {"Name":"retail"}}'
```

当某个主体在数据目录中创建表时，系统会将表上的所有 Lake Formation 权限授予给该主体，并且该主体能够将这些权限授予其他主体。

**跨账户授权**  
如果数据库拥有者账户向接收者账户授予 `CREATE_TABLE` 权限，并且该接收者账户中的用户在拥有者账户的数据库中成功创建了表，则以下规则适用：
+ 接收者账户中的用户和数据湖管理员具有对表的所有 Lake Formation 权限。他们可以将对表的权限授予给其账户中的其他主体；但无法向拥有者账户或任何其他账户中的主体授予权限。
+ 拥有者账户中的数据湖管理员可以向其账户中的其他主体授予对表的权限。

**数据位置权限**  
当您尝试创建指向 Amazon S3 位置的表时，根据您是否具有数据位置权限，`CREATE_TABLE` 权限可能不足以创建表。请务必牢记以下三种情况。


| 创建表格用例 | 所需权限 | 
| --- | --- | 
| 指定位置不受 Lake Formation 管理（未注册）。 | CREATE\$1TABLE 已足够。 | 
| 指定位置由 Lake Formation（已注册）管理，并且包含的数据库没有位置属性或具有不是表位置的 Amazon S3 前缀的位置属性。 | 需要 CREATE\$1TABLE 以及指定位置的数据位置权限。 | 
| 指定位置由 Lake Formation（已注册）管理，并且包含的数据库具有一个位置属性，该属性指向已注册的位置且是表位置的 Amazon S3 前缀。 | CREATE\$1TABLE 已足够。 | 

### `DATA_LOCATION_ACCESS`
<a name="perm-location"></a>


| 权限 | 针对此项资源授予的权限 | 被授权者还需要 | 
| --- | --- | --- | 
| DATA\$1LOCATION\$1ACCESS | Amazon S3 位置 | （Amazon S3 对位置的权限，必须由用于注册位置的角色指定。） | 

这是唯一的数据位置权限。具有此权限的主体可以创建指向指定 Amazon S3 位置的元数据数据库或表。必须注册该位置。对某个位置具有数据位置权限的主体也对子位置具有位置权限。

**Example**  
以下示例在 AWS 账户 1111-2222-3333 中向用户 `datalake_user1` 授予对 `s3://products/retail` 的数据位置权限。  

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DATA_LOCATION_ACCESS" --resource '{ "DataLocation": {"ResourceArn":"arn:aws:s3:::products/retail"}}'
```

查询或更新基础数据不需要 `DATA_LOCATION_ACCESS` 权限。此权限仅适用于创建数据目录资源。

有关数据位置权限的更多信息，请参阅[Underlying data access control](access-control-underlying-data.md#data-location-permissions)。

### `DELETE`
<a name="perm-delete"></a>


| 权限 | 针对此项资源授予的权限 | 被授权者还需要 | 
| --- | --- | --- | 
| DELETE | TABLE | （如果注册了位置，则无需其他 IAM 权限。） | 

具有此权限的主体可以在表指定的 Amazon S3 位置插入、更新和读取基础数据。主体还可以在 Lake Formation 控制台上查看表，并使用 AWS Glue API 检索有关表的信息。

**Example**  
以下示例向 AWS 账户 1111-2222-33 `datalake_user1` 33 `inventory` 中的用户授予对数据库`retail`中表的`DELETE`权限。  

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DELETE" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}'
```

此权限仅适用于 Amazon S3 中的数据，不适用于 Amazon Relational Database Service (Amazon RDS) 等其他数据存储中的数据。

### `DESCRIBE`
<a name="perm-describe"></a>


| 权限 | 针对此项资源授予的权限 | 被授权者还需要 | 
| --- | --- | --- | 
| DESCRIBE |  表资源链接 数据库资源链接  |  `glue:GetTable` `glue:GetDatabase`  | 
| DESCRIBE | DATABASE | glue:GetDatabase | 
| DESCRIBE | TABLE | glue:GetTable | 
| DESCRIBE | LF-Tag |  `glue:GetTable` `glue:GetDatabase` `lakeformation:GetResourceLFTags` `lakeformation:ListLFTags` `lakeformation:GetLFTag` `lakeformation:SearchTablesByLFTags` `lakeformation:SearchDatabasesByLFTags`  | 

具有此权限的主体可以查看指定的数据库、表或资源链接。不会隐式授予任何其他数据目录权限，也不会隐式授予任何数据访问权限。数据库和表显示在集成服务的查询编辑器中，但除非授予其他 Lake Formation 权限（例如 `SELECT`），否则无法对它们进行查询。

例如，对数据库具有 `DESCRIBE` 权限的用户可以查看数据库和所有数据库元数据（描述、位置等）。但是，用户无法找出数据库包含哪些表，也无法删除、更改或创建数据库中的表。同样，对表具有 `DESCRIBE` 权限的用户可以查看表和表元数据（描述、架构、位置等），但无法删除、更改或运行对表的查询。

以下是 `DESCRIBE` 的一些附加规则：
+ 如果用户对数据库、表或资源链接具有其他 Lake Formation 权限，则会隐式授予 `DESCRIBE` 权限。
+ 如果用户仅对表的列子集具有 `SELECT` 权限（部分 `SELECT`），则用户只能查看这些列。
+ 您无法向对表具有部分 SELECT 权限的用户授予 `DESCRIBE` 权限。反之，您无法为被授予了 `DESCRIBE` 权限的表指定列包含或排除列表。

**Example**  
以下示例向 AWS 账户 1111-2222-33 `datalake_user1` 33 中的用户授予对数据库`inventory-link``retail`中表资源链接的`DESCRIBE`权限。  

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DESCRIBE" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory-link"}}'
```

### `DROP`
<a name="perm-drop"></a>


| 权限 | 针对此项资源授予的权限 | 被授权者还需要 | 
| --- | --- | --- | 
| DROP | DATABASE | glue:DeleteDatabase | 
| DROP | TABLE | glue:DeleteTable  | 
| DROP | LF-Tag | lakeformation:DeleteLFTag  | 
| DROP |  数据库资源链接 表资源链接  | `glue:DeleteDatabase` `glue:DeleteTable`  | 

具有此权限的主体可以在数据目录中删除数据库、表或资源链接。您无法向外部账户或组织授予对数据库的 DROP 权限。

**警告**  
删除数据库会删除数据库中的所有表。

**Example**  
以下示例向 AWS 账户 1111-2222-33 `datalake_user1` 33 `retail` 中的用户授予数据库`DROP`权限。  

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DROP" --resource '{ "Database": {"Name":"retail"}}'
```

**Example**  
以下示例向用户 `datalake_user1` 授予对数据库 `retail` 中 `inventory` 表的 `DROP` 权限。  

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DROP" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}'
```

**Example**  
以下示例向用户 `datalake_user1` 授予对数据库 `retail` 中表资源链接 `inventory-link` 的 `DROP` 权限。  

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DROP" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory-link"}}'
```

### `INSERT`
<a name="perm-insert"></a>


| 权限 | 针对此项资源授予的权限 | 被授权者还需要 | 
| --- | --- | --- | 
| INSERT | TABLE | （如果注册了位置，则无需其他 IAM 权限。） | 

具有此权限的主体可以在表指定的 Amazon S3 位置插入、更新和读取基础数据。主体还可以在 Lake Formation 控制台中查看表，并使用 AWS Glue API 检索有关表的信息。

**Example**  
以下示例向 AWS 账户 1111-2222-33 `datalake_user1` 33 `inventory` 中的用户授予对数据库`retail`中表的`INSERT`权限。  

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "INSERT" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}'
```

此权限仅适用于 Amazon S3 中的数据，不适用于 Amazon RDS 等其他数据存储中的数据。

### `SELECT`
<a name="perm-select"></a>


| 权限 | 针对此项资源授予的权限 | 被授权者还需要 | 
| --- | --- | --- | 
| SELECT |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/lf-permissions-reference.html)  | （如果注册了位置，则无需其他 IAM 权限。） | 

具有此权限的主体可以查看数据目录中的表，并可以在表指定的位置查询 Amazon S3 中的基础数据。主体可以在 Lake Formation 控制台中查看表，并使用 AWS Glue API 检索有关表的信息。如果在授予此权限时应用了列筛选，则主体只能查看所包含列的元数据，并且只能从所包含的列中查询数据。

**注意**  
集成分析服务负责在处理查询时应用列筛选。

**Example**  
以下示例向 AWS 账户 1111-2222-33 `datalake_user1` 33 `inventory` 中的用户授予对数据库`retail`中表的`SELECT`权限。  

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "SELECT" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}'
```

此权限仅适用于 Amazon S3 中的数据，不适用于 Amazon RDS 等其他数据存储中的数据。

您可以使用可选的包含列表或排除列表来筛选特定列（限制访问权限）。包含列表指定可以访问的列。排除列表指定无法访问的列。如果没有包含列表或排除列表，则所有表列均可访问。

`glue:GetTable` 的结果仅返回调用方有权查看的列。Amazon Athena 和 Amazon Redshift 等集成服务支持列包含和排除列表。

**Example**  
以下示例使用包含列表向用户 `datalake_user1` 授予对表 `inventory` 的 `SELECT` 权限。  

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "SELECT"  --resource '{ "TableWithColumns": {"DatabaseName":"retail", "Name":"inventory", "ColumnNames": ["prodcode","location","period","withdrawals"]}}'
```

**Example**  
下一个示例使用排除列表授予对 `inventory` 表的 `SELECT` 权限。  

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "SELECT"  --resource '{ "TableWithColumns": {"DatabaseName":"retail", "Name":"inventory", "ColumnWildcard": {"ExcludedColumnNames": ["intkey", "prodcode"]}}}'
```

以下限制适用于 `SELECT` 权限：
+ 授予 `SELECT` 时，如果应用了列筛选，则不能包含授权选项。
+ 不能限制对作为分区键的列的访问控制。
+ 不能向对表中的列子集具有 `SELECT` 权限的主体授予对该表的 `ALTER`、`DROP`、`DELETE` 或 `INSERT` 权限。同样，不能通过列筛选向对表具有 `ALTER`、`DROP`、`DELETE` 或 `INSERT` 权限的主体授予 `SELECT` 权限。

`SELECT` 权限始终作为单独的行显示在 Lake Formation 控制台的**数据权限**页面上。下图显示向用户 `datalake_user2` 和 `datalake_user3` 授予对 `inventory` 表中所有列的 `SELECT` 权限。

![\[数据权限页面显示四行。第一行和第三行列出了资源类型为 Table 的 Delete 和 Insert 权限，资源显示为 inventory；第二行和第四行列出了资源类型为 Column 的 Select 权限，同时资源显示为 retail.inventory.*。\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/data-permissions-dialog-select-cross.png)


### `Super`
<a name="perm-super"></a>


| 权限 | 针对此项资源授予的权限 | 被授权者还需要 | 
| --- | --- | --- | 
| Super | DATABASE | glue:\$1Database\$1  | 
| Super | TABLE | glue:\$1Table\$1, glue:\$1Partition\$1 | 

此权限允许主体对数据库或表执行所有支持的 Lake Formation 操作。您无法向外部账户授予对数据库的 `Super` 权限。

此权限可以与其他 Lake Formation 权限共存。例如，您可以授予对元数据表的 `Super`、`SELECT`、和 `INSERT` 权限。然后，主体可以对表执行所有受支持的操作。撤销 `Super` 后，`SELECT` 和 `INSERT` 权限将保留，且主体只能执行 select 和 insert 操作。

您可以将 `Super` 授予组 `IAMAllowedPrincipals`，而不是将其授予单个主体。`IAMAllowedPrincipals` 组是自动创建的，其中包括 IAM 策略允许访问数据目录资源的所有 IAM 用户和角色。当向 `IAMAllowedPrincipals` 授予对数据目录资源的 `Super` 权限时，对该资源的访问实际上完全由 IAM 策略控制。

通过利用 Lake Formation 控制台的**设置**页面上的选项，可以自动向 `IAMAllowedPrincipals` 授予对新目录资源的 `Super` 权限。

![\[“数据目录设置”对话框的副标题为“新创建的数据库和表的默认权限”，并具有两个复选框，如文本中所述。\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/settings-page.png)

+ 要向 `IAMAllowedPrincipals` 授予对所有新数据数据库的 `Super` 权限，请选择**仅对新数据库使用 IAM 访问控制**。
+ 要向 `IAMAllowedPrincipals` 授予对新数据数据库中所有新表的 `Super` 权限，请选择**仅对新数据库中的新表使用 IAM 访问控制**。
**注意**  
此选项会导致默认情况下选中**创建数据库**对话框中的**仅对此数据库中的新表使用 IAM 访问控制**复选框。它的作用仅此而已。它是**创建数据库**对话框中的复选框，用于向 `IAMAllowedPrincipals` 授予 `Super` 权限。

默认情况下，将启用这些**设置**页面选项。有关更多信息，请参阅下列内容：
+ [更改数据湖的默认设置](change-settings.md)
+ [升级 AWS Lake Formation 模型AWS Glue的数据权限](upgrade-glue-lake-formation.md)

### `SUPER_USER`
<a name="perm-super-user"></a>


| 权限 | 针对此项资源授予的权限 | 被授权者还需要 | 
| --- | --- | --- | 
| Super user | Catalog | glue:GetCatalog  | 

您只能向默认 Data Catalog 中目录的特定主体授予 `Super user` 权限。您不能对默认目录或其他资源类型（例如数据库和表）的授予 `Super user` 权限，也不能向外部账户中的主体授予该权限。`Super user` 权限使主体能够对已授权目录中的数据库和表执行所有支持的 Lake Formation 操作。

获得 `Super user` 权限后，主体（被授权者）可以对目录中的资源（目录、数据库和表）执行以下操作：
+ 对目录的 `CREATE_DATABASE`、`DESCRIBE` 权限。
+ 对目录中所有数据库的 `DROP`、`ALTER`、`CREATE_TABLE`、`DESCRIBE`（实际上是 `SUPER`）权限。
+ 对目录中所有数据库中的所有表的 `DROP`、`ALTER`、`DESCRIBE`、`SELECT`、`INSERT`、`DELETE`（实际上是 `SUPER`）权限。
+ 对目录中的目录的 `All`（实际上是 SUPER）权限。
+ 对目录中的所有目录、数据库和表的可授予权限（能够向其他主体授予这些权限）。

获得目录资源的 `Super user` 权限后，不允许被授权者对目录执行或委托执行 `ALTER` 和 `DROP` 操作。

### `ASSOCIATE`
<a name="perm-associate"></a>


| 权限 | 针对此项资源授予的权限 | 被授权者还需要 | 
| --- | --- | --- | 
| ASSOCIATE | LF-Tag |   `glue:GetDatabase` `glue:GetTable`  `lakeformation:AddLFTagsToResource"` `lakeformation:RemoveLFTagsFromResource"` `lakeformation:GetResourceLFTags` `lakeformation:ListLFTags` `lakeformation:GetLFTag` `lakeformation:SearchTablesByLFTags` `lakeformation:SearchDatabasesByLFTags`  | 

对 LF 标签具有此权限的主体可以将 LF 标签分配给数据目录资源。授予 `ASSOCIATE` 会隐式授予 `DESCRIBE` 权限。

**Example**  
此示例向用户 `datalake_user1` 授予对带有键 `module` 的 LF 标签的 `ASSOCIATE` 权限。它授予查看和分配该键的所有值的权限，如星号 (\$1) 所示。  

```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "ASSOCIATE" --resource '{ "LFTag": {"CatalogId":"111122223333","TagKey":"module","TagValues":["*"]}}'
```

# 集成 IAM Identity Center
<a name="identity-center-integration"></a>

借 AWS IAM Identity Center助，您可以连接到身份提供商 (IdPs)，并集中管理 AWS 分析服务中用户和群组的访问权限。您可以将 Okta、Ping 和 Microsoft Entra ID（以前称为 Azure Active Directory）等身份提供者与 IAM Identity Center 集成，以便您组织中的用户使用单点登录体验访问数据。IAM Identity Center 还支持连接其他第三方身份提供者。

有关更多信息，请参阅《 AWS IAM Identity Center 用户指南》中[支持的身份提供商](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html)。

您可以在 IAM Identity Center 中配置 AWS Lake Formation 为已启用的应用程序，数据湖管理员可以向授权用户和群组授予对 AWS Glue Data Catalog 资源的精细权限。

您组织中的用户可以使用组织的身份提供程者登录到任何启用了 Identity Center 的应用程序，并查询应用 Lake Formation 权限的数据集。通过此集成，您可以管理对 AWS 服务的访问权限，而无需创建多个 IAM 角色。

[可信身份传播](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overview.html)是一项 AWS IAM Identity Center 功能，connected 的管理员 AWS 服务 可以使用它来授予和审核对服务数据的访问权限。对这些数据的访问权限基于用户属性，例如组关联。设置可信身份传播需要连接的管理员 AWS 服务 和 IAM Identity Center 管理员之间的协作。有关更多信息，请参阅[先决条件和注意事项](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overall-prerequisites.html)。

有关限制，请参阅[IAM Identity Center 集成限制](identity-center-lf-notes.md)。

**Topics**
+ [IAM Identity Center 与 Lake Formation 集成的先决条件](prerequisites-identity-center.md)
+ [将 Lake Formation 与 IAM Identity Center 连接](connect-lf-identity-center.md)
+ [更新 IAM Identity Center 集成](update-lf-identity-center-connection.md)
+ [删除 Lake Formation 与 IAM Identity Center 的连接](delete-lf-identity-center-connection.md)
+ [向用户和组授予权限](grant-permissions-sso.md)
+ [在 CloudTrail 日志中包含 IAM 身份中心用户上下文](identity-center-ct-logs.md)

# IAM Identity Center 与 Lake Formation 集成的先决条件
<a name="prerequisites-identity-center"></a>

 以下是将 IAM Identity Center 与 Lake Formation 集成的先决条件。

1. 启用 IAM Identity Center – 启用 IAM Identity Center 是支持身份验证和身份传播的先决条件。

1. 选择您的身份源 – 启用 IAM Identity Center 后，您必须有身份提供者来管理用户和组。您可以使用内置的 Identity Center 目录作为身份源，也可以使用外部 IdP，例如 Microsoft Entra ID 或 Okta。

    有关更多信息，请参阅《 AWS IAM Identity Center 用户指南》中的 “[管理您的身份源](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html)” 和 “[Connect 到外部身份提供商](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html)”。

1. 创建 IAM 角色 - 创建 IAM Identity Center 连接的角色需要具有在 Lake Formation 和 IAM Identity Center 中创建和修改应用程序配置的权限，如以下内联策略所示。

   您需要按照 IAM 最佳实践添加权限。后面的步骤将会详细介绍具体权限。有关更多信息，请参阅[开始使用 IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-enable-identity-center.html)。

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "lakeformation:CreateLakeFormationIdentityCenterConfiguration",
                   "sso:CreateApplication",
                   "sso:PutApplicationAssignmentConfiguration",
                   "sso:PutApplicationAuthenticationMethod",
                   "sso:PutApplicationGrant",
                   "sso:PutApplicationAccessScope"
               ],
               "Resource": [
                   "*"
               ]
           }
       ]
   }
   ```

------

    如果您要与外部 AWS 账户 或组织共享数据目录资源，则必须具有 AWS Resource Access Manager (AWS RAM) 权限才能创建资源共享。有关共享资源所需权限的更多信息，请参阅[跨账户数据共享先决条件](cross-account-prereqs.md)。

以下内联策略包含查看、更新和删除 Lake Formation 与 IAM Identity Center 集成的属性所需的特定权限。
+ 使用以下内联策略允许 IAM 角色查看 Lake Formation 与 IAM Identity Center 的集成。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "lakeformation:DescribeLakeFormationIdentityCenterConfiguration",
                  "sso:DescribeApplication"
              ],
              "Resource": [
                  "*"
              ]
          }
      ]
  }
  ```

------
+ 使用以下内联策略允许 IAM 角色更新 Lake Formation 与 IAM Identity Center 的集成。该策略还包括与外部账户共享资源所需的可选权限。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "lakeformation:UpdateLakeFormationIdentityCenterConfiguration",
                  "lakeformation:DescribeLakeFormationIdentityCenterConfiguration",
                  "sso:DescribeApplication",
                  "sso:UpdateApplication"
              ],
              "Resource": [
                  "*"
              ]
          }
      ]
  }
  ```

------
+ 使用以下内联策略允许 IAM 角色删除 Lake Formation 与 IAM Identity Center 的集成。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "lakeformation:DeleteLakeFormationIdentityCenterConfiguration",
                  "sso:DeleteApplication"
              ],
              "Resource": [
                  "*"
              ]
          }
      ]
  }
  ```

------
+ 有关授予或撤销 IAM Identity Center 用户和组的数据湖权限所需的 IAM 权限，请参阅[授予或撤销 Lake Formation 权限所需的 IAM 权限](required-permissions-for-grant.md)。

*权限描述*
+ `lakeformation:CreateLakeFormationIdentityCenterConfiguration` – 创建 Lake Formation IdC 配置。
+ `lakeformation:DescribeLakeFormationIdentityCenterConfiguration` – 描述现有的 IdC 配置。
+ `lakeformation:DeleteLakeFormationIdentityCenterConfiguration` – 允许删除现有的 Lake Formation IdC 配置。
+ `lakeformation:UpdateLakeFormationIdentityCenterConfiguration` – 用于更改现有的 Lake Formation 配置。
+ `sso:CreateApplication` – 用于创建 IAM Identity Center 应用程序。
+ `sso:DeleteApplication` – 用于删除 IAM Identity Center 应用程序。
+ `sso:UpdateApplication` – 用于更新 IAM Identity Center 应用程序。
+ `sso:PutApplicationGrant` – 用于更改可信令牌发布者信息。
+ `sso:PutApplicationAuthenticationMethod` – 授予 Lake Formation 身份验证访问权限。
+ `sso:GetApplicationGrant` – 用于列出可信令牌发布者信息。
+ `sso:DeleteApplicationGrant` – 删除可信令牌颁发者信息。
+ `sso:PutApplicationAccessScope` – 添加或更新应用程序的 IAM Identity Center 访问范围的授权目标列表。
+ `sso:PutApplicationAssignmentConfiguration` – 用于配置用户访问应用程序的方式。

# 将 Lake Formation 与 IAM Identity Center 连接
<a name="connect-lf-identity-center"></a>

您必须先完成以下步骤，然后才能使用 IAM Identity Center 管理身份以使用 Lake Formation 授予对数据目录资源的访问权限。您可以使用 Lake Formation 控制台或 AWS CLI创建 IAM Identity Center 集成。

------
#### [ AWS 管理控制台 ]

**将 Lake Formation 与 IAM Identity Center 连接**

1. 登录并打开 Lake AWS 管理控制台 Formation 控制台，网址为[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)。

1. 在左侧导航窗格中，选择 **IAM Identity Center 集成**。  
![\[IAM Identity Center 与 Identity Center ARN 的集成屏幕。\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/identity-center-integ.png)

1. （可选）输入一个或多个有效的组织 AWS 账户 IDs IDs、 and/or 组织单位， IDs 以允许外部帐户访问数据目录资源。当 IAM Identity Center 用户或组尝试访问 Lake Formation 托管式数据目录资源时，Lake Formation 会代入 IAM 角色来授权访问元数据。如果 IAM 角色属于没有 AWS Glue 资源策略和 AWS RAM 资源共享的外部账户，那么 IAM Identity Center 用户和群组即使拥有 Lake Formation 权限，也无法访问该资源。

   Lake Formation 使用 AWS Resource Access Manager (AWS RAM) 服务与外部账户和组织共享资源。 AWS RAM 向被授权者账户发送接受或拒绝资源共享的邀请。

   有关更多信息，请参阅 [接受来自的资源共享邀请 AWS RAM](accepting-ram-invite.md)。
**注意**  
Lake Formation 允许外部账户中的 IAM 角色代表 IAM Identity Center 用户和组作为访问数据目录资源的载体角色，但只能在所有者账户内授予对数据目录资源的权限。如果您尝试在外部账户中向 IAM Identity Center 用户和组授予对数据目录资源的权限，那么 Lake Formation 会引发以下错误：“Cross-account grants are not supported for the principal.” 

1. （可选）在**创建 Lake Formation 集成**屏幕上，指定哪些第三方应用程序可以访问注册到 Lake Formation 的 Amazon S3 位置中的数据。 ARNs Lake Formation 根据有效权限以 AWS STS 令牌的形式向已注册的 Amazon S3 地点出售限定范围的临时证书，以便授权的应用程序可以代表用户访问数据。

1. （可选）在**创建 Lake Formation 集成**屏幕上，选中 “可信身份传播” 中的 Amazon Redshift Connect 复选框，启用通过 IDC 发现亚马逊 Redshift 联合权限。Lake Formation 根据有效的权限向下游传播身份，这样获得授权的应用程序就能够代表用户访问数据。

1. 选择**提交**。

   Lake Formation 管理员完成这些步骤并创建集成后，IAM Identity Center 属性将显示在 Lake Formation 控制台中。完成这些任务后，Lake Formation 将成为启用了 IAM Identity Center 的应用程序。控制台中的属性包括集成状态。集成完成后，状态显示为 `Success`。此状态指示 IAM Identity Center 配置是否已完成。

------
#### [ AWS CLI ]
+ 以下示例演示如何创建 Lake Formation 与 IAM Identity Center 的集成。您还可以指定该应用程序的 `Status`（`ENABLED`、`DISABLED`）。

  ```
  aws lakeformation create-lake-formation-identity-center-configuration \
      --catalog-id <123456789012> \
      --instance-arn <arn:aws:sso:::instance/ssoins-112111f12ca1122p> \
      --share-recipients '[{"DataLakePrincipalIdentifier": "<123456789012>"},
                          {"DataLakePrincipalIdentifier": "<555555555555>"}]' \
      --external-filtering '{"AuthorizedTargets": ["<app arn1>", "<app arn2>"], "Status": "ENABLED"}'
  ```
+ 以下示例演示如何查看 Lake Formation 与 IAM Identity Center 的集成。

  ```
  aws lakeformation describe-lake-formation-identity-center-configuration
   --catalog-id <123456789012>
  ```
+ 以下示例说明如何启用`Redshift:Connect`授权。可以启用或禁用授权。

  ```
  aws lakeformation  create-lake-formation-identity-center-configuration \
  --instance-arn <arn:aws:sso:::instance/ssoins-112111f12ca1122p> \
  --service-integrations '[{
    "Redshift": [{
      "RedshiftConnect": {
        "Authorization": "ENABLED"
      }
    }]
  }]'
  ```
+ 使用`describe-lake-formation-identity-center-configuration`命令描述湖泊形成身份中心应用程序。 `Redshift:Connect`服务集成对于跨服务和跨集群 IdC 身份传播至关重要：

  ```
  aws lakeformation describe-lake-formation-identity-center-configuration --catalog-id <123456789012>
  ```

  响应：

  ```
  {
      "CatalogId": "CATALOG ID",
      "InstanceArn": "INSTANCE ARN",
      "ApplicationArn": "APPLICATION ARN",
      "ShareRecipients": [],
      "ServiceIntegrations": [
          {
              "Redshift": [
                  {
                      "RedshiftConnect": {
                          "Authorization": "ENABLED"
                      }
                  }
              ]
          }
      ]
  }
  ```

------

## 跨多个 IAM 身份中心使用 AWS 区域
<a name="connect-lf-identity-center-multi-region"></a>

Lake Formation 以多种方式支持 IAM 身份中心 AWS 区域。您可以将 IAM Identity Center 从您的主区域扩展 AWS 区域 到其他区域，从而通过靠近用户和提高可靠性来提高性能。在 IAM Identity Center 中添加新区域后，您可以在新区域中创建 Lake Formation Identity Center 应用程序，而无需从主区域复制身份。有关开始在多个区域使用 IAM 身份中心的更多详细信息，请参阅 [IAM 身份中心用户指南中的多区域](https://docs.aws.amazon.com/singlesignon/latest/userguide/multi-region-iam-identity-center.html) *IAM 身份中心*。

# 更新 IAM Identity Center 集成
<a name="update-lf-identity-center-connection"></a>

创建连接后，您可以为 IAM Identity Center 集成添加第三方应用程序，以便与 Lake Formation 集成，并可以代表用户访问 Amazon S3 数据。您也可以从 IAM Identity Center 集成中移除现有应用程序。您可以使用 Lake Formation 控制台和[UpdateLakeFormationIdentityCenterConfiguration](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_UpdateLakeFormationIdentityCenterConfiguration.html)操作添加或删除应用程序。 AWS CLI

**注意**  
创建 IAM Identity Center 集成后，您无法更新实例 `ARN`。

------
#### [ AWS 管理控制台 ]

**更新 IAM Identity Center 与 Lake Formation 的现有连接**

1. 登录并打开 Lake AWS 管理控制台 Formation 控制台，网址为[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)。

1. 在左侧导航窗格中，选择 **IAM Identity Center 集成**。

1. 在 **IAM Identity Center 集成**页面上选择**添加**。

1. 输入一个或多个有效的组织 AWS 账户 IDs IDs、 and/or 组织单位， IDs 以允许外部帐户访问数据目录资源。

1. 在**添加应用程序**屏幕上，输入要与 Lake Formation 集成的第三方应用程序的应用程序。 IDs 

1. 选择**添加**。

1. （可选）在 **IAM 身份中心集成**页面上，您可以为 Amazon Redshift 连接启用可信身份传播，也可以将其禁用。Lake Formation 根据有效的权限向下游传播身份，这样获得授权的应用程序就能够代表用户访问数据。

------
#### [ AWS CLI ]

您可以通过运行以下 AWS CLI 命令为 IAM Identity Center 集成添加或删除第三方应用程序。当您将外部筛选状态设置为 `ENABLED` 时，它使 IAM Identity Center 能够为第三方应用程序提供身份管理，以便访问 Lake Formation 管理的数据。您还可以通过设置应用程序状态来启用或禁用 IAM Identity Center 集成。

```
aws lakeformation update-lake-formation-identity-center-configuration \
 --external-filtering '{"AuthorizedTargets": ["<app arn1>", "<app arn2>"], "Status": "ENABLED"}'\
 --share-recipients '[{"DataLakePrincipalIdentifier": "<444455556666>"}
                     {"DataLakePrincipalIdentifier": "<777788889999>"}]' \
 --application-status ENABLED
```

如果您已有 LF IDC 应用程序，但希望添加`Redshift:Connect`授权，则可以使用以下内容更新您的 Lake Formation IDC 应用程序。可以启用或禁用授权。

```
aws lakeformation update-lake-formation-identity-center-configuration \
--service-integrations '[{                                                            
  "Redshift": [{
    "RedshiftConnect": {
      "Authorization": "ENABLED"
    }
  }]
}]'
```

------

# 删除 Lake Formation 与 IAM Identity Center 的连接
<a name="delete-lf-identity-center-connection"></a>

 如果您想删除现有的 IAM 身份中心集成，可以使用 Lake Formation 控制台或[DeleteLakeFormationIdentityCenterConfiguration](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_DeleteLakeFormationIdentityCenterConfiguration.html)操作来删除。 AWS CLI

------
#### [ AWS 管理控制台 ]

**删除 IAM Identity Center 与 Lake Formation 的现有连接**

1. 登录并打开 Lake AWS 管理控制台 Formation 控制台，网址为[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)。

1. 在左侧导航窗格中，选择 **IAM Identity Center 集成**。

1. 在 **IAM Identity Center 集成**页面上选择**删除**。

1. 在**确认集成**屏幕上，确认该操作，然后选择**删除**。

------
#### [ AWS CLI ]

您可以通过运行以下 AWS CLI 命令删除 IAM Identity Center 集成。

```
 aws lakeformation delete-lake-formation-identity-center-configuration \
     --catalog-id <123456789012>
```

------

# 向用户和组授予权限
<a name="grant-permissions-sso"></a>

您的数据湖管理员可以向 IAM Identity Center 用户和组授予对数据目录资源（数据库、表和视图）的权限，以便轻松访问数据。要授予或撤销数据湖权限，授予者需要具有执行以下 IAM Identity Center 操作的权限。
+ [DescribeUser](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_DescribeUser.html)
+ [DescribeGroup](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_DescribeGroup.html)
+ [DescribeInstance](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_DescribeInstance.html)

您可以使用 Lake Formation 控制台、API 或 AWS CLI来授予权限。

有关授予权限的更多信息，请参阅[授予对数据目录资源的权限](granting-catalog-permissions.md)。

**注意**  
您只能授予对账户中资源的权限。要将权限级联到用户和群组对与您共享的资源，您必须使用 AWS RAM 资源共享。

------
#### [ AWS 管理控制台 ]

**向用户和组授予权限**

1. 登录并打开 Lake AWS 管理控制台 Formation 控制台，网址为[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)。

1. 在 Lake Formation 控制台的**权限**下，选择**数据湖权限**。

1. 选择**授予**。

1. 在**授予数据湖权限**页面上，选择 **IAM Identity Center** 用户和组。

1. 选择**添加**以选择要授予权限的用户和组。  
![\[选中 IAM Identity Center 用户和组的“授予数据湖权限”屏幕。\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/identity-center-grant-perm.png)

1. 在 “**分配用户和群组**” 屏幕上，选择要授予权限的用户 and/or 组。

   选择**分配**。  
![\[选中 IAM Identity Center 用户和组的“授予数据湖权限”屏幕。\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/identity-center-assign-users-groups.png)

1. 接下来，选择授予权限的方法。

   有关使用命名资源方法授予权限的说明，请参阅[使用命名资源方法授予数据权限](granting-cat-perms-named-resource.md)。

   有关使用 LF 标签授予权限的说明，请参阅[使用 LF-TBAC 方法授予数据湖权限](granting-catalog-perms-TBAC.md)。

1. 选择要授予其权限的数据目录资源。

1. 选择要授予的数据目录权限。

1. 选择**授予**。

------
#### [ AWS CLI ]

以下示例演示如何向 IAM Identity Center 用户授予对表的 `SELECT` 权限。

```
aws lakeformation grant-permissions \
--principal DataLakePrincipalIdentifier=arn:aws:identitystore:::user/<UserId> \
--permissions "SELECT" \
--resource '{ "Table": { "DatabaseName": "retail", "TableWildcard": {} } }'
```

要`UserId`从 IAM 身份中心检索，请参阅 IAM 身份中心 API 参考中的[GetUserId](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_GetUserId.html)操作。

------

# 在 CloudTrail 日志中包含 IAM 身份中心用户上下文
<a name="identity-center-ct-logs"></a>

Lake Formation 使用[凭证售卖](using-cred-vending.md)功能提供对 Amazon S3 数据的临时访问权限。默认情况下，当 IAM Identity Center 用户向集成分析服务提交查询时， CloudTrail 日志仅包含该服务为提供短期访问而承担的 IAM 角色。如果您使用用户定义的角色向 Lake Formation 注册 Amazon S3 数据位置，则可以选择在 CloudTrail 事件中包含 IAM 身份中心用户的上下文，然后跟踪访问您资源的用户。

**重要**  
要在中包含对象级的 Amazon S3 API 请求 CloudTrail，您需要为 Amazon S3 存储桶和对象启用 CloudTrail 事件记录。有关更多信息，请参阅 Amazon S3 用户指南中的[为 Amazon S3 存储桶和对象启用 CloudTrail 事件记录](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html)。

**在使用用户定义的角色注册的数据湖位置上启用凭证售卖审计**

1. 登录 Lake Formation 控制台，网址为[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)。

1. 在左侧导航中，展开**管理**，然后选择**数据目录设置**。

1. 在**增强审计**下，选择**传播提供的上下文**。

1. 选择**保存**。

 您也可以通过在[PutDataLakeSettings](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_PutDataLakeSettings.html)操作中设置`Parameters`属性来启用增强审计选项。默认情况下，`SET_CONTEXT"` 参数值设置为 true。

```
{
    "DataLakeSettings": {
        "Parameters": {"SET_CONTEXT": "true"},
    }
}
```

以下是带有增强审计选项 CloudTrail 的事件的摘录。此日志包括 IAM Identity Center 用户的会话上下文和 Lake Formation 为访问 Amazon S3 数据位置而代入的用户定义的 IAM 角色。参见以下摘录中的 `onBehalfOf` 参数。

```
{
         "eventVersion":"1.09",
         "userIdentity":{
            "type":"AssumedRole",
            "principalId":"AROAW7F7MOX4OYE6FLIFN:access-grants-e653760c-4e8b-44fd-94d9-309e035b75ab",
            "arn":"arn:aws:sts::123456789012:assumed-role/accessGrantsTestRole/access-grants-e653760c-4e8b-44fd-94d9-309e035b75ab",           
            "accountId":"123456789012",
            "accessKeyId":"ASIAW7F7MOX4CQLD4JIZN",
            "sessionContext":{
               "sessionIssuer":{
                  "type":"Role",
                  "principalId":"AROAW7F7MOX4OYE6FLIFN",
                  "arn":"arn:aws:iam::123456789012:role/accessGrantsTestRole",
                  "accountId":"123456789012",
                  "userName":"accessGrantsTestRole"
               },
               "attributes":{
                  "creationDate":"2023-08-09T17:24:02Z",
                  "mfaAuthenticated":"false"
               }
            },
            "onBehalfOf":{
                "userId": "<identityStoreUserId>",
                "identityStoreArn": "arn:aws:identitystore::<restOfIdentityStoreArn>"
            }
         },
         "eventTime":"2023-08-09T17:25:43Z",
         "eventSource":"s3.amazonaws.com",
         "eventName":"GetObject",
    ....
```

# 向数据湖添加 Amazon S3 位置
<a name="register-data-lake"></a>

要将数据位置添加为数据湖中的存储空间，请向*注册*该位置（**数据湖位置**） AWS Lake Formation。然后，您可以使用 Lake Formation 权限对指向该位置的 AWS Glue Data Catalog 对象以及该位置中的基础数据进行精细的访问控制。

Lake Formation 还允许在混合访问模式下注册数据位置，并让您能够灵活地选择为数据目录中的数据库和表启用 Lake Formation 权限。在混合访问模式下，您可以通过增量路径为一组特定用户设置 Lake Formation 权限，而不会干扰其它现有用户或工作负载的权限策略。

有关设置混合访问模式的更多信息，请参阅[混合访问模式](hybrid-access-mode.md) 

当您注册某个位置时，将注册 Amazon S3 路径以及该路径下的所有文件夹。

例如，假设您有一个如下所示的 Amazon S3 路径组织：

`/mybucket/accounting/sales/`

如果您注册了 `S3://mybucket/accounting`，则 `sales` 文件夹也会被注册并由 Lake Formation 管理。

有关注册位置的更多信息，请参阅[Underlying data access control](access-control-underlying-data.md#underlying-data-access-control)。

**注意**  
建议对结构化数据（按包含行和列的表进行排列）使用 Lake Formation 权限。如果您的数据包含基于对象的非结构化数据，请考虑使用 Amazon S3 访问权限管控来管理数据访问。

**Topics**
+ [用于注册位置的角色的要求](registration-role.md)
+ [注册 Amazon S3 位置](register-location.md)
+ [注册加密的 Amazon S3 位置](register-encrypted.md)
+ [在另一个 AWS 账户中注册 Amazon S3 营业地点](register-cross-account.md)
+ [跨 AWS 账户注册加密的 Amazon S3 位置](register-cross-encrypted.md)
+ [取消注册 Amazon S3 位置](unregister-location.md)

# 用于注册位置的角色的要求
<a name="registration-role"></a>

注册亚马逊简单存储服务 AWS Identity and Access Management (Amazon S3) 位置时，必须指定 (IAM) 角色。 AWS Lake Formation 在访问该位置的数据时担任该角色。

您可以使用以下角色类型之一来注册位置：
+ Lake Formation 服务相关角色。此角色授予对该位置的所需权限。使用此角色是注册位置的最简单方法。有关更多信息，请参阅[在 Lake Formation 中使用服务相关角色](service-linked-roles.md)和[服务相关角色限制](service-linked-role-limitations.md)。
+ 用户定义的角色。当您需要授予的权限多于服务相关角色提供的权限时，请使用用户定义的角色。

  在以下情况下，您必须使用用户定义的角色：
  + 在其他账户中注册位置时。

    有关更多信息，请参阅[在另一个 AWS 账户中注册 Amazon S3 营业地点](register-cross-account.md)和[跨 AWS 账户注册加密的 Amazon S3 位置](register-cross-encrypted.md)。
  + 如果您使用 AWS 托管 CMK (`aws/s3`) 对 Amazon S3 位置进行加密。

    有关更多信息，请参阅 [注册加密的 Amazon S3 位置](register-encrypted.md)。
  + 如果您计划使用 Amazon EMR。

    如果您已使用服务相关角色注册了某个位置，并且想要开始使用 Amazon EMR 访问该位置，则必须取消注册该位置，然后使用用户定义的角色重新注册该位置。有关更多信息，请参阅 [取消注册 Amazon S3 位置](unregister-location.md)。

# 在 Lake Formation 中使用服务相关角色
<a name="service-linked-roles"></a>

AWS Lake Formation 使用 AWS Identity and Access Management (IAM) *服务相关角色*。服务相关角色是一种独特类型的 IAM 角色，它与 Lake Formation 直接相关。服务相关角色由 Lake Formation 预定义，包括该服务代表您调用其他 AWS 服务所需的所有权限。

服务相关角色可让您更轻松地设置 Lake Formation，因为您不必创建角色并手动添加必要的权限。Lake Formation 定义其服务相关角色的权限，除非另有定义，否则只有 Lake Formation 可以代入该角色。定义的权限包括信任策略和权限策略，以及不能附加到任何其他 IAM 实体的权限策略。

此服务相关角色仅信任以下服务来代入该角色：
+ `lakeformation.amazonaws.com`

当您使用账户 A 中的服务相关角色注册账户 B 所拥有的 Amazon S3 位置时，账户 B 中的 Amazon S3 存储桶策略（基于资源的策略）必须向账户 A 中的服务相关角色授予访问权限。

有关使用服务相关角色注册数据位置的信息，请参阅[服务相关角色限制](service-linked-role-limitations.md)。

**注意**  
服务控制策略 (SCPs) 不影响服务相关角色。  
有关更多信息，请参阅*AWS Organizations 用户指南*中的[服务控制策略 (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。

## Lake Formation 的服务相关角色权限
<a name="service-linked-role-permissions"></a>

Lake Formation 使用名为 `AWSServiceRoleForLakeFormationDataAccess` 的服务相关角色。此角色提供了一组亚马逊简单存储服务 (Amazon S3) 权限，这些权限使 Lake Formation 集成服务（ Amazon Athena例如）能够访问注册地点。注册数据湖位置时，必须提供具有该位置所需的 Amazon S3 read/write 权限的角色。您可以使用此服务相关角色，而不是创建具有所需 Amazon S3 权限的角色。

首次将服务相关角色命名为用于注册路径的角色时，将代表您创建服务相关角色和新的 IAM 策略。Lake Formation 将路径添加到内联策略，并将其附加到服务相关角色。当您向服务相关角色注册后续路径时，Lake Formation 会将该路径添加到现有策略中。

以数据湖管理员身份登录后，注册数据湖位置。然后，在 IAM 控制台中，搜索角色 `AWSServiceRoleForLakeFormationDataAccess` 并查看其附加的策略。

例如，在您注册位置 `s3://my-kinesis-test/logs` 后，Lake Formation 会创建以下内联策略并将其附加到 `AWSServiceRoleForLakeFormationDataAccess`。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "LakeFormationDataAccessPermissionsForS3",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject",
                "s3:AbortMultipartUpload",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::my-kinesis-test/logs/*"
            ]
        },
        {
            "Sid": "LakeFormationDataAccessPermissionsForS3ListBucket",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:ListBucketMultipartUploads"
            ],
            "Resource": [
                "arn:aws:s3:::my-kinesis-test"
            ]
        }
    ]
}
```

------

## 为 Lake Formation 创建服务相关角色
<a name="create-slr"></a>

您无需手动创建服务关联角色。当你在 AWS 管理控制台、或 AWS API 中向 Lake Formation 注册一个 Amazon S3 地点时，Lake Formation 会为你创建服务相关角色。 AWS CLI

**重要**  
如果您在其他使用此角色支持的功能的服务中完成某个操作，此服务关联角色可以出现在您的账户中。要了解更多信息，请参阅[我的 IAM 账户中出现新角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)。

如果您删除该服务关联角色，然后需要再次创建，您可以使用相同流程在账户中重新创建此角色。当您向 Lake Formation 注册 Amazon S3 位置时，Lake Formation 会再次为您创建服务相关角色。

您也可以使用 IAM 控制台为 **Lake Formation** 使用案例创建服务相关角色。在 AWS CLI 或 AWS API 中，使用服务名称创建服务相关角色。`lakeformation.amazonaws.com`有关更多信息，请参阅 *IAM 用户指南* 中的[创建服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role)。如果您删除了此服务相关角色，可以使用同样的过程再次创建角色。

## 为 Lake Formation 编辑服务相关角色
<a name="edit-slr"></a>

Lake Formation 不允许您编辑 `AWSServiceRoleForLakeFormationDataAccess` 服务相关角色。创建服务关联角色后，您将无法更改角色的名称，因为可能有多种实体引用该角色。但是可以使用 IAM 编辑角色描述。有关更多信息，请参阅《IAM 用户指南》**中的[编辑服务关联角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)。

## 为 Lake Formation 删除服务相关角色
<a name="delete-slr"></a>

如果不再需要使用某个需要服务关联角色的功能或服务，我们建议您删除该角色。这样就没有未被主动监控或维护的未使用实体。但是，必须先清除服务相关角色的资源，然后才能手动删除它。

**注意**  
如果在您试图删除资源时 Lake Formation 服务正在使用该角色，则删除操作可能会失败。如果发生这种情况，请等待几分钟后重试。

**删除 Lake Formation 使用的 Lake Formation 资源**
+ 如果您使用服务相关角色向 Lake Formation 注册了 Amazon S3 位置，则在删除服务相关角色之前，需要注销该位置，然后使用自定义角色重新注册。

**使用 IAM 手动删除服务关联角色**

使用 IAM 控制台 AWS CLI、或 AWS API 删除`AWSServiceRoleForLakeFormationDataAccess`服务相关角色。有关更多信息，请参见 *IAM 用户指南*中的[删除服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)。

以下是用户定义的角色的要求：
+ 创建新角色时，在 IAM 控制台的**创建角色**页面上，选择 **AWS 服务**，然后在**选择一个使用案例**下选择 **Lake Formation**。

  如果使用其他路径创建角色，请确保该角色与 `lakeformation.amazonaws.com` 具有信任关系。有关更多信息，请参阅[修改角色信任策略（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html)。
+ 该角色必须具有授予 Amazon S3 read/write 对该位置的权限的内联策略。以下是典型的策略。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "s3:PutObject",
                  "s3:GetObject",
                  "s3:DeleteObject"
              ],
              "Resource": [
                  "arn:aws:s3:::awsexamplebucket/*"
              ]
          },
          {
              "Effect": "Allow",
              "Action": [
                  "s3:ListBucket"
              ],
              "Resource": [
                  "arn:aws:s3:::awsexamplebucket"
              ]
          }
      ]
  }
  ```

------
+ 将以下信任策略添加到 IAM 角色，以便 Lake Formation 服务代入该角色并将临时凭证提供给集成的分析引擎。

  要在 CloudTrail 日志中包含 IAM Identity Center 用户上下文，信任策略必须具有该`sts:SetContext`操作的权限。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Sid": "DataCatalogViewDefinerAssumeRole1",
              "Effect": "Allow",
              "Principal": {
                 "Service": [                    
                      "lakeformation.amazonaws.com"
                   ]
              },
              "Action": [
                  "sts:AssumeRole",
                  "sts:SetContext"
              ]
          }
      ]
  }
  ```

------
+ 注册该位置的数据湖管理员必须具有对该角色的 `iam:PassRole` 权限。

  以下是授予此权限的内联策略。*<account-id>*替换为有效的 AWS 账号，然后*<role-name>*替换为角色的名称。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Sid": "PassRolePermissions",
              "Effect": "Allow",
              "Action": [
                  "iam:PassRole"
              ],
              "Resource": [
                  "arn:aws:iam::111122223333:role/<role-name>"
              ]
          }
      ]
  }
  ```

------
+ 要允许 Lake Formati CloudWatch on 在日志中添加日志并发布指标，请添加以下内联策略。
**注意**  
写入 CloudWatch 日志会产生费用。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Sid": "Sid1",
              "Effect": "Allow",
              "Action": [
                  "logs:CreateLogStream",
                  "logs:CreateLogGroup",
                  "logs:PutLogEvents"
              ],
              "Resource": [
                   "arn:aws:logs:us-east-1:111122223333:log-group:/aws-lakeformation-acceleration/*",
                   "arn:aws:logs:us-east-1:111122223333:log-group:/aws-lakeformation-acceleration/*:log-stream:*"
              ]
          }
      ]
  }
  ```

------

# 注册 Amazon S3 位置
<a name="register-location"></a>

注册亚马逊简单存储服务 AWS Identity and Access Management (Amazon S3) 位置时，必须指定 (IAM) 角色。Lake Formation 在向访问该位置数据的集成 AWS 服务授予临时证书时担任该角色。

**重要**  
避免注册启用了**请求者付费**的 Amazon S3 存储桶。对于在 Lake Formation 中注册的存储桶，用于注册存储桶的角色始终被视为请求者。如果存储桶被其他 AWS 账户访问，则如果该角色与存储桶拥有者属于同一个账户，则该存储桶拥有者需要支付数据访问费用。

您可以使用 AWS Lake Formation 控制台、Lake Formation API 或 AWS Command Line Interface (AWS CLI) 注册亚马逊 S3 地点。

**开始前的准备工作**  
查看[用于注册位置的角色的要求](registration-role.md)。

**注册位置（控制台）**
**重要**  
以下过程假设 Amazon S3 位置与数据目录位于同一个 AWS 账户中，并且该位置中的数据未加密。本章中的其他部分介绍了跨账户注册和加密位置的注册。

1. 打开 AWS Lake Formation 控制台，网址为[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)。以数据湖管理员或具有 `lakeformation:RegisterResource` IAM 权限的用户身份登录。

1. 在导航窗格的**管理**下，选择**数据湖位置**。

1. 选择**注册位置**，然后选择**浏览**以选择 Amazon Simple Storage Service (Amazon S3) 路径。

1. （可选，但强烈推荐）选择**查看位置权限**以查看所选 Amazon S3 位置中所有现有资源及其权限的列表。

   注册所选位置可能会导致 Lake Formation 用户可以访问该位置已有的数据。查看此列表有助于确保现有数据保持安全。

1. 对于 **IAM 角色**，选择 `AWSServiceRoleForLakeFormationDataAccess` 服务相关角色（默认）或符合[用于注册位置的角色的要求](registration-role.md)中要求的自定义 IAM 角色。

   只有在使用自定义 IAM 角色注册已注册位置时，您才能更新该位置或其他详细信息。要编辑使用服务相关角色注册的位置，应取消注册该位置，然后重新注册。

1. 选择 “**启用数据目录联**合” 选项，允许 Lake Formation 代入角色并向集成 AWS 服务提供临时凭证，以访问联合数据库下的表。如果某个位置已注册到 Lake Formation，并且您希望对联合数据库下的表使用同一位置，则需要使用**启用数据目录联合身份验证**选项注册该同一位置。

1. 选择**混合访问模式**以默认不启用 Lake Formation 权限。当您在混合访问模式下注册 Amazon S3 位置时，您可以通过选择该位置下的数据库和表的主体来启用 Lake Formation 权限。 

   有关设置混合访问模式的更多信息，请参阅[混合访问模式](hybrid-access-mode.md)。

1. 选择**注册位置**。

**注册位置 (AWS CLI)**

1. 

**向 Lake Formation 注册新位置**

   此示例使用服务相关角色注册位置。您可以改用 `--role-arn` 参数来提供自己的角色。

   *<s3-path>*替换为有效的 Amazon S3 路径、*<s3-access-role>*使用有效 AWS 账户的账号以及有权注册数据位置的 IAM 角色。
**注意**  
如果已注册位置是使用服务相关角色注册的，则无法编辑该位置的属性。

   ```
   aws lakeformation register-resource \
    --resource-arn arn:aws:s3:::<s3-path> \
    --use-service-linked-role
   ```

   以下示例使用自定义角色注册位置。

   ```
   aws lakeformation register-resource \
    --resource-arn arn:aws:s3:::<s3-path> \
    --role-arn arn:aws:iam::<123456789012>:role/<s3-access-role>
   ```

1. 

**更新向 Lake Formation 注册的位置**

   仅当使用自定义 IAM 角色注册已注册位置时，您才能对其进行编辑。对于使用服务相关角色注册的位置，应取消注册该位置并重新注册。有关更多信息，请参阅 [取消注册 Amazon S3 位置](unregister-location.md)。

   ```
   aws lakeformation update-resource \
    --role-arn arn:aws:iam::<123456789012>:role/<s3-access-role>\
    --resource-arn arn:aws:s3:::<s3-path>
   ```

   ```
   aws lakeformation update-resource \
    --resource-arn arn:aws:s3:::<s3-path> \
    --use-service-linked-role
   ```

1. 

**在混合访问模式下使用联合身份验证注册数据位置**

   ```
   aws lakeformation register-resource \
    --resource-arn arn:aws:s3:::<s3-path> \
    --role-arn arn:aws:iam::<123456789012>:role/<s3-access-role> \
    --hybrid-access-enabled
   ```

   ```
   aws lakeformation register-resource \
    --resource-arn arn:aws:s3:::<s3-path> \
    --role-arn arn:aws:iam::<123456789012>:role/<s3-access-role> \
    --with-federation
   ```

   ```
   aws lakeformation update-resource \
    --resource-arn arn:aws:s3:::<s3-path> \
    --role-arn arn:aws:iam::<123456789012>:role/<s3-access-role> \
    --hybrid-access-enabled
   ```

有关更多信息，请参阅 [RegisterResource](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_RegisterResource.html)API 操作。

**注意**  
注册了 Amazon S3 位置后，任何指向该地点（或其任何子位置）的 AWS Glue 表都将返回`GetTable`调用`true`中`IsRegisteredWithLakeFormation`参数的值。存在一个已知限制，即数据目录 API 操作（如 `GetTables` 和 `SearchTables`）不会更新 `IsRegisteredWithLakeFormation` 参数的值，并返回默认值 false。建议使用 `GetTable` API 查看 `IsRegisteredWithLakeFormation` 参数的正确值。

# 注册加密的 Amazon S3 位置
<a name="register-encrypted"></a>

Lake Formation 与 [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) (AWS KMS) 集成，使您能够更轻松地设置其他集成服务，以加密和解密 Amazon Simple Storage Service (Amazon S3) 位置中的数据。

既由客户管理 AWS KMS keys ，又 AWS 托管式密钥 受支持。目前，只有 encryption/decryption Athena 支持客户端。

在注册 Amazon S3 营业地点时，您必须指定 AWS Identity and Access Management (IAM) 角色。对于加密的 Amazon S3 位置，要么角色必须具有使用加密和解密数据的权限 AWS KMS key，要么是 KMS 密钥策略必须向该角色授予对密钥的权限。

**重要**  
避免注册启用了**请求者付费**的 Amazon S3 存储桶。对于在 Lake Formation 中注册的存储桶，用于注册存储桶的角色始终被视为请求者。如果存储桶被其他 AWS 账户访问，则如果该角色与存储桶拥有者属于同一个账户，则该存储桶拥有者需要支付数据访问费用。

Lake Formation 使用服务相关角色来注册数据位置。但此角色有几项[限制](service-linked-role-limitations.md)。由于这些限制，我们建议改为创建和使用自定义 IAM 角色，以获得更高的灵活性和更强的控制力。您为注册位置而创建的自定义角色必须满足[用于注册位置的角色的要求](registration-role.md)中指定的要求。

**重要**  
如果您使用 AWS 托管式密钥 来加密 Amazon S3 位置，则无法使用 Lake Formation 服务相关角色。您必须使用一个自定义角色，并向该角色添加对密钥的 IAM 权限。本部分后面将提供相关详细信息。

以下过程说明如何注册使用客户自主管理型密钥或 AWS 托管式密钥加密的 Amazon S3 位置。
+ [注册使用客户自主管理型密钥加密的位置](#proc-register-cust-cmk)
+ [注册使用加密的地点 AWS 托管式密钥](#proc-register-aws-cmk)

**开始前的准备工作**  
查看[用于注册位置的角色的要求](registration-role.md)。<a name="proc-register-cust-cmk"></a>

**注册使用客户自主管理型密钥加密的 Amazon S3 位置**
**注意**  
如果 KMS 密钥或 Amazon S3 位置与数据目录不在同一个 AWS 账户中，请[跨 AWS 账户注册加密的 Amazon S3 位置](register-cross-encrypted.md)改为按照中的说明进行操作。

1. 在 [https://console.aws.amazon.com/km](https://console.aws.amazon.com/kms) s 上打开 AWS KMS 控制台，以 AWS Identity and Access Management (IAM) 管理用户或可以修改用于加密位置的 KMS 密钥策略的用户身份登录。

1. 在导航窗格中，选择**客户自主管理型密钥**，然后选择所需的 KMS 密钥的名称。

1. 在 KMS 密钥详细信息页面上，选择**密钥策略**选项卡，然后执行以下任一操作将您的自定义角色或 Lake Formation 服务相关角色添加为 KMS 密钥用户：
   + **如果显示默认视图（包括 “****密钥管理员**”、“密**钥删除**”、“**密钥用户**” 和 “**其他 AWS 账户**” 部分），则在 “**密钥用户**” 部分下，添加您的自定义角色或 Lake Formation 服务相关角色`AWSServiceRoleForLakeFormationDataAccess`。
   + **如果显示密钥策略 (JSON)** – 编辑策略以将您的自定义角色或 Lake Formation 服务相关角色 `AWSServiceRoleForLakeFormationDataAccess` 添加到“Allow use of the key”对象，如以下示例所示。
**注意**  
如果缺少该对象，请使用示例中显示的权限添加该对象。该示例使用服务相关角色。

     ```
             ...
             {
                 "Sid": "Allow use of the key",
                 "Effect": "Allow",
                 "Principal": {
                     "AWS": [
                         "arn:aws:iam::111122223333:role/aws-service-role/lakeformation.amazonaws.com/AWSServiceRoleForLakeFormationDataAccess",
                         "arn:aws:iam::111122223333:user/keyuser"
                     ]
                 },
                 "Action": [
                     "kms:Encrypt",
                     "kms:Decrypt",
                     "kms:ReEncrypt*",
                     "kms:GenerateDataKey*",
                     "kms:DescribeKey"
                 ],
                 "Resource": "*"
             },
             ...
     ```

1. 打开 AWS Lake Formation 控制台，网址为[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)。以数据湖管理员或具有 `lakeformation:RegisterResource` IAM 权限的用户身份登录。

1. 在导航窗格的**管理**下，选择**数据湖位置**。

1. 选择**注册位置**，然后选择**浏览**以选择 Amazon Simple Storage Service (Amazon S3) 路径。

1. （可选，但强烈推荐）选择**查看位置权限**以查看所选 Amazon S3 位置中所有现有资源及其权限的列表。

   注册所选位置可能会导致 Lake Formation 用户可以访问该位置已有的数据。查看此列表有助于确保现有数据保持安全。

1. 对于 **IAM 角色**，选择 `AWSServiceRoleForLakeFormationDataAccess` 服务相关角色（默认）或符合[用于注册位置的角色的要求](registration-role.md)的自定义角色。

1. 选择**注册位置**。

有关服务相关角色的更多信息，请参阅 [Lake Formation 的服务相关角色权限](service-linked-roles.md#service-linked-role-permissions)。<a name="proc-register-aws-cmk"></a>

**注册使用加密的 Amazon S3 地点 AWS 托管式密钥**
**重要**  
如果 Amazon S3 位置与数据目录不在同一个 AWS 账户中，请[跨 AWS 账户注册加密的 Amazon S3 位置](register-cross-encrypted.md)改为按照中的说明进行操作。

1. 创建用于注册位置的 IAM 角色。确保该角色符合[用于注册位置的角色的要求](registration-role.md)中列出的要求。

1. 将下面的内联策略附加到该角色。该策略会向该角色授予对密钥的权限。`Resource` 规范必须指定 AWS 托管式密钥的 Amazon 资源名称 (ARN)。您可以从控制台获取 ARN。 AWS KMS 要获得正确的 ARN，请确保使用与加密该位置相同的 AWS 账户和区域登录 AWS KMS 控制台。 AWS 托管式密钥 

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "kms:Encrypt",
           "kms:Decrypt",
           "kms:ReEncrypt*",
           "kms:GenerateDataKey*",
           "kms:DescribeKey"
         ],
         "Resource": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
       }
     ]
   }
   ```

------

   您可以使用 KMS 密钥别名代替密钥 ID - `arn:aws:kms:region:account-id:key/alias/your-key-alias`

   有关更多信息，请参阅《 AWS Key Management Service 开发人员指南》[中的 “别名](https://docs.aws.amazon.com/kms/latest/developerguide/kms-alias.html)” 一 AWS KMS节。

1. 打开 AWS Lake Formation 控制台，网址为[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)。以数据湖管理员或具有 `lakeformation:RegisterResource` IAM 权限的用户身份登录。

1. 在导航窗格的**管理**下，选择**数据湖位置**。

1. 选择**注册位置**，然后选择**浏览**以选择 Amazon S3 路径。

1. （可选，但强烈推荐）选择**查看位置权限**以查看所选 Amazon S3 位置中所有现有资源及其权限的列表。

   注册所选位置可能会导致 Lake Formation 用户可以访问该位置已有的数据。查看此列表有助于确保现有数据保持安全。

1. 对于 **IAM 角色**，选择您在步骤 1 中创建的角色。

1. 选择**注册位置**。

# 在另一个 AWS 账户中注册 Amazon S3 营业地点
<a name="register-cross-account"></a>

AWS Lake Formation 允许您跨账户注册亚马逊简单存储服务 (Amazon S3) Service 地点 AWS 。例如，如果在账户 A 中， AWS Glue Data Catalog 则账户 A 中的用户可以在账户 B 中注册 Amazon S3 存储桶。

使用账户 A 中的 AWS Identity and Access Management (IAM) 角色在 AWS 账户 B 中 AWS 注册 Amazon S3 存储桶需要以下权限：
+ 账户 A 中的角色必须授予对账户 B 中存储桶的权限。
+ 账户 B 中的存储桶策略必须向账户 A 中的角色授予访问权限。

**重要**  
避免注册启用了**请求者付费**的 Amazon S3 存储桶。对于在 Lake Formation 中注册的存储桶，用于注册存储桶的角色始终被视为请求者。如果存储桶被其他 AWS 账户访问，则如果该角色与存储桶拥有者属于同一个账户，则该存储桶拥有者需要支付数据访问费用。  
您不能使用 Lake Formation 服务相关角色在其他账户中注册位置。您必须改用用户定义的角色。该角色必须符合[用于注册位置的角色的要求](registration-role.md)中的要求。有关服务相关角色的更多信息，请参阅 [Lake Formation 的服务相关角色权限](service-linked-roles.md#service-linked-role-permissions)。

**开始前的准备工作**  
查看[用于注册位置的角色的要求](registration-role.md)。

**在其他 AWS 账户中注册营业地点**
**注意**  
如果该位置已加密，请改为按照[跨 AWS 账户注册加密的 Amazon S3 位置](register-cross-encrypted.md)中的说明进行操作。

以下过程假定包含数据目录的账户 1111-2222-3333 中的主体想要注册位于账户 1234-5678-9012 中的 Amazon S3 存储桶 `awsexamplebucket1`。

1. 在账户 1111-2222-3333 中，登录 AWS 管理控制台 并打开 IAM 控制台，网址为。[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)

1. 创建新角色或查看符合[用于注册位置的角色的要求](registration-role.md)中要求的现有角色。确保该角色授予对 `awsexamplebucket1` 的 Amazon S3 权限。

1. 打开 Amazon S3 控制台，网址为 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)。使用账户 1234-5678-9012 登录。

1. 在**存储桶名称**列表中，选择存储桶名称 `awsexamplebucket1`。

1. 选择**权限**。

1. 在**权限**页面上，选择**存储桶策略**。

1. 在**存储桶策略编辑器**中，粘贴以下策略。将 *<role-name>* 替换为您的角色的名称。

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect":"Allow",
               "Principal": {
                   "AWS":"arn:aws:iam::111122223333:role/<role-name>"
               },
               "Action":"s3:ListBucket",
               "Resource":"arn:aws:s3:::awsexamplebucket1"
           },
           {
               "Effect":"Allow",
               "Principal": {
                   "AWS":"arn:aws:iam::111122223333:role/<role-name>"
               },
               "Action": [
                   "s3:DeleteObject",
                   "s3:GetObject",
                   "s3:PutObject"
               ],
               "Resource":"arn:aws:s3:::awsexamplebucket1/*"
           }
       ]
   }
   ```

------

1. 选择**保存**。

1. 打开 AWS Lake Formation 控制台，网址为[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)。以数据湖管理员或具有足够权限注册位置的用户身份登录账户 1111-2222-3333。

1. 在导航窗格的**管理**下，选择**数据湖位置**。

1. 在**数据湖位置**页面上，选择**注册位置**。

1. 在**注册位置**页面上，对于 **Amazon S3 路径**，输入存储桶名称 `s3://awsexamplebucket1`。
**注意**  
您必须键入存储桶名称，因为当您选择**浏览**时，跨账户存储桶不会显示在列表中。

1. 对于 **IAM 角色**，选择您的角色。

1. 选择**注册位置**。

# 跨 AWS 账户注册加密的 Amazon S3 位置
<a name="register-cross-encrypted"></a>

AWS Lake Formation 与 [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)(AWS KMS) 集成，使您能够更轻松地设置其他集成服务，以加密和解密亚马逊简单存储服务 (Amazon S3) 中的数据。

同时支持客户管理 AWS 托管式密钥 的密钥和。 encryption/decryption 不支持客户端。

**重要**  
避免注册启用了**请求者付费**的 Amazon S3 存储桶。对于在 Lake Formation 中注册的存储桶，用于注册存储桶的角色始终被视为请求者。如果存储桶被其他 AWS 账户访问，则如果该角色与存储桶拥有者属于同一个账户，则该存储桶拥有者需要支付数据访问费用。

本部分介绍如何在以下情况下注册 Amazon S3 位置：
+ Amazon S3 位置中的数据使用在 AWS KMS中创建的 KMS 密钥进行加密。
+ Amazon S3 的营业地点与不在同一个 AWS 账户中 AWS Glue Data Catalog。
+ KMS 密钥与数据目录位于或不在同一个 AWS 账户中。

使用账户 A 中的 AWS Identity and Access Management (IAM) 角色在 AWS 账户 B 中 AWS 注册 AWS KMS加密的 Amazon S3 存储桶需要以下权限：
+ 账户 A 中的角色必须授予对账户 B 中存储桶的权限。
+ 账户 B 中的存储桶策略必须向账户 A 中的角色授予访问权限。
+ 如果 KMS 密钥位于账户 B 中，则密钥策略必须向账户 A 中的角色授予访问权限，并且账户 A 中的角色必须授予对 KMS 密钥的权限。

在以下步骤中，您将在包含数据目录的 AWS 账户（前面讨论中的账户 A）中创建一个角色。然后，使用此角色注册位置。Lake Formation 在访问 Amazon S3 中的基础数据时代入此角色。代入的角色具有对 KMS 密钥的所需权限。因此，您不必向使用 ETL 作业或集成服务（如 Amazon Athena）访问基础数据的主体授对 KMS 密钥的权限。

**重要**  
您不能使用 Lake Formation 服务相关角色在其他账户中注册位置。您必须改用用户定义的角色。该角色必须符合[用于注册位置的角色的要求](registration-role.md)中的要求。有关服务相关角色的更多信息，请参阅 [Lake Formation 的服务相关角色权限](service-linked-roles.md#service-linked-role-permissions)。

**开始前的准备工作**  
查看[用于注册位置的角色的要求](registration-role.md)。

**跨 AWS 账户注册加密的 Amazon S3 营业地点**

1. 使用与数据目录相同的 AWS 账户，登录 AWS 管理控制台 并打开 IAM 控制台，网址为[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。

1. 创建新角色或查看符合[用于注册位置的角色的要求](registration-role.md)中要求的现有角色。确保该角色包含授予对该位置的 Amazon S3 权限的策略。

1. 如果 KMS 密钥与数据目录不在同一账户中，请向该角色附加一个内联策略，该策略授予对 KMS 密钥的所需权限。以下是示例策略。将区域和账户 ID 替换为 KMS 密钥所在的区域和账号。*<key-id>*替换为密钥 ID。

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
           "Effect": "Allow",
           "Action": [
               "kms:Encrypt",
               "kms:Decrypt",
               "kms:ReEncrypt*",
               "kms:GenerateDataKey*",
               "kms:DescribeKey"
            ],
           "Resource": "arn:aws:kms:us-east-1:111122223333:key/<key-id>"
           }
       ]
   }
   ```

------

1. 在 Amazon S3 控制台上，添加存储桶策略，该策略向该角色授予所需的 Amazon S3 权限。下面是一个示例存储桶策略。将账户 ID 替换为数据目录的 AWS 账号、*<role-name>*您的角色*<bucket-name>*名称和存储桶的名称。

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect":"Allow",
               "Principal": {
                   "AWS":"arn:aws:iam::111122223333:role/<role-name>"
               },
               "Action":"s3:ListBucket",
               "Resource":"arn:aws:s3:::<bucket-name>"
           },
           {
               "Effect":"Allow",
               "Principal": {
                   "AWS":"arn:aws:iam::111122223333:role/<role-name>"
               },
               "Action": [
                   "s3:DeleteObject",
                   "s3:GetObject",
                   "s3:PutObject"
               ],
               "Resource":"arn:aws:s3:::<bucket-name>/*"
           }
       ]
   }
   ```

------

1. 在中 AWS KMS，将角色添加为 KMS 密钥的用户。

   1. 在 [https://console.aws.amazon.com/km AWS KMS](https://console.aws.amazon.com/kms) s 处打开控制台。然后，以管理员用户或可以修改用于加密位置的 KMS 密钥策略的用户身份登录。

   1. 在导航窗格中，选择**客户自主管理型密钥**，然后选择 KMS 密钥的名称。

   1. 在“KMS 密钥详细信息”页面的**密钥策略**选项卡下，如果未显示密钥策略的 JSON 视图，请选择**切换到策略视图**。

   1. 在**密钥策略**部分中，选择**编辑**，然后将该角色的 Amazon 资源名称 (ARN) 添加到 `Allow use of the key` 对象，如以下示例所示。
**注意**  
如果缺少该对象，请使用示例中显示的权限添加该对象。

      ```
              ...
              {
                  "Sid": "Allow use of the key",
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": [
                          "arn:aws:iam::<catalog-account-id>:role/<role-name>"
                      ]
                  },
                  "Action": [
                      "kms:Encrypt",
                      "kms:Decrypt",
                      "kms:ReEncrypt*",
                      "kms:GenerateDataKey*",
                      "kms:DescribeKey"
                  ],
                  "Resource": "*"
              },
              ...
      ```

      有关更多信息，请参阅《AWS Key Management Service 开发人员指南》中的[允许其他账户中的用户使用 KMS 密钥](https://docs.amazonaws.cn/en_us/kms/latest/developerguide/key-policy-modifying-external-accounts.html)。**

       

1. 打开 AWS Lake Formation 控制台，网址为[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)。以数据湖管理员身份登录数据目录 AWS 账户。

1. 在导航窗格的**管理**下，选择**数据湖位置**。

1. 选择**注册位置**。

1. 在**注册位置**页面上，对于 **Amazon S3 路径**，输入位置路径 **s3://*<bucket>*/*<prefix>***。*<bucket>*替换为存储桶的*<prefix>*名称和该位置路径的其余部分。
**注意**  
您必须键入该路径，因为当您选择**浏览**时，跨账户存储桶不会显示在列表中。

1. 对于 **IAM 角色**，从步骤 2 中选择角色。

1. 选择**注册位置**。

# 取消注册 Amazon S3 位置
<a name="unregister-location"></a>

如果您不再希望 Amazon Simple Storage Service (Amazon S3) 位置由 Lake Formation 管理，则可以取消注册该位置。取消注册某个位置不会影响对该位置授予的 Lake Formation 数据位置权限。您可以重新注册已取消注册的位置，并且数据位置权限仍然有效。您可以使用其他角色重新注册该位置。

**取消注册位置（控制台）**

1. 打开 AWS Lake Formation 控制台，网址为[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)。以数据湖管理员或具有 `lakeformation:RegisterResource` IAM 权限的用户身份登录。

1. 在导航窗格的**管理**下，选择**数据湖位置**。

1. 选择一个位置，然后在**操作**菜单上选择**删除**。

1. 当系统提示进行确认时，选择**删除**。

# 混合访问模式
<a name="hybrid-access-mode"></a>

AWS Lake Formation *混合访问模式*支持访问相同 AWS Glue Data Catalog 对象的两种权限路径。  在第一条途径中，Lake Formation 允许您选择特定的主体，并通过选择操作向他们授予用于访问目录、数据库、表和视图的 Lake Formation 权限。第二种途径允许所有其他委托人通过 Amazon S3 的默认 IAM 委托人策略和 AWS Glue 操作访问这些资源。

在 Lake Formation 中注册 Amazon S3 位置时，您可以选择对该位置的所有资源强制实施 Lake Formation 权限，也可以选择使用混合访问模式。默认情况下，混合访问模式仅强制实施 `CREATE_TABLE`、`CREATE_PARTITION`、`UPDATE_TABLE` 权限。当 Amazon S3 位置处于混合模式时，您可以通过为该位置下的 Data Catalog 对象选择主体来启用 Lake Formation 权限。这意味着 Lake Formation 权限和 IAM 权限都可以控制对该数据的访问。这意味着选择加入的委托人将需要 Lake Formation 权限和 IAM 权限才能访问数据，而 non-opted-in委托人将继续仅使用 IAM 权限访问数据。

因此，通过混合访问模式，您可以灵活且有选择性地为一组特定用户针对 Data Catalog 中的目录、数据库和表启用 Lake Formation，而不会中断其他现有用户或工作负载的访问。

![\[AWS 账户 architecture showing data flow between S3, Glue, Lake Formation, Athena, and IAM roles.\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/hybrid-access-mode-concept.png)


有关注意事项和限制，请参阅[混合访问模式注意事项和限制](notes-hybrid.md)。术语和定义

 以下是基于您对访问权限的设置方式的数据目录资源定义：

Lake Formation 资源  
 已向 Lake Formation 注册的资源。用户需要 Lake Formation 权限才能访问该资源。

AWS Glue 资源  
未向 Lake Formation 注册的资源。用户只需 IAM 权限即可访问该资源，因为它具有 `IAMAllowedPrincipals` 组权限。Lake Formation 权限不会被强制实施。  
有关 `IAMAllowedPrincipals` 组权限的更多信息，请参阅[元数据权限](metadata-permissions.md)。

混合资源  
在混合访问模式下注册的资源。根据访问资源的用户，该资源会在充当 Lake Formation 资源或 AWS Glue 资源之间动态切换。

## 常见的混合访问模式使用案例
<a name="hybrid-access-mode-use-cases"></a>

您可以在单账户和跨账户数据共享场景中使用混合访问模式提供访问权限：

**单账户场景**
+ 将@@ ** AWS Glue 资源转换为混合**资源-在这种情况下，您当前未使用 Lake Formation，但希望对数据目录对象采用 Lake Formation 权限。当您在混合访问模式下注册 Amazon S3 位置时，您可以向选择使用指向该位置的特定数据库和表的用户授予 Lake Formation 权限。
+ **将 Lake Formation 资源转换为混合资源** – 目前，您正在使用 Lake Formation 权限控制对数据目录数据库的访问，但希望在不中断现有 Lake Formation 权限的情况下，使用适用于 Amazon S3 和 AWS Glue 的 IAM 权限为新主体提供访问权限。

  当您将数据位置注册更新为混合访问模式时，新的主体可以使用 IAM 权限策略访问指向 Amazon S3 位置的数据目录数据库，而不会中断现有用户的 Lake Formation 权限。

  在更新数据位置注册以启用混合访问模式之前，您需要先选择当前使用 Lake Formation 权限访问资源的主体。  这是为了防止当前工作流可能出现中断。  您还需要向 `IAMAllowedPrincipal` 组授予对数据库中表的 `Super` 权限。

**跨账户数据共享场景**
+ **使用混合访问模式共享 AWS Glue 资源**-在这种情况下，创建者账户在数据库中拥有表，这些表当前使用针对 Amazon S3 和 AWS Glue 操作的 IAM 权限策略与消费者账户共享。数据库的数据位置未在 Lake Formation 中注册。

   在混合访问模式下注册数据位置之前，您需要将**跨账户版本设置**更新为版本 4。版本 4 提供了`IAMAllowedPrincipal`群组拥有资源 AWS RAM 权限时跨账户共享所需的新`Super`权限策略。对于那些具有 `IAMAllowedPrincipal` 组权限的资源，您可以向外部账户授予 Lake Formation 权限，并选择他们以使他们可以使用 Lake Formation 权限。接收方账户中的数据湖管理员可以向账户中的主体授予 Lake Formation 权限，并选择他们以强制实施 Lake Formation 权限。
+ **使用混合访问模式共享 Lake Formation 资源** — 当前，制作者账户拥有与强制实施 Lake Formation 权限的使用者账户共享的数据库中的表。数据库的数据位置在 Lake Formation 中注册。

  在这种情况下，您可以将 Amazon S3 位置注册更新为混合访问模式，并针对使用者账户中的主体使用 Amazon S3 存储桶策略和数据目录资源策略来共享来自 Amazon S3 的数据和来自数据目录的元数据。在更新 Amazon S3 位置注册之前，您需要重新授予现有的 Lake Formation 权限并选择主体。此外，您还需要向 `IAMAllowedPrincipals` 组授予对数据库中表的 `Super` 权限。

**Topics**
+ [常见的混合访问模式使用案例](#hybrid-access-mode-use-cases)
+ [混合访问模式的工作原理](hybrid-access-workflow.md)
+ [设置混合访问模式 - 常见场景](hybrid-access-setup.md)
+ [从混合访问模式下删除主体和资源](delete-hybrid-access.md)
+ [在混合访问模式下查看主体和资源](view-hybrid-access.md)
+ [其他资源](additional-resources-hybrid.md)

# 混合访问模式的工作原理
<a name="hybrid-access-workflow"></a>

下图显示了查询数据目录资源时 Lake Formation 授权在混合访问模式下的工作原理。

![\[AWS Lake Formation authorization process flowchart for hybrid access mode queries.\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/hybrid-workflow.png)


在访问数据湖中的数据之前，数据湖管理员或具有管理权限的用户会设置单个数据目录表用户策略以允许或拒绝访问数据目录中的表。然后，有权执行 `RegisterResource` 操作的主体在混合访问模式下向 Lake Formation 中注册表的 Amazon S3 位置。如果数据位置未向 Lake Formation 注册，则管理员向特定用户授予对 Data Catalog 数据库和表的 Lake Formation 权限，并选择他们以使他们能够在混合访问模式下对这些数据库和表使用 Lake Formation 权限。

1. **提交查询**-委托人使用集成服务（例如亚马逊 Athena、Amazon EMR 或 AWS Glue Amazon Redshift Spectrum）提交查询或 ETL 脚本。

1. **请求数据** - 集成分析引擎可识别正在请求的表，并向数据目录发送元数据请求（`GetTable`、`GetDatabase`）。

1. **检查权限** - 数据目录可通过 Lake Formation 验证查询主体的访问权限。

   1. 如果该表未附加 `IAMAllowedPrincipals` 组权限，则会强制实施 Lake Formation 权限。

   1. 如果主体选择在混合访问模式下使用 Lake Formation 权限，并且该表附加了 `IAMAllowedPrincipals` 组权限，则会强制实施 Lake Formation 权限。查询引擎应用从 Lake Formation 接收的筛选条件，并将数据返回给用户。

   1. 如果表位置未在 Lake Formation 中注册，并且主体未选择在混合访问模式下使用 Lake Formation 权限，则数据目录将检查该表是否附加了 `IAMAllowedPrincipals` 组权限。如果针对该表存在此权限，则该账户中的所有主体均将获得对该表的 `Super` 或 `All` 权限。

      除非数据位置已向 Lake Formation 注册，否则即使选择加入，也无法自动提供 Lake Formation 凭证。

1. **获取凭证** - 数据目录会检查表位置是否已在 Lake Formation 中注册并将结果告知引擎。如果基础数据已在 Lake Formation 中注册，则分析引擎会请求 Lake Formation 提供临时凭证，以访问 Amazon S3 存储桶中的数据。

1. **获取数据** - 如果主体有权访问表数据，Lake Formation 将提供对集成分析引擎的临时访问权限。通过使用临时访问权限，分析引擎可从 Amazon S3 获取数据，并执行必要的筛选，例如列、行或单元格筛选。当引擎运行完作业后，它会将结果返回给用户。此过程称为凭证售卖。有关更多信息，请参阅[将第三方服务与 Lake Formation 集成](Integrating-with-LakeFormation.md)。

1.  如果表的数据位置未在 Lake Formation 中注册，则分析引擎将直接向 Amazon S3 进行第二次调用。系统会对相关 Amazon S3 存储桶策略和 IAM 用户策略进行评估以确定是否支持访问数据。每当您使用 IAM 策略时，请确保遵循 IAM 最佳实践。有关更多信息，请参阅《IAM 用户指南》中的 [IAM 中的安全最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)。

# 设置混合访问模式 - 常见场景
<a name="hybrid-access-setup"></a>

与 Lake Formation 权限一样，您通常有两种类型的场景可以使用混合访问模式来管理数据访问权限：在一个场景中提供对委托人的访问权限， AWS 账户 以及提供对外部 AWS 账户 或委托人的访问权限。

 本节提供有关在以下场景下设置混合访问模式的说明：

**在一个混合访问模式下管理权限 AWS 账户**
+ [将 AWS Glue 资源转换为混合资源](hybrid-access-mode-new.md)— 您目前正在使用 Amazon S3 的 IAM 权限为账户中的所有委托人提供数据库中表的访问权限， AWS Glue 但希望采用 Lake Formation 来逐步管理权限。
+ [将 Lake Formation 资源转换为混合资源](hybrid-access-mode-update.md) – 您目前正使用 Lake Formation 管理您账户中的所有主体对数据库中表的访问，但只想使用 Lake Formation 管理特定主体的访问。您想通过对同一数据库和表使用 IAM 权限 AWS Glue 和 Amazon S3 来提供对新委托人的访问权限。

**在混合访问模式下管理跨 AWS 账户的权限**
+ [使用混合访问模式共享 AWS Glue 资源](hybrid-access-mode-cross-account.md) – 您目前未在使用 Lake Formation 管理对表的权限，但想要应用 Lake Formation 权限为其它账户中的主体提供访问权限。
+ [使用混合访问模式共享 Lake Formation 资源](hybrid-access-mode-cross-account-IAM.md)— 您正在使用 Lake Formation 管理表的访问权限，但希望通过对同一数据库 AWS Glue 和表使用 Amazon S3 的 IAM 权限为其他账户中的委托人提供访问权限。

**设置混合访问模式 – 主要步骤**

1. 通过选择**混合访问模式**，在 Lake Formation 中注册 Amazon S3 数据位置。

1. 主体必须拥有对数据湖位置的 `DATA_LOCATION` 权限才能创建指向该位置的数据目录表或数据库。

1.  将**跨账户版本设置**设置为版本 4。

1. 向特定 IAM 用户或角色授予对数据库和表的精细权限。同时，确保为 `IAMAllowedPrincipals` 组设置对数据库以及数据库中所有或部分表的 `Super` 或 `All` 权限。

1. 选择主体和资源。账户中的其他委托人可以使用针对和 Amazon S3 操作的 IAM 权限策略继续访问数据库 AWS Glue 和表。

1. （可选）为选择使用 Lake Formation 权限的主体清除适用于 Amazon S3 的 IAM 权限策略。

# 设置混合访问模式的先决条件
<a name="hybrid-access-prerequisites"></a>

以下是设置混合访问模式的先决条件：

**注意**  
 我们建议 Lake Formation 管理员在混合访问模式下注册 Amazon S3 位置，并选择主体和资源。

1. 授予数据位置权限 (`DATA_LOCATION_ACCESS`)，以创建指向 Amazon S3 位置的数据目录资源。数据位置权限可控制创建指向特定 Amazon S3 位置的 Data Catalog 目录、数据库和表的能力。

1. 要在混合访问模式下与其他账户共享数据目录资源（无需从资源中移除`IAMAllowedPrincipals`组权限），您需要将**跨账户版本设置更新为版本** 4 或更高版本。要使用 Lake Formation 控制台更新**版本，请在**数据目录**设置页面的**跨账户版本设置**下选择版本 4** **或版本 5**。

   您也可以使用`put-data-lake-settings` AWS CLI 命令将`CROSS_ACCOUNT_VERSION`参数设置为版本 4 或 5：

   ```
   aws lakeformation put-data-lake-settings --region us-east-1 --data-lake-settings file://settings
   {
   "DataLakeAdmins": [
           {
   "DataLakePrincipalIdentifier": "arn:aws:iam::<111122223333>:user/<user-name>"
           }
       ],
       "CreateDatabaseDefaultPermissions": [],
       "CreateTableDefaultPermissions": [],
       "Parameters": {
   "CROSS_ACCOUNT_VERSION": "5"
       }
   }
   ```

1.  要在混合访问模式下授予跨账户权限，授予者必须拥有 AWS Glue 和 AWS RAM 服务所需的 IAM 权限。 AWS 托管策略`AWSLakeFormationCrossAccountManager`授予所需的权限。  为了在混合访问模式下启用跨账户数据共享，我们通过添加两项新的 IAM 权限更新了 `AWSLakeFormationCrossAccountManager` 托管策略：
   + 内存:ListResourceSharePermissions
   + 内存:AssociateResourceSharePermission
**注意**  
如果您未使用授予者角色的 AWS 托管策略，请将上述策略添加到您的自定义策略中。

## Amazon S3 存储桶位置和用户访问权限
<a name="w2aac11c34c21c15b9"></a>

在中创建目录、数据库或表时 AWS Glue Data Catalog，您可以指定基础数据的 Amazon S3 存储桶位置并将其注册到 Lake Formation。下表根据表或数据库的 Amazon S3 数据位置描述了权限如何适用 AWS Glue 于 Lake Formation 用户（委托人）。


**注册到 Lake Formation 的 Amazon S3 位置**  

| 数据库的 Amazon S3 位置 | AWS Glue 用户 | Lake Formation 用户 | 
| --- | --- | --- | 
|  已在 Lake Formation 中注册（在混合访问模式或 Lake Formation 模式下）  |  通过继承 IAMAllowed委托人组的权限（超级 read/write 访问权限）权限，可以访问 Amazon S3 数据位置。  | 从授予的 CREATE TABLE 权限中继承创建表的权限。 | 
| 没有关联的 Amazon S3 位置 |  运行 CREATE TABLE 和 INSERT TABLE 语句时需要明确的 DATA LOCATION 权限。  |  运行 CREATE TABLE 和 INSERT TABLE 语句时需要明确的 DATA LOCATION 权限。  | 

****IsRegisteredWithLakeFormation**表属性**  
表的 `IsRegisteredWithLakeFormation` 属性表示该表的数据位置是否已在 Lake Formation 中为请求者注册。如果位置的权限模式注册为 Lake Formation，那么对于访问数据位置的所有用户来说，`IsRegisteredWithLakeFormation` 属性都为 `true`，因为所有用户都被视为已选择使用该表。如果位置是以混合访问模式注册的，那么只有对于已选择使用该表的用户来说，才会将该值设为 `true`。


**`IsRegisteredWithLakeFormation` 的工作原理**  

| 权限模式 | 用户/角色 |  `IsRegisteredWithLakeFormation`  | 说明 | 
| --- | --- | --- | --- | 
|  Lake Formation  | 全部 | True |  在 Lake Formation 中注册位置后，所有用户的 `IsRegisteredWithLakeFormation` 属性都将设为 true。这意味着，Lake Formation 中定义的权限适用于已注册的位置。凭证售卖将由 Lake Formation 完成。  | 
| 混合访问模式 | 已选择使用 | True |  对于已选择使用 Lake Formation 对表进行数据访问和管理的用户，该表的 `IsRegisteredWithLakeFormation` 属性将设为 `true`。这些用户受 Lake Formation 中为已注册位置定义的权限策略的约束。  | 
| 混合访问模式 | 未选择使用 | False |  对于尚未选择使用 Lake Formation 权限的用户，`IsRegisteredWithLakeFormation` 属性设为 `false`。这些用户不受 Lake Formation 中为已注册位置定义的权限策略的约束。相反，用户将遵守 Amazon S3 权限策略。  | 

# 将 AWS Glue 资源转换为混合资源
<a name="hybrid-access-mode-new"></a>

按照以下步骤在混合访问模式下注册 Amazon S3 位置，并在不中断现有数据目录用户数据访问的情况下引导新的 Lake Formation 用户。

场景描述 - 数据位置未在 Lake Formation 中注册，用户对数据目录数据库和表的访问权限由适用于 Amazon S3 和 AWS Glue 操作的 IAM 权限策略决定。  默认情况下，`IAMAllowedPrincipals` 组拥有对数据库中所有表的 `Super` 权限。

**为未在 Lake Formation 中注册的数据位置启用混合访问模式**

1. 

**注册 Amazon S3 位置，以启用混合访问模式。**

------
#### [ Console ]

   1. 以数据湖管理员身份登录 [Lake Formation 控制台](https://console.aws.amazon.com/lakeformation/)。

   1. 在导航窗格中，选择**管理**下的**数据湖位置**。

   1. 选择**注册位置**。  
![\[Register location form for Amazon S3 data lake with path input, IAM role selection, and permission mode options.\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/hybrid-access-register-s3.png)

   1. 在**注册位置**窗口中，选择要在 Lake Formation 中注册的 **Amazon S3** 路径。

   1. 对于 **IAM 角色**，选择 `AWSServiceRoleForLakeFormationDataAccess` 服务相关角色（默认）或符合[用于注册位置的角色的要求](registration-role.md)中要求的自定义 IAM 角色。

   1. 选择**混合访问模式**以应用精细的 Lake Formation 访问控制策略来选择主体以及指向注册位置的数据目录数据库和表。 

      选择 Lake Formation 以允许 Lake Formation 授权对注册位置的访问请求。 

   1. 选择**注册位置**。

------
#### [ AWS CLI ]

   以下是使用:true/false 向 Lake Formation 注册数据位置的 HybridAccessEnabled示例。`HybridAccessEnabled` 参数的默认值为 false。将 Amazon S3 路径、角色名称和 AWS 账户 ID 替换为有效值。

   ```
   aws lakeformation register-resource --cli-input-json file:file path
   json:
       {
           "ResourceArn": "arn:aws:s3:::s3-path",
           "UseServiceLinkedRole": false,
           "RoleArn": "arn:aws:iam::<123456789012>:role/<role-name>",
           "HybridAccessEnabled": true
       }
   ```

------

1. 

**授予权限并选择主体以在混合访问模式下对资源使用 Lake Formation 权限**

   在混合访问模式下选择主体和资源之前，请确认对于在该模式下已使用 Lake Formation 注册了位置的数据库和表，已向 `IAMAllowedPrincipals` 组授予了 `Super` 或 `All` 权限。
**注意**  
您不能向 `IAMAllowedPrincipals` 组授予对数据库中 `All tables` 的权限。您需要从下拉菜单中分别选择每个表，并授予权限。此外，在数据库中创建新表时，可以在**数据目录设置**中选择使用 `Use only IAM access control for new tables in new databases`。当您在数据库中创建新表时，此选项会自动向 `IAMAllowedPrincipals` 组授予 `Super` 权限。

------
#### [ Console ]

   1. 在 Lake Formation 控制台的 **Data Catalog** 下，选择**目录**、**数据库**或**表**。

   1. 从列表中选择目录、数据库或表，然后从**操作**菜单中选择**授予**。

   1. 选择要使用命名资源方法或 LF 标签授予其对数据库、表和列的权限的主体。

      或者，选择**数据权限**，从列表中选择要向其授予权限的主体，然后选择**授予**。

      有关授予数据权限的更多详细信息，请参阅[授予对数据目录资源的权限](granting-catalog-permissions.md)。
**注意**  
如果您要向主体授予创建表的权限，则还需要向主体授予数据位置权限 (`DATA_LOCATION_ACCESS`)。更新表不需要此权限。  
有关更多信息，请参阅 [授予数据位置权限](granting-location-permissions.md)。

   1. 当您使用**命名资源方法**授予权限时，**授予数据权限**页面的下半部分提供了用于选择主体和资源的选项。

      选择**让 Lake Formation 权限立即生效**，为主体和资源启用 Lake Formation 权限。  
![\[为 Data Catalog 资源选择混合访问模式的选项。\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/hybrid-access-grant-option.png)

   1. 选择**授权**。

       当您在指向数据位置的表 A 上选择主体 A 时，如果数据位置是在混合模式下注册的，则为主体 A 提供对该表的位置的 Lake Formation 权限。

------
#### [ AWS CLI ]

   以下是在混合访问模式下选择主体和表的示例。将角色名、 AWS 账户 ID、数据库名称和表名替换为有效值。

   ```
   aws lakeformation create-lake-formation-opt-in --cli-input-json file://file path
   json:
     {
           "Principal": {
               "DataLakePrincipalIdentifier": "arn:aws:iam::<123456789012>:role/<hybrid-access-role>"
           },
           "Resource": {
               "Table": {
                   "CatalogId": "<123456789012>",
                   "DatabaseName": "<hybrid_test>",
                   "Name": "<hybrid_test_table>"
               }
           }
       }
   ```

------

   1. 如果您选择 LF 标签来授予权限，则可以在单独的步骤中选择主体来使用 Lake Formation 权限。您可以通过在左侧导航栏的**权限**下选择**混合访问模式**来执行此操作。

   1.  在**混合访问模式**页面的下半部分，选择**添加**将资源和主体添加到混合访问模式下。

   1.  在**添加资源和主体**页面上，选择在混合访问模式下注册的目录、数据库和表。

      您可以选择数据库下的 `All tables` 以授予主体访问权限。  
![\[在混合访问模式下添加目录、数据库和表的界面。\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/hybrid-access-opt-in.png)

   1. 选择要选择在混合访问模式下使用 Lake Formation 权限的主体。
      +  **主体**：您可以选择同一个账户或另一个账户中的 IAM 用户和角色。您还可以选择 SAML 用户和组。
      + **属性**：根据属性选择要授予权限的属性。  
![\[使用属性表达式添加主体和资源的界面。\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/abac-hybrid-access.png)
      + 输入键值对，根据属性创建授予。在控制台中查看 Cedar 策略表达式。有关 Cedar 的更多信息，请参阅 [What is Cedar? \$1 Cedar 政策语言参考 GuideLink](https://docs.cedarpolicy.com/)。
      + 选择**添加**。

        所有 roles/users 具有匹配属性的 IAM 都被授予访问权限。

   1. 选择**添加**。

# 将 Lake Formation 资源转换为混合资源
<a name="hybrid-access-mode-update"></a>

如果您当前正对数据目录数据库和表使用 Lake Formation 权限，则可以编辑位置注册属性以启用混合访问模式。这样，您就可以在不中断现有 Lake Formation 权限的情况下使用适用于 Amazon S3 的 IAM 权限策略和 AWS Glue 操作为新的委托人提供对相同资源的访问权限。

 场景描述 - 以下步骤假定您已在 Lake Formation 中注册了一个数据位置，并且您已为主体设置了对指向该位置的数据库、表或列的权限。如果该位置是通过服务相关角色注册的，则无法更新位置参数和启用混合访问模式。默认情况下，`IAMAllowedPrincipals` 组对数据库及其所有表拥有 Super 权限。

**重要**  
如果不选择将访问该位置的数据的主体，请勿将位置注册更新为混合访问模式。

**为在 Lake Formation 中注册的数据位置启用混合访问模式**

1. 
**警告**  
我们不建议将 Lake Formation 托管式数据位置转换为混合访问模式，以免中断其它现有用户或工作负载的权限策略。

   选择拥有 Lake Formation 权限的现有主体。

   1. 列出并查看您向主体授予的目录、数据库和表权限。有关更多信息，请参阅 [在 Lake Formation 中查看数据库和表权限](viewing-permissions.md)。

   1. 在左侧导航栏中的**权限**下选择**混合访问模式**，然后选择**添加**。

   1. 在**添加主体和资源**页面上，从 Amazon S3 数据位置中选择要在混合访问模式下使用的目录、数据库和表。选择已经拥有 Lake Formation 权限的主体。

   1.  选择**添加**以选择要在混合访问模式下使用 Lake Formation 权限的主体。

1.  通过选择**混合访问模式**选项来更新 Amazon S3 bucket/prefix 注册。

------
#### [ Console ]

   1. 以数据湖管理员身份登录 Lake Formation 控制台。

   1.  在导航窗格中的**注册和提取**下，选择**数据湖位置**。

   1. 选择一个位置，然后在**操作**菜单上选择**编辑**。

   1. 选择**混合访问模式**。

   1. 选择**保存**。

   1. 在数据目录下，选择数据库或表，然后向名为 `IAMAllowedPrincipals` 的虚拟组授予 `Super` 或 `All` 权限。

   1.  确认在更新位置注册属性时，您的现有 Lake Formation 用户的访问没有中断。以 Lake Formation 主体身份登录 Athena 控制台，然后对指向更新后位置的表运行示例查询。

      同样，验证使用 IAM 权限策略访问数据库和表的 AWS Glue 用户的访问权限。

------
#### [ AWS CLI ]

   以下是使用:true/false 向 Lake Formation 注册数据位置的 HybridAccessEnabled示例。`HybridAccessEnabled` 参数的默认值为 false。将 Amazon S3 路径、角色名称和 AWS 账户 ID 替换为有效值。

   ```
   aws lakeformation update-resource --cli-input-json file://file path
   json:
   {
       "ResourceArn": "arn:aws:s3:::<s3-path>",
       "RoleArn": "arn:aws:iam::<123456789012>:role/<test>",
       "HybridAccessEnabled": true
   }
   ```

------

# 使用混合访问模式共享 AWS Glue 资源
<a name="hybrid-access-mode-cross-account"></a>

在不中断现有数据目录用户基于 IAM 的访问的情况下，与 AWS 账户 执行 Lake Formation 权限的其他人 AWS 账户 或委托人共享数据。

场景描述-创建者账户有一个数据目录数据库，该数据库的访问权限使用适用于 Amazon S3 的 IAM 委托人策略和 AWS Glue 操作进行控制。数据库的数据位置未在 Lake Formation 中注册。默认情况下，`IAMAllowedPrincipals` 组对数据库及其所有表拥有 `Super` 权限。

**在混合访问模式下授予跨账户 Lake Formation 权限**

1. 

**制作者账户设置**

   1. 使用具有 `lakeformation:PutDataLakeSettings` IAM 权限的角色登录 Lake Formation 控制台。

   1. 前往**数据目录设置**，然后在**跨账户版本设置**中选择`Version 4`。

      如果您当前使用的是版本 1 或 2，请参阅有关更新至版本 3 的[更新跨账户数据共享版本设置](optimize-ram.md)说明。

      从版本 3 升级到 4 时，无需更改权限策略。

   1. 注册您计划在混合访问模式下共享的数据库或表的 Amazon S3 位置。

   1. 验证 `IAMAllowedPrincipals` 组对在上述步骤中在混合访问模式下注册其数据位置的数据库和表是否拥有 `Super` 权限。

   1. 向 AWS 组织、组织单位 (OUs) 授予 Lake Formation 权限，或者直接向其他账户中的 IAM 委托人授予 Lake Formation 权限。

   1. 如果您要直接向 IAM 主体授予权限，请选择使用者账户中的主体，通过启用**让 Lake Formation 权限立即生效**选项，在混合访问模式下强制实施 Lake Formation 权限。

       如果您向其他账户授予跨账户权限，则当您选择加入该 AWS 账户时，Lake Formation 权限仅适用于该账户的管理员。接收方账户数据湖管理员需要向下级联权限并选择账户中的主体，才能对处于混合访问模式的共享资源强制实施 Lake Formation 权限。

      如果您选择**通过 LF 标签匹配的资源**选项来授予跨账户权限，则需要先完成权限授予步骤。您可以单独执行一步，通过在 Lake Formation 控制台左侧导航栏的“权限”下选择**混合访问模式**来选择要置于混合访问模式下的主体和资源。然后选择**添加**以添加资源和主体来强制实施 Lake Formation 权限。

1. 

**使用者账户设置**

   1. 以数据湖管理员的身份登录 Lake [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)Formation 控制台。

   1. 返回[https://console.aws.amazon.com/ram/主页](https://console.aws.amazon.com/ram/home)，接受资源共享邀请。 AWS RAM 控制台中的 “**与我共享**” 选项卡显示与您的账户共享的数据库和表。

   1.  在 Lake Formation 中创建指向共享数据库 and/or 表的资源链接。

   1.  向您（使用者）账户中的 IAM 主体授予对资源链接的 `Describe` 权限和对原共享资源的 `Grant on target` 权限。

   1.  向账户中的主体授予对与您共享的数据库或表的 Lake Formation 权限。通过启用**让 Lake Formation 权限立即生效**选项，选择主体和资源以在混合访问模式下强制实施 Lake Formation 权限。

   1.  通过运行示例 Athena 查询来测试主体的 Lake Formation 权限。使用 Amazon S3 的 IAM 委托人策略和 AWS Glue 操作测试 AWS Glue 用户的现有访问权限。

      （可选）为您配置为使用 Lake Formation 权限的主体删除关于数据访问的 Amazon S3 存储桶策略以及适用于 AWS Glue 和 Amazon S3 数据访问的 IAM 主体策略。

# 使用混合访问模式共享 Lake Formation 资源
<a name="hybrid-access-mode-cross-account-IAM"></a>

允许外部账户中的新数据目录用户使用基于 IAM 的策略访问数据目录数据库和表，而无需中断现有的 Lake Formation 跨账户共享权限。

场景描述 - 制作者账户拥有在账户级别或 IAM 主体级别与外部（使用者）账户共享的 Lake Formation 托管数据库和表。数据库的数据位置在 Lake Formation 中注册。`IAMAllowedPrincipals` 组没有对数据库及其表的 `Super` 权限。

**在不中断现有 Lake Formation 权限的情况下，通过基于 IAM 的策略向新的数据目录用户授予跨账户访问权限**

1. 

**制作者账户设置**

   1. 以拥有以下权限的角色登录 Lake Formation 控制台：`lakeformation:PutDataLakeSettings`。

   1. 前往**数据目录设置**，然后在**跨账户版本设置**中选择`Version 4`。

      如果您当前使用的是版本 1 或 2，请参阅有关更新至版本 3 的[更新跨账户数据共享版本设置](optimize-ram.md)说明。

      从版本 3 升级到 4 无需更改权限策略。

   1. 列出您已授予主体的对数据库和表的权限。有关更多信息，请参阅 [在 Lake Formation 中查看数据库和表权限](viewing-permissions.md)。

   1.  通过选择主体和资源来重新授予现有的 Lake Formation 跨账户权限。
**注意**  
在将数据位置注册更新为混合访问模式以授予跨账户权限之前，您需要为每个账户重新授予至少一个跨账户数据共享。要更新附加到 AWS RAM 资源共享的 AWS RAM 托管权限，必须执行此步骤。  
2023 年 7 月，Lake Formation 更新了用于共享数据库和表格的 AWS RAM 托管权限：  
`arn:aws:ram::aws:permission/AWSRAMLFEnabledGlueAllTablesReadWriteForDatabase`（数据库级别共享策略）
`arn:aws:ram::aws:permission/AWSRAMLFEnabledGlueTableReadWrite`（表级别共享策略） 
2023 年 7 月之前授予的跨账户权限没有这些更新的 AWS RAM 权限。  
如果您已直接向主体授予跨账户权限，则需要单独向主体重新授予这些权限。如果跳过此步骤，访问共享资源的主体可能会遇到非法组合错误。

   1. 回[https://console.aws.amazon.com/ram/家](https://console.aws.amazon.com/ram/home)。

   1.  AWS RAM 控制台中的 “**由我共享**” 选项卡显示您与外部账户或委托人共享的数据库和表名。

       确保附加到共享资源的权限具有正确的 ARN。

   1. 验证 AWS RAM 共享中的资源是否处于`Associated`状态。如果状态显示为 `Associating`，请等待，直到它们进入 `Associated` 状态。如果状态变为 `Failed`，请停下来联系 Lake Formation 服务团队。

   1. 在左侧导航栏中的**权限**下选择**混合访问模式**，然后选择**添加**。

   1.  “**添加委托人和资源**” 页面显示了有权访问的数据库、 and/or 表和委托人。您可以通过添加或删除主体和资源来进行所需的更新。

   1.  选择对要更改为混合访问模式的数据库和表拥有 Lake Formation 权限的主体。选择数据库和表。

   1.  选择**添加**以选择要在混合访问模式下强制实施 Lake Formation 权限的主体。

   1.  向虚拟组 `IAMAllowedPrincipals` 授予对您的数据库和所选表的 `Super` 权限。

   1. 将 Amazon S3 位置的 Lake Formation 注册编辑为混合访问模式。

   1. 使用 IAM 权限策略为外部（消费者）账户中的 AWS Glue 用户授予对 Amazon S3 AWS Glue 操作的权限。

1. 

**使用者账户设置**

   1. 以数据湖管理员的身份登录 Lake [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)Formation 控制台。

   1. 返回[https://console.aws.amazon.com/ram/主页](https://console.aws.amazon.com/ram/home)并接受资源共享邀请。 AWS RAM 页面中的 “**与我共享的资源**” 选项卡显示与您的账户共享的数据库和表名。

       对于 AWS RAM 共享，请确保附加的权限具有共享 AWS RAM 邀请的正确 ARN。检查 AWS RAM 共享中的资源是否处于`Associated`状态。如果状态显示为 `Associating`，请等待，直到它们进入 `Associated` 状态。如果状态变为 `Failed`，请停下来联系 Lake Formation 服务团队。

   1.  在 Lake Formation 中创建指向共享数据库 and/or 表的资源链接。

   1.  向您（使用者）账户中的 IAM 主体授予对资源链接的 `Describe` 权限和对原共享资源的 `Grant on target` 权限。

   1. 接下来，为您账户中的主体设置对共享数据库或表的 Lake Formation 权限。

      在左侧导航栏中的**权限**下选择**混合访问模式**。

   1.  在**混合访问模式**页面的下半部分选择**添加**，从制作者账户中选择主体以及与您共享的数据库或表。

   1.  使用 IAM 权限策略向账户中的 AWS Glue 用户授予对 Amazon S3 AWS Glue 操作的权限。

   1.  使用 Athena 在表格上运行单独的示例查询，测试用户的 Lake Formation AWS Glue 权限和权限

      （可选）为处于混合访问模式的主体清除 Amazon S3 的 IAM 权限策略。

# 从混合访问模式下删除主体和资源
<a name="delete-hybrid-access"></a>

 按照以下步骤将数据库、表和主体从混合访问模式下删除。

------
#### [ Console ]

1. 登录 Lake Formation 控制台，网址为[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)。

1. 在**权限**下，选择**混合访问模式**。

1.  在**混合访问模式**页面上，选中数据库或表名称旁边的复选框，然后选择 `Remove`。

1. 此时将显示一条警告消息，提示您确认此操作。选择**移除 **。

   Lake Formation 不再对这些资源强制执行权限，对该资源的访问将使用 IAM 和 AWS Glue 权限进行控制。如果用户没有适当的 IAM 权限，则可能会导致他们无法再访问这些资源。

------
#### [ AWS CLI ]

 以下示例显示了如何从混合访问模式下删除资源。

```
aws lakeformation delete-lake-formation-opt-in --cli-input-json file://file path

json:
{
    "Principal": {
        "DataLakePrincipalIdentifier": "arn:aws:iam::<123456789012>:role/role name"
    },
    "Resource": {
        "Table": {
            "CatalogId": "<123456789012>",
            "DatabaseName": "<database name>",
            "Name": "<table name>"
          }
    }
}
```

------

# 在混合访问模式下查看主体和资源
<a name="view-hybrid-access"></a>

 按照以下步骤在混合访问模式下查看数据库、表和主体。

------
#### [ Console ]

1. 登录 Lake Formation 控制台，网址为[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)。

1. 在**权限**下，选择**混合访问模式**。

1.  **混合访问模式**页面显示当前处于混合访问模式的资源和主体。

------
#### [ AWS CLI ]

 以下示例说明如何列出处于混合访问模式的全部所选主体和资源。

```
      
aws lakeformation list-lake-formation-opt-ins
```

 以下示例说明了如何列出所选择的特定主体-资源对。

```
aws lakeformation list-lake-formation-opt-ins --cli-input-json file://file path

json:
{
    "Principal": {
        "DataLakePrincipalIdentifier": "arn:aws:iam::<account-id>:role/<role name>"
    },
    "Resource": {
        "Table": {
            "CatalogId": "<account-id>",
            "DatabaseName": "<database name>",
            "Name": "<table name>"
          }
    }
}
```

------

# 其他资源
<a name="additional-resources-hybrid"></a>

在以下博客文章中，我们将带您查看有关如何在其他用户已经可以通过 IAM 和 Amazon S3 权限访问数据库时在混合访问模式下为选定用户加载 Lake Formation 权限的说明。我们将查看在一个账户内和两个 AWS 账户之间设置混合访问模式的说明。
+ [引入混合访问模式，使用 Lake Formation、IAM 和 Amazon S3 策略进行安全访问。 AWS Glue Data Catalog](https://aws.amazon.com/blogs/big-data/introducing-hybrid-access-mode-for-aws-glue-data-catalog-to-secure-access-using-aws-lake-formation-and-iam-and-amazon-s3-policies/)

# 在中创建对象 AWS Glue Data Catalog
<a name="populating-catalog"></a>

AWS Lake Formation 使用 AWS Glue Data Catalog （数据目录）存储有关数据湖、数据源、转换和目标的元数据。元数据是与数据集中的底层数据有关的数据。每个 AWS 账户在每个 AWS 区域都有一个数据目录。

Data Catalog 中的元数据按三级数据层次结构（包括目录、数据库和表）进行组织。它将各种来源的数据组织到称为目录的逻辑容器中。每个目录都代表来自 Amazon Redshift 数据仓库、 Amazon DynamoDB 数据库，以及第三方数据来源（例如 Snowflake、MySQL）和 30 多个外部数据来源（它们通过联合连接器进行集成）的数据。您还可以在 Data Catalog 中创建新目录，以便将数据存储在 S3 表存储桶或 Redshift 托管存储（RMS）中。

表存储有关基础数据的信息，包括架构信息、分区信息和数据位置。数据库是表的集合。Data Catalog 还包含资源链接，这些链接是指向外部账户中共享目录、数据库和表的链接，用于跨账户访问数据湖中的数据。

Data Catalog 是一个包含目录、数据库和表格的嵌套目录对象。它由 AWS 账户 ID 引用，是账户和账户中的默认目录 AWS 区域。数据目录使用三级层次结构（目录.数据库.表）来组织表。
+ 目录：Data Catalog 三级元数据层次结构的最顶层。您可以通过联合身份验证在 Data Catalog 中添加多个目录。
+ 数据库：由表和视图组成的元数据层次结构的第二级。在 Amazon Redshift 和 Trino 等许多数据系统中，数据库也被称为架构。
+ 表和视图：Data Catalog 的 3 级数据层次结构的第三级。

Amazon S3 中的所有 Iceberg 表都存储在目录 ID = AWS 账户 ID 的默认数据目录中。您可以通过联合身份在其中创建联合目录 AWS Glue Data Catalog ，用于存储 Amazon Redshift、Amazon S3 表存储或其他第三方数据源中表的定义。

**Topics**
+ [创建目录](creating-catalog.md)
+ [创建数据库](creating-database.md)
+ [创建表](creating-tables.md)
+ [建筑物 AWS Glue Data Catalog 视图](working-with-views.md)

# 创建目录
<a name="creating-catalog"></a>

目录代表 AWS Glue Data Catalog的三级元数据层次结构中的最高或最顶层。您可以使用多种方法将数据引入 Data Catalog 并创建多级目录。

 有关从外部数据来源创建目录的更多信息，请参阅[将您的数据带入 AWS Glue Data Catalog](bring-your-data-overview.md)。

 要使用 Lake Formation 控制台创建目录，您必须以数据湖管理员或*目录创建者*身份登录。目录创建者是已获得 Lake Formation `CREATE_CATALOG` 权限的主体。您可以在 Lake Formation 控制台的**管理角色和任务**页面上查看目录创建者列表。要查看此列表，您必须具有 `lakeformation:ListPermissions` IAM 权限，并以数据湖管理员或通过授予选项获得 `CREATE_CATALOG` 权限的目录创建者身份登录。

# 创建数据库
<a name="creating-database"></a>

数据目录中的元数据表存储在数据库中。您可以根据需要创建任意数量的数据库，并且可以为每个数据库授予不同的 Lake Formation 权限。

数据库可以具有可选的位置属性。此位置通常位于向 Lake Formation 注册的Amazon Simple Storage (Amazon S3) 位置内。指定位置时，主体不需要数据位置权限即可创建指向数据库位置内位置的数据目录表。有关更多信息，请参阅 [Underlying data access control](access-control-underlying-data.md#data-location-permissions)。

要使用 Lake Formation 控制台创建数据库，您必须以数据湖管理员或“数据库创建者”身份登录。**数据库创建者是已被授予 Lake Formation `CREATE_DATABASE` 权限的主体。您可以在 Lake Formation 控制台的**管理角色和任务**页面上查看数据库创建者列表。要查看此列表，您必须具有 `lakeformation:ListPermissions` IAM 权限，并以数据湖管理员或通过授予选项获得 `CREATE_DATABASE` 权限的数据库创建者身份登录。

**创建数据库**

1. 在打开 AWS Lake Formation 控制台 [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)，然后以数据湖管理员或数据库创建者的身份登录。

1. 在导航窗格的**数据目录**下，选择**数据库**。

1. 选择**创建数据库**。

1. 在**创建数据库**对话框中，输入数据库名称、可选位置和可选描述。

1. 取消选中**仅对新数据库中的新表使用 IAM 访问控制**。

   有关此选项的更多信息，请参阅 [更改数据湖的默认设置](change-settings.md)。

1. 选择**创建数据库**。

# 创建表
<a name="creating-tables"></a>

AWS Lake Formation 元数据表包含有关数据湖中数据的信息，包括架构信息、分区信息和数据位置。这些表存储在 AWS Glue 数据目录中。您可以使用它们访问数据湖中的基础数据，并使用 Lake Formation 权限管理这些数据。表存储在数据目录的数据库中。

有以下几种方法可以创建数据目录表：
+ 在 AWS Glue 中运行爬网程序。请参阅《AWS Glue 开发人员指南》中的[定义爬网程序](https://docs.aws.amazon.com/glue/latest/dg/add-crawler.html)。**
+ 创建并运行工作流。请参阅[在 Lake Formation 中使用工作流导入数据](workflows.md)。
+ 使用 Lake Formation 控制台、AWS Glue API 或 AWS Command Line Interface （AWS CLI）手动创建表。
+ 使用创建表 Amazon Athena。
+ 创建指向外部账户中的表的资源链接。请参阅[创建资源链接](creating-resource-links.md)。

# 创建 Apache Iceberg 表
<a name="creating-iceberg-tables"></a>

 AWS Lake Formation 支持创建使用 Apache Parquet 数据格式的 Apache Iceberg 表，数据驻留在 AWS Glue Data Catalog Amazon S3 中。该数据目录中的表是表示数据存储中数据的元数据定义。默认情况下，Lake Formation 会创建 Iceberg v2 表。有关 v1 和 v2 表之间的区别，请参阅 Apache Iceberg 文档中的[格式版本更改](https://iceberg.apache.org/spec/#appendix-e-format-version-changes)。

 [Apache Iceberg](https://iceberg.apache.org/) 是适用于超大型分析数据集的开放表格式。Iceberg 允许轻松更改架构，也称为架构发展，这意味着用户可以在不破坏基础数据的情况下添加、重命名或删除数据表中的列。Iceberg 还支持数据版本控制，允许用户跟踪数据随时间的变化。这将启用时间旅行功能，该功能允许用户访问和查询数据的历史版本，并分析更新和删除之间的数据更改。

你可以使用 Lake Formation 控制台或 AWS Glue API 中的`CreateTable`操作在数据目录中创建 Iceberg 表。有关更多信息，请参阅[CreateTable 操作（Python：create\$1table](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog-tables.html#aws-glue-api-catalog-tables-CreateTable)）。

在数据目录中创建 Iceberg 表时，您必须在 Amazon S3 中指定表格式和元数据文件路径，以便能够执行读取和写入操作。

 在注册 Amazon S3 数据位置时，您可以使用精细的访问控制权限使用 Lake Formation 来保护您的 Iceberg 表。 AWS Lake Formation对于亚马逊 S3 中的源数据和未在 Lake Formation 中注册的元数据，访问权限由 Amazon S3 的 IAM 权限策略和 AWS Glue 操作决定。有关更多信息，请参阅 [管理 Lake Formation 权限](managing-permissions.md)。

**注意**  
数据目录不支持创建分区和添加 Iceberg 表属性。

**Topics**
+ [先决条件](#iceberg-prerequisites)
+ [创建 Iceberg 表](#create-iceberg-table)

## 先决条件
<a name="iceberg-prerequisites"></a>

 要在数据目录中创建 Iceberg 表并设置 Lake Formation 数据访问权限，您需要完成以下要求：

1. 

**在没有向 Lake Formation 注册数据的情况下创建 Iceberg 表所需的权限。**

   除了在数据目录中创建表所需的权限外，表创建者还需要以下权限：
   + 针对资源 arn:aws:s3:::\$1bucketName\$1 的 `s3:PutObject`
   + 针对资源 arn:aws:s3:::\$1bucketName\$1 的 `s3:GetObject`
   + 针对资源 arn:aws:s3:::\$1bucketName\$1 的 `s3:DeleteObject`

1. 

**使用向 Lake Formation 注册的数据创建 Iceberg 表所需的权限：**

   要使用 Lake Formation 管理和保护数据湖中的数据，请向 Lake Formation 注册包含表数据的 Amazon S3 位置。这样，Lake Formation 就可以将证书出售给 Athena、Redshift Spectrum 和 Amazon EMR 等 AWS 分析服务机构以访问数据。有关注册 Amazon S3 位置的更多信息，请参阅[向数据湖添加 Amazon S3 位置](register-data-lake.md)。

   读取和写入向 Lake Formation 注册的基础数据的主体需要以下权限：
   + `lakeformation:GetDataAccess`
   + `DATA_LOCATION_ACCESS`

     对某个位置具有数据位置权限的主体也对所有子位置具有位置权限。

     有关数据位置权限的更多信息，请参阅[基础数据访问控制](access-control-underlying-data.md)。

 要启用压缩，该服务需要代入有权更新数据目录中的表的 IAM 角色。有关详细信息，请参阅[表优化先决条件](https://docs.aws.amazon.com/glue/latest/dg/optimization-prerequisites.html)。

## 创建 Iceberg 表
<a name="create-iceberg-table"></a>

你可以使用 Lake Formation 控制台创建 Iceberg v1 和 v2 表，也可以 AWS Command Line Interface 按照本页上的说明创建。您也可以使用 AWS Glue 控制台或 AWS Glue 爬网程序创建 Iceberg 表。有关更多信息，请参阅《 AWS Glue 开发人员指南》中的[数据目录和爬网程序](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html)。

**创建 Iceberg 表**

------
#### [ Console ]

1. 登录并打开 Lake AWS 管理控制台 Formation 控制台，网址为[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)。

1. 在数据目录下，选择**表**，然后使用**创建表**按钮指定以下属性：
   + **表名称**：输入表的唯一名称。如果您使用 Athena 访问表，请使用《Amazon Athena 用户指南》中的这些[命名提示](https://docs.aws.amazon.com/athena/latest/ug/tables-databases-columns-names.html)。
   + **数据库**：选择现有数据库或创建新数据库。
   + **描述**：表的描述。您可以编写描述以帮助您了解表的内容。
   + **表格式**：对于**表格式**，请选择 Apache Iceberg。  
![\[选择了 Apache Iceberg 表选项和表优化选项。\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/table-optimization.png)
   + **表优化**
     + **压缩** – 此功能会合并和重写数据文件以移除过时数据，并将碎片数据合并到更大、更高效的文件中。
     + **快照保留** – 快照是带有时间戳的 Iceberg 表版本。借助快照保留配置，客户可以强制规定快照保留期限和要保留的快照数量。配置快照保留优化器可以移除不必要的旧快照及其相关底层文件，从而帮助管理存储开销。
     + **孤立文件删除** – 孤立文件是指不再被 Iceberg 表元数据引用的文件。这些文件可能会逐渐堆积，尤其是在表删除或 ETL 任务失败等操作之后。启用孤立文件删除功能可以 AWS Glue 定期识别和删除这些不必要的文件，从而释放存储空间。

     有关更多信息，请参阅[优化 Iceberg 表](https://docs.aws.amazon.com/glue/latest/dg/table-optimizers.html)。
   + **IAM 角色**：为了运行压缩，该服务会代表您代入一个 IAM 角色。您可以使用下拉列表选择一个 IAM 角色。确保该角色具有启用压缩所需的权限。

     要了解有关所需权限的更多信息，请参阅[表优化先决条件](https://docs.aws.amazon.com/glue/latest/dg/optimization-prerequisites.html)。
   + **位置**：指定 Amazon S3 中存储元数据表的文件夹的路径。Iceberg 需要数据目录中的元数据文件和位置才能执行读取和写入。
   + **架构**：选择**添加列**以添加列和列的数据类型。您可以选择创建一个空表，然后稍后更新架构。数据目录支持 Hive 数据类型。有关更多信息，请参阅 [Hive 数据类型](https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=27838462#content/view/27838462)。

      Iceberg 允许您在创建表后演变架构和分区。您可以使用 [Athena 查询](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-evolving-table-schema.html)更新表架构，使用 [Spark 查询](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table-sql-extensions)更新分区。

------
#### [ AWS CLI ]

```
aws glue create-table \
    --database-name iceberg-db \
    --region us-west-2 \
    --open-table-format-input '{
      "IcebergInput": { 
           "MetadataOperation": "CREATE",
           "Version": "2"
         }
      }' \
    --table-input '{"Name":"test-iceberg-input-demo",
            "TableType": "EXTERNAL_TABLE",
            "StorageDescriptor":{ 
               "Columns":[ 
                   {"Name":"col1", "Type":"int"}, 
                   {"Name":"col2", "Type":"int"}, 
                   {"Name":"col3", "Type":"string"}
                ], 
               "Location":"s3://DOC_EXAMPLE_BUCKET_ICEBERG/"
            }
        }'
```

------

# 优化 Iceberg 表
<a name="data-compaction"></a>

Lake Formation 支持多种表优化选项，以增强 AWS 分析引擎和 ETL 作业使用的 Apache Iceberg 表的管理和性能。这些优化器可提高存储空间利用效率、提升查询性能，并实现有效的数据管理。Lake Formation 中提供了三种表优化器：
+ **压缩** – 数据压缩功能可压缩小数据文件，以减少存储空间使用量并提升读取性能。此功能会合并和重写数据文件以移除过时数据，并将碎片数据合并到更大、更高效的文件中。可以根据需要配置为自动运行或手动触发压缩。
+ **快照保留** – 快照是带有时间戳的 Iceberg 表版本。借助快照保留配置，客户可以强制规定快照保留期限和要保留的快照数量。配置快照保留优化器可以移除不必要的旧快照及其相关底层文件，从而帮助管理存储开销。
+ **孤立文件删除** – 孤立文件是指不再被 Iceberg 表元数据引用的文件。这些文件可能会逐渐堆积，尤其是在表删除或 ETL 任务失败等操作之后。启用孤立文件删除功能可以 AWS Glue 定期识别和删除这些不必要的文件，从而释放存储空间。

您可以使用 AWS Glue 控制台或 API 操作为数据目录中的单个 Iceberg 表启用或禁用压缩 AWS CLI、快照保留和孤立文件删除优化器。 AWS Glue 

有关更多信息，请参阅 AWS Glue 开发人员指南中的[优化 Iceberg 表](https://docs.aws.amazon.com/glue/latest/dg/table-optimizers.html)。

# 搜索表
<a name="searching-for-tables"></a>

您可以使用 AWS Lake Formation 控制台按名称、位置、包含的数据库等来搜索数据目录表。搜索结果仅显示您具有 Lake Formation 权限的表。

**搜索表（控制台）**

1. 登录 AWS 管理控制台 并打开 Lake Formation 控制台，网址为[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)。

1. 在导航窗格中，选择**表**。

1. 将光标置于页面顶部的搜索字段中。该字段具有占位符文本“按属性查找表”。**

   此时将显示**属性**菜单，其中显示了要搜索的各种表属性。  
![\[属性菜单从搜索字段中下拉出来，其中包含以下条目：名称、分类、数据库、位置、目录 ID\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/search-for-tables.png)

1. 请执行以下操作之一：
   + 按包含的数据库进行搜索。

     1. 从**属性**菜单中选择**数据库**，然后从显示的**数据库**菜单中选择一个数据库，或者键入数据库名称并按 **Enter**。

        此时将列出您在数据库中具有权限的表。

     1. （可选）要将列表范围缩小到数据库中的单个表，请再次将光标置于搜索字段中，从**属性**菜单中选择**名称**，然后从显示的**表**菜单中选择表名称，或者键入表名称并按 **Enter**。

        此时将列出单个表，并且数据库名称和表名称都显示为搜索字段下的磁贴。  
![\[搜索字段下方有两个磁贴：一个标记为“数据库”（包含所选数据库名称），另一个标记为“表”（包含所选表名称）。磁贴的右侧是“清除筛选条件”按钮。\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/search-for-tables-with-filter.png)

        要调整筛选条件，请关闭任一磁贴或选择**清除筛选条件**。
   + 按其他属性进行搜索。

     1. 从**属性**菜单中选择搜索属性。

        **要按 AWS 账户 ID 进行搜索，请从 “**属性**” 菜单中选择 “**目录 ID**”，输入有效的 AWS 账户 ID（例如 111122223333），然后按 Enter。**

        要按位置进行搜索，请从**属性**菜单中选择**位置**，然后从显示的**位置**菜单中选择一个位置。此时将返回所选位置（例如，Amazon S3）的根位置中的所有表。

**使用搜索表格 AWS CLI**
+ 以下示例说明示如何运行部分搜索。您可以使用 `--search-text` 参数搜索在元数据中包含指定文本的表。在本例中，该搜索会返回所有在名称、描述或其他元数据字段中包含“customer”的表。

  ```
  aws glue search-tables 
        --search-text "customer" 
        --region AWS 区域
        --max-results 10
        --sort-criteria "FieldName=Name,Sort=ASC"
  ```

# 跨 AWS 账户共享数据目录表和数据库
<a name="sharing-catalog-resources"></a>

通过向外部账户授予 Lake Formation 对资源的权限，您可以与外部 AWS 账户共享数据目录资源（数据库和表）。然后，用户可以运行跨多个账户联接和查询表的查询和作业。但有一些限制，当您与其他账户共享数据目录资源时，该账户中的主体可以对该资源进行操作，就像该资源位于其数据目录中一样。

您不会与外部 AWS 账户中的特定委托人共享资源，而是与账户或 AWS 组织共享资源。当您与 AWS 组织共享资源时，就是与该组织中所有级别的所有账户共享资源。然后，每个外部账户中的数据湖管理员必须向其账户中的主体授予共享资源的权限。

有关更多信息，请参阅[Lake Formation 中的跨账户数据共享](cross-account-permissions.md)和[授予对数据目录资源的权限](granting-catalog-permissions.md)。

**另请参见：**  
[访问和查看共享数据目录表和数据库](viewing-shared-resources.md)
[先决条件](cross-account-prereqs.md)

# 建筑物 AWS Glue Data Catalog 视图
<a name="working-with-views"></a>

在中 AWS Glue Data Catalog，*视图*是一个虚拟表，其中的内容由引用一个或多个表的 SQL 查询定义。您可以使用 EMR Serverless 或 5.0 版本的 Amazon Athena、Amazon Redshift 或 Apache Spark 的 SQL 编辑器创建最多引用 10 个表的数据目录视图。 AWS Glue 视图的基础参考表可以属于同一个数据库，也可以属于同一 AWS 账户数据目录中的不同数据库。

您可以引用标准 AWS Glue 表和开放表格式 (OTF) 的表，例如 [Apache Hudi](https://hudi.incubator.apache.org/)、Linux Foundation D [elta Lak](https://delta.io/) e 和 [Apache Iceberg](https://iceberg.apache.org/)，底层数据存储在注册的 Amazon S3 位置中。 AWS Lake Formation此外，您还可以根据与 Lake Formation 共享的 Amazon Redshift 数据共享中的联合表创建视图。

## 将数据目录视图与其它视图类型区分开来
<a name="diff-views"></a>

数据目录视图与 Apache Hive、Apache Spark 和 Amazon Athena 视图不同。数据目录视图是的本机功能 AWS Glue Data Catalog，也是由多方言定义者创建的视图。您可以使用 Athena 或 Amazon Redshift Spectrum 等支持的分析服务之一创建数据目录视图，并使用其它支持的分析服务访问相同的视图。另一方面，Apache Hive、Apache Spark 和 Athena 视图是在 Athena 和 Amazon Redshift 等每个分析服务中独立创建的，并且仅在该服务中可见和可访问。

## 什么是定义者视图？
<a name="definer-view"></a>

 定义者视图是一种 SQL 视图，根据创建视图的主体的权限进行操作。定义者角色拥有访问所引用表的必要权限，并运行定义视图的 SQL 语句。定义者创建视图并通过精细 AWS Lake Formation的访问控制与其他用户共享。

当用户查询定义者视图时，查询引擎会使用定义者角色的权限访问底层引用表。这种方法使用户能够与视图交互，而无需直接访问源表，从而增强了安全性并简化了数据访问管理。

要设置定义者视图，定义者 IAM 角色可以与基表位于同一个 AWS 账户中，也可以使用跨账户定义者角色位于不同的账户中。有关定义者角色所需权限的更多信息，请参阅[创建视图的先决条件](views-prereqs.md)。

## 多方言视图框架
<a name="multi-dialect"></a>

数据目录支持使用多种结构化查询语言（SQL）方言创建视图。SQL 是一种用于在关系数据库中存储和处理信息的语言，每个 AWS 分析引擎都使用自己的 SQL 变体或 SQL 方言。

您可以使用一种支持的分析查询引擎，采用一种 SQL 方言创建数据目录视图。随后，您可以在任何其它支持的分析引擎中使用不同 SQL 方言的 `ALTER VIEW` 语句更新视图。不过，每种方言都必须引用一组相同的表、列和数据类型。

您可以使用 `GetTable` API AWS CLI 和 AWS 控制台访问视图可用的多种方言。因此，数据目录视图是可见的，可在支持的不同分析引擎中进行查询。

通过定义可从多个引擎查询的通用视图架构和元数据对象，数据目录视图使您能够在整个数据湖中使用统一视图。

有关如何为每种方言解析架构的更多详细信息，请参阅 [API 参考链接]()。有关不同类型的匹配规则的更多详细信息，请参阅 [API 文档中相关章节的链接]()。

## 整合 Lake Formation 权限
<a name="lf-view-integ"></a>

您可以使用 AWS Lake Formation 集中管理用户 AWS Glue Data Catalog 视图的权限。您可以使用命名的资源方法或 LF-Tag 授予对数据目录视图的精细权限，并在 AWS 组织和组织单位之间 AWS 账户共享这些权限。您还可以 AWS 区域 使用资源链接共享和访问数据目录视图。这样，用户就可以在不复制数据来源并共享底层表的情况下提供数据访问权限。

数据目录视图的 `CREATE VIEW` DDL 语句可以引用开放表格式 (OTF) 的标准 AWS Glue 表和表，例如 Hudi、Delta Lake 和 Iceberg，其基础数据存储在 Lake Formation 注册的 Amazon S3 位置，以及与 Lake Formation 共享的 Amazon Redshift 数据共享中的联合表。表可以是任何文件格式，只要用于查询视图的引擎支持该格式即可。您也可以引用运行引擎的内置函数，但可能不允许引用其它特定于引擎的资源。有关更多详细信息，请参阅 [数据目录视图注意事项和限制](views-notes.md)

## 使用案例
<a name="views-use-cases"></a>

以下是数据目录视图的重要使用案例：
+ 创建和管理对单个视图架构的权限。这有助于避免对在多个引擎中创建的重复视图的权限存在不一致的风险。
+ 向用户授予对引用多个表的视图的权限，而无需直接授予对基础引用表的权限。
+ 通过在视图上应用 LF 标签，并向用户授予基于 LF 标签的权限，使用 LF 标签在表上实现行级筛选（LF 标签只级联到列级别）。

## 支持的视图 AWS 分析服务
<a name="views-supported-engines"></a>

以下 AWS 分析服务支持创建数据目录视图：
+ Amazon Redshift
+ Amazon Athena 版本 3
+ Apache Spark on EMR Serverless
+  5.0 AWS Glue 版本上的 Apache Spark

## 其他资源
<a name="views-addtional-resources"></a>

您可以在本指南中了解有关数据目录的更多信息，也可以使用以下资源：

以下视频演示了如何从 Athena 和 Amazon Redshift 创建视图并进行查询。

[![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/rFO2OoxVYxE?si=Z0qsyuvTp2ZJg-PL/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/rFO2OoxVYxE?si=Z0qsyuvTp2ZJg-PL)


**Topics**
+ [将数据目录视图与其它视图类型区分开来](#diff-views)
+ [什么是定义者视图？](#definer-view)
+ [多方言视图框架](#multi-dialect)
+ [整合 Lake Formation 权限](#lf-view-integ)
+ [使用案例](#views-use-cases)
+ [支持的视图 AWS 分析服务](#views-supported-engines)
+ [其他资源](#views-addtional-resources)
+ [创建视图的先决条件](views-prereqs.md)
+ [使用 DDL 语句创建数据目录视图](create-views.md)
+ [使用创建数据目录视图 AWS Glue APIs](views-api-usage.md)
+ [授予对数据目录视图的权限](grant-perms-views.md)
+ [实体化视图](materialized-views.md)

# 创建视图的先决条件
<a name="views-prereqs"></a>
+ 要在数据目录中创建视图，您必须向 Lake Formation 注册引用表的基础 Amazon S3 数据位置。有关向 Lake Formation 注册数据的详细信息，请参阅[向数据湖添加 Amazon S3 位置](register-data-lake.md)。
+ 只有 IAM 角色可以创建数据目录视图。其他 IAM 身份无法创建数据目录视图。
+ 定义视图的 IAM 角色必须具有以下权限：
  + 对所有引用表（包括所有列）使用 `Grantable` 选项的 Lake Formation `SELECT` 权限。
  + 在要创建视图的目标数据库上，需要具备 Lake Formation `CREATE_TABLE` 权限。
  + Lake Formation 和 AWS Glue 服务机构承担该角色的信任政策。

------
#### [ JSON ]

****  

    ```
    {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Sid": "DataCatalogViewDefinerAssumeRole1",
                "Effect": "Allow",
                "Principal": {
                   "Service": [
                        "glue.amazonaws.com",
                        "lakeformation.amazonaws.com"
                     ]
                },
                "Action": "sts:AssumeRole"
            }
        ]
    }
    ```

------
  + 目标： AWS Glue 和 Lake Formation 的PassRole 许可。

------
#### [ JSON ]

****  

    ```
    {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Sid": "DataCatalogViewDefinerPassRole1",
                "Action": [
                    "iam:PassRole"
                ],
                "Effect": "Allow",
                "Resource": "*",
                "Condition": {
                    "StringEquals": {
                        "iam:PassedToService": [ 
                            "glue.amazonaws.com",
                            "lakeformation.amazonaws.com"
                          ]
                    }
                }
            }
        ]
    }
    ```

------
  + AWS Glue 以及 Lake Formation 权限。

------
#### [ JSON ]

****  

    ```
    {
        "Version":"2012-10-17",		 	 	 
                     "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "Glue:GetDatabase",
                    "Glue:GetDatabases",
                    "Glue:CreateTable",
                    "Glue:GetTable",
                    "Glue:GetTables",
                    "Glue:BatchGetPartition",
                    "Glue:GetPartitions",
                    "Glue:GetPartition",
                    "Glue:GetTableVersion",
                    "Glue:GetTableVersions",
    				"Glue:PassConnection",
                    "lakeFormation:GetDataAccess"
                ],
                "Resource": "*"
            }
        ]   
    }
    ```

------
+ 不能在向 `IAMAllowedPrincipals` 组授予 `Super` 或 `ALL` 权限的数据库中创建视图。您可以撤销 `IAMAllowedPrincipals` 组对数据库的 `Super` 权限，请参阅[步骤 4：将数据存储切换到 Lake Formation 权限模型](upgrade-glue-lake-formation.md#upgrade-glue-lake-formation-step4)；也可以创建一个新数据库，在**新创建表的默认权限**下取消选中**仅对此数据库中的新表使用 IAM 访问控制**复选框。

# 使用 DDL 语句创建数据目录视图
<a name="create-views"></a>

你可以使用适用于 Athena 的 SQL 编辑器、Amazon Redshift 和使用/来创建 AWS Glue Data Catalog 视图。 AWS Glue APIs AWS CLI

要使用 SQL 编辑器创建数据目录视图，请选择 Athena 或 Redshift Spectrum，然后使用 `CREATE VIEW` 数据定义语言（DDL）语句创建视图。使用第一个引擎的方言创建视图后，可以使用第二个引擎的 `ALTER VIEW` DDL 语句添加其它方言。

在定义视图时，必须考虑以下几点：
+ **定义多方言视图** - 定义具有多种方言的视图时，不同方言的架构必须匹配。每种 SQL 方言的语法规范略有不同。在所有方言中，定义数据目录视图的查询语法应解析为完全相同的列列表，包括类型和名称。这些信息存储在视图的 `StorageDescriptor` 中。方言还必须引用数据目录中相同的底层表对象。

  要使用 DDL 向视图添加另一种方言，可以使用 `ALTER VIEW` 语句。如果 `ALTER VIEW` 语句试图更新视图定义，如修改视图的存储描述符或底层表，该语句就会出错，提示“输入与现有存储描述符不匹配”。您可以使用 SQL 转换操作来确保视图列类型匹配。
+ **更新视图** - 要更新视图，可以使用 `UpdateTable` API。如果在不匹配存储描述符或引用表的情况下更新视图，则可以提供 `FORCE` 标志（语法参见引擎 SQL 文档）。强制更新后，视图将采用强制的 `StorageDescriptor` 和引用表。任何进一步的 `ALTER VIEW` DDL 都应与修改后的值相匹配。已更新为具有不兼容方言的视图将处于“过时”状态。视图状态在 Lake Formation 控制台中可见，可使用 `GetTable` 操作查看。
+ **以字符串形式引用 varchar 列类型** – 无法将 Redshift Spectrum 的 varchar 列类型转换为字符串。如果在 Redshift Spectrum 中创建了具有 varchar 列类型的视图，而后续方言尝试将该字段作为字符串引用，则数据目录会将其作为字符串处理，而无需使用 `FORCE` 标志。
+ **复杂类型字段的处理** – Amazon Redshift 将所有复杂类型都视为 [SUPER 类型](https://docs.aws.amazon.com/redshift/latest/dg/r_SUPER_type.html)，而 Athena 则指定复杂类型。如果视图有一个 `SUPER` 类型字段，而另一个引擎将该列引用为特定的复杂类型，如 struct（`<street_address:struct<street_number:int, street_name:string, street_type:string>>`），那么数据目录会认为该字段是特定的复杂类型，并在存储描述符中使用该字段，而无需使用 `Force` 标志。

有关用于创建和管理数据目录视图的语法的更多信息，请参阅：
+ 《Amazon Athena 用户指南》中的[使用 AWS Glue Data Catalog 视图](https://docs.aws.amazon.com/athena/latest/ug/views-glue.html)。
+ 《Amazon Athena 用户指南》中的 [Glue Data Catalog 视图查询语法](https://docs.aws.amazon.com/athena/latest/ug/views-glue-ddl.html)。
+ 《Amazon Redshift 数据库开发人员指南》中的[在 AWS Glue Data Catalog中创建视图](https://docs.aws.amazon.com/redshift/latest/dg/data-catalog-views-overview.html)。

  有关与 Data Catalog 中的视图相关的 SQL 命令的更多信息，请参阅 [CREATE EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_VIEW.html)、[ALTER EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_EXTERNAL_VIEW.html) 和 [DROP EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_DROP_EXTERNAL_VIEW.html)。

创建数据目录视图后，该视图的详细信息可在 Lake Formation 控制台中查看。

1. 在 Lake Formation 控制台中选择“数据目录”下的**视图**。

1. 可用视图列表将显示在“视图”页面上。

1. 从列表中选择一个视图，详细信息页面将显示该视图的属性。

![\[下面的部分包含五个水平排列的选项卡，每个选项卡都包含相应的信息。\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/view-definition.png)


架构  
选择 `Column` 行，然后选择**编辑 LF 标签**，以更新标签值或分配新的 LF 标签。

SQL 定义  
您可以查看可用 SQL 定义的列表。选择**添加 SQL 定义**，然后选择要添加 SQL 定义的查询引擎。在 `Edit definition` 列下选择查询引擎（Athena 或 Amazon Redshift）以更新 SQL 定义。

LF 标签  
选择**编辑 LF 标签**以编辑标签的值或分配新标签。您可以使用 LF 标签来授予对视图的权限。

跨账户访问  
您可以看到与您共享数据目录视图的 AWS 账户组织和组织单位 (OUs) 的列表。

基础表  
用于创建视图的 SQL 定义中引用的基础表显示在此选项卡下。

# 使用创建数据目录视图 AWS Glue APIs
<a name="views-api-usage"></a>

您可以使用 AWS Glue [CreateTable](https://docs.aws.amazon.com/glue/latest/webapi/API_CreateTable.html)和[UpdateTable](https://docs.aws.amazon.com/glue/latest/webapi/API_UpdateTable.html) APIs 来创建和更新数据目录中的视图。`CreateTable` 和 `UpdateTable` 操作为 `ViewDefinition` 提供了新的 `TableInput` 结构，而 `SearchTables`、`GetTable`、`GetTables`、`GetTableVersion`、`GetTableVersions` 操作则在其视图输出语法中提供了 `ViewDefinition`。此外，`GetTable` API 输出中还有一个新的 `Status` 字段。

两个新 AWS Glue 连接可用于验证每个支持的查询引擎的 SQL 方言， Amazon Athena 以及 Amazon Redshift。

`CreateTable`与视图一起使用时 `UpdateTable` APIs ，和是异步的。当使用多个 SQL 方言调用 APIs 这些方言时，将使用每个引擎验证该调用，以确定该方言是否可以在该引擎上运行，以及每种方言的视图生成的架构是否匹配。该 AWS Glue 服务使用这些连接对分析引擎进行内部调用。这些调用模拟了在引擎上执行 `CREATE VIEW` 或 `ALTER VIEW` SQL DDL 时引擎的验证过程。

如果提供的 SQL 有效，且视图方言之间的架构匹配，则 AWS Glue API 会以原子方式提交结果。原子性允许在不停机的情况下创建或更改具有多种方言的视图。

**Topics**
+ [创建 AWS Glue 连接以验证状态](views-api-usage-connection.md)
+ [验证视图生成状态](views-api-usage-get-table.md)
+ [异步状态和操作](views-api-usage-async-states.md)
+ [查看异步操作期间的创建失败场景](views-api-usage-errors.md)

# 创建 AWS Glue 连接以验证状态
<a name="views-api-usage-connection"></a>

要使用或`UpdateTable`操作创建`CreateTable`或更新 AWS Glue Data Catalog 视图，必须创建一种用于验证的新 AWS Glue 连接类型，并将其提供给支持的分析引擎。要在 Athena 或 Amazon Redshift 中使用数据目录视图，需要这些连接。只能使用 AWS CLI AWS SDKs、或创建这些连接 AWS Glue APIs。您不能使用 AWS 管理控制台 来创建 AWS Glue 连接。

**注意**  
如果视图定义者角色和调用 `CreateTable` 或 `UpdateTable` 的角色不同，那么它们都需要在 IAM 策略声明中获得 `glue:PassConnection` 权限。

有关更多信息，请参阅[创建连接文档](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/glue/create-connection.html) AWS CLI 。

**AWS CLI 用于创建连接的命令**  
以下是用于创建连接的 AWS CLI 命令：

```
aws glue create-connection --region us-east-1 
--endpoint-url https://glue.us-east-1.amazonaws.com 
--cli-input-json file:///root/path/to/create-connection.json
```

**AWS CLI 输入 json**  
对于 Amazon Redshift：

```
{
    "CatalogId": "123456789012",
    "ConnectionInput": {
        "ConnectionType": "VIEW_VALIDATION_REDSHIFT",
        "Name": "views-preview-cluster-connection-2",
        "Description": "My first Amazon Redshift validation connection",
        "ConnectionProperties": {
            "DATABASE": "dev",
            "CLUSTER_IDENTIFIER": "glue-data-catalog-views-preview-cluster"
        }
    }
}
```

对于 Amazon Athena：

```
{
    "CatalogId": "123456789012",
    "ConnectionInput": {
        "ConnectionType": "VIEW_VALIDATION_ATHENA",
        "Name": "views-preview-cluster-connection-3",
        "Description": "My first Amazon Athena validation connection",
        "ConnectionProperties": {
            "WORKGROUP_NAME": "workgroup-name"
        }
    }
}
```

# 验证视图生成状态
<a name="views-api-usage-get-table"></a>

运行 `CreateTable` 或 `UpdateTable` 操作时，`GetTable` API 输出的 `Status` 字段会显示视图创建状态的详细信息。对于表尚不存在的`create`请求，在异步处理期间 AWS Glue 创建一个空表。调用 `GetTable` 时，可以传递一个可选的布尔标志 `IncludeStatusDetails`，用于显示请求的诊断信息。如果失败，此标志会显示一条错误消息，其中包含每种方言的个别状态。

视图创建、读取、更新和删除 (CRUD) 操作期间的错误可能发生在 AWS Glue/Lake Formation 服务中处理期间，或者在 Amazon Redshift 或 Athena 中进行视图 SQL 验证期间。当引擎在验证过程中发生错误时， AWS Glue 服务会提供引擎返回的错误信息。

**状态字段**  
以下是状态字段：
+ 状态：通用状态，与不同类型的作业无关：
  + QUEUED
  + 进行中
  + 成功
  + FAILED
+ Action – 表示对表调用了哪种操作，目前只有 `CREATE` 或 `UPDATE` 操作可用。

  在处理视图时，区分 `UPDATE` 和 `CREATE` 操作非常重要。操作类型决定了查询表的方式。

   `UPDATE` 操作表示表已存在于数据目录中。在这种情况下，您可以继续查询之前创建的表，不会出现任何问题。另一方面，`CREATE ` 操作表示该表以前从未成功创建过。如果将表标记为 `CREATE`，则尝试查询该表将失败，因为系统中还不存在该表。因此，在尝试查询表之前，必须确定操作类型（UPDATE 或 CREATE）。
+ RequestedBy — 请求异步更改的用户的 ARN。
+ UpdatedBy — 上次手动更改异步更改流程（例如请求取消或修改）的用户的 ARN。
+ Error – 此字段仅在状态为 **FAILED** 时出现。这是一条父级异常消息。每种方言可能存在不同的错误。
  + ErrorCode — 异常的类型。
  + ErrorMessage — 例外情况的简要描述。
+ RequestTime — 一个 ISO 8601 格式的日期字符串，表示启动更改的时间。
+ UpdateTime — 一个 ISO 8601 格式的日期字符串，表示上次更新状态的时间。

# 异步状态和操作
<a name="views-api-usage-async-states"></a>

当您运行 `glue:CreateTable` 请求时，将开始异步创建数据目录视图。在以下各节中，本文档描述了`glue:GetTable`响应中可用的 AWS Glue 视图。`Status`为简洁起见，本节略去完整响应。

```
{
    "Table": {
        ...
        "Status": {
            ...
            "Action": "CREATE",
            "State": "QUEUED",
        }
    }
}
```

上述两个属性均代表重要的诊断信息，这些信息指示异步操作的状态，以及可对此视图执行的操作。以下是这些属性的可能值。

1. `Status.Action`

   1. CREATE

   1. UPDATE

1. `Status.State`

   1. QUEUED

   1. 进行中

   1. 成功

   1. FAILED

还需要注意的是，数据目录视图上的某些更新不需要异步操作。例如，用户可能希望更新表的 `Description` 属性。由于这不需要任何异步操作，因此生成的表元数据将没有任何 `Status`，属性将为 `NULL`。

```
{
    "Table": {
        ...,
        "Description": "I changed this attribute!"
    }
}
```

接下来，本主题探讨上述状态信息如何影响可以对 AWS Glue 视图执行的操作。

**胶水：CreateTable**  
与任何 Glue 表的 `glue:CreateTable` 功能相比，该 API 没有任何变化。可以为任何尚未存在的表名调用 `CreateTable`。

**胶水：UpdateTable**  
无法对具有以下状态信息的 AWS Glue 视图执行此操作：

1. Action == CREATE and State == QUEUED

1. Action == CREATE and State == IN\$1PROGRESS

1. Action == CREATE and state == FAILED

1. Action == UPDATE and state == QUEUED

1. Action == UPDATE and state == IN\$1PROGRESS

总之，只有当数据目录视图满足以下要求时，才能更新该视图。

1. 首次成功创建。

   1. Action == CREATE and State == SUCCESS

1. 在异步更新操作后达到终端状态。

   1. Action == UPDATE and State == SUCCESS

   1. Action == UPDATE and State == FAILED

1. 由于同步更新，状态属性为 `NULL`。

**胶水：DeleteTable**  
与任何 AWS Glue 表的运行方式`glue:DeleteTable`相比，此操作没有任何变化。无论数据目录视图处于何种状态，都可以删除该视图。

**胶水：GetTable**  
与任何 AWS Glue 表的运行方式`glue:GetTable`相比，此操作没有任何变化。但是，在首次成功创建数据目录视图之前，不能从分析引擎中查询该视图。`Action == CREATE and State == SUCCESS`。首次成功创建数据目录视图后，无论其状态如何，都可以查询该视图。

**注意**  
本节中的所有信息都适用于读取的所有表`GetTable`， APIs 例如`GetTables`、和`SearchTables`。

# 查看异步操作期间的创建失败场景
<a name="views-api-usage-errors"></a>

以下示例代表了 `CreateTable` 或 `UpdateTable` 视图 API 调用可能导致的错误类型。由于 SQL 查询失败的错误范围相当大，因此这些错误并不详尽。

## 场景 1：Amazon Redshift 查询失败
<a name="views-api-usage-errors-scenario-1"></a>

为 Amazon Redshift 提供的查询包含一个拼写错误的表名，在验证过程中无法在数据目录中找到。由此产生的错误会显示在视图的 `GetTable` 响应的 `Status` 字段中。

`GetTable` 请求：

```
{
    "CatalogId": "123456789012",
    "DatabaseName": "async-view-test-db",
    "TableInput": {
        "Name": "view-athena-redshift-72",
        "Description": "This is an atomic operation",
        "StorageDescriptor": {
            "Columns": [
                { "Name": "col1", "Type": "int" },
                { "Name": "col2", "Type": "string" },
                { "Name": "col3", "Type": "double" }
            ]
        },
        "ViewDefinition": {
            "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
            "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ],
            "Representations": [
                {
                    "Dialect": "ATHENA",
                    "DialectVersion": "3",
                    "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
                    "ValidationConnection": "athena-connection"
                },
                {
                    "Dialect": "REDSHIFT",
                    "DialectVersion": "1.0",
                    "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";",
                    "ValidationConnection": "redshift-connection"
                }
            ]
        }
    }
}
```

`GetTable` 响应：

```
IncludeStatusDetails = FALSE
{
    "Table": {
        "Name": "view-athena-redshift-72",
        "DatabaseName": "async-view-test-db",
        "Description": "",
        "CreateTime": "2024-07-11T11:39:19-07:00",
        "UpdateTime": "2024-07-11T11:39:19-07:00",
        "Retention": 0,
        "ViewOriginalText": "",
        "ViewExpandedText": "",
        "TableType": "",
        "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
        "IsRegisteredWithLakeFormation": false,
        "CatalogId": "123456789012",
        "IsRowFilteringEnabled": false,
        "VersionId": "-1",
        "DatabaseId": "<databaseID>",
        "IsMultiDialectView": false,
        "Status": {
            "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "RequestTime": "2024-07-11T11:39:19-07:00",
            "UpdateTime": "2024-07-11T11:40:06-07:00",
            "Action": "CREATE",
            "State": "FAILED"
        }
    }
}

IncludeStatusDetails = TRUE
{
    "Table": {
        "Name": "view-athena-redshift-72",
        "DatabaseName": "async-view-test-db",
        "Description": "",
        "CreateTime": "2024-07-11T11:39:19-07:00",
        "UpdateTime": "2024-07-11T11:39:19-07:00",
        "Retention": 0,
        "ViewOriginalText": "",
        "ViewExpandedText": "",
        "TableType": "",
        "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
        "IsRegisteredWithLakeFormation": false,
        "CatalogId": "123456789012",
        "IsRowFilteringEnabled": false,
        "VersionId": "-1",
        "DatabaseId": "<databaseID>",
        "IsMultiDialectView": false,
        "Status": {
            "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "RequestTime": "2024-07-11T11:39:19-07:00",
            "UpdateTime": "2024-07-11T11:40:06-07:00",
            "Action": "CREATE",
            "State": "FAILED",
            "Error": {
                "ErrorCode": "QueryExecutionException",
                "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection | Query Execution Id: ddb711d3-2415-4aa9-b251-6a76ab4f41b1 | Timestamp: Thu Jul 11 18:39:37 UTC 2024]: Redshift returned error for the statement: ERROR: AwsClientException: EntityNotFoundException from glue - Entity Not Found"
            },
            "Details": {
                "RequestedChange": {
                    "Name": "view-athena-redshift-72",
                    "DatabaseName": "async-view-test-db",
                    "Description": "This is an atomic operation",
                    "Retention": 0,
                    "StorageDescriptor": {
                        "Columns": [
                            {
                                "Name": "col1",
                                "Type": "int"
                            },
                            {
                                "Name": "col2",
                                "Type": "string"
                            },
                            {
                                "Name": "col3",
                                "Type": "double"
                            }
                        ],
                        "Compressed": false,
                        "NumberOfBuckets": 0,
                        "SortColumns": [],
                        "StoredAsSubDirectories": false
                    },
                    "TableType": "VIRTUAL_VIEW",
                    "IsRegisteredWithLakeFormation": false,
                    "CatalogId": "123456789012",
                    "IsRowFilteringEnabled": false,
                    "VersionId": "-1",
                    "DatabaseId": "<databaseID>",
                    "ViewDefinition": {
                        "IsProtected": true,
                        "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
                        "SubObjects": [
                            "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1"
                        ],
                        "Representations": [
                            {
                                "Dialect": "ATHENA",
                                "DialectVersion": "3",
                                "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
                                "IsStale": false
                            },
                            {
                                "Dialect": "REDSHIFT",
                                "DialectVersion": "1.0",
                                "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";",
                                "IsStale": false
                            }
                        ]
                    },
                    "IsMultiDialectView": true
                },
                "ViewValidations": [
                    {
                        "Dialect": "ATHENA",
                        "DialectVersion": "3",
                        "ViewValidationText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
                        "UpdateTime": "2024-07-11T11:40:06-07:00",
                        "State": "SUCCESS"
                    },
                    {
                        "Dialect": "REDSHIFT",
                        "DialectVersion": "1.0",
                        "ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";",
                        "UpdateTime": "2024-07-11T11:39:37-07:00",
                        "State": "FAILED",
                        "Error": {
                            "ErrorCode": "QueryExecutionException",
                            "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection | Query Execution Id: ddb711d3-2415-4aa9-b251-6a76ab4f41b1 | Timestamp: Thu
 Jul 11 18:39:37 UTC 2024]: Redshift returned error for the statement: ERROR: AwsClientException: EntityNotFoundException from glue - Entity Not Found"
                        }
                    }
                ]
            }
        }
    }
}
```

## 场景 2：Amazon Redshift 连接无效
<a name="views-api-usage-errors-scenario-2"></a>

以下示例中的 Amazon Redshift 连接格式不正确，因为它引用了提供的终端节点中不存在的亚马逊 Redshift 数据库。 cluster/serverless Amazon Redshift 无法验证视图，来自 Amazon Redshift 的 `GetTable` 响应中的 `Status` 字段显示错误（`"State": "FAILED"`）。

`GetTable` 请求：

```
{
    "CatalogId": "123456789012",
    "DatabaseName": "async-view-test-db",
    "TableInput": {
        "Name": "view-athena-redshift-73",
        "Description": "This is an atomic operation",
        "StorageDescriptor": {
            "Columns": [
                { "Name": "col1", "Type": "int" },
                { "Name": "col2", "Type": "string" },
                { "Name": "col3", "Type": "double" }
            ]
        },
        "ViewDefinition": {
            "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
            "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ],
            "Representations": [
                {
                    "Dialect": "ATHENA",
                    "DialectVersion": "3",
                    "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
                    "ValidationConnection": "athena-connection"
                },
                {
                    "Dialect": "REDSHIFT",
                    "DialectVersion": "1.0",
                    "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
                    "ValidationConnection": "redshift-connection-malformed"
                }
            ]
        }
    }
}
```

`GetTable` 响应：

```
IncludeStatusDetails = FALSE
{
    "Table": {
        "Name": "view-athena-redshift-73",
        "DatabaseName": "async-view-test-db",
        "Description": "",
        "CreateTime": "2024-07-11T11:43:27-07:00",
        "UpdateTime": "2024-07-11T11:43:27-07:00",
        "Retention": 0,
        "ViewOriginalText": "",
        "ViewExpandedText": "",
        "TableType": "",
        "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
        "IsRegisteredWithLakeFormation": false,
        "CatalogId": "123456789012",
        "IsRowFilteringEnabled": false,
        "VersionId": "-1",
        "DatabaseId": "<databaseID>",
        "IsMultiDialectView": false,
        "Status": {
            "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "RequestTime": "2024-07-11T11:43:27-07:00",
            "UpdateTime": "2024-07-11T11:43:40-07:00",
            "Action": "CREATE",
            "State": "FAILED"
        }
    }
}

IncludeStatusDetails = TRUE
{
    "Table": {
        "Name": "view-athena-redshift-73",
        "DatabaseName": "async-view-test-db",
        "Description": "",
        "CreateTime": "2024-07-11T11:43:27-07:00",
        "UpdateTime": "2024-07-11T11:43:27-07:00",
        "Retention": 0,
        "ViewOriginalText": "",
        "ViewExpandedText": "",
        "TableType": "",
        "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
        "IsRegisteredWithLakeFormation": false,
        "CatalogId": "123456789012",
        "IsRowFilteringEnabled": false,
        "VersionId": "-1",
        "DatabaseId": "<databaseID>",
        "IsMultiDialectView": false,
        "Status": {
            "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "RequestTime": "2024-07-11T11:43:27-07:00",
            "UpdateTime": "2024-07-11T11:43:40-07:00",
            "Action": "CREATE",
            "State": "FAILED",
            "Error": {
                "ErrorCode": "QueryExecutionException",
                "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection-malformed | Query Execution Id: 69bfafd4-3d51-4cb0-9320-7ce5404b1809 | Timestamp: Thu Jul 11 18:43:38 UTC 2024]: Redshift returned error for the statement: FATAL: database \"devooo\" does not exist"
            },
            "Details": {
                "RequestedChange": {
                    "Name": "view-athena-redshift-73",
                    "DatabaseName": "async-view-test-db",
                    "Description": "This is an atomic operation",
                    "Retention": 0,
                    "StorageDescriptor": {
                        "Columns": [
                            {
                                "Name": "col1",
                                "Type": "int"
                            },
                            {
                                "Name": "col2",
                                "Type": "string"
                            },
                            {
                                "Name": "col3",
                                "Type": "double"
                            }
                        ],
                        "Compressed": false,
                        "NumberOfBuckets": 0,
                        "SortColumns": [],
                        "StoredAsSubDirectories": false
                    },
                    "TableType": "VIRTUAL_VIEW",
                    "IsRegisteredWithLakeFormation": false,
                    "CatalogId": "123456789012",
                    "IsRowFilteringEnabled": false,
                    "VersionId": "-1",
                    "DatabaseId": "<databaseID>",
                    "ViewDefinition": {
                        "IsProtected": true,
                        "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
                        "SubObjects": [
                            "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1"
                        ],
                        "Representations": [
                            {
                                "Dialect": "ATHENA",
                                "DialectVersion": "3",
                                "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
                                "IsStale": false
                            },
                            {
                                "Dialect": "REDSHIFT",
                                "DialectVersion": "1.0",
                                "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
                                "IsStale": false
                            }
                        ]
                    },
                    "IsMultiDialectView": true
                },
                "ViewValidations": [
                    {
                        "Dialect": "ATHENA",
                        "DialectVersion": "3",
                        "ViewValidationText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"",
                        "UpdateTime": "2024-07-11T11:43:40-07:00",
                        "State": "SUCCESS"
                    },
                    {
                        "Dialect": "REDSHIFT",
                        "DialectVersion": "1.0",
                        "ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
                        "UpdateTime": "2024-07-11T11:43:38-07:00",
                        "State": "FAILED",
                        "Error": {
                            "ErrorCode": "QueryExecutionException",
                            "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection-malformed | Query Execution Id: 69bfafd4-3d51-4cb0-9320-7ce5404b1809 | Time
stamp: Thu Jul 11 18:43:38 UTC 2024]: Redshift returned error for the statement: FATAL: database \"devooo\" does not exist"
                        }
                    }
                ]
            }
        }
    }
}
```

## 场景 3：Athena 查询失败
<a name="views-api-usage-errors-scenario-3"></a>

此处 Athena 的 SQL 无效，因为查询拼错了数据库名称。Athena 查询验证会捕捉到这一点，由此产生的错误会通过 `GetTable` 调用中的 `Status` 对象显示出来。

`GetTable` 请求：

```
{
    "CatalogId": "123456789012",
    "DatabaseName": "async-view-test-db",
    "TableInput": {
        "Name": "view-athena-redshift-70",
        "Description": "This is an atomic operation",
        "StorageDescriptor": {
            "Columns": [
                { "Name": "col1", "Type": "int" },
                { "Name": "col2", "Type": "string" },
                { "Name": "col3", "Type": "double" }
            ]
        },
        "ViewDefinition": {
            "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
            "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ],
            "Representations": [
                {
                    "Dialect": "ATHENA",
                    "DialectVersion": "3",
                    "ViewOriginalText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"",
                    "ValidationConnection": "athena-connection"
                },
                {
                    "Dialect": "REDSHIFT",
                    "DialectVersion": "1.0",
                    "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
                    "ValidationConnection": "redshift-connection"
                }
            ]
        }
    }
}
```

`GetTable` 响应：

```
IncludeStatusDetails = FALSE
{
    "Table": {
        "Name": "view-athena-redshift-70",
        "DatabaseName": "async-view-test-db",
        "Description": "",
        "CreateTime": "2024-07-11T11:09:53-07:00",
        "UpdateTime": "2024-07-11T11:09:53-07:00",
        "Retention": 0,
        "ViewOriginalText": "",
        "ViewExpandedText": "",
        "TableType": "",
        "CreatedBy": "arn:aws:iam::123456789012:user/",
        "IsRegisteredWithLakeFormation": false,
        "CatalogId": "123456789012",
        "IsRowFilteringEnabled": false,
        "VersionId": "-1",
        "DatabaseId": "<databaseID>",
        "IsMultiDialectView": false,
        "Status": {
            "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "RequestTime": "2024-07-11T11:09:54-07:00",
            "UpdateTime": "2024-07-11T11:10:41-07:00",
            "Action": "CREATE",
            "State": "FAILED",
        }
    }
}

IncludeStatusDetails = TRUE
{
    "Table": {
        "Name": "view-athena-redshift-70",
        "DatabaseName": "async-view-test-db",
        "Description": "",
        "CreateTime": "2024-07-11T11:09:53-07:00",
        "UpdateTime": "2024-07-11T11:09:53-07:00",
        "Retention": 0,
        "ViewOriginalText": "",
        "ViewExpandedText": "",
        "TableType": "",
        "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
        "IsRegisteredWithLakeFormation": false,
        "CatalogId": "123456789012",
        "IsRowFilteringEnabled": false,
        "VersionId": "-1",
        "DatabaseId": "<databaseID>",
        "IsMultiDialectView": false,
        "Status": {
            "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "RequestTime": "2024-07-11T11:09:54-07:00",
            "UpdateTime": "2024-07-11T11:10:41-07:00",
            "Action": "CREATE",
            "State": "FAILED",
            "Error": {
                "ErrorCode": "QueryExecutionException",
                "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: athena-connection | Query Execution Id: d9bb1e6d-ce26-4b35-8276-8a199af966aa | Timestamp: Thu Jul 11 18:10:
41 UTC 2024]: Athena validation FAILED: {ErrorCategory: 2,ErrorType: 1301,Retryable: false,ErrorMessage: line 1:118: Schema 'gdc--view-playground-db' does not exist}"
            },
            "Details": {
                "RequestedChange": {
                    "Name": "view-athena-redshift-70",
                    "DatabaseName": "async-view-test-db",
                    "Description": "This is an atomic operation",
                    "Retention": 0,
                    "StorageDescriptor": {
                        "Columns": [
                            {
                                "Name": "col1",
                                "Type": "int"
                            },
                            {
                                "Name": "col2",
                                "Type": "string"
                            },
                            {
                                "Name": "col3",
                                "Type": "double"
                            }
                        ],
                        "Compressed": false,
                        "NumberOfBuckets": 0,
                        "SortColumns": [],
                        "StoredAsSubDirectories": false
                    },
                    "TableType": "VIRTUAL_VIEW",
                    "IsRegisteredWithLakeFormation": false,
                    "CatalogId": "123456789012",
                    "IsRowFilteringEnabled": false,
                    "VersionId": "-1",
                    "DatabaseId": "<databaseID>",
                    "ViewDefinition": {
                        "IsProtected": true,
                        "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
                        "SubObjects": [
                            "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1"
                        ],
                        "Representations": [
                            {
                                "Dialect": "ATHENA",
                                "DialectVersion": "3",
                                "ViewOriginalText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"",
                                "IsStale": false
                            },
                            {
                                "Dialect": "REDSHIFT",
                                "DialectVersion": "1.0",
                                "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
                                "IsStale": false
                            }
                        ]
                    },
                    "IsMultiDialectView": true
                },
                "ViewValidations": [
                    {
                        "Dialect": "ATHENA",
                        "DialectVersion": "3",
                        "ViewValidationText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"",
                        "UpdateTime": "2024-07-11T11:10:41-07:00",
                        "State": "FAILED",
                        "Error": {
                            "ErrorCode": "QueryExecutionException",
                            "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: athena-connection | Query Execution Id: d9bb1e6d-ce26-4b35-8276-8a199af966aa | Timestamp: Thu J
ul 11 18:10:41 UTC 2024]: Athena validation FAILED: {ErrorCategory: 2,ErrorType: 1301,Retryable: false,ErrorMessage: line 1:118: Schema 'gdc--view-playground-db' does not exist}"
                        }
                    },
                    {
                        "Dialect": "REDSHIFT",
                        "DialectVersion": "1.0",
                        "ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";",
                        "UpdateTime": "2024-07-11T11:10:41-07:00",
                        "State": "SUCCESS"
                    }
                ]
            }
        }
    }
}
```

## 场景 4：存储描述符不匹配
<a name="views-api-usage-errors-scenario-4"></a>

为 Athena 方言提供的 SQL 选择 `col1` 和 `col2`，而为 Redshift 提供的 SQL 只选择 `col1`。这会导致存储描述符不匹配错误。

`GetTable` 请求：

```
{
    "CatalogId": "123456789012",
    "DatabaseName": "async-view-test-db",
    "TableInput": {
        "Name": "view-athena-redshift-71",
        "Description": "This is an atomic operation",
        "StorageDescriptor": {
            "Columns": [
                { "Name": "col1", "Type": "int" },
                { "Name": "col2", "Type": "string" },
                { "Name": "col3", "Type": "double" }
            ]
        },
        "ViewDefinition": {
            "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
            "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ],
            "Representations": [
                {
                    "Dialect": "ATHENA",
                    "DialectVersion": "3",
                    "ViewOriginalText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"",
                    "ValidationConnection": "athena-connection"
                },
                {
                    "Dialect": "REDSHIFT",
                    "DialectVersion": "1.0",
                    "ViewOriginalText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";",
                    "ValidationConnection": "redshift-connection"
                }
            ]
        }
    }
}
```

`GetTable` 响应：

```
IncludeStatusDetails = FALSE

{
    "Table": {
        "Name": "view-athena-redshift-71",
        "DatabaseName": "async-view-test-db",
        "Description": "",
        "CreateTime": "2024-07-11T11:22:02-07:00",
        "UpdateTime": "2024-07-11T11:22:02-07:00",
        "Retention": 0,
        "ViewOriginalText": "",
        "ViewExpandedText": "",
        "TableType": "",
        "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
        "IsRegisteredWithLakeFormation": false,
        "CatalogId": "123456789012",
        "IsRowFilteringEnabled": false,
        "VersionId": "-1",
        "DatabaseId": "<databaseID>",
        "IsMultiDialectView": false,
        "Status": {
            "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "RequestTime": "2024-07-11T11:22:02-07:00",
            "UpdateTime": "2024-07-11T11:23:19-07:00",
            "Action": "CREATE",
            "State": "FAILED"
        }
    }
}

IncludeStatusDetails = TRUE

{
    "Table": {
        "Name": "view-athena-redshift-71",
        "DatabaseName": "async-view-test-db",
        "Description": "",
        "CreateTime": "2024-07-11T11:22:02-07:00",
        "UpdateTime": "2024-07-11T11:22:02-07:00",
        "Retention": 0,
        "ViewOriginalText": "",
        "ViewExpandedText": "",
        "TableType": "",
        "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse",
        "IsRegisteredWithLakeFormation": false,
        "CatalogId": "123456789012",
        "IsRowFilteringEnabled": false,
        "VersionId": "-1",
        "DatabaseId": "<databaseID>",
        "IsMultiDialectView": false,
        "Status": {
            "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse",
            "RequestTime": "2024-07-11T11:22:02-07:00",
            "UpdateTime": "2024-07-11T11:23:19-07:00",
            "Action": "CREATE",
            "State": "FAILED",
            "Error": {
                "ErrorCode": "InvalidInputException",
                "ErrorMessage": "Engine and existing storage descriptor mismatch"
            },
            "Details": {
                "RequestedChange": {
                    "Name": "view-athena-redshift-71",
                    "DatabaseName": "async-view-test-db",
                    "Description": "This is an atomic operation",
                    "Retention": 0,
                    "StorageDescriptor": {
                        "Columns": [
                            {
                                "Name": "col1",
                                "Type": "int"
                            },
                            {
                                "Name": "col2",
                                "Type": "string"
                            },
                            {
                                "Name": "col3",
                                "Type": "double"
                            }
                        ],
                        "Compressed": false,
                        "NumberOfBuckets": 0,
                        "SortColumns": [],
                        "StoredAsSubDirectories": false
                    },
                    "TableType": "VIRTUAL_VIEW",
                    "IsRegisteredWithLakeFormation": false,
                    "CatalogId": "123456789012",
                    "IsRowFilteringEnabled": false,
                    "VersionId": "-1",
                    "DatabaseId": "<databaseID>",
                    "ViewDefinition": {
                        "IsProtected": true,
                        "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner",
                        "SubObjects": [
                            "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1"
                        ],
                        "Representations": [
                            {
                                "Dialect": "ATHENA",
                                "DialectVersion": "3",
                                "ViewOriginalText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"",
                                "IsStale": false
                            },
                            {
                                "Dialect": "REDSHIFT",
                                "DialectVersion": "1.0",
                                "ViewOriginalText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";",
                                "IsStale": false
                            }
                        ]
                    },
                    "IsMultiDialectView": true
                },
                "ViewValidations": [
                    {
                        "Dialect": "ATHENA",
                        "DialectVersion": "3",
                        "ViewValidationText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"",
                        "UpdateTime": "2024-07-11T11:23:19-07:00",
                        "State": "FAILED",
                        "Error": {
                            "ErrorCode": "InvalidInputException",
                            "ErrorMessage": "Engine and existing storage descriptor mismatch"
                        }
                    },
                    {
                        "Dialect": "REDSHIFT",
                        "DialectVersion": "1.0",
                        "ViewValidationText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";",
                        "UpdateTime": "2024-07-11T11:22:49-07:00",
                        "State": "FAILED",
                        "Error": {
                            "ErrorCode": "InvalidInputException",
                            "ErrorMessage": "Engine and existing storage descriptor mismatch"
                        }
                    }
                ]
            }
        }
    }
}
```

# 授予对数据目录视图的权限
<a name="grant-perms-views"></a>

 在中创建视图后 AWS Glue Data Catalog，您可以向各组织和组织单位的委托人授予视图的数据湖权限。 AWS 账户您可以使用 LF 标签或命名资源方法授予权限。有关标记资源的更多信息，请参阅 [Lake Formation 基于标签的访问控制](tag-based-access-control.md)。有关直接授予视图权限的更多信息，请参阅[使用命名资源方法授予对视图的权限](granting-view-permissions.md)。

# 实体化视图
<a name="materialized-views"></a>

**Topics**
+ [将实例化视图与其他视图类型区分开来](#materialized-views-differentiating)
+ [使用案例](#materialized-views-use-cases)
+ [重要概念](#materialized-views-key-concepts)
+ [实体化视图的权限](#materialized-views-permissions)
+ [创建和管理物化视图](#materialized-views-creating-managing)
+ [存储和数据访问](#materialized-views-storage-access)
+ [与 AWS Lake Formation 权限集成](#materialized-views-lake-formation)
+ [监控和调试](#materialized-views-monitoring-debugging)
+ [管理刷新作业](#materialized-views-managing-refresh-jobs)
+ [监控和排查](#materialized-views-monitoring-troubleshooting)
+ [注意事项和限制](#materialized-views-considerations-limitations)

在 AWS Glue 数据目录中，物化视图是一个托管表，它以 Apache Iceberg 格式存储预先计算的 SQL 查询结果。与每次访问时都执行查询的标准数据目录视图不同，物化视图会物理存储查询结果，并在基础源表更改时对其进行更新。你可以在亚马逊 Athena、亚马逊 EMR 或中使用 Apache Spark 3.5.6\$1 版本创建物化视图。 AWS Glue

物化视图引用了在 AWS Glue 数据目录中注册的 Apache Iceberg 表，预先计算的数据以 Apache Iceberg 表的形式存储在 Amazon S3 表存储桶或 Amazon S3 通用存储桶中，因此可以从包括亚马逊雅典娜、Amazon Redshift 和第三方冰山兼容引擎在内的多个查询引擎进行访问。

## 将实例化视图与其他视图类型区分开来
<a name="materialized-views-differentiating"></a>

物化视图在根本上不同于 AWS Glue 数据目录视图、Apache Spark 视图和 Amazon Athena 视图。虽然数据目录视图是虚拟表，每次访问时都会执行 SQL 查询定义，但物化视图会物理存储预先计算的查询结果。这消除了冗余计算，并显著提高了经常访问的复杂转换的查询性能。

物化视图还不同于使用 AWS Glue ETL 或自定义 Spark 作业构建的传统数据转换管道。您可以使用标准 SQL 语法定义物化视图，而不是编写自定义代码来处理变更检测、增量更新和工作流程编排。 AWS Glue 数据目录使用完全托管的计算基础架构自动监控源表、检测更改并刷新实体化视图。

## 使用案例
<a name="materialized-views-use-cases"></a>

以下是物化视图的重要用例：
+ **加速复杂的分析查询**-创建预先计算昂贵的联接、聚合和窗口函数的物化视图。Spark 引擎会自动重写后续查询以使用预先计算的结果，从而减少查询延迟和计算成本。
+ **简化数据转换管道** — 将处理变更检测、增量更新和工作流程编排的复杂 ETL 作业替换为基于 SQL 的简单物化视图定义。 AWS Glue 数据目录自动管理所有操作的复杂性。
+ 通过@@ **受管控的数据访问实现自助式分析** — 创建精选的物化视图，将原始数据转换为业务就绪型数据集。允许用户在不暴露底层源表的情况下访问物化视图，从而简化安全管理，同时支持自助分析。
+ **优化机器学习的特征工程**-定义实现机器学习模型特征转换的物化视图。自动刷新功能可确保功能存储在源数据演变时保持最新状态，而增量刷新可最大限度地降低计算成本。
+ **实现高效的数据共享**-创建物化视图，筛选和转换特定使用者的数据。使用跨账户和区域共享实体化视图 AWS Lake Formation，无需重复数据，同时保持集中化治理。

## 重要概念
<a name="materialized-views-key-concepts"></a>

### 自动刷新
<a name="materialized-views-automatic-refresh"></a>

自动刷新是一种持续监视源表并根据您定义的计划更新实体化视图的功能。创建物化视图时，您可以使用基于时间的调度来指定刷新频率，间隔频率可达一小时。 AWS Glue 数据目录使用托管 Spark 计算基础架构在后台执行刷新操作，透明地处理变更检测和增量更新的各个方面。

当源数据在刷新间隔之间发生变化时，实例化视图会暂时失效。在下一次定时刷新完成之前，直接访问物化视图的查询可能会返回过时的结果。对于需要立即访问最新数据的场景，可以使用 `REFRESH MATERIALIZED VIEW` SQL 命令执行手动刷新。

### 增量刷新
<a name="materialized-views-incremental-refresh"></a>

增量刷新是一种优化技术，它仅处理自上次刷新以来源表中已更改的数据，而不是重新计算整个实例化视图。 AWS Glue 数据目录利用 Apache Iceberg 的元数据层来有效地跟踪源表中的变化，并确定物化视图的哪些部分需要更新。

与完全刷新操作相比，这种方法可以显著降低计算成本和刷新持续时间，特别是对于大型数据集，在刷新周期之间，只有一小部分数据会发生变化。增量刷新机制会自动运行；您无需编写自定义逻辑即可检测或处理更改的数据。

### 自动查询重写
<a name="materialized-views-automatic-query-rewrite"></a>

自动查询重写是 Amazon Athena、Amazon EMR 和 Spark 引擎中提供的查询优化功能。 AWS Glue当您对基表执行查询时，Spark 优化器会分析您的查询计划并自动确定可用的物化视图能否更有效地满足查询。如果存在合适的实例化视图，则优化器会透明地重写查询，以使用预先计算的结果，而不是处理基表。

这种优化无需对您的应用程序代码或查询语句进行任何更改。Spark 优化器可确保自动查询重写仅在物化视图为最新视图并且可以生成准确结果时才适用。如果物化视图已过时或与查询要求不完全匹配，则优化程序会对基表执行原始查询计划，将正确性置于性能之上。

### 视图定义者角色
<a name="materialized-views-view-definer-role"></a>

物化视图基于创建该视图的 IAM 角色（称为视图定义者角色）的权限进行操作。定义者角色必须对实例化视图定义中引用的所有基表具有读取权限，并且必须对目标数据库具有创建表权限。当 AWS Glue 数据目录刷新实例化视图时，它将扮演定义者的角色来访问源表并写入更新的结果。

使用此安全模型，您可以向用户授予对实例化视图的访问权限，而无需授予他们对基础源表的直接权限。如果视图定义者角色失去对任何基表的访问权限，则在恢复权限之前，后续的刷新操作将失败。

## 实体化视图的权限
<a name="materialized-views-permissions"></a>

要创建和管理物化视图，必须配置 AWS Lake Formation 权限。创建实体化视图的 IAM 角色（定义者角色）需要对源表和目标数据库的特定权限。

### 定义者角色所需的权限
<a name="materialized-views-required-permissions-definer-role"></a>

定义者角色必须具有以下 Lake Formation 权限：
+ 在源表上 – 不带行、列或单元格筛选条件的 SELECT 或 ALL 权限
+ 在目标数据库上 – CREATE\$1TABLE 权限
+ 在 AWS Glue 数据目录上 — GetTable 以及 CreateTable API 权限

创建实体化视图时，定义者角色的 ARN 存储在视图定义中。执行自动刷新操作时， AWS Glue 数据目录将扮演此角色。如果定义者角色失去对源表的访问权限，则在恢复权限之前，刷新操作将失败。

### AWS Glue 任务的 IAM 权限
<a name="materialized-views-iam-permissions-glue-jobs"></a>

您的 AWS Glue 任务的 IAM 角色需要以下权限：

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "glue:GetCatalog",
                "glue:GetCatalogs",
                "glue:GetTable",
                "glue:GetTables",
                "glue:CreateTable",
                "glue:UpdateTable",
                "glue:DeleteTable",
                "glue:GetDatabase",
                "glue:GetDatabases",
                "cloudwatch:PutMetricData"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:*:*:*:/aws-glue/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "lakeformation:GetDataAccess"
            ],
            "Resource": "*"
        }
    ]
}
```

用于物化视图自动刷新的角色必须对该角色具有 iam: PassRole 权限。

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": [
        "arn:aws:iam::111122223333:role/materialized-view-role-name"
      ]
    }
  ]
}
```

要让 Glue 自动刷新实体化视图，角色还必须具有以下信任策略，进而确保服务能够担任该角色。

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "glue.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

如果实体化视图存储在 S3 表类数据存储服务存储桶中，则还需要为角色添加以下权限。

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3tables:PutTableMaintenanceConfiguration"
      ],
      "Resource": "arn:aws:s3tables:*:123456789012:*"
    }
  ]
}
```

### 授予对实体化视图的访问权限
<a name="materialized-views-granting-access"></a>

要向其他用户授予查询物化视图的访问权限，请使用授予 AWS Lake Formation 对物化视图表的 SELECT 权限。用户无需直接访问基础源表即可查询实体化视图。

有关配置 Lake Formation 权限的详细信息，请参阅 AWS Lake Formation 开发人员指南中的授予和撤消数据目录资源的权限。

## 创建和管理物化视图
<a name="materialized-views-creating-managing"></a>

您可以在 Spark 引擎中使用 `CREATE MATERIALIZED VIEW` SQL 语句创建实例化视图。视图定义指定了定义转换逻辑、目标数据库和表名以及可选刷新配置的 SQL 查询。您可以定义复杂的转换，包括聚合、跨多个表的联接、筛选器和窗口函数。

```
CREATE MATERIALIZED VIEW sales_summary
AS
SELECT 
    region,
    product_category,
    SUM(sales_amount) as total_sales,
    COUNT(DISTINCT customer_id) as unique_customers
FROM sales_transactions
WHERE transaction_date >= current_date - interval '90' day
GROUP BY region, product_category;
```

要配置自动刷新，请在视图定义中包括刷新计划：

```
CREATE MATERIALIZED VIEW sales_summary
SCHEDULE REFRESH EVERY 1 HOUR
AS
SELECT region, product_category, SUM(sales_amount) as total_sales
FROM sales_transactions
GROUP BY region, product_category;
```

您可以使用以下`REFRESH MATERIALIZED VIEW`命令随时手动刷新实例化视图：

```
REFRESH MATERIALIZED VIEW sales_summary;
```

要修改现有实例化视图的刷新计划，请使用以下`ALTER MATERIALIZED VIEW`语句：

```
ALTER MATERIALIZED VIEW sales_summary
ADD SCHEDULE REFRESH EVERY 2 HOURS;
```

### 嵌套实体化视图
<a name="materialized-views-nested"></a>

您可以创建引用其他实例化视图作为基表的实例化视图，从而实现多阶段数据转换。创建嵌套实例化视图时， AWS Glue 数据目录会跟踪依赖关系并自动通过物化视图层次结构传播更新。当基础物化视图刷新时，所有依赖该视图的下游物化视图都会相应更新。

此功能允许您将复杂的转换分解为逻辑阶段，从而提高可维护性，并允许根据数据新鲜度要求选择性刷新转换层。

## 存储和数据访问
<a name="materialized-views-storage-access"></a>

物化视图将预先计算的结果存储为 Apache Iceberg 表存储在 S3 表存储桶中，或者将您的账户中的通用 S3 存储桶存储为通用的 S3 存储桶。 AWS AWS Glue 数据目录通过 S3 表的自动优化功能管理 Iceberg 表维护的各个方面，包括压缩和快照保留。

由于物化视图存储为 Iceberg 表，因此您可以直接从任何兼容 Iceberg 的引擎中读取它们，包括亚马逊 Athena、Amazon Redshift 和第三方分析平台。这种多引擎可访问性可确保预先计算的数据在整个分析生态系统中保持可访问性，而无需重复数据或格式转换。

## 与 AWS Lake Formation 权限集成
<a name="materialized-views-lake-formation"></a>

您可以使用 AWS Lake Formation 来管理物化视图的细粒度权限。视图创建者自动成为物化视图的所有者，并且可以使用的命名资源方法或 LF-Tag AWS Lake Formation s 向其他用户或角色授予权限。

当您授予用户对物化视图的`SELECT`权限时，他们无需访问基础源表即可查询预先计算的结果。此安全模型简化了数据访问管理，使您能够实施最小权限原则，仅向用户提供他们所需的特定数据转换的访问权限。

您可以使用跨 AWS 账户共享功能在账户、 AWS 组织和组织单位之间共享实体化视图。 AWS Lake Formation您还可以使用资源链接访问跨 AWS 区域的物化视图，从而通过分布式数据访问实现集中式数据治理。

## 监控和调试
<a name="materialized-views-monitoring-debugging"></a>

 AWS Glue 数据目录将所有实体化视图刷新操作和相关指标发布到 Amazon CloudWatch。您可以通过 CloudWatch 指标监控刷新开始时间、结束时间、持续时间、处理的数据量和刷新状态。刷新操作失败时，将在 CloudWatch 日志中捕获错误消息和诊断信息。

您可以设置 CloudWatch 警报，以便在刷新任务超过预期持续时间或重复失败时收到通知。 AWS Glue 数据目录还会将成功和失败的刷新运行的更改事件发布到，从而使您能够将实体化视图操作集成到更广泛的工作流程自动化中。

要检查实例化视图的当前状态，请使用 `DESCRIBE MATERIALIZED VIEW` SQL 命令，该命令会返回包括失效状态、上次刷新时间戳和刷新计划配置在内的元数据。

## 管理刷新作业
<a name="materialized-views-managing-refresh-jobs"></a>

### 开始手动刷新
<a name="materialized-views-manual-refresh"></a>

在计划间隔之外触发立即刷新。

必需权限：用于进行 API 调用的 AWS 凭据必须具有物化视图的`glue:GetTable`权限。

对于 S3 表目录：

```
aws glue start-materialized-view-refresh-task-run \
    --catalog-id <ACCOUNT_ID>:s3tablescatalog/<CATALOG_NAME> \
    --database-name <DATABASE_NAME> \
    --table-name <MV_TABLE_NAME>
```

对于根目录：

```
aws glue start-materialized-view-refresh-task-run \
    --catalog-id <ACCOUNT_ID> \
    --database-name <DATABASE_NAME> \
    --table-name <MV_TABLE_NAME>
```

### 正在检查刷新状态
<a name="materialized-views-checking-refresh-status"></a>

获取特定刷新任务的状态：

```
aws glue get-materialized-view-refresh-task-run \
    --catalog-id <CATALOG_ID> \
    --materialized-view-refresh-task-run-id <TASK_RUN_ID>
```

### 房源刷新历史记录
<a name="materialized-views-listing-refresh-history"></a>

查看实体化视图的所有刷新作业：

```
aws glue list-materialized-view-refresh-task-runs \
    --catalog-id <CATALOG_ID> \
    --database-name <DATABASE_NAME> \
    --table-name <MV_TABLE_NAME>
```

**注意**  
用`<ACCOUNT_ID>:s3tablescatalog/<CATALOG_NAME>`于 S3 表或`<ACCOUNT_ID>`根目录。

### 停止正在运行的刷新
<a name="materialized-views-stopping-refresh"></a>

取消正在进行的刷新作业：

```
aws glue stop-materialized-view-refresh-task-run \
    --catalog-id <CATALOG_ID> \
    --database-name <DATABASE_NAME> \
    --table-name <MV_TABLE_NAME>
```

## 监控和排查
<a name="materialized-views-monitoring-troubleshooting"></a>

有三种方法可以监视实体化视图刷新作业：

### CloudWatch 指标
<a name="materialized-views-cloudwatch-metrics"></a>

在以下位置查看所有实体化视图刷新作业的汇总指标： CloudWatch

可用指标：
+ AWS/Glue 带有维度的命名空间：
  + CatalogId: 您的目录标识符
  + DatabaseName: 包含物化视图的数据库
  + TableName: 物化视图名称
  + TaskType: 设置为 “MaterializedViewRefresh”

在控制台中查看：

1. 导航到 CloudWatch 控制台 → 指标

1. 选择 AWS/Glue 命名空间

1. 按维度筛选： CatalogId、 DatabaseName、 TableName、 TaskType

1. 查看任务成功、失败和持续时间的指标

 CloudWatch 指标查询示例：

```
{AWS/Glue,CatalogId,DatabaseName,TableName,TaskType} MaterializedViewRefresh
```

使用 AWS CLI：

```
aws cloudwatch get-metric-statistics \
    --namespace AWS/Glue \
    --metric-name <MetricName> \
    --dimensions Name=CatalogId,Value=<CATALOG_ID> \
                 Name=DatabaseName,Value=<DATABASE_NAME> \
                 Name=TableName,Value=<TABLE_NAME> \
                 Name=TaskType,Value=MaterializedViewRefresh \
    --start-time <START_TIME> \
    --end-time <END_TIME> \
    --period 3600 \
    --statistics Sum \
    --region <REGION>
```

### CloudWatch 日志
<a name="materialized-views-cloudwatch-logs"></a>

查看各个刷新任务运行的详细执行日志：

日志组：`/aws-glue/materialized-views/<task_run_id>`

UUID 在`<task_run_id>`哪里（例如 abc12345-def6-7890-ghij-klmnopqrstuv）。

查看日志：

```
# List log streams for a task run
aws logs describe-log-streams \
    --log-group-name /aws-glue/materialized-views/<TASK_RUN_ID> \
    --region <REGION>

# Get log events
aws logs get-log-events \
    --log-group-name /aws-glue/materialized-views/<TASK_RUN_ID> \
    --log-stream-name <LOG_STREAM_NAME> \
    --region <REGION>
```

在 CloudWatch 控制台中：

1. 导航至 CloudWatch → 日志组

1. 搜索 /aws-glue/materialized-views/

1. 选择带有您的任务运行 ID 的日志组

1. 查看详细的执行日志、错误和 Spark 任务输出

### 通知
<a name="materialized-views-eventbridge"></a>

订阅事件以获取有关刷新作业状态更改的实时通知：

可用的事件类型：
+ Glue 物化视图刷新任务已启动
+ Glue 物化视图刷新任务成功
+ Glue 物化视图刷新任务失败
+ Glue 物化视图自动刷新调用失败

创建规则：

```
aws events put-rule \
    --name materialized-view-refresh-notifications \
    --event-pattern '{
        "source": ["aws.glue"],
        "detail-type": [
            "Glue Materialized View Refresh Task Started",
            "Glue Materialized View Refresh Task Succeeded",
            "Glue Materialized View Refresh Task Failed",
            "Glue Materialized View Auto-Refresh Invocation Failure"
        ]
    }' \
    --region <REGION>
```

添加目标（例如，SNS 主题）：

```
aws events put-targets \
    --rule materialized-view-refresh-notifications \
    --targets "Id"="1","Arn"="arn:aws:sns:<REGION>:<ACCOUNT_ID>:<TOPIC_NAME>" \
    --region <REGION>
```

### 查看刷新状态
<a name="materialized-views-refresh-status"></a>

使用 AWS Glue API 检查您的物化视图刷新任务的状态：

```
aws glue get-materialized-view-refresh-task-run \
    --catalog-id <CATALOG_ID> \
    --materialized-view-refresh-task-run-id <TASK_RUN_ID> \
    --region <REGION>
```

或者列出所有最近的刷新运行：

```
aws glue list-materialized-view-refresh-task-runs \
    --catalog-id <CATALOG_ID> \
    --database-name <DATABASE_NAME> \
    --table-name <MV_TABLE_NAME> \
    --region <REGION>
```

这显示：
+ 上次刷新时间
+ 刷新状态（成功、失败、正在运行、已停止）
+ 任务运行 ID
+ 错误消息（如果失败）

常见刷新状态：
+ 正在运行：刷新作业当前正在执行
+ 成功：刷新成功完成
+ 失败：刷新遇到错误
+ 已停止：刷新已手动取消

刷新失败疑难解答：

如果刷新失败，请检查：

1. IAM 权限：确保定义者角色有权访问所有基表和物化视图位置

1. 基表可用性：验证所有引用的表都存在并且可以访问

1. 查询有效性：确认 SQL 查询对 Spark SQL 方言有效

1. 资源限制：检查您的账户是否已达到并发刷新上限

使用 GetMaterializedViewRefreshTaskRun API 检索详细的错误消息。

## 注意事项和限制
<a name="materialized-views-considerations-limitations"></a>
+ 物化视图只能引用在 AWS Glue 数据目录中注册的 Apache Iceberg 表作为基表。
+ 视图创建和自动查询重写仅适用于亚马逊 Athena、亚马逊 EMR 和（版本 5.1）的 Apache Spark 3.5.6 及更高版本的 Spark 引擎。 AWS Glue 
+ 物化视图最终与基表保持一致。在刷新窗口期间，直接访问物化视图的查询可能会返回过期的数据。要立即访问当前数据，请执行手动刷新。
+ 最小自动刷新间隔为一小时。对于需要更频繁更新的用例，请使用命令以编程方式执行手动刷新。`REFRESH MATERIALIZED VIEW`
+ 查询重写优先考虑正确性而不是性能。如果物化视图过时或无法准确满足查询要求，则 Spark 引擎会对基表执行原始查询。

# 在 Lake Formation 中使用工作流导入数据
<a name="workflows"></a>

通过 AWS Lake Formation，您可以使用工作流导入数据。**工作流定义数据来源和计划以将数据导入到数据湖中。它是一个容器，用于存放 AWS Glue 爬网程序、作业和触发器，用于编排加载和更新数据湖的流程。

**Topics**
+ [Lake Formation 中的蓝图和工作流](workflows-about.md)
+ [创建工作流](workflows-creating.md)
+ [运行工作流](workflows-running.md)

# Lake Formation 中的蓝图和工作流
<a name="workflows-about"></a>

工作流封装了复杂的多作业提取、转换、加载 (ETL) 活动。工作流生成 AWS Glue 爬网程序、作业和触发器，以编排数据的加载和更新。Lake Formation 将工作流作为单个实体来执行和跟踪。您可以将工作流配置为按需或按计划运行。

**注意**  
Spark Parquet 写入器不支持在列名中使用特殊字符。这是写入器本身的技术限制，而不是配置问题。

您在 Lake Formation 中创建的工作流在 AWS Glue 控制台中显示为有向无环图 (DAG) 形式。每个 DAG 节点都是一个作业、爬网程序或触发器。要监控进度并进行故障排除，您可以跟踪工作流中每个节点的状态。

Lake Formation 工作流完成后，运行该工作流的用户将获得对该工作流创建的数据目录表的 Lake Formation `SELECT` 权限。

您也可以在 AWS Glue 中创建工作流。但是，由于 Lake Formation 允许您从蓝图创建工作流，因此在 Lake Formation 中创建工作流要简单得多，自动化程度也更高。Lake Formation 提供以下类型的蓝图：
+ **数据库快照** – 将所有表中的数据从 JDBC 源加载或重新加载到数据湖中。您可以根据排除模式从该源中排除某些数据。
+ **增量数据库** - 根据先前设置的书签，仅将新数据从 JDBC 源加载到数据湖中。您可以指定 JDBC 源数据库中要包含的各个表。对于每个表，您可以选择书签列和书签排序顺序，以跟踪之前加载的数据。首次对一组表运行增量数据库蓝图时，工作流会加载表中的所有数据，并为下一次增量数据库蓝图运行设置书签。因此，您可以使用增量数据库蓝图（而不是数据库快照蓝图）来加载所有数据，前提是将数据来源中的每个表指定为参数。
+ **日志文件** - 从日志文件来源（包括 AWS CloudTrail、Elastic Load Balancing 日志和应用程序负载均衡器日志）批量加载数据。

使用下表可帮助确定是使用数据库快照蓝图还是增量数据库蓝图。


| 在以下情况下使用数据库快照... | 在以下情况下使用增量数据库... | 
| --- | --- | 
|  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/workflows-about.html)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/workflows-about.html)  | 

**注意**  
用户无法编辑 Lake Formation 创建的蓝图和工作流。

# 创建工作流
<a name="workflows-creating"></a>

在开始之前，请确保已向角色 `LakeFormationWorkflowRole` 授予所需的数据权限和数据位置权限。这样，工作流就可以在数据目录中创建元数据表，并将数据写入 Amazon S3 中的目标位置。有关更多信息，请参阅[（可选）为工作流创建 IAM 角色](initial-lf-config.md#iam-create-blueprint-role)和 [Lake Formation 权限概述](lf-permissions-overview.md)。

**注意**  
Lake Formation 使用 `GetTemplateInstance`、`GetTemplateInstances` 和 `InstantiateTemplate` 操作根据蓝图创建工作流。这些操作不对外公开，仅在内部使用，用于代表您创建资源。您会收到用于创建工作流的 CloudTrail 事件。

**通过蓝图创建工作流**

1. 通过 [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) 打开 AWS Lake Formation 控制台。以数据湖管理员或具有数据工程师权限的用户身份登录。有关更多信息，请参阅[Lake Formation 角色和 IAM 权限参考](permissions-reference.md)。

1. 在导航窗格中，选择**蓝图**，然后选择**使用蓝图**。

1. 在**使用蓝图**页面上，选择一个磁贴以选择蓝图类型。

1. 在**导入来源**下，指定数据来源。

   如果要从 JDBC 源导入，请指定以下内容：
   + ****数据库连接**** - 从列表中选择一个连接。使用 AWS Glue 控制台创建其他连接。连接中的 JDBC 用户名和密码决定了工作流有权访问的数据库对象。
   + ****来源数据路径**** - 输入 *<database>*/*<schema>*/*<table>* 或 *<database>*/*<table>*，具体取决于数据库产品。Oracle Database 和 MySQL 不支持路径中的架构。您可以用百分比 (%) 字符替换 *<schema>* 或 *<table>*。例如，对于系统标识符 (SID) 为 `orcl` 的 Oracle 数据库，输入 `orcl/%` 以导入连接中指定的用户有权访问的所有表。
**重要**  
此字段区分大小写。如果任何组件存在大小写不匹配的情况，则工作流将失败。

     如果指定 MySQL 数据库，则 AWS Glue ETL 默认使用 Mysql5 JDBC 驱动程序，因此 MySQL8 不受原生支持。您可以将 ETL 作业脚本编辑为使用 `customJdbcDriverS3Path` 参数，如《AWS Glue 开发人员指南》中的 [JDBC connectionType 值](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-connect.html#aws-glue-programming-etl-connect-jdbc)中所述，以使用支持 MySQL8 的其他 JDBC 驱动程序。**

   如果要从日志文件导入，请确保您为工作流指定的角色（“工作流角色”）具有访问数据来源所需的 IAM 权限。例如，要导入 AWS CloudTrail 日志，用户必须具有 `cloudtrail:DescribeTrails` 和 `cloudtrail:LookupEvents` 权限才能在创建工作流时查看 CloudTrail 日志列表，并且工作流角色必须具有对 Amazon S3 中 CloudTrail 位置的权限。

1. 请执行以下操作之一：
   + 对于**数据库快照**蓝图类型，可以选择通过指定一个或多个排除模式来识别要导入的一部分数据。这些排除模式是 Unix 风格的 `glob` 模式。它们将存储为由工作流创建的表的属性。

     有关可用排除模式的详细信息，请参阅《AWS Glue 开发人员指南》中的[包含和排除模式](https://docs.aws.amazon.com/glue/latest/dg/define-crawler.html#crawler-data-stores-exclude)。**
   + 对于**增量数据库**蓝图类型，请指定以下字段。为每个要导入的表添加一行。  
**表名称**  
要导入的表。必须全部小写。  
**书签键**  
定义书签键的列名的逗号分隔列表。如果为空，则使用主键确定新数据。每列的大小写必须与数据来源中定义的大小写匹配。  
仅当主键按顺序递增或递减（无间隙）时，主键才有资格成为默认书签键。如果要使用主键作为书签键并且它有间隙，则必须将主键列命名为书签键。  
**书签顺序**  
选择**升序**时，值大于书签值的行将被标识为新行。选择**降序**时，值小于书签值的行将被标识为新行。  
**分区方案**  
（可选）分区键列列表，用斜杠 (/) 分隔。示例：` year/month/day`。  
![\[控制台的“增量数据”部分包括以下字段：“表名称”、“书签键”、“书签顺序”、“分区方案”。您可以添加或删除行，其中每行用于不同的表。\]](http://docs.aws.amazon.com/zh_cn/lake-formation/latest/dg/images/incremental-data.png)

     有关更多信息，请参阅《AWS Glue 开发人员指南》中的[使用作业书签来跟踪已处理的数据](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html)。**

1. 在**导入目标**下，指定目标数据库、目标 Amazon S3 位置和数据格式。

   确保工作流角色对数据库和 Amazon S3 目标位置具有所需的 Lake Formation 权限。
**注意**  
目前，蓝图不支持加密目标位置的数据。

1. 选择导入频率。

   您可以使用**自定义**选项指定 `cron` 表达式。

1. 在**导入选项**下：

   1. 输入工作流名称。

   1. 对于角色，选择您在[（可选）为工作流创建 IAM 角色](initial-lf-config.md#iam-create-blueprint-role)中创建的角色 `LakeFormationWorkflowRole`。

   1. （可选）指定表前缀。该前缀位于工作流创建的数据目录表的名称之前。

1. 选择**创建**，然后等待控制台报告已成功创建工作流。
**提示**  
您是否收到了以下错误消息？  
`User: arn:aws:iam::<account-id>:user/<username> is not authorized to perform: iam:PassRole on resource:arn:aws:iam::<account-id>:role/<rolename>...`  
如果是，请检查您是否已在所有策略中将 *<account-id>* 替换为有效的 AWS 账号。

**另请参阅：**  
[Lake Formation 中的蓝图和工作流](workflows-about.md)

# 运行工作流
<a name="workflows-running"></a>

您可以使用 Lake Formation 控制台、AWS Glue 控制台、AWS Glue 命令行界面 (AWS CLI) 或 API 运行工作流。

**运行工作流（Lake Formation 控制台）**

1. 通过 [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) 打开 AWS Lake Formation 控制台。以数据湖管理员或具有数据工程师权限的用户身份登录。有关更多信息，请参阅[Lake Formation 角色和 IAM 权限参考](permissions-reference.md)。

1. 在导航窗格中，选择**蓝图**。

1. 在**蓝图**页面上，选择工作流。然后，在**操作**菜单上，选择**开始**。

1. 当工作流运行时，在**上次运行状态**列中查看其进度。时不时地选择刷新按钮。

   状态从**正在运行**依次变为**正在发现**、**正在导入**和**已完成**。

   工作流完成后：
   + 数据目录中将含有新的元数据表。
   + 您的数据已被摄取到数据湖中。

   如果工作流失败，请执行以下操作：

   1. 选择工作流。选择**操作**，然后选择**查看图表**。

      该工作流将在 AWS Glue 控制台中打开。

   1. 确保已选择工作流，然后选择**历史记录**选项卡。

   1. 在**历史记录**下，选择最近的运行，然后选择**查看运行详细信息**。

   1. 在动态（运行时）图表中选择失败的作业或爬网程序，然后查看错误消息。失败的节点为红色或黄色。

**另请参阅：**  
[Lake Formation 中的蓝图和工作流](workflows-about.md)