為什么Spark在數(shù)據(jù)科學(xué)界這么紅

這篇文章給大家介紹為什么Spark在數(shù)據(jù)科學(xué)界這么紅，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

今天是2019年，要是有誰(shuí)說(shuō)有十年大數(shù)據(jù)工作經(jīng)驗(yàn)，我是不信的。因?yàn)?Spark 正式應(yīng)用才多少年?看過(guò)下面文章的你，應(yīng)該就知道了，2012 年移交  Apache Spark, 就算他是 Spark 的 Committer, 滿打滿算才 7 年。

如果是 2006 年 Hadoop 一代長(zhǎng)老呢，那肯定有 10 年大數(shù)據(jù)經(jīng)驗(yàn)了，但依然只能說(shuō)是半吊子的大數(shù)據(jù)工程師，因?yàn)檎嬲袑?shí)時(shí)大數(shù)據(jù)平臺(tái)的年代，要從  2012 年 Apache Spark 正式推出算起。

Spark 是 Apache 的頂級(jí)項(xiàng)目，一舉一動(dòng)都在整個(gè)社區(qū)的矚目之下。凡是由 Apache 推動(dòng)的項(xiàng)目，自然大概率是比較成功的。回想 Google  當(dāng)年沒(méi)將 Big Table, Map Reduce, GFS 及時(shí)的推廣到 Apache 落地，反而被后來(lái)者 Hadoop  奪得了頭魁，甚為惋惜。想知道Google 錯(cuò)過(guò)這段好時(shí)機(jī)，可以看我的這篇文章《繼螞蟻金服OceanBase之后，騰訊也祭出了大殺技》

最初時(shí)，Spark 孵化于加利福尼亞大學(xué)(University of California) 伯克利分校(Berkeley)的大數(shù)據(jù)實(shí)驗(yàn)室(  AMPLab).說(shuō)起這個(gè)實(shí)驗(yàn)室，還有兩個(gè)巨頭產(chǎn)品， Apache Mesos 和 Alluxio.  看官可能對(duì)這兩產(chǎn)品不是很了解，沒(méi)關(guān)系，這里也不打算講，以后再細(xì)說(shuō)。

2006 年， Hadoop 基于 Google 的三駕馬車(chē)，先于 GCP 而被世人所知。除了分布式存儲(chǔ)擴(kuò)充了商業(yè)關(guān)系型數(shù)據(jù)庫(kù)的存儲(chǔ)容量外，Map  Reduce 更是一大創(chuàng)舉，讓分布式計(jì)算取得了開(kāi)創(chuàng)新的進(jìn)展。但 Map Reduce 的原理注定了它的致命缺陷，中間數(shù)據(jù)集要存盤(pán)，以致于丟失了性能上的戰(zhàn)略牌。被  Spark 的內(nèi)存式彈性分布數(shù)據(jù)集(Resilient Distributed Dataset)撿了個(gè)漏。于是 Spark 于 2009 年橫空出世，彌補(bǔ)了  Hadoop 性能上的缺陷，由此也搶到了一塊市場(chǎng)。

Hadoop 本來(lái)被期望很高，直指機(jī)器學(xué)習(xí)與人工智能，科學(xué)家已經(jīng)嘗試在 Hadoop  上研發(fā)機(jī)器學(xué)習(xí)的軟件庫(kù)，但由于中間數(shù)據(jù)要存盤(pán)的這一致命缺陷，導(dǎo)致最終很多實(shí)時(shí)計(jì)算項(xiàng)目爛尾，而科學(xué)家們?cè)诹硗庖粋€(gè)項(xiàng)目，叫做 Mesos(分布式集群管理)  上取得長(zhǎng)足進(jìn)展，索性在 Mesos 上建立 Spark(分布式計(jì)算) 來(lái)替代 Hadoop.

由此可見(jiàn)，Hadoop 之所以會(huì)被 Spark 打敗，完全是市場(chǎng)新興的訴求(機(jī)器學(xué)習(xí)與人工智能)使然。Spark  的出生，就是為了解決機(jī)器學(xué)習(xí)的困境。

當(dāng)然，說(shuō) Spark 打敗 Hadoop 有些不嚴(yán)謹(jǐn)，就像說(shuō) Apple 的 iOS 打敗 Google 的 Andriod  一樣，兩者是補(bǔ)充，滿足了不同的市場(chǎng)需求而已。Spark 與 Hadoop 在應(yīng)用場(chǎng)景上，只是互相補(bǔ)充罷了，畢竟實(shí)現(xiàn) Spark 的硬件要求比 Hadoop  要高很多，成本也就不一樣了。這些都是廠商不會(huì)直接告訴你的。

Hadoop 先于 Spark 3 年出世，那么做為 Spark 如何快速?gòu)?Hadoop 中奪取屬于自己的市場(chǎng)呢?從頭建立自己的分布式管理，還是利用  Hadoop 已有市場(chǎng)，與 Hadoop 兼容 ，只拋出自己的分布式計(jì)算引擎呢?很顯然， 聰明人都會(huì)選后者，沒(méi)必要從頭建立一個(gè)輪子啊。所以很快的，社區(qū)對(duì)于  Spark 的接受也相當(dāng)輕松。社區(qū)的推廣在很大程度上也助推了 Spark 的應(yīng)用鋪貨。

Spark  流行的基礎(chǔ)原因說(shuō)的差不多了，那再說(shuō)點(diǎn)高級(jí)應(yīng)用。軟件發(fā)生到現(xiàn)在這個(gè)時(shí)間段，真不是哪家軟件能解決某個(gè)問(wèn)題而已了，而是哪家軟件能提供一整套應(yīng)用鏈，就用那家。所以開(kāi)放性就決定了軟件體系能走多遠(yuǎn)。

就跟編程語(yǔ)言一樣的，原本的 Visual FoxPro， Visual Basic， Delphi 本是解決 MIS 系統(tǒng)的最有效編程工具，但隨著  web, mobile 應(yīng)用需求的出現(xiàn)，這些工具再也跟不上需求發(fā)展的步伐了，逐漸就被市場(chǎng)給拋棄了。

縱觀 現(xiàn)在主流的編程語(yǔ)言，Java, Python, 哪一個(gè)不是包羅萬(wàn)象，既可以玩的了 C/S 傳統(tǒng)開(kāi)發(fā)，又駕馭的了 B/S 的潮流，甚至在 mobile  應(yīng)用上也能對(duì)付。Spark 也一樣，除了能玩轉(zhuǎn)數(shù)據(jù) CRUD(Create, Retrieve, Update, Delete)，  更能匹配當(dāng)下數(shù)據(jù)科學(xué)的潮流，比如批量，實(shí)時(shí) ETL， 比如集成各種數(shù)據(jù)分析，數(shù)據(jù)挖掘的算法，高效的去完成機(jī)器學(xué)習(xí)。

Spark 在擁抱內(nèi)存式分布計(jì)算的同時(shí)，順應(yīng)時(shí)勢(shì)間接容納了 Spark Streaming, Spark Machine  Learning(MLlib)Spark SQL 和 Spark GraphX, 這些組件是當(dāng)下互聯(lián)網(wǎng)生態(tài)需求的大綜合，可以說(shuō)整個(gè)數(shù)據(jù)應(yīng)用鏈，Spark  都完美的提供了解決方案，那么它不紅，都沒(méi)理由了!

關(guān)于為什么Spark在數(shù)據(jù)科學(xué)界這么紅就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。