《大數(shù)據(jù)運(yùn)營》大數(shù)據(jù)運(yùn)營技術(shù)體系

大數(shù)據(jù)運(yùn)營技術(shù)體系本章知識點(diǎn)(1)掌握Hadoop、Spark、Flink3種主流技術(shù)的基本原理。(2)掌握數(shù)據(jù)處理的基本流程。(3)了解數(shù)據(jù)挖掘概論與數(shù)據(jù)挖掘的常用方法。(4)掌握數(shù)據(jù)可視化庫及可視化軟件的概念。01大數(shù)據(jù)技術(shù)概述02數(shù)據(jù)處理與數(shù)據(jù)挖掘概述03數(shù)據(jù)可視化概述PART01大數(shù)據(jù)技術(shù)概述Hadoo核心技術(shù)Hadoo核心技術(shù)Hadoop是Apache軟件基金會下用Java語言開發(fā)的一個(gè)開源分布式計(jì)算平臺，在大量計(jì)算機(jī)組成的集群中對海量數(shù)據(jù)進(jìn)行分布式計(jì)算。它是一個(gè)適合大數(shù)據(jù)的分布式存儲和計(jì)算平臺。Hadoop最早起源于Nutch搜索引擎,Nutch是一個(gè)開源Java實(shí)現(xiàn)的搜索引擎Nutch的設(shè)計(jì)目標(biāo)是構(gòu)建一個(gè)大型的全網(wǎng)搜索引擎,包括網(wǎng)頁抓取、索引、查詢等功能,但隨著抓取網(wǎng)頁數(shù)量的增加，遇到了嚴(yán)重的可擴(kuò)展性問題，即如何解決數(shù)十億網(wǎng)頁的存儲和索引問題。在Nutch的開發(fā)人員正一籌莫展之際谷歌發(fā)表的兩篇論文為該問題提供了可行的解決方案：分布式文件系統(tǒng)distributedfilesystem，DFS)可用于處理海量網(wǎng)頁的存儲；分布式計(jì)算框架MapReduce可用于處理海量網(wǎng)頁的索引計(jì)算問題。Hadoo核心技術(shù)Hadoop之父道格·卡廷(Dougcutting)帶領(lǐng)Nutch的開發(fā)人員基于Google的兩篇論文完成了相應(yīng)的開源實(shí)現(xiàn)Hadoo分布式文件系統(tǒng)HadoopdistributedfilesystemHDFS)和MapReduce，并從Nutch中剝離成為獨(dú)立項(xiàng)目Hadoop，到2008年1月，Hadoop成為Apache頂級項(xiàng)目，迎來了它的快速發(fā)展期Hadoop的大象Logo靈感來源于道格·卡廷女兒的玩具大象。狹義上來說，Hadoop就是單獨(dú)指代hadoop這個(gè)計(jì)算框架。廣義上來說，Hadoop指代大數(shù)據(jù)的一個(gè)軟件生態(tài)圈，包括很多其他的軟件，如圖所示。MapReduc編程模型1)MapReduce的概念MapReduce是一種大規(guī)模數(shù)據(jù)處理編程模型，用于大規(guī)模數(shù)據(jù)集的并行運(yùn)算，是Hadoop核心組件之一。MaReduce的核心功能是將用戶編寫的業(yè)務(wù)邏輯代碼和自帶默認(rèn)組件整合成一個(gè)完整的分布式運(yùn)算程序，并運(yùn)行在Hadoop集群上。2)MapReduce的編程思想MapReduce的思想核心是“分而治之”適用于大量復(fù)雜的任務(wù)處理場景(大規(guī)模數(shù)據(jù)處理場景)。Map(映射)負(fù)責(zé)“分”,即把復(fù)雜的任務(wù)分解為若干個(gè)“簡單的任務(wù)”來并行處理?？梢赃M(jìn)行拆分的前提是這些小任務(wù)可以并行計(jì)算,彼此間幾乎沒有依賴關(guān)系Reduce(化簡)負(fù)責(zé)“合”,即對Map階段的結(jié)果進(jìn)行全局匯總。這兩個(gè)階段合起來正是MapReduce思想的體現(xiàn)。舉例如下比如我們要統(tǒng)計(jì)圖書館所有類型的書,如果一個(gè)人統(tǒng)計(jì)的話,不知道要統(tǒng)計(jì)多久,如果人多點(diǎn),你統(tǒng)計(jì)1號書架,我統(tǒng)計(jì)2號書架,他統(tǒng)計(jì)3號書架····.·人越多,統(tǒng)計(jì)的速度就越快。這就是Map階段,可以并行地做一件事,彼此之間并沒有依賴關(guān)系。數(shù)完之后，聚到一起，把所有人的統(tǒng)計(jì)數(shù)加在一起，就得出的圖書館書籍的總數(shù)。這就是Reduce階段。MapReduc編程模型3)MapReduce的框架結(jié)構(gòu)一個(gè)完整的MapReduce程序在分布式運(yùn)行時(shí)有三類實(shí)例進(jìn)程:MRAppMaster：負(fù)責(zé)整個(gè)程序的過程調(diào)度及狀態(tài)協(xié)調(diào)。MapTask:負(fù)責(zé)Map階段整個(gè)數(shù)據(jù)處理流程。ReduceTask:負(fù)責(zé)reduce階段的整個(gè)數(shù)據(jù)處理流程。4)MapReduce的編程規(guī)范（1）用戶編寫的程序分成三個(gè)部分：Mapper，Reducer，Driver(提交運(yùn)行mr程序的客戶端)。（2）Mapper的輸入數(shù)據(jù)是鍵值對的形式（鍵與值的類型可自定義）。（3）Mapper的輸出數(shù)據(jù)是鍵值對的形式（鍵與值的類型可自定義）。（4）Mapper中的業(yè)務(wù)邏輯寫在map()方法中。（5）map()方法（maptask進(jìn)程）對每一個(gè)調(diào)用一次。（6）Reducer的輸入數(shù)據(jù)類型對應(yīng)Mapper的輸出數(shù)據(jù)類型，也是鍵值對。（7）Reducer的業(yè)務(wù)邏輯寫在reduce()方法中。（8）Reducetask進(jìn)程對每一組相同鍵的組調(diào)用一次reduce()方法。（9）用戶自定義的Mapper和Reducer都要繼承各自的父類。（10）整個(gè)程序需要一個(gè)Drvier來進(jìn)行提交，提交的是一個(gè)描述了各種必要信息的job對象。Hadoop分布式文件系統(tǒng)HDFS1)HDFS的概念HDFS是一個(gè)可以運(yùn)行在通用硬件上的分布式文件系統(tǒng)（DistributedFileSystem）。它和現(xiàn)有的分布式文件系統(tǒng)有很多共同點(diǎn)。但同時(shí)，它和其他的分布式文件系統(tǒng)的區(qū)別也是很明顯的。HDFS是一個(gè)高度容錯(cuò)性的系統(tǒng)，適合部署在廉價(jià)的機(jī)器上。HDFS能提供高吞吐量的數(shù)據(jù)訪問，非常適合大規(guī)模數(shù)據(jù)集上的應(yīng)用。2)HDFS的原理多臺計(jì)算機(jī)(集群)聯(lián)網(wǎng)協(xié)同工作就像單臺系統(tǒng)一樣解決某種問題，這樣的系統(tǒng)我們稱之為分布式系統(tǒng)。分布式文件系統(tǒng)是分布式系統(tǒng)的一個(gè)子集，它們解決的問題就是數(shù)據(jù)存儲。換句話說，它們是橫跨在多臺計(jì)算機(jī)上的存儲系統(tǒng)。存儲在分布式文件系統(tǒng)上的數(shù)據(jù)自動(dòng)分布在不同的節(jié)點(diǎn)上。分布式文件系統(tǒng)在大數(shù)據(jù)時(shí)代有著廣泛的應(yīng)用前景，它們?yōu)榇鎯吞幚韥碜跃W(wǎng)絡(luò)和其它地方的超大規(guī)模數(shù)據(jù)提供所需的擴(kuò)展能力，為各類分布式運(yùn)算框架（如：mapreduce，spark，……）提供數(shù)據(jù)存儲服務(wù)。Hadoop分布式文件系統(tǒng)HDFS3)HDFS設(shè)計(jì)思想分而治之：將大文件、大批量文件，分布式存放在同一集群中的不同服務(wù)器上，以便于采取分而治之的方式對海量數(shù)據(jù)進(jìn)行運(yùn)算分析。4)HDFS架構(gòu)HDFS是一個(gè)塊結(jié)構(gòu)的文件系統(tǒng)，其中每個(gè)文件被分成預(yù)定大小的塊（Hadoop1.x版本塊大小為64M，2.x版本塊大小為128M），這些塊存儲在一臺或多臺機(jī)器的集群中。HDFS遵循主/從架構(gòu)，其中集群包含單個(gè)NameNode（主節(jié)點(diǎn)），所有其他節(jié)點(diǎn)都是DataNode（從節(jié)點(diǎn)）。HDFS可以部署在支持Java的各種機(jī)器上。雖然可以在一臺機(jī)器上運(yùn)行多個(gè)DataNode，但在實(shí)際應(yīng)用中，這些DataNode分布在不同的機(jī)器上。Hadoop分布式文件系統(tǒng)HDFSNameNode在原生的Hadoop集群中，HDFS分為三個(gè)角色：NameNode、DataNode、SecondaryNameNode。DataNodeHDFS中的從屬節(jié)點(diǎn)。不具備高質(zhì)量或高可用性，主要負(fù)責(zé)將數(shù)據(jù)落實(shí)到本地存儲，所以DataNode所在機(jī)器通常配置有大量的硬盤空間。DataNode會定期向NameNode發(fā)送心跳，如果NameNode長時(shí)間沒有接受到DataNode發(fā)送的心跳，NameNode就會認(rèn)為該DataNode失效。SecondaryNameNode是NameNode的一個(gè)助手節(jié)點(diǎn)，來幫助NameNode更好的工作。它存在的目的就是為HDFS中提供一個(gè)檢查點(diǎn)，它會定時(shí)到NameNode去獲取editlogs，并更新到fsimage上，一旦它有了新的fsimage文件，它將其拷貝回NameNode中，當(dāng)NameNode在下次重啟時(shí)會使用這個(gè)新的fsimage文件，從而減少重啟的時(shí)間。ApacheHadoopHDFS架構(gòu)中的主節(jié)點(diǎn)，主要是用來保存HDFS的元數(shù)據(jù)信息，比如命名空間信息，塊信息等。當(dāng)它運(yùn)行的時(shí)候，這些信息是存在內(nèi)存中的。但是這些信息也可以持久化到磁盤上。Hadoop分布式文件系統(tǒng)HDFS5)HDFS的優(yōu)缺點(diǎn)事物都具有兩面性，HDFS再強(qiáng)大也會存在一些缺點(diǎn)，下面讓我們了解一下HDFS的優(yōu)缺點(diǎn)，從而可以在不同的應(yīng)用場景中更好的發(fā)揮HDFS的一些特性。優(yōu)點(diǎn)概述高容錯(cuò)性數(shù)據(jù)自動(dòng)保存多個(gè)副本(默認(rèn)為3份，可通過修改配置文件來修改副本數(shù))，副本丟失后，自動(dòng)恢復(fù)。適合批處理HDFS會將數(shù)據(jù)位置暴露給計(jì)算框架，通過移動(dòng)計(jì)算而非移動(dòng)數(shù)據(jù)的方式來減少文件I/O，從而提高計(jì)算效率。適合大規(guī)模數(shù)據(jù)處理適合GB，TB，甚至PB級數(shù)據(jù)的計(jì)算，百萬規(guī)模以上的文件處理?？蓸?gòu)建在廉價(jià)機(jī)器上HDFS通過多副本提高可靠性，提供了容錯(cuò)和恢復(fù)機(jī)制。HDFS的存儲節(jié)點(diǎn)只需要提供磁盤存儲空間即可，對操作系統(tǒng)與其他硬件資源沒有要求。缺點(diǎn)概述不支持低延遲數(shù)據(jù)訪問毫秒級的數(shù)據(jù)訪問，HDFS是不支持的。所以說HDFS不能作為實(shí)時(shí)任務(wù)的數(shù)據(jù)源。小文件存儲HDFS上的每一個(gè)文件的元數(shù)據(jù)都由NameNode進(jìn)行管理，如果有大量的小文件，將會占用NameNode大量內(nèi)存，并且文件尋道時(shí)間超過讀取時(shí)間，所以HDFS建議將小文件進(jìn)行合并或者說使用HDFS提供的archive檔案機(jī)制。文件只支持追加HDFS上的文件只支持追加操作，不支持修改。而且一個(gè)文件同一時(shí)間只能有一個(gè)用戶進(jìn)行寫入操作。分布式資源調(diào)度管理系統(tǒng)分布式資源調(diào)度管理系統(tǒng),即另一種資源協(xié)調(diào)者(yetanotherresourcenegotiator，YARN)是Hadoop的資源管理器,它是一個(gè)分布式的資源管理系統(tǒng),用以提高分布式集群環(huán)境下的資源利用率,這些資源包括內(nèi)存、輸入輸出、網(wǎng)絡(luò)、磁盤等,其產(chǎn)生的原因是為了解決原MapReduce框架的不足。1)YARN的概念我們先來了解一下在Yarn誕生之前，Hadoop是如何進(jìn)行資源調(diào)度的。在Hadoop1.X版本，一個(gè)Hadoop集群可分解為兩個(gè)抽象實(shí)體：Mapreduce計(jì)算引擎和分布式文件系統(tǒng)。當(dāng)一個(gè)客戶端向一個(gè)Hadoop集群發(fā)出一個(gè)請求時(shí)，此請求由Jobtracker管理。Jobtracker與Namenode聯(lián)合將任務(wù)分發(fā)到離它所處理的數(shù)據(jù)盡可能近的位置。然后Jobtracker將Map和Reduce任務(wù)安排到一個(gè)或多個(gè)Tasktracker上的可用插槽中。Tasktracker與Datanode一起對來自Datanode的數(shù)據(jù)執(zhí)行Map和Reduce任務(wù)。當(dāng)Map和Reduce任務(wù)完成時(shí)，Tasktracker會告知Jobtracker，后者確定所有任務(wù)何時(shí)完成并最終告知客戶作業(yè)已完成。分布式資源調(diào)度管理系統(tǒng)在使用Jobtracker進(jìn)行資源調(diào)度的時(shí)候，會存在如下問題：Jobtracker是集群事務(wù)的集中處理點(diǎn)，存在單點(diǎn)故障。Jobtracker需要完成的任務(wù)太多，既要維護(hù)Job的狀態(tài)又要維護(hù)Job的Task的狀態(tài)，造成過多的資源消耗。在Tasktracker端，用Map/ReduceTask作為資源的表示過于簡單，沒有考慮到Cpu、內(nèi)存等資源情況，當(dāng)把兩個(gè)需要消耗大內(nèi)存的Task調(diào)度到一起，很容易出現(xiàn)OOM（內(nèi)存溢出）。把資源強(qiáng)制劃分為Map/ReduceSlot，當(dāng)只有MapTask時(shí)，ReduceSlot不能用；當(dāng)只有ReduceTask時(shí)，MapSlot不能用，容易造成資源利用不足。到了Hadoop2.X版本，Yarn作為Hadoop第三大核心組件橫空出世，為了解決了Hadoop1.X版本資源調(diào)度的問題，YARN將資源管理和作業(yè)監(jiān)控/調(diào)度這兩個(gè)功能拆分開來，交由不同的守護(hù)進(jìn)程完成。具體來說就是有一個(gè)全局的資源管理者（Resourcemanager）和負(fù)責(zé)每一個(gè)應(yīng)用的應(yīng)用管理者（Applicationmaster）。分布式資源調(diào)度管理系統(tǒng)ResourceManager2)YARN的基本架構(gòu)YARN是一個(gè)資源管理、任務(wù)調(diào)度的框架，主要包含三大模塊：ResourceManager（簡稱RM）、NodeManager（簡稱NM）、ApplicationMaster（簡稱AM）。NodeManager是每個(gè)節(jié)點(diǎn)上的資源和任務(wù)管理器，它是管理這臺機(jī)器的代理，負(fù)責(zé)該節(jié)點(diǎn)程序的運(yùn)行，以及該節(jié)點(diǎn)資源的管理和監(jiān)控，YARN集群每個(gè)節(jié)點(diǎn)都會運(yùn)行一個(gè)NodeManager。NodeManager會定時(shí)向ResourceManager匯報(bào)本節(jié)點(diǎn)資源（CPU、內(nèi)存）的使用情況和Container的運(yùn)行狀態(tài)。當(dāng)ResourceManager宕機(jī)時(shí)NodeManager自動(dòng)連接RM備用節(jié)點(diǎn)。ApplicationMaster用戶提交的每個(gè)應(yīng)用程序均包含一個(gè)ApplicationMaster。ResourceManager會為應(yīng)用分配一個(gè)Container（分配的資源）來運(yùn)行ApplicationMaster，ApplicationMaster會將得到的任務(wù)進(jìn)一步分配給內(nèi)部的任務(wù)(資源的二次分配)，還有就是負(fù)責(zé)監(jiān)控所有任務(wù)運(yùn)行狀態(tài)，并在任務(wù)運(yùn)行失敗時(shí)重新為任務(wù)申請資源以重啟任務(wù)。負(fù)責(zé)整個(gè)集群的資源管理和分配，是一個(gè)全局的資源管理系統(tǒng)。NodeManager以心跳的方式向ResourceManager匯報(bào)資源使用情況（目前主要是CPU和內(nèi)存的使用情況）。RM只接受NM的資源回報(bào)信息，對于具體的資源處理則交給NM自己處理。YARNScheduler根據(jù)application的請求為其分配資源，不負(fù)責(zé)applicationjob的監(jiān)控、追蹤、運(yùn)行狀態(tài)反饋、啟動(dòng)等工作。分布式資源調(diào)度管理系統(tǒng)3)YARN調(diào)度工作的流程(1)客戶端向RM提交應(yīng)用程序,其中包括啟動(dòng)該應(yīng)用的AM所必需信息。例如AM程序、啟動(dòng)AM的命令、用戶程序等。(2)RM啟動(dòng)一個(gè)容器用于運(yùn)行AM(3)啟動(dòng)中的AM向RM注冊自己啟動(dòng)成后與RM保持心跳(4)AM向RM發(fā)送請求，申請相應(yīng)數(shù)目的容器(5)RM返回AM申請的容器信息。申請成功的容器,由AM進(jìn)行初始化。容器的啟動(dòng)信息初始化后,AM與對應(yīng)的NM通信,要求NM啟動(dòng)容器。AM與NM保持心跳,從而對NM上運(yùn)行的任務(wù)進(jìn)行監(jiān)控和管理(6)容器運(yùn)行期間，AM對容器進(jìn)行監(jiān)控。容器通過RPC協(xié)議向?qū)?yīng)的AM匯報(bào)自己的進(jìn)度和狀態(tài)等信息.(7)應(yīng)用運(yùn)行期間，客戶端直接與AM通信獲取應(yīng)用的狀態(tài)、進(jìn)度更新等信息。(8)應(yīng)用運(yùn)行結(jié)束后，AM向RM注銷自己，并允許屬于它的容器被收回。分布式資源調(diào)度管理系統(tǒng)4)YARN的調(diào)度策略在YARN中，負(fù)責(zé)給應(yīng)用分配資源的就是調(diào)度器，調(diào)度本身就是一個(gè)難題，很難找到一個(gè)完美的策略可以解決所有的應(yīng)用場景。為此YARN提供了3種調(diào)度器，也可以叫作調(diào)度策略如表所示。調(diào)度器分類策略特點(diǎn)先進(jìn)先出調(diào)度器FIFOSchedulerFIFOScheduler把應(yīng)用按提交的順序排成一個(gè)隊(duì)列，這是一個(gè)先進(jìn)先出隊(duì)列，在進(jìn)行資源分配的時(shí)候，先給隊(duì)列中最頭上的應(yīng)用進(jìn)行分配資源，待最頭上的應(yīng)用需求滿足后再給下一個(gè)分配，以此類推。FIFOScheduler是最簡單也是最容易理解的調(diào)度器，也不需要任何配置，但它并不適用于共享集群。大的應(yīng)用可能會占用所有集群資源，這就導(dǎo)致其它應(yīng)用被阻塞公平調(diào)度器FairScheduler在Fair調(diào)度器中，我們不需要預(yù)先占用一定的系統(tǒng)資源，F(xiàn)air調(diào)度器會為所有運(yùn)行的job動(dòng)態(tài)的調(diào)整系統(tǒng)資源當(dāng)?shù)谝粋€(gè)占用資源較大的job提交時(shí)，如果只有這一個(gè)job在運(yùn)行，那么它會獲得所有的集群資源；此時(shí)，當(dāng)?shù)诙€(gè)小任務(wù)提交后，F(xiàn)air調(diào)度器就會分配一半資源給這個(gè)小任務(wù)，讓這兩個(gè)任務(wù)公平的共享集群資源。容器調(diào)度器CapacitySchedulerCapacity調(diào)度器允許多個(gè)組織共享整個(gè)集群，每個(gè)組織可以獲得集群的一部分計(jì)算能力。通過為每個(gè)組織分配專門的隊(duì)列，然后再為每個(gè)隊(duì)列分配一定的集群資源，這樣整個(gè)集群就可以通過設(shè)置多個(gè)隊(duì)列的方式給多個(gè)組織提供服務(wù)了。除此之外，隊(duì)列內(nèi)部又可以垂直劃分，這樣一個(gè)組織內(nèi)部的多個(gè)成員就可以共享這個(gè)隊(duì)列資源了，在一個(gè)隊(duì)列內(nèi)部，資源的調(diào)度是采用的是先進(jìn)先出(FIFO)策略。高性能分布式協(xié)調(diào)服務(wù)高性能分布式協(xié)調(diào)服務(wù)(ZooKeeper)致力于為分布式應(yīng)用提供一個(gè)高性能、高可用且具有嚴(yán)格順序訪問控制能力的分布式協(xié)調(diào)服務(wù)。ZooKeeper由雅虎研究院開發(fā)，是GoogleChubby的開源實(shí)現(xiàn),后來托管到Apache,于2010年11月正式成為Apache的頂級項(xiàng)目。ZooKeeper的應(yīng)用場景有很多，比如說HadoopHA(高可用)集群、KafkaHBase都強(qiáng)依賴于ZooKeeper,讓我們一起來看下ZooKeeper有哪些特性。1)zookeeper的五大特性特性概述順序一致性從同一個(gè)客戶端發(fā)起的事務(wù)請求，最終將會嚴(yán)格地按照其發(fā)起的順序被應(yīng)用到Zookeeper去。原子性所有請求的響應(yīng)結(jié)果在整個(gè)分布式集群環(huán)境中具備原子性，即要么整個(gè)集群中所有機(jī)器都成功的處理了某個(gè)請求，要么就都沒有處理，絕對不會出現(xiàn)集群中一部分機(jī)器處理了某一個(gè)請求，而另一部分機(jī)器卻沒有處理的情況。單一性無論客戶端連接到ZooKeeper集群中哪個(gè)服務(wù)器，每個(gè)客戶端所看到的服務(wù)端模型都是一致的，不可能出現(xiàn)兩種不同的數(shù)據(jù)狀態(tài)，因?yàn)閆ooKeeper集群中每臺服務(wù)器之間會進(jìn)行數(shù)據(jù)同步?？煽啃砸坏┓?wù)端數(shù)據(jù)的狀態(tài)發(fā)送了變化，就會立即存儲起來，除非此時(shí)有另一個(gè)請求對其進(jìn)行了變更，否則數(shù)據(jù)一定是可靠的。實(shí)時(shí)性當(dāng)某個(gè)請求被成功處理后，ZooKeeper僅僅保證在一定的時(shí)間段內(nèi)，客戶端最終一定能從服務(wù)端上讀取到最新的數(shù)據(jù)狀態(tài)，即ZooKeeper保證數(shù)據(jù)的最終一致性。Zookeeper具有嚴(yán)格的寫操作順序性，客戶端能夠基于zookeeper實(shí)現(xiàn)一些復(fù)雜的同步原語。對于來自客戶端的每個(gè)更新請求，都會分配一個(gè)全局唯一的遞增編號，這個(gè)編號反應(yīng)了所有事物操作的先后順序。高性能分布式協(xié)調(diào)服務(wù)2)ZooKeeper的角色領(lǐng)導(dǎo)者(Leader)Leader是ZooKeeper集群工作的核心。主要負(fù)責(zé)調(diào)度工作，是事務(wù)請求的調(diào)度處理者和集群內(nèi)部各服務(wù)器的調(diào)度。跟隨者(Follower)Follower是ZooKeeper集群的跟隨者。主要負(fù)責(zé)處理客戶端非事務(wù)性請求(讀取數(shù)據(jù))并轉(zhuǎn)發(fā)事務(wù)請求給Leader服務(wù)器和參與Leader選舉投票。觀察者(Observer)Observer充當(dāng)觀察者角色，觀察ZooKeeper集群的最新狀態(tài)變化并將這些狀態(tài)同步過來,其對于非事務(wù)請求可以進(jìn)行獨(dú)立處理,對于事務(wù)請求,則會轉(zhuǎn)發(fā)給Leader服務(wù)器進(jìn)行處理。Observer不會參與任何形式的投票,包括事務(wù)請求Proposal的投票和Leader選舉投票。HBase數(shù)據(jù)庫HBase是建立在HDFS之上，提供高可靠性、高性能、列存儲、可伸縮、實(shí)時(shí)讀寫的數(shù)據(jù)庫系統(tǒng)。它是ApacheHadoop生態(tài)系統(tǒng)中的重要一員，主要用于海量結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)存儲，Hbase的Logo是一只鯨魚，如圖所示。HBase是GoogleBigtable的開源實(shí)現(xiàn)，與GoogleBigtable利用GFS作為其文件存儲系統(tǒng)類似，HBase利用HadoopHDFS作為其文件存儲系統(tǒng)；Google運(yùn)行MapReduce來處理Bigtable中的海量數(shù)據(jù)，HBase同樣利用HadoopMapReduce來處理HBase中的海量數(shù)據(jù)；GoogleBigtable利用Chubby作為協(xié)同服務(wù)，HBase利用Zookeeper作為對應(yīng)。HBase數(shù)據(jù)庫1)Hbase特性特點(diǎn)概述大一個(gè)表可以有上億行，上百萬列。面向列面向列表（簇）的存儲和權(quán)限控制，列（簇）獨(dú)立檢索。稀疏每個(gè)單元中的數(shù)據(jù)可以有多個(gè)版本，默認(rèn)情況下，版本號自動(dòng)分配，版本號就是單元格插入時(shí)的時(shí)間戳。數(shù)據(jù)多版本每個(gè)單元中的數(shù)據(jù)可以有多個(gè)版本，默認(rèn)情況下，版本號自動(dòng)分配，版本號就是單元格插入時(shí)的時(shí)間戳。數(shù)據(jù)類型單一HBase中的數(shù)據(jù)都是字符串，沒有類型。HBase數(shù)據(jù)庫2)Hbase與傳統(tǒng)數(shù)據(jù)庫對比對比傳統(tǒng)數(shù)據(jù)庫可能遇到的問題（1）數(shù)據(jù)量很大的時(shí)候無法存儲。（2）沒有很好的備份機(jī)制。（3）數(shù)據(jù)達(dá)到一定數(shù)量開始緩慢，很大的話基本無法支撐。Hbase的優(yōu)勢（1）線性擴(kuò)展，隨著數(shù)據(jù)量增多可以通過節(jié)點(diǎn)擴(kuò)展進(jìn)行支撐。（2）數(shù)據(jù)存儲在hdfs上，備份機(jī)制健全。（3）通過zookeeper協(xié)調(diào)查找數(shù)據(jù)，訪問速度快。HBase數(shù)據(jù)庫3)zookeeper在HBase中的作用①可以保證在HBase集群中有且只有一個(gè)活躍的Master；②存儲所有Region的尋址入口；③實(shí)時(shí)監(jiān)控Regionserver的上線和下線信息，并實(shí)時(shí)通知給Master；④存儲HBase的schema和Table元數(shù)據(jù)。Region是HBase分布式存儲的最基本單元。它將一個(gè)數(shù)據(jù)表按Key值范圍橫向劃分為一個(gè)個(gè)的子表，實(shí)現(xiàn)分布式存儲。這個(gè)子表，在HBase中被稱作“Region”。每一個(gè)Region都關(guān)聯(lián)一個(gè)Key值范圍，即一個(gè)使用StartKey和EndKey描述的區(qū)間。HBase數(shù)據(jù)庫4)HBase的集群角色HBase的集群角色有兩種分別是HMaster和Regionserver。其中HMaster是主進(jìn)程，負(fù)責(zé)管理所有的Regionserver；Regionserver是數(shù)據(jù)服務(wù)進(jìn)程，負(fù)責(zé)處理用戶數(shù)據(jù)的讀寫請求。HMaster與Regionserver之間有著密切的關(guān)系，而Regionserver又與Region它是HBase中存儲數(shù)據(jù)的最小單元)密不可分，所以我們分別講解Region、Regionserver和HMaster的特點(diǎn)。(1)RegionRegionServer是HBase的數(shù)據(jù)服務(wù)進(jìn)程。它負(fù)責(zé)處理用戶數(shù)據(jù)的讀寫請求，所有的Region都被交由RegionServer管理，包括執(zhí)行Flush、Compaction、Open、Close、Load等操作。實(shí)際上，所有用戶數(shù)據(jù)的讀寫請求，都是和RegionServer管理的Region進(jìn)行交互。當(dāng)某個(gè)RegionServer發(fā)生故障的時(shí)候，此RegionServer所管理Region就會轉(zhuǎn)移到其它RegionServer下。RegionServer需要定期向HMaster匯報(bào)自身的情況，包括內(nèi)存使用狀態(tài)、在線狀態(tài)的Region等信息。RegionServer除此之外，還可以管理WAL，以及執(zhí)行數(shù)據(jù)插入、更新和刪除操作，并通過Metrics對外提供了衡量HBase內(nèi)部服務(wù)狀況的參數(shù)。另外，RegionServer還內(nèi)置了HttpServer，所以我們可以通過圖形界面的方式訪問Hbase。(2)RegionserverHMaster進(jìn)程負(fù)責(zé)管理所有的RegionServer。包括新RegionServer的注冊；RegionServerFailover處理；負(fù)責(zé)建表/修改表/刪除表以及一些集群操作；新表創(chuàng)建時(shí)的Region分配；運(yùn)行期間的負(fù)載均衡保障；負(fù)責(zé)所有Region的轉(zhuǎn)移操作，包括RegionServerFailover后的Region接管。(3)HMasterHBase數(shù)據(jù)庫4)HBase的集群角色HMaster進(jìn)程有主備角色。集群可以配置多個(gè)HMaster角色，在集群啟動(dòng)時(shí)，這些HMaster角色通過競爭獲得主HMaster角色。主HMaster只能有一個(gè)，所有的備HMaster進(jìn)程在集群運(yùn)行期間處于休眠狀態(tài)，不干涉任何集群事務(wù)。為了方便理解HMaster、RegionServer和Region三者之間的關(guān)系，舉一個(gè)很形象的例子,你可以把HMaster理解為部門總經(jīng)理，它管理了若干個(gè)項(xiàng)目經(jīng)理(RegionServer),而每個(gè)項(xiàng)目經(jīng)理都帶了若干個(gè)項(xiàng)目組成員(Region)。HBase有自己獨(dú)特的一套文件存儲架構(gòu)和數(shù)據(jù)尋址機(jī)制,來保證在海量數(shù)據(jù)中快速檢索到需要的數(shù)據(jù),有興趣的同學(xué)可以前往HBase官網(wǎng)(/)進(jìn)行學(xué)習(xí)。Hive系統(tǒng)Hive是基于Hadoop構(gòu)建的一套數(shù)據(jù)倉庫分析系統(tǒng)，它提供了豐富的SQL查詢方式來分析存儲在Hadoop分布式文件系統(tǒng)（HDFS）中的數(shù)據(jù)：可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射為一張數(shù)據(jù)庫表，并提供完整的SQL查詢功能；可以將SQL語句轉(zhuǎn)換為MapReduce任務(wù)運(yùn)行，通過自己的SQL查詢分析需要的內(nèi)容，這套SQL簡稱HiveSQL，使不熟悉mapreduce的用戶可以很方便地利用SQL語言查詢、匯總和分析數(shù)據(jù)。而mapreduce開發(fā)人員可以把自己寫的mapper和reducer作為插件來支持hive做更復(fù)雜的數(shù)據(jù)分析。它與關(guān)系型數(shù)據(jù)庫的SQL略有不同，但支持了絕大多數(shù)的語句如DDL、DML以及常見的聚合函數(shù)、連接查詢、條件查詢。它還提供了一系列的工具進(jìn)行數(shù)據(jù)提取轉(zhuǎn)化加載，用來存儲、查詢和分析存儲在Hadoop中的大規(guī)模數(shù)據(jù)集，并支持UDF（User-DefinedFunction）、UDAF(User-DefnesAggregateFunction)和UDTF（User-DefinedTable-GeneratingFunction），也可以實(shí)現(xiàn)對map和reduce函數(shù)的定制，為數(shù)據(jù)操作提供了良好的伸縮性和可擴(kuò)展性。Hive系統(tǒng)1)什么是數(shù)據(jù)倉庫數(shù)據(jù)倉庫，英文名稱為DataWarehouse，可簡寫為DW或DWH。數(shù)據(jù)倉庫的目的是構(gòu)建面向分析的集成化數(shù)據(jù)環(huán)境，為企業(yè)提供決策支持（DecisionSupport）。它出于分析性報(bào)告和決策支持目的而創(chuàng)建。數(shù)據(jù)倉庫本身并不“生產(chǎn)”任何數(shù)據(jù)，同時(shí)自身也不需要“消費(fèi)”任何的數(shù)據(jù)，數(shù)據(jù)來源于外部，并且開放給外部應(yīng)用，這也是為什么叫“倉庫”，而不叫“工廠”的原因。數(shù)據(jù)倉庫有四個(gè)特性：分別是主體性、集成性、非易失性（不可更新性）和時(shí)變性。Hive系統(tǒng)2)數(shù)據(jù)倉庫與數(shù)據(jù)庫的區(qū)別數(shù)據(jù)庫與數(shù)據(jù)倉庫的區(qū)別實(shí)際講的是OLTP與OLAP的區(qū)別，見表所示。處理方式概述OLTP聯(lián)機(jī)事務(wù)處理，也可以稱面向交易的處理系統(tǒng)，它是針對具體業(yè)務(wù)在數(shù)據(jù)庫聯(lián)機(jī)的日常操作，通常對少數(shù)記錄進(jìn)行查詢、修改。用戶較為關(guān)心操作的響應(yīng)時(shí)間、數(shù)據(jù)的安全性、完整性和并發(fā)支持的用戶數(shù)等問題。傳統(tǒng)的數(shù)據(jù)庫系統(tǒng)作為數(shù)據(jù)管理的主要手段，主要用于操作型處理。OLAP聯(lián)機(jī)分析處理，一般針對某些主題的歷史數(shù)據(jù)進(jìn)行分析，支持管理決策。數(shù)據(jù)倉庫的出現(xiàn)，并不是要取代數(shù)據(jù)庫，兩者之間的區(qū)別如下表所示。差異數(shù)據(jù)庫數(shù)據(jù)倉庫面向方向面向事務(wù)面向主題數(shù)據(jù)存儲存儲業(yè)務(wù)數(shù)據(jù)存儲歷史數(shù)據(jù)表設(shè)計(jì)盡量避免冗余有意引入冗余，依照分析需求，分析維度、分析指標(biāo)進(jìn)行設(shè)計(jì)作用方向?yàn)椴东@數(shù)據(jù)而設(shè)計(jì)為分析數(shù)據(jù)而設(shè)計(jì)Hive系統(tǒng)以銀行業(yè)務(wù)為例。數(shù)據(jù)庫是事務(wù)系統(tǒng)的數(shù)據(jù)平臺，客戶在銀行做的每筆交易都會寫入數(shù)據(jù)庫，被記錄下來，這里，可以簡單地理解為用數(shù)據(jù)庫記賬。數(shù)據(jù)倉庫是分析系統(tǒng)的數(shù)據(jù)平臺，它從事務(wù)系統(tǒng)獲取數(shù)據(jù)，并做匯總、加工，為決策者提供決策的依據(jù)。比如，某銀行某分行一個(gè)月發(fā)生多少交易，該分行當(dāng)前存款余額是多少。如果存款又多，消費(fèi)交易又多，那么該地區(qū)就有必要設(shè)立ATM了。顯然，銀行的交易量是巨大的，通常以百萬甚至千萬次來計(jì)算。事務(wù)系統(tǒng)是實(shí)時(shí)的，這就要求時(shí)效性，客戶存一筆錢需要幾十秒是無法忍受的，這就要求數(shù)據(jù)庫只能存儲很短一段時(shí)間的數(shù)據(jù)。而分析系統(tǒng)是事后的，它要提供關(guān)注時(shí)間段內(nèi)所有的有效數(shù)據(jù)。這些數(shù)據(jù)是海量的，匯總計(jì)算起來也要慢一些，但是，只要能夠提供有效的分析數(shù)據(jù)就達(dá)到目的了。數(shù)據(jù)倉庫，是在數(shù)據(jù)庫已經(jīng)大量存在的情況下，為了進(jìn)一步挖掘數(shù)據(jù)資源、為了決策需要而產(chǎn)生的，它決不是所謂的“大型數(shù)據(jù)庫”。Hive系統(tǒng)3)Hive的作用MapReduce使用起來學(xué)習(xí)難度大，成本高，坡度陡，并且MapReduce實(shí)現(xiàn)復(fù)雜查詢邏輯開發(fā)難度較大。而Hive可以把SQL語句轉(zhuǎn)化成Mapreduce代碼，操作接口內(nèi)SQL語法，提升開發(fā)的效率；避免了去寫MapReduce，降低開發(fā)人員的學(xué)習(xí)成本；較強(qiáng)的擴(kuò)展性，Hive支持用戶自定義函數(shù)，用戶可以根據(jù)自己的需求來實(shí)現(xiàn)自己的函數(shù)；良好的容錯(cuò)性，節(jié)點(diǎn)出現(xiàn)問題SQL仍可完成執(zhí)行。關(guān)于Hive的使用方式與數(shù)據(jù)類型，會在第4章中詳細(xì)講解。Flume軟件Flume是Cloudera提供的一個(gè)高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸?shù)能浖lume的核心是把數(shù)據(jù)從數(shù)據(jù)源(source)收集過來，再將收集到的數(shù)據(jù)送到指定的目的地(sink)。為了保證輸送的過程一定成功，在送到目的地(sink)之前，會先緩存數(shù)據(jù)(channel)，待數(shù)據(jù)真正到達(dá)目的地(sink)后，F(xiàn)lume在刪除自己緩存的數(shù)據(jù)。Flume支持定制各類數(shù)據(jù)發(fā)送方，用于收集各類型數(shù)據(jù)；同時(shí)，F(xiàn)lume支持定制各種數(shù)據(jù)接受方，用于最終存儲數(shù)據(jù)。一般的采集需求，通過對Flume的簡單配置即可實(shí)現(xiàn)。針對特殊場景也具備良好的自定義擴(kuò)展能力。因此，F(xiàn)lume可以適用于大部分的日常數(shù)據(jù)采集場景。Flume軟件Flume系統(tǒng)中核心的角色是Agent，Agent本身是一個(gè)Java進(jìn)程，一般運(yùn)行在日志收集節(jié)點(diǎn)，執(zhí)行流程如圖所示。每一個(gè)Agent相當(dāng)于一個(gè)數(shù)據(jù)傳遞員，內(nèi)部有三個(gè)組件：Source：采集源，用于跟數(shù)據(jù)源對接，以獲取數(shù)據(jù)。Sink：下沉地，采集數(shù)據(jù)的傳送目的地，用于往下一級Agent傳遞數(shù)據(jù)或者往最終存儲系統(tǒng)傳遞數(shù)據(jù)。Channel：Agent內(nèi)部的數(shù)據(jù)傳輸通道，用于從source將數(shù)據(jù)傳遞到sink；在整個(gè)數(shù)據(jù)的傳輸?shù)倪^程中，流動(dòng)的是Event，它是Flume內(nèi)部數(shù)據(jù)傳輸?shù)淖罨締卧?。Event將傳輸?shù)臄?shù)據(jù)進(jìn)行封裝。如果是文本文件，通常是一行記錄，Event也是事務(wù)的基本單位。Event從Source，流向Channel，再到Sink，本身為一個(gè)字節(jié)數(shù)組，并可攜帶headers(頭信息)信息。Event代表著一個(gè)數(shù)據(jù)的最小完整單元，從外部數(shù)據(jù)源來，向外部的目的地去。一個(gè)完整的Event包括：Eventheaders、Eventbody、Event信息，其中Event信息就是Flume收集到的日記記錄。kafka系統(tǒng)1)kafka的概念A(yù)pacheKafka是一個(gè)開源消息系統(tǒng)，由Scala語言編寫，以可水平擴(kuò)展和高吞吐率而被廣泛使用。Kafka最初是由Linkedin公司開發(fā)，是一個(gè)分布式、分區(qū)的、多副本的、多訂閱者，基于Zookeeper協(xié)調(diào)的分布式消息系統(tǒng)，Linkedin于2010年貢獻(xiàn)給了Apache基金會并成為頂級開源項(xiàng)目，KafkaLogo如圖所示。Kafka官網(wǎng)地址為：/kafka系統(tǒng)2)

