一、背景概述
1.1 什么样的客户需要数据湖
在数据处理领域,数据湖相对来说是一个比较新的概念,它的提出可以很好地帮助企业应对当前数据场景越来越多、数据结构越来越复杂、数据处理的需求越来越多样化的问题。传统的单机数据库技术倾向于大一统,一个数据库可以解决数据存储、在线交易、在线分析、离线报表等功能,好处是简单,数据只有一份,缺点是各个功能都做了取舍,很难解决规模的问题。为了突破数据规模的瓶颈,大数据技术更倾向于针对单独领域做深度定制,比如海量文件存储使用HDFS、海量对象存储使用OSS/S3、宽表存储使用BigTable/HBase、嵌套数据使用MongoDB、大规模TP数据使用PolarDB、大规模AP数据使用ADB/Clickhouse、日志数据使用LogService等等。
在很多企业里面,不同的部门业务不同,采用的数据方案也不同。在企业发展的前期,更多是靠业务模式驱动、流量驱动,数据复杂度的问题还不明显,后期则需要精细化运营、向数据要红利,数据管理的难度就成为企业的痛点。数据湖的出现可以很好地解决这个痛点,这也是为什么各个云厂商都推出了数据湖产品,数据湖产品和解决方案越来越得到客户的认可。Gartner 2020年发布的报告显示目前已经有39%的用户在使用数据湖,34%的用户考虑在1年内使用数据湖。
1.2 Aliyun DLA数据湖整体方案
Aliyun数据湖分析(DLA)产品提供了数据湖的一站式解决方案。OSS对象存储采用KV的技术架构,可以实现无限扩展,是公认的数据湖存储底座。用户可以通过离线ETL和在线增量ETL将在线数据和实时增量数据,同步到OSS中,然后对数据做深度的计算和分析。用户也可以直接访问这些在线库,做在线的联邦分析。为了方便用户管理数据湖中的数据,我们提供了统一的数据湖管理方案。数据湖管理可以统一存储数据湖中数据的元信息给计算引擎使用,另外还提供元数据动态爬取功能,可以动态解析OSS数据目录结构和数据格式,省去了用户手动创建表和分区的工作。DLA同时提供了SQL和Spark两个引擎,SQL基于Presto实现,可以实现在线分析,Spark可以实现用户自定义代码和复杂计算逻辑。同时,DLA跟DMS和QuickBI进行了深度集成,方便用户实现更丰富的开发和管理逻辑。
二、DLA Serverless Spark架构解析
2.1 DLA Spark为什么是云原生 + Serverless
2.1.1 数据湖天然存储计算分离
数据湖技术处理的对象是用户已存在的所有的数据。这里提到两个关键定语“已存在的”和“所有的”。要处理好“已存在的”原始数据,最好的方式显然不是先将其导入到数据仓库中,最好是能够原地分析,使用单独的计算资源来计算分析各种类型存储系统中的数据,这就是存储计算分离的架构。存储计算分离的架构能够做到存储和计算的分层弹性,存储可以无限扩展,计算能够按需弹性调度。这里提到了弹性计算,计算的弹性可以分很多层次:
- 集群级弹性:用户可以按需购买ECS并部署集群,然后后再执行计算任务,任务执行完之后再释放掉集群;
- 作业级弹性:用户每个作业都是单独的计算资源,作业执行完之后立即释放;
- 作业内弹性:一个任务在执行过程中,不同的阶段所需要消耗的资源不同,典型地,分布式作业出现长尾时,大部分资源都是空闲的,此时可以将空闲资源释放掉;
- 容器内弹性:计算任务的进程在执行过程中不同时段所需要的资源不同,是否可以做到动态调节;
弹性的粒度越细,资源的利用率越高,成本也就越低。相对于传统IDC,云的最大的优势之一就是弹性,数据湖天然是存储计算分离的,跟云弹性的能力十分匹配,数据湖场景下,云原生 + 弹性是必然趋势。
2.1.2 Serverless是云的趋势
Serverless是业内公认的云发展的一个趋势。其实不难理解,从IDC自建到搬站上云再到Serverless化符合技术和客户需求发展的规律。
在云最初产生的时候,大家把云计算基本等同于虚拟化技术,客户最普遍的需求是将线下的站点搬上云,用户把云当做对线下硬件的替换,企业的IT研发、运维大体跟上云前一致。用户对大数据系统,比如Hadoop集群,也类似,把线下集群换成虚拟集群,再由专门团队运维大数据集群。在云市场发展的第一阶段,这种模式有用户习惯的因素,也有性能、成本等的因素,自建跟云产品在性能上差距不太大,在成本上甚至更便宜,客户也拥有一定的掌控感。然而,云的技术会继续往精细化深入发展,从资源共享的角度来看,每套Hadoop集群都有一套自己的管控,这些管控包括Master节点,Core节点上面的守护进程,以及配套的监控、运维管理等系统。这些资源和人力投入实际上对企业来说都只是成本,并不产生真正的计算价值。
随着云技术的发展,Serverless形态可以很好的解决企业在第一阶段遇到的问题,企业只需要关心自己的业务开发,只为真正参与计算的资源付费,云产品把管控的部分统一管理起来,边际成本可以做到很低。另外,云产品会深度扎根于云基础设施,对性能、弹性、使用体验等做持续深入优化,相对于第一阶段的用户自建模式可以实现数倍的性价比提升。最后,随着云产业的发展,云产品会越来越标准化,客户也不必担心被云绑定的问题。在云市场进入第二阶段,Serverless形态的产品让企业更专注于自身业务,进一步降低运维和资源成本,让开发者拥有更好的使用体验以及更低的入门门槛。
2.1.3 Spark一站式解决数据湖计算需求
“所有的”意味着数据的来源途径多种多样,存储位置多种多样,数据格式多种多样。这就要求计算引擎可以支持所有数据类型,并且可以很方便的做分析、计算,因为数据是“已存在的”,Schema只能在读取的时候才能确定,而不能依赖用户把表都提前建好。Spark非常适合数据湖场景:
- Spark本身内置了十分丰富的数据源连接器,接口也很方便扩展;
- Spark既支持使用SQL,又支持编写多种语言的DataFrame代码,兼具易用性和灵活性;
- Spark一站式引擎能力,同一个引擎同时提供SQL、流、机器学习、图计算的能力;
DLA团队将Serverless、云原生、Spark技术优势深度整合到一起,提供Serverless Spark产品,兼具三者优势。下面我们将对Serverless Spark产品架构进一步解析。
2.2 自建Spark集群 VS Serverless Spark
上图中左半部分是传统最常见的集群版Spark,右边是Serverless Spark。集群版Spark大家都比较熟悉,每个用户一个集群,集群内部拥有一套完整的Spark管控,用户使用方式上跟传统IDC模式一致。
Serverless Spark将管控完全多租户化,相对于传统的集群模式,Serverless Spark抽象出一个虚拟集群的概念。虚拟集群只是承载用户对作业进行控制的一些配置,包括网络的配置、安全隔离的配置、计算资源Quota的配置、作业通用参数的配置等。由于是虚拟集群,所以集群创建基本都可以做到秒级完成。用户创建完虚拟集群之后,就可以往虚拟集群提交作业,去访问用户在各个存储引擎中的数据。
Serverless Spark在弹性能力上基于Aliyun Kubernetes云原生技术深度定制,调度层可以实现秒级拉起,一分钟可以并行拉起300个计算节点,后续还会持续优化。Serverless Spark控制服务实现了对云资源、作业、库表列元数据、租户、安全等管理,对上提供阿里云OpenAPI,用户可以通过OpenAPI实现作业的提交和管理。另外Serverless Spark会跟其他云产品深度集成,进一步丰富用户的使用场景,目前Serverless Spark已经跟DMS进行集成,可以实现工作流,定时调度等管理。
对比维度 | 自建Hadoop集群 | Serverless版 |
---|---|---|
内置存储 | HDFS | 数据湖存储OSS |
集群形态 | ECS集群,需配置Master、Core规格 | 虚拟集群,只需配置资源quota |
集群管理 | 扩缩容、升降配 | quota调整,参数配置 |
售卖形态 | 实例型,集群粒度,按ECS规格售卖 | 服务型,按作业实际使用CU*时收费 |
资源弹性 | 集群级别 | 作业级弹性 |
性价比 | 低:管控开销+资源空闲开销 | 高:按需付费 |
维护成本 | 高:运维团队维护集群 | 低:管理员分配资源 |
作业管理 | Livy、脚本、控制台、定时调度、作业编排 | OpenAPI、脚本、控制台、定时调度、作业编排 |
租户支持 | 依赖开源,配置复杂 | Aliyun RAM |
学习成本 | 高:需要先学习集群管理与配置 | 低:只需要学习Spark开发 |
在上表中,我们在集群运维、性价比、作业开发等方面对比了两种形态的差异。从使用体验上,Serverless Spark可以做到开箱即用,一分钟就可以跑通一个Spark作业;从成本上,由于将管控完全多租户化,用户不需要承担这部分额外开销,只需要实际使用付费;从运维方面,一个企业中一个管理员就可以实现整体管理工作,大大降低运维成本。
三、DLA Serverless Spark性价比
3.1 1TB Terasort DLA Spark vs 自建Hadoop 性价比对比
我们先对比下1TB数据情况下,数据湖方案跟传统Spark集群方式的性价比。相关配置说明如下:
- TeraSort输入1TB + shuffle大约1TB + 输出1TB,作业每天跑一次。
- Hadoop集群配置:单Master(4c8g) + 5个Core(8c32g),Core节点配置4块500GB的高效云盘。一般高效云盘采用2备份的HDFS配置。这里存储空间是4 500GB 5 / 2 = 5TB。
- Serverless Spark采用40CU + 2TB OSS。
对比结果如右图所示,作业性能上Serverless Spark跟Hadoop基本持平,但是性价比差异非常大,DLA Serverless Spark会节约80%。也就是会有4-5倍的性价比提升。
需要说明的是:
- Hadoop集群配置是一个总容量5TB集群的典型配置,一般情况下集群不能把磁盘都用满,要留一定buffer,否则系统可能会出现各种空间不足问题。
- Serverless Spark完全按需使用存储和计算资源。
- Serverless Spark对OSS访问实现了深度定制优化,性能相比于社区提升1倍左右。
3.2 10TB Terasort DLA Spark vs 自建Hadoop 性价比对比
对于更大规模数据,比如10TB,对比结果如上图所示。相关配置说明:
- TeraSort输入10TB + shuffle大约10TB + 输出10TB。作业每天跑一次。
- Hadoop集群配置:单Master(4c8g) + 5个Core(16c64g),Core节点配置8 5.5TB的本地盘。一般本地盘采用3备份的HDFS配置。这里存储空间是5 8 * 5.5TB / 3 = 73TB。
- Serverless Spark采用80CU + 50TB OSS。
我们发现性能上DLA Spark提升了1倍,成本反而降低了一半,性价比提升4倍。
需要说明的是:
- Hadoop集群采用的是大数据量场景下的典型配置,采用本地盘D1机型,成本相对于云盘要便宜。由于本地盘机型要求空间比较大,16c64g的只能配置44TB的本地盘,考虑到Hadoop集群的本地盘通常不能打太满,为了公平起见,我们采用OSS的空间是50TB。
- 在分析性能时发现,在10TB场景下,本地盘的存储和shuffle之间会有IO带宽上明显的争用,而Serverless Spark计算节点自带essd云盘,将shuffle盘完全独立,对性能提升有较大的贡献。
3.3 Serverless Spark访问用户自建Hadoop
用户可以将自建Hadoop和Serverless Spark混合使用,用户Hadoop集群在高峰期需要更多的计算资源,用户可以直接提交Serverless Spark来实现对计算弹性的需求。由于Serverless Spark可以做到直接跟用户VPC打通,可以直接使用内网带宽,经过对比两者的性能基本持平。
四、使用场景
面向数据湖中的各种各样的数据,Spark可以用于如下场景:
- 生态打通:Spark的多数据源能力,提供外部数据源批量入库、联邦分析能力;DLA Spark会跟云上数据源做深度集成优化,解决稳定性问题并提升性能;
- 算法及用户可编程:支持python、java、scala、R、SQL多语言,支持复杂的数据过程处理(类似PL/SQL)、机器学习等;
- 离线数仓(复杂分析):支持复杂离线分析,提供天/月级别的报表等;
- 半结构化/非结构化处理:搭配HDFS/OSS存储为数据库添加非结构化数据存储处理能管理(CSV、XML、Parquet多种存储);
- 离线ETL:可以用于各存储引擎之间的数据转换、清洗、归档等操作;
- 实时计算:Spark Streaming + Hudi可以实现数据实时转存,实现在不影响在线库稳定性情况下,对实时数据的复杂分析;Spark Streaming实时ETL将多个MySQL大表,合并为一个ADB宽表,避免大表在线join,提高在线分析性能。
上图是某游戏公司使用DLA解决数据湖场景问题的方案。用户要对在线库RDS做分析,但又怕影响RDS的稳定性,于是选择采用DLA一键建仓功能将其同步到OSS里面转为列存;用户游戏APP的日志数据会接入到Kafka里面,然后通过Spark Streaming实时写入到OSS,数据采用Hudi增量数据湖格式。数据流入到OSS后,用户会对数据使用DLA SQL(Presto)做在线分析,也会对历史数据做复杂分析和机器学习,挖掘游戏玩家的使用规律。
五、总结与展望
针对用户面临的越来越多的数据湖场景典型问题,阿里云DLA产品提供了一体化解决方案,从数据湖管理到数据湖分析和计算。相对于在线引擎,Spark更适合弹性计算架构,可以跟云原生的弹性能力深度整合起来。从传统IDC到搬站上云到完全Serverless化,这条路径已经被越来越被认可为云技术的发展路径。DLA Spark采用完全云原生 + Serverless形式,相对于传统的自建Hadoop在性价比上拥有数倍的优势。
未来,DLA Serverless Spark会面向数据湖场景做进一步深度优化:
- 更便宜:实现更细粒度的弹性继续降低成本;
- 更快:优化Spark内核本身,特别是跟云存储之间做深入定制优化,提升引擎性能;
- 更好用:降低Spark开发难度,更进一步提升用户使用体验。