大數(shù)據(jù)處理技術(shù)簡介37課件

1、大數(shù)據(jù)處理技術(shù)簡介第1頁，共38頁。1234大數(shù)據(jù)處理相關(guān)工具介紹國內(nèi)相關(guān)數(shù)據(jù)處理平臺簡介Storm實時計算系統(tǒng)簡介概念及背景介紹第2頁，共38頁。大數(shù)據(jù)概念1、指的是所涉及的資料量規(guī)模巨大到無法通過目前主流軟件工具，在合理的時間內(nèi)達到擷取、管理、處理并整理成為幫助企業(yè)經(jīng)營決策更積極目的的咨詢。2、維克托邁爾-舍恩伯格以及肯尼斯庫克耶編寫的大數(shù)據(jù)時代中大數(shù)據(jù)指不用隨機分析法（抽樣調(diào)查）這樣的捷徑，而采用所有數(shù)據(jù)進行分析處理。3、海量異構(gòu)的數(shù)據(jù)（包括文本、圖像、聲音等）。大數(shù)據(jù)的4V特點：Volume（大量）、Velocity（高速）、Variety（多樣）、Value（價值）第3頁，共38頁。

2、 近年來，一種新的數(shù)據(jù)密集型應(yīng)用已經(jīng)得到了廣泛的認同，這些應(yīng)用的實例包括：網(wǎng)絡(luò)監(jiān)控、電信數(shù)據(jù)管理、Web應(yīng)用、傳感檢測等等。在這種數(shù)據(jù)流模型中，數(shù)據(jù)以大量、快速、時變（可能是不可預(yù)知）的數(shù)據(jù)流持續(xù)到達，如何對海量瞬時流動數(shù)據(jù)建模并處理，產(chǎn)生了一些新的基礎(chǔ)性研究問題。大數(shù)據(jù)處理技術(shù)的應(yīng)用第4頁，共38頁。大數(shù)據(jù)應(yīng)用情景一（B2C、C2C與金融）：淘寶、股票等即時交易數(shù)據(jù)截至2011年11月，淘寶Beltles平臺單日最大服務(wù)調(diào)用量19億。今年淘寶雙11 QPS:32萬/分鐘2012-01-14報道，鐵道部12306網(wǎng)站連續(xù)5天日均點擊數(shù)超過10億次，高峰時超過14.09億次，導(dǎo)致系統(tǒng)近乎崩潰或癱

3、瘓。2009年四月統(tǒng)計：上證交易所新一代交易系統(tǒng)峰值訂單處理能力約80000筆/秒，平均訂單時延比現(xiàn)用交易系統(tǒng)縮短30%以上，系統(tǒng)日雙邊成交容量不低于1.2億筆/日，相當于單市場1.2萬億的日成交規(guī)模。第5頁，共38頁。大數(shù)據(jù)應(yīng)用情景三（社交網(wǎng)絡(luò)）：社交網(wǎng)絡(luò)即時消息處理每秒鐘，人們發(fā)送290萬封電子郵件。每分鐘，人們向Youtube上傳60個小時的視頻。每一天，人們在Twitter上發(fā)消息1.9億條微博。每一天，人們在Twitter上發(fā)出3.44億條消息。每一天，人們在Facebook發(fā)出40億條信息。第6頁，共38頁。大數(shù)據(jù)應(yīng)用情景三（物聯(lián)網(wǎng)數(shù)據(jù)流）：傳感網(wǎng)、物聯(lián)網(wǎng)、智慧城市數(shù)據(jù)庫 傳感設(shè)備

4、 服務(wù)器 用戶端程序 實時數(shù)據(jù)流 處理平臺 Internet設(shè)備網(wǎng)PDA決策支持PC機傳感網(wǎng)、物聯(lián)網(wǎng)源源不斷產(chǎn)生海量數(shù)據(jù)流、數(shù)據(jù)量更大，加上能更準確、更快地收集比如位置、生活信息等數(shù)據(jù)，對在線即時處理提出了更高的要求和挑戰(zhàn)。第7頁，共38頁。大數(shù)據(jù)應(yīng)用情景四（數(shù)據(jù)流過濾）：互聯(lián)網(wǎng)帶寬增長根據(jù)中國互聯(lián)網(wǎng)絡(luò)信息中心（CNNIC）的“中國互聯(lián)網(wǎng)絡(luò)發(fā)展狀況統(tǒng)計報告”調(diào)查顯示，2011年中國的互聯(lián)網(wǎng)基礎(chǔ)資源繼續(xù)保持快速增長，IP地址、域名、網(wǎng)站和網(wǎng)頁等增速基本與網(wǎng)民增長等速或超過網(wǎng)民的增速，網(wǎng)絡(luò)國際出口帶寬達到1,182,261.45Mbps，半年增長了7.6%。第8頁，共38頁。國內(nèi)外相關(guān)研究數(shù)據(jù)流計

