Spark 生態(tài)系統(tǒng)組件是什么

這期內(nèi)容當中小編將會給大家?guī)碛嘘PSpark 生態(tài)系統(tǒng)組件是什么，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

　Spark 生態(tài)系統(tǒng)以Spark Core 為核心，能夠讀取傳統(tǒng)文件（如文本文件）、HDFS、Amazon S3、Alluxio 和NoSQL 等數(shù)據(jù)源，利用Standalone、YARN 和Mesos 等資源調(diào)度管理，完成應用程序分析與處理。這些應用程序來自Spark 的不同組件，如Spark Shell 或Spark Submit 交互式批處理方式、Spark Streaming 的實時流處理應用、Spark SQL 的即席查詢、采樣近似查詢引擎BlinkDB 的權(quán)衡查詢、MLbase/MLlib 的機器學習、GraphX 的圖處理和SparkR 的數(shù)學計算等，如下圖所示，正是這個生態(tài)系統(tǒng)實現(xiàn)了“One Stack to Rule Them All”目標。 

Spark Core

　　Spark Core 是整個BDAS 生態(tài)系統(tǒng)的核心組件，是一個分布式大數(shù)據(jù)處理框架。Spark Core提供了多種資源調(diào)度管理，通過內(nèi)存計算、有向無環(huán)圖（DAG）等機制保證分布式計算的快速，并引入了RDD 的抽象保證數(shù)據(jù)的高容錯性，其重要特性描述如下。

• Spark Core提供了多種運行模式，不僅可以使用自身運行模式處理任務，如本地模式、Standalone，而且可以使用第三方資源調(diào)度框架來處理任務，如YARN、MESOS等。相比較而言，第三方資源調(diào)度框架能夠更細粒度管理資源。

• Spark Core提供了有向無環(huán)圖（DAG）的分布式并行計算框架，并提供內(nèi)存機制來支持多次迭代計算或者數(shù)據(jù)共享，大大減少迭代計算之間讀取數(shù)據(jù)的開銷，這對于需要進行多次迭代的數(shù)據(jù)挖掘和分析性能有極大提升。另外，在任務處理過程中移動計算而非移動數(shù)據(jù)，RDDPartition 可以就近讀取分布式文件系統(tǒng)中的數(shù)據(jù)塊到各個節(jié)點內(nèi)存中進行計算。

• 在Spark 中引入了RDD的抽象，它是分布在一組節(jié)點中的只讀對象集合，這些集合是彈性的，如果數(shù)據(jù)集一部分丟失，則可以根據(jù)“血統(tǒng)”對它們進行重建，保證了數(shù)據(jù)的高容錯性。

Spark Streaming

　　Spark Streaming 是一個對實時數(shù)據(jù)流進行高吞吐、高容錯的流式處理系統(tǒng)，可以對多種數(shù)據(jù)源（如Kafka、Flume、Twitter 和ZeroMQ 等）進行類似Map、Reduce 和Join 等復雜操作，并將結(jié)果保存到外部文件系統(tǒng)、數(shù)據(jù)庫或應用到實時儀表盤，如下圖。 

　　相比其他的處理引擎要么只專注于流處理，要么只負責批處理（僅提供需要外部實現(xiàn)的流處理API 接口），而Spark Streaming 最大的優(yōu)勢是提供的處理引擎和RDD 編程模型可以同時進行批處理與流處理。 
　　對于傳統(tǒng)流處理中一次處理一條記錄的方式而言，Spark Streaming 使用的是將流數(shù)據(jù)離散化處理（Discretized Streams），通過該處理方式能夠進行秒級以下的數(shù)據(jù)批處理。在SparkStreaming 處理過程中，Receiver 并行接收數(shù)據(jù)，并將數(shù)據(jù)緩存至Spark 工作節(jié)點的內(nèi)存中。經(jīng)過延遲優(yōu)化后，Spark 引擎對短任務（幾十毫秒）能夠進行批處理，并且可將結(jié)果輸出至其他系統(tǒng)中。與傳統(tǒng)連續(xù)算子模型不同，其模型是靜態(tài)分配給一個節(jié)點進行計算，而Spark 可基于數(shù)據(jù)的來源以及可用資源情況動態(tài)分配給工作節(jié)點。 

