這是個老生常談的話題,你們是否是看到這個文章標題就快吐了,原本想着手寫一些有技術深度的東西,可是看到太多童鞋卡在入門的門檻上,因此仍是打算總結一下入門經驗。這種標題真的真的在哪裏均可以看獲得,度娘一搜就是幾火車皮,打開一看都是千篇一概的「workcount」、「quickstart」,可是這些對於初學者來講還差的太多,這些東東真的只是spark的冰山一角,摸着這些石頭過河的話,彎路太多、暗礁涌動,一個不留神就掉河裏了。但願我這篇文章能讓你們看到些不同的地方。文章分五個部分,包括官網、blog(特指某sdn)、書籍、源碼、視頻五個角度,多視角分享一下對於初學者而言在選擇學習方法時改如何取捨。mysql
奇葩的技術blog面試
之因此說奇葩,是由於你們都是相互抄啊抄,這個在某sdn特別流行,知乎上已經有關於這個的吐槽了,國內的技術論壇跟國外還差幾條街,Stack Overflow上關於各類疑難雜症的回答都很是專業,可是國內鮮有這樣的大型平臺。若是你們要經過某sdn的技術博客學習spark,那坑真是太多,你們能碰到及時更新而且分析深刻、全面且合理的博主的機率真是過低。首先在信息大爆炸時代,人人都是信息源,博客太多太多,這是信息太多帶給學習者的困擾。其次在移動互聯網時代,你們的學習時間也都被碎片化了,估計你們大部分時間都被手機佔據,不多有人願意花時間坐在電腦前認真的看技術論壇上的博客了,因此微信的技術公衆號才能大行其道。可是,如今的技術公衆號也是太多太多,因此你們要平時留意優秀的技術博客,積累優秀公衆號就跟學習一門技術同樣,是一個積累的過程,不是別人給你推薦幾個就必定是好的。可是不要關注一些大型平臺的官方公衆號,虛的東西太多,沒什麼乾貨。至於我的以爲不錯的spark學習相關的公衆號在這裏就不推薦了,你懂的。。。。sql
官網的編程手冊shell
不得不說,spark的官網編程手冊,仍是特別的好的,更新及時,覆蓋面廣,可是缺點也很明顯,那就是官網的編程手冊,其實並不適合初學者。爲何這麼說,首先,它只給出了代碼片斷,而初學者須要的是一個能夠運行起來的工程。初學者每每對spark沒有任何的初始印象,他們須要的是一個有輸入有輸出的直觀的工程,經過這個工程,輸出變成了輸出,他們也就知道spark是幹些什麼的了。誠然,spark最近版本的編程手冊給出了編寫spark應用須要的依賴,但問題是不少初學者連maven都沒有用過,他們更不知道這些依賴應該如何使用,也不知道這些依賴和代碼片斷應該如何組合才能構建出一個開發環境來。有些童鞋會說,經過spark-shell能夠達到這個目的啊,不須要添加依賴,所見即所得,即寫即用,但問題時,一開始就一直使用spark-shell學習的話,其實不知道現網真正的spark應用都不是經過這種方式提交的,這就在必定程度上誤導了初學者,他們把spark-shell用的很熟,覺得這就是spark的常規使用方式了。官網編程手冊的第二個問題是,它給出了api的使用方法,卻沒有給出這些api的使用場景,誠然,不能要求編程手冊給出應用場景來,但這也正是編程手冊不適合初學者的緣由,由於若是不瞭解這些api的使用場景,那麼即便手動生成幾個數據,把這些api測試一遍,學習者不會對這些api有什麼印象,更沒法激起他們深刻學些這些api底層實現的興趣,他們也不會去注意這些api之間的微妙差別,更沒法經過api看到spark的全貌來。我到目前爲止,在實際項目中沒有使用過的api理解也不是很深入,只是瞭解一些他們理論上的實現和差別。舉個例子,咱們都知道spark的transformation操做是lazy模式,要靠action去啓動,可是若是個人一個應用場景就是沒有transform,那我應該靠那個action來完成這樣一個並行化的處理流程呢?感興趣的能夠思考一下這個問題,其實spark提供了api的,可是你們在學習編程手冊時每每不會去注意到這個問題。官網編程手冊的第三個問題,就是測試數據來源都太簡單,絕大多數都經過一個api生成幾個簡單的數值類型或者字符串類型,數據量也不多,可是問題是,咱們在實際項目中,spark的輸入數據千差萬別,有些來自文件好比本地文件或者HDFS文件,有些來自其餘的DBMS好比mysql等,有些來自網絡好比kafka或者flume,有些甚至是spark本身產生的,而若是隻是經過api生成數據的方式來描述編程過程,其實不利於初學者瞭解spark的真是使用方法。這也就是爲何不少童鞋說看官網的api手冊看的懂,可是實際項目就比較懵逼的緣由了。編程
書籍api
看書確實是一個不錯的入門途徑,隨着spark的火熱,如今國內國外的spark書籍也是愈來愈多,可是每每存在幾個問題。第一,版本老舊。這是沒辦法的事情,spark更新太快,寫本書特別是技術書籍,通常都是以半年爲單位,半年後書籍出版時,spark都不知道迭代了多少個小版本了,甚至均可能有大版本的跟新,因此你們選擇書籍時,能夠先經過各類渠道打聽一下某本書是基於spark哪一個版本寫的。可是也不是說老的版本不能看,若是有沒有跨大的版本,仍是有必定參考意義的。這裏給你們普及一下spark的版本號的知識:微信
spark書籍的第二個問題是,你們要清楚這本書是怎麼分類的,怎麼講呢?從橫向來看,spark有很是多的用途,好比能夠用於ETL、實時處理、數據分析、數據挖掘、機器學習,那麼spark書籍也須要從這個角度去分類。那麼從縱向來看,有spark原理講解的、實戰的、源碼分析的,這又是另一個分類視角了。我的認爲最好的途徑是:若是有很是實際的橫向需求,好比要作數據分析,那麼就從數據分析相關的spark書籍入手,不要一開始就去看原理性的東西,由於你從實際需求入手的話,過段時間你就會很是想了解底層原理了,在這種內在需求的推進下,這時再去看原理相關的書籍效果就會很是好。若是沒有實際的橫向需求,那就只能從原理性的書籍入手了。看書的另一個誤區就是不少人以爲看一遍就好了,其實不少技術書籍須要反覆的看反覆的體會,不要以爲本身看書要看好幾遍才能理解是本身笨,從而自欺欺人不去複習。網絡
源碼架構
其實很不推薦初學者一開始就去看源碼,這每每是一個性價比比較低的入門方法,我知道一個剛剛畢業幾個月的童鞋,花了幾個月看spark源碼,給spark源碼添加了80%的中文註釋,可是當我問他一些spark使用和很是經常使用的優化時,他卻一個都回答不上來。你們以爲這樣一種狀態,去面試,能拿到好的offer嗎?我換工做時去參加面試,並無被問到什麼spark源碼的東西,能夠說基本沒人問,由於面試官很是清楚一個事實,那就是誰都能把spark源碼看個只知其一;不知其二,可是這樣的人並不能表明他能用spark開發出高效的分佈式應用來,而這種能力的培養,必須是有實際的項目實踐經驗才行。國內目前95%的公司對spark的使用都停留在應用層面,只要能使用開源spark寫出高效的應用便可,對源碼的閱讀只多是一個加分項,由於他們但願你經過源碼閱讀加深優化spark分佈式應用的方法的理解和加快問題定位,並無但願你能經過spark源碼閱讀能對spark進行二次開發。spark源碼的閱讀確實頗有必要,但絕對不是在剛剛開始學習的時候,這點你們切雞切雞!我在2013年初次接觸spark時,公司是對spark有二次開發需求的,那時就很盲目的閱讀了不少spark core部分的源碼,可是對spark api的使用卻很是很是初級,很不利於對spark總體體系或者大數據總體架構的理解。走了這樣的彎路,但願初學者能吸收這樣的教訓。機器學習
視頻
爲了體驗一把初學者,我特地買了tensorflow的視頻,可是發現實在是看不下去,分析了一下緣由,主要是第一,我已經有了多年的工做經驗,不少基礎的東西其實不須要聽,可是培訓機構爲了考慮初學者以及課程完整性,會加入很是多的基礎知識,好比語言基礎,環境搭建等。建議有必定基礎的朋友,這些東西能夠直接跳過,聽他講根本沒有本身實際操做來的快。第二,視頻通常都會宣稱本身有實戰項目,可是這實際上是一個挺搞笑的事情,實戰實戰,是聽出來的嗎?實戰必定要本身動手操做,本身解決項目中遇到的問題,這纔是實戰,視頻中最多也就是應用場景介紹而已。一句話,沒有老闆催的東西,都不叫實戰。即便你按照視頻中的案例操做一遍,遇到實際項目仍是懵逼狀態。spark的api是固定的,可是應用場景變幻無窮,只有實際項目才能從本質上提高一我的的spark能力。看視頻真心不如看書和實操,不少初學者甚至已經入門的童鞋,以爲看視頻很輕鬆,可是這就跟減肥機構騙女人吃減肥藥去減肥同樣,這些女人通常比較懶,想經過捷徑去減肥,卻不知靠減肥藥其實沒有效果,對不少女人來講都是心理安慰而已,真正的減肥要考堅持鍛鍊和有效的食物熱量控制,是個堅苦卓絕的過程。這跟學習一門技術是一個道理。
怎麼辦?
講了這麼多,怎麼沒有給出解決方案來?緣由就是,學習spark沒有固定套路可走,任何一種方法都是優勢和缺點並存,並且每一個人的基礎是不一樣的,要給出一套通用的解決方案實際上是一種不負責任的行爲,我上邊講這麼多隻是爲了提醒你們。你們惟一要作的事,就是不要在猶豫不決了,spark是絕對是將來大數據的基礎,火的一塌糊塗,多少人由於spark發家致富了。手頭有什麼就拿起什麼來,有視頻就看視頻,有書就看書,開始搭環境寫代碼,一個字「開幹!」,各類方法都嘗試一下,過上一段時間,新航道官網你從各個方面學習的點滴spark知識就會連成一片,從而達到融會貫通的效果。我見過不少人成功轉行大數據,靜下心來本身訂製學習計劃、準備面試、入職、項目實戰、進階、再學習、再實戰、再進階,本身給本身造成一個良性循環!
更多精彩內容,請關注spark技術學院,bat一線工程師和你互動,一塊兒學習spark,一塊兒迎接大數據時代!