数据湖当前在国内外是比较热的方案 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三种开放模式 同时提供元数据自动发现服务一键异步构建元数据。下面是各个模块的介绍
可以看出在对接多种数据源以及数据集成方式方面提供了友好的开放性 目前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目录结构按照典型的数仓结构 库、表、分区模式规划 那么在分区识别及表识别上面会有固定的规则 这样可以对上面的算法遍历过程剪枝 分区间的采样率进一步减少 且容错率更高。数仓模式的目录规划需要如下
在大数据场景中 分区是用于提升性能非常常见的方法 合理划分分区有利于计算引擎过滤掉大量无用的数据从而提升计算性能。但是如果分区非常多 比如单表数百万的分区 那么计算引擎从元数据服务查询分区所需要的时间就会上升 从而使得查询的整体时间变长。比如我们客户有张表有130多万分区 一个简单的分区过滤查询元数据访问这块就花了4秒以上的时间 而剩下的计算时间却不到1秒
?
针对这个问题 我们设计开发出了一种叫做“分区映射”的功能 分区映射让用户指定分区的规则 然后具体每个SQL查询的分区会直接通过SQL语句中的查询条件结合用户创建表时候指定的规则直接在计算引擎中计算出来 从而不用去查询外部的元数据 避免元数据爆炸带来的性能问题。经测试 上述场景下 利用分区投影生成分区需要的时间降为1秒以下 大大提升查询效率。
可以看到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分析、数据科学等多种业务场景。
欢迎大家关注我们?
本文转自网络，原文链接：https://developer.aliyun.com/article/783235
相关文章
精彩导读
热门资讯