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

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

前言

今天我們會討論一個在大數(shù)據(jù)領(lǐng)域中最重要的話題——存儲。

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

可預知的在未來，數(shù)據(jù)的量級會越來越大，特別是隨著 5G 時代的到來，數(shù)據(jù)的吞吐量級成指數(shù)的增長，數(shù)據(jù)的維度與來源會越來越多，數(shù)據(jù)的種類也會變得越來越異質(zhì)化，對大數(shù)據(jù)平臺也帶來新的挑戰(zhàn)。成本低、存得多、讀寫快成為大數(shù)據(jù)存儲的三大問題，而今天我們就會針對這三大問題進行探討。

容器化大數(shù)據(jù)的計算與存儲

計算和存儲分離是大數(shù)據(jù)領(lǐng)域被大家討論過很多次的問題了，通常我們會通過如下幾個角度來看這個問題：

• 硬件限制：機器的帶寬成倍數(shù)的增長，但是磁盤的速度基本不變，從而造成數(shù)據(jù)本地讀寫優(yōu)勢減弱。

• 計算成本：計算和存儲的量級不匹配，可能造成算力的大量浪費，獨立計算資源可以節(jié)約成本。

• 存儲成本：集中式存儲可以在保證更高 SLA 的前提下降低存儲成本，使得自建數(shù)據(jù)倉庫的優(yōu)勢減少。

這三大問題，隨著容器時代的到來也變得愈發(fā)的凸顯。我們知道在 Kubernetes 中，Pod 是運行在底層的資源池上，而 Pod 所需要的存儲是通過 PV 或者 PVC 的方式動態(tài)分配與掛載的，從某種意義來講，容器本身的架構(gòu)就是計算與存儲分離的。那么使用了存儲與計算分離方式的大數(shù)據(jù)容器集群會帶來哪些變化與優(yōu)勢呢？

• 成本更低

通常在阿里云上建立一個 Spark 大數(shù)據(jù)平臺的時候，首先會選擇 D 系列的機器，在上面搭建 HDFS、Hadoop 等一系列的基礎(chǔ)組件，然后再將 Spark 等作業(yè)任務(wù)通過 Yarn 進行調(diào)度，跑在這個集群之上。D系列的內(nèi)網(wǎng)帶寬范圍是3Gbps-20Gbps，默認可以綁定（4-28 塊) 5.5T 的本地盤。因為在云上，云盤的 IO 和網(wǎng)絡(luò)的 IO 是共享的，而本地盤的 IO 是獨立的，因此 D 系列+本地盤的 IO 性能會比同規(guī)格傳統(tǒng)機型+云盤的性能更好。
但是在實際生產(chǎn)中，我們會發(fā)現(xiàn)存儲的數(shù)據(jù)對著時間變得越來越多，而由于數(shù)據(jù)具有一定的時效性，造成單位時間的算力與存儲的增長是不相匹配的，這個時候就會帶來了成本的浪費。那么如果我們使用計算和存儲分離的思想，使用外部存儲，例如 OSS、Nas 或者 DFS(阿里云 HDFS 產(chǎn)品)，會有哪些變化呢？
首先，我們屏蔽由于存儲的 IO 差異造成的影響，先都使用遠程的 DFS 作為文件存儲。然后我們選擇了 ecs.ebmhfg5.2xlarge（8C32G6Gbps)和ecs.d1ne.2xlarge (8C32G6Gbps) 兩款分別面向計算和大數(shù)據(jù)場景規(guī)格配置相同的熱門機型，進行了比對。
ecs.ebmhfg5.2xlarge（8C32G)的測試結(jié)果：

ecs.d1ne.2xlarge (8C32G)的測試結(jié)果：

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

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

• 存的更多

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

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

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

• 讀寫更快

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

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

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

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

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

大量小文件存儲

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

第一種方案在大數(shù)據(jù)的場景下是非常不適用的，特別是文件比較多的場景，如果沒有類似 SmartFS 的優(yōu)化手段，會帶來很大的時延與不一致性。而使用 SDK 的方式則非常直接簡單，只需將相應的 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:[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 的方式進行任務(wù)執(zhí)行是，需要在 Driver Pod 與 Exector Pod 的 CLASSPATH 下預置好相應的 Jar 包。

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

HDFS 文件存儲

阿里云上新推出了 DFS 服務(wù)，可以像在 Hadoop 分布式文件系統(tǒng) (Hadoop Distributed File System) 中管理和訪問數(shù)據(jù)。無需對現(xiàn)有大數(shù)據(jù)分析應用做任何修改，即可使用具備無限容量及性能擴展、單一命名空間、多共享、高可靠和高可用等特性的分布式文件系統(tǒng)。
DFS 服務(wù)兼容 HDFS 協(xié)議，開發(fā)者只需將相應的調(diào)用 Jar 包放置在 Driver Pod 與 Exector Pod 的 CLASSPATH 中即可，調(diào)用時可以如下的方式進行調(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ù)場景，價格會高于 OSS 存儲，但低于 Nas 以及其他結(jié)構(gòu)化存儲。對于已經(jīng)習慣了 HDFS 的開發(fā)者而言，是最佳的的方案。在所有的存儲方案中，目前 IO 性能最佳，同容量場景，IO 優(yōu)于本地盤。

常規(guī)文件存儲

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

1. 首先在容器服務(wù)控制臺創(chuàng)建 Nas 相關(guān)的存儲 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 比較熟悉的開發(fā)者，同樣可以使用動態(tài)存儲的方式直接掛載。具體文檔地址如下:

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

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

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

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

看完上述內(nèi)容，你們對如何分析Spark in action on Kubernetes的存儲有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。

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

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、域名注冊、全網(wǎng)營銷推廣、外貿(mào)建站、微信小程序、關(guān)鍵詞優(yōu)化

廣告

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