本文編輯整理自【微學(xué)堂】第二十六期活動(dòng)實(shí)錄。

嘉賓介紹：孟碩

擅長(zhǎng)技術(shù)：基于Hadoop,，Spark分布式平臺(tái)的數(shù)據(jù)分析,，業(yè)務(wù)開發(fā)與模型搭建。參與公司電商行業(yè)、交通運(yùn)輸行業(yè)數(shù)據(jù)變現(xiàn)項(xiàng)目?，F(xiàn)任職于云和恩墨教育產(chǎn)品部,，負(fù)責(zé)大數(shù)據(jù)產(chǎn)品研發(fā)和交付。加入云和恩墨之前,，曾在Oracle研究與開發(fā)（北京）中心供職5年,，在Oracle解決方案中心擔(dān)任 Oracle大數(shù)據(jù)一體機(jī)產(chǎn)品 Big Data Appliance(BDA)咨詢顧問，期間接觸大量一線大數(shù)據(jù)應(yīng)用案例,，同時(shí)取得國(guó)際商業(yè)大數(shù)據(jù)領(lǐng)導(dǎo)公司 Cloudera管理員,、Spark開發(fā)認(rèn)證，并經(jīng)過選拔成為Cloudera ACTP認(rèn)證講師資質(zhì),。在此之前曾任職于中科紅旗（RedFlag-Linux）操作系統(tǒng)服務(wù)器組,，負(fù)責(zé)操作系統(tǒng)安全、虛擬化產(chǎn)品自動(dòng)化測(cè)試套件開發(fā),。

直播實(shí)錄Spark 2.0+版本的技術(shù)路線分享：

大家好,，今天我們講的主要的主題就是這個(gè)spark，剛才發(fā)了一張圖片,，那一會(huì)兒呢我還會(huì)轉(zhuǎn)發(fā)一次,，你們大家這個(gè)太熱情了刷屏已經(jīng)把那張圖片給淹沒。希望大家盡量在講的過程中有問題可以隨時(shí)提問,，為了大家能夠更清楚地看到圖片,，就不要再刷屏了，謝謝大家的配合,。

說起spark我就不得不提這篇論文，那么它和之前google的三駕馬車,、google file system,，也就是后來的HDFS，還有MapReduce以及google big table就是后來HBase,，奠定了整個(gè)大數(shù)據(jù)的基礎(chǔ)設(shè)施這個(gè)軟件的基礎(chǔ),。那我們?cè)谥v起spark的時(shí)候，它的由來也是因?yàn)槭沁@篇論文,。

我們看這篇論文的標(biāo)題,。他其實(shí)和spark沒有任何關(guān)系。他這個(gè)標(biāo)題主要是寫的是Resilient Distributed Datasets也是講一個(gè)彈性分布式數(shù)據(jù)集,。這就是我們?cè)诹膕park時(shí)技術(shù)經(jīng)常說起的RDD,。那spark和RDD究竟是一個(gè)什么樣的關(guān)系呢,？其實(shí)他在第一個(gè)自然段里邊已經(jīng)說了,，那一會(huì)兒我會(huì)給大家放大來看,。上一張圖主要是讓大家看清楚這篇論文的大概的全貌。一會(huì)兒我會(huì)分別摘出來幾個(gè)比較有用的句子,，方便大家回去再看,。在其中第一個(gè)自然段最后倒數(shù)第二句話，他就明確的寫了,，我們通過這個(gè)知道,，他就是一個(gè)彈性分布式數(shù)據(jù)集。

我發(fā)的第二張圖片就是把那句話重點(diǎn)給你講出來了,，就是說我們把這個(gè)彈性分布式數(shù)據(jù)集,，這種基于內(nèi)存的分布式的架構(gòu)實(shí)現(xiàn)出來一個(gè)產(chǎn)品,，那么我們把這個(gè)產(chǎn)品的名字就叫spark,。這就是我們這個(gè)論文第一段的重點(diǎn),。那spark和RDD的關(guān)系,，就是一個(gè)是她背后的架構(gòu),，那么實(shí)現(xiàn)出來一個(gè)產(chǎn)品就是spark,，那這就是spark和RDD的之間的關(guān)系,。

每一項(xiàng)新的技術(shù)產(chǎn)生都有它的一個(gè)背后的推動(dòng)力。就像大數(shù)據(jù)基礎(chǔ)設(shè)施Hadoop,，它包含這么幾個(gè)組件HDFS,、MapReduce。它產(chǎn)生的背后的動(dòng)力就是因?yàn)?，第一家遇到大量?shù)據(jù)存儲(chǔ)和處理的公司就是google,，那么他面臨大量數(shù)據(jù)處理首先就是要存儲(chǔ)它，那么HDFS,，接下來就是要處理這么大量的數(shù)據(jù)，他發(fā)明了一個(gè)分布式計(jì)算框架,，叫MapReduce,。這是被業(yè)務(wù)推動(dòng)而產(chǎn)生的兩項(xiàng)技術(shù)。

