点击查看直播回放
一、 元数据与权限背景介绍
开源元数据体系由来、演进及问题
开源大数据体系是指以 Hadoop 为核心的生态系统，而目前 Hive 是开源数仓的事实标准。
对于大数据的由来和倒退，要追溯到谷歌在 2003 年发表的论文，论文中提出了 HDFS 和 MapReduce 两个组件。HDFS 组件最早用于解决网页存储问题，它能够部署在大量便宜的机器上，提供极佳的硬件容错能力以及存储的扩展性。MapReduce 的初衷是解决搜索引擎中大规模网页数据的并行化解决问题。同时它也是比拟通用的并行处理框架，可用于解决很多大数据场景。
尽管 HDFS 和 MapReduce 很好地解决了大数据存储和大规模数据并行处理的问题，但仍然存在几个毛病：
第一，编程门槛较高。传统的数仓工程师接触的编程接口个别是 SQL，但 MapReduce 框架有肯定的编程能力要求。
第二，HDFS 上存储的是文件和目录，并没有存储元数据，也无奈进行查问。因而即便晓得文件的构造，也无奈对文件的内容形式变动进行治理，导致程序自身可能丢失稳定性。
基于以上痛点，以雅虎为代表的公司提出了 Apache Pig，提供 SQL-like 语言，该语言的编译器会把类 SQL 的数据分析申请转换为一系列通过优化解决的 MapReduce 运算，屏蔽了 MapReduce 细节，能够很轻松高效地解决数据；而以 Facebook 为代表的公司提出 Hive 的解决方案，在 HDFS 上提供了一层数据抽象，屏蔽了文件系统及编程模型的细节，极大升高了数仓开发人员的门槛。通过对数据及文件系统到元数据的形象，可能十分不便地进行数据共享、检索以及查看数据变更历史。这一层的元数据抽象即现在大家所熟知的 Database、Table、Partition 和 Function，同时在元数据上又衍生出了十分靠近 SQL 语言的 HiveQL。同时后续的 Hive3.0 版本新增了 catalog 的性能，Hive4.0 版本新增了 Connectors 性能。依靠于元数据, 计算引擎能够很好地进行历史的追溯。除了追溯历史 schema 变更外，元数据还有一个重要性能是爱护数据（不做不兼容的变更）。
Hive3.0 实现的 catalog 性能，次要基于以下两个场景：
① 多个零碎之间可能须要 MetaStore 元数据的 Namespace，冀望可能达到肯定的隔离。比方 Spark 有本人的 catalog，Hive 也有本人的 catalog，不同的 catalog 上能够有不同的鉴权、经营策略。
② 能够对接内部零碎的 catalog。
Hive4.0 的 Connectors 次要是定义数据 DataSource，其余引擎对接 Hive 元数据后，即可通过该接口辨认 DataSource 的信息，不便其余引擎做查问。
目前 Hive 上简直曾经反对了 Hadoop 生态的所有计算引擎，因而它也曾经成为开源数仓的事实标准。但它仍然存在一些问题，比方尽管反对了 schema 的衍变，然而并不能通过 Time-Travel 的形式查问数据变动的历史快照，尽管有 ACID 新个性，但与 Hive 引擎的深度绑定导致无奈很好地移植到其余引擎上。
另外，ACID 个性次要应用 rename 的形式做 isolation 隔离，在做文件 Compaction 及在存储拆散等场景容易呈现问题，比方 rename 过程在云存储上的性能问题。开源社区针对这些点衍化出了一些数据湖的格局，在不同水平上解决了 ACID 的问题。
数据湖格局领有本人的元数据，同时会将本身的元数据注册到 Hive Metastore 中。数据湖格局的元数据与 Hive 元数据造成补充，并没有脱离整体 Hive 元数据的视图，其余引擎仍然能够通过 Hive Metastore 这一套元数据管理体系拜访数据湖格局上的数据。
但 Hive Metastore 上并没有多租户的能力，同时受限于单个元数据库的能力瓶颈，有些公司会部署多套 Metastore，这很容易造成数据孤岛，所以也有一些公司提出了解决方案，比方 Waggle-Dance 及 Multiple Hive Metastore 计划等。另外因为 HiveMetaStore 应用 Thrift 协定的接口，所以外部引擎和自研引擎对接 Hive Metastore 时，必须对接 Metastore 的协定以及依赖相应的客户端，这种依赖还是比拟重的。
另外，Metastore 在设计元数据存储时高度去冗余，因而会带来一些 Metadata Fetch 的性能问题。
开源的 Waggle-Dance 计划后端有多个 Metastore，每个 Metastore 有本人的 Database 存储。Waggle-Dance 模块实现了 Hive Metastore 后端残缺的 Thrift 协定，可能无缝对接到其它引擎，解决现有的 Metastore 瓶颈问题，比方单个 DB 存储量、单个 Metastore 性能问题等。
然而 Waggle-Dance 解决多租户的计划存在命名抵触问题，须要提前做 Database 和 Metastore 的命名布局。因为 Waggle-Dance 路由的模块有一个 Database 到后端 Metastore 路由表。如果是 Hive 3.0，能够通过 catalog 这一层路由的映射设计来解决。
另外，Waggle-Dance 可能会带来 Thrift 接口协议的抵触，比方后端可能存在多个 Hive Metastore 的版本或有多个不同 client 的版本。因而中间层的路由组件可能须要兼容不同的版本，就可能会呈现协定的兼容性问题。
权限管制体系介绍
除了元数据外，元数据和数据拜访的安全性也十分重要。企业的数据安全性必须依赖于欠缺的权限体系。权限的根本三要素包含主体、客体和操作。ACL 建设在根底三要素之上，对应到元数据上为：某个人对某个表有什么样的操作权限。ACL 存在肯定的缺点，比方后续如果权限比拟多会难以治理，因而又倒退出 RBAC 和 PBAC 权限。
以入住酒店为例解释 ACL、RBAC 和 PBAC 三者的区别：比方住客入住酒店后会失去一把房门钥匙，失去进入某个房间的权限，即相当于 ACL；而针对某一楼层有一个楼层管理员，能够治理所有房间，即相当于 RBAC，在 ACL 下面减少了一层用户的角色到权限的映射，有了角色之后很显然升高了权限治理老本；然而如果有比拟非凡的需要，比方须要限度某一层的管理员只能在上午 7 点后才有权限进入房间，即须要 PBAC，它是基于策略的模型，在一般权限模型的根底之上反对了权限条件。
Hive 0.13 提出了 Hive Storage-Based Authorization，它是基于底层存储的鉴权。该权限策略的长处在于无论是 meta 操作还是底层文件存储操作，都能够取得对立的权限视图。但它是基于目录和底层文件的权限体系，因而无奈很好地映射到 SQL 层面权限操作。同时，因为底层的权限是文件，所以无奈在数据层面或字段级别做更细粒度的鉴权，因而它并不反对 Fine-grain control。
基于以上问题，社区提出了 Hive SQL-Standard Based Authorization，即基于 SQL 的标准化鉴权模型，可能在 SQL 层面反对 Grant 和 Revoke 控制指令。同时能够做绝对细粒度的权限管制，比方能够将搜寻上的很多操作映射到权限模型上。该模型实现了列级的访问控制，但没有实现行级的权限。
另外，Hive SQL-Standard Based Authorization 尽管具备 SQL 层面的权限，但并不蕴含存储系统的权限。因而做存储系统的拜访或实操层面拜访时，无奈取得对立的权限视图。且该模式不反对数据湖格局。
起初，某商业公司推出了 Apache Ranger(Sentry)，面向所有大数据开源生态组件，对底层的文件系统 YARN、Hive、Spark、Kafka 提供了中心化的权限管制计划。同时反对在 SQL 层面进行 Grant、Revoke，比此前的模型减少了更细粒度的权限，比方行级过滤、列级权限管制，同时在权限上还具备 exception policy 及其他能力。
但 Apache Ranger 也存在一些问题。因为 PBAC 模型的权限是当时定好的，不依赖对象的存在与否。比方用户对某表有 select 权限，表被删除后又被从新建出，而该用户依然领有权限，这并不合理。另外，尽管 ranger 能够应用在很多大数据组件之上，但仅限于 Hive 的 HiveServer，而 Hive Metastore 上并没有权限管制，所以它面临的问题在于 Hive Metastore 提供的元数据拜访接口和在之上提供的权限接口存在拆散。
因而，总结来看，数据湖治理面临的挑战蕴含以下几个方面：
在元数据服务层面，开源版本没有多租户的能力，扩展性、稳定性以及性能方面都存在问题，对接多个计算引擎难度大。
数据安全层面，权限管制计划简单，成熟度低，无奈笼罩所有计算引擎，且为凋谢存储，权限难以管制。
数据治理层面，开源社区目前没有十分好的数据管理工具。无奈很好地依据元数据分析现有的存储老本，也无奈做很好的生命周期治理。尽管 Hive4.0 曾经减少了一些个性，比方能够做 partition 的主动发现 以及对 partition 做肯定的生命周期治理，但整体上仍然没有很好的治理伎俩。
查问性能层面，存储计算拆散架构的读写性能受带宽管制，原始数据未通过优化因此查问性能低，且短少索引、统计等减速伎俩。
阿里云针对上述问题和挑战，实现了一套面向数据湖畛域的元数据、平安、治理、减速的解决方案：
- 全托管免运维的对立元数据中心
对立元数据中心脱胎于阿里云外部久经考验的元数据底座，无缝对接多种开源计算引擎和自研的外部引擎，同时依靠于阿里云的数据湖构建与治理 DLF 产品提供了元数据的发现、迁徙、备份的能力。
- 企业级权限管制
数据安全方面，反对阿里云账号零碎，也能够兼容开源的 LDAP 账号体系；提供字段级别的读写权限管制和 Location 权限托管。引擎和利用甚至能够对接元数据 API 和权限 API，实现本人的权限集成或元数据集成，从而使所有引擎及利用都能够实现对权限的对立管制。
- 智能数据管理与优化
<!—->
-
- 精细化存储统计与剖析
- 自动化数据冷热判断与分层
- 多重数据湖减速
<!—->
-
- JindoFS 提供数据缓存减速
- 主动小文件合并、数据清理
- 主动 Stats 计算、查问优化
- 湖格局元数据服务化
二、阿里云数据湖对立元数据服务
阿里云上数据湖对立元数据服务架构
阿里云上数据湖对立元数据服务（DLF）提供了多租户、对立数据目录，反对多引擎的扩大与切换。兼容了 Hive2.X 与 Hive3.X 协定，可能实现无缝对接开源与自研的所有计算引擎。同时，所有 API、SDK 和对接开源引擎的客户端曾经在阿里云上开源，反对客户自研引擎、利用或系统集成。
另外，依靠于底层存储的表格存储，面向海量结构化提供的 service 服务有着十分优良的弹性伸缩能力，无需放心扩大问题。同时提供了高可用、免运维的能力。
此外，提供对立的权限管制，用户只需依附权限的配置，无论在 EMR 引擎上、阿里云的自研引擎上，还是在 DataWorks 等数据开发平台上，都能够实现多引擎、多治理平台或多利用的对立权限管控。可能反对阿里云 RAM 以及开源 LDAP 账号体系。
对立元数据服务的最上层是数据湖存储，目前反对对象存储和文件存储。数据服务层提供了两个根底服务：第一层是 catalog，负责管理元数据，包含 Catalog、Database、Function 和 Table；第二层是权限服务，包含 ACL 体系、RBAC 和 PBAC，TBAC 正在打算中（次要针对资源包）。
再下层对接阿里云网关认证体系，反对 RAM 的子账号鉴权以及权限策略，能够实现底层元数据 API 和权限 API，之上提供了 SDK 插件体系。有的云厂商保留了所有组件，在 Hive Metastore 外部进行封装来实现开源的无缝对接。其长处在于只需改变 Hive Metastore，其余的引擎都能主动对接到 Hive Metastore 上。而阿里云没有抉择 Hive Metastore 计划，次要出于以下几个考量：
首先，保留 Hive Metastore 会带来肯定的老本，所有申请都须要进行转发，会导致性能损耗。同时，Hive Metastore 自身的稳定性会影响整体元数据服务的稳定性，而且随着用户集群流量的增大，Metastore 也须要扩容。因而阿里云抉择了在轻量级 SDK 上实现 client 接口并间接嵌入到引擎中，实现开源引擎到 DLF 服务的对接。
阿里云自研的引擎 MaxCompute、Hologres 以及全托管的 OLAP 引擎也曾经齐全对接 DLF。另外，用户的元数据管理利用或开发平台也能够对接 API。
很多用户外部的元数据管理利用通过 JDBC 的形式连贯底层的 MySQL，而这也可能存在问题。比方底层元数据结构的降级会导致利用也须要改变。另一方面，间接对接 JDBC 接口查问底层数据，齐全没有权限管制。然而如果对接 DLF API，无论是 API 拜访还是 EMR 拜访，都会通过一层权限的管制体系，不会泄露权限。
阿里云上数据湖对立元数据基本功能及优化
阿里云提供了多租户和对立的数据目录，是以阿里云账号进行租户之间隔离的一种机制。阿里云账号下能够创立多个 catalog，提供了 table 级别的 schema 多版本，能够依据版本数据查问 table schema 的演变过程。同时阿里云外部各引擎通过反对 DLF，也同时实现了 Iceberg、Hudi、Delta 数据湖格局买通。
此外，在 catalog 上会按租户的元数据做分区，用户的存储不会打在同一个后端存储的热点分区上。同时，咱们实现了 ID 化，不便后续进行软删除、异步删除等优化。同时，在很多申请上实现了异步化。
IO 方面也进行了局部优化。比方做 List partition 时，返回的是同一个表 partition 的所有元数据，而在大多数场景上 partition 元数据的 SD 都雷同，因而齐全能够基于雷同的 SD 做共享，进行 partition SD 压缩，缩小网络层的 IO。
阿里云上数据湖对立元数据之稳定性机制
稳定性是另一个比拟要害的问题。在云上须要对接所有租户，因而元数据服务的降级、灰度、主动恢复能力十分重要。主动恢复能力和弹性伸缩是云上的标配，都是基于资源调度零碎实现。
稳定性机制的底层是阿里云 Table Store，下层是元数据服务。元数据服务有两个常驻集群 A 和 B，互为主备关系。在做降级时，将备服务配置为灰度状态，前端网关依据服务的配置策略以及租户分桶策略采集流量，而后发到灰度服务上，察看灰度流量是否失常，如果失常则降级到主服务；如果呈现问题，则依据配置回滚即可。
降级对用户侧、引擎侧齐全无感知。即便是服务下线，也会等到主服务的流量归零才下线，这一层依赖于元数据本人的网关，因而能够实现得更为轻量，比方能够通过切断心跳的形式实现下线。
三、阿里云数据湖对立权限服务
实现数据湖对立权限服务，首先要解决两个问题：身份的问题、API 和引擎的拜访权限一致性问题。
上图为数据湖对立权限架构图。底层为湖上数据及元数据，下层为数据湖对立鉴权服务，包含网关、用户模型转换、引擎的鉴权插件体系和 DLF 数据拜访服务端鉴权。最上层是曾经实现以及进行中的数据湖格局、开源引擎、数仓、数据湖构建平台以及利用。
目前，咱们提供了 ACL 和 RBAC 和 PBAC 三种权限管制相结合的形式，ACL 和 Policy 相互补充。其中 ACL 模式依赖于受权的主体和客体，因而主客体必须存在，反对白名单受权。Policy 同时反对白名单和黑名单。
引擎侧与 API 侧如何实现对立的鉴权？
如果是用户持有 AK 或在内部操作上应用治理平台，则该层级全副通过 DLF SDK/API，在服务端元数据拜访时会调用底下的鉴权引擎。
如果是 EMR 开源集群，用户通过 beeline 接口方式、通过 LDAP 认证，再通过 Spark ThriftServer 获取元数据。引擎会持有可信的身份，通过可信身份校验后引擎能够获取所有元数据，再由引擎负责用户模型的转换，获取用户的操作与身份，代理用户鉴权，将相应的鉴权申请发到服务端，调用同样的服务端鉴权逻辑，最终实现引擎侧和 API 层的对立鉴权。
四、数据湖元数据与权限瞻望
将来，数据湖元数据与权限将在对立、一致性和性能三个方面继续演进。
①对立元数据、权限、生态：云上的元数据目录及集中式权限治理将会成为标配，引擎、格局和各生态组件、开发平台对于元数据、权限的反对具备一致性。此外，反对非结构化、机器学习场景元数据模型自定义，这样其余类型的元数据也可通过自定义的形式接入到对立的元数据体系中。
②元数据减速：比方针对数据湖格局推出定制元数据 API，为计算层提供给更多面向性能优化的计划。
③更灵便的权限管制及更平安的数据拜访：用户能够自定义角色权限、操作权限。另外数据存储也能够实现加密，当然这所有都会治理在对立元数据服务侧。
问答
Q：connection 工作与业务工作解耦导致元数据抵触的问题如何解决？
A：湖格局广泛提供了 MVCC 版本控制体系，通过多版本控制和最初的 commit 可能解决该问题。
Q：对于半结构化和非结构化的元数据管理是否有相干实践经验？
A：半构造的数据，次要利用 JSON 或一些简单的数据结构来解决数据存取问题。非结构化的数据大多与机器学习场景相干，后续咱们打算将机器学习的模型对接到元数据上。
Q：Hive Warehouse Connector 的原理是什么？
A：Hive Warehouse Connector 是一层内部数据源的定义。引擎能够通过 Connector 去链接内部数据源。
Q：如何让 Spark SQL 利用 Hive 自身的权限？
A：目前开源社区暂无解决方案。但在阿里云上，Hive 和 Spark SQL 有统一的鉴权。**\
Q：湖和仓的元数据能在一个视图里查看吗？
A：目前，阿里云上还未开发此性能，但在一些数据开发平台上能够，比方 DataWorks。
Q：元数据服务是每个租户有独立的服务实例还是大家共享元数据服务？
A：是多个租户共享元数据服务，包含底层存储应用同一个 table store 实例，只是存储在不同的 table store 分区上。在同一个租户内应用 catalog 做 namespace 隔离，每一个 catalog 能够有本人的权限。
Q：DLF 与数据湖格局如何配合的？数据多版本在哪一层实现？
A：数据湖格局更多的是以注册或 meta 同步的形式将元数据向 DLF 元数据同步。数据多版本次要依赖底层的数据湖格局自身的能力。
Q：Hologres 的实时指标，如果计算频率很高，是否会导致压力过大？
A：Hologres 反对高并发的数据服务场景和数据分析场景，不同的场景会抉择通过行存或列存来解决问题。
Q：元数据生产过程中，为什么抉择了 StructStreaming 而不是 Flink？
A：两者时效性相差不大，抉择 StructStreaming 次要基于技术栈思考。
Q：元数据性能方面是否有 benchmark 的指标？
A：目前官网暂未透出。因为存储有良好的 scale 能力及计算是无状态的，因而实践上来说整体 QPS 也可能很好的 scale out。然而针对单个 table 分区数仍然存在肯定的下限。
Q：生命周期治理中，触发冻结的因素是什么？
A：目前还未实现主动触发，仅反对用户手动冻结。用户应用之前，会提供一个入口供选择是否进行冻结。
理解更多：
[1] 数据湖构建 Data Lake Formation：https://www.aliyun.com/produc…
[2] 开源大数据平台 EMR：https://www.aliyun.com/produc…
[3] 数据湖揭秘—Delta Lake：https://developer.aliyun.com/…
[4] 数据湖构建—如何构建湖上对立的数据权限：https://developer.aliyun.com/…
[5] 对于 Data Lake 的概念、架构与利用场景介绍：https://developer.aliyun.com/…
[6] 数据湖架构及概念简介：
https://developer.aliyun.com/…