Apache Spark項(xiàng)目于2009年誕生于伯克利大學(xué)的AMPLab實(shí)驗(yàn)室，當(dāng)初的目的在于將內(nèi)存內(nèi)分析機(jī)制引入大規(guī)模數(shù)據(jù)集當(dāng)中。在那個(gè)時(shí)候，Hadoop MapReduce的關(guān)注重點(diǎn)仍然放在那些本質(zhì)上無(wú)法迭代的大規(guī)模數(shù)據(jù)管道身上。想在2009年以MapReduce為基礎(chǔ)構(gòu)建起分析模型實(shí)在是件費(fèi)心費(fèi)力而又進(jìn)展緩慢的工作，因此AMPLab設(shè)計(jì)出Spark來(lái)幫助開(kāi)發(fā)人員對(duì)大規(guī)模數(shù)據(jù)集執(zhí)行交互分析、從而運(yùn)行各類(lèi)迭代工作負(fù)載——也就是對(duì)內(nèi)存中的同一套或者多套數(shù)據(jù)集進(jìn)行反復(fù)處理，其中最典型的就是機(jī)器學(xué)習(xí)算法。

Spark的意義并不在于取代Hadoop。正相反，它為那些高度迭代的工作負(fù)載提供了一套備用處理引擎。通過(guò)顯著降低面向磁盤(pán)的寫(xiě)入強(qiáng)度，Spark任務(wù)通常能夠在運(yùn)行速度方面高出Hadoop MapReduce幾個(gè)數(shù)量級(jí)。作為“寄生”在Hadoop集群當(dāng)中的得力助手，Spark利用Hadoop數(shù)據(jù)層（HDFS、HBase等等）作為數(shù)據(jù)管道終端，從而實(shí)現(xiàn)原始數(shù)據(jù)讀取以及最終結(jié)果存儲(chǔ)。

編寫(xiě)Spark應(yīng)用程序

作為由Scala語(yǔ)言編寫(xiě)的項(xiàng)目，Spark能夠?yàn)閿?shù)據(jù)處理流程提供一套統(tǒng)一化抽象層，這使其成為開(kāi)發(fā)數(shù)據(jù)應(yīng)用程序的絕佳環(huán)境。Spark在大多數(shù)情況下允許開(kāi)發(fā)人員選擇Scala、Java以及Python語(yǔ)言用于應(yīng)用程序構(gòu)建，當(dāng)然對(duì)于那些最為前沿的層面、只有Scala能夠?qū)崿F(xiàn)大家的一切構(gòu)想。

Spark當(dāng)中的突出特性之一在于利用Scala或者Python控制臺(tái)進(jìn)行交互式工作。這意味著大家可以在嘗試代碼運(yùn)行時(shí)，立即查看到其實(shí)際執(zhí)行結(jié)果。這一特性非常適合調(diào)試工作——大家能夠在無(wú)需進(jìn)行編譯的前提下變更其中的數(shù)值并再次處理——以及數(shù)據(jù)探索——這是一套典型的處理流程，由大量檢查-顯示-更新要素所構(gòu)成。

Spark的核心數(shù)據(jù)結(jié)構(gòu)是一套彈性分布式數(shù)據(jù)（簡(jiǎn)稱(chēng)RDD）集。在Spark當(dāng)中，驅(qū)動(dòng)程序被編寫(xiě)為一系列RDD轉(zhuǎn)換機(jī)制，并附帶與之相關(guān)的操作環(huán)節(jié)。顧名思義，所謂轉(zhuǎn)換是指通過(guò)變更現(xiàn)有數(shù)據(jù)——例如根據(jù)某些特定指標(biāo)對(duì)數(shù)據(jù)進(jìn)行過(guò)濾——根據(jù)其創(chuàng)建出新的RDD。操作則隨RDD自身同步執(zhí)行。具體而言，操作內(nèi)容可以是計(jì)算某種數(shù)據(jù)類(lèi)型的實(shí)例數(shù)量或者將RDD保存在單一文件當(dāng)中。

Spark的另一大優(yōu)勢(shì)在于允許使用者輕松將一套R(shí)DD共享給其它Spark項(xiàng)目。由于RDD的使用貫穿于整套Spark堆棧當(dāng)中，因此大家能夠隨意將SQL、機(jī)器學(xué)習(xí)、流以及圖形等元素?fù)诫s在同一個(gè)程序之內(nèi)。