那么spark它是基于什么樣的業(yè)務(wù)需求,，這么迫切才產(chǎn)生了這樣一個(gè)比較神奇的組件,。如果你了解大數(shù)據(jù),，但是不知道spark這個(gè)組件的話，那就感覺好像沒有深入了解過大數(shù)據(jù)一樣,。那么接下來這張圖就是講一下整個(gè)spark這個(gè)組件被發(fā)明或者是被設(shè)計(jì)出來的一個(gè)原動(dòng)力,。

很抱歉開篇就拋出來大段大段的英文,。這個(gè)主要就是為了讓大家了解原汁原味的,，各種技術(shù)的起源，而不是去讀一些被人翻譯過來的,，不能完整表達(dá)出原文意思的那些文章,。那我也推薦大家去讀一些英文的文檔因?yàn)榇髷?shù)據(jù)畢竟是一個(gè)更新迭代速度特別快的一個(gè)領(lǐng)域。那如果想掌握最新最一手的技術(shù),，還是繞不開要讀一些這個(gè)英文的文檔,。這段英文來自于spark的這個(gè)最基礎(chǔ)的一篇論文。大家可以看一看他沒有代碼,，只是詳細(xì)描述了他的產(chǎn)生和他的設(shè)計(jì),。最后還有一些評(píng)測(cè)，大家確實(shí)是值得一讀,。

我們可以看出整個(gè)spark的產(chǎn)生是直擊之前的傳統(tǒng)的基于分布式的計(jì)算框架MapReduce的一些缺點(diǎn)而設(shè)計(jì)的,。那我們看看究竟是哪里的缺點(diǎn)，紅色框出來的部分大家可以稍微的讀一讀,。第一個(gè)就是數(shù)據(jù)重用在許多迭代的機(jī)器學(xué)習(xí)計(jì)算里邊或者是圖像計(jì)算里面,，這里邊他舉出來了兩個(gè)機(jī)器學(xué)習(xí)經(jīng)典的例子一個(gè)是PageRank，還有K-means還有邏輯回歸這些算法,，那么另外一個(gè)呢就是要交互式的數(shù)據(jù)挖掘,。那這些都是要求你的計(jì)算框架反應(yīng)速度特別快，這恰恰就是MapReduce的弱項(xiàng),。

所以就有了剛才我發(fā)的第一張圖，那現(xiàn)在我們說spark會(huì)取代Hadoop,。其實(shí)本質(zhì)的意義上來說spark和Hadoop并不是一個(gè)層級(jí)上的概念,。我們知道Hadoop，如果狹義的理解,，他是一個(gè)軟件,，這個(gè)軟件里面包含三個(gè)組件。一個(gè)是解決大數(shù)據(jù)分布式存儲(chǔ)的HDFS,，另外一個(gè)就是分布式計(jì)算的MapReduce,，還有一個(gè)資源調(diào)度器，是在Hadoop版本二里邊從MapReduce分離出來的,，專門用作資源管理的這么一個(gè)組件,。那spark他取代的部分只是這個(gè)分布式計(jì)算,，負(fù)責(zé)計(jì)算的這個(gè)組件就是MapReduce，而不是其他的HDFS或者是YARN,。

這張圖是經(jīng)常拿來做對(duì)比的。也就是我們spark和Hadoop里邊的MapReduce,，這里邊他寫的還是很嚴(yán)謹(jǐn),。spark對(duì)比的不是整個(gè)Hadoop，而是Hadoop里邊的計(jì)算框架MapReduce,，他們倆執(zhí)行的時(shí)間,、執(zhí)行效率這么一個(gè)對(duì)比。相同的任務(wù)spark要比MapReduce要快這么多,。那接下來我們就可以來說一說為什么而會(huì)比MapReduce快這么多,。

了解過MapReduce的同學(xué)可能知道MapReduce他也是來自于google的那篇論文MapReduce，一個(gè)基于分布式架構(gòu)的計(jì)算控件,。那他的名字的由來就是來自于函數(shù)式編程的兩個(gè)函數(shù),，一個(gè)是Map，一個(gè)是Reduce,。那他之所以執(zhí)行這么慢就是因?yàn)樗@種簡(jiǎn)單,，雖然強(qiáng)大但是他的邏輯流程比較簡(jiǎn)單，它的過程只分一個(gè)Mapper和一個(gè)Reducer,。那么程序員只能夠定制化他的Mapper函數(shù)或者是Reducer函數(shù),。那他主要是慢在它的Mapper產(chǎn)生的中間結(jié)果要傳到Reducer之前是要落在本地磁盤上的。

