如何分析Spark in action on Kubernetes的存储

今天就跟大家聊聊有关如何分析Spark in action on Kubernetes的存储，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

通过 Hibench 我们可粗略的估算，在假定 IO性能基本一致的场景下，ecs.ebmhfg5.2xlarge会比ecs.d1ne.2xlarge 计算性能高 30% 左右，而成本上 ecs.ebmhfg5.2xlarge 会比 ecs.d1ne.2xlarge 低 25% 左右。
也就是说如果单单只看计算的能力，是可以有更高效、更节省的机型选择的。当存储和计算分离后，我们可以从存储和计算两个维度分开去估算所需的用量，在机型上可以更多的考虑高主频计算能力较强 ECS，而存储上可以使用 OSS 或者 DFS，存储成本也相较本地存储更为低廉。

此外通常 D 系列的机型都是 1:4 的 CPU 内存比，随着大数据作业的场景越来越丰富，1:4 的 CPU 内存比也不完全是最佳的配比，当存储与计算分离后，我们可以根据业务的类型选择合适的计算资源，甚至可以在一个计算资源池中维护多种计算资源，从而提高资源使用率。
数据存储的 SLA 和计算任务的SLA也是完全不同的，存储上是无法忍受宕机或者中断的，但是对于计算任务而言，本身已经被切割为子任务了，单个子任务的异常只需重试即可，那么进一步就可以使用类似竞价实例这种成本更低的资源来作为计算任务运行时环境，实现成本的进一步优化。
此外容器最大的特点就是弹性，通过弹性的能力，容器可以在短时间内获得超远原本自身几十甚至上百倍的计算资源，而计算任务完成后又自动释放掉。目前阿里云容器服务提供 autoscaler 进行节点级别的弹性伸缩，可以做到在 1 分半内伸缩 500 台节点。传统的计算与存储耦合的场景下，存储是阻碍弹性的一大障碍，而存储和计算分离后，就可以针对近乎无状态的计算来实现弹性的能力，实现真正的按需使用、按量消费。

• 存的更多

使用外部存储后，我们不止存储量级上可以做到近乎无限，而且可以有更多的选择。在本文开头位置，我们已经提到了大数据时代的到来，将引入更多维度、更异质化的数据。而这也对数据存储的方式与类型也带来了更多的挑战。

单纯的 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.example
object 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 中即可，调用时可以如下的方式进行调用。

import org.apache.spark.sql.SparkSession
object 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 的本身的协议是强一致性的，开发者可以像操作本地文件的方式，读写数据。使用方式如下：

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

然后在 Spark Operator 的定义中声明所使用的 PodVolumeClain。

apiVersion: "sparkoperator.k8s.io/v1alpha1"
kind: SparkApplication
metadata:
  name: spark-pi
  namespace: default
spec:
  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: "200m"
    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 等等。这些在阿里云上面也都有对应的服务支持，开发者可以通过这些云服务的集成与使用，将精力更多的放在数据开发上。

看完上述内容，你们对如何分析Spark in action on Kubernetes的存储有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注编程网行业资讯频道，感谢大家的支持。