熟悉各類(lèi)其它函數(shù)型編程語(yǔ)言——例如LISP、Haskell或者F#——的開(kāi)發(fā)人員會(huì)發(fā)現(xiàn)，除了API之外、自己能夠非常輕松地掌握Spark編程方式。歸功于Scala語(yǔ)言的出色收集系統(tǒng)，利用Spark Scala API編寫(xiě)的應(yīng)用程序能夠以干凈而且簡(jiǎn)潔的面貌呈現(xiàn)在開(kāi)發(fā)者面前。在對(duì)Spark編程工作進(jìn)行調(diào)整時(shí)，我們主要需要考慮這套系統(tǒng)的分布式特性并了解何時(shí)需要對(duì)對(duì)象以及函數(shù)進(jìn)行排序。

擁有其它程序語(yǔ)言，例如Java，知識(shí)背景的程序員則往往沒(méi)辦法快速適應(yīng)Spark項(xiàng)目的函數(shù)編程范式。有鑒于此，企業(yè)可能會(huì)發(fā)現(xiàn)找到一位能夠切實(shí)上手Spark（從這個(gè)角度講，Hadoop也包含其中）的Scala與函數(shù)編程人員實(shí)在不是件容易的事。

由于Spark的RDD能夠?qū)崿F(xiàn)跨系統(tǒng)共享，因此大家能夠隨意將SQL、機(jī)器學(xué)習(xí)、流以及圖形等元素?fù)诫s在同一個(gè)程序之內(nèi)。

彈性分布式數(shù)據(jù)集

對(duì)于RDD的使用貫穿于整套堆棧當(dāng)中，而這也成為Spark如此強(qiáng)大的根基之一。無(wú)論是從概念層面還是實(shí)施層面，RDD都顯得非常簡(jiǎn)單; RDD類(lèi)當(dāng)中的大部分方法都在20行以?xún)?nèi)。而從核心角度看，RDD屬于一套分布式記錄集合，由某種形式的持久性存儲(chǔ)作為依托并配備一系列轉(zhuǎn)換機(jī)制。

RDD是不可變更的。我們無(wú)法對(duì)RDD進(jìn)行修改，但卻能夠輕松利用不同數(shù)值創(chuàng)建新的RDD。這種不可變性算得上是分布式數(shù)據(jù)集的一大重要特性; 這意味著我們用不著擔(dān)心其它線程或者進(jìn)程在我們不知不覺(jué)中對(duì)RDD數(shù)值作出了變更——而這正是多線程編程領(lǐng)域的一個(gè)老大難問(wèn)題。這同時(shí)意味著我們能夠?qū)DD分發(fā)到整個(gè)集群當(dāng)中加以執(zhí)行，而不必?fù)?dān)心該如何在各節(jié)點(diǎn)之間對(duì)RDD內(nèi)容變更進(jìn)行同步。

RDD不可變性在Spark應(yīng)用程序的容錯(cuò)機(jī)制當(dāng)中同樣扮演著重要角色。由于每個(gè)RDD都保留有計(jì)算至當(dāng)前數(shù)值的全部歷史記錄、而且其它進(jìn)程無(wú)法對(duì)其作出變更，因此在某個(gè)節(jié)點(diǎn)丟失時(shí)對(duì)RDD進(jìn)行重新計(jì)算就變得非常輕松——只需要返回原本的持久性數(shù)據(jù)分區(qū)，再根據(jù)不同節(jié)點(diǎn)重新推導(dǎo)計(jì)算即可。（Hadoop當(dāng)中的大多數(shù)分區(qū)都具備跨節(jié)點(diǎn)持久性。）

RDD能夠通過(guò)多種數(shù)據(jù)分區(qū)類(lèi)型加以構(gòu)成。在大多數(shù)情況下，RDD數(shù)據(jù)來(lái)自HDFS，也就是所謂“分區(qū)”的書(shū)面含義。不過(guò)RDD也可以由來(lái)自其它持久性存儲(chǔ)機(jī)制的數(shù)據(jù)所構(gòu)成，其中包括HBase、Cassandra、SQL數(shù)據(jù)庫(kù)（通過(guò)JDBC）、Hive ORC（即經(jīng)過(guò)優(yōu)化的行列）文件乃至其它能夠與Hadoop InputFormat API相對(duì)接的存儲(chǔ)系統(tǒng)。無(wú)論RDD的實(shí)際來(lái)源如何，其運(yùn)作機(jī)制都是完全相同的。

