关于云原生:深度-面向云原生数据湖的元数据管理技术解析

简介： 作者：沐远、明惠

背景

数据湖以后在国内外是比拟热的计划，MarketsandMarkets 市场调研显示预计数据湖市场规模在 2024 年会从 2019 年的 79 亿美金增长到 201 亿美金。一些企业曾经构建了本人的云原生数据湖计划，无效解决了业务痛点；还有很多企业在构建或者打算构建本人的数据湖，Gartner 2020 年公布的报告显示目前曾经有 39% 的用户在应用数据湖，34% 的用户思考在 1 年内应用数据湖。随着对象存储等云原生存储技术的成熟，一开始大家会先把结构化、半结构化、图片、视频等数据存储在对象存储中。当须要对这些数据进行剖析时，发现短少面向剖析的数据管理视图，在这样的背景下业界在面向云原生数据湖的元数据管理技术进行了宽泛的摸索和落地。

一、元数据管理面临的挑战

1、什么是数据湖

Wikipedia 上说数据湖是一类存储数据天然 / 原始格局的零碎或存储，通常是对象块或者文件，包含原始零碎所产生的原始数据拷贝以及为了各类工作而产生的转换数据，包含来自于关系型数据库中的结构化数据（行和列）、半结构化数据（如 CSV、日志、XML、JSON）、非结构化数据（如 email、文档、PDF、图像、音频、视频）。

从下面能够总结出数据湖具备以下个性：

• 数据起源：原始数据、转换数据
• 数据类型：结构化数据、半结构化数据、非结构化数据、二进制
• 数据湖存储：可扩大的海量数据存储服务

2、数据湖剖析计划架构

当数据湖只是作为存储的时候架构架构比拟清晰，在基于数据湖存储构建剖析平台过程中，业界进行了大量的实际，根本的架构如下：

次要包含五个模块：

• 数据源：原始数据存储模块，包含结构化数据(Database 等)、半结构化(File、日志等)、非结构化(音视频等)
• 数据集成：为了将数据对立到数据湖存储及治理，目前数据集成次要分为三种状态。第一种为间接通过表面的形式关联元数据；第二种为基于 ETL、集成工具、流式写入模式，这种形式间接解决数据可能感知 Schema，在写入数据的过程中同时创立元数据；第三种为文件间接上传数据湖存储，须要预先异步构建元数据
• 数据湖存储：目前业界次要应用对象存储以及自建 HDFS 集群
• 元数据管理：元数据管理，作为连贯数据集成、存储和剖析引擎的总线
• 数据分析引擎：目前有丰盛的剖析引擎，比方 Spark、Hadoop、Presto 等，他们通常通过对接元数据来取得数据的 Schema 及门路；同时比方 Spark 也反对间接剖析存储门路，在剖析过程中进行元数据的推断

咱们能够看到元数据管理是数据湖剖析平台架构的总线，面向数据生态要反对丰盛的数据集成工具对接，面向数据湖存储要进行欠缺的数据管理，面向剖析引擎要可能提供牢靠的元数据服务。

3、元数据管理面临的挑战

元数据管理如此重要，然而以后开源的计划不够成熟，常常会听到大家对于元数据管理相干的探讨，比方：

• 有 10 来个数据存储系统，每种都去对接适配，每次都要配置账密、门路，真麻烦，有没有对立的视图？
• 一个有 200 个字段的 CSV 文件，手动写出 200 个字段的 DDL 真的好累？JSON 增加了字段每次都须要手动解决下吗？
• 我的业务数据，是否有被其他同学删库跑路的危险？
• 分区太多了，每次剖析在读取分区上竟然占用了那么多工夫？
• …..

4、业界数据湖元数据管理现状

下面这些是大家在对数据湖进行治理剖析时遇到的典型问题。这些问题其实都能够通过欠缺的元数据管理系统来解决，从元数据管理的视角能够总结为：

