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

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

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

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

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

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