Spark轉(zhuǎn)換機(jī)制的最后一項(xiàng)備注是：此類(lèi)流程非常懶惰，也就是說(shuō)直到某項(xiàng)操作要求將一條結(jié)果返回至驅(qū)動(dòng)程序，否則此前整個(gè)過(guò)程不涉及任何計(jì)算環(huán)節(jié)。這樣的特性在與Scala shell進(jìn)行交互時(shí)顯得意義重大。這是因?yàn)镽DD在逐步轉(zhuǎn)換的過(guò)程當(dāng)中不會(huì)帶來(lái)任何資源成本——直到需要執(zhí)行實(shí)際操作。到這個(gè)時(shí)候，所有數(shù)值才需要進(jìn)行計(jì)算，并將結(jié)果返回給用戶。除此之外，由于RDD能夠利用內(nèi)存充當(dāng)緩存機(jī)制，因此頻繁使用計(jì)算結(jié)果也不會(huì)造成反復(fù)計(jì)算或者由此引發(fā)的資源消耗。

Spark轉(zhuǎn)換機(jī)制非常懶惰，也就是說(shuō)直到某項(xiàng)操作要求將一條結(jié)果返回至用戶處，否則此前整個(gè)過(guò)程不涉及任何計(jì)算環(huán)節(jié)。

執(zhí)行Spark應(yīng)用程序

為了將一項(xiàng)Spark任務(wù)提交至集群，開(kāi)發(fā)人員需要執(zhí)行驅(qū)動(dòng)程序并將其與集群管理器（也被稱(chēng)為cluster master）相對(duì)接。集群管理器會(huì)為該驅(qū)動(dòng)程序提供一套持久性接口，這樣同一款應(yīng)用程序即可在任何受支持集群類(lèi)型之上實(shí)現(xiàn)正常運(yùn)行。

Spark項(xiàng)目目前支持專(zhuān)用Spark（獨(dú)立）、Mesos以及YARN集群。運(yùn)行在集群當(dāng)中的每個(gè)驅(qū)動(dòng)程序以各自獨(dú)立的方式負(fù)責(zé)資源分配與任務(wù)調(diào)度工作。盡管以隔離方式進(jìn)行應(yīng)用程序交付，但這種架構(gòu)往往令集群很難高效實(shí)現(xiàn)內(nèi)存管理——也就是對(duì)于Spark而言最為寶貴的資源類(lèi)型。多個(gè)高內(nèi)存消耗任務(wù)在同時(shí)提交時(shí)，往往會(huì)瞬間將內(nèi)存吞噬殆盡。盡管獨(dú)立集群管理器能夠?qū)崿F(xiàn)簡(jiǎn)單的資源調(diào)度，但卻只能做到跨應(yīng)用程序FIFO（即先入先出）這種簡(jiǎn)單的程度，而且無(wú)法實(shí)現(xiàn)資源識(shí)別。

總體而言，Spark開(kāi)發(fā)人員必須更傾向于裸機(jī)層面思維，而非利用像Hive或者Pig這樣的高級(jí)應(yīng)用程序?qū)?shù)據(jù)分析作為思考出發(fā)點(diǎn)。舉例來(lái)說(shuō)，由于驅(qū)動(dòng)程序充當(dāng)著調(diào)度任務(wù)的執(zhí)行者，它需要最大程度與這些工作節(jié)點(diǎn)保持緊密距離、從而避免網(wǎng)絡(luò)延遲對(duì)執(zhí)行效果造成的負(fù)面影響。

驅(qū)動(dòng)程序與集群管理器高可用性這兩者都很重要。如果驅(qū)動(dòng)程序停止工作，任務(wù)也將立即中止。而如果集群管理器出現(xiàn)故障，新的任務(wù)則無(wú)法被提交至其中，不過(guò)現(xiàn)有任務(wù)仍將繼續(xù)保持執(zhí)行。在Spark 1.1版本當(dāng)中，主高可用性機(jī)制由獨(dú)立Spark集群通過(guò)ZooKeeper實(shí)現(xiàn)，但驅(qū)動(dòng)程序卻缺乏與高可用性相關(guān)的保障措施。

