阿里云基于 Spark 的云原生数据湖剖析理论

我不是处男

导读：本文将讨论 spark 和云原生结合的话题，但愿给大家带来对于 Spark 部署的一些新思绪。
全文将环抱上面四点展开：
Spark 与云原生的结合Spark on K8s 原理引见Spark on K8s 在阿里云 EMR 上的理论Serverless Spark 在阿里云 DLF 的理论分享佳宾｜范佚伦阿里云技术专家
编纂整顿｜徐泽厚北京理工大学
出品平台｜DataFunSu妹妹it
01
Spark 与云原生的结合

1. 传统 Spark 集群的痛点
① 部署运维难度大
目前咱们大家所相熟的Spark集群都是在传统的 Hadoop 集群外部，好比CDH，或者初期的云上的EMR集群，这类全家桶式的部署形式的益处在于组件对比丰硕，然而部署组件单一，无论是装置、部署、运维都对比繁杂，带来对比大的运维和人力本钱。
② 弹机能力缺乏
这类部署模式需求对比固定的资源预估，好比跑功课需求多少 master，多少worker，都要提前筹备好，还要事前实现环境的装置和组件的部署。这样，弹性扩容的效力就对比差。
③ 存储与计算耦合
传统 Spark 集群既要部署HDFS 的 data node，也要部署 YARN 的 node manager，这样虽然数据不乱性可能好一些，然而假如存储节点需求扩容的时分，象征着 CPU 和内存也要扩容，有可能会带来一些资源的挥霍和使用率的一些问题。

2. Spark 与云原生结合的劣势
假如把 Spark 部署在云上，而且能充沛利用云原生的特征，能够带来更好的成果。甚么是云原生？不同组织对云原生都有一些不同的定义，关于云原生中咱们可能接触到像容器化、微办事、DevOps等概念。实际上这些都是技术，但不是云原生的定义。我以为云原生就是代表着经过一些技术能够充沛利用到云上的云计算资源和办事的劣势，而后高效地在云上部署。由于在云上的部署就代表了在云上的海量资源均可以用到，能够按需使用。Spark 功课能够结合到这些特征，来完成对功课本钱和效力的优化。
① 弹性劣势
和云原生结合最大特征仍是弹性，利用云原生的技术能够完成秒级别的弹性，更细的按量付费。
② 功课为核心
要完成更好的弹性，也象征着环境的部署更矫捷了。好比用容器镜像的技术， Spark 运转环境就是和容器镜像相干，而与集群有关了。功课版本对环境的依赖，均可以经过不同镜像来疾速地进行区别，防止得多依赖冲突的问题。
③ 更低运维本钱
Spark 运转依赖了得多 Hadoop 的得多组件，然而云上其实有得多这些组件的代替品。好比能够用对象存储 OSS 来代替 HDFS，用 DLF 元数据来去替代 Hive Meta。这些形式均可以增加组件数量，增加部署的繁杂度，升高运维本钱。
02
Spark on K8s 原理引见
接上去详细引见 Spark 和云原生结合的两种状态。
首先引见 Spark on K8s，由于 K8s 是云原生的首要代表技术。这个章节将引见 Spark on K8s 的原理和部署形式。

1. Spark 的集群部署模式
Spark 获得运转时资源是经过 Cluster Manager 的对象的。目前 Spark 民间反对四种部署模式。
① Standalone。对比简略，Spark 不依赖内部调度器，间接就能独立部署起来。实际中个别在测试用得对比多，很少在出产环境用。
② YARN。就是后面提到的在 Hadoop 集群中跑，这个也是业界最多见的部署模式，大部份 Spark job 也都是跑在 YARN 外面的，生态也对比丰硕。
③ Mesos。跟着 K8s 的衰亡，目前曾经对比少有人用了。
④ Kubernetes。把 Spark 功课跑在 K8s 集群里。跟着云原生趋向热度对比高，当初也有更多的用户在尝试用这类部署模式跑 Spark 功课。

2. Spark on K8s 的部署架构
Spark on K8s 通常会有两种部署模式。
① 使用原生 spark-submit
Spark 民间文档里给出了一个规范的 spark-submit 的形式。这类形式和大家罕用的spark-submit 的形式差未几，需求 client 端装置一个 Spark 环境，同时还要装 kubectl，用于衔接 K8s 集群。和正常 spark-submit 同样，在提交命令里需求额定指定一下 K8s 的 master 的地址和镜像的地址，这样 Spark 就会自动把功课提交到 K8s 集群里，集群里也不需求装任何的环境配置就能跑起来。