這張圖就描述了MapReduce也就是我們之前傳統(tǒng)的分布式計(jì)算框架，他的執(zhí)行的一個(gè)流程,。那我們看看他要處理一個(gè)文件也就是input file,，他會(huì)根據(jù)文件格式的不同，比如說我們要處理一個(gè)文本文件,，那他就是TEXT Format,，也就是文本文件的格式。如果你這個(gè)文件格式在HDFS也就是分布式存儲(chǔ)上分為三個(gè)塊,，那么他就會(huì)分別在三臺(tái)不同的機(jī)器,，前提是你這個(gè)三個(gè)塊是分布在三臺(tái)機(jī)上。那我們新型分布式計(jì)算架構(gòu)是要讓計(jì)算去尋找數(shù)據(jù),，所以他就會(huì)在這三臺(tái)機(jī)上分別啟動(dòng)MapReduce的Mapper程序,。那我們看看接下來他這幾個(gè)流程。

首先是Record Reader,，她會(huì)把讀取你blog里面的內(nèi)容之后交給Mapper函數(shù),，Mapper函數(shù)是我們用戶自定義函數(shù),，你可以對(duì)數(shù)據(jù)做一個(gè)任何的處理，最后把數(shù)據(jù)交給Partitioner把數(shù)據(jù)分類,。那么相同的數(shù)據(jù)交給Reduce去處理,，這就是最后Reduce根據(jù)指令做一個(gè)匯總或者聚合的一些操作，最后把計(jì)算結(jié)果存儲(chǔ)HDFS上或者是你指定的路徑下,。那整個(gè)她的這個(gè)過程只能跑一次,，也就是一次Mapper，然后中間Shuffle and Sort,，最后是Reduce,，不能進(jìn)行迭代，如果要進(jìn)行迭代,，必須依賴第三方的組件去操作,。

所以總結(jié)起來說MapReduce中間結(jié)果羅盤，最后還要落盤,。如果你要反復(fù)的迭代依賴于第三方的調(diào)度,，那反反復(fù)復(fù)迭代次數(shù)越多他落盤的次數(shù)越多，那這樣的話就造成它的速度嚴(yán)重的緩慢,。我們說計(jì)算機(jī)如果按照資源來分,，他有這么幾個(gè)資源，一個(gè)是存儲(chǔ)資源就是磁盤,，計(jì)算資源就是CPU還有內(nèi)存,。這三塊，磁盤,、內(nèi)存和CPU,，說起來他們都是有存儲(chǔ)的。那我們CPU里有cache,，memory就是一個(gè)速度比較快的存儲(chǔ),，那磁盤更不用說他就是永久保存數(shù)據(jù)的，如果把數(shù)量級(jí)提升到秒,，那我們的CPU開始存儲(chǔ)一個(gè)數(shù)據(jù),，如果用了一秒鐘的話，那我們內(nèi)存是一個(gè)什么樣的數(shù)量級(jí)呢,？

內(nèi)存的數(shù)量級(jí),，存儲(chǔ)數(shù)據(jù)的數(shù)量級(jí)，同樣的內(nèi)容如果CPU cache用了一秒鐘,，內(nèi)存就會(huì)用十幾秒的時(shí)間,，那我們磁盤可能就需要一個(gè)月這樣子長(zhǎng)的一個(gè)數(shù)量級(jí)。所以說磁盤IO,，在大數(shù)據(jù)或者是任何一個(gè)我們不管是傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)的應(yīng)用,，都是一個(gè)盡量避免的操作,，就是要避免磁盤IO。

所以說我們回過頭再看spark產(chǎn)生的這個(gè)原動(dòng)力這張圖,，我們就能更清晰地了解到，為什么這個(gè)spark會(huì)取代MapReduce,。他確實(shí)指向的就是MapReduce一個(gè)痛點(diǎn),，那第一個(gè)就是數(shù)據(jù)重用。因?yàn)槟阈枰岩徊糠謹(jǐn)?shù)據(jù)集反復(fù)地對(duì)他進(jìn)行計(jì)算,，如果要MapReduce有什么他不會(huì)把它存在內(nèi)存里而是磁盤上,，反復(fù)的讀取大量的磁盤IO就會(huì)造成他讀寫的緩慢。那這正是一些機(jī)器學(xué)習(xí)的算法經(jīng)常用的一些迭代,，讓他迭代次數(shù)越多他可能得出來的值就越準(zhǔn),。另外一個(gè)交互式呢。MapReduce整個(gè)的作業(yè)是一個(gè)面向批處理,，而不是交互式,。