將一套Spark集群當(dāng)中的性能最大程度壓榨出來(lái)更像是一種魔法甚至妖術(shù)，因?yàn)槠渲行枰婕皩?duì)驅(qū)動(dòng)程序、執(zhí)行器、內(nèi)存以及內(nèi)核的自由組合及反復(fù)實(shí)驗(yàn)，同時(shí)根據(jù)特定集群管理器對(duì)CPU及內(nèi)存使用率加以?xún)?yōu)化。目前關(guān)于此類(lèi)運(yùn)維任務(wù)的指導(dǎo)性文檔還非常稀缺，而且大家可能需要與同事進(jìn)行頻繁溝通并深入閱讀源代碼來(lái)實(shí)現(xiàn)這一目標(biāo)。

Spark應(yīng)用程序架構(gòu)。Spark目前可以被部署在Spark獨(dú)立、YARN或者M(jìn)esos集群當(dāng)中。請(qǐng)注意，運(yùn)行在集群當(dāng)中的每一個(gè)驅(qū)動(dòng)程序都會(huì)以彼此獨(dú)立的方式進(jìn)行資源分配與任務(wù)調(diào)度。

監(jiān)控與運(yùn)維

每一款驅(qū)動(dòng)程序都擁有自己的一套Web UI，通常為端口4040，其中顯示所有實(shí)用性信息——包括當(dāng)前運(yùn)行任務(wù)、調(diào)度程度、執(zhí)行器、階段、內(nèi)存與存儲(chǔ)使用率、RDD等等。這套UI主要充當(dāng)信息交付工具，而非針對(duì)Spark應(yīng)用程序或者集群的管理方案。當(dāng)然，這也是調(diào)試以及性能調(diào)整之前的基礎(chǔ)性工具——我們需要了解的、與應(yīng)用程序運(yùn)行密切相關(guān)的幾乎所有信息都能在這里找到。

雖然算是個(gè)不錯(cuò)的開(kāi)始，但這套Web UI在細(xì)節(jié)方面仍然顯得比較粗糙。舉例來(lái)說(shuō)，要想查看任務(wù)歷史記錄、我們需要導(dǎo)航到一臺(tái)獨(dú)立的歷史服務(wù)器，除非大家所使用的是處于獨(dú)立模式下的集群管理器。不過(guò)最大的缺點(diǎn)在于，這套Web UI缺少對(duì)于運(yùn)維信息的管理與控制能力。啟動(dòng)與中止節(jié)點(diǎn)運(yùn)行、查看節(jié)點(diǎn)運(yùn)行狀況以及其它一些集群層面的統(tǒng)計(jì)信息在這里一概無(wú)法實(shí)現(xiàn)。總體而言，Spark集群的運(yùn)行仍然停留在命令行操作時(shí)代。

Spark的Web UI提供了與當(dāng)前運(yùn)行任務(wù)相關(guān)的豐富信息，但所有指向集群的管理操作則需要完全通過(guò)命令行來(lái)實(shí)現(xiàn)。

Spark對(duì)決Tez

事實(shí)上，Spark與Tez都采用有向無(wú)環(huán)圖（簡(jiǎn)稱(chēng)DAG）執(zhí)行方式，這兩套框架之間的關(guān)系就如蘋(píng)果與桔子般不分軒輊，而最大的差別在于其受眾以及設(shè)計(jì)思路。即使如此，我發(fā)現(xiàn)很多IT部門(mén)仍然沒(méi)能分清這兩款框架間的差異所在。

Tez是一款應(yīng)用程序框架，設(shè)計(jì)目的在于幫助開(kāi)發(fā)人員編寫(xiě)出更為高效的多級(jí)MapReduce任務(wù)。舉例來(lái)說(shuō)，在Hive 0.13版本當(dāng)中，HQL（即Hive查詢(xún)語(yǔ)言）由語(yǔ)言編譯器負(fù)責(zé)解析并作為T(mén)ez DAG進(jìn)行渲染，即將數(shù)據(jù)流映射至處理節(jié)點(diǎn)處以實(shí)現(xiàn)高效執(zhí)行。Tez DAG由應(yīng)用程序以邊緣到邊緣、頂點(diǎn)到頂點(diǎn)的方式進(jìn)行構(gòu)建。用戶則完全不需要了解Tez DAG的構(gòu)建方式，甚至感受不到它的存在。

