Spark in action on Kubernetes

  • 时间:
  • 浏览:2

作者 | 阿里云智能事业群技术专家 莫源

前言

在上篇文章中,Spark in action on Kubernetes – Spark Operator 的原理解析亲戚亲戚朋友分析了 Spark Operator 内部管理的机制,今天亲戚亲戚朋友会讨论一兩个 在大数据领域中最重要语录题——存储。

大数据而且无声无息的融入了每而且 人的生活中。大到旅游买房,小到外卖打车,都可不也能看得人通过大数据提供数据分析、数据推荐、数据决策的使用场景。大数据要想也能更准确地协助决策,需用在数据多维度、数据完备性等方面有较高要求。

可预知的在未来,数据的量级会这麼 大,不如保是随着 5G 时代的到来,数据的吞吐量级成指数的增长,数据的维度与来源会太久,数据的种类也会变得这麼 异质化,对大数据平台也带来新的挑战。成本低、存得多、读写快成为大数据存储的三问题,而今天亲戚亲戚朋友就会针对这三问题进行探讨。

容器化大数据的计算与存储

计算和存储分离是大数据领域被亲戚亲戚朋友讨论过全都次的问题了,通常亲戚亲戚朋友会通过如下几个传输速率来看这些 问题:

  • 硬件限制:机器的传输速率成倍数的增长,而且磁盘的传输速率基本不变,从而造成数据本地读写优势减弱。
  • 计算成本:计算和存储的量级不匹配,而且造成算力的一定量浪费,独立计算资源可不也能节约成本。
  • 存储成本:集中式存储可不也能在保证更高 SLA 的前提下降低存储成本,使得自建数据仓库的优势减少。

这三问题,随着容器时代的到来也变得愈发的凸显。亲戚亲戚朋友知道在 Kubernetes 中,Pod 是运行在底层的资源池上,而 Pod 所需用的存储是通过 PV 而且 PVC 的土办法 动态分配与挂载的,从有两种意义来讲,容器有两种的架构就说 计算与存储分离的。这麼 使用了存储与计算分离土办法 的大数据容器集群会带来哪些变化与优势呢?

  • 成本更低

通常在阿里云上建立一兩个 Spark 大数据平台的就说 ,首先会确定 D 系列的机器,在上边搭建 HDFS、Hadoop 等一系列的基础组件,而且再将 Spark 等作业任务通过 Yarn 进行调度,跑在这些 集群之上。D系列的内网传输速率范围是3Gbps-20Gbps,默认可不也能绑定(4-28 块) 5.5T 的本地盘。而且在云上,云盘的 IO 和网络的 IO 是共享的,而本地盘的 IO 是独立的,而且 D 系列+本地盘的 IO 性能会比同规格传统机型+云盘的性能更好。

而且在实际生产中,亲戚亲戚朋友会发现存储的数据对着时间变得太久,而而且数据具有一定的时效性,造成单位时间的算力与存储的增长是不相匹配的,这些 就说 就会带来了成本的浪费。这麼 而且亲戚亲戚朋友使用计算和存储分离的思想,使用内部管理存储,例如 OSS、Nas 而且 DFS(阿里云 HDFS 产品),会哪些变化呢?

首先,亲戚亲戚朋友屏蔽而且存储的 IO 差异造成的影响,先都使用远程的 DFS 作为文件存储。而且亲戚亲戚朋友确定了 ecs.ebmhfg5.2xlarge(8C32G6Gbps)和ecs.d1ne.2xlarge (8C32G6Gbps) 两款分别面向计算和大数据场景规格配置相同的热门机型,进行了比对。

ecs.ebmhfg5.2xlarge(8C32G)的测试结果:

ecs.d1ne.2xlarge (8C32G)的测试结果:

通过 Hibench 亲戚亲戚朋友可粗略的估算,在假定 IO性能基本一致的场景下,ecs.ebmhfg5.2xlarge会比ecs.d1ne.2xlarge 计算性能高 50% 左右,而成本上 ecs.ebmhfg5.2xlarge 会比 ecs.d1ne.2xlarge 低 25% 左右。

也却语录而且单单只看计算的能力,是可不也能有更高效、更节省的机型确定的。当存储和计算分离后,亲戚亲戚朋友可不也能从存储和计算兩个 维度分开去估算所需的用量,在机型上可不也能更多的考虑高主频计算能力较强 ECS,而存储上可不也能使用 OSS 而且 DFS,存储成本也相较本地存储更为低廉。

此外通常 D 系列的机型都有 1:4 的 CPU 内存比,随着大数据作业的场景这麼 充足,1:4 的 CPU 内存比就说 完都有最佳的配比,当存储与计算分离后,亲戚亲戚朋友可不也能根据业务的类型确定合适的计算资源,甚至可不也能在一兩个 计算资源池中维护多种计算资源,从而提高资源使用率。