所以這個(gè)spark她就是一個(gè)基于內(nèi)存的彈性分布式數(shù)據(jù)集。而且它的計(jì)算的邏輯不是分為一個(gè)Mapper階段一Reducer階段,，是能夠根據(jù)你的數(shù)據(jù)經(jīng)過不同的操作步驟,，這樣比MapReduce更靈活。

所以總結(jié)起來說,，spark因?yàn)槭腔趦?nèi)存的分布式計(jì)算架構(gòu),，他要比MapReduce基于磁盤的分布式計(jì)算的架構(gòu)要快很多。那我們剛才兩個(gè)計(jì)算框架做對(duì)比的那張圖,，其實(shí)不是特別嚴(yán)謹(jǐn),。為什么呢，大家可能也想到了,，因?yàn)榈谝淮巫x取數(shù)據(jù)就是你在啟動(dòng)MapReduce或者spark程序的時(shí)候,。在第一次去執(zhí)行計(jì)算都是從HDFS或者是你的磁盤上去讀取數(shù)據(jù)。那處理一次他的這個(gè)執(zhí)行的速度可能還沒有快那么多,。那么spark他的一個(gè)強(qiáng)項(xiàng)，就是在迭代,。因?yàn)樗褦?shù)據(jù)放在內(nèi)存里面,，所以迭代次數(shù)越多，他就越快,，因?yàn)槊恳惠喫却疟P快很多

大家可以看這張圖，這張圖來自于我剛才提到的那篇論文,。這個(gè)就做的比較嚴(yán)謹(jǐn),，它是利用了兩個(gè)算法,，一個(gè)是Logistic Regression還有一個(gè)是K-mean，就是邏輯回歸和這個(gè)分類的算法,。咱們先說橫軸表示三個(gè)產(chǎn)品一個(gè)是Hadoop里邊的MapReduce中間那個(gè)咱們就不要管了,，已經(jīng)被淘汰了你看那么慢，那肯定要被淘汰,。最后一個(gè)就是我們的spark,。那豎軸就是代表的執(zhí)行時(shí)間。一個(gè)邏輯回歸的任務(wù),，當(dāng)然是相同的,，灰色柱狀圖表示第一次迭代，那么黑色柱狀圖表示后續(xù)的迭代,。

我們可以看看第一次迭代,，相同的任務(wù)Hadoop用了80，spark用了46,，并沒有傳說中的快一百倍,。那相反后續(xù)迭代。他的spark優(yōu)勢(shì)才逐漸顯現(xiàn),，那我們Hadoop是用了76,。這個(gè)可以理解因?yàn)樗看味悸浔P，那他的這個(gè)速度的提升不會(huì)那么明顯,。之所以比他慢了一些可能是因?yàn)樽隽薍DFS的cache,。那我們看spark他的這個(gè)速度，他所用的時(shí)間只用了三秒,。那這就是后續(xù)迭代比它快的地方,。所以我們今后再說，如果要是spark比Hadoop的哪兒快一百倍,，這樣的說法是不嚴(yán)謹(jǐn)?shù)?。那最?yán)謹(jǐn)?shù)恼f法是首次迭代還是后續(xù)迭。

再有什么問題也可以隨時(shí)提出來,，然后我們可以一起討論,。

說完spark和傳統(tǒng)的分布式計(jì)算框架MapReduce對(duì)比之后,。那我們就來深入的理解一下spark,。因?yàn)樗暮笈_(tái)，就是產(chǎn)品背后的設(shè)計(jì)架構(gòu)是基于RDD的,，所以說我們就來先來了解一下RDD這個(gè)彈性分布式數(shù)據(jù)集,。那我們首先說彈性，彈性他給的解釋就是如果數(shù)據(jù)在內(nèi)存中丟失，那么他能夠被重建,。這個(gè)是基于spark的一個(gè)原理,，那他本質(zhì)上還是從HDFS上去讀取數(shù)據(jù)。那如果把數(shù)據(jù)緩存到內(nèi)存中,，這部分?jǐn)?shù)據(jù)如果因?yàn)閱吸c(diǎn)故障或者是機(jī)器的一些故障原因丟失了會(huì)怎么辦,？

他的做法和其他的基于內(nèi)存的分布式計(jì)算框架。這里我要解釋一點(diǎn),，就是基于內(nèi)存的分布式計(jì)算這種產(chǎn)品也不是只有死spark一家,，那他跟其他的分布式內(nèi)存計(jì)算框架相比，這個(gè)spark他是一個(gè)粗粒度的,，就是說他不會(huì)把你的數(shù)據(jù)緩存到內(nèi)存里做一個(gè)多份拷貝保證它的安全性,。他完全不在乎你這個(gè)數(shù)據(jù)丟失或者gvm kill掉怎么辦，那為什么說到gvm,，一會(huì)我們?cè)儆懻撨@個(gè),。他不管你這個(gè)數(shù)據(jù)，突然丟掉了怎么辦,，因?yàn)樗麜?huì)把他的計(jì)算的過程給保留下來,。