Spark與Tez之間的真正差異在于二者實(shí)現(xiàn)方式的不同。在Spark應(yīng)用程序當(dāng)中，同樣的工作節(jié)點(diǎn)通過(guò)跨迭代實(shí)現(xiàn)重新使用，這就消除了JVM啟動(dòng)所帶來(lái)的資源成本。Spark工作節(jié)點(diǎn)還能夠?qū)ψ兞窟M(jìn)行緩存處理，從而消除對(duì)數(shù)值進(jìn)行跨迭代重新讀取與重新計(jì)算的需要。正是借鑒著以上幾大特征，Spark才能夠在迭代編程當(dāng)中如魚(yú)得水、充分發(fā)力。而由此帶來(lái)的缺點(diǎn)是，Spark應(yīng)用程序會(huì)消耗大量集群資源、特別是在緩存過(guò)期的情況下。我們很難在集群運(yùn)行著Spark的時(shí)候?qū)Y源進(jìn)行優(yōu)化。

盡管支持多級(jí)任務(wù)執(zhí)行機(jī)制，Tez仍然不具備任何形式的緩存處理能力。雖然變量能夠在一定程度上得到緩存處理，從而保證規(guī)劃器在可能的情況下保證調(diào)度任務(wù)從同節(jié)點(diǎn)中的上一級(jí)處獲取必要數(shù)值，但Tez當(dāng)中仍然未能提供任何一種經(jīng)過(guò)妥善規(guī)劃的跨迭代或者變量廣播機(jī)制。除此之外，Tez任務(wù)還需要反復(fù)啟動(dòng)JVM，而這會(huì)帶來(lái)額外的資源開(kāi)銷(xiāo)。因此，Tez更適合處理那些規(guī)模極為龐大的數(shù)據(jù)集，在這種情況下啟動(dòng)時(shí)間只占整體任務(wù)處理周期的一小部分、幾乎可以忽略不計(jì)。

在大多數(shù)情況下，Hadoop社區(qū)對(duì)此都擁有很好的移花接木式解決方案，而且其中最出色的部分機(jī)制已經(jīng)能夠作用于其它項(xiàng)目。舉例來(lái)說(shuō)，YARN-1197將允許Spark執(zhí)行器以動(dòng)態(tài)方式進(jìn)行規(guī)模調(diào)整，這樣它們就能夠在合適的條件下將資源返還給集群。與之相似，Stinger.next將為Hive等傳統(tǒng)Hadoop應(yīng)用程序帶來(lái)由跨查詢(xún)緩存提供的巨大優(yōu)勢(shì)。

一整套集成化分析生態(tài)系統(tǒng)

Spark所采用的底層RDD抽象機(jī)制構(gòu)建起整個(gè)Spark生態(tài)系統(tǒng)的核心數(shù)據(jù)結(jié)構(gòu)。在機(jī)器學(xué)習(xí)（MLlib）、數(shù)據(jù)查詢(xún)（Spark SQL）、圖形分析（GraphX）以及流運(yùn)行（Spark Streaming）等模塊的共同支持下，開(kāi)發(fā)人員能夠以無(wú)縫化方式使用來(lái)自任意單一應(yīng)用程序的庫(kù)。

舉例來(lái)說(shuō)，開(kāi)發(fā)人員可以根據(jù)HDFS當(dāng)中的某個(gè)文件創(chuàng)建一個(gè)RDD，將該RDD轉(zhuǎn)換為SchemaRDD、利用Spark SQL對(duì)其進(jìn)行查詢(xún)，而后將結(jié)果交付給MLlib庫(kù)。最后，結(jié)果RDD可以被插入到Spark Streaming當(dāng)中，從而充當(dāng)消息交付機(jī)制的預(yù)測(cè)性模型。如果要在不使用Spark項(xiàng)目的情況下實(shí)現(xiàn)以上目標(biāo)，大家需要使用多套庫(kù)、對(duì)數(shù)據(jù)結(jié)構(gòu)進(jìn)行封包與轉(zhuǎn)換，并投入大量時(shí)間與精力對(duì)其加以部署。總體而言，將三到上個(gè)在最初設(shè)計(jì)當(dāng)中并未考慮過(guò)協(xié)作場(chǎng)景的應(yīng)用程序整合在一起絕對(duì)不是正常人的脆弱心靈所能承受的沉重負(fù)擔(dān)。

