简介： 作者：沐远、明惠
背景
数据湖以后在国内外是比拟热的计划，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剖析、数据迷信等多种业务场景。
原文链接
本文为阿里云原创内容，未经容许不得转载。