Spark入門——什麼是Hadoop，爲何是Spark?

　　#Spark入門#這個系列課程，是綜合於我從2017年3月分到今年7月份爲止學習並使用Spark的使用心得感悟，暫定於每週更新，之後可能會上傳講課視頻和PPT，目前先在博客園把稿子打好。注意：這只是一個草稿，裏面關於知識的誤解還請各大網友監督，咱們互相進步。總而言之，網絡上的知識學會斷舍離，學會帶着辯證的眼光去學習就能進步。

　　談到Spark，實際上從16年本科實習的時候就已經開始接觸，那個時候是從Pig入門大數據Hadoop的，有興趣的朋友能夠看Hadoop家族之Pig入門；當時你們基本都在使用Pig，Pig我也沒有接觸太深，大概兩個月後開始跟着當時的師父（當時是實習的碩士，後來就業去了阿里）學了Spark，整個公司就他在寫Spark，他是一個我很佩服的人，屬於全棧工程師類型的人，先後端數據分析以及數據挖掘的算法都會，因此就跟着使用Python寫着Spark的一些入門程序，可見我另一個博客Spark2.0系列RDDVs.DataSetVs.DataFrame，實際上這裏關於Dataset的介紹是很是不全面的，接下來我也會在這個Spark入門系列講的更爲詳細一點。目前看來，大數據相關的職位那麼吃香，不少學計算機的，學數學的，學統計的，半路上培訓的，各類各樣的人都來投Spark工程師的崗位，由於薪資高的緣由吧，可是真正喜歡這個職業的又有幾個，但願你們能一直堅持下去，見證大數據技術的更新迭代！

　　第一個問題，什麼是Hadoop^TM？實際上這個答案Hadoop官網已經給的很明確：

　　Hadoop是Apache軟件基金會支持可靠的、可擴展的一個開源的分佈式計算框架的工程。（PS：Apache軟件基金會真是扛下了開源世界的半壁江山，旗下支持的開源的大數據項目你們有興趣能夠去官網訪問一下。）

　　具體而言，Apache Hadoop軟件庫是一個容許使用簡單編程模型跨計算機集羣處理大型數據集合的框架，其設計的初衷是將單個服務器擴展成上千個機器組成的一個集羣爲大數據提供計算服務，其中每一個機器都提供本地計算和存儲服務。

　　Hadoop工程包括如下模塊：

• Hadoop Common：支持其餘Hadoop模塊的通用工具。
• Hadoop Distributed File System(HDFS^TM)：提供高吞吐量的訪問應用數據的一個分佈式文件系統。
• Hadoop YARN：一種做業調度和集羣資源管理的框架。
• Hadoop MapReduce：一種基於Yarn來處理大數據集合的系統。

　　Apache中其餘Hadoop相關的項目包括：

• Ambari^TM：一種用於提供、管理和監督Apache Hadoop集羣的基於Web UI的且易於使用的Hadoop管理工具。
• Avro^TM：一種數據序列化系統。
• Cassandra^TM：一種無單點故障的可擴展的分佈式數據庫。
• Chukwa^TM：一種用於管理大型分佈式系統的數據收集系統。
• HBase^TM：一種支持存儲大型表的結構化存儲的可擴展的分佈式數據庫。
• Hive^TM：一種提供數據彙總和特定查詢的數據倉庫。
• Mahout^TM：一種可擴展的機器學習和數據挖掘庫（Scala語言實現，可結合Spark後端）。
• Pig^TM：一種高級的數據流語言且支持並行計算的執行框架（2017年發佈的最新版本0.17.0是添加了Spark上的Pig應用）。
• Spark^TM：一種用於Hadoop數據的快速通用計算引擎。Spark提供一種支持普遍應用的簡單而易懂的編程模型，包括ETL（ Extract-Transform-Load）、機器學習、流處理以及圖計算。
• Tez^TM：一種創建在Hadoop YARN上數據流編程框架，它提供了一個強大而靈活的引擎來任意構建DAG（Directed-acyclic-graph）任務去處理用於批處理和交互用例的數據。
• ZooKeeper^TM：一種給分佈式應用提供高性能的協同服務系統。