Kafka的特性特性概述高吞吐量、低延遲kafka每秒可以處理幾十萬條消息，它的延遲最低只有幾毫秒，每個(gè)topic可以分多個(gè)partition，consumergroup對partition進(jìn)行consume操作。可擴(kuò)展性Kafka集群支持熱擴(kuò)展。持久性、可靠性消息被持久化到本地磁盤，并且支持?jǐn)?shù)據(jù)備份防止數(shù)據(jù)丟失。容錯(cuò)性允許集群中節(jié)點(diǎn)失?。ㄈ舾北緮?shù)量為n，則允許n-1個(gè)節(jié)點(diǎn)失?。８卟l(fā)支持?jǐn)?shù)千個(gè)客戶端同時(shí)讀寫。kafka系統(tǒng)2)

Kafka的特性kafka中的相關(guān)組件如下(1)服務(wù)器節(jié)點(diǎn)(Broker)0102(2)主題(Topic)Kafka集群包含一個(gè)或多個(gè)服務(wù)器，服務(wù)器節(jié)點(diǎn)稱為Broker。Broker存儲Topic的數(shù)據(jù)。如果某Topic有N個(gè)Partition，集群有N個(gè)Broker，那么每個(gè)Broker存儲該Topic的一個(gè)Partition。如果某Topic有N個(gè)Partition，集群有(N+M)個(gè)Broker，那么其中有N個(gè)Broker存儲該Topic的一個(gè)Partition，剩下的M個(gè)Broker不存儲該Topic的Partition數(shù)據(jù)。如果某Topic有N個(gè)Partition，集群中Broker數(shù)目少于N個(gè)，那么一個(gè)Broker存儲該Topic的一個(gè)或多個(gè)Partition。在實(shí)際生產(chǎn)環(huán)境中，盡量避免這種情況的發(fā)生，這種情況容易導(dǎo)致Kafka集群數(shù)據(jù)不均衡。每條發(fā)布到Kafka集群的消息都有一個(gè)類別，這個(gè)類別被稱為Topic。（物理上不同Topic的消息分開存儲，邏輯上一個(gè)Topic的消息雖然保存于一個(gè)或多個(gè)broker上但用戶只需指定消息的Topic即可生產(chǎn)或消費(fèi)數(shù)據(jù)而不必關(guān)心數(shù)據(jù)存于何處）類似于數(shù)據(jù)庫的表名。kafka系統(tǒng)2)

