為什么Spark發(fā)展不如Hadoop_數(shù)據(jù)分析師

  一說大數(shù)據(jù)，人們往往想到Hadoop。這固然不錯，但隨著大數(shù)據(jù)技術(shù)的深入應(yīng)用，多種類型的數(shù)據(jù)應(yīng)用不斷被要求提出，一些Hadoop被關(guān)注的范疇開始被人們注意，相關(guān)技術(shù)也迅速獲得專業(yè)技術(shù)范疇的應(yīng)用。最近半年來的Spark之熱就是典型例子。

    Spark是一個基于RAM計算的開源碼ComputerCluster運算系統(tǒng)，目的是更快速地進行數(shù)據(jù)分析。Spark早期的核心部分代碼只有3萬行。Spark提供了與HadoopMap/Reduce相似的分散式運算框架，但基于RAM和優(yōu)化設(shè)計，因此在交換式數(shù)據(jù)分析和datamining的Workload中表現(xiàn)不錯。

    進入2014年以后，Spark開源碼生態(tài)系統(tǒng)大幅增長，已成為大數(shù)據(jù)范疇最活躍的開源碼項目之一。Spark之所以有如此多的關(guān)注，塬因主要是因為Spark具有的高性能、高靈活性、與Hadoop生態(tài)系統(tǒng)完美融合等叁方面的特點。

    首先，Spark對分散的數(shù)據(jù)集進行抽樣，創(chuàng)新地提出RDD(ResilientDistributedDataset)的概念，所有的統(tǒng)計分析任務(wù)被翻譯成對RDD的基本操作組成的有向無環(huán)圖(DAG)。RDD可以被駐留在RAM中，往后的任務(wù)可以直接讀取RAM中的數(shù)據(jù)；同時分析DAG中任務(wù)之間的依賴性可以把相鄰的任務(wù)合并，從而減少了大量不準確的結(jié)果輸出，極大減少了HarddiskI/O，使復(fù)雜數(shù)據(jù)分析任務(wù)更高效。從這個推算，如果任務(wù)夠復(fù)雜，Spark比Map/Reduce快一到兩倍。

    其次，Spark是一個靈活的運算框架，適合做批次處理、工作流、交互式分析、流量處理等不同類型的應(yīng)用，因此Spark也可以成為一個用途廣泛的運算引擎，并在未來取代Map/Reduce的地位。

    最后，Spark可以與Hadoop生態(tài)系統(tǒng)的很多組件互相操作。Spark可以運行在新一代資源管理框架YARN上，它還可以讀取已有并存放在Hadoop上的數(shù)據(jù)，這是個非常大的優(yōu)勢。

    雖然Spark具有以上叁大優(yōu)點，但從目前Spark的發(fā)展和應(yīng)用現(xiàn)狀來看，Spark本身也存在很多缺陷，主要包括以下幾個方面：

    –穩(wěn)定性方面，由于代碼質(zhì)量問題，Spark長時間運行會經(jīng)常出錯，在架構(gòu)方面，由于大量數(shù)據(jù)被緩存在RAM中，Java回收垃圾緩慢的情況嚴重，導(dǎo)致Spark性能不穩(wěn)定，在復(fù)雜場景中SQL的性能甚至不如現(xiàn)有的Map/Reduce。

    –不能處理大數(shù)據(jù)，單獨機器處理數(shù)據(jù)過大，或者由于數(shù)據(jù)出現(xiàn)問題導(dǎo)致中間結(jié)果超過RAM的大小時，常常出現(xiàn)RAM空間不足或無法得出結(jié)果。然而，Map/Reduce運算框架可以處理大數(shù)據(jù)，在這方面，Spark不如Map/Reduce運算框架有效。

    –不能支持復(fù)雜的SQL統(tǒng)計；目前Spark支持的SQL語法完整程度還不能應(yīng)用在復(fù)雜數(shù)據(jù)分析中。在可管理性方面，SparkYARN的結(jié)合不完善，這就為使用過程中埋下隱憂，容易出現(xiàn)各種難題。

    雖然Spark活躍在Cloudera、MapR、Hortonworks等眾多知名大數(shù)據(jù)公司，但是如果Spark本身的缺陷得不到及時處理，將會嚴重影響Spark的普及和發(fā)展。本文來源：CDA數(shù)據(jù)分析師培訓官網(wǎng)