　　使用離散化流數(shù)據(jù)（DStreaming），Spark Streaming 將具有如下特性。

• 動態(tài)負載均衡：Spark Streaming 
  將數(shù)據(jù)劃分為小批量，通過這種方式可以實現(xiàn)對資源更細粒度的分配。例如，傳統(tǒng)實時流記錄處理系統(tǒng)在輸入數(shù)據(jù)流以鍵值進行分區(qū)處理情況下，如果一個節(jié)點計算壓力較大超出了負荷，該節(jié)點將成為瓶頸，進而拖慢整個系統(tǒng)的處理速度。而在Spark　Streaming中，作業(yè)任務將會動態(tài)地平衡分配給各個節(jié)點，如圖，即如果任務處理時間較長，分配的任務數(shù)量將少些；如果任務處理時間較短，則分配的任務數(shù)據(jù)將更多些。

• 快速故障恢復機制：在節(jié)點出現(xiàn)故障的情況下，傳統(tǒng)流處理系統(tǒng)會在其他的節(jié)點上重啟失敗的連續(xù)算子，并可能重新運行先前數(shù)據(jù)流處理操作獲取部分丟失數(shù)據(jù)。在此過程中只有該節(jié)點重新處理失敗的過程，只有在新節(jié)點完成故障前所有計算后，整個系統(tǒng)才能夠處理其他任務。在Spark中，計算將分成許多小的任務，保證能在任何節(jié)點運行后能夠正確進行合并。因此，在某節(jié)點出現(xiàn)的故障的情況，這個節(jié)點的任務將均勻地分散到集群中的節(jié)點進行計算，相對于傳遞故障恢復機制能夠更快地恢復。 
  
  　　批處理、流處理與交互式分析的一體化：Spark Streaming 是將流式計算分解成一系列短小的批處理作業(yè)，也就是把Spark Streaming 的輸入數(shù)據(jù)按照批處理大?。ㄈ鐜酌耄┓殖梢欢我欢蔚碾x散數(shù)據(jù)流（DStream），每一段數(shù)據(jù)都轉(zhuǎn)換成Spark 中的RDD，然后將Spark Streaming 中對DStream 流處理操作變?yōu)獒槍park 中對RDD 的批處理操作。另外，流數(shù)據(jù)都儲存在Spark 節(jié)點的內(nèi)存里，用戶便能根據(jù)所需進行交互查詢。正是利用了Spark 這種工作機制將批處理、流處理與交互式工作結(jié)合在一起。

Spark SQL

　　Spark SQL 的前身是Shark，它發(fā)布時Hive 可以說是SQL on Hadoop 的唯一選擇（Hive 負責將SQL 編譯成可擴展的MapReduce 作業(yè)），鑒于Hive 的性能以及與Spark 的兼容，Shark 由此而生。 
　　Shark 即Hive on Spark，本質(zhì)上是通過Hive 的HQL 進行解析，把HQL 翻譯成Spark 上對應的RDD 操作，然后通過Hive 的Metadata 獲取數(shù)據(jù)庫里的表信息，實際為HDFS 上的數(shù)據(jù)和文件，最后由Shark 獲取并放到Spark 上運算。Shark 的最大特性就是速度快，能與Hive 的完全兼容，并且可以在Shell 模式下使用rdd2sql 這樣的API，把HQL 得到的結(jié)果集繼續(xù)在Scala環(huán)境下運算，支持用戶編寫簡單的機器學習或簡單分析處理函數(shù)，對HQL 結(jié)果進一步分析計算。 
　　在2014 年7 月1 日的Spark Summit 上，Databricks 宣布終止對Shark 的開發(fā)，將重點放到Spark SQL 上。在此次會議上，Databricks 表示，Shark 更多是對Hive 的改造，替換了Hive 的物理執(zhí)行引擎，使之有一個較快的處理速度。然而，不容忽視的是，Shark 繼承了大量的Hive代碼，因此給優(yōu)化和維護帶來大量的麻煩。隨著性能優(yōu)化和先進分析整合的進一步加深，基于MapReduce 設計的部分無疑成為了整個項目的瓶頸。因此，為了更好的發(fā)展，給用戶提供一個更好的體驗，Databricks 宣布終止Shark 項目，從而將更多的精力放到Spark SQL 上。 
　　Spark SQL 允許開發(fā)人員直接處理RDD，同時也可查詢在 Hive 上存在的外部數(shù)據(jù)。SparkSQL 的一個重要特點是能夠統(tǒng)一處理關系表和RDD，使得開發(fā)人員可以輕松地使用SQL 命令進行外部查詢，同時進行更復雜的數(shù)據(jù)分析。

