溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
摘要： 隨著大數據技術的發展，實時流計算、機器學習、圖計算等領域成為較熱的研究方向，而Spark作為大數據處理的“利器”有著較為成熟的生態圈，能夠一站式解決類似場景的問題。那你知道Spark生態系統有哪些組件嗎？下面讓我們跟著本文一同了解下這些不可或缺的組件。本文選自《圖解Spark：核心技術與案例實戰》
Spark 生態系統以Spark Core 為核心，能夠讀取傳統文件（如文本文件）、HDFS、Amazon S3、Alluxio 和NoSQL 等數據源，利用Standalone、YARN 和Mesos 等資源調度管理，完成應用程序分析與處理。這些應用程序來自Spark 的不同組件，如Spark Shell 或Spark Submit 交互式批處理方式、Spark Streaming 的實時流處理應用、Spark SQL 的即席查詢、采樣近似查詢引擎BlinkDB 的權衡查詢、MLbase/MLlib 的機器學習、GraphX 的圖處理和SparkR 的數學計算等，如下圖所示，正是這個生態系統實現了“One Stack to Rule Them All”目標。
Spark Core 是整個BDAS 生態系統的核心組件，是一個分布式大數據處理框架。Spark Core提供了多種資源調度管理，通過內存計算、有向無環圖（DAG）等機制保證分布式計算的快速，并引入了RDD 的抽象保證數據的高容錯性，其重要特性描述如下。
Spark Core提供了多種運行模式，不僅可以使用自身運行模式處理任務，如本地模式、Standalone，而且可以使用第三方資源調度框架來處理任務，如YARN、MESOS等。相比較而言，第三方資源調度框架能夠更細粒度管理資源。
Spark Core提供了有向無環圖（DAG）的分布式并行計算框架，并提供內存機制來支持多次迭代計算或者數據共享，大大減少迭代計算之間讀取數據的開銷，這對于需要進行多次迭代的數據挖掘和分析性能有極大提升。另外，在任務處理過程中移動計算而非移動數據，RDDPartition 可以就近讀取分布式文件系統中的數據塊到各個節點內存中進行計算。
在Spark 中引入了RDD的抽象，它是分布在一組節點中的只讀對象集合，這些集合是彈性的，如果數據集一部分丟失，則可以根據“血統”對它們進行重建，保證了數據的高容錯性。
Spark Streaming 是一個對實時數據流進行高吞吐、高容錯的流式處理系統，可以對多種數據源（如Kafka、Flume、Twitter 和ZeroMQ 等）進行類似Map、Reduce 和Join 等復雜操作，并將結果保存到外部文件系統、數據庫或應用到實時儀表盤，如下圖。
相比其他的處理引擎要么只專注于流處理，要么只負責批處理（僅提供需要外部實現的流處理API 接口），而Spark Streaming 最大的優勢是提供的處理引擎和RDD 編程模型可以同時進行批處理與流處理。
對于傳統流處理中一次處理一條記錄的方式而言，Spark Streaming 使用的是將流數據離散化處理（Discretized Streams），通過該處理方式能夠進行秒級以下的數據批處理。在SparkStreaming 處理過程中，Receiver 并行接收數據，并將數據緩存至Spark 工作節點的內存中。經過延遲優化后，Spark 引擎對短任務（幾十毫秒）能夠進行批處理，并且可將結果輸出至其他系統中。與傳統連續算子模型不同，其模型是靜態分配給一個節點進行計算，而Spark 可基于數據的來源以及可用資源情況動態分配給工作節點。
使用離散化流數據（DStreaming），Spark Streaming 將具有如下特性。
動態負載均衡：Spark Streaming 將數據劃分為小批量，通過這種方式可以實現對資源更細粒度的分配。例如，傳統實時流記錄處理系統在輸入數據流以鍵值進行分區處理情況下，如果一個節點計算壓力較大超出了負荷，該節點將成為瓶頸，進而拖慢整個系統的處理速度。而在Spark Streaming中，作業任務將會動態地平衡分配給各個節點，如圖，即如果任務處理時間較長，分配的任務數量將少些；如果任務處理時間較短，則分配的任務數據將更多些。
快速故障恢復機制：在節點出現故障的情況下，傳統流處理系統會在其他的節點上重啟失敗的連續算子，并可能重新運行先前數據流處理操作獲取部分丟失數據。在此過程中只有該節點重新處理失敗的過程，只有在新節點完成故障前所有計算后，整個系統才能夠處理其他任務。在Spark中，計算將分成許多小的任務，保證能在任何節點運行后能夠正確進行合并。因此，在某節點出現的故障的情況，這個節點的任務將均勻地分散到集群中的節點進行計算，相對于傳遞故障恢復機制能夠更快地恢復。
批處理、流處理與交互式分析的一體化：Spark Streaming 是將流式計算分解成一系列短小的批處理作業，也就是把Spark Streaming 的輸入數據按照批處理大小（如幾秒）分成一段一段的離散數據流（DStream），每一段數據都轉換成Spark 中的RDD，然后將Spark Streaming 中對DStream 流處理操作變為針對Spark 中對RDD 的批處理操作。另外，流數據都儲存在Spark 節點的內存里，用戶便能根據所需進行交互查詢。正是利用了Spark 這種工作機制將批處理、流處理與交互式工作結合在一起。
Spark SQL 的前身是Shark，它發布時Hive 可以說是SQL on Hadoop 的唯一選擇（Hive 負責將SQL 編譯成可擴展的MapReduce 作業），鑒于Hive 的性能以及與Spark 的兼容，Shark 由此而生。
Shark 即Hive on Spark，本質上是通過Hive 的HQL 進行解析，把HQL 翻譯成Spark 上對應的RDD 操作，然后通過Hive 的Metadata 獲取數據庫里的表信息，實際為HDFS 上的數據和文件，最后由Shark 獲取并放到Spark 上運算。Shark 的最大特性就是速度快，能與Hive 的完全兼容，并且可以在Shell 模式下使用rdd2sql 這樣的API，把HQL 得到的結果集繼續在Scala環境下運算，支持用戶編寫簡單的機器學習或簡單分析處理函數，對HQL 結果進一步分析計算。
在2014 年7 月1 日的Spark Summit 上，Databricks 宣布終止對Shark 的開發，將重點放到Spark SQL 上。在此次會議上，Databricks 表示，Shark 更多是對Hive 的改造，替換了Hive 的物理執行引擎，使之有一個較快的處理速度。然而，不容忽視的是，Shark 繼承了大量的Hive代碼，因此給優化和維護帶來大量的麻煩。隨著性能優化和先進分析整合的進一步加深，基于MapReduce 設計的部分無疑成為了整個項目的瓶頸。因此，為了更好的發展，給用戶提供一個更好的體驗，Databricks 宣布終止Shark 項目，從而將更多的精力放到Spark SQL 上。
Spark SQL 允許開發人員直接處理RDD，同時也可查詢在 Hive 上存在的外部數據。SparkSQL 的一個重要特點是能夠統一處理關系表和RDD，使得開發人員可以輕松地使用SQL 命令進行外部查詢，同時進行更復雜的數據分析。
Spark SQL 的特點如下。
引入了新的RDD 類型SchemaRDD，可以像傳統數據庫定義表一樣來定義SchemaRDD。 SchemaRDD由定義了列數據類型的行對象構成。SchemaRDD 既可以從RDD 轉換過 來，也可以從Parquet 文件讀入，還可以使用HiveQL從Hive 中獲取。
內嵌了Catalyst 查詢優化框架，在把SQL 解析成邏輯執行計劃之后，利用Catalyst 包里的一些類和接口，執行了一些簡單的執行計劃優化，最后變成RDD 的計算。
在應用程序中可以混合使用不同來源的數據，如可以將來自HiveQL的數據和來自SQL的數據進行Join 操作。 Shark的出現使得SQL-on-Hadoop 的性能比Hive 有了10～100 倍的提高，那么，擺脫了 Hive 的限制，Spark SQL的性能又有怎么樣的表現呢？雖然沒有Shark 相對于Hive 那樣矚目的 性能提升，但也表現得優異，如圖（其中，右側數據為Spark SQL）。
為什么Spark SQL 的性能會得到這么大的提升呢？主要是Spark SQL 在以下幾點做了優化。
內存列存儲（In-Memory Columnar Storage）：Spark SQL 的表數據在內存中存儲不是采用原生態的JVM對象存儲方式，而是采用內存列存儲。
字節碼生成技術（Bytecode Generation）：Spark 1.1.0 在Catalyst 模塊的Expressions 增加了Codegen 模塊，使用動態字節碼生成技術，對匹配的表達式采用特定的代碼動態編譯。另外對SQL 表達式都做了CG 優化。CG優化的實現主要還是依靠Scala 2.10運行時的反射機制（Runtime Reflection）。
Scala 代碼優化：Spark SQL 在使用Scala編寫代碼的時候，盡量避免低效的、容易GC的代碼；盡管增加了編寫代碼的難度，但對于用戶來說接口統一。
BlinkDB 是一個用于在海量數據上運行交互式SQL 查詢的大規模并行查詢引擎，它允許用戶通過權衡數據精度來提升查詢響應時間，其數據的精度被控制在允許的誤差范圍內。為了達到這個目標，BlinkDB 使用如下核心思想：
自適應優化框架，從原始數據隨著時間的推移建立并維護一組多維樣本。
動態樣本選擇策略，選擇一個適當大小的示例，該示例基于查詢的準確性和響應時間的緊迫性。和傳統關系型數據庫不同，BlinkDB是一個交互式查詢系統，就像一個蹺蹺板，用戶需要在查詢精度和查詢時間上做權衡；如果用戶想更快地獲取查詢結果，那么將犧牲查詢結果的精度；反之，用戶如果想獲取更高精度的查詢結果，就需要犧牲查詢響應時間。下圖為BlinkDB架構。
MLBase 是Spark 生態系統中專注于機器學習的組件，它的目標是讓機器學習的門檻更低，讓一些可能并不了解機器學習的用戶能夠方便地使用MLBase。MLBase 分為4 個部分：MLRuntime、MLlib、MLI 和ML Optimizer。
MLRuntime：是由Spark Core 提供的分布式內存計算框架，運行由Optimizer優化過的算法進行數據的計算并輸出分析結果。
MLlib：是Spark 實現一些常見的機器學習算法和實用程序，包括分類、回歸、聚類、協同過濾、降維以及底層優化。該算法可以進行可擴充。
MLI：是一個進行特征抽取和高級ML 編程抽象算法實現的API 或平臺。
MLOptimizer：會選擇它認為最適合的已經在內部實現好了的機器學習算法和相關參數，來處理用戶輸入的數據，并返回模型或其他幫助分析的結果。
MLBase 的核心是其優化器（ML Optimizer），它可以把聲明式的任務轉化成復雜的學習計劃，最終產出最優的模型和計算結果。MLBase 與其他機器學習Weka 和Mahout 不同，三者各有特色，具體內容如下。
MLBase 基于Spark，它是使用的是分布式內存計算的；Weka 是一個單機的系統，而Mahout 是使用MapReduce 進行處理數據（Mahout 正向使用Spark 處理數據轉變）。
MLBase 是自動化處理的；Weka 和Mahout 都需要使用者具備機器學習技能，來選擇自己想要的算法和參數來做處理。
MLBase 提供了不同抽象程度的接口，可以由用戶通過該接口實現算法的擴展。
GraphX 最初是伯克利AMP 實驗室的一個分布式圖計算框架項目，后來整合到Spark 中成為一個核心組件。它是Spark 中用于圖和圖并行計算的API，可以認為是GraphLab 和Pregel 在Spark 上的重寫及優化。跟其他分布式圖計算框架相比，GraphX 最大的優勢是：在Spark 基礎上提供了一棧式數據解決方案，可以高效地完成圖計算的完整的流水作業。
GraphX 的核心抽象是Resilient Distributed Property Graph，一種點和邊都帶屬性的有向多重圖。GraphX 擴展了Spark RDD 的抽象，它有Table 和Graph 兩種視圖，但只需要一份物理存儲，兩種視圖都有自己獨有的操作符，從而獲得了靈活操作和執行效率。GraphX 的整體架構中大部分的實現都是圍繞Partition 的優化進行的，這在某種程度上說明了，點分割的存儲和相應的計算優化的確是圖計算框架的重點和難點。
GraphX 的底層設計有以下幾個關鍵點。
（1）對Graph 視圖的所有操作，最終都會轉換成其關聯的Table 視圖的RDD 操作來完成。這樣對一個圖的計算，最終在邏輯上，等價于一系列RDD 的轉換過程。因此，Graph 最終具備了RDD 的3 個關鍵特性：Immutable、Distributed 和Fault-Tolerant。其中最關鍵的是Immutable（不變性）。邏輯上，所有圖的轉換和操作都產生了一個新圖；物理上，GraphX 會有一定程度的不變頂點和邊的復用優化，對用戶透明。
（2）兩種視圖底層共用的物理數據，由RDD[Vertex-Partition]和RDD[EdgePartition]這兩個RDD 組成。點和邊實際都不是以表Collection[tuple] 的形式存儲的， 而是由VertexPartition/EdgePartition 在內部存儲一個帶索引結構的分片數據塊，以加速不同視圖下的遍歷速度。不變的索引結構在RDD 轉換過程中是共用的，降低了計算和存儲開銷。
（3）圖的分布式存儲采用點分割模式，而且使用partitionBy 方法，由用戶指定不同的劃分策略（PartitionStrategy）。劃分策略會將邊分配到各個EdgePartition，頂點Master 分配到各個VertexPartition，EdgePartition 也會緩存本地邊關聯點的Ghost 副本。劃分策略的不同會影響到所需要緩存的Ghost 副本數量，以及每個EdgePartition 分配的邊的均衡程度，需要根據圖的結構特征選取最佳策略。
R 是遵循GNU 協議的一款開源、免費的軟件，廣泛應用于統計計算和統計制圖，但是它只能單機運行。為了能夠使用R 語言分析大規模分布式的數據，伯克利分校AMP 實驗室開發了SparkR，并在Spark 1.4 版本中加入了該組件。通過SparkR 可以分析大規模的數據集，并通過R Shell 交互式地在SparkR 上運行作業。SparkR 特性如下：
提供了Spark 中彈性分布式數據集（RDDs）的API，用戶可以在集群上通過R Shell交互性地運行Spark 任務。
支持序化閉包功能，可以將用戶定義函數中所引用到的變量自動序化發送到集群中其他的機器上。
SparkR 還可以很容易地調用R 開發包，只需要在集群上執行操作前用includePackage讀取R 開發包就可以了。
下為SparkR 的處理流程示意圖。
Alluxio 是一個分布式內存文件系統，它是一個高容錯的分布式文件系統，允許文件以內存的速度在集群框架中進行可靠的共享，就像Spark 和 MapReduce 那樣。Alluxio 是架構在最底層的分布式文件存儲和上層的各種計算框架之間的一種中間件。其主要職責是將那些不需要落地到DFS 里的文件，落地到分布式內存文件系統中，來達到共享內存，從而提高效率。同時可以減少內存冗余、GC 時間等。
和Hadoop 類似，Alluxio 的架構是傳統的Master-Slave 架構，所有的Alluxio Worker 都被Alluxio Master 所管理，Alluxio Master 通過Alluxio Worker 定時發出的心跳來判斷Worker 是否已經崩潰以及每個Worker 剩余的內存空間量，為了防止單點問題使用了ZooKeeper 做了HA。
Alluxio 具有如下特性。
AVA-Like File API：Alluxio 提供類似Java File 類的API。
兼容性：Alluxio 實現了HDFS 接口，所以Spark 和MapReduce 程序不需要任何修改即可運行。
可插拔的底層文件系統：Alluxio是一個可插拔的底層文件系統，提供容錯功能，它將內存數據記錄在底層文件系統。它有一個通用的接口，可以很容易地插入到不同的底層文件系統。目前支持HDFS、S3、GlusterFS和單節點的本地文件系統，以后將支持更多的文件系統。Alluxio 所支持的應用如下。
本文選自《圖解Spark：核心技術與案例實戰》，想及時獲得更多精彩文章，可在微信中搜索“博文視點”或者掃描下方二維碼并關注。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