• 如何构建数据的对立治理视图：面向多种数据源须要有一套对立的数据管理模型，比方通过 JDBC 连贯数据库、通过云账号受权治理对象存储文件、一套 Serde 治理解决不同的数据格式解决形式等。
• 如何构建多租户的权限治理：如果全域数据都应用数据湖计划治理，企业多部门研发人员独特应用数据湖开掘价值，然而短少无效的数据租户及权限隔离，会产生数据危险；
• 如何自动化的构建元数据：通过 ETL 模式的数据集成工具写入数据湖存储时，对应工具晓得数据 Schema 能够被动建元数据，这样就须要元数据服务有欠缺的凋谢接口。然而在某些场景数据文件间接上传到 OSS 存储，且文件量微小、数据动静增长变动；这种状况须要有一套被动推断提取元数据的服务，做到 Schema 感知以及增量辨认。
• 如何提供面向剖析的优化能力：比方海量分区的高效加载等。

针对这些问题业界在做了大量的摸索和实际：

• Hive Metastore：在 Hadoop 生态为了构建对立的治理视图，用户会在本人的 Hadoop 集群搭建 HMS 服务。
• AWS Glue Meta：提供多租户的对立数据湖元数据管理服务，配套 Serverless 的元数据爬取技术生成元数据。相干性能免费。
• Aliyun DLA Meta: Meta 兼容 Hive Metastore，反对云上 15+ 种数据数据源（OSS、HDFS、DB、DW）的对立视图，提供凋谢的元数据拜访服务，引入多租户、元数据发现、对接 HUDI 等能力。DLA Meta 谋求边际老本为 0，收费提供应用。上面也将重点介绍 DLA Meta 的相干技术实现。

二、云原生数据湖的元数据管理架构

为了解决下面这些挑战，阿里云云原生数据湖剖析服务 DLA 的元数据管理，反对对立的多租户元数据管理视图；数据模型兼容 Hive Metastore；提供阿里云 OpenAPI、Client、JDBC 三种凋谢模式；同时提供元数据主动发现服务一键异步构建元数据。上面是各个模块的介绍：

• 对立元数据视图：反对 15+ 中数据源，OSS、HDFS、DB、DW 等；并兼容 Hive Metastore 的数据模型，比方 Schema、View、UDF、Table、Partition、Serde 等，敌对对接 Spark、Hadoop、Hudi 等生态；
• 丰盛的凋谢模式：反对阿里云 OpenAPi、Client、JDBC 三种接口凋谢模式，不便生态工具及业务集成 DLA Meta，比方能够开发 Sqoop 元数据插件对接 OpenAPI，同步数据时构建元数据；目前开源 Apache Hudi 反对通过 JDBC 形式对接 DLA Meta；DLA 内置的 Serverless Spark、Presto、Hudi 反对通过 Client 模式对接 DLA Meta；
• 反对多租户及权限管制：基于 UID 的多租户机制进行权限的隔离，通过 GRANT&REVOKE 进行账号间的权限治理。
• 反对程度扩大：为了满足海量元数据的治理，服务自身是能够程度扩大，同时底层应用 RDS&PolarDB 的库表拆分技术，反对存储的扩大。
• 元数据发现服务：当数据入湖时没有关联元数据，能够通过元数据发现服务一键主动关联元数据。

能够看出在对接多种数据源以及数据集成形式方面提供了敌对的开放性，目前 Apache Hudi 原生对接了 DLA Meta；在剖析生态方面反对业界通用的数据模型规范(Hive Metastore)；同时服务自身具备多租户、可扩大的能力满足企业级的需要。

三、元数据管理核心技术解析

上面次要介绍 DLA Meta 对于元数据多租户、元数据发现、海量分区治理三方面的技术实际，这几块也是目前业界外围关注和摸索的问题。

1、元数据多租户治理

在大数据体系中，应用 Hive MetaStore（上面简称 HMS）作为元数据服务是十分广泛的应用办法。DLA 作为多租户的产品，其中一个比拟重要的性能就是须要对不同用户的元数据进行隔离，而且须要领有残缺的权限体系；HMS 自身是不反对多租户和权限体系。阿里云 DLA 重写了一套 Meta 服务，其外围指标是兼容 HMS、反对多租户、反对残缺的权限体系、同时反对存储各种数据源的元数据。

多租户实现