数据存储的 SLA 和计算任务的SLA也是全版不同的,存储上是无法忍受宕机而且中断的,而且对于计算任务而言,有两种而且被切割为子任务了,单个子任务的异常只需重试即可,这麼 进一步就可不也能使用例如竞价实例这些 成本更低的资源来作为计算任务运行时环境,实现成本的进一步优化。

此外容器最大的特点就说 弹性,通过弹性的能力,容器可不也能在短时间内获得超远就说 自身几十甚至上百倍的计算资源,而计算任务完成后又自动释放掉。目前阿里云容器服务提供 autoscaler 进行节点级别的弹性伸缩,可不也能做到在 1 分半内伸缩 50 台节点。传统的计算与存储耦合的场景下,存储是阻碍弹性的一大障碍,而存储和计算分离后,就可不也能针对近乎无状态的计算来实现弹性的能力,实现真正的按需使用、按量消费。

  • 存的更多

使用内部管理存储后,亲戚亲戚朋友不止存储量级上可不也能做到近乎无限,而且可不也能有更多的确定。在本文开头位置,亲戚亲戚朋友而且提到了大数据时代的到来,将引入更多维度、更异质化的数据。而这也对数据存储的土办法 与类型也带来了更多的挑战。

单纯的 HDFS、Hbase、Kafka 等数据存储与链路将无法满足亲戚亲戚朋友的需求。例如从 IoT 设备分类整理的数据更倾向于使用时序存储进行离线、从应用上下游的产生的数据更倾向于存倒进形状化数据库中,数据的来源与链路会太久,大数据平台的底层基础设施与依赖就会越变太久。在云上,阿里云提供了多种类型的存储服务,可不也能满足各种大数据处理的场景。

除了传统的 HDFS、Hbase、kafka、OSS、Nas、CPFS 等存储,还蕴藏 MNS、TSDB、OAS(冷数据归档)等等。使用存储服务可不也能让大数据平台更关注在业务的开发,而都有底层基础架构的运维。不但也能存的更多,还可不也能存的更好、存的更省。

  • 读写减慢

从有两种传输速率来讲,读写减慢是不而且的,而且独立本地盘可不也能通过挂足够盘并行的土办法 进行提升的,而且要注意的问题在于,当亲戚亲戚朋友通过 MR 进行任务切割后,每个子任务的瓶颈是算不算还是在磁盘 IO 上,大每项状态下答案是算不算定。

上边亲戚亲戚朋友测试的 ECS 规格内网的传输速率而且可不也能到达 6Gbps,而且全版网络传输速率都换算成磁盘的 IO 语录,这些 量级的数据吞吐 IO 相比 8C32G 的算力而言是冗余的,全都此处亲戚亲戚朋友提到的读写减慢是处在 IO 冗余的前提下提升读写传输速率的土办法 。

OSS 是阿里云上提供的对象存储,读取不同单个文件的 IO 是并行的,也却语录而且你的业务场景是一定量中小型文件的并行读取,例如在 Spark 中读写目录的土办法 ,这麼 此时 IO 的读写传输速率近似是线性增强的。而且依然希望使用 HDFS 的开发者,阿里云也提 HDFS 存储服务,提供了一定量存储与查询的优化,和传统的自建的 HDFS 相比有 50% 左右的提升。

阿里云容器服务的存储方案

阿里云容器服务在多个维度多个层次满足大数据处理中的需求。开发者可不也能根据不同的业务场景和 IO 的新更能指标要求,确定合适而且 人的存储土办法 。

一定量小文件存储

OSS 是面向这些 场景的最佳使用土办法 ,在容器中可不也能使用有两种土办法 操作 OSS,有两种是将 OSS 挂载为一兩个 文件系统,有两种是直接在 Spark 中使用 SDK 来操作。

第有两种方案在大数据的场景下是非常不适用的,不如保是文件比较多的场景,而且这麼 例如 SmartFS 的优化手段,会带来很大的传输速率与不一致性。而使用 SDK 的土办法 则非常直接简单,只需将相应的 Jar 倒进 CLASSPATH 下即可,可不也能参考如下代码,直接处理  OSS 中的文件内容。

package com.aliyun.emr.exampleobject OSSSample extends RunLocally {  def main(args: Array[String]): Unit = {    if (args.length < 2) {      System.err.println(        """Usage: bin/spark-submit --class OSSSample examples-1.0-SNAPSHOT-shaded.jar <inputPath> <numPartition>          |          |Arguments:          |          |    inputPath        Input OSS object path, like oss://accessKeyId:accessKeySecret@bucket.endpoint/a/b.txt          |    numPartitions    the number of RDD partitions.          |        """.stripMargin)      System.exit(1)    }    val inputPath = args(0)    val numPartitions = args(1).toInt    val ossData = sc.textFile(inputPath, numPartitions)    println("The top 10 lines are:")    ossData.top(10).foreach(println)  }  override def getAppName: String = "OSS Sample"}

