今天就跟大家聊聊有關(guān)如何進(jìn)行spark原理及生態(tài)圈分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
成都創(chuàng)新互聯(lián)公司是一家專業(yè)提供雙河企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站設(shè)計、做網(wǎng)站、H5響應(yīng)式網(wǎng)站、小程序制作等業(yè)務(wù)。10年已為雙河眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進(jìn)行中。1、簡介
1.1 Spark簡介
Spark是加州大學(xué)伯克利分校AMP實(shí)驗室（Algorithms, Machines, and People Lab）開發(fā)通用內(nèi)存并行計算框架。Spark在2013年6月進(jìn)入Apache成為孵化項目，8個月后成為Apache頂級項目，速度之快足見過人之處，Spark以其先進(jìn)的設(shè)計理念，迅速成為社區(qū)的熱門項目，圍繞著Spark推出了Spark SQL、Spark Streaming、MLLib和GraphX等組件，也就是BDAS（伯克利數(shù)據(jù)分析棧），這些組件逐漸形成大數(shù)據(jù)處理一站式解決平臺。從各方面報道來看Spark抱負(fù)并非池魚，而是希望替代Hadoop在大數(shù)據(jù)中的地位，成為大數(shù)據(jù)處理的主流標(biāo)準(zhǔn)，不過Spark還沒有太多大項目的檢驗，離這個目標(biāo)還有很大路要走。
Spark使用Scala語言進(jìn)行實(shí)現(xiàn)，它是一種面向?qū)ο?、函?shù)式編程語言，能夠像操作本地集合對象一樣輕松地操作分布式數(shù)據(jù)集（Scala 提供一個稱為 Actor 的并行模型，其中Actor通過它的收件箱來發(fā)送和接收非同步信息而不是共享數(shù)據(jù)，該方式被稱為：Shared Nothing 模型）。在Spark官網(wǎng)上介紹，它具有運(yùn)行速度快、易用性好、通用性強(qiáng)和隨處運(yùn)行等特點(diǎn)。
l運(yùn)行速度快
Spark擁有DAG執(zhí)行引擎，支持在內(nèi)存中對數(shù)據(jù)進(jìn)行迭代計算。官方提供的數(shù)據(jù)表明，如果數(shù)據(jù)由磁盤讀取，速度是Hadoop MapReduce的10倍以上，如果數(shù)據(jù)從內(nèi)存中讀取，速度可以高達(dá)100多倍。
l易用性好
Spark不僅支持Scala編寫應(yīng)用程序，而且支持Java和Python等語言進(jìn)行編寫，特別是Scala是一種高效、可拓展的語言，能夠用簡潔的代碼處理較為復(fù)雜的處理工作。
l通用性強(qiáng)
Spark生態(tài)圈即BDAS（伯克利數(shù)據(jù)分析棧）包含了Spark Core、Spark SQL、Spark Streaming、MLLib和GraphX等組件，這些組件分別處理Spark Core提供內(nèi)存計算框架、SparkStreaming的實(shí)時處理應(yīng)用、Spark SQL的即席查詢、MLlib或MLbase的機(jī)器學(xué)習(xí)和GraphX的圖處理，它們都是由AMP實(shí)驗室提供，能夠無縫的集成并提供一站式解決平臺。
l隨處運(yùn)行
Spark具有很強(qiáng)的適應(yīng)性，能夠讀取HDFS、Cassandra、HBase、S3和Techyon為持久層讀寫原生數(shù)據(jù)，能夠以Mesos、YARN和自身攜帶的Standalone作為資源管理器調(diào)度job，來完成Spark應(yīng)用程序的計算。
Spark是在借鑒了MapReduce之上發(fā)展而來的，繼承了其分布式并行計算的優(yōu)點(diǎn)并改進(jìn)了MapReduce明顯的缺陷，具體如下：
首先，Spark把中間數(shù)據(jù)放到內(nèi)存中，迭代運(yùn)算效率高。MapReduce中計算結(jié)果需要落地，保存到磁盤上，這樣勢必會影響整體速度，而Spark支持DAG圖的分布式并行計算的編程框架，減少了迭代過程中數(shù)據(jù)的落地，提高了處理效率。
其次，Spark容錯性高。Spark引進(jìn)了彈性分布式數(shù)據(jù)集RDD (Resilient Distributed Dataset) 的抽象，它是分布在一組節(jié)點(diǎn)中的只讀對象集合，這些集合是彈性的，如果數(shù)據(jù)集一部分丟失，則可以根據(jù)“血統(tǒng)”（即充許基于數(shù)據(jù)衍生過程）對它們進(jìn)行重建。另外在RDD計算時可以通過CheckPoint來實(shí)現(xiàn)容錯，而CheckPoint有兩種方式：CheckPoint Data，和Logging The Updates，用戶可以控制采用哪種方式來實(shí)現(xiàn)容錯。
最后，Spark更加通用。不像Hadoop只提供了Map和Reduce兩種操作，Spark提供的數(shù)據(jù)集操作類型有很多種，大致分為：Transformations和Actions兩大類。Transformations包括Map、Filter、FlatMap、Sample、GroupByKey、ReduceByKey、Union、Join、Cogroup、MapValues、Sort和PartionBy等多種操作類型，同時還提供Count, Actions包括Collect、Reduce、Lookup和Save等操作。另外各個處理節(jié)點(diǎn)之間的通信模型不再像Hadoop只有Shuffle一種模式，用戶可以命名、物化，控制中間結(jié)果的存儲、分區(qū)等。
目前大數(shù)據(jù)處理場景有以下幾個類型：
1. 復(fù)雜的批量處理（Batch Data Processing），偏重點(diǎn)在于處理海量數(shù)據(jù)的能力，至于處理速度可忍受，通常的時間可能是在數(shù)十分鐘到數(shù)小時；
2. 基于歷史數(shù)據(jù)的交互式查詢（Interactive Query），通常的時間在數(shù)十秒到數(shù)十分鐘之間
3. 基于實(shí)時數(shù)據(jù)流的數(shù)據(jù)處理（Streaming Data Processing），通常在數(shù)百毫秒到數(shù)秒之間
目前對以上三種場景需求都有比較成熟的處理框架，第一種情況可以用Hadoop的MapReduce來進(jìn)行批量海量數(shù)據(jù)處理，第二種情況可以Impala進(jìn)行交互式查詢，對于第三中情況可以用Storm分布式處理框架處理實(shí)時流式數(shù)據(jù)。以上三者都是比較獨(dú)立，各自一套維護(hù)成本比較高，而Spark的出現(xiàn)能夠一站式平臺滿意以上需求。
通過以上分析，總結(jié)Spark場景有以下幾個：
lSpark是基于內(nèi)存的迭代計算框架，適用于需要多次操作特定數(shù)據(jù)集的應(yīng)用場合。需要反復(fù)操作的次數(shù)越多，所需讀取的數(shù)據(jù)量越大，受益越大，數(shù)據(jù)量小但是計算密集度較大的場合，受益就相對較小
l由于RDD的特性，Spark不適用那種異步細(xì)粒度更新狀態(tài)的應(yīng)用，例如web服務(wù)的存儲或者是增量的web爬蟲和索引。就是對于那種增量修改的應(yīng)用模型不適合
l數(shù)據(jù)量不是特別大，但是要求實(shí)時統(tǒng)計分析需求
演進(jìn)時間表：
l 2009年由Berkeley's AMPLab開始編寫最初的源代碼
l 2010年開放源代碼
l 2013年6月進(jìn)入Apache孵化器項目
l 2014年2月成為Apache的頂級項目（8個月時間）
l 2014年5月底Spark1.0.0發(fā)布
l 2014年9月Spark1.1.0發(fā)布
l 2014年12月Spark1.2.0發(fā)布
目前情況：
l 目前已經(jīng)有30+公司100+開發(fā)者在提交代碼
l Hadoop大的廠商Cloudera宣稱加大Spark框架的投入來取代Mapreduce
l Hortonworks
l Hadoop廠商MapR投入Spark陣營
l Apache Mahout放棄MapReduce，將使用Spark作為后續(xù)算子的計算平臺
目前大數(shù)據(jù)在互聯(lián)網(wǎng)公司主要應(yīng)用在廣告、報表、推薦系統(tǒng)等業(yè)務(wù)上。在廣告業(yè)務(wù)方面需要大數(shù)據(jù)做應(yīng)用分析、效果分析、定向優(yōu)化等，在推薦系統(tǒng)方面則需要大數(shù)據(jù)優(yōu)化相關(guān)排名、個性化推薦以及熱點(diǎn)點(diǎn)擊分析等。這些應(yīng)用場景的普遍特點(diǎn)是計算量大、效率要求高。Spark恰恰滿足了這些要求，該項目一經(jīng)推出便受到開源社區(qū)的廣泛關(guān)注和好評。并在近兩年內(nèi)發(fā)展成為大數(shù)據(jù)處理領(lǐng)域最炙手可熱的開源項目。
本章將列舉國內(nèi)外應(yīng)用Spark的成功案例。
1. 騰訊
廣點(diǎn)通是最早使用Spark的應(yīng)用之一。騰訊大數(shù)據(jù)精準(zhǔn)推薦借助Spark快速迭代的優(yōu)勢，圍繞“數(shù)據(jù)+算法+系統(tǒng)”這套技術(shù)方案，實(shí)現(xiàn)了在“數(shù)據(jù)實(shí)時采集、算法實(shí)時訓(xùn)練、系統(tǒng)實(shí)時預(yù)測”的全流程實(shí)時并行高維算法，最終成功應(yīng)用于廣點(diǎn)通pCTR投放系統(tǒng)上，支持每天上百億的請求量。
基于日志數(shù)據(jù)的快速查詢系統(tǒng)業(yè)務(wù)構(gòu)建于Spark之上的Shark，利用其快速查詢以及內(nèi)存表等優(yōu)勢，承擔(dān)了日志數(shù)據(jù)的即席查詢工作。在性能方面，普遍比Hive高2-10倍，如果使用內(nèi)存表的功能，性能將會比Hive快百倍。
2. Yahoo
Yahoo將Spark用在Audience Expansion中的應(yīng)用。Audience Expansion是廣告中尋找目標(biāo)用戶的一種方法：首先廣告者提供一些觀看了廣告并且購買產(chǎn)品的樣本客戶，據(jù)此進(jìn)行學(xué)習(xí)，尋找更多可能轉(zhuǎn)化的用戶，對他們定向廣告。Yahoo采用的算法是logistic regression。同時由于有些SQL負(fù)載需要更高的服務(wù)質(zhì)量，又加入了專門跑Shark的大內(nèi)存集群，用于取代商業(yè)BI/OLAP工具，承擔(dān)報表/儀表盤和交互式/即席查詢，同時與桌面BI工具對接。目前在Yahoo部署的Spark集群有112臺節(jié)點(diǎn)，9.2TB內(nèi)存。
3. 淘寶
阿里搜索和廣告業(yè)務(wù)，最初使用Mahout或者自己寫的MR來解決復(fù)雜的機(jī)器學(xué)習(xí)，導(dǎo)致效率低而且代碼不易維護(hù)。淘寶技術(shù)團(tuán)隊使用了Spark來解決多次迭代的機(jī)器學(xué)習(xí)算法、高計算復(fù)雜度的算法等。將Spark運(yùn)用于淘寶的推薦相關(guān)算法上,同時還利用Graphx解決了許多生產(chǎn)問題，包括以下計算場景：基于度分布的中樞節(jié)點(diǎn)發(fā)現(xiàn)、基于大連通圖的社區(qū)發(fā)現(xiàn)、基于三角形計數(shù)的關(guān)系衡量、基于隨機(jī)游走的用戶屬性傳播等。
4. 優(yōu)酷土豆
優(yōu)酷土豆在使用Hadoop集群的突出問題主要包括：第一是商業(yè)智能BI方面，分析師提交任務(wù)之后需要等待很久才得到結(jié)果；第二就是大數(shù)據(jù)量計算，比如進(jìn)行一些模擬廣告投放之時，計算量非常大的同時對效率要求也比較高，最后就是機(jī)器學(xué)習(xí)和圖計算的迭代運(yùn)算也是需要耗費(fèi)大量資源且速度很慢。
最終發(fā)現(xiàn)這些應(yīng)用場景并不適合在MapReduce里面去處理。通過對比，發(fā)現(xiàn)Spark性能比MapReduce提升很多。首先，交互查詢響應(yīng)快，性能比Hadoop提高若干倍；模擬廣告投放計算效率高、延遲?。ㄍ琱adoop比延遲至少降低一個數(shù)量級）；機(jī)器學(xué)習(xí)、圖計算等迭代計算，大大減少了網(wǎng)絡(luò)傳輸、數(shù)據(jù)落地等，極大的提高的計算性能。目前Spark已經(jīng)廣泛使用在優(yōu)酷土豆的視頻推薦（圖計算）、廣告業(yè)務(wù)等。
運(yùn)行環(huán)境 | 模式 | 描述 |
Local | 本地模式 | 常用于本地開發(fā)測試，本地還分為local單線程和local-cluster多線程; |
Standalone | 集群模式 | 典型的Mater/slave模式，不過也能看出Master是有單點(diǎn)故障的；Spark支持 ZooKeeper來實(shí)現(xiàn)HA |
On yarn | 集群模式 | 運(yùn)行在yarn資源管理器框架之上，由yarn負(fù)責(zé)資源管理，Spark負(fù)責(zé)任務(wù)調(diào)度和計算 |
On mesos | 集群模式 | 運(yùn)行在mesos資源管理器框架之上，由mesos負(fù)責(zé)資源管理，Spark負(fù)責(zé)任務(wù)調(diào)度和計算 |
On cloud | 集群模式 | 比如AWS的EC2，使用這個模式能很方便的訪問Amazon的S3; Spark支持多種分布式存儲系統(tǒng)：HDFS和S3 |
術(shù)語 | 描述 |
Application | Spark的應(yīng)用程序，包含一個Driver program和若干Executor |
SparkContext | Spark應(yīng)用程序的入口，負(fù)責(zé)調(diào)度各個運(yùn)算資源，協(xié)調(diào)各個Worker Node上的Executor |
Driver Program | 運(yùn)行Application的main()函數(shù)并且創(chuàng)建SparkContext |
Executor | 是為Application運(yùn)行在Worker node上的一個進(jìn)程，該進(jìn)程負(fù)責(zé)運(yùn)行Task，并且負(fù)責(zé)將數(shù)據(jù)存在內(nèi)存或者磁盤上。 每個Application都會申請各自的Executor來處理任務(wù) |
Cluster Manager | 在集群上獲取資源的外部服務(wù) (例如：Standalone、Mesos、Yarn) |
Worker Node | 集群中任何可以運(yùn)行Application代碼的節(jié)點(diǎn)，運(yùn)行一個或多個Executor進(jìn)程 |
Task | 運(yùn)行在Executor上的工作單元 |
Job | SparkContext提交的具體Action操作，常和Action對應(yīng) |
Stage | 每個Job會被拆分很多組task，每組任務(wù)被稱為Stage，也稱TaskSet |
RDD | 是Resilient distributed datasets的簡稱，中文為彈性分布式數(shù)據(jù)集;是Spark最核心的模塊和類 |
DAGScheduler | 根據(jù)Job構(gòu)建基于Stage的DAG，并提交Stage給TaskScheduler |
TaskScheduler | 將Taskset提交給Worker node集群運(yùn)行并返回結(jié)果 |
Transformations | 是Spark API的一種類型，Transformation返回值還是一個RDD， 所有的Transformation采用的都是懶策略，如果只是將Transformation提交是不會執(zhí)行計算的 |
Action | 是Spark API的一種類型，Action返回值不是一個RDD，而是一個scala集合；計算只有在Action被提交的時候計算才被觸發(fā)。 |
Spark生態(tài)圈也稱為BDAS（伯克利數(shù)據(jù)分析棧），是伯克利APMLab實(shí)驗室打造的，力圖在算法（Algorithms）、機(jī)器（Machines）、人（People）之間通過大規(guī)模集成來展現(xiàn)大數(shù)據(jù)應(yīng)用的一個平臺。伯克利AMPLab運(yùn)用大數(shù)據(jù)、云計算、通信等各種資源以及各種靈活的技術(shù)方案，對海量不透明的數(shù)據(jù)進(jìn)行甄別并轉(zhuǎn)化為有用的信息，以供人們更好的理解世界。該生態(tài)圈已經(jīng)涉及到機(jī)器學(xué)習(xí)、數(shù)據(jù)挖掘、數(shù)據(jù)庫、信息檢索、自然語言處理和語音識別等多個領(lǐng)域。
Spark生態(tài)圈以Spark Core為核心，從HDFS、Amazon S3和HBase等持久層讀取數(shù)據(jù)，以MESS、YARN和自身攜帶的Standalone為資源管理器調(diào)度Job完成Spark應(yīng)用程序的計算。 這些應(yīng)用程序可以來自于不同的組件，如Spark Shell/Spark Submit的批處理、Spark Streaming的實(shí)時處理應(yīng)用、Spark SQL的即席查詢、BlinkDB的權(quán)衡查詢、MLlib/MLbase的機(jī)器學(xué)習(xí)、GraphX的圖處理和SparkR的數(shù)學(xué)計算等等。
前面介紹了Spark Core的基本情況，以下總結(jié)一下Spark內(nèi)核架構(gòu)：
l 提供了有向無環(huán)圖（DAG）的分布式并行計算框架，并提供Cache機(jī)制來支持多次迭代計算或者數(shù)據(jù)共享，大大減少迭代計算之間讀取數(shù)據(jù)局的開銷，這對于需要進(jìn)行多次迭代的數(shù)據(jù)挖掘和分析性能有很大提升
l 在Spark中引入了RDD (Resilient Distributed Dataset) 的抽象，它是分布在一組節(jié)點(diǎn)中的只讀對象集合，這些集合是彈性的，如果數(shù)據(jù)集一部分丟失，則可以根據(jù)“血統(tǒng)”對它們進(jìn)行重建，保證了數(shù)據(jù)的高容錯性；
l 移動計算而非移動數(shù)據(jù)，RDD Partition可以就近讀取分布式文件系統(tǒng)中的數(shù)據(jù)塊到各個節(jié)點(diǎn)內(nèi)存中進(jìn)行計算
l 使用多線程池模型來減少task啟動開稍
l 采用容錯的、高可伸縮性的akka作為通訊框架
SparkStreaming是一個對實(shí)時數(shù)據(jù)流進(jìn)行高通量、容錯處理的流式處理系統(tǒng)，可以對多種數(shù)據(jù)源（如Kdfka、Flume、Twitter、Zero和TCP 套接字）進(jìn)行類似Map、Reduce和Join等復(fù)雜操作，并將結(jié)果保存到外部文件系統(tǒng)、數(shù)據(jù)庫或應(yīng)用到實(shí)時儀表盤。
Spark Streaming構(gòu)架
l計算流程：Spark Streaming是將流式計算分解成一系列短小的批處理作業(yè)。這里的批處理引擎是Spark Core，也就是把Spark Streaming的輸入數(shù)據(jù)按照batch size（如1秒）分成一段一段的數(shù)據(jù)（Discretized Stream），每一段數(shù)據(jù)都轉(zhuǎn)換成Spark中的RDD（Resilient Distributed Dataset），然后將Spark Streaming中對DStream的Transformation操作變?yōu)獒槍park中對RDD的Transformation操作，將RDD經(jīng)過操作變成中間結(jié)果保存在內(nèi)存中。整個流式計算根據(jù)業(yè)務(wù)的需求可以對中間的結(jié)果進(jìn)行疊加或者存儲到外部設(shè)備。下圖顯示了Spark Streaming的整個流程。
l容錯性：對于流式計算來說，容錯性至關(guān)重要。首先我們要明確一下Spark中RDD的容錯機(jī)制。每一個RDD都是一個不可變的分布式可重算的數(shù)據(jù)集，其記錄著確定性的操作繼承關(guān)系（lineage），所以只要輸入數(shù)據(jù)是可容錯的，那么任意一個RDD的分區(qū)（Partition）出錯或不可用，都是可以利用原始輸入數(shù)據(jù)通過轉(zhuǎn)換操作而重新算出的。
對于Spark Streaming來說，其RDD的傳承關(guān)系如下圖所示，圖中的每一個橢圓形表示一個RDD，橢圓形中的每個圓形代表一個RDD中的一個Partition，圖中的每一列的多個RDD表示一個DStream（圖中有三個DStream），而每一行最后一個RDD則表示每一個Batch Size所產(chǎn)生的中間結(jié)果RDD。我們可以看到圖中的每一個RDD都是通過lineage相連接的，由于Spark Streaming輸入數(shù)據(jù)可以來自于磁盤，例如HDFS（多份拷貝）或是來自于網(wǎng)絡(luò)的數(shù)據(jù)流（Spark Streaming會將網(wǎng)絡(luò)輸入數(shù)據(jù)的每一個數(shù)據(jù)流拷貝兩份到其他的機(jī)器）都能保證容錯性，所以RDD中任意的Partition出錯，都可以并行地在其他機(jī)器上將缺失的Partition計算出來。這個容錯恢復(fù)方式比連續(xù)計算模型（如Storm）的效率更高。
l實(shí)時性：對于實(shí)時性的討論，會牽涉到流式處理框架的應(yīng)用場景。Spark Streaming將流式計算分解成多個Spark Job，對于每一段數(shù)據(jù)的處理都會經(jīng)過Spark DAG圖分解以及Spark的任務(wù)集的調(diào)度過程。對于目前版本的Spark Streaming而言，其最小的Batch Size的選取在0.5~2秒鐘之間（Storm目前最小的延遲是100ms左右），所以Spark Streaming能夠滿足除對實(shí)時性要求非常高（如高頻實(shí)時交易）之外的所有流式準(zhǔn)實(shí)時計算場景。
l擴(kuò)展性與吞吐量：Spark目前在EC2上已能夠線性擴(kuò)展到100個節(jié)點(diǎn)（每個節(jié)點(diǎn)4Core），可以以數(shù)秒的延遲處理6GB/s的數(shù)據(jù)量（60M records/s），其吞吐量也比流行的Storm高2～5倍，圖4是Berkeley利用WordCount和Grep兩個用例所做的測試，在Grep這個測試中，Spark Streaming中的每個節(jié)點(diǎn)的吞吐量是670k records/s，而Storm是115k records/s。
Shark是SparkSQL的前身，它發(fā)布于3年前，那個時候Hive可以說是SQL on Hadoop的唯一選擇，負(fù)責(zé)將SQL編譯成可擴(kuò)展的MapReduce作業(yè)，鑒于Hive的性能以及與Spark的兼容，Shark項目由此而生。
Shark即Hive on Spark，本質(zhì)上是通過Hive的HQL解析，把HQL翻譯成Spark上的RDD操作，然后通過Hive的metadata獲取數(shù)據(jù)庫里的表信息，實(shí)際HDFS上的數(shù)據(jù)和文件，會由Shark獲取并放到Spark上運(yùn)算。Shark的大特性就是快和與Hive的完全兼容，且可以在shell模式下使用rdd2sql()這樣的API，把HQL得到的結(jié)果集，繼續(xù)在scala環(huán)境下運(yùn)算，支持自己編寫簡單的機(jī)器學(xué)習(xí)或簡單分析處理函數(shù)，對HQL結(jié)果進(jìn)一步分析計算。
在2014年7月1日的Spark Summit上，Databricks宣布終止對Shark的開發(fā)，將重點(diǎn)放到Spark SQL上。Databricks表示，Spark SQL將涵蓋Shark的所有特性，用戶可以從Shark 0.9進(jìn)行無縫的升級。在會議上，Databricks表示，Shark更多是對Hive的改造，替換了Hive的物理執(zhí)行引擎，因此會有一個很快的速度。然而，不容忽視的是，Shark繼承了大量的Hive代碼，因此給優(yōu)化和維護(hù)帶來了大量的麻煩。隨著性能優(yōu)化和先進(jìn)分析整合的進(jìn)一步加深，基于MapReduce設(shè)計的部分無疑成為了整個項目的瓶頸。因此，為了更好的發(fā)展，給用戶提供一個更好的體驗，Databricks宣布終止Shark項目，從而將更多的精力放到Spark SQL上。
Spark SQL允許開發(fā)人員直接處理RDD，同時也可查詢例如在 Apache Hive上存在的外部數(shù)據(jù)。Spark SQL的一個重要特點(diǎn)是其能夠統(tǒng)一處理關(guān)系表和RDD，使得開發(fā)人員可以輕松地使用SQL命令進(jìn)行外部查詢，同時進(jìn)行更復(fù)雜的數(shù)據(jù)分析。除了Spark SQL外，Michael還談到Catalyst優(yōu)化框架，它允許Spark SQL自動修改查詢方案，使SQL更有效地執(zhí)行。
還有Shark的作者是來自中國的博士生辛湜（Reynold Xin），也是Spark的核心成員，具體信息可以看他的專訪 http://www.csdn.net/article/2013-04-26/2815057-Spark-Reynold
Spark SQL的特點(diǎn):
l引入了新的RDD類型SchemaRDD，可以象傳統(tǒng)數(shù)據(jù)庫定義表一樣來定義SchemaRDD，SchemaRDD由定義了列數(shù)據(jù)類型的行對象構(gòu)成。SchemaRDD可以從RDD轉(zhuǎn)換過來，也可以從Parquet文件讀入，也可以使用HiveQL從Hive中獲取。
l內(nèi)嵌了Catalyst查詢優(yōu)化框架，在把SQL解析成邏輯執(zhí)行計劃之后，利用Catalyst包里的一些類和接口，執(zhí)行了一些簡單的執(zhí)行計劃優(yōu)化，最后變成RDD的計算
l在應(yīng)用程序中可以混合使用不同來源的數(shù)據(jù)，如可以將來自HiveQL的數(shù)據(jù)和來自SQL的數(shù)據(jù)進(jìn)行Join操作。
Shark的出現(xiàn)使得SQL-on-Hadoop的性能比Hive有了10-100倍的提高， 那么，擺脫了Hive的限制，SparkSQL的性能又有怎么樣的表現(xiàn)呢？雖然沒有Shark相對于Hive那樣矚目地性能提升，但也表現(xiàn)得非常優(yōu)異，如下圖所示：
為什么sparkSQL的性能會得到怎么大的提升呢？主要sparkSQL在下面幾點(diǎn)做了優(yōu)化：
1. 內(nèi)存列存儲（In-Memory Columnar Storage） sparkSQL的表數(shù)據(jù)在內(nèi)存中存儲不是采用原生態(tài)的JVM對象存儲方式，而是采用內(nèi)存列存儲；
2. 字節(jié)碼生成技術(shù)（Bytecode Generation） Spark1.1.0在Catalyst模塊的expressions增加了codegen模塊，使用動態(tài)字節(jié)碼生成技術(shù)，對匹配的表達(dá)式采用特定的代碼動態(tài)編譯。另外對SQL表達(dá)式都作了CG優(yōu)化， CG優(yōu)化的實(shí)現(xiàn)主要還是依靠Scala2.10的運(yùn)行時放射機(jī)制（runtime reflection）；
3. Scala代碼優(yōu)化 SparkSQL在使用Scala編寫代碼的時候，盡量避免低效的、容易GC的代碼；盡管增加了編寫代碼的難度，但對于用戶來說接口統(tǒng)一。
BlinkDB 是一個用于在海量數(shù)據(jù)上運(yùn)行交互式 SQL 查詢的大規(guī)模并行查詢引擎，它允許用戶通過權(quán)衡數(shù)據(jù)精度來提升查詢響應(yīng)時間，其數(shù)據(jù)的精度被控制在允許的誤差范圍內(nèi)。為了達(dá)到這個目標(biāo)，BlinkDB 使用兩個核心思想:
l一個自適應(yīng)優(yōu)化框架，從原始數(shù)據(jù)隨著時間的推移建立并維護(hù)一組多維樣本；
l一個動態(tài)樣本選擇策略，選擇一個適當(dāng)大小的示例基于查詢的準(zhǔn)確性和（或）響應(yīng)時間需求。
和傳統(tǒng)關(guān)系型數(shù)據(jù)庫不同，BlinkDB是一個很有意思的交互式查詢系統(tǒng)，就像一個蹺蹺板，用戶需要在查詢精度和查詢時間上做一權(quán)衡；如果用戶想更快地獲取查詢結(jié)果，那么將犧牲查詢結(jié)果的精度；同樣的，用戶如果想獲取更高精度的查詢結(jié)果，就需要犧牲查詢響應(yīng)時間。用戶可以在查詢的時候定義一個失誤邊界。
MLBase是Spark生態(tài)圈的一部分專注于機(jī)器學(xué)習(xí)，讓機(jī)器學(xué)習(xí)的門檻更低，讓一些可能并不了解機(jī)器學(xué)習(xí)的用戶也能方便地使用MLbase。MLBase分為四部分：MLlib、MLI、ML Optimizer和MLRuntime。
l ML Optimizer會選擇它認(rèn)為最適合的已經(jīng)在內(nèi)部實(shí)現(xiàn)好了的機(jī)器學(xué)習(xí)算法和相關(guān)參數(shù)，來處理用戶輸入的數(shù)據(jù)，并返回模型或別的幫助分析的結(jié)果；
l MLI 是一個進(jìn)行特征抽取和高級ML編程抽象的算法實(shí)現(xiàn)的API或平臺；
l MLlib是Spark實(shí)現(xiàn)一些常見的機(jī)器學(xué)習(xí)算法和實(shí)用程序，包括分類、回歸、聚類、協(xié)同過濾、降維以及底層優(yōu)化，該算法可以進(jìn)行可擴(kuò)充； MLRuntime 基于Spark計算框架，將Spark的分布式計算應(yīng)用到機(jī)器學(xué)習(xí)領(lǐng)域。
總的來說，MLBase的核心是他的優(yōu)化器，把聲明式的Task轉(zhuǎn)化成復(fù)雜的學(xué)習(xí)計劃，產(chǎn)出最優(yōu)的模型和計算結(jié)果。與其他機(jī)器學(xué)習(xí)Weka和Mahout不同的是：
l MLBase是分布式的，Weka是一個單機(jī)的系統(tǒng)；
l MLBase是自動化的，Weka和Mahout都需要使用者具備機(jī)器學(xué)習(xí)技能，來選擇自己想要的算法和參數(shù)來做處理；
l MLBase提供了不同抽象程度的接口，讓算法可以擴(kuò)充
l MLBase基于Spark這個平臺
GraphX是Spark中用于圖(e.g., Web-Graphs and Social Networks)和圖并行計算(e.g., PageRank and Collaborative Filtering)的API,可以認(rèn)為是GraphLab(C++)和Pregel(C++)在Spark(Scala)上的重寫及優(yōu)化，跟其他分布式圖計算框架相比，GraphX大的貢獻(xiàn)是，在Spark之上提供一棧式數(shù)據(jù)解決方案，可以方便且高效地完成圖計算的一整套流水作業(yè)。GraphX最先是伯克利AMPLAB的一個分布式圖計算框架項目，后來整合到Spark中成為一個核心組件。
GraphX的核心抽象是Resilient Distributed Property Graph，一種點(diǎn)和邊都帶屬性的有向多重圖。它擴(kuò)展了Spark RDD的抽象，有Table和Graph兩種視圖，而只需要一份物理存儲。兩種視圖都有自己獨(dú)有的操作符，從而獲得了靈活操作和執(zhí)行效率。如同Spark，GraphX的代碼非常簡潔。GraphX的核心代碼只有3千多行，而在此之上實(shí)現(xiàn)的Pregel模型，只要短短的20多行。GraphX的代碼結(jié)構(gòu)整體下圖所示，其中大部分的實(shí)現(xiàn)，都是圍繞Partition的優(yōu)化進(jìn)行的。這在某種程度上說明了點(diǎn)分割的存儲和相應(yīng)的計算優(yōu)化的確是圖計算框架的重點(diǎn)和難點(diǎn)。
GraphX的底層設(shè)計有以下幾個關(guān)鍵點(diǎn)。
1.對Graph視圖的所有操作，最終都會轉(zhuǎn)換成其關(guān)聯(lián)的Table視圖的RDD操作來完成。這樣對一個圖的計算，最終在邏輯上，等價于一系列RDD的轉(zhuǎn)換過程。因此，Graph最終具備了RDD的3個關(guān)鍵特性：Immutable、Distributed和Fault-Tolerant。其中最關(guān)鍵的是Immutable（不變性）。邏輯上，所有圖的轉(zhuǎn)換和操作都產(chǎn)生了一個新圖；物理上，GraphX會有一定程度的不變頂點(diǎn)和邊的復(fù)用優(yōu)化，對用戶透明。
2.兩種視圖底層共用的物理數(shù)據(jù)，由RDD[Vertex-Partition]和RDD[EdgePartition]這兩個RDD組成。點(diǎn)和邊實(shí)際都不是以表Collection[tuple]的形式存儲的，而是由VertexPartition/EdgePartition在內(nèi)部存儲一個帶索引結(jié)構(gòu)的分片數(shù)據(jù)塊，以加速不同視圖下的遍歷速度。不變的索引結(jié)構(gòu)在RDD轉(zhuǎn)換過程中是共用的，降低了計算和存儲開銷。
3.圖的分布式存儲采用點(diǎn)分割模式，而且使用partitionBy方法，由用戶指定不同的劃分策略（PartitionStrategy）。劃分策略會將邊分配到各個EdgePartition，頂點(diǎn)Master分配到各個VertexPartition，EdgePartition也會緩存本地邊關(guān)聯(lián)點(diǎn)的Ghost副本。劃分策略的不同會影響到所需要緩存的Ghost副本數(shù)量，以及每個EdgePartition分配的邊的均衡程度，需要根據(jù)圖的結(jié)構(gòu)特征選取最佳策略。目前有EdgePartition2d、EdgePartition1d、RandomVertexCut和CanonicalRandomVertexCut這四種策略。在淘寶大部分場景下，EdgePartition2d效果最好。
SparkR是AMPLab發(fā)布的一個R開發(fā)包，使得R擺脫單機(jī)運(yùn)行的命運(yùn)，可以作為Spark的job運(yùn)行在集群上，極大得擴(kuò)展了R的數(shù)據(jù)處理能力。
SparkR的幾個特性：
l 提供了Spark中彈性分布式數(shù)據(jù)集（RDD）的API，用戶可以在集群上通過R shell交互性的運(yùn)行Spark job。
l 支持序化閉包功能，可以將用戶定義函數(shù)中所引用到的變量自動序化發(fā)送到集群中其他的機(jī)器上。
l SparkR還可以很容易地調(diào)用R開發(fā)包，只需要在集群上執(zhí)行操作前用includePackage讀取R開發(fā)包就可以了，當(dāng)然集群上要安裝R開發(fā)包。
Tachyon是一個高容錯的分布式文件系統(tǒng)，允許文件以內(nèi)存的速度在集群框架中進(jìn)行可靠的共享，就像Spark和 MapReduce那樣。通過利用信息繼承，內(nèi)存侵入，Tachyon獲得了高性能。Tachyon工作集文件緩存在內(nèi)存中，并且讓不同的 Jobs/Queries以及框架都能內(nèi)存的速度來訪問緩存文件”。因此，Tachyon可以減少那些需要經(jīng)常使用的數(shù)據(jù)集通過訪問磁盤來獲得的次數(shù)。Tachyon兼容Hadoop，現(xiàn)有的Spark和MR程序不需要任何修改而運(yùn)行。
在2013年4月，AMPLab共享了其Tachyon 0.2.0 Alpha版本的Tachyon，其宣稱性能為HDFS的300倍，繼而受到了極大的關(guān)注。Tachyon的幾個特性如下：
lJAVA-Like File API
Tachyon提供類似JAVA File類的API,
l兼容性
Tachyon實(shí)現(xiàn)了HDFS接口，所以Spark和MR程序不需要任何修改即可運(yùn)行。
l可插拔的底層文件系統(tǒng)
Tachyon是一個可插拔的底層文件系統(tǒng)，提供容錯功能。tachyon將內(nèi)存數(shù)據(jù)記錄在底層文件系統(tǒng)。它有一個通用的接口，使得可以很容易的插入到不同的底層文件系統(tǒng)。目前支持HDFS，S3，GlusterFS和單節(jié)點(diǎn)的本地文件系統(tǒng)，以后將支持更多的文件系統(tǒng)。
看完上述內(nèi)容，你們對如何進(jìn)行spark原理及生態(tài)圈分析有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道，感謝大家的支持。
重慶分公司
重慶分公司
