简介:最佳实践,以DLA为例子。DLA致力于帮助客户构建低成本、简单易用、弹性的数据平台,比传统Hadoop至少节约50%的成本。其中DLA Meta支持云上15+种数据数据源(OSS、HDFS、DB、DW)的统一视图,引入多租户、元数据发现,追求边际成本为0,免费提供使用。DLA Lakehouse基于Apache Hudi实现,主要目标是提供高效的湖仓,支持CDC及消息的增量写入,目前这块在加紧产品化中。DLA Serverless Presto是基于Apache PrestoDB研发的,主要是做联邦交互式查询与轻量级ETL。
数据湖当前在国内外是比较热的方案,MarketsandMarkets _(https://www.marketsandmarkets.com/Market-Reports/data-lakes-market-213787749.html)_市场调研显示预计数据湖市场规模在2024年会从2019年的79亿美金增长到201亿美金。一些企业已经构建了自己的云原生数据湖方案,有效解决了业务痛点;还有很多企业在构建或者计划构建自己的数据湖。Gartner 2020年发布的报告显示_(https://www.gartner.com/smarterwithgartner/the-best-ways-to-organize-your-data-structures/)_目前已经有39%的用户在使用数据湖,34%的用户考虑在1年内使用数据湖。随着对象存储等云原生存储技术的成熟,一开始大家会先把结构化、半结构化、图片、视频等数据存储在对象存储中。当需要对这些数据进行分析时,会选择比如Hadoop或者阿里云的云原生数据湖分析服务DLA进行数据处理。对象存储相比部署HDFS在分析性能上面有一定的劣势,目前业界做了广泛的探索和落地。
Wikipedia上说数据湖是一类存储数据自然/原始格式的系统或存储,通常是对象块或者文件,包括原始系统所产生的原始数据拷贝以及为了各类任务而产生的转换数据,包括来自于关系型数据库中的结构化数据(行和列)、半结构化数据(如CSV、日志、XML、JSON)、非结构化数据(如email、文档、PDF、图像、音频、视频)。
从上面可以总结出数据湖具有以下特性:
主要包括五个模块:
对象存储相比HDFS为了保证高扩展性,在元数据管理方面选择的是扁平的方式;元数据管理没有维护目录结构,因此可以做到元数据服务的水平扩展,而不像HDFS的NameNode会有单点瓶颈。同时对象存储相比HDFS可以做到免运维,按需进行存储和读取,构建完全的存储计算分离架构。但是面向分析与计算也带来了一些问题:
上面这些是大家基于对象存储构建数据湖分析方案遇到的典型问题。解决这些问题需要理解对象存储相比传统HDFS的架构区别进行针对性的优化。目前业界做了大量的探索和实践:
由于对象存储面向分析场景具有上面的问题,DLA构建了统一的DLA FS层来解决对象存储元信息访问、Rename、读取慢等问题。DLA FS同时支持DLA的Serverless Spark进行ETL读写、DLA Serverless Presto数据交互式查询、Lakehouse入湖建仓数据的高效读取等。面向对象存储OSS的架构优化整体分为四层:
下面主要介绍DLA FS面向对象存储OSS的优化技术:
在Hadoop生态中使用OutputCommitter接口来保证写入过程的数据一致性,它的原理类似于二阶段提交协议。
开源Hadoop提供了Hadoop FileSystem的实现来读写OSS文件,它默认使用的OutputCommitter的实现是FileOutputCommitter。为了数据一致性,不让用户看到中间结果,在执行task时先把结果输出到一个临时工作目录,所有task都确认输出完成时,再由driver统一将临时工作目录rename到生产数据路径中去。如下图:
由于OSS相比HDFS它的Rename操作十分昂贵,是copy&delete操作,而HDFS则是NameNode上的一个元数据操作。在DLA的分析引擎继续使用开源Hadoop的FileOutputCommitter性能很差,为了解决这个问题,我们决定在DLA FS中引入OSS Multipart Upload特性来优化写入性能。
阿里云OSS支持Multipart Upload功能,原理是把一个文件分割成多个数据片并发上传,上传完成后,让用户自己选择一个时机调用Multipart Upload的完成接口,将这些数据片合并成原来的文件,以此来提高文件写入OSS的吞吐。由于Multipart Upload可以控制文件对用户可见的时机,所以我们可以利用它代替rename操作来优化DLA FS在OutputCommitter场景写OSS时的性能。
基于Multipart Upload实现的OutputCommitter,整个算法流程如下图:
利用OSS Multipart Upload,有以下几个好处:
OSS Multipart Upload中控制用户可见性的接口是CompleteMultipartUpload和abortMultipartUpload,这种接口的语义类似于commit/abort。Hadoop FileSystem标准接口没有提供commit/abort这样的语义。
为了解决这个问题,我们在DLA FS中引入Semi-Transaction层。
前面有提到过,OutputCommitter类似于一个二阶段提交协议,因此我们可以把这个过程抽象为一个分布式事务。可以理解为Driver开启一个全局事务,各个Executor开启各自的本地事务,当Driver收到所有本地事务完成的信息之后,会提交这个全局事务。
基于这个抽象,我们引入了一个Semi-Transaction层(我们没有实现所有的事务语义),其中定义了Transaction等接口。在这个抽象之下,我们把适配OSS Multipart Upload特性的一致性保证机制封装进去。另外我们还实现了OSSTransactionalOutputCommitter,它实现了OutputCommitter接口,上层的计算引擎比如Spark通过它和我们DLA FS的Semi-Transaction层交互,结构如下图:
下面以DLA Serverless Spark的使用来说明DLA FS的OSSTransactionalOutputCommitter的大体流程:
引入DLA FS的Semi-Transaction,有两个好处:
用户反馈OSS请求费用高,甚至超过了DLA费用(OSS请求费用=请求次数×每万次请求的单价÷10000)。调查发现,是因为开源的OSSFileSystem在读取数据的过程中,会按照512KB为一个单位进行预读操作。例如,用户如果顺序读一个1MB的文件,会产生两个对OSS的调用:第一个请求读前512KB,第二个请求读后面的512KB。这样的实现就会造成读大文件时请求次数比较多,另外由于预读的数据是缓存在内存里面的,如果同时读取的文件比较多,也会给内存造成一些压力。
因此,在DLA FS的实现中,我们去掉了预读的操作,用户调用hadoop的read时,底层会向OSS请求读取从当前位置到文件结尾整个范围的数据,然后从OSS返回的流中读取用户需要的数据并返回。这样如果用户是顺序读取,下一个read调用就自然从同一个流中读取数据,不需要发起新的调用,即使顺序读一个很大的文件也只需要一次对OSS的调用就可以完成。
另外,对于小的跳转(seek)操作,DLA FS的实现是从流中读取出要跳过的数据并丢弃,这样也不需要产生新的调用,只有大的跳转才会关闭当前的流并且产生一个新的调用(这是因为大的跳转读取-丢弃会导致seek的延时变大)。这样的实现保证了DLA FS的优化在ORC/Parquet等文件格式上面也会有减少调用次数的效果。
基于对象存储OSS的存储计算分离的架构,通过网络从远端存储读取数据仍然是一个代价较大的操作,往往会带来性能的损耗。云原生数据湖分析DLA FS中引入了本地缓存机制,将热数据缓存在本地磁盘,拉近数据和计算的距离,减少从远端读取数据带来的延时和IO限制,实现更小的查询延时和更高的吞吐。
我们把缓存的处理逻辑封装在DLA FS中。如果要读取的数据存在于缓存中,会直接从本地缓存返回,不需要从OSS拉取数据。如果数据不在缓存中,会直接从OSS读取同时异步缓存到本地磁盘。
这里以DLA Serverless Presto来说明如何提高DLA FS的local Cache的命中率提高。Presto默认的split提交策略是NO\_PREFERENCE,在这种策略下面,主要考虑的因素是worker的负载,因此某个split会被分到哪个worker上面很大程度上是随机的。在DLA Presto中,我们使用SOFT\_AFFINITY提交策略。在提交Hive的split时,会通过计算split的hash值,尽可能将同一个split提交到同一个worker上面,从而提高Cache的命中率。
使用\_SOFT\_AFFINITY\_策略时,split的提交策略是这样的:
客户在使用DLA过程中,通常使用DLA Serverless Spark做大规模数据的ETL。我们用TPC-H 100G数据集中的orders表进行写入测试,新建一个以o\_ordermonth字段为分区的orders\_test表。在Spark中执行sql:"insert overwrite table \`tpc\_h\_test\`.\`orders\_test\` select * from \`tpc\_h\_test\`.\`orders\`"。使用同样的资源配置,使用的Spark版本一个为开源Spark,另外一个为DLA Serverless Spark,将它们的结果进行对比。
从图中可以得出:
DLA客户会使用DLA的Serverless Presto对多种格式进行分析,比如Text、ORC、Parquet等。下面对比基于DLA FS以及社区OSSFS在1GB Text及ORC格式的访问请求次数。
1GB Text文件分析的请求次数对比
我们针对社区版本prestodb和DLA做了性能对比测试。社区版本我们选择了prestodb 0.228版本,并通过复制jar包以及修改配置的方式增加对oss数据源的支持。我们对DLA Presto CU版512核2048GB通社区版本集群进行了对比。
测试的查询我们选择TPC-H 1TB数据测试集。由于TPC-H的大部分查询并不是IO密集型的,所以我们只从中挑选出符合如下两个标准的查询来做比较:
按照这两个标准,我们选择了对lineitem单个表进行查询的Q1和Q6,以及lineitem和另一个表进行join操作的Q4、Q12、Q14、Q15、Q17、Q19和Q20。
可以看到Cache加速能管理在这几个query都有明显的效果。
最佳实践,以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分析、数据科学等多种业务场景。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
在默认情况之下,如果在Canvas之中将某个物体(源)绘制在另一个物体(目标)之...
简介: 6月4日,以“开启分布式云新时代”为主题2021云边协同大会在北京举行,本...
作者:Joe Seifi 译者:前端小智 移动: https://mp.weixin.qq.com/s/p5... 有梦...
背景 在公司参与一个原生APP和h5混合开发的项目,本人在项目中负责h5部分,现将...
一、虽然有的属性是boolean类型,但仍旧建议按照XHTML书写(属性名=属性值)格式...
折叠式卡片布局在PC版网站中可能不常见,但是在手机版,小屏幕的网页浏览会大发...
前言 Canvas绘制多变形非常简单,只要懂得Canvas路径 + 简单的初中数学知识即可...
1、纯工具操作步骤,懂代码更容易 划线就是不符合国人的审美观念,看着就别扭,...
1.先瞧瞧效果: 2.代码是这样的: img src=images/circle.png alt= id=circle/@m...
本文没有咬文嚼字的地方,只是一个配色技巧的分享,十分简单,简单到流泪,但或...