② 使用 spark-on-k8s-operator
除了民间文档这类形式以外，还有一个 spark-on-k8s-operator 的模式。这个 Spark operator 是 Google 的一个开源名目（链接：http://GitHub.com/GoogleCloudPlatform/spark-on-k8s-operator），它能够让 Spark 功课作为一种 CRD（Custom Resource Definition），用 yaml 的形式来形容，间接提交一个 yaml 文件就可以提交 Spark 功课了。这类形式其实是 spark-submit 民间形式的一种封装罢了，然而它更合乎咱们作为用户的习气，由于 K8s 其余的对象也都是用这类的 yaml 形式去提交的。
除此以外 operator 也做了一些功课办理才能的加强。好比能够做按时调度、功课监控，以及 pod 加强等等，但这是需求在 K8s 集群里提前装置一个常驻 operator 能力完成的，不像后面的 spark-sumit 的形式不需求常驻办事就能间接跑起来。

3. Spark on K8s 部署架构——比较
简略比较一下这两种形式。spark-submit形式是对老用户对比敌对，迁徙难度对比低，并且交互式功课间接就可以跑起来。Spark operator做了一些完美，在功课办理方面做了得多功用，能够自动去创立 service ingress，能够自动去清算残留的 pod，而且反对重试等等。整体来讲就是这两种形式各无利弊。此外咱们也提供了一种提交形式，能够结合这两个优点，前面会进行引见。

4. Spark on K8s 社区停顿
Spark 民间在 Spark 2.3 正式反对 native on K8s。以前有人尝试过在 K8s 上用Standalone 或者 YARN 模式来跑，不外都不是 native on K8s，缺陷对比多。Spark 2.3 反对之后，在 2.4 有了大量的功用优化，然而真正失掉完美是在 Spark 3 之后，Spark on K8s GA 是 Spark 3.1（general available，正式可用，以前都是叫experimental）。假如想要尝试在 K8s 里跑 Spark 仍是选择 Spark 3 对比好，由于 Spark 2 功用和不乱性都有些缺乏，好比 Spark 3 的一个首要特性是反对了 K8s 的 dynamic allocation，此外还反对了自定义 pod template，晋升了灵敏性。
总体来看，近几年社区外面对于 K8s 有得多新版本公布，阐明比来社区在 K8s 仍是对比活泼的，愈来愈多的人在使用这方面的功用。
接上去看一下Spark 3.3 有哪些对于 K8s 的优化。

5. Spark 3.3 新特性引见
Spark 3.3 在 K8s 方面次要有两个重点特性公布。
① Executor Rolling in K8s environment
这个 issue 的配景是，Spark 功课运转的时分老是可能会遇到一些慢的 executor，这些慢的 executor 会发生长尾 task，拖慢功课速度。这个景象在流功课更加重大。为何会有这些慢 executor，可能缘故对比多，好比有多是由于某个机器节点网络环境或者磁盘环境有问题，也有可能有潜伏的内存泄露之类的 bug 等。
为理解决这个问题，它提供了一个叫 executor 的转动刷新的形式，能够设置刷新的频率，刷新的战略（好比能够结合比来的统计跑 task 最慢的 executor，偏重启这些 executor，完成这个 executor 按期地从新拉起）。这样，这些慢 executor 能够经过重启来防止始终拖慢前面的功课。由于重启 executor 对功课可能会有些影响，所以它需求结合 Spark 3 提供的另外一个特性——deco妹妹issioning，节点优雅下线的特性，既包管这个 executor 可以重启，也不会带来 Stage 重算之类的对功课的搅扰。
② Support Customized K8s Schedulers
K8s 默许调度器对大数据批处置不敌对，功用上也有对比多的欠缺，好比没有 capacity scheduling。这些大数据调度的功用在 K8s 对比少，因此有一些第三方的调度器提供了加强的才能，好比 YuniKorn、Volcano。为了可以更好的对接这些第三方 K8s 调度器，Spark 社区比来也提供了一个扩展接口和内置的完成类，这样用户能够便利地经过一些 Spark conf 来配置，连上这些第三方调度器，对这个 K8s 环境的调度会有一些对比好的可用性的晋升。虽然以前也能用，然而配置起来会较繁琐，当初 Spark 有了内置的反对就会有更好的用户体验。
这些就是近期 Spark 3.3 对于 K8s 方面的次要特性。
03
Spark on K8s 在阿里云 EMR 上的理论
这一章节将引见 Spark on K8s 在阿里云上的理论，结合咱们云上的一个产品 Spark on ACK，详细引见咱们提供的计划，以及所做的优化。