　　Spark SQL 的特點如下。

• 引入了新的RDD 類型SchemaRDD，可以像傳統(tǒng)數(shù)據(jù)庫定義表一樣來定義SchemaRDD。 SchemaRDD由定義了列數(shù)據(jù)類型的行對象構(gòu)成。SchemaRDD 既可以從RDD 轉(zhuǎn)換過 來，也可以從Parquet 文件讀入，還可以使用HiveQL從Hive 中獲取。

• 內(nèi)嵌了Catalyst 查詢優(yōu)化框架，在把SQL 解析成邏輯執(zhí)行計劃之后，利用Catalyst 包里的一些類和接口，執(zhí)行了一些簡單的執(zhí)行計劃優(yōu)化，最后變成RDD 的計算。

• 在應用程序中可以混合使用不同來源的數(shù)據(jù)，如可以將來自HiveQL的數(shù)據(jù)和來自SQL的數(shù)據(jù)進行Join 操作。 Shark的出現(xiàn)使得SQL-on-Hadoop 的性能比Hive 有了10～100 倍的提高，那么，擺脫了 Hive 的限制，Spark SQL的性能又有怎么樣的表現(xiàn)呢？雖然沒有Shark 相對于Hive 那樣矚目的 性能提升，但也表現(xiàn)得優(yōu)異，如圖（其中，右側(cè)數(shù)據(jù)為Spark　SQL）。 
  
  　　為什么Spark SQL 的性能會得到這么大的提升呢？主要是Spark SQL 在以下幾點做了優(yōu)化。

• 內(nèi)存列存儲（In-Memory Columnar Storage）：Spark SQL 的表數(shù)據(jù)在內(nèi)存中存儲不是采用原生態(tài)的JVM對象存儲方式，而是采用內(nèi)存列存儲。

• 字節(jié)碼生成技術(shù)（Bytecode Generation）：Spark 1.1.0 在Catalyst 模塊的Expressions 
  增加了Codegen 模塊，使用動態(tài)字節(jié)碼生成技術(shù)，對匹配的表達式采用特定的代碼動態(tài)編譯。另外對SQL 表達式都做了CG 優(yōu)化。CG優(yōu)化的實現(xiàn)主要還是依靠Scala 2.10運行時的反射機制（Runtime Reflection）。

• Scala 代碼優(yōu)化：Spark SQL 在使用Scala編寫代碼的時候，盡量避免低效的、容易GC的代碼；盡管增加了編寫代碼的難度，但對于用戶來說接口統(tǒng)一。

BlinkDB

　　BlinkDB 是一個用于在海量數(shù)據(jù)上運行交互式SQL 查詢的大規(guī)模并行查詢引擎，它允許用戶通過權(quán)衡數(shù)據(jù)精度來提升查詢響應時間，其數(shù)據(jù)的精度被控制在允許的誤差范圍內(nèi)。為了達到這個目標，BlinkDB 使用如下核心思想：

• 自適應優(yōu)化框架，從原始數(shù)據(jù)隨著時間的推移建立并維護一組多維樣本。

• 動態(tài)樣本選擇策略，選擇一個適當大小的示例，該示例基于查詢的準確性和響應時間的緊迫性。和傳統(tǒng)關系型數(shù)據(jù)庫不同，BlinkDB是一個交互式查詢系統(tǒng)，就像一個蹺蹺板，用戶需要在查詢精度和查詢時間上做權(quán)衡；如果用戶想更快地獲取查詢結(jié)果，那么將犧牲查詢結(jié)果的精度；反之，用戶如果想獲取更高精度的查詢結(jié)果，就需要犧牲查詢響應時間。下圖為BlinkDB架構(gòu)。 
  