堆棧集成機(jī)制讓Spark在交互式數(shù)據(jù)探索與同一數(shù)據(jù)集內(nèi)的重復(fù)性函數(shù)應(yīng)用領(lǐng)域擁有著不可替代的重要價(jià)值。機(jī)器學(xué)習(xí)正是Spark項(xiàng)目大展拳腳的理想場(chǎng)景，而在不同生態(tài)系統(tǒng)之間以透明方式實(shí)現(xiàn)RDD共享的特性更是大大簡(jiǎn)化了現(xiàn)代數(shù)據(jù)分析應(yīng)用程序的編寫(xiě)與部署流程。

然而，這些優(yōu)勢(shì)的實(shí)現(xiàn)并非全無(wú)代價(jià)。在1.x系列版本當(dāng)中，Spark系統(tǒng)在諸多細(xì)節(jié)上還顯得相當(dāng)粗糙。具體而言，缺乏安全性（Spark無(wú)法運(yùn)行在Kerberised集群當(dāng)中，也不具備任務(wù)控制功能）、缺乏企業(yè)級(jí)運(yùn)維功能、說(shuō)明文檔質(zhì)量糟糕，而且嚴(yán)苛的稀缺性技能要求意味著目前Spark仍然只適合早期實(shí)驗(yàn)性部署或者那些有能力滿足大規(guī)模機(jī)器學(xué)習(xí)模型必需條件且愿意為其構(gòu)建支付任何投入的大型企業(yè)。

到底應(yīng)不應(yīng)該部署Spark算是一個(gè)“仁者見(jiàn)仁，智者見(jiàn)智”的開(kāi)放性議題。對(duì)于一部分組織而言，Spark這套速度極快的內(nèi)存內(nèi)分析引擎能夠帶來(lái)諸多優(yōu)勢(shì)，從而輕松為其帶來(lái)理想的投資回報(bào)表現(xiàn)。但對(duì)于另一些組織來(lái)說(shuō)，那些雖然速度相對(duì)較慢但卻更為成熟的工具仍然是其不二之選，畢竟它們擁有適合企業(yè)需求的完善功能而且更容易找到有能力對(duì)其進(jìn)行管理與控制的技術(shù)人員。

無(wú)論如何，我們都要承認(rèn)Spark的積極意義。Spark項(xiàng)目將一系列創(chuàng)新型思維帶入了大數(shù)據(jù)處理市場(chǎng)，并且表現(xiàn)出極為強(qiáng)勁的發(fā)展勢(shì)頭。隨著其逐步成熟，可以肯定Spark將最終成為一支不容忽視的巨大力量。

　　Apache Spark 1.1.0 / Apache軟件基金會(huì)

總結(jié)性描述

作為一套配備精妙A(yù)PI以實(shí)現(xiàn)數(shù)據(jù)處理應(yīng)用程序創(chuàng)建目標(biāo)的高速內(nèi)存內(nèi)分析引擎，Spark在迭代工作負(fù)載這類(lèi)需要重復(fù)訪問(wèn)同一套或者多套數(shù)據(jù)集的領(lǐng)域——例如機(jī)器學(xué)習(xí)——表現(xiàn)出無(wú)可匹敵的競(jìng)爭(zhēng)優(yōu)勢(shì)。

基于Apache 2.0許可的開(kāi)源項(xiàng)目

優(yōu)勢(shì)

精妙且具備一致性保障的API幫助開(kāi)發(fā)人員順利構(gòu)建起數(shù)據(jù)處理應(yīng)用程序

支持Hadoop集群上的交互式查詢(xún)與大規(guī)模數(shù)據(jù)集分析任務(wù)

在運(yùn)行迭代工作負(fù)載時(shí)擁有高出Hadoop幾個(gè)數(shù)量級(jí)的速度表現(xiàn)

能夠以獨(dú)立配置、YARN、Hadoop MapReduce或者M(jìn)esos等方式部署在Hadoop集群當(dāng)中

RDD（即彈性分布式數(shù)據(jù)集）能夠在不同Spark項(xiàng)目之間順利共享，從而允許用戶將SQL、機(jī)器學(xué)習(xí)、流運(yùn)行以及圖形等元素?fù)诫s在同一程序當(dāng)中

Web UI提供與Spark集群及當(dāng)前運(yùn)行任務(wù)相關(guān)的各類(lèi)實(shí)用性信息

缺點(diǎn)

安全性不理想

說(shuō)明文檔質(zhì)量糟糕

不具備集群資源管理能力

學(xué)習(xí)曲線不夠友好