如何進(jìn)行Spark大數(shù)據(jù)分析

如何進(jìn)行Spark大數(shù)據(jù)分析，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

背景

之前的Flask的基礎(chǔ)教程暫時先結(jié)束了。 因?yàn)槟壳八婕暗降臇|西已經(jīng)能夠滿足我的需要。剩下的東西都是根據(jù)需求修改和優(yōu)化。 不涉及更多的東西。 所以我也就是平時維護(hù)著，我們接下來講講Spark，為什么要講Spark呢，因?yàn)槲覀冃阅軠y試的需求要造10億級甚至更多的數(shù)據(jù)。普通的方式肯定不行了，得用到spark提交到y(tǒng)arn上運(yùn)行才跑的動。所以現(xiàn)在我們來談?wù)撜務(wù)摯髷?shù)據(jù)方面的東西。同時大數(shù)據(jù)也是人工智能的基礎(chǔ)，現(xiàn)在搞搞大數(shù)據(jù)的東西，也為以后討論人工智能方面的測試做做鋪墊吧。

起源

萬事開頭難，我剛接觸大數(shù)據(jù)的那會是天天的一臉懵逼。因?yàn)橐郧爸桓鷶?shù)據(jù)庫打過交道，對于hadoop生態(tài)圈完全是沒聽過的狀態(tài)。看資料的時候也根本看不懂。所以我先介紹一下基礎(chǔ)的概念吧。
大數(shù)據(jù)，首先要能存的下大數(shù)據(jù)。 傳統(tǒng)的數(shù)據(jù)庫雖然衍生了主從，分片。但是他們在存儲上也無法應(yīng)對TB甚至PB的數(shù)據(jù)量，尤其是在計(jì)算處理上他們更無法突破單機(jī)計(jì)算的桎梏。因?yàn)槲覀儌鹘y(tǒng)的文件系統(tǒng)是單機(jī)的，不能橫跨不同的機(jī)器。在前些年的時候隨著互聯(lián)網(wǎng)的崛起，我們進(jìn)入了數(shù)據(jù)爆炸的時代。傳統(tǒng)的數(shù)據(jù)存儲方式不論在存儲量上還是計(jì)算性能上都已經(jīng)越來越跟不上數(shù)據(jù)發(fā)展的速度了。當(dāng)時開發(fā)一個新的方式處理數(shù)據(jù)在業(yè)界呼聲很高。之后在04年(好像是吧，記不清了）Google發(fā)表了論文--MapReduce，詳細(xì)講述了Google的分布式計(jì)算原理。這時候業(yè)界才發(fā)現(xiàn)原來數(shù)據(jù)還可以這么玩，但是Google的良心大大滴壞，他只發(fā)了論文但是沒有開源，這把一干人等急的抓耳撓腮，后來Apache組織了一幫人根據(jù)Google的論文糊出了一個hadoop。直到現(xiàn)在hadoop生態(tài)已經(jīng)發(fā)展了10余年(是的沒錯，我們現(xiàn)在看的很高大上的hadoop技術(shù)是人家Google玩剩下的)。

Hadoop 的出現(xiàn)

先前說我們傳統(tǒng)的文件系統(tǒng)是單機(jī)的，無法橫跨不同的機(jī)器。而HDFS的出現(xiàn)(Hadoop Distributed FileSystem)，打破了我們單機(jī)的限制。HDFS是Apache專門研發(fā)的分布式文件系統(tǒng)。設(shè)計(jì)本質(zhì)上是為了大量的數(shù)據(jù)能橫跨成百上千臺機(jī)器，但是你看到的是一個文件系統(tǒng)而不是多個。比如說我要取/hdfs/gaofei/file1上的數(shù)據(jù)。你引用的是一個文件路徑，但是實(shí)際的數(shù)據(jù)是存放在很多個不同的機(jī)器上的。作為用戶，我們不知道實(shí)際的物理存儲結(jié)構(gòu)，我們知道的只要暴露給我們的邏輯路徑。那么在我們有能力存在這么大的數(shù)據(jù)后，就開始考慮怎么處理數(shù)據(jù)了。 雖然HDFS幫助我們管理不同機(jī)器上的數(shù)據(jù)并抽象一個統(tǒng)一接口給我們。但是這仍然改變不了這些數(shù)據(jù)非常大的事實(shí)。 如果我們?nèi)匀皇窃谝慌_機(jī)器上處理這海量的數(shù)據(jù)，那性能上仍然是不可接受的。那么如果我們要在多臺機(jī)器上同時處理這些數(shù)據(jù)，就面臨了一個機(jī)器之間如何通信和調(diào)度的問題。 這就是MapReduce/Spark的功能。MapReduce是第一代的產(chǎn)物，Apache研發(fā)的hadoop就是基于MapReduce框架(根據(jù)Google的論文而來)。Spark是第二代。 MapReduce采用了很簡化的模型，只有Map和Reduce兩個計(jì)算過程（中間用shuffle串聯(lián)）。