MLBase/MLlib

　　MLBase 是Spark 生態(tài)系統(tǒng)中專注于機器學習的組件，它的目標是讓機器學習的門檻更低，讓一些可能并不了解機器學習的用戶能夠方便地使用MLBase。MLBase 分為4 個部分：MLRuntime、MLlib、MLI 和ML Optimizer。

• MLRuntime：是由Spark Core 提供的分布式內(nèi)存計算框架，運行由Optimizer優(yōu)化過的算法進行數(shù)據(jù)的計算并輸出分析結(jié)果。

• MLlib：是Spark 實現(xiàn)一些常見的機器學習算法和實用程序，包括分類、回歸、聚類、協(xié)同過濾、降維以及底層優(yōu)化。該算法可以進行可擴充。

• MLI：是一個進行特征抽取和高級ML 編程抽象算法實現(xiàn)的API 或平臺。

• MLOptimizer：會選擇它認為最適合的已經(jīng)在內(nèi)部實現(xiàn)好了的機器學習算法和相關參數(shù)，來處理用戶輸入的數(shù)據(jù)，并返回模型或其他幫助分析的結(jié)果。

　　MLBase 的核心是其優(yōu)化器（ML Optimizer），它可以把聲明式的任務轉(zhuǎn)化成復雜的學習計劃，最終產(chǎn)出最優(yōu)的模型和計算結(jié)果。MLBase 與其他機器學習Weka 和Mahout 不同，三者各有特色，具體內(nèi)容如下。

• MLBase 基于Spark，它是使用的是分布式內(nèi)存計算的；Weka 是一個單機的系統(tǒng)，而Mahout 是使用MapReduce 
  進行處理數(shù)據(jù)（Mahout 正向使用Spark 處理數(shù)據(jù)轉(zhuǎn)變）。

• MLBase 是自動化處理的；Weka 和Mahout 都需要使用者具備機器學習技能，來選擇自己想要的算法和參數(shù)來做處理。

• MLBase 提供了不同抽象程度的接口，可以由用戶通過該接口實現(xiàn)算法的擴展。

GraphX

　　GraphX 最初是伯克利AMP 實驗室的一個分布式圖計算框架項目，后來整合到Spark 中成為一個核心組件。它是Spark 中用于圖和圖并行計算的API，可以認為是GraphLab 和Pregel 在Spark 上的重寫及優(yōu)化。跟其他分布式圖計算框架相比，GraphX 最大的優(yōu)勢是：在Spark 基礎上提供了一棧式數(shù)據(jù)解決方案，可以高效地完成圖計算的完整的流水作業(yè)。 
　　GraphX 的核心抽象是Resilient Distributed Property Graph，一種點和邊都帶屬性的有向多重圖。GraphX 擴展了Spark RDD 的抽象，它有Table 和Graph 兩種視圖，但只需要一份物理存儲，兩種視圖都有自己獨有的操作符，從而獲得了靈活操作和執(zhí)行效率。GraphX 的整體架構(gòu)中大部分的實現(xiàn)都是圍繞Partition 的優(yōu)化進行的，這在某種程度上說明了，點分割的存儲和相應的計算優(yōu)化的確是圖計算框架的重點和難點。 
GraphX 的底層設計有以下幾個關鍵點。 
（1）對Graph 視圖的所有操作，最終都會轉(zhuǎn)換成其關聯(lián)的Table 視圖的RDD 操作來完成。這樣對一個圖的計算，最終在邏輯上，等價于一系列RDD 的轉(zhuǎn)換過程。因此，Graph 最終具備了RDD 的3 個關鍵特性：Immutable、Distributed 和Fault-Tolerant。其中最關鍵的是Immutable（不變性）。邏輯上，所有圖的轉(zhuǎn)換和操作都產(chǎn)生了一個新圖；物理上，GraphX 會有一定程度的不變頂點和邊的復用優(yōu)化，對用戶透明。 
（2）兩種視圖底層共用的物理數(shù)據(jù)，由RDD[Vertex-Partition]和RDD[EdgePartition]這兩個RDD 組成。點和邊實際都不是以表Collection[tuple] 的形式存儲的， 而是由VertexPartition/EdgePartition 在內(nèi)部存儲一個帶索引結(jié)構(gòu)的分片數(shù)據(jù)塊，以加速不同視圖下的遍歷速度。不變的索引結(jié)構(gòu)在RDD 轉(zhuǎn)換過程中是共用的，降低了計算和存儲開銷。 
（3）圖的分布式存儲采用點分割模式，而且使用partitionBy 方法，由用戶指定不同的劃分策略（PartitionStrategy）。劃分策略會將邊分配到各個EdgePartition，頂點Master 分配到各個VertexPartition，EdgePartition 也會緩存本地邊關聯(lián)點的Ghost 副本。劃分策略的不同會影響到所需要緩存的Ghost 副本數(shù)量，以及每個EdgePartition 分配的邊的均衡程度，需要根據(jù)圖的結(jié)構(gòu)特征選取最佳策略。