1. EMR Spark on ACK
在阿里云的公共云上，有一款 EMR on ACK 的产品，其中有一个集群类型是 Spark 集群（前面简称为 Spark on ACK）。顺便提一下，这里的 ACK 是阿里容器办事 K8s 版， ACK 能够了解为 K8s 集群。Spark on ACK 其实提供了一套半托管的大数据平台，帮大家在本人的 K8s 集群里部署好 Spark 运转的环境，提供一些管制台管控之类的功用。
用户首先需求有一个本人的 ACK 集群（K8s 集群），而后平台会在这个集群外面创立一个 Spark 功课的 namespace，而且固定装置一些组件，包罗 Spark operator、History Server 等，后续的 Spark 功课的 pod 也会在这个 namespace 下做运转。这些 Spark 功课的 pod 能够是 ACK 节点资源，也能够利用云上的弹性实力（ECI），来完成按量付费。

2. 充沛利用云上弹性劣势
所谓的这个弹性实例（ECI）是甚么？Spark 和云上结合最大的劣势就是弹性对比好，能够充沛利用云上的资源劣势。在阿里云 K8s 环境里有一个弹性容器实例（ECI）的产品，这个产品提供了一个很好的弹性，好比假如要请求 2 核 8G的一个 pod，再也不是占用本人机器节点的资源，而是彻底用云上的资源帮你来去创立这个 pod，不需求感知机器了。同时能够做到疾速拉起（秒级），以及按秒付费等。这样，用 ECI 来跑 Spark 功课很划算，由于通常大家用 Spark 跑批处置工作，峰谷对比显著，有的时分是人群顶峰，白昼可能查问对比少，这样的场景十分合适搭配这类极致的弹性。这些均可以节俭得多本钱，性价比十分高。

3. 使用 RSS 优化 shuffle 和静态资源
① Spark Shuffle 在 K8s 环境下的应战
Shuffle 是 K8s 环境跑 Spark 的另外一个应战，次要有两点：
Spark Shuffle 对当地存储的依赖Spark 功课的数据是需求落盘的，得多大的功课 shuffle 数据量很大（可能到 TB 级别）。在传统化的集群里这个问题到对比好解决，由于节点都会配置对比大的数据盘，和 HDFS 同时使用，所以很少会泛起磁盘不敷的状况。然而在 K8s 环境就不太同样。K8s 环境可能和其余办事做混合部署，K8s 得多机型没有当地盘，不是专门给大数据用的一些机型，只能利用它们的闲暇的 CPU，这个时分功课就很难利用上这些资源。假如 ECI 用弹性实力来跑 Spark，这些实例也没有对比大的数据盘，它只要大量的零碎盘，而挂云盘又有机能损失，也欠好评价挂多大的云盘对比适合。这个是在当地存储可能会见临的一些问题。
不完善的 Dynamic AllocationSpark 2 民间没有反对 dynamic allocation，Spark 3 GA 之后才反对在 K8s 环境里的dynamic allocation。然而 Spark 3 提供的 shuffle tracking 这个功用的 executor 回收效力对比慢，会带来资源使用的挥霍，也不是一个对比完善的计划。这个是环境跑 shuffle 的一个问题。

② Spark Shuffle 自身的缺乏
此外 Spark Shuffle 自身的算法也有一些缺乏。在 shuffle write 期间，会根据数据所属Reducer 排序，而后合并成一个文件，这个排序的过程当中可能会触发外排，会形成磁盘写缩小的一些机能问题。此外，Reducer 是并发拉取 Mapper 真个数据的，Mapper 端读的时分，有得多小碎片随机读，也会影响机能。还有就是 Shuffle 数据一旦丧失就要全部 Stage 重算，尤为在 K8s 环境里还可能会遇到节点摈除、pod 实例回收这些问题，遇到 executor 挂掉的状况会更加广泛，而一旦挂掉就重算对容错度的影响仍是对比大的，对功课的时长也有对比大的影响。

③使用 RSS 优化 shuffle 和静态资源
针对这两类问题，阿里云提供了一个叫做 RSS（Remote Shuffle Service）（链接：http://github.com/alibaba/celeborn）的办事，目前曾经在 GitHub 上开源了。原来的 Spark Shuffle 数据是保留在当地磁盘的，用了 RSS 之后，Shuffle 数据就交给 RSS 来办理，executor 间接把数据推给 RSS，当地就不需求占用很大的磁盘空间了。这类用内部 Shuffle Service 的模式在业界曾经是一个对比盛行的一个共鸣，得多公司都有在做这方面的优化，只不外 Spark 尚无提供一个民间的形式。
这类做法的优点有得多，不单单是机能上的优化，还能解耦后面提到的 executor 对当地盘的依赖，这样各种 pod 的机型均可以跑 Spark 功课了。此外这类形式对静态资源的反对也更好，多正本特性能够包管即便有一些挂掉可能也不会带来 Stage 重算的这些问题等等。

4. 使用 DLF 构建云上数据湖
接上去引见一下对于 Spark 生态的问题。
在 K8s 上大家不会部署残缺的 Hadoop 集群，好比 HDFS，会用对象存储 OSS 来做代替，还有得多其余组件可能用到，好比用 Hive Metadata 保留元数据，用 Sqoop 做数据导入等。在云上构建大数据平台是对比繁杂的，Spark 也依赖得多这些组件，这些问题均可以用云上的全托管办事 DLF，它能够提供一致的元数据权限管制，这样 Spark 就不需求本人再保护 Hive Metastore ，能够间接对接 DLF 做元数据办理，免去了得多组建运维的问题，而且用户也能够借此来疾速上手，是引擎的一个很好的搭档。

5. 易用性晋升
最初引见一下在 Spark on ACK 功课提交这一侧做的这个优化。
方才提到有两种功课提交形式，各有优劣，Spark on K8s operator 有对比好的功课办理才能，然而提交功课不兼容老的语法，也欠好跑交互式的功课，这样从老集群迁徙就对比费事。咱们提供了一个 CLI 工具，能够间接以 spark-submit 语法来提交 Spark 功课，同时也会记载到 operator 来进行办理，这样就同时享用到了这两种提交形式的优点。
详细原理其实就是在咱们在集群提交功课到 Spark Pod 的时分，咱们会去反向监听这个Pod 创立，而后再注册回 Spark operator。这里也是用咱们外部革新过的 Spark operator 来做这个功用。这对用户来讲较大地晋升了易用性。
04
Serverless Spark 在阿里云 DLF 的理论
下面咱们引见了 Spark on K8s 的一些内容。Spark 和云原生结合纷歧定非要用 K8s，云上也有些 Serverless 的功用，在 Spark 场景下也更为合适。上面这个章节我再引见一下 Serverless Spark 相干的一些信息。

1. DLF 数据探究引见
甚么是 Serverless Spark？
方才提到的 Spark on K8s 的状态仍是需求用户去感知、运维K8s 集群，是一种半托管的状态。云上 serverless Spark 的状态象征着用户无需求感知任何机器节点，能够间接经过规范的 API 形式提交功课。所谓 Serverless Spark 就是说用户彻底不需求买机器了，按功课去付费就能，这类状态很合适中小型的客户。阿里云 DLF 除了提供以前形容的元数据等等这些湖办理的功用之外，还有一个叫数据探究的功用。这个功用是一个规范的 Serverless Spark SQL，能够用来跑交互式查问。咱们只有把数据放到 OSS 上，而后在 DLF 建好表格，就能间接使用 SQL，并在管制台上进行交互式查问。图中右边是咱们实际的产品截图是一个规范的 SQL 任务台，用户能够间接在这里做一些剖析查问。

2. Serverless Spark SQL 架构
接上去引见一下Serverless Spark 详细的完成原理。
在架构里，最下层是 DLF-SQL Server，它是一个管控办事，对外提供查问 API，是一个无形态的在线办事。上面一层是利用了 Apache Livy 来去做交互式查问的会话创立和保护，这一层部署在 K8s 环境里，会按照负载扩缩容。最上层 Spark 跑在外部的机器资源池里，阿里云外部有一些一致的资源池，这个资源池是咱们和阿里云 Max Compute 同享的机器资源，能够最大水平保障用户资源的需要，关于每个用户的 SQL 查问都会提供独立的 Spark session，这样就象征着它们是不同的 Spark application，能够使隔离性和平安性失掉包管。

3. Spark Session 办理
关于交互式查问，咱们设计上有几个指标：既要包管用户查问可以疾速前往，用户提交的短查问，咱们但愿最少在几秒一定要能前往。此外也要包管外部资源不要做到挥霍。因此咱们需求对这些 Spark session 做好办理。
咱们把 Livy 拉起的 Spark session 分红了几品种型，一种是咱们默许会拉起一些空白会话，并一直保护若干个空白会话，包管用户查问来的时分不在现场创立 Spark 功课，这样，初次查问就会打到曾经建好的 Spark session 里了，可以最大限制地进步查问的机能。当用户查问到来的时分，就会从这个空白会话池里选中一个，并标志为这个用户专属的活泼会话，进入活泼会话池。在一段时间以内，假如用户进行一些查问之后再也不提交查问了（超时了），咱们就会把这个活泼会话从活泼会话池里拿走，自动烧毁、自动封闭，防止资源的挥霍。这就是咱们针对每一个个用户查问对应的后盾的 Spark Session 的办理和完成。

4. Livy Server 的优化
在 Livy server 这一层，咱们也做了一些优化和改进。
首先，每一个个 Livy session 默许只能运转一条语句，之后运转的语句都要排队等候。为了进步一些并行度，咱们改进了 Livy 的形态办理，搭配 Spark 的 Fair Scheduler，能够反对多条语句并行履行。
同时，为了包管用户初次查问的机能，咱们在空白 session 创立之初还会跑一些预热的语句，这样能够进步初次查问的机能。
此外，Livy 对查问的报错信息有一些 error 的显露出是不全的，默许只取 error 的第一行 message，实际上详细信息可能在 call stack 下方，所以咱们会按照一些规定把 call stack 下方的异样也都前往回来，便于用户查问定位等等这些细节。
固然上面还有一些就是咱们对分页的反对，对一些扫描量的记载等等，这些是结合咱们的详细产品功用做的优化和适配。

5. 其余功用特性
为了包管用户体验，在功用细节上也做了得多配置和优化。好比权限这块，咱们对接DLF 权限，用户阿里云子账号登录下去之后，自动去按照用户的子账号去做鉴权，只能查问本人有权限的 table，很合适剖析师在阿里云上开几个子账号，分别去做数据剖析的这类场景，咱们也有一些用户就是这么用的。
此外数据和格局方面，对 Delta、Hudi、IceBerg 这三个咱们都提供了内置反对。用户能够间接写 SQL 查问，不需求配额定的参数就可以间接查这些数据湖格局的表。这里完成上其实有一些辣手之处，由于每个湖格局都要配置本人的这个 SQL extension，做 SQL 阻拦来去做处置，在配置上三种格局有些场景下会有一些冲突，咱们也是在湖格局这个层面做了优化和兼容，包管互操作的顺滑性。
咱们在功用上也提供了后盾自动导出，默许内置了一些 TPC-DS 数据，经过映照的形式能够疾速创立，这些功用均可以帮帮忙大家疾速上手，也欢送大家在 DLF 里间接用这个功用体验一下 Serverless Spark SQL 的才能。
明天的分享就到这里，谢谢大家。
｜分享佳宾｜

范佚伦
阿里云开源大数据部技术专家
担任阿里云 EMR Spark on ACK 和 DLF 产品开发。
｜DataFun新媒体矩阵｜

｜对于DataFun｜
专一于大数据、人工智能技术运用的分享与交流。发动于2017年，在北京、上海、深圳、杭州等城市举行超过100+线下和100+线上沙龙、论坛及峰会，已约请超过2000位专家和学者参预分享。其大众号 DataFunTalk 累计出产原创文章800+，百万+浏览，15万+精准粉丝。

华人澳洲中文论坛

热图推荐

阿里云基于 Spark 的云原生数据湖剖析理论

发表回复

我不是处男
关注TA

图文推荐

华人澳洲中文论坛

热图推荐

阿里云基于 Spark 的云原生数据湖剖析理论

发表回复

我不是处男 关注TA

图文推荐

我不是处男
关注TA