共计 4560 个字符，预计需要花费 12 分钟才能阅读完成。
简介：阿里云数据湖构建产品（DLF）提供的对立元数据服务，通过欠缺各种引擎 / 表格局生态解决了数据湖场景下多引擎面临的数据孤岛和元数据一致性问题，实现了开源大数据引擎及数据湖格局元数据的对立视图，防止了各引擎拜访湖上数据其中额定的 ETL 老本并升高了业务解决链路的延时。
背景信息
阿里云数据湖构建产品（DLF）提供的对立元数据服务，通过欠缺各种引擎 / 表格局生态解决了数据湖场景下多引擎面临的数据孤岛和元数据一致性问题，实现了开源大数据引擎及数据湖格局元数据的对立视图，防止了各引擎拜访湖上数据其中额定的 ETL 老本并升高了业务解决链路的延时。但同时另一个问题随之产生即不同的引擎可能有不同的权限模型和用户模型，这导致在不同的引擎上用户和权限无奈真正做到互通，如果可能在对立元数据的根底上实现集中式的权限校验，一次权限配置多引擎失效，实现引擎级的权限互通，将极大的进步湖上数据拜访的安全性，同时将升高权限治理的复杂性。
实现数据湖对立权限服务计划的要点
因为不同的引擎 / 表格局在权限计划上 / 用户模型上存在着差别，例如在用户模型上 EMR Hive/Spark 等开源引擎的用户模型可能是 LDAP，但阿里云的其余产品如 MaxCompute、Holo 等是阿里云账号 /RAM 体系，又比方在权限计划上 EMR Hive/Spark/Presto 等或没有本人的平安体系或借助其余平台实现、特地是一些开源体系的表格局 Hudi/iceberg/delta 等目前齐全没有权限管制，而在 Maxcompute/Holo 则有本人的一套权限管制体系，即便开源引擎都可能进行权限管制，但权限的数据、模型和权限校验的行为也基本不可能做到统一，所以在对立的元数据视图的根底上，实现对立的权限服务，须要解决四个重要问题
不同引擎的用户体系互通问题
实现不同引擎的不同的用户体系可能进行互转
不同引擎的权限体系互通问题
各引擎和格局应用同一套权限校验体系
通过元数据 API 拜访 / 引擎拜访，鉴权一致性的问题
元数据 API 拜访也要应用同样的鉴权体系
放弃不同引擎可能在现有应用形式上
在解决上述两个问题的根底上，可能放弃现有用户应用形式、产生的元数据不变
数据湖构建之对立权限服务计划介绍
数据湖构建对立权限服务计划依靠于数据湖对立元数据，是整个数据湖构建根底服务的一部分。整体计划一方面通过将不同引擎的用户体系映射至同一套用户体系来解决用户辨认问题，另一方面通过将数据湖对立权限校验机制与开源体系的 EMR hive/spark/Presto/Databricks 等引擎、数据湖格局 Hudi/Delta 等以及与 MaxCompute/Holo（进行中）等引擎集成来解决不同引擎权限数据一致性和互通问题，从而开源引擎拜访湖上数据时有了对立的元数据视图及权限校验机制。
1651736877516-6a8259aa-5ff2-4ddf-bcd0-52a2a8354c41.png
开源引擎 / 数据湖格局代理鉴权机制
数据湖构建产品是采纳类 Ranger Pugin 计划来反对引擎侧鉴权，其形式首先是通过将引擎拜访的账号在 RAM 平台授予 AliyunDLFFullAccess 权限同时将引擎账号增加至 DLF 互信权限名单中（互信权限可通过 Setting API 增加），实现引擎与 DLF 元数据产品的互信，这样当各引擎承受到用户的申请时，这些 Plugin 将拦挡该申请并可在引擎侧发动该用户的代理鉴权调用，同时在引擎侧将进行用户模型转换，例如在数据湖构建平台上应用阿里云账号 /Ram 子账号机制，在引擎侧将 LDAP 用户与云账号进行映射（可采纳 LDAP 账号与 RAM 账号同名映射形式简化），鉴权申请在服务端鉴权之后，引擎将鉴权后果返回给用户，此种模式下用户须要具备元数据资源的拜访权限即可，权限获取能够通过数据湖构建产品 - 数据权限页面进行受权获取。
引擎侧整体鉴权流程如下：
1651736954151-c6147a2b-152f-47f7-ba4e-a5ce0b38a1e0.png
DLF 元数据拜访鉴权机制
对于间接拜访 DLF 元数据的用户将采纳双层鉴权模型，亦即用户须要同时具备 DLF 元数据 API 拜访权限（在 RAM 上配置）及元数据资源拜访权限。前者须要在 Ram 平台进行受权（如下图所示），后者跟引擎代理鉴权模式雷同须要通过数据湖构建产品 - 数据权限页面进行受权获取。
在 Ram 访问控制平台上可抉择用户增加权限，如果用户只读元数据能够授予 AliyunDLFReadOnlyAccess 权限。
1651737026179-32d44546-ae91-426b-9ff3-f83b56ba263d.png
元数据拜访整体鉴权流程如下：
1651737040301-40dba316-5aec-4819-862d-a72bfc7180b1.png
数据湖构建之对立权限服务实际
前提条件
已开明数据湖构建产品，目前对立权限服务已在所有数据湖构建产品所在 region 上线。
已开明 EMR 3.40/5.60 及以上版本的集群，如已有其余低版本的 EMR 请提交工单分割阿里云工程师进行征询解决。
已开启数据湖权限服务端鉴权，可通过如下形式开明
需提交工单分割阿里云工程师进行征询解决
通过 Settings API（调用 Settings API 须要 DLF Ram Api “dlf:UpdateCatalogSettings” 及 DLF admin 角色的权限）
将来页面将凋谢 Settings 配置给用户自行配置
具体内容及操作步骤
采纳阿里云主账号对阿里云 Ram 子账号 (也可对 Ram 角色) 进行 admin/super_administrator 角色受权，以进行分权治理。
对其余业务阿里云 Ram 子账（Ram 角色）在数据湖构建平台集中施行 database 及 table 权限的治理
对其余业务阿里云 Ram 子账（Ram 角色）通过角色在数据湖构建平台集中施行 database 及 table 权限的治理
在数据湖构建平台、EMR 引擎中别离拜访有权限的表和没有权限的表
数据湖构建平台提供丰盛的权限 api 供给用产品集成，用户能够退出本人的权限申请、审批流程
- 采纳阿里云主账号对阿里云 Ram 子账号进行 admin/super_administrator 角色受权，以进行分权治理。
导航至数据湖构建 - 数据权限 - 角色页面，点击右侧增加用户按钮，抉择待受权的 RAM 子账号，点击确定，进行子账号 admin 角色受权，如图：
1651737108045-f0dd5faa-7687-4356-a933-821384e89a74.png
实现后，子账号 test1 将领有 admin 角色权限，test1 将从 admin 角色取得所有资源的拜访和受权权限。后续能够通过 test1 账号进行其余账号权限的治理。
2. 应用 test1 账号登录，对子账号间接受权
导航至数据湖构建 - 数据权限 - 数据受权页面，点击新增受权，对子账号 data 受权 db1 的 Describe、CreateTable 权限，并授予该 db1 下所有除 Drop 外的表权限，在受权页面抉择 data 用户并实现如下受权
1651737142459-dc57f2d7-4f0c-46ac-9e7e-1e508857310f.png
实现后，data 将具备上述权限。
3. 应用 test1 账号登录，创立角色，对角色受权，并将角色授予用户
创立数据湖构建角色 test，并将该角色授予给子账号 datamigrator，同时给角色 test 受权 db1 的 Describe 权限，并授予该 db1 下所有除 Select 外的表权限
1651737207437-9f9f0a23-002b-45a0-8481-258539ff1e00.png
1651737221452-5c253d48-e534-40f6-8b17-e7e4777d0c01.png
1651737235358-581ce142-84b6-4c59-bc7c-6b7123d26198.png
此时各账户具备如下权限：
账号
领有角色
权限
test1
admin
领有所有资源的拜访和受权权限
data
领有 db1 的 Describe、CreateTable、List
领有 db1 下所有表除 Drop 外的权限（默认领有本人创立的表权限）
datamigrator
test
领有 db1 的 Describe、List 权限
领有 db1 下所有表除 Select 外的权限
4. 在数据湖平台上进行权限验证
在数据湖构建平台上应用 data 子账号拜访相干元数据进行权限的验证，例如创立表，删除表，查问表.
1) 可失常创立表 test_create_table_from_data
1651737303585-275d97f5-97c2-453e-89e4-376ce6d0ea4a.png
2) 可失常删除本人创立的表 test_create_table_from_data
3) 删除其余用户创立的表 test_table，将报权限谬误
1651737316619-14cd3147-2e30-49b7-a783-29d8b7971464.png
4) 应用数据摸索拜访另一个 db 下的表，将报权限谬误
1651737330570-86bedc5e-502d-4c07-9122-a481cf9f42c9.png
5）用户可自行实现 datamigrator 权限的测试，此处不再过多演示。
5. 在 EMR 集群进行权限的验证
1) 通过 Settings API（近期实现自动化），将 EMR 集群角色（可在 EMR 集群根底信息页面 -ECS 利用角色局部找到），增加为互信账号(批改之前通过 GetCatalogSettingsAPI 查看 Settings 内容，防止误批改):
{
“Config”: {
“auth.super.principal”: “acs:[aliyunAccountId]:role/AliyunECSInstanceForEMRRole”
}
}
2）在 EMR 集群上，抉择 DLF-Auth 组件并按下图所示，启用 hive/Presto/Spark 的鉴权
1651737393340-d333d3f4-13db-461e-841e-6a9b7015b9a7.png
3）对鉴权进行验证
应用 data 用户通过 beeline 拜访 Hiveserver 执行元数据操作，用户可自行进行其余语句的测试
1651737407168-97923477-ce8c-475c-8bfa-63dc5f0ad44a.png
6. 其余利用及平台与数据湖元数据 / 权限 API 集成
数据湖构建平台提供丰盛的权限 API 供给用产品集成，用户能够退出本人的权限申请、审批流程权限 API 列表见链接，用户可抉择将元数据 API 及权限 API 集成至自有权限审批平台，以实现本人的业务诉求。
总结
目前权限能力陆续在生态上进行集成，可能满足一部分场景需要，但还有一些局限，比方受权操作仅 admin 角色可进行资源受权，基于此咱们将在近期推出 Grantable 权限，届时能够将资源的 Grant 权限授予给其余角色和用户，进一步实现权限分治，升高治理压力。另外数据湖构建产品将来将持续在多引擎生态、数据安全上发力，让数据湖构建产品具备更欠缺的生态和企业级的个性！
原文链接：http://click.aliyun.com/m/100…
本文为阿里云原创内容，未经容许不得转载。