为了实现多租户性能，咱们把每张库的元数据和阿里云的 UID 进行关联，而表的元数据又是和库的元信息关联的。所以基于这种设计每张库、每张表都是能够对应到具体的用户。当用户申请元数据的时候，除了须要传进库名和表名，还须要将申请的阿里云 UID 带进来，再联合上述关联关系就能够拿到相应用户的元数据。每个元数据的 API 都有一个 UID 参数，比方如果咱们须要通过 getTable 获取某个用户的表信息，整个流程如下：

下面的 ACCOUNT 是 DLA 中存储用户账户信息的表；DBS 和 TBLS 是用于存储元数据的表。虚线代表他们之间的关联关系。

权限体系

咱们晓得，个别大型的企业会存在多个不同部门，或者一个比拟大的部门须要辨别出不同的用户，这些用户之间又须要共享一些资源。为了解决这个问题，DLA 将阿里云 UID 作为主账号，DLA userName 作为子账号来区别每个用户，同一个阿里云 UID 上面的不同子用户拜访的资源是有限度的，比方主账号用户能够看到所有的元数据；而个别用户只能看到一部分。为了解决这个问题，DLA Meta 实现了一套残缺的权限体系，用户能够通过 GRANT/REVOKE 对用户进行相干的权限操作。

DLA Meta 中所有对外的元数据 API 都是有权限校验的，比方 Create Database 是须要有全局的 Create 或 All 权限的。只有权限校验通过才能够进行下一步的操作。目前 DLA Meta 权限管制粒度是做到表级别的，能够对用户授予表级别的权限；当然，列粒度、分区粒度的权限咱们也是能够做到的，目前还在布局中。上面是咱们权限校验的解决流程：

因为 DLA Presto 能够兼容 MySQL 权限操作相干，为了升高用户的应用老本，以后 DLA Meta 的权限是与 MySQL 权限是兼容的，所以如果你对 MySQL 的权限体系比拟理解，那么这些常识是能够间接使用到 DLA 的。

2、元数据发现 Schema 推断技术

元数据发现的定位：为 OSS 等存储下面的数据文件主动发现和构建表、字段、分区，并感知新增表 & 字段 & 分区等元数据信息，不便计算与剖析。

从上图能够看出，元数据发现的输出是一个父目录，上面能够蕴含百万级别 OSS 的文件，同时这些文件还在增量的增加。输入为依据 Schema 信息进行聚合生成数目为万级别的表，以及单表万级别分区。元数据主动发现引擎次要包含文件 Schema 识别器、文件表分类器、Meta 同步三块，上面重点介绍 Schema 识别器、以及文件表分类器。

文件 Schema 识别器：这个模块次要用来推断 OSS 下面文件的格局及字段。对于一个文件齐全没有 Schema 信息状况下，首先须要推断出是什么格局，而后还须要推断出具体的字段。整个模块包含文件采样、Schema 识别器两块。测试表明单个文件的 Schema 探测须要 150ms 左右，如果对所有的文件进行全量的辨认，整个效率会比拟低，DLA 元数据发现有一套采样的技术，缩小文件辨认的数量。具体的 Schema 识别器由一组 Schema 推断的策略组成，面对一个没有任何先验信息的文件，通过一一匹配 CSV、JSON、Parquet 等推断器的形式来进行辨认，每种推断器在效率和准确性下面做了大量优化，比方 CSV 外部蕴含了 30+ 种依据表头、分隔符、本义、援用组合的策略，同时字段的辨认应用数据行采样的形式保障准确率的状况下，缩小近程 IO 读取。

文件分类器：因为文件在 OSS 下面是依照目录存储的，当通过 Schema 识别器辨认出了叶子节点目录上面的 Schema 状况后，如果每个叶子节点目录创立一张表，表会很多，治理简单且难以剖析。因而须要有一套文件分类器来聚合生成最终的表。且反对增量文件的 Schema 变更，比方增加字段、增加分区等。上面是整个分类算法过程，依据目录树形的构造，第一步先深度遍历并联合“文件 Schema 识别器”在每个节点聚合子节点的 Schema 是否兼容，如果兼容则把子目录向上合并为分区，如果不兼容则每个子目录创立一张表。通过第一步后每个节点是否能够创立表、分区信息，以及合并后的 Schema 都会存储在节点下面；第二步再次遍历能够生成对应的 Meta 创立事件。

