云計算

Spark in action on Kubernetes – 存儲篇

作者 | 阿里云智能事業群技術專家 莫源

前言

在上篇文章中,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 計算性能高 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.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:[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.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:?"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 等等。這些在阿里云上面也都有對應的服務支持,開發者可以通過這些云服務的集成與使用,將精力更多的放在數據開發上。

最后

本文主要和大家探討了當容器遇到大數據后,改如何通過存儲與計算分離的方式,降低資源的使用成本,通過不同的場景,選擇合適的存儲方式,實現云原生的大數據容器化計算。

我還沒有學會寫個人說明!

日志監控實踐 - 監控Agent集成Lua引擎實現多維度日志采集

上一篇

2019 年,容器技術生態會發生些什么?

下一篇

你也可能喜歡

Spark in action on Kubernetes – 存儲篇

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
30岁的男人干啥赚钱快赚钱多 广西体彩11选5 今天山西十一选五 贵州11选5漏选情况 pk10精准实用6码公式 东方电气股票分析 佳永配资网上深圳配资平台排名可靠吗 湖北快三官方手机版 南京期货配资 福建快三电子走势图 生肖6+1走势图