5、算的典型模式之一是不確定數(shù)據(jù)速率的數(shù)據(jù)流流入系統(tǒng)，系統(tǒng)處理能力必須與數(shù)據(jù)流量大小相匹配。 Hadoop（MapReduce）框架為批處理做了高度優(yōu)化，數(shù)據(jù)存儲在分布式文件系統(tǒng)中，系統(tǒng)典型地通過調(diào)度批量任務(wù)來操作分布式文件系統(tǒng)靜態(tài)數(shù)據(jù)。實時計算（數(shù)據(jù)驅(qū)動） VS. 批處理計算（任務(wù)驅(qū)動） 第9頁，共38頁。國內(nèi)外相關(guān)研究數(shù)據(jù)流計算的典型模式之一是不確定數(shù)據(jù)速率的數(shù)據(jù)流流入系統(tǒng)，系統(tǒng)處理能力必須與數(shù)據(jù)流量大小相匹配。 Hadoop（MapReduce）框架為批處理做了高度優(yōu)化，數(shù)據(jù)存儲在分布式文件系統(tǒng)中，系統(tǒng)典型地通過調(diào)度批量任務(wù)來操作分布式文件系統(tǒng)靜態(tài)數(shù)據(jù)。實時計算（數(shù)據(jù)驅(qū)動） VS. 批處理計

6、算（任務(wù)驅(qū)動） 第10頁，共38頁。應(yīng)用計算模型與通信機制數(shù)據(jù)規(guī)模計算模型普通集群基于消息傳遞的分布式模型TB級/百臺MPI云計算基于文件傳輸?shù)牟⑿杏嬎隳Ｐ蚉B級/千臺MapReduce數(shù)據(jù)流實時云計算基于消息（封裝文件）傳輸?shù)牟⑿杏嬎鉖B級/千臺Online MapReduce分布式并行計算系統(tǒng) 流水線+并行、可配置、可容錯、彈性可擴展、全內(nèi)存、實時在線處理。第11頁，共38頁。第一類方法，Hadoop改造：1 Yingyi Bu等在Hadoop MapReduce工作的基礎(chǔ)上設(shè)計了HaLoop，主要克服了Hadoop進行迭代計算時需要設(shè)置收斂條件以及每次迭代均需要重新加載數(shù)據(jù)的缺點；2 伯

7、克利大學(xué)的Tyson Condie等對Hadoop進行改進，設(shè)計了Hadoop Online Prototype (HOP)系統(tǒng)，支持連續(xù)查詢、事件監(jiān)測以及流處理等功能；3 Facebook在SIGMOD 2011上發(fā)表了利用Hbase/Hadoop進行實時處理數(shù)據(jù)的論文，通過一些實時性改造，力圖使hadoop批處理計算平臺也具備實時計算的能力。4 Google在新一代內(nèi)容索引系統(tǒng)中放棄了MapReduce，替代者是尚不為人知的分布式數(shù)據(jù)處理系統(tǒng)Percolator，Percolator是一種增量處理平臺，它能持續(xù)更新索引系統(tǒng)，無需從頭重新處理一遍整個系統(tǒng)。5 Wang Lam等開發(fā)了類似于M

8、ap-reduce框架、專注于快速處理數(shù)據(jù)的Muppet；第二類方法，實時云計算系統(tǒng)：6 MIT等三所高校的研究人員聯(lián)合研發(fā)了第二代分布式流處理系統(tǒng)Borealis；7 SheheryarMalik設(shè)計了具有良好錯誤容忍機制的實時云計算系統(tǒng)；Harmeek Singh Bedi申請了實時云計算系統(tǒng)的專利；8 Baidu Dstream， 淘寶Beales， Facebook Puma，Twitter Storm，Yahoo！ S49 2011年組織了以實時云計算和虛擬化為主題的國際討論組會RTSOAA（Real-Time Cloud Computing and Virtualization）。