　　第二個問題，既然Hadoop生態家族這麼龐大，咱們爲何要選擇Spark做爲對於大數據進行數據分析和數據挖掘的基本計算框架？

　　這個問題的答案實際上Spark官網已經給的很明確了，我就照樣搬磚過來。

• 速度快
  

　　Apache Spark擁有先進的DAG調度器、查詢優化器以及物理執行引擎從而高性能的實現批處理和流數據處理。

• 易用性（可使用Java，Scala，Python，R以及SQL快速的寫Spark應用）

　　Spark提供80個以上高級算子便於執行並行應用，而且可使用Scala、Python、R以及SQL的shell端交互式運行Spark應用。

#經過Spark的Python的DataFrame的API讀取JSON文件
df = spark.read.json("logs.json")
df.where("age > 21").show()

• 通用性(支持SQL，流數據處理以及複雜分析)

　　Spark擁有一系列庫，包括SQL和DataFrame，用於機器學習的MLib,支持圖計算GraphX以及流計算模塊Streaming。你能夠在一個應用中同時組合這些庫。

　　

• 支持多種模式運行（平臺包括Hadoop,Apache Mesos,Kubernete,standalone或者雲上，也能夠獲取各類數據源上的數據）

　　Spark能夠直接運行以自身的standalone集羣模式運行，也能夠在亞馬遜EC2上運行，不過企業級用的比較多的是Hadoop Yarn模式，固然也有Mesos和Kubernetes模式。能夠獲取不限於來自於HDFS、Apache Cassandra、Apache HBase和Apache Hive等上百種數據源。

　　那麼，第三個問題，Hadoop和Spark之間的關係是什麼？

　　首先要從Hadoop的MapReduce編程框架提及，若是說MapReduce是第一代計算引擎，那麼Spark就是第二代計算引擎。

　　MapReduce將複雜的並行計算過程高度的抽象到了兩個函數：Map函數和Reduce函數。

　　

　　MapReduce的核心是「分而治之」策略。數據在其MapReduce的生命週期中過程當中須要通過六大保護神的洗禮，分別是：Input、Split、Map、Shuffule、Reduce和Output。

　　

　　MapReduce框架採用Master/Slave架構，一個Master對應多個Slave，Master運行JobTracker，Slave運行TaskTracker；JobTracker充當一個管理者，負責Client端提交的任務可以由手下的TaskTracker執行完成，而TaskTracker充當普通員工執行的Task分爲Map Task（Split and Map）和Reduce Task(Shuffle and Reduce)。

　　如今，咱們普通的開發人員只要會用MapReduce的API就能夠實現高大上的並行計算了，可是對於非科班畢業的數據分析（例如我這樣半路出家的統計學畢業）人員而言，MapReduce存在的侷限性不只僅是在於其代碼的又長又臭，固定的框架等，總而言之其短板可見如下列表：

1. 抽象層次低，具體的Map和Reduce實現起來代碼量大而且對於數據挖掘算法中複雜的分析須要大量的Job來支持，且Job之間的依賴須要開發者定義，致使開發的難度高而代碼的可讀性不強；
2. 中間結果也存放在HDFS文件系統中，致使中間結果不能複用（須要從新從磁盤中讀取），不適宜數據挖掘算法中的大量迭代操做，ReduceTask須要等待全部的MapTask執行完畢才能夠開始；
3. 只適合批處理場景，不支持交互式查詢和數據的實時處理。

　　要知道，咱們一般意義上的Hadoop每每是Hadoop生態圈，意味着不少技術對Hadoop自己具備的侷限進行了擴展和改進，從而有了Pig、Hive將SQL語言翻譯成MapReduce程序，讓咱們從繁瑣的MapReduce程序中釋放出來。若是說Pig這類的類SQL語言解決了MapReduce中存在的大量手寫代碼，那麼Tez就解決是去除了Map和Reduce兩個任務之間的屏障從而提高了總體的性能，從而將多個MapReduce任務在一個Tez任務中處理完。