MapReduce

那什么是MapReduce呢， 舉個最常用的wordcount的例子。 假如你需要統(tǒng)計(jì)一個巨大的文件中所有單詞出現(xiàn)的詞頻。 首先你需要很多臺機(jī)器同時并發(fā)的讀取這個文件的各個部分，分別把自己讀到的部分進(jìn)行第一步計(jì)算。 假如在這臺機(jī)器上，我讀取了一部分?jǐn)?shù)據(jù)，對這些數(shù)據(jù)統(tǒng)計(jì)出了類似（Hello--100次）（word--1000次）這樣的結(jié)果。 每臺機(jī)器都讀取了部分?jǐn)?shù)據(jù)并做了相同的操作。這就是MapReduce中的Map階段(額，中間其實(shí)還有別的操作，恕我學(xué)藝不精，解釋不清了)。然后我們進(jìn)入Reduce階段，這個階段也會并發(fā)啟動很多的機(jī)器，框架會將Map機(jī)器上的數(shù)據(jù)按一定規(guī)則分別放到這些Reduce機(jī)器上進(jìn)行計(jì)算。 例如我們把所有Hello這個單詞的放在ReduceA上，把所有word這個單詞的數(shù)據(jù)放到ReduceB上。然后ReduceA匯總所有的Map數(shù)據(jù)中的Hello這個單詞的結(jié)果，計(jì)算出這個單詞在數(shù)據(jù)中出現(xiàn)的詞頻為1000次。 ReduceB匯總所有Word這個單詞并計(jì)算出它在數(shù)據(jù)中出現(xiàn)的詞頻為1000次。這樣我們就統(tǒng)計(jì)出了這個巨大文件的詞頻了。 這就是MapReduce， 可以簡單理解為Map階段并發(fā)機(jī)器讀取不同的數(shù)據(jù)塊做第一步處理，然后Reduce階段并發(fā)機(jī)器按規(guī)則匯總Map階段的數(shù)據(jù)做第二部處理。中間有個很重要的過程是shuffle，暫時可以理解為這個shuffle就是哪些Map的數(shù)據(jù)放到哪個Reduce上的規(guī)則過程。詳細(xì)的不表示了，shuffle這個東西有點(diǎn)復(fù)雜，我們之后再講。

Spark

MapReduce的模型簡單暴力，但是程序?qū)懫饋碚媛闊?。因?yàn)槿砍绦騿T編碼，框架只是提供了Map和Reduce的函數(shù)，至于里面什么邏輯全靠你自己寫。于是有了pig和Hive。Pig我沒怎么了解過，Hive是基于SQL的，它們把SQL翻譯成的MapReduce程序。有了Hive以后，大家發(fā)現(xiàn)Sql實(shí)在太容易寫了，這比寫java代碼方便太多了。例如我司的產(chǎn)品中，專門有一個算子是sql，可以讓業(yè)務(wù)人員也sql做拼表的動作。但是我們發(fā)現(xiàn)Hive在MapReduce上跑的特別慢，這個實(shí)在讓人接受不了。 于是中間又經(jīng)過了幾個引擎的進(jìn)化，Spark和SparkSQL應(yīng)運(yùn)而生。Spark不僅擁有新一代的計(jì)算引擎(跑的更快)，而且內(nèi)置了很多的方法供你操作數(shù)據(jù)，我們編寫起程序來現(xiàn)在變的更快更簡單。假如我們有這么一個需求，統(tǒng)計(jì)一個文件中a，b這兩個字母出現(xiàn)的單詞有多少個。 可以像下面這樣寫：

numAs和numBs就是我們統(tǒng)計(jì)的結(jié)果。可以看到spark提供了filter這種過濾函數(shù)和count這種內(nèi)置的統(tǒng)計(jì)數(shù)量函數(shù)。 我們不再像以前MapReduce一樣要寫那么多的邏輯。 同時SparkSQL也支持了我們把SQL翻譯成代碼的功

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注億速云行業(yè)資訊頻道，感謝您對億速云的支持。