什么意思呢？就是說他還是依靠,因?yàn)槟愕臄?shù)據(jù)是從底層HDFS東西過來或者是其他分布式文件系統(tǒng),。那既然你原始的數(shù)據(jù)還在那么我只要記錄出來我的整個(gè)計(jì)算的過程,，或者計(jì)算的步驟，那我就能夠了,。大不了就把數(shù)據(jù)從磁盤上在錄出來或者從庫(kù)里再把它拽出來,，重算一遍就好了。所以說這個(gè)RDD,，他雖然是一個(gè)基于內(nèi)存的一小塊兒存儲(chǔ)數(shù)據(jù)的一個(gè)數(shù)據(jù)結(jié)構(gòu),，它本質(zhì)上還是要從磁盤上去讀取文件，通過一系列的轉(zhuǎn)換過程,，然后才到你丟失的那個(gè)點(diǎn),，他是通過這種方式去保障他的數(shù)據(jù)。

所以說我們把文件從磁盤放到內(nèi)存里,，這部分內(nèi)存的這個(gè)結(jié)構(gòu)，我們就叫他RDD,。有同學(xué)可能會(huì)問說既然你在HDFS上,，也就是說分布式文件系統(tǒng)上的這個(gè)文件都是在不同機(jī)器上存的，那你這些內(nèi)存他彼此看不見,，他都叫RDD嗎？那我這可以詳細(xì)的說一說，每一臺(tái)機(jī)器上那小塊內(nèi)存,，比如說咱們打個(gè)比方,，你有一個(gè)文件是西游記，那前三十章假如說前三分之一的內(nèi)容存在A節(jié)點(diǎn),。中間三十章存在B節(jié)點(diǎn),，后三分之一的部分，假如說是取到真經(jīng)是放在C節(jié)點(diǎn),。

接下來你寫了一個(gè)spark程序要處理這個(gè)西游記,，你要統(tǒng)計(jì)一下這個(gè)吳承恩他最喜歡用哪些單詞，那這種情況就需要把ABC三臺(tái)節(jié)點(diǎn)的西游記上中下部分都給提出來,。那每一個(gè)機(jī)器上分布的一塊兒內(nèi)容錄到內(nèi)存里邊都叫RDD一個(gè)分區(qū),。ABC三個(gè)節(jié)點(diǎn)所有的分區(qū)加起來。就叫做一個(gè)RDD,，那這就是一整個(gè)RDD,。

張圖所描述的是創(chuàng)建RDD的三種方式。第一個(gè)就是從文件或者是從一堆文件,，第二個(gè)是從內(nèi)存,，第三個(gè)是從其他RDD，那從文件我們剛才已經(jīng)舉了一個(gè)例子了,。那從內(nèi)存呢,，比如說你的數(shù)據(jù)已經(jīng)被緩存到內(nèi)存里，或者是從這個(gè)消息中間件,，當(dāng)然也是內(nèi)存的數(shù)據(jù)傳過來的,，那或者是你做了一個(gè)轉(zhuǎn)換，比如說你把西游記上中下錄到內(nèi)存里之后,，你把它標(biāo)點(diǎn)符號(hào)全都去掉了,，那這就是一個(gè)轉(zhuǎn)換。也就是說你轉(zhuǎn)換過來的那個(gè)RDD就是從其他最原始的那個(gè)RDD創(chuàng)建過來的.

這就是我們?cè)谑菃?dòng)spark里面創(chuàng)建一個(gè)RDD的過程,。那我這里邊呢，也正好有一臺(tái)虛擬機(jī),，我可以給大家看一看啟動(dòng)spark他究竟是一個(gè)什么樣子,。然后呢我們先來對(duì)spark的版本做一個(gè)介紹。spark從最初的版本到現(xiàn)在最新是2.1的版本,，那之前最常用的版本是2.6,。那spark他其實(shí)從1點(diǎn)幾之后到2點(diǎn)幾這個(gè)版本他是有一個(gè)自己的發(fā)展的里程碑的。的每一步發(fā)展,，也是有前期規(guī)劃,，比如說他從1.3版本之后就陸續(xù)的加入鮮新的功能來保障spark在整個(gè)分布式計(jì)算的領(lǐng)域一統(tǒng)江湖的地位。

