如何分析Spark in action on Kubernetes的存儲(chǔ)

今天就跟大家聊聊有關(guān)如何分析Spark in action on Kubernetes的存儲(chǔ)，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

通過 Hibench 我們可粗略的估算，在假定 IO性能基本一致的場景下，ecs.ebmhfg5.2xlarge會(huì)比ecs.d1ne.2xlarge 計(jì)算性能高 30% 左右，而成本上 ecs.ebmhfg5.2xlarge 會(huì)比 ecs.d1ne.2xlarge 低 25% 左右。
也就是說如果單單只看計(jì)算的能力，是可以有更高效、更節(jié)省的機(jī)型選擇的。當(dāng)存儲(chǔ)和計(jì)算分離后，我們可以從存儲(chǔ)和計(jì)算兩個(gè)維度分開去估算所需的用量，在機(jī)型上可以更多的考慮高主頻計(jì)算能力較強(qiáng) ECS，而存儲(chǔ)上可以使用 OSS 或者 DFS，存儲(chǔ)成本也相較本地存儲(chǔ)更為低廉。

此外通常 D 系列的機(jī)型都是 1:4 的 CPU 內(nèi)存比，隨著大數(shù)據(jù)作業(yè)的場景越來越豐富，1:4 的 CPU 內(nèi)存比也不完全是最佳的配比，當(dāng)存儲(chǔ)與計(jì)算分離后，我們可以根據(jù)業(yè)務(wù)的類型選擇合適的計(jì)算資源，甚至可以在一個(gè)計(jì)算資源池中維護(hù)多種計(jì)算資源，從而提高資源使用率。
數(shù)據(jù)存儲(chǔ)的 SLA 和計(jì)算任務(wù)的SLA也是完全不同的，存儲(chǔ)上是無法忍受宕機(jī)或者中斷的，但是對(duì)于計(jì)算任務(wù)而言，本身已經(jīng)被切割為子任務(wù)了，單個(gè)子任務(wù)的異常只需重試即可，那么進(jìn)一步就可以使用類似競價(jià)實(shí)例這種成本更低的資源來作為計(jì)算任務(wù)運(yùn)行時(shí)環(huán)境，實(shí)現(xiàn)成本的進(jìn)一步優(yōu)化。
此外容器最大的特點(diǎn)就是彈性，通過彈性的能力，容器可以在短時(shí)間內(nèi)獲得超遠(yuǎn)原本自身幾十甚至上百倍的計(jì)算資源，而計(jì)算任務(wù)完成后又自動(dòng)釋放掉。目前阿里云容器服務(wù)提供 autoscaler 進(jìn)行節(jié)點(diǎn)級(jí)別的彈性伸縮，可以做到在 1 分半內(nèi)伸縮 500 臺(tái)節(jié)點(diǎn)。傳統(tǒng)的計(jì)算與存儲(chǔ)耦合的場景下，存儲(chǔ)是阻礙彈性的一大障礙，而存儲(chǔ)和計(jì)算分離后，就可以針對(duì)近乎無狀態(tài)的計(jì)算來實(shí)現(xiàn)彈性的能力，實(shí)現(xiàn)真正的按需使用、按量消費(fèi)。

• 存的更多

使用外部存儲(chǔ)后，我們不止存儲(chǔ)量級(jí)上可以做到近乎無限，而且可以有更多的選擇。在本文開頭位置，我們已經(jīng)提到了大數(shù)據(jù)時(shí)代的到來，將引入更多維度、更異質(zhì)化的數(shù)據(jù)。而這也對(duì)數(shù)據(jù)存儲(chǔ)的方式與類型也帶來了更多的挑戰(zhàn)。

單純的 HDFS、Hbase、Kafka 等數(shù)據(jù)存儲(chǔ)與鏈路將無法滿足我們的需求。例如從 IoT 設(shè)備采集的數(shù)據(jù)更傾向于使用時(shí)序存儲(chǔ)進(jìn)行離線、從應(yīng)用上下游的產(chǎn)生的數(shù)據(jù)更傾向于存放在結(jié)構(gòu)化數(shù)據(jù)庫中，數(shù)據(jù)的來源與鏈路會(huì)越來越多，大數(shù)據(jù)平臺(tái)的底層基礎(chǔ)設(shè)施與依賴就會(huì)越變越多。在云上，阿里云提供了多種類型的存儲(chǔ)服務(wù)，可以滿足各種大數(shù)據(jù)處理的場景。

除了傳統(tǒng)的 HDFS、Hbase、kafka、OSS、Nas、CPFS 等存儲(chǔ)，還包含 MNS、TSDB、OAS(冷數(shù)據(jù)歸檔)等等。使用存儲(chǔ)服務(wù)可以讓大數(shù)據(jù)平臺(tái)更關(guān)注在業(yè)務(wù)的開發(fā)，而不是底層基礎(chǔ)架構(gòu)的運(yùn)維。不但能夠存的更多，還可以存的更好、存的更省。

• 讀寫更快

從某種角度來講，讀寫更快是不可能的，因?yàn)楠?dú)立本地盤可以通過掛足夠盤并行的方式進(jìn)行提升的，但是要注意的問題在于，當(dāng)我們通過 MR 進(jìn)行任務(wù)切割后，每個(gè)子任務(wù)的瓶頸是否還是在磁盤 IO 上，大部分情況下答案是否定。

上面我們測試的 ECS 規(guī)格內(nèi)網(wǎng)的帶寬已經(jīng)可以到達(dá) 6Gbps，如果全部網(wǎng)絡(luò)帶寬都換算成磁盤的 IO 的話，這個(gè)量級(jí)的數(shù)據(jù)吞吐 IO 相比 8C32G 的算力而言是冗余的，所以此處我們提到的讀寫更快是指在 IO 冗余的前提下提升讀寫速度的方式。