9、10 2011年度的HadoopChina大會一個熱點議題就是數(shù)據(jù)流計算，在MapReduce計算模型風(fēng)靡全球之后，StreamProcessing將會是下一個研究熱點，無論是在工業(yè)界還是學(xué)術(shù)界。實時計算系統(tǒng)的改造第12頁，共38頁。1234大數(shù)據(jù)處理相關(guān)工具介紹國內(nèi)相關(guān)數(shù)據(jù)處理平臺簡介Storm實時計算系統(tǒng)簡介概念及背景介紹第13頁，共38頁。Hadoop家族14第14頁，共38頁。開源工具簡介-批處理Hadoop Common：Hadoop體系最底層的一個模塊，為Hadoop各子項目提供各種工具，如：配置文件和日志操作等。HDFS：是Hadoop的分布式存儲系統(tǒng)，同Google的GFS性質(zhì)

10、是一樣的。MapReduce：是一種編程模型，用于大規(guī)模數(shù)據(jù)集的并行運算。Hive是基于Hadoop的一個數(shù)據(jù)倉庫工具，提供簡單的sql查詢功能，可以將sql語句轉(zhuǎn)換為MapReduce任務(wù)進行運行，十分適合數(shù)據(jù)倉庫的統(tǒng)計分析。Pig：Pig最大的作用就是對MapReduce算法(框架)實現(xiàn)了一套shell腳本 ，類似我們通常熟悉的SQL語句，在Pig中稱之為Pig Latin。Hbase：一個分布式、可擴展的大數(shù)據(jù)存儲。它提供了大數(shù)據(jù)集上隨機和實時的讀/寫訪問，并針對了商用服務(wù)器集群上的大型表格做出優(yōu)化上百億行，上千萬列。它是Google bigtable的一個開源的實現(xiàn)。Zookeeper

11、:它是一個針對大型分布式系統(tǒng)的可靠協(xié)調(diào)系統(tǒng)，功能包括：配置維護、名字服務(wù)、 分布式同步、組服務(wù)等。ZooKeeper的目標就是封裝好復(fù)雜易出錯的關(guān)鍵服務(wù)，將簡單易用的接口和性能高效、功能穩(wěn)定的系統(tǒng)提供給用戶。它是 Google的Chubby一個開源的實現(xiàn)。第15頁，共38頁。開源工具簡介-實時計算國外1：facebook puma 國外2：twitter storm國外3：yahoo! s4Twitter 數(shù)據(jù)處理分層架構(gòu)Puma 3 系統(tǒng)數(shù)據(jù)處理通路Storm 數(shù)據(jù)流處理示意圖S4 數(shù)據(jù)流處理流程Real time Cloud computingFacebook PumaTwitter St

12、ormYahoo！ S4開發(fā)語言JAVAClojureJAVA高可用機制被動備用上游回放被動備用架構(gòu)均勻架構(gòu)主從架構(gòu)主從架構(gòu)資源利用率低高低恢復(fù)時間短長長第16頁，共38頁。開源工具簡介-全內(nèi)存查詢Spark是一通用并行計算框架，由UCBerkeley的AMP實驗室開發(fā)。將中間數(shù)據(jù)放到內(nèi)存中，對于迭代運算效率比較高。如：機器學(xué)習(xí)（ML）與hadoop相比提供了更多種運算操作，并且通信模型也是多樣的，hadoop僅有Data Shuffle。缺點： Spark不適用那種異步細粒度更新狀態(tài)的應(yīng)用，例如web服務(wù)的存儲或者是增量的web爬蟲和索引。就是對于那種增量修改的應(yīng)用模型，因為增量改動完了，也

13、就不用了，不需要迭代了。Druid為分析而設(shè)計- Druid是為OLAP工作流的探索性分析而構(gòu)建。它支持各種filter、aggregator和查詢類型，并為添加新功能提供了一個框架。交互式查詢-低延遲數(shù)據(jù)攝取架構(gòu)允許事件在它們創(chuàng)建后毫秒內(nèi)查詢， 完全有可能在6TB的數(shù)據(jù)集上實現(xiàn)秒級查詢。高可用性-支持需要一直在線的SaaS的實現(xiàn)。你的數(shù)據(jù)在系統(tǒng)更新時依然可用、可查詢。規(guī)模的擴大和縮小不會造成數(shù)據(jù)丟失?？缮炜s-每天處理數(shù)十億事件和TB級數(shù)據(jù)。Druid被設(shè)計成PB級別。優(yōu)缺點：Druid對于需要實時單一、海量數(shù)據(jù)流攝取產(chǎn)品非常適合。特別是如果你面向無停機操作時，如果你對查詢查詢的靈活性和原始數(shù)