SparkR

　　R 是遵循GNU 協(xié)議的一款開源、免費的軟件，廣泛應用于統(tǒng)計計算和統(tǒng)計制圖，但是它只能單機運行。為了能夠使用R 語言分析大規(guī)模分布式的數(shù)據(jù)，伯克利分校AMP 實驗室開發(fā)了SparkR，并在Spark 1.4 版本中加入了該組件。通過SparkR 可以分析大規(guī)模的數(shù)據(jù)集，并通過R Shell 交互式地在SparkR 上運行作業(yè)。SparkR 特性如下：

• 提供了Spark 中彈性分布式數(shù)據(jù)集（RDDs）的API，用戶可以在集群上通過R Shell交互性地運行Spark 任務。

• 支持序化閉包功能，可以將用戶定義函數(shù)中所引用到的變量自動序化發(fā)送到集群中其他的機器上。

• SparkR 還可以很容易地調(diào)用R 開發(fā)包，只需要在集群上執(zhí)行操作前用includePackage讀取R 開發(fā)包就可以了。

下為SparkR 的處理流程示意圖。 

Alluxio

　　Alluxio 是一個分布式內(nèi)存文件系統(tǒng)，它是一個高容錯的分布式文件系統(tǒng)，允許文件以內(nèi)存的速度在集群框架中進行可靠的共享，就像Spark 和 MapReduce 那樣。Alluxio 是架構(gòu)在最底層的分布式文件存儲和上層的各種計算框架之間的一種中間件。其主要職責是將那些不需要落地到DFS 里的文件，落地到分布式內(nèi)存文件系統(tǒng)中，來達到共享內(nèi)存，從而提高效率。同時可以減少內(nèi)存冗余、GC 時間等。 
　　和Hadoop 類似，Alluxio 的架構(gòu)是傳統(tǒng)的Master-Slave 架構(gòu)，所有的Alluxio Worker 都被Alluxio Master 所管理，Alluxio Master 通過Alluxio Worker 定時發(fā)出的心跳來判斷Worker 是否已經(jīng)崩潰以及每個Worker 剩余的內(nèi)存空間量，為了防止單點問題使用了ZooKeeper 做了HA。 
　　Alluxio 具有如下特性。

• AVA-Like File API：Alluxio 提供類似Java File 類的API。

• 兼容性：Alluxio 實現(xiàn)了HDFS 接口，所以Spark 和MapReduce 程序不需要任何修改即可運行。

• 可插拔的底層文件系統(tǒng)：Alluxio是一個可插拔的底層文件系統(tǒng)，提供容錯功能，它將內(nèi)存數(shù)據(jù)記錄在底層文件系統(tǒng)。它有一個通用的接口，可以很容易地插入到不同的底層文件系統(tǒng)。目前支持HDFS、S3、GlusterFS和單節(jié)點的本地文件系統(tǒng)，以后將支持更多的文件系統(tǒng)。

上述就是小編為大家分享的Spark 生態(tài)系統(tǒng)組件是什么了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業(yè)資訊頻道。