这种通用的算法能够辨认任意目录摆放，然而因为面向海量分区的场景，当时不晓得分区目录是否能够聚合，这样每个目录都须要采样辨认，且在聚合时如果某个分区和其余分区兼容度达不到要求，会拆分生成大量的表，在这种场景下性能个别。如果用户的 OSS 目录构造依照典型的数仓构造，库、表、分区模式布局，那么在分区辨认及表辨认下面会有固定的规定，这样能够对下面的算法遍历过程剪枝，分区间的采样率进一步缩小，且容错率更高。数仓模式的目录布局须要如下：

3、海量分区解决技术

分区投影

在大数据场景中，分区是用于晋升性能十分常见的办法，正当划分分区有利于计算引擎过滤掉大量无用的数据从而晋升计算性能。然而如果分区十分多，比方单表数百万的分区，那么计算引擎从元数据服务查问分区所须要的工夫就会回升，从而使得查问的整体工夫变长。比方咱们客户有张表有 130 多万分区，一个简略的分区过滤查问元数据拜访这块就花了 4 秒以上的工夫，而剩下的计算工夫却不到 1 秒！

针对这个问题，咱们设计开发出了一种叫做“分区映射”的性能，分区映射让用户指定分区的规定，而后具体每个 SQL 查问的分区会间接通过 SQL 语句中的查问条件联合用户创立表时候指定的规定间接在计算引擎中计算出来，从而不必去查问内部的元数据，防止元数据爆炸带来的性能问题。经测试，上述场景下，利用分区投影生成分区须要的工夫降为 1 秒以下，大大晋升查问效率。

基于 OSS 的 Metatable 技术

能够看到 DLA 的分区投影技术升高了海量分区状况下，拜访 Meta 服务的工夫开销，该技术通过计算侧计算分区的办法来躲避掉海量分区的拜访。DLA 目前基于 Apache Hudi 实现 DLA Lakehouse，提供高效的湖仓。其中在海量分区解决这块，Apache Hudi 将表的海量分区映射信息存储在一个 OSS 下面的 Object 外面，这样通过读取若干个 Object 文件能够获取所有的分区信息，躲避拜访 Meta 服务的开销。上面介绍 DLA Lakehouse 基于 Hudi 的 Metatable 技术：

从上图能够看到 DLA Meta 中会存储库、表、分区的信息，应用以后计划 OSS 下面分区目录对应的分区信息会存储在 DLA Meta 服务中，当剖析引擎拜访这张表的时候，会通过 DLA Meta 服务读取大量的分区信息，这些分区信息会从底层的 RDS 中读出，这样会有肯定的拜访开销。如果应用到 DLA Lakehouse 计划，能够将大量的分区映射信息独自存储在基于 OSS 对象的 Hudi Metatable 中，Metatable 底层基于 HFile 反对更新删除，通过 KV 存储形式进步分区查问效率。这样剖析引擎在拜访分区表的时候，能够只在 Meta 中读取库、表轻量的信息，分区信息能够通过读取 OSS 的对象获取。目前该计划还在布局中，DLA 线上还不反对。

四、云原生数据湖最佳实际

最佳实际，以 DLA 为例子。DLA 致力于帮忙客户构建低成本、简略易用、弹性的 数据平台 ， 比传统 Hadoop 至多节约 50% 的老本。其中 DLA Meta 反对云上 15+ 种数据数据源（OSS、HDFS、DB、DW）的对立视图，引入多租户、元数据发现，谋求边际老本为 0，收费提供应用。DLA Lakehouse 基于 Apache Hudi 实现，次要指标是提供高效的湖仓，反对 CDC 及音讯的增量写入，目前这块在加紧产品化中。DLA Serverless Presto 是基于 Apache PrestoDB 研发的，次要是做联邦交互式查问与轻量级 ETL。DLA 反对 Spark 次要是为在湖上做大规模的 ETL，并反对流计算、机器学习；比传统自建 Spark 有着 300% 的性价比晋升，从 ECS 自建 Spark 或者 Hive 批处理迁徙到 DLA Spark 能够节约 50% 的老本。基于 DLA 的一体化数据处理计划，能够反对 BI 报表、数据大屏、数据挖掘、机器学习、IOT 剖析、数据迷信等多种业务场景。

原文链接
本文为阿里云原创内容，未经容许不得转载。