14、據(jù)訪問要求，高于對速度和無停機操作，Druid可能不是很好的解決方案。第17頁，共38頁。1234大數(shù)據(jù)處理相關(guān)工具介紹國內(nèi)相關(guān)數(shù)據(jù)處理平臺簡介Storm實時計算系統(tǒng)簡介概念及背景介紹第18頁，共38頁。國內(nèi)相關(guān)計算平臺國內(nèi)1：baidu下一代數(shù)據(jù)流系統(tǒng)DStream百度基礎(chǔ)架構(gòu)部的下一代規(guī)劃中，實時計算是重要的組成部分。實時計算系統(tǒng)和批處理計算系統(tǒng)同屬于云計算這個大的范疇，相互配合使用。批處理計算是MapReduce（Hadoop）、實時計算是DStream等。DStream的Release 1.0版本在2012年上半年發(fā)布。DStream依賴幾個第三方系統(tǒng)，Bigpipe、Zookeepe

15、r和HDFS，分別用于數(shù)據(jù)流輸入輸出和操作日志的存儲、分布式異常監(jiān)控、用戶文件存儲和計算狀態(tài)存儲。第19頁，共38頁。1、每天有超過30億的店鋪、商品瀏覽記錄，10億在線商品數(shù)，上千萬的成交、收藏和評價數(shù)據(jù)。2、量子統(tǒng)計、數(shù)據(jù)魔方和淘寶指數(shù)。3、Hadoop集群：1500個節(jié)點，每天有大約40000個作業(yè)對1.5PB的原始數(shù)據(jù)按照產(chǎn)品需求進行不同的MapReduce計算。4、Storm集群：處理實時流數(shù)據(jù)。國內(nèi)相關(guān)計算平臺國內(nèi)2：淘寶數(shù)據(jù)分析平臺架構(gòu)第20頁，共38頁。數(shù)據(jù)存儲引擎：MySQL的MyISAM引擎統(tǒng)計數(shù)據(jù)：10TB（分布在20個節(jié)點），每天6億條的增量節(jié)點類型劃分： 熱節(jié)點：SA

16、S硬盤（15000轉(zhuǎn)/分鐘） 4.5W/TB 冷節(jié)點：SATA硬盤（7500轉(zhuǎn)/分鐘） 1.6W/TB缺點：不能解決全屬性選擇器問題，這時NoSql是對其的有益補充。Myfox簡介4:300國內(nèi)相關(guān)計算平臺第21頁，共38頁。國內(nèi)相關(guān)計算平臺國內(nèi)2：淘寶Beatles實時流式數(shù)據(jù)分析平臺2010年Beatles開放平臺基礎(chǔ)體系開始建立，服務(wù)調(diào)用量增漲到了9億。截至2011年11月，單日最大服務(wù)調(diào)用量19億，增量統(tǒng)計實時性要求在2分鐘內(nèi)（包含數(shù)據(jù)分析和數(shù)據(jù)產(chǎn)出，低峰期1分鐘，高峰期1分半），系統(tǒng)可用性要求高于99.6第22頁，共38頁。目錄1234大數(shù)據(jù)處理相關(guān)工具介紹國內(nèi)相關(guān)數(shù)據(jù)處理平臺簡介S

17、torm實時計算系統(tǒng)簡介概念及背景介紹第23頁，共38頁。Storm實時計算系統(tǒng)第24頁，共38頁。Storm數(shù)據(jù)流處理引擎整體架構(gòu)第25頁，共38頁。主要模塊Master-Supervisor-Worker的模塊關(guān)系圖控制節(jié)點啟動Master,負責(zé)整個topology執(zhí)行監(jiān)控和任務(wù)分配工作節(jié)點啟動Supervisor，每個Supervisor包含一組port，每個port可以初始化一個Worker，每個Worker執(zhí)行一部分數(shù)據(jù)處理程序工作節(jié)點啟動Zookeeper, 負責(zé)topology的協(xié)調(diào)和同步第26頁，共38頁。Nimbus模塊第27頁，共38頁。Supervisor模塊步驟1：Su