OSS 是阿里云上提供的對(duì)象存儲(chǔ)，讀取不同單個(gè)文件的 IO 是并行的，也就是說如果你的業(yè)務(wù)場景是大量中小型文件的并行讀取，例如在 Spark 中讀寫目錄的方式，那么此時(shí) IO 的讀寫速度近似是線性增強(qiáng)的。如果依然希望使用 HDFS 的開發(fā)者，阿里云也提 HDFS 存儲(chǔ)服務(wù)，提供了大量存儲(chǔ)與查詢的優(yōu)化，和傳統(tǒng)的自建的 HDFS 相比有 50% 左右的提升。

阿里云容器服務(wù)的存儲(chǔ)方案

阿里云容器服務(wù)在多個(gè)維度多個(gè)層次滿足大數(shù)據(jù)處理中的需求。開發(fā)者可以根據(jù)不同的業(yè)務(wù)場景和 IO 的新更能指標(biāo)要求，選擇合適自己的存儲(chǔ)方式。

大量小文件存儲(chǔ)

OSS 是面向這個(gè)場景的最佳使用方式，在容器中可以使用兩種方式操作 OSS，一種是將 OSS 掛載為一個(gè)文件系統(tǒng)，一種是直接在 Spark 中使用 SDK 來操作。

第一種方案在大數(shù)據(jù)的場景下是非常不適用的，特別是文件比較多的場景，如果沒有類似 SmartFS 的優(yōu)化手段，會(huì)帶來很大的時(shí)延與不一致性。而使用 SDK 的方式則非常直接簡單，只需將相應(yīng)的 Jar 放在 CLASSPATH 下即可，可以參考如下代碼，直接處理  OSS 中的文件內(nèi)容。

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"
}

另外針對(duì) Spark SQL 的場景，阿里云也提供了 https://yq.aliyun.com/articles/593910">oss-select 的方式進(jìn)行支持，可以通過 SparkSQL 的方式對(duì)單文件檢索和查詢。特別注意：當(dāng)使用 Spark Operator 的方式進(jìn)行任務(wù)執(zhí)行是，需要在 Driver Pod 與 Exector Pod 的 CLASSPATH 下預(yù)置好相應(yīng)的 Jar 包。

OSS 的方式主要面向單個(gè)文件在百兆之下，文件數(shù)目比較多的場景優(yōu)化較好，數(shù)據(jù)存儲(chǔ)是幾種常見存儲(chǔ)中最便宜的，支持冷熱數(shù)據(jù)的分離，主要面向讀多寫少或者不寫的場景。

HDFS 文件存儲(chǔ)

阿里云上新推出了 DFS 服務(wù)，可以像在 Hadoop 分布式文件系統(tǒng) (Hadoop Distributed File System) 中管理和訪問數(shù)據(jù)。無需對(duì)現(xiàn)有大數(shù)據(jù)分析應(yīng)用做任何修改，即可使用具備無限容量及性能擴(kuò)展、單一命名空間、多共享、高可靠和高可用等特性的分布式文件系統(tǒng)。
DFS 服務(wù)兼容 HDFS 協(xié)議，開發(fā)者只需將相應(yīng)的調(diào)用 Jar 包放置在 Driver Pod 與 Exector Pod 的 CLASSPATH 中即可，調(diào)用時(shí)可以如下的方式進(jìn)行調(diào)用。

/* SimpleApp.scala */
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 服務(wù)的方式主要是面向高 IO 讀寫的熱數(shù)據(jù)場景，價(jià)格會(huì)高于 OSS 存儲(chǔ)，但低于 Nas 以及其他結(jié)構(gòu)化存儲(chǔ)。對(duì)于已經(jīng)習(xí)慣了 HDFS 的開發(fā)者而言，是最佳的的方案。在所有的存儲(chǔ)方案中，目前 IO 性能最佳，同容量場景，IO 優(yōu)于本地盤。

常規(guī)文件存儲(chǔ)

OSS 的方式對(duì)于某些場景而言，數(shù)據(jù)的上傳與傳輸依賴 SDK，操作會(huì)略顯不便。那么Nas也是一種備選的方案，Nas 的本身的協(xié)議是強(qiáng)一致性的，開發(fā)者可以像操作本地文件的方式，讀寫數(shù)據(jù)。使用方式如下：

1. 首先在容器服務(wù)控制臺(tái)創(chuàng)建 Nas 相關(guān)的存儲(chǔ) PV 與 PVC。

2. 然后在 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"

當(dāng)然對(duì)于 Kubernetes 比較熟悉的開發(fā)者，同樣可以使用動(dòng)態(tài)存儲(chǔ)的方式直接掛載。具體文檔地址如下:

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

Nas 存儲(chǔ)的方式在 Spark 的場景下用途比較少，主要是因?yàn)樵?IO 方面與 HDFS 有一定差距，在存儲(chǔ)價(jià)格方面比OSS 也貴了不少。不過對(duì)于需要復(fù)用一些 data workflow 的產(chǎn)生結(jié)果，且 IO 要求要求不是特別高的場景，Nas 的使用還是非常簡單的。

其他存儲(chǔ)結(jié)構(gòu)

在 Spark Streaming 的場景中，我們還經(jīng)常使用例如 mns 或者 kafka，有的時(shí)候也會(huì)使用 Elasticsearch 與 Hbase 等等。這些在阿里云上面也都有對(duì)應(yīng)的服務(wù)支持，開發(fā)者可以通過這些云服務(wù)的集成與使用，將精力更多的放在數(shù)據(jù)開發(fā)上。

看完上述內(nèi)容，你們對(duì)如何分析Spark in action on Kubernetes的存儲(chǔ)有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。