一、背景概述
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进行集成，可以实现工作流，定时调度等管理。
在上表中，我们在集群运维、性价比、作业开发等方面对比了两种形态的差异。从使用体验上，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）做在线分析，也会对历史数据做复杂分析和机器学习，挖掘游戏玩家的使用规律。