Kafka的特性kafka中的相關(guān)組件如下(3)分區(qū)(Partition)0304(4)生產(chǎn)者(Producer)Topic中的數(shù)據(jù)分割為一個(gè)或多個(gè)Partition。每個(gè)Topic至少有一個(gè)Partition。每個(gè)Partition中的數(shù)據(jù)使用多個(gè)Segment文件存儲。Partition中的數(shù)據(jù)是有序的，不同Partition間的數(shù)據(jù)丟失了數(shù)據(jù)的順序。如果Topic有多個(gè)Partition，消費(fèi)數(shù)據(jù)時(shí)就不能保證數(shù)據(jù)的順序。在需要嚴(yán)格保證消息的消費(fèi)順序的場景下，需要將Partition數(shù)目設(shè)為1。生產(chǎn)者即數(shù)據(jù)的發(fā)布者，該角色將消息發(fā)布到Kafka的Topic中。Broker接收到生產(chǎn)者發(fā)送的消息后，Broker將該消息追加到當(dāng)前用于追加數(shù)據(jù)的Segment文件中。生產(chǎn)者發(fā)送的消息，存儲到一個(gè)Partition中，生產(chǎn)者也可以指定數(shù)據(jù)存儲的Partition。kafka系統(tǒng)2)

Kafka的特性kafka中的相關(guān)組件如下(5)消費(fèi)者(Consumer)0304(6)消費(fèi)者群ConsumerGroup)消費(fèi)者可以從Broker中讀取數(shù)據(jù)。消費(fèi)者可以消費(fèi)多個(gè)Topic中的數(shù)據(jù)。每個(gè)Consumer屬于一個(gè)特定的ConsumerGroup（可為每個(gè)Consumer指定GroupName，若不指定GroupName則屬于默認(rèn)的Group）。kafka系統(tǒng)3)Kafka與RabbitMQ的區(qū)別區(qū)別Kafka傳統(tǒng)消息隊(duì)列架構(gòu)模型Kafka遵從一般的MQ結(jié)構(gòu)，Producer，Broker，Consumer，以Consumer為中心，消息的消費(fèi)信息保存的客戶端Consumer上，Consumer根據(jù)消費(fèi)的點(diǎn)，從Broker上批量Pull數(shù)據(jù)；無消息確認(rèn)機(jī)制。Rabbitmq遵循AMQP協(xié)議，Rabbitmq的Brokerexchange，Binding，Queue組成，其中Exchange和Binding組成了消息的路由鍵；客戶端Producer通過連接Channel和Server進(jìn)行通信，Consumer從Queue獲取消息進(jìn)行消費(fèi)（長連接，Queue有消息會推送到Consumer端，Consumer循環(huán)從輸入流讀取數(shù)據(jù)）。Rabbitmq以Broker為中心；有消息的確認(rèn)機(jī)制。吞吐量方面Kafka具有高的吞吐量，內(nèi)部采用消息的批量處理，zero-copy機(jī)制，數(shù)據(jù)的存儲和獲取是本地磁盤順序批量操作，具有O(1)的復(fù)雜度，消息處理的效率很高。RabbitMQ在吞吐量方面稍遜于kafka，他們的出發(fā)點(diǎn)不一樣，rabbitMQ支持對消息的可靠的傳遞，支持事務(wù)，不支持批量的操作；基于存儲的可靠性的要求存儲可以采用內(nèi)存或者硬盤?？捎眯苑矫鍷afka的broker支持主備模式。Rabbitmq支持Miror的Queue，主Queue失效，MirorQueue接管。集群負(fù)載均衡Kafka采用Zookeeper對集群中的Broker、Consumer進(jìn)行管理，可以注冊Topic到Zookeeper上；通過Zookeeper的協(xié)調(diào)機(jī)制，Producer保存對應(yīng)Topic的Broker信息，可以隨機(jī)或者輪詢發(fā)送到Broker上；并且Producer可以基于語義指定分片，消息發(fā)送到Broker的某分片上。Rabbitmq支持集群模式，但不支持負(fù)載均衡。SqoopSqoop(SQL-to-Hadoop)項(xiàng)目旨在協(xié)助RDBMS與Hadoop之間進(jìn)行高效的大數(shù)據(jù)交流，是一款基于MapReduce的數(shù)據(jù)遷移工具，同時(shí)也是一款開源的工具。它主要用在Hadoop(Hive)與非關(guān)系型數(shù)據(jù)庫(NoSQL、HBase等)間進(jìn)行數(shù)據(jù)的傳遞，可以將一個(gè)關(guān)系型數(shù)據(jù)庫(MySQL，Oracle，PostgreSQL等)中的數(shù)據(jù)導(dǎo)人Hadoop的HDFS中，也可以將HDFS的數(shù)據(jù)導(dǎo)人關(guān)系型數(shù)據(jù)庫中。隨著聯(lián)網(wǎng)的普及，企業(yè)積累的數(shù)據(jù)量越來越大，傳統(tǒng)的數(shù)據(jù)庫已經(jīng)無法滿足存儲需求，所以更多的用戶選擇使用Hadoop的HDFS來存儲數(shù)據(jù)。那么就需要將數(shù)據(jù)在傳統(tǒng)數(shù)據(jù)庫與HDFS之間進(jìn)行轉(zhuǎn)移能夠幫助數(shù)據(jù)傳輸?shù)墓ぞ咦兊酶又匾?。ApacheSqoop就是這樣一款開源工具，可以在Hadoop和關(guān)系型數(shù)據(jù)庫之間轉(zhuǎn)移大量數(shù)據(jù)。Sqoop項(xiàng)目開始于2009年，最早是作為Hadop的一個(gè)第三方模塊存在，后來為了讓使用者能夠快速部署，也為了讓開發(fā)人員能夠更快速地送代開發(fā),Sqoop獨(dú)立成為一個(gè)Apache項(xiàng)目。Sqoop本質(zhì)其實(shí)是將導(dǎo)入或?qū)С雒罘g成MapReduce程序并執(zhí)行。在翻譯成MapReduce程序中主要是對InputFormat和OutputFormat進(jìn)行定制。隨著Sqoop的使用者越來越多，舊版本的Sqoop已經(jīng)漸漸暴露出一些缺點(diǎn)，開發(fā)人員優(yōu)化之后推出了一個(gè)新的系列版本Sqoop2。Sqoop1與Sqoop2是兩個(gè)完全不同的版本，它們并不兼容。Sqoopl通常是指1.4.x版本，Sqoop2是指1.99.x以后的版本。1)Sqoop的概念Sqoop(1)引入sqoopserver，集中化管理connector等。(2)多種訪問方式：CLI，WebUI，RESTAPI。(3)引入基于角色的安全機(jī)制。Sqoop2和Sqoop1的功能性對比，如下表所示：2）Sqoop2比sqoop1的改進(jìn)：功能Sqoop1Sqoop2用于所有主要RDBMS的連接器支持不支持解決辦法：使用已在以下數(shù)據(jù)庫上執(zhí)行測試的通用JDBC連接器：MicrosoftSQLServer、PostgreSQL、MySQL和Oracle。此連接器應(yīng)在任何其它符合JDBC要求的數(shù)據(jù)庫上運(yùn)行。但是，性能可能無法與Sqoop中的專用連接器相比。Kerberos安全集成支持不支持?jǐn)?shù)據(jù)從RDBMS傳輸至Hive或HBase支持不支持解決辦法：按照此兩步方法操作。將數(shù)據(jù)從RDBMS導(dǎo)入HDFS在Hive中使用相應(yīng)的工具和命令（例如LOADDATA語句），手動(dòng)將數(shù)據(jù)載入Hive或Hbase。數(shù)據(jù)從Hive或HBase傳輸至RDBMS不支持解決辦法：按照此兩步方法操作。從Hive或HBase將數(shù)據(jù)提取至HDFS使用Sqoop將上一步的輸出導(dǎo)出至RDBMS。不支持按照與Sqoop1相同的解決方法操作。Spark核心技術(shù)Spark核心技術(shù)ApacheSpark是一個(gè)具有高效、易用通用兼容性特點(diǎn)的計(jì)算框架，它是基于大數(shù)據(jù)的基礎(chǔ)，也被稱為大數(shù)據(jù)分析引擎(Spak管網(wǎng)為/)。進(jìn)人Spark官網(wǎng)，首先映人眼簾的就是一個(gè)大Logo和一段英文描述:Lightning-fastunifiedanalyticsengine(閃電般的統(tǒng)一分析引擎)，由此,Spark的處理效率可見一斑。Spark誕生于加州伯克利分校的AMP實(shí)驗(yàn)室,項(xiàng)目采用Scala語言編寫2009年2013年6月2016年2010年2014年進(jìn)入Apache孵化器Spark2.0版本發(fā)布Spark正式對外開源成為Apache頂級項(xiàng)目……..目前，最新版本3.0+Spark核心技術(shù)目前Spark生態(tài)系統(tǒng)已經(jīng)發(fā)展成為一個(gè)包含多個(gè)予項(xiàng)目的集合，其中包含SparkCore、SparkSQL、SparkStreaming、GraphX、MLlib等子項(xiàng)目。Spark的主要特性如下所示。與Hadoop的MapReduce相比，Spark基于內(nèi)存的運(yùn)算要快100倍以上，基于硬盤的運(yùn)算也要快10倍以上。Spark實(shí)現(xiàn)了高效的DAG(有向無環(huán)圖)執(zhí)行引擎，可以通過基于內(nèi)存來高效處理數(shù)據(jù)流。速度快Spark支持Java、Python和Scala的API，還支持超過80種高級算法，使用戶可以快速構(gòu)建不同的應(yīng)用。而且Spark支持交互式的Python和Scala的Shell，可以非常方便地在這些shell中使用Spark集群來驗(yàn)證解決問題的方法。易用性Spark核心技術(shù)目前Spark生態(tài)系統(tǒng)已經(jīng)發(fā)展成為一個(gè)包含多個(gè)予項(xiàng)目的集合，其中包含SparkCore、SparkSQL、SparkStreaming、GraphX、MLlib等子項(xiàng)目。Spark的主要特性如下所示。Spark提供了統(tǒng)一的解決方案。Spark可以用于批處理、交互式查詢（SparkSQL）、實(shí)時(shí)流處理（SparkStreaming）、機(jī)器學(xué)習(xí)（SparkMLlib）和圖計(jì)算（GraphX）。這些不同類型的處理都可以在同一個(gè)應(yīng)用中無縫使用。Spark統(tǒng)一的解決方案非常具有吸引力，畢竟任何公司都想用統(tǒng)一的平臺去處理遇到的問題，減少開發(fā)和維護(hù)的人力成本和部署平臺的物力成本。通用性Spark可以非常方便地與其他的開源產(chǎn)品進(jìn)行融合。比如，Spark可以使用Hadoop的YARN和ApacheMesos作為它的資源管理和調(diào)度器，并且可以處理所有Hadoop支持的數(shù)據(jù)，包括HDFS、HBase和Cassandra等。這對于已經(jīng)部署Hadoop集群的用戶特別重要，因?yàn)椴恍枰鋈魏螖?shù)據(jù)遷移就可以使用Spark的強(qiáng)大處理能力。Spark也可以不依賴于第三方的資源管理和調(diào)度器，它實(shí)現(xiàn)了Standalone作為其內(nèi)置的資源管理和調(diào)度框架，這樣進(jìn)一步降低了Spark的使用門檻，使得所有人都可以非常容易地部署和使用Spark。兼容性Spark核心技術(shù)Spark已經(jīng)得到了眾多大數(shù)據(jù)公司的支持，這些公司包括Hortonworks、IBM、Intel、Cloudera、MapR、Pivotal、百度、阿里、騰訊、京東、攜程、優(yōu)酷土豆等。當(dāng)前百度的Spark已應(yīng)用于鳳巢、大搜索、直達(dá)號、百度大數(shù)據(jù)等業(yè)務(wù)；阿里利用GraphX構(gòu)建了大規(guī)模的圖計(jì)算和圖挖掘系統(tǒng)，實(shí)現(xiàn)了很多生產(chǎn)系統(tǒng)的推薦算法；騰訊Spark集群達(dá)到8000臺的規(guī)模，是當(dāng)前已知的世界上最大的Spark集群。SparkCoreSparkCore是Spark分布式運(yùn)算的核心，Spark的其他組件均依賴于SparkCore。在Hadoop的MapReduce中，Shuffle過程會頻繁將內(nèi)存中保存的中間計(jì)算結(jié)果數(shù)據(jù)“溢寫”到磁盤中，從而引發(fā)大量的磁盤IO，導(dǎo)致處理數(shù)據(jù)的效率大幅度下降。而Spark中有一個(gè)基于內(nèi)存緩存的“集合”概念，可以解決類似問題，并且允許在內(nèi)存不足的情況下，將這個(gè)集合的數(shù)據(jù)溢寫到磁盤中。即：數(shù)據(jù)有限存儲在內(nèi)存中，如果內(nèi)存空間不足，再將數(shù)據(jù)溢寫到磁盤中，這種行為引申出一個(gè)概念——“Resilient（彈性的）”。Spark的研發(fā)目標(biāo)是解決大數(shù)據(jù)量的數(shù)據(jù)分析問題，那么數(shù)據(jù)一定是分布式存儲的，因此引入分布式概念——“Distributed（分布式）”。在Spark中，如果想要方便的處理數(shù)據(jù)，那么Spark也需要引入集合的概念——“DataSet（數(shù)據(jù)集）”。綜上所述，Spark引入了一個(gè)彈性的、分布式的數(shù)據(jù)集——RDD（ResilientDistributedDataset）。RDD是一種具有容錯(cuò)性、基于內(nèi)存計(jì)算的抽象方法，RDD是SparkCore的底層核心，Spark則是這個(gè)抽象方法的實(shí)現(xiàn)。SparkCore數(shù)據(jù)有限存儲在內(nèi)存中，如果內(nèi)存空間不足，再將數(shù)據(jù)溢寫到磁盤中，這種行為引申出一個(gè)概念——“Resilient（彈性的）”。Spark的研發(fā)目標(biāo)是解決大數(shù)據(jù)量的數(shù)據(jù)分析問題，那么數(shù)據(jù)一定是分布式存儲的，因此引入分布式概念——“Distributed（分布式）”。在Spark中，如果想要方便的處理數(shù)據(jù)，那么Spark也需要引入集合的概念——“DataSet（數(shù)據(jù)集）”。綜上所述，Spark引入了一個(gè)彈性的、分布式的數(shù)據(jù)集——RDD（ResilientDistributedDataset）。RDD是一種具有容錯(cuò)性、基于內(nèi)存計(jì)算的抽象方法，RDD是SparkCore的底層核心，Spark則是這個(gè)抽象方法的實(shí)現(xiàn)。SparkCore是Spark分布式運(yùn)算的核心，Spark的其他組件均依賴于SparkCore。在Hadoop的MapReduce中，Shuffle過程會頻繁將內(nèi)存中保存的中間計(jì)算結(jié)果數(shù)據(jù)“溢寫”到磁盤中，從而引發(fā)大量的磁盤IO，導(dǎo)致處理數(shù)據(jù)的效率大幅度下降。而Spark中有一個(gè)基于內(nèi)存緩存的“集合”概念，可以解決類似問題，并且允許在內(nèi)存不足的情況下，將這個(gè)集合的數(shù)據(jù)溢寫到磁盤中。SparkCore1)RDDRDD（ResilientDistributedDataset）叫做彈性分布式數(shù)據(jù)集，是Spark中最基本的數(shù)據(jù)抽象，它代表一個(gè)不可變、可分區(qū)、里面的元素可并行計(jì)算的集合。RDD具有數(shù)據(jù)流模型的特點(diǎn)：自動(dòng)容錯(cuò)、位置感知性調(diào)度和可伸縮性。RDD允許用戶在執(zhí)行多個(gè)查詢時(shí)顯式地將數(shù)據(jù)緩存在內(nèi)存中，后續(xù)的查詢能夠重用這些數(shù)據(jù)，這極大地提升了查詢速度。一個(gè)RDD就是一個(gè)分布式對象集合，本質(zhì)上是一個(gè)只讀的分區(qū)記錄集合，每個(gè)RDD可以分成多個(gè)分區(qū)，每個(gè)分區(qū)就是一個(gè)數(shù)據(jù)集片段。并且一個(gè)RDD的不同分區(qū)可以被保存到集群中不同的節(jié)點(diǎn)上，從而可以在集群中的不同節(jié)點(diǎn)進(jìn)行并行計(jì)算。SparkCore2)RDD的特性（1）Alistofpartitions一個(gè)分區(qū)（Partition）列表，數(shù)據(jù)集的基本組成單位。SparkRDD是被分區(qū)的，每一個(gè)分區(qū)都會被一個(gè)計(jì)算任務(wù)(Task)處理，分區(qū)數(shù)決定了并行計(jì)算的數(shù)量，RDD的并行度默認(rèn)從父RDD傳給子RDD。默認(rèn)情況下，一個(gè)HDFS上的數(shù)據(jù)分片就是一個(gè)partiton，RDD分片數(shù)決定了并行計(jì)算的力度，可以在創(chuàng)建RDD時(shí)指定RDD分片個(gè)數(shù)（分區(qū)）。如果不指定分區(qū)數(shù)量，當(dāng)RDD從集合創(chuàng)建時(shí)，則默認(rèn)分區(qū)數(shù)量為該程序所分配到的資源的CPU核數(shù)(每個(gè)Core可以承載2~4個(gè)partition)，如果是從HDFS文件創(chuàng)建，默認(rèn)為文件的Block數(shù)。（2）Afunctionforcomputingeachsplit一個(gè)計(jì)算每個(gè)分區(qū)的函數(shù)。每個(gè)分區(qū)都會有計(jì)算函數(shù)，Spark的RDD的計(jì)算函數(shù)是以分片為基本單位的，每個(gè)RDD都會實(shí)現(xiàn)compute函數(shù)，對具體的分片進(jìn)行計(jì)算，RDD中的分片是并行的，所以是分布式并行計(jì)算。SparkCore2)RDD的特性(3）AlistofdependenciesonotherRDDs依賴于其他RDD的列表，一個(gè)RDD會依賴于其他多個(gè)RDD。由于RDD每次轉(zhuǎn)換都會生成新的RDD，所以RDD會形成類似流水線一樣的前后依賴關(guān)系。(4）APartitionerforkey-valueRDDskey-value數(shù)據(jù)類型的RDD分區(qū)器，用于控制分區(qū)策略和分區(qū)數(shù)。(5)Alistofpreferredlocationstocomputeeachspliton每個(gè)分區(qū)都有一個(gè)優(yōu)先位置列表。對于一個(gè)HDFS文件來說，這個(gè)列表保存的就是每個(gè)Partition所在的塊的位置。按照“移動(dòng)數(shù)據(jù)不如移動(dòng)計(jì)算”的理念，Spark在進(jìn)行任務(wù)調(diào)度的時(shí)候，會盡可能地將計(jì)算任務(wù)分配到其所要處理數(shù)據(jù)塊的存儲位置（Spark進(jìn)行任務(wù)分配的時(shí)候盡可能選擇那些存有數(shù)據(jù)的worker節(jié)點(diǎn)來進(jìn)行任務(wù)計(jì)算）。SparkCore3)RDD的緩存機(jī)制在默認(rèn)情況下，RDD是駐留在內(nèi)存中的。但是內(nèi)存始終有限制，當(dāng)內(nèi)存到達(dá)一定的限制以后，此時(shí)如果還需要生成新的RDD，那么Spark將會移除內(nèi)存中長時(shí)間不使用的RDD，以便存放新生成的RDD。當(dāng)需要再次使用移除的RDD的時(shí)候，就需要重新計(jì)算得到。而RDD緩存（也叫RDD持久化）就避免了這樣的重復(fù)運(yùn)算，對性能提升明顯，這就是為什么把Spark成為內(nèi)存計(jì)算框架的原因。緩存RDD可以通過persist和cache來實(shí)現(xiàn)，從本質(zhì)上來講，cache內(nèi)部依賴persist方法。SparkCore4)RDD的容錯(cuò)機(jī)制Spark在生產(chǎn)環(huán)境下經(jīng)常會面臨Transformation的RDD非常多(例如一個(gè)Job中包含1萬個(gè)RDD)或者是具體的Transformation產(chǎn)生的RDD本身計(jì)算特別復(fù)雜和耗時(shí)(例如計(jì)算時(shí)常超過1個(gè)小時(shí))，這個(gè)時(shí)候如果可以對計(jì)算的過程進(jìn)行復(fù)用，就可以極大的提升效率，此時(shí)我們必需考慮對計(jì)算結(jié)果的持久化。如果采用緩存的方式把數(shù)據(jù)持久化在內(nèi)存中的話，雖然最快速但是也是最不可靠的（內(nèi)存清理）；如果放在磁盤上也不是完全可靠的，例如磁盤會損壞，系統(tǒng)管理員可能會清空磁盤。Checkpoint的產(chǎn)生就是為了相對而言更加可靠的持久化數(shù)據(jù)，在Checkpoint可以指定把數(shù)據(jù)放在本地并且是多副本的方式，在正常生產(chǎn)環(huán)境下通常放在HDFS上，借助HDFS高可靠的特征來實(shí)現(xiàn)更可靠的數(shù)據(jù)持久化，來提升數(shù)據(jù)容錯(cuò)。SparkSQLSparkSQL是ApacheSpark核心組件之一，使用DataFrame和DataSet對RDD進(jìn)行封裝，允許開發(fā)者利用類SQL語法快速處理結(jié)構(gòu)化數(shù)據(jù)。SparkSQL特性SparkSQL是ApacheSpark核心組件之一，使用DataFrame和DataSet對RDD進(jìn)行封裝，允許開發(fā)者利用類SQL語法快速處理結(jié)構(gòu)化數(shù)據(jù)。集成性SparkSQL可以無縫地將SQL查詢與Spark序混合在一起,SparkSQL允許使用SQL或熟悉的DataFrameAPI在Spark序中查詢結(jié)構(gòu)化數(shù)據(jù)。適用于Java、ScalaPython和R語言。01統(tǒng)一的數(shù)據(jù)訪問SparkSQL可以以相同的方式連接到任何數(shù)據(jù)源，DataFrames和SQL提供了訪問各種數(shù)據(jù)源的通用方法，包括Hive、Avro、Parquet、ORC、JSON和JDBC。甚至可以跨這些數(shù)據(jù)源連接數(shù)據(jù)。02兼容HiveSparkSQL可以在現(xiàn)有倉庫上運(yùn)行SQL或HiveQL查詢，SparkSQL支持HiveQL語法以及HiveSerDes和udf，允許您訪問現(xiàn)有的Hive倉庫。03標(biāo)準(zhǔn)數(shù)據(jù)連接可以通過JDBC或ODBC連接，服務(wù)器模式為商業(yè)智能工具提供了行業(yè)標(biāo)準(zhǔn)的JDBC和ODBC連接。04SparkSQLSparkSOL是用于結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)處理的Spark高級模塊，可用于從各種結(jié)構(gòu)化數(shù)據(jù)源，例如JISON(半結(jié)構(gòu)化)文件、CSV文件、ORC文件(ORC文件格式是一種Hive的文件存儲格式，可以提高Hive表的讀、寫以及處理數(shù)據(jù)的性能)、Hive表、Parquest文件(新型列式存儲格式，具有降低查詢成本、高效壓縮等優(yōu)點(diǎn)，廣泛用于大數(shù)據(jù)存儲、分析領(lǐng)域)中讀取數(shù)據(jù)，然后在Spark程序內(nèi)通過SQL語句對數(shù)據(jù)進(jìn)行交互式查詢，進(jìn)而實(shí)現(xiàn)數(shù)據(jù)分析需求，也可通過標(biāo)準(zhǔn)數(shù)據(jù)庫連接器(JDBC/ODBC)連接傳統(tǒng)關(guān)系型數(shù)據(jù)庫，取出并轉(zhuǎn)化關(guān)系數(shù)據(jù)庫表，利用SparkSQL進(jìn)行數(shù)據(jù)分析。結(jié)構(gòu)化數(shù)據(jù)是指記錄內(nèi)容具有明確的結(jié)構(gòu)信息且數(shù)據(jù)集內(nèi)的每一條記錄都符合結(jié)構(gòu)規(guī)范的數(shù)據(jù)集合，是由二維表結(jié)構(gòu)來邏輯表達(dá)和實(shí)現(xiàn)的數(shù)據(jù)集合?？梢灶惐葌鹘y(tǒng)數(shù)據(jù)庫表來現(xiàn)解該定義，所謂的“明確結(jié)構(gòu)”即是由預(yù)定義的表頭(Schema)表示的每一條記錄由哪些字段組成以及各個(gè)字段的名稱、類型、屬性等信息。SparkSQL(1)SparkSQL的產(chǎn)生在早期的Hadoop的生態(tài)系統(tǒng)中，處理數(shù)據(jù)只能使用Hadoop的MapReduce組件。為了給熟悉RDBMS但是又不理解MapReduce的技術(shù)人員提供快速上手的工具，Hive應(yīng)運(yùn)而生。Hive的出現(xiàn)，大大降低了分布式開發(fā)的門檻，同時(shí)也在很大程度上提升了開發(fā)效率。Hive允許開發(fā)者使用類SQL語法來處理結(jié)構(gòu)化數(shù)據(jù)，該語法簡稱：HQL。Hive是當(dāng)時(shí)唯一一個(gè)運(yùn)行在Hadoop上的SQL-on-Hadoop的工具，Hive將HQL語言翻譯為MapReduce代碼，并通過Yarn來調(diào)度任務(wù)資源，以處理數(shù)據(jù)分析任務(wù)。由于Hive高度依賴MapReduce，所以它只能處理離線任務(wù)。開發(fā)者可以使用HQL的語法進(jìn)行數(shù)據(jù)分析和管理，大大提升了開發(fā)效率。Hive組件流行起來，成為構(gòu)建數(shù)據(jù)倉庫的主流工具之一。但是，MapReduce在計(jì)算過程中大量的中間磁盤落地過程消耗了大量的磁盤I/O，降低了運(yùn)行效率。此時(shí)，由于Hive的火爆，伯克利實(shí)驗(yàn)室的開發(fā)人員基于Hive開發(fā)出一套新的框架——Shark。Shark在Hive的基礎(chǔ)上優(yōu)化的了內(nèi)存管理、執(zhí)行計(jì)劃等多個(gè)模塊，從而提升了內(nèi)存與磁盤的交互效率。但是，Shark強(qiáng)依賴于Hive框架的眾多技術(shù)模塊（如采用Hive的語法解析器、查詢優(yōu)化器等），所以不能與Spark其他核心組件配合使用。最終，開發(fā)人員基于Shark框架開發(fā)出了SparkSQL組件。SparkSQL（2)SparkSQL中的數(shù)據(jù)抽象SparkSQL中所使用的數(shù)據(jù)抽象并非是RDD，而是DataFrame。Spark1.3版本中首次引進(jìn)這個(gè)概念，它的前身是SchemaRDD。SparkSQL通調(diào)用DataFrameAPI來對數(shù)據(jù)進(jìn)行分析處理，也可以將DataFrame注冊成表，直接使用SQL語句在數(shù)據(jù)表上進(jìn)行交互式查詢。DataFrame的推出，讓Spark具備了處理大規(guī)模結(jié)構(gòu)化數(shù)據(jù)的能力，它不僅比原有的RDD的轉(zhuǎn)化方式更加簡單易用，而且獲得了更高的計(jì)算性能。在直接面向RDD進(jìn)行數(shù)據(jù)分析時(shí)為了得到最終的結(jié)果，可能需要基于初始RDD執(zhí)行多次轉(zhuǎn)換，每一次轉(zhuǎn)換都生成了一個(gè)新的RDD；而對于DataFrame而言，一條SQL語句可能隱含多次轉(zhuǎn)換操作，但轉(zhuǎn)換操作在其內(nèi)部發(fā)生，并不會頻繁創(chuàng)建新的RDD，以減少系統(tǒng)開銷。Spark1.6之后，引入了一個(gè)新的數(shù)據(jù)抽象類型——DataSet。它結(jié)合了RDDAPI的很多優(yōu)點(diǎn)，比如說強(qiáng)類型，保證編譯期類型安全，支持Lanbda表達(dá)式等，并且還結(jié)合了SparkSQL優(yōu)化執(zhí)行引擎的優(yōu)點(diǎn)。Dataset可以通過JVM對象來構(gòu)造，然后通過transformation類算子（map，flatMap，filter等）來進(jìn)行操作。在Spark2.0之后的版本中，管理結(jié)構(gòu)化數(shù)據(jù)的主要數(shù)據(jù)類型變成了DataSet。DataFrame的源碼已經(jīng)被移除了，但是DataFrame這個(gè)數(shù)據(jù)類型并沒有別徹底刪除，而是規(guī)定：如果Dataset[T]中的泛型T是Row類型，那么Dataset就等同于DataFarme，即DataFrame=Dataset[Row]，為Dataset的子集。SparkStreamingSparkStreaming類似于ApacheStorm，用于流式數(shù)據(jù)的處理。根據(jù)其官方文檔介紹，SparkStreaming有高吞吐量和容錯(cuò)能力強(qiáng)等特點(diǎn)。SparkStreaming支持的數(shù)據(jù)輸入源很多，例如：Kafka、Flume、Twitter、ZeroMQ和簡單的TCP套接字等等。數(shù)據(jù)輸入后可以用Spark的高度抽象操作如：map、reduce、join、window等進(jìn)行運(yùn)算。而結(jié)果也能保存在很多地方，如HDFS，數(shù)據(jù)庫等。另外SparkStreaming也能和MLlib（機(jī)器學(xué)習(xí)）以及Graphx完美融合?，F(xiàn)在，無論是傳統(tǒng)行業(yè)還是互聯(lián)網(wǎng)行業(yè)，都逐漸使用即時(shí)數(shù)據(jù)分析來提供決策或響應(yīng)用戶。隨著硬件技術(shù)的升級，業(yè)務(wù)系統(tǒng)在單位時(shí)間內(nèi)產(chǎn)生的數(shù)據(jù)量也越來越大。要滿足這個(gè)需求，就必須使用分布式、實(shí)時(shí)流處理框架。在構(gòu)建數(shù)據(jù)倉庫時(shí)，SparkStreaming還可以實(shí)時(shí)備份數(shù)據(jù)，或?qū)崟r(shí)對流入的數(shù)據(jù)進(jìn)行轉(zhuǎn)換，將轉(zhuǎn)換結(jié)果輸出到另外一套系統(tǒng)中。在大多數(shù)實(shí)時(shí)處理流式數(shù)據(jù)的場景中，SparkStreaming都可以勝任，如圖所示。SparkStreaming1)SparkStreaming的原理SparkStreaming是基于Spark的流式批處理引擎，其基本原理是把輸入數(shù)據(jù)以某一時(shí)間間隔批量的處理。當(dāng)批處理間隔縮短到秒級時(shí)，便可以用于處理實(shí)時(shí)數(shù)據(jù)流，其實(shí)就是把流式計(jì)算當(dāng)作一系列連續(xù)的小規(guī)模批處理來對待，本質(zhì)上是用批處理(小批次)的思想來做流處理，如圖所示。SparkStreaming2)SparkStreaming計(jì)算流程SparkStreaming是將流式計(jì)算分解成一系列短小的批處理作業(yè)。這里的批處理引擎是SparkCore，也就是把SparkStreaming的輸入數(shù)據(jù)按照batchsize（如1秒）分成一段一段的離散流（DiscretizedStream），每一段數(shù)據(jù)都轉(zhuǎn)換成Spark中的RDD，然后將SparkStreaming中對DStream的Transformation操作變?yōu)獒槍park中對RDD的Transformation操作，將RDD經(jīng)過操作變成中間結(jié)果保存在內(nèi)存中。整個(gè)流式計(jì)算根據(jù)業(yè)務(wù)的需求可以對中間的結(jié)果進(jìn)行緩存或者存儲到外部設(shè)備，如圖所示。SparkStreaming3)SparkStreaming數(shù)據(jù)抽象在SparkStreaming中，引入了一個(gè)新的概念——Dstream。Dstream是SparkStreaming中運(yùn)算、存儲數(shù)據(jù)的基礎(chǔ)。DStream：DiscretizedStream，離散流，SparkStreaming提供的一種高級抽象，代表了一個(gè)持續(xù)不斷的數(shù)據(jù)流。其最主要的功能是為每一個(gè)批次的數(shù)據(jù)生成RDD實(shí)例，每個(gè)RDD含有一段時(shí)間間隔內(nèi)的數(shù)據(jù)，如圖所示。SparkMLlibSparkMllib是Spark提供的機(jī)器學(xué)習(xí)庫，旨在簡化機(jī)器學(xué)習(xí)的工程實(shí)踐工作，并方便擴(kuò)展到更大規(guī)模MLlib由一些通用的學(xué)習(xí)算法和工具組成，包括分類、回歸、聚類、協(xié)同過濾、降維等，同時(shí)還包括底層的優(yōu)化原語和高層的管道API。Spark是基于內(nèi)存計(jì)算的，天然適應(yīng)于數(shù)據(jù)挖掘的迭代式計(jì)算，但是對于普通開發(fā)者來說，實(shí)現(xiàn)分布式的數(shù)據(jù)挖掘算法仍然具有極大的挑戰(zhàn)性。因此，Spark提供了一個(gè)基于海量數(shù)據(jù)的機(jī)器學(xué)習(xí)庫MLlib，它提供了常用數(shù)據(jù)挖掘算法的分布式實(shí)現(xiàn)功能。開發(fā)者只需要有Spark基礎(chǔ)并且了解數(shù)據(jù)挖掘算法的原理，以及算法參數(shù)的含義，就可以通過調(diào)用相應(yīng)的算法的API來實(shí)現(xiàn)基于海量數(shù)據(jù)的挖掘過程。SparkMLlib相比于基于HadoopMapReduce實(shí)現(xiàn)的機(jī)器學(xué)習(xí)算法（如HadoopMahout），SparkMLlib在機(jī)器學(xué)習(xí)方面具有一些得天獨(dú)厚的優(yōu)勢。首先，機(jī)器學(xué)習(xí)算法一般都有由多個(gè)步驟組成迭代計(jì)算的過程，機(jī)器學(xué)習(xí)的計(jì)算需要在多次迭代后獲得足夠小的誤差或者足夠收斂時(shí)才會停止。如果迭代時(shí)使用HadoopMapReduce計(jì)算框架，則每次計(jì)算都要讀/寫磁盤及完成任務(wù)的啟動(dòng)等工作，從而會導(dǎo)致非常大的I/O和CPU消耗。而Spark基于內(nèi)存的計(jì)算模型就是針對迭代計(jì)算而設(shè)計(jì)的，多個(gè)迭代直接在內(nèi)存中完成，只有在必要時(shí)才會操作磁盤和網(wǎng)絡(luò)，所以說，SparkMLlib正是機(jī)器學(xué)習(xí)的理想的平臺。其次，Spark具有出色而高效的Akka和Netty通信系統(tǒng)，通信效率高于HadoopMapReduce計(jì)算框架的通信機(jī)制。HadoopMapReduce實(shí)現(xiàn)的機(jī)器學(xué)習(xí)算法（如HadoopMahout）VSSparkMLlibSparkGraphxSparkGraphX是ApacheSpark提供的一個(gè)分布式圖處理框架，它是基于Spark平臺提供對圖計(jì)算和圖挖掘簡潔易用的而豐富的接口，極大的方便了對分布式圖處理的需求。眾所周知社交網(wǎng)絡(luò)中人與人之間有很多關(guān)系鏈，例如Twitter、Facebook、微博和微信等，數(shù)據(jù)中出現(xiàn)網(wǎng)狀結(jié)構(gòu)關(guān)系都需要圖計(jì)算。ApacheSpark每個(gè)子模塊都有一個(gè)核心抽象。GraphX的核心抽象是彈性分布式屬性圖（ResilientDistributedPropertyGraph）。每個(gè)圖的頂點(diǎn)和邊均有屬性的有向多重圖，來擴(kuò)展SparkRDD，它繼承了Spark中RDD的DAG、高容錯(cuò)性等概念和特性，實(shí)現(xiàn)了圖計(jì)算的高效性與健壯性。彈性分布式屬性圖有Table和Graph兩種視圖，而只需要一份物理存儲。兩種視圖都有自己獨(dú)有的操作符，從而獲得了靈活操作和執(zhí)行效率。為了支持圖計(jì)算，GraphX開發(fā)了一組基本的功能操作以及一個(gè)優(yōu)化過的PregelAPI。另外，GraphX也包含了一個(gè)快速增長的圖算法和圖builders的集合，用以簡化圖分析任務(wù)。SparkGraphx分布式數(shù)據(jù)計(jì)算通過同時(shí)處理獨(dú)立的數(shù)據(jù)來獲得并發(fā)的目的，分布式圖計(jì)算則是通過對圖數(shù)據(jù)進(jìn)行分區(qū)（即切分）來獲得并發(fā)的目的。更準(zhǔn)確的說，分布式圖計(jì)算遞歸地定義特征的轉(zhuǎn)換函數(shù)（這種轉(zhuǎn)換函數(shù)作用于鄰居特征），通過并發(fā)地執(zhí)行這些轉(zhuǎn)換函數(shù)來獲得并發(fā)的目的。分布式圖計(jì)算比分布式數(shù)據(jù)計(jì)算更適合圖的處理，但是在典型的圖處理流水線中，它并不能很好地處理所有操作。例如，雖然分布式圖系統(tǒng)可以很好的計(jì)算PageRank等算法，但是它們不適合從不同的數(shù)據(jù)源構(gòu)建圖或者跨過多個(gè)圖計(jì)算特征。更準(zhǔn)確的說，分布式圖系統(tǒng)提供的更窄的計(jì)算視圖無法處理那些構(gòu)建和轉(zhuǎn)換圖結(jié)構(gòu)以及跨越多個(gè)圖的需求。分布式圖系統(tǒng)中無法提供的這些操作需要數(shù)據(jù)在圖本體之上移動(dòng)并且需要一個(gè)圖層面而不是單獨(dú)的頂點(diǎn)或邊層面的計(jì)算視圖。分布式圖計(jì)算和分布式數(shù)據(jù)計(jì)算類似，分布式數(shù)據(jù)計(jì)算采用了一種record-centric（以記錄為中心）的集合視圖，而分布式圖計(jì)算采用了一種vertex-centric（以頂點(diǎn)為中心）的圖視圖。Flink生態(tài)圈技術(shù)Flink官網(wǎng)主頁在其頂部展示了該項(xiàng)目的理念：“ApacheFlink是為分布式、高性能、隨時(shí)可用以及準(zhǔn)確的流處理應(yīng)用程序打造的開源流處理框架”（Flink官網(wǎng)地址：/）。ApacheFlink是一個(gè)框架和分布式處理引擎，用于對無界和有界數(shù)據(jù)流進(jìn)行有狀態(tài)計(jì)算。Flink被設(shè)計(jì)在所有常見的集群環(huán)境中運(yùn)行，以內(nèi)存執(zhí)行速度和任意規(guī)模來執(zhí)行計(jì)算。ApacheFlink能夠基于同一個(gè)Flink運(yùn)行時(shí)（FlinkRuntime），提供支持流處理和批處理兩種類型應(yīng)用的功能?，F(xiàn)有的開源計(jì)算方案，會把流處理和批處理作為兩種不同的應(yīng)用類型，因?yàn)樗麄兯鼈兯峁┑腟LA是完全不相同的：流處理一般需要支持低延遲、Exactly-once保證，而批處理需要支持高吞吐、高效處理，所以在實(shí)現(xiàn)的時(shí)候通常是分別給出兩套實(shí)現(xiàn)方法，或者通過一個(gè)獨(dú)立的開源框架來實(shí)現(xiàn)其中每一種處理方案。例如，實(shí)現(xiàn)批處理的開源方案有MapReduce、Tez、Crunch、Spark，實(shí)現(xiàn)流處理的開源方案有Samza、Storm。Flink在實(shí)現(xiàn)流處理和批處理時(shí)，與傳統(tǒng)的一些方