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

成都創新互聯專注為客戶提供全方位的互聯網綜合服務，包含不限于成都做網站、成都網站制作、華鎣網絡推廣、小程序定制開發、華鎣網絡營銷、華鎣企業策劃、華鎣品牌公關、搜索引擎seo、人物專訪、企業宣傳片、企業代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；成都創新互聯為所有大學生創業者提供華鎣建站搭建服務，24小時服務熱線：18980820575，官方網址：m.2m8n56k.cn

前言

今天我們會討論一個在大數據領域中最重要的話題——存儲。

大數據已經無聲無息的融入了每個人的生活中。大到旅游買房，小到外賣打車，都可以看到通過大數據提供數據分析、數據推薦、數據決策的使用場景。大數據要想能夠更準確地協助決策，需要在數據多維度、數據完備性等方面有較高要求。

可預知的在未來，數據的量級會越來越大，特別是隨著 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 計算性能高 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:[email protected]/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.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 的本身的協議是強一致性的，開發者可以像操作本地文件的方式，讀寫數據。使用方式如下：

1. 首先在容器服務控制臺創建 Nas 相關的存儲 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"

當然對于 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的存儲有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注創新互聯行業資訊頻道，感謝大家的支持。

名稱欄目：如何分析SparkinactiononKubernetes的存儲
URL鏈接：http://m.2m8n56k.cn/article40/pchjeo.html

成都網站建設公司_創新互聯，為您提供網站排名、域名注冊、全網營銷推廣、外貿建站、微信小程序、關鍵詞優化

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：[email protected]。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