高端网站建设案例,咖啡网站源码,免费广告设计软件,php mysql开发的网站开发简介#xff1a; 作者#xff1a;沐远、明惠
背景
数据湖当前在国内外是比较热的方案#xff0c;MarketsandMarkets市场调研显示预计数据湖市场规模在2024年会从2019年的79亿美金增长到201亿美金。一些企业已经构建了自己的云原生数据湖方案#xff0c;有效解决了业务痛点…简介 作者沐远、明惠
背景
数据湖当前在国内外是比较热的方案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 MetaDLA内置的Serverless Spark、Presto、Hudi支持通过Client模式对接DLA Meta支持多租户及权限控制基于UID的多租户机制进行权限的隔离通过GRANTREVOKE进行账号间的权限管理。支持水平扩展为了满足海量元数据的管理服务本身是可以水平扩展同时底层使用RDSPolarDB的库表拆分技术支持存储的扩展。元数据发现服务当数据入湖时没有关联元数据可以通过元数据发现服务一键自动关联元数据。可以看出在对接多种数据源以及数据集成方式方面提供了友好的开放性目前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分析、数据科学等多种业务场景。 原文链接
本文为阿里云原创内容未经允许不得转载。