這個(gè)就是我在虛擬機(jī)上剛剛敲了一個(gè)pyspark,，也就是用python去運(yùn)行spark的一個(gè)命令,。我們當(dāng)前剛裝了一個(gè)最新版本的2.1.0。再解釋一下pythonspark這個(gè)概念,，這個(gè)到終端的啟動(dòng)命令是pyspark,，他如果從代碼上來說，按代碼行數(shù)來說,他七十五行數(shù)的開發(fā)語言是Scala語言,，那百分之十五是Java語言,，剩下百分之十是R語言和python語言。那就是說她支持你用四種開發(fā)語言,，而且它還支持你用交互式的這種方式去開發(fā)程序,。就跟Python是一樣。那我現(xiàn)在進(jìn)入的就是用python語言去交互式的了解spark,。

舉個(gè)例子，就是分別用python和Scala這兩種終端,，交互式的去進(jìn)入跟spark這個(gè)組件去編寫一些程序,。那這個(gè)大家如果有興趣的可以去找個(gè)spark然后只要解壓出來就可以運(yùn)行。前提是你安裝了java的GDK,，那之前我們?cè)诹私鈙park運(yùn)行的時(shí)候說跟建偉GVM有關(guān)系的,，因?yàn)檫@個(gè)Scala的開發(fā)語言的跟java很像。整個(gè)spark程序也是運(yùn)行在java虛擬機(jī)之上的,。那所以說我們這個(gè)SPARK和JAVA語言還是有淵源的,，也是Scala語言和java也是有一定淵源。這就涉及到整個(gè)這個(gè)Scala語言的一些特性我們可以稍微再說一說,。

接下來說函數(shù)式編程語言在spark的應(yīng)用。那我們知道函數(shù)式編程語言其實(shí)發(fā)明了很早,，早在上個(gè)世紀(jì)四幾年五幾年的時(shí)候就有了各種各樣的函數(shù)式編程語言,。那為什么在大數(shù)據(jù)時(shí)代才又從重新回到了咱們這個(gè)整個(gè)技術(shù)圈兒里最火熱的領(lǐng)域里邊，那就是因?yàn)楹瘮?shù)式編程語言里面有很多比較好的特性,，特別適用在分布式程序開發(fā)里面,，比如說我們的函數(shù)式編程語言里邊是沒有變量的。那他怎么表示a=1,我要把a(bǔ)加上1變成a等于二呢,，那就是你再新定義一個(gè)變量讓a2等于a1,，a加上一。

那我們程序需要記錄的就是你的a2是通過a這個(gè)變量加上一得到,。那我們這個(gè)a2和a他倆就有一定的血緣關(guān)系,。那所謂的這種血緣關(guān)系就是繼承關(guān)系,。這在我們大數(shù)據(jù)里面或者是在數(shù)據(jù)這個(gè)領(lǐng)域里邊就叫數(shù)據(jù)沿襲，這個(gè)概念如果你要是閱讀大數(shù)據(jù)的一些文章也是經(jīng)常能夠看到,。

python和Scala還有java在版本8之后都是支持這種函數(shù)式編程的寫法以及這個(gè)所謂的匿名函數(shù)這種寫法。因?yàn)樵诤瘮?shù)式編程語言里面函數(shù)是一等公民,，大家可以回去了解一下這個(gè)函數(shù)式編程語言，匿名函數(shù)這些概念,。這些概念都是對(duì)你在分布式計(jì)算框架上寫程序都是很有幫助的,。那就拿java來講，我們傳統(tǒng)的那些編程的方式我們管它叫指令式編程,。那現(xiàn)在的這種函數(shù)式編程和指令式編程有什么差別呢,？我們可以看下一張圖。

這張圖雖然講的是這個(gè)spark和 MapReduce程序之間他們倆的簡(jiǎn)練程度,，spark程序其實(shí)是一個(gè)用python的函數(shù)式編程的寫法去寫一個(gè)所謂詞頻統(tǒng)計(jì)的那個(gè)程序，最后把它存到我output這個(gè)文件夾里面,。下邊整段代碼實(shí)現(xiàn)的是同樣一個(gè)功能,。那上面的完全采用是函數(shù)式編程的寫法，大家看每一個(gè)函數(shù)后面括號(hào)里面第一個(gè)是lambda,，是匿名函數(shù)的這么一個(gè)代名詞,。那這樣寫的其實(shí)還是給面子的，我們看每一個(gè)點(diǎn)兒,，下邊這些行有縮進(jìn)然后還每個(gè)點(diǎn)兒,，其實(shí)他是可以被寫在一行。那下面用java傳統(tǒng)的語言是這么多行,。