18、pervisor從Zookeeper目錄中下載Worker執(zhí)行的代碼步驟2：Supervisor監(jiān)控Worker的執(zhí)行狀態(tài)。步驟3：Supervisor向Zookeeper的目錄中寫入它所監(jiān)控的各個Worker的心跳信息第28頁，共38頁。Worker模塊步驟1：Worker從Zookeeper目錄獲取Task集合步驟2：Worker建立接收和發(fā)送的消息隊列步驟3：Worker內(nèi)部的每個Task開始初始化，準備執(zhí)行處理程序和向Zookeeper發(fā)送心跳步驟4：消息隊列把Tuple發(fā)送給相應(yīng)的Task進行處理，處理結(jié)果再傳給消息隊列進行下發(fā)第29頁，共38頁。關(guān)鍵技術(shù)并行處理技術(shù)條件：查詢由兩個

19、有狀態(tài)算子（一個Join和一個Aggregate）和4個無狀態(tài)算子（兩個Map和兩個Filter）組成。如圖b所示，將每個算子都部署在有15個節(jié)點的子集群，跳數(shù)為5，每個節(jié)點的扇出數(shù)為15，所以扇出的總數(shù)就是155。如圖c所示，將a所示的查詢根據(jù)有狀態(tài)算子進行劃分，可以劃分成3個子查詢，每個子查詢都部署在30個節(jié)點的子查詢上，由此可見，跳數(shù)為2，每個節(jié)點的扇出數(shù)為302。第30頁，共38頁。相關(guān)工作關(guān)鍵技術(shù)可靠性保障技術(shù)a) 主動備份技術(shù)b) 被動備份技術(shù)c) 上游備份技術(shù)主動備份技術(shù)：節(jié)點A產(chǎn)生的元組同時發(fā)送給主節(jié)點B1和備份節(jié)點B2。該容錯技術(shù)存在保存副本的空間開銷。被動備份技術(shù)：將要備份

20、的算子的狀態(tài)信息周期的拷貝到備份節(jié)點。當最后一個校驗點出現(xiàn)故障時，主節(jié)點中的所有元組并沒有在備份節(jié)點中維護，那么，就需要上游算子將元組重新發(fā)送到備份節(jié)點上，這會導(dǎo)致故障的恢復(fù)時間較長。上游備份技術(shù)：上游節(jié)點維護所有輸出元組的狀態(tài)，當且僅當下游節(jié)點確認已經(jīng)接收上游節(jié)點發(fā)來的這些元組，上游節(jié)點才會將這些已確認的元組刪除。該容錯技術(shù)也存在故障恢復(fù)時間較長的問題。第31頁，共38頁。元組跟蹤器總體結(jié)構(gòu)關(guān)鍵技術(shù)可靠性保障技術(shù)工作原理：1、讀取配置文件，生成元組跟蹤單元。2、跟蹤記錄的構(gòu)造（三元組）。三元組結(jié)構(gòu)：3、元組跟蹤單元的選擇。4、校驗值更新。5、將更新結(jié)果反饋給元組生成器（Spring）。第32

21、頁，共38頁。元組跟蹤單元（acker）選擇關(guān)鍵技術(shù)可靠性保障技術(shù)a) springId（taskId）映射b) acker的元組分配第33頁，共38頁。元組跟蹤單元（acker）選擇關(guān)鍵技術(shù)可靠性保障技術(shù)c) acker故障后的元組分配d) acker變更后的元組分配第34頁，共38頁。校驗值更新策略關(guān)鍵技術(shù)可靠性保障技術(shù)第35頁，共38頁。彈性可擴展協(xié)議關(guān)鍵技術(shù)彈性可擴展技術(shù)窗口重構(gòu)協(xié)議能夠避免處理元組的Task間通信，但是該協(xié)議的一個弊端就是協(xié)議的完成時間依賴于滑動窗口大小，因此，假如窗口很大的話，協(xié)議的完成時間會很長，這樣的效果是不能接受的。狀態(tài)重構(gòu)協(xié)議該協(xié)議不受滑動窗口大小的影響，該協(xié)議的實現(xiàn)是通過用一個檢查點來記錄元組桶，該檢查點就是元組發(fā)送到新Task和舊Task的分界點。第36頁，共38頁。第3