　　隨着大數據處理的應用場景愈來愈多，人們對Hadoop的要求也愈來愈高，開發出的對應的系統也愈來愈多，人們迫切的須要一個綜合的計算框架，Spark應運而生，咱們能夠看看Spark能夠幹些什麼。

　　那麼爲何Spark能作到這些？

　　首先，咱們須要理解Spark中的三大概念：

1. RDD（Resilient Distributed Dataset）。實際上對與開發人員而已它是以一種對象的形式做爲數據的一種表現形式而存在，能夠理解爲一種你能夠操做的只讀的分佈式數據集，之因此稱之爲有彈性，在於：
   1. RDD能夠在內存和磁盤存儲間手動或自動切換；
   2. RDD擁有Lineage（血統）信息，及存儲着它的父RDD以及父子之間的關係，當數據丟失時，可經過Lineage關係從新計算並恢復結果集，使其具有高容錯性；
   3. 當血統鏈太長時，用戶能夠創建checkpoint將數據存放到磁盤上持久化存儲加快容錯速度（建議經過saveAsTextFile等方式存儲到文件系統），而persist方式能夠將數據存儲到內存中用於後續計算的複用；
   4. RDD的數據從新分片能夠手動設置。在Spark中執行從新分片操做的方法有repartition和coalesce兩個方法，這兩個方法都是手動設置RDD的分區數量，repartition只是coalesce接口中參數shuffle=true的實現；是否從新分區對性能影響比較大，若是分區數量大，能夠減小每一個分區的佔存，減小OOM（內存溢出）的風險，但若是分區數量過多同時產生了過多的碎片，消耗過多的線程去處理數據，從而浪費計算資源。
2. Transformations。轉換髮生在當你將現有的RDD轉換成其餘的RDD的時候。好比當你打開一個文件而後讀取文件內容並經過map方法將字符串類型RDD轉換成另一個數組類型RDD就是一種轉換操做，經常使用的轉換操做有map,filer,flatMap,union,distinct,groupByKey等。
3. Actions。動做發生在你須要系統返回一個結果的時候。好比你須要知道RDD的第一行數據是什麼樣的內容，好比你想知道RDD一共有多少行這樣相似的操做就是一種動做，經常使用的動做操做有reduce,collect,count,first,take(),saveAsTextFile(),foreach()等。

　　有意思的是Spark使用「lazy evaluation」，意味着執行Transformations操做的時候實際上系統並無發生任何操做，只有在遇到Actions操做的時候Spark纔開始真正從頭運行程序執行一系列轉換並返回結果。由於有了這種惰性求值方式加上RDD的血緣依賴關係致使程序在一系列連續的運算中造成了DAG，而這種DAG（Directed Acyclic Graph）能夠優化整個執行計劃（參照上圖中的Tez）。

　　最後再強調一下，爲何要選擇Spark？

• 首先，Spark經過RDD的lineage血統依賴關係提供了一個完備的數據恢復機制；
• 其次，Spark經過使用DAG優化整個計算過程；
• 最後，Spark對RDD進行Transformation和Action的一系列算子操做使得並行計算在粗粒度上就能夠簡單執行，並且Spark生態系統提供了一系列的開發包使得數據科學家能夠執行一系列的SQL、ML、Streaming以及Graph操做，並且還支持不少其餘的第三方包括一些交互式框架相似於Apache Zeppelin，地理數據可視化框架GeoSpark以及一些比較流行的深度學習框架Sparking-water,Deeplearning4j,SparkNet等。

　　咱們都知道Spark最初是由UC伯克利大學的AMP實驗室研究出來的，強烈推薦這個實驗室的Projects！Happy Coding!