今天因?yàn)闀r(shí)間關(guān)系,咱就先不繼續(xù)深入的去討論這些,，大家可以先了解一下這些概念深入去學(xué)習(xí)。那也可以來恩墨學(xué)院和我們進(jìn)行交流,。而spark里面涉及的一些技術(shù),，大家可以回去再看一看，我先把這些名詞給大家倒騰一遍,。那后來有spark的RDD,是SPARK后臺(tái)的一個(gè)數(shù)據(jù)結(jié)構(gòu),，那有RDD之后他會(huì)做用一系列函數(shù)對(duì)這個(gè)RDD做一個(gè)轉(zhuǎn)換。

后邊有streaming,，就是Dstream,，就是他的一個(gè)在流逝計(jì)算里邊他的一個(gè)分布式的內(nèi)存的一個(gè)架構(gòu)。那我接下來主要講的是在1.6版本以后新加入的一個(gè)功能,。那這個(gè)功能就是spark SQL,。那么先來看一看這個(gè)spark SQL,，他也一樣是有論文去支撐的，這個(gè)是spark 最重要的一個(gè)轉(zhuǎn)變,。

Spark SQL和Spark GraphX還有SparkStreaming還有Spark MLLIB被他們并稱為spark 的四個(gè)組件,spark 的四大金剛。那我要說的就是這個(gè)是spark SQL,。他的出現(xiàn)的意義為什么這么重大呢,？那我們可以先來了解一下我們比較熟的一個(gè)概念就是這個(gè)SQL。我們哪像還是我們那個(gè)思路,，每一項(xiàng)新的技術(shù)推出來他都是有背后的源動(dòng)力的,。那我們看看這個(gè)spark SQL，它的推出的原動(dòng)力是什么,？

我還是要貼出來一段英文，這個(gè)就是spark SQL出現(xiàn)的產(chǎn)生的背景的這么一段話,，也來自最上面我貼出來的那篇論文,。那么來看一看這段話，就是說我們?cè)趥鹘y(tǒng)的應(yīng)用里邊SQL的朋友圈兒是很大的,。那基本上我們傳統(tǒng)的用就是DD加上SQL,，那中間再加一個(gè)中間件所謂的三層架構(gòu)。那既然我們之前SQL他代表的是對(duì)結(jié)構(gòu)化數(shù)據(jù)的一個(gè)處理,，那傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)是處理這種數(shù)據(jù)的最主要的一個(gè)應(yīng)用,。那他就在大數(shù)據(jù)時(shí)代就有兩個(gè)缺點(diǎn)或者是兩個(gè)不足的地方。

不足的地方在我們這里邊分別寫了,，那么第一是用戶想要執(zhí)行一些ETL,，他會(huì)從不同的數(shù)據(jù)源去來搜集一些半結(jié)構(gòu)化或者非結(jié)構(gòu)化說白了就是大量的日志。那需要我們用戶自定義編碼,，說白了就是你要寫程序,。那第二用戶想要去執(zhí)行一些高級(jí)的分析，比如說機(jī)器學(xué)習(xí)或者圖像處理,。那這些都是傳統(tǒng)結(jié)構(gòu)化語言或者SQL或者是這個(gè)關(guān)系型數(shù)據(jù)庫(kù)他的能量所不及的地方,。就是傳統(tǒng)的這個(gè)處理結(jié)果話數(shù)據(jù)，那它這也有短板,，比如說處理這些日志他就顯得力不從心,，因?yàn)橐恍C(jī)器學(xué)習(xí)算法他也打不到。

那你有的這些不就是恰恰spark這個(gè)組件他所擅長(zhǎng)的嗎,，因?yàn)槲壹扔羞@個(gè)機(jī)器學(xué)習(xí)的庫(kù)又能夠讓用戶提供編碼,。那既然你spark有這么強(qiáng)大那你直接用spark不就好了嗎？但是呢我們別忘了這個(gè)傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)對(duì)結(jié)構(gòu)化處理數(shù)據(jù)處理的能力依然是讓人很羨慕,。那如果spark要是把這個(gè)能力吸收進(jìn)來,，那就是會(huì)一統(tǒng)數(shù)據(jù)的江湖,。那我們整個(gè)數(shù)據(jù)從技術(shù)語言來說就是分為結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)據(jù)。那從業(yè)務(wù)語言來說,，結(jié)構(gòu)化數(shù)據(jù)對(duì)應(yīng)的就是交易數(shù)據(jù),，真金白銀，這個(gè)非結(jié)構(gòu)化數(shù)據(jù)對(duì)應(yīng)的就是我們的這個(gè)行為數(shù)據(jù),，量大,。

所以spark SQL這個(gè)組件就出現(xiàn)了,。我們可以看看第一句話并不是很難的英文,。就是bridges the gap 就是把這個(gè)兩個(gè)模型的空缺，也是他們之間的有一道鴻溝給填不了,，那是什么樣的鴻溝呢？而在總結(jié)一下就是傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)也就是SQL對(duì)節(jié)化數(shù)據(jù)的處理能力非常強(qiáng)大,。但是呢他用不了機(jī)學(xué)習(xí)呀,！或者是處理非結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)這個(gè)功能。而且spark這個(gè)組件,。他擁有強(qiáng)大的機(jī)器學(xué)習(xí)算法以及對(duì)非結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)據(jù)的處理功能,。但是對(duì)結(jié)構(gòu)化數(shù)據(jù)又無能為力。那spark SQL就是想要在spark 組件添加處理結(jié)構(gòu)化數(shù)據(jù)的能力,。

那這樣spark 組件就如虎添翼,。結(jié)構(gòu)化數(shù)據(jù)能處理非結(jié)構(gòu)化數(shù)據(jù)半結(jié)構(gòu)化數(shù)據(jù)都能處理。這個(gè)我們整個(gè)大數(shù)據(jù)時(shí)代,，數(shù)據(jù)分為結(jié)構(gòu)化和非結(jié)構(gòu)化也就是行為數(shù)據(jù)和交易手機(jī)我都能處理了,。那這個(gè)是非常明顯的就是要一統(tǒng)數(shù)據(jù)的江湖。

那我們來看看spark SQL里邊,，我們剛才講spark 他本身背后的數(shù)據(jù)結(jié)構(gòu)是叫RDD。那spark SQL他背后的這個(gè)數(shù)據(jù)結(jié)構(gòu)就叫DataFrame,。那我們知道SQL在關(guān)系型數(shù)據(jù)庫(kù)里面都有一個(gè)SQL的這個(gè)語法的解析器也就SQL的執(zhí)行引擎或者叫優(yōu)化器,。在優(yōu)化器里面如果大家有這個(gè)關(guān)系型數(shù)據(jù)庫(kù)DDA可能了解到有基于規(guī)則的RBO。那我們這個(gè)spark 里邊他的這個(gè)SQL也是有一個(gè)這個(gè)優(yōu)化計(jì)算引擎,，那我們管它叫Catalyst,。

那張圖就是在spark 里邊創(chuàng)建一個(gè)基于RDD的一個(gè)DataFrame的數(shù)據(jù)結(jié)構(gòu)，其實(shí)他本質(zhì)上還是繼續(xù)RDD,。只不過RDD就向一個(gè)空曠的屋子,，你要找東西要把這個(gè)屋子翻遍才能找到。那我們的這個(gè)DataFrame相當(dāng)于在你的屋子里面打上了貨架,。那你只要告訴他你是在第幾個(gè)貨架的第幾個(gè)位置,，那不就是二維表嗎,。那就是我們DataFrame就是在RDD基礎(chǔ)上加入了列。實(shí)際上我們處理數(shù)據(jù)就像處理二維表一樣,。

這是我們整個(gè)spark處理的這么一個(gè)機(jī)制，我們首先看最底下,。依然是spark以及他后臺(tái)的數(shù)據(jù)結(jié)構(gòu),。這個(gè)Resilient Distributed Datasets彈性分布式數(shù)據(jù)集。那我們用戶可以通過這個(gè)編程語言的接口來直接處理,，大家看看最右側(cè)這個(gè)向下的箭頭,，可以去處理這個(gè)非結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)。剛才講一間屋子數(shù)據(jù)都堆到里邊,，你可以通過程序處理,，那如果數(shù)據(jù)要是規(guī)則的，他就可以通過這個(gè)中間這個(gè)層spark SQL背后的數(shù)據(jù)結(jié)構(gòu)DataFrame API,。DataFrame API是接SQL的,。那所以說她下面有Catalyst Optimizer，SQL優(yōu)化器,，上邊JDBC,、Console接這個(gè)SQL的一些語句的。

所以說我們這個(gè)整個(gè)spark的一個(gè)發(fā)展趨勢(shì),，其中有一條路就是要重視結(jié)構(gòu)化數(shù)據(jù)的處理,。那其實(shí)我們?cè)诖髷?shù)據(jù)數(shù)據(jù)清洗過程中，他的一個(gè)思路也就是把非結(jié)構(gòu)化數(shù)據(jù)給結(jié)構(gòu)化,。那這是我們spark的一個(gè)技術(shù)的發(fā)展路線,，那關(guān)于很多內(nèi)容，而其實(shí)都是可以值得聊的,，但是今天因?yàn)闀r(shí)間的關(guān)系咱們就先說到這兒,。然后呢，有機(jī)會(huì)咱們?cè)賹?duì)此spark進(jìn)行一個(gè)深入的交流,。

今天的技術(shù)交流就先到這里,。謝謝大家。