另外针对 Spark SQL 的场景,阿里云也提供了 https://yq.aliyun.com/articles/593910″>oss-select 的土办法 进行支持,可不也能通过 SparkSQL 的土办法 对单文件检索和查询。不如保注意:当使用 Spark Operator 的土办法 进行任务执行是,需用在 Driver Pod 与 Exector Pod 的 CLASSPATH 下预置好相应的 Jar 包。

OSS 的土办法 主要面向单个文件在百兆之下,文件数目比较多的场景优化较好,数据存储是几种常见存储中最便宜的,支持冷热数据的分离,主要面向读多写少而且不写的场景。

HDFS 文件存储

阿里云上新推出了 DFS 服务,可不也能像在 Hadoop 分布式文件系统 (Hadoop Distributed File System) 中管理和访问数据。不不对现有大数据分析应用做任何修改,即可使用具备无限容量及性能扩展、单一命名空间、多共享、高可靠和高可用等形状的分布式文件系统。

DFS 服务兼容 HDFS 协议,开发者只需将相应的调用 Jar 包放置在 Driver Pod 与 Exector Pod 的 CLASSPATH 中即可,调用时可不也能如下的土办法 进行调用。

/* SimpleApp.scala */import org.apache.spark.sql.SparkSessionobject SimpleApp {  def main(args: Array[String]) {    val logFile = "dfs://f-5d68cc61ya36.cn-beijing.dfs.aliyuncs.com:10290/logdata/ab.log"    val spark = SparkSession.builder.appName("Simple Application").getOrCreate()    val logData = spark.read.textFile(logFile).cache()    val numAs = logData.filter(line => line.contains("a")).count()    val numBs = logData.filter(line => line.contains("b")).count()    println(s"Lines with a: $numAs, Lines with b: $numBs")    spark.stop()  }}

DFS 服务的土办法 主就说 面向高 IO 读写的热数据场景,价格会高于 OSS 存储,但低于 Nas 以及而且 形状化存储。对于而且习惯了 HDFS 的开发者而言,是最佳的的方案。在所有的存储方案中,目前 IO 性能最佳,同容量场景,IO 优于本地盘。

常规文件存储

OSS 的土办法 对于而且 场景而言,数据的上传与传输依赖 SDK,操作会略显不便。这麼 Nas也是有两种备选的方案,Nas 的有两种的协议是强一致性的,开发者可不也能像操作本地文件的土办法 ,读写数据。使用土办法 如下:

1. 首先在容器服务控制台创建 Nas 相关的存储 PV 与 PVC。

2. 而且在 Spark Operator 的定义中声明所使用的 PodVolumeClain。

apiVersion: "sparkoperator.k8s.io/v1alpha1"kind: SparkApplicationmetadata:  name: spark-pi  namespace: defaultspec:  type: Scala  mode: cluster  image: "gcr.io/spark-operator/spark:v2.4.0"  imagePullPolicy: Always  mainClass: org.apache.spark.examples.SparkPi  mainApplicationFile: "local:///opt/spark/examples/jars/spark-examples_2.11-2.4.0.jar"  restartPolicy:    type: Never  volumes:  - name: pvc-nas    persistentVolumeClaim:        claimName: pvc-nas  driver:    cores: 0.1    coreLimit: "50m"    memory: "512m"    labels:      version: 2.4.0    serviceAccount: spark    volumeMounts:      - name: "pvc-nas"        mountPath: "/tmp"  executor:    cores: 1    instances: 1    memory: "512m"    labels:      version: 2.4.0    volumeMounts:      - name: "pvc-nas"        mountPath: "/tmp"

当然对于 Kubernetes 比较熟悉的开发者,同样可不也能使用动态存储的土办法 直接挂载。具体文档地址如下:

https://www.alibabacloud.com/help/zh/doc-detail/88940.htm



Nas 存储的土办法 在 Spark 的场景下用途比较少,主就说 而且在 IO 方面与 HDFS 有一定差距,在存储价格方面比OSS 也贵了不少。不过对于需用复用而且 data workflow 的产生结果,且 IO 要求要求都有不如保高的场景,Nas 的使用还是非常简单的。

而且 存储形状

在 Spark Streaming 的场景中,亲戚亲戚朋友还老会 使用例如 mns 而且 kafka,有的就说 也会使用 Elasticsearch 与 Hbase 等等。哪些在阿里云上边也都有对应的服务支持,开发者可不也能通过哪些云服务的集成与使用,将精力更多的倒进数据开发上。

最后

本文主要和亲戚亲戚朋友探讨了当容器遇到大数据后,改如保通过存储与计算分离的土办法 ,降低资源的使用成本,通过不同的场景,确定合适的存储土办法 ,实现云原生的大数据容器化计算。

本文由

阿里系统软件技术

发布在

ITPUB

,转载此文请保持文章全版性,并请附上文章来源(ITPUB)及本页链接。

原文链接:http://www.itpub.net/2019/04/15/509/