大數(shù)據(jù)導論（第2版） 課件 項目6 大數(shù)據(jù)處理技術

項目6大數(shù)據(jù)處理技術目錄1任務6.1：熟悉大數(shù)據(jù)處理技術

【導讀案例】Cloudera領銜大數(shù)據(jù)基礎設施

【任務描述】

【知識準備】大數(shù)據(jù)處理的內(nèi)容與技術【作業(yè)】【實訓操作】理解和熟悉大數(shù)據(jù)處理技術【導讀案例】Cloudera領銜大數(shù)據(jù)基礎設施討論：（1）請通過網(wǎng)絡搜索，進一步了解Cloudera公司，并做簡單描述。（2）除了Cloudera，你還知道哪些領銜大數(shù)據(jù)基礎設施的公司？其中屬于中國的公司主要有哪些？（3）文中為什么說：“大數(shù)據(jù)技術需要花費很長時間才能融入企業(yè)中”？（4）請簡單記述你所知道的上一周內(nèi)發(fā)生的國

際、國內(nèi)或者身邊的大事。【任務描述】（1）熟悉大數(shù)據(jù)處理的基本技術，了解大數(shù)據(jù)處理的基本概念和技術架構。（2）熟悉大數(shù)據(jù)處理的批處理模式和實時處理模式。（3）掌握大數(shù)據(jù)處理的處理工作量，熟悉SCV原則。（4）分析ETI企業(yè)，掌握大數(shù)據(jù)處理工作量與處理模式工作方式?！局R準備】大數(shù)據(jù)處理的內(nèi)容與技術大數(shù)據(jù)處理如今已不再是新話題了。在考慮數(shù)據(jù)倉庫與其相關數(shù)據(jù)市場的關系時，把龐大的數(shù)據(jù)集分成多個較小的數(shù)據(jù)集來處理可以加快大數(shù)據(jù)處理的速度。人們已經(jīng)把存儲在分布式文件系統(tǒng)、分布式數(shù)據(jù)庫上的大數(shù)據(jù)集分成較小的數(shù)據(jù)集了。要理解大數(shù)據(jù)處理，關鍵是要意識到處理大數(shù)據(jù)與在傳統(tǒng)關系型數(shù)據(jù)庫中處理數(shù)據(jù)是不同的，大數(shù)據(jù)通常以分布式的方式在其各自存儲的位置進行并行處理。許多大數(shù)據(jù)處理采用批處理模式，而針對以一定速度按時間順序到達的流式數(shù)據(jù)，現(xiàn)今已經(jīng)有了相關的分析方法，例如，利用內(nèi)存架構，意義構建理論可以提供態(tài)勢感知。流式大數(shù)據(jù)的處理應遵循一項重要的原則，即SCV原則，其中：S代表Speed（速度），C代表Consistency（一致性），V代表Volume（容量）。開源技術的商業(yè)支援6.1.16.1.1開源技術的商業(yè)支援在大數(shù)據(jù)生態(tài)系統(tǒng)中，基礎設施主要負責數(shù)據(jù)存儲以及處理公司掌握的海量數(shù)據(jù)。應用程序則是指人類和計算機系統(tǒng)通過使用這些程序，從數(shù)據(jù)中獲知關鍵信息。人們使用應用程序使數(shù)據(jù)可視化，并由此做出更好的決策；而計算機則使用應用系統(tǒng)將廣告投放到合適的人群，或者監(jiān)測信用卡欺詐行為。在大數(shù)據(jù)的演變中，開源軟件起到了很大的作用。如今，Linux已經(jīng)成為主流操作系統(tǒng)，并與低成本的服務器硬件系統(tǒng)相結(jié)合。有了Linux，企業(yè)就能在低成本硬件上使用開源操作系統(tǒng)，以低成本獲得許多相同的功能。MySQL開源數(shù)據(jù)庫、Apache開源網(wǎng)絡服務器以及PHP開源腳本語言（最初為創(chuàng)建網(wǎng)站開發(fā)）搭配起來的實用性也推動了Linux的普及。6.1.1開源技術的商業(yè)支援隨著越來越多的企業(yè)將Linux大規(guī)模地用于商業(yè)用途，他們期望獲得企業(yè)級的商業(yè)支持和保障。在眾多的供應商中，紅帽子Linux（RedHat）脫穎而出，成為Linux商業(yè)支持及服務的市場領導者。甲骨文公司（Oracle）也購并了最初屬于瑞典MySQLAB公司的開源MySQL關系數(shù)據(jù)庫項目。6.1.1開源技術的商業(yè)支援IBM、Oracle（甲骨文）以及其他公司都在將他們所擁有的大型關系型數(shù)據(jù)庫商業(yè)化。關系型數(shù)據(jù)庫使數(shù)據(jù)存儲在自定義表中，再通過一個密碼進行訪問。例如，一個雇員可以通過一個雇員編號認定，然后該編號就會與包含該雇員信息的其他字段相聯(lián)系——她的名字、地址、雇用日期及職位等。本來這樣的結(jié)構化數(shù)據(jù)庫還是可以適用的，直到公司不得不解決大量的非結(jié)構化數(shù)據(jù)。比如谷歌必須處理海量網(wǎng)頁以及這些網(wǎng)頁鏈接之間的關系，而Facebook必須應付社交圖譜數(shù)據(jù)。社交圖譜是其社交網(wǎng)站上人與人之間關系的數(shù)字表示——社交圖譜上每個點末端連接所有非結(jié)構化數(shù)據(jù)，例如照片、信息、個人檔案等。因此，這些公司也想利用低成本商用硬件。6.1.1開源技術的商業(yè)支援于是，像谷歌、雅虎、臉書以及其他這樣的公司開發(fā)出各自的解決方案，以存儲和處理大量的數(shù)據(jù)。正如UNIX的開源版本和甲骨文的數(shù)據(jù)庫以Linux和MySQL這樣的形式應運而生一樣，大數(shù)據(jù)世界里有許多類似的事物在不斷涌現(xiàn)。6.1.1開源技術的商業(yè)支援ApacheHadoop是一個開源分布式計算平臺，通過Hadoop分布式文件系統(tǒng)HDFS（HadoopDistributedFileSystem）存儲大量數(shù)據(jù)，再通過名為MapReduce的編程模型將這些數(shù)據(jù)的操作分成小片段。ApacheHadoop源自谷歌的原始創(chuàng)建技術，隨后，開發(fā)了一系列圍繞Hadoop的開源技術。ApacheHive提供數(shù)據(jù)倉庫功能，包括數(shù)據(jù)抽取、轉(zhuǎn)換、裝載（ETL），即將數(shù)據(jù)從各種來源中抽取出來，再實行轉(zhuǎn)換以滿足操作需要（包括確保數(shù)據(jù)質(zhì)量），然后裝載到目標數(shù)據(jù)庫。ApacheHBase則提供處于Hadoop頂部的海量結(jié)構化表的實時讀寫訪問功能，它仿照了谷歌的BigTable。同時，ApacheCassandra通過復制數(shù)據(jù)來提供容錯數(shù)據(jù)存儲功能。6.1.1開源技術的商業(yè)支援在過去，這些功能通常只能從商業(yè)軟件供應商處依靠專門的硬件獲取。開源大數(shù)據(jù)技術正在使數(shù)據(jù)存儲和處理能力——這些本來只有像谷歌或其他商用運營商之類的公司才具備的能力，在商用硬件上也得到了應用。這樣就降低了使用大數(shù)據(jù)的先期投入，并且具備了使大數(shù)據(jù)接觸到更多潛在用戶的潛力。6.1.1開源技術的商業(yè)支援開源軟件在開始使用時是免費的，這使其對大多數(shù)人頗具吸引力，從而使一些商用運營商采用免費增值的商業(yè)模式參與到競爭當中。產(chǎn)品在個人使用或有限數(shù)據(jù)的前提下是免費的，但顧客需要在之后為部分或大量數(shù)據(jù)的使用付費。久而久之，采用開源技術的這些企業(yè)往往需要商業(yè)支援，一如當初使用Linux碰到的情形。像Cloudera、HortonWorks及MapR這樣的公司在為Hadoop解決這種需要的同時，類似DataStax的公司也在為非關系型數(shù)據(jù)庫（cassandra）做著同樣的事情，LucidWorks之于ApacheLucerne也是如此（后者是一種開源搜索解決方案，用于索引并搜索大量網(wǎng)頁或文件）。大數(shù)據(jù)的技術架構6.1.26.1.2大數(shù)據(jù)的技術架構要容納數(shù)據(jù)本身，IT基礎架構必須能夠以經(jīng)濟的方式存儲比以往更大量、類型更多的數(shù)據(jù)。此外，還必須能適應數(shù)據(jù)變化的速度。由于數(shù)量如此大的數(shù)據(jù)難以在當今的網(wǎng)絡連接條件下快速移動，因此，大數(shù)據(jù)基礎架構必須分布計算能力，以便能在接近用戶的位置進行數(shù)據(jù)分析，減少跨越網(wǎng)絡所引起的延遲。企業(yè)逐漸認識到必須在數(shù)據(jù)駐留的位置進行分析，分布這類計算能力，以便為分析工具提供實時響應將帶來的挑戰(zhàn)?？紤]到數(shù)據(jù)速度和數(shù)據(jù)量，移動數(shù)據(jù)進行處理是不現(xiàn)實的，相反，計算和分析工具可能會移到數(shù)據(jù)附近。而且，云計算模式對大數(shù)據(jù)的成功至關重要。云模型在從大數(shù)據(jù)中提取商業(yè)價值的同時也能為企業(yè)提供一種靈活的選擇，以實現(xiàn)大數(shù)據(jù)分析所需的效率、可擴展性、數(shù)據(jù)便攜性和經(jīng)濟性。6.1.2大數(shù)據(jù)的技術架構僅僅存儲和提供數(shù)據(jù)還不夠，必須以新的方式合成、分析和關聯(lián)數(shù)據(jù)，才能提供商業(yè)價值。部分大數(shù)據(jù)方法要求處理未經(jīng)建模的數(shù)據(jù)，因此，可以對毫不相干的數(shù)據(jù)源進行不同類型數(shù)據(jù)的比較和模式匹配。這使得大數(shù)據(jù)分析能以新視角挖掘企業(yè)傳統(tǒng)數(shù)據(jù)，并帶來傳統(tǒng)上

未曾分析過的數(shù)據(jù)洞察力。基于上述考慮構建的適合大數(shù)據(jù)的4層堆棧

式技術架構（見圖）。圖6-24層堆棧式大數(shù)據(jù)技術架構6.1.2大數(shù)據(jù)的技術架構（1）基礎層：第一層作為整個大數(shù)據(jù)技術架構基礎的最底層，也是基礎層。要實現(xiàn)大數(shù)據(jù)規(guī)模的應用，企業(yè)需要一個高度自動化的、可橫向擴展的存儲和計算平臺。這個基礎設施需要從以前的存儲孤島發(fā)展為具有共享能力的高容量存儲池。容量、性能和吞吐量必須可以線性擴展。云模型鼓勵訪問數(shù)據(jù)并提供彈性資源池來應對大規(guī)模問題，解決了如何存儲大量數(shù)據(jù)，以及如何積聚所需的計算資源來操作數(shù)據(jù)的問題。在云中，數(shù)據(jù)跨多個節(jié)點調(diào)配和分布，使得數(shù)據(jù)更接近需要它的用戶，從而縮短響應時間和提高生產(chǎn)率。6.1.2大數(shù)據(jù)的技術架構（2）管理層：要支持在多源數(shù)據(jù)上做深層次的分析，大數(shù)據(jù)技術架構中需要一個管理平臺，使結(jié)構化和非結(jié)構化數(shù)據(jù)管理融為一體，具備實時傳送和查詢、計算功能。本層既包括數(shù)據(jù)的存儲和管理，也涉及數(shù)據(jù)的計算。并行化和分布式是大數(shù)據(jù)管理平臺所必須考慮的要素。（3）分析層：大數(shù)據(jù)應用需要大數(shù)據(jù)分析。分析層提供基于統(tǒng)計學的數(shù)據(jù)挖掘和機器學習算法，用于分析和解釋數(shù)據(jù)集，幫助企業(yè)獲得對數(shù)據(jù)價值深入的領悟?？蓴U展性強、使用靈活的大數(shù)據(jù)分析平臺更可成為數(shù)據(jù)科學家的利器，起到事半功倍的效果。6.1.2大數(shù)據(jù)的技術架構（4）應用層：大數(shù)據(jù)的價值體現(xiàn)在幫助企業(yè)進行決策和為終端用戶提供服務的應用。不同的新型商業(yè)需求驅(qū)動了大數(shù)據(jù)的應用。另一方面，大數(shù)據(jù)應用為企業(yè)提供的競爭優(yōu)勢使得企業(yè)更加重視大數(shù)據(jù)的價值。新型大數(shù)據(jù)應用對大數(shù)據(jù)技術不斷提出新的要求，大數(shù)據(jù)技術也因此在不斷地發(fā)展變化中日趨成熟。Hadoop數(shù)據(jù)處理基礎6.1.36.1.3Hadoop數(shù)據(jù)處理基礎在傳統(tǒng)的數(shù)據(jù)存儲、處理平臺中，需要將數(shù)據(jù)從CRM、ERP等系統(tǒng)中，通過ELT（Extract/Load/Transform，抽取/加載/轉(zhuǎn)換）工具提取出來，并轉(zhuǎn)換為容易使用的形式，再導入像數(shù)據(jù)倉庫和RDBMS等專用于分析的數(shù)據(jù)庫中。這樣的工作通常會按照計劃，以每天或者每周這樣的周期來進行。然后，為了讓經(jīng)營策劃等部門中的商務分析師能夠通過數(shù)據(jù)倉庫用其中經(jīng)正則化處理的數(shù)據(jù)輸出固定格式的報表，并讓管理層能夠?qū)I(yè)績進行管理和對目標完成情況進行查詢，就需要提供一個“管理指標板”，將多張數(shù)據(jù)表和圖表整合顯示在一個畫面上。6.1.3Hadoop數(shù)據(jù)處理基礎當管理的數(shù)據(jù)超過一定規(guī)模時，要完成這一系列工作，除了數(shù)據(jù)倉庫之外，一般還需要使用如SAP的BusinessObjects、IBM的Cognos、Oracle的OracleBI等商業(yè)智能工具。用這些現(xiàn)有的平臺很難處理具備3V特征的大數(shù)據(jù)，即便能夠處理，在性能方面也很難期望能有良好的表現(xiàn)。首先，隨著數(shù)據(jù)量的增加，數(shù)據(jù)倉庫所帶來的負荷也會越來越大，數(shù)據(jù)裝載的時間和查詢的性能都會惡化。其次，企業(yè)目前所管理的數(shù)據(jù)都是如CRM、ERP、財務系統(tǒng)等產(chǎn)生的客戶數(shù)據(jù)、銷售數(shù)據(jù)等結(jié)構化數(shù)據(jù)，而現(xiàn)有的平臺在設計時并沒有考慮到由社交媒體、傳感器網(wǎng)絡等產(chǎn)生的非結(jié)構化數(shù)據(jù)。6.1.3Hadoop數(shù)據(jù)處理基礎因此，對這些時時刻刻都在產(chǎn)生的非結(jié)構化數(shù)據(jù)進行實時分析，并從中獲取有意義的觀點，是十分困難的。由此可見，為了應對大數(shù)據(jù)時代，需要從根本上重新考慮用于數(shù)據(jù)存儲和處理的平臺。6.1.3Hadoop數(shù)據(jù)處理基礎1.Hadoop的由來Hadoop是一個能夠與當前商用硬件兼容，用于存儲與分析海量數(shù)據(jù)的，對大規(guī)模數(shù)據(jù)進行分布式處理的一種開源軟件技術（框架）。特別是處理大數(shù)據(jù)時代的非結(jié)構化數(shù)據(jù)時，Hadoop在性能和成本方面都具有優(yōu)勢，而且通過橫向擴展進行擴容也相對容易，因此備受關注。Hadoop是最受歡迎的在因特網(wǎng)上對搜索關鍵字進行內(nèi)容分類的工具，但它也可以解決許多要求極大伸縮性的問題。事實上，它被公認為當代大數(shù)據(jù)解決方案的工業(yè)平臺。Hadoop可以作為ETL引擎與分析引擎來處理大量的結(jié)構化、半結(jié)構化與非結(jié)構化數(shù)據(jù)。從分析的角度來看，Hadoop實現(xiàn)了MapReduce處理框架，圖6-3描述了Hadoop的某些特征。6.1.3Hadoop數(shù)據(jù)處理基礎圖6-3Hadoop是一個多功能的

系統(tǒng)架構，它可以提供數(shù)據(jù)存

儲與處理功能6.1.3Hadoop數(shù)據(jù)處理基礎Hadoop的基礎是美國Google公司于2004年發(fā)表的一篇關于大規(guī)模數(shù)據(jù)分布式處理的題為“MapReduce：大集群上的簡單數(shù)據(jù)處理”的論文。Hadoop由ApacheSoftwareFoundation公司于2005年秋天作為Lucene的子項目Nutch的一部分正式引入。它受到最先由GoogleLab開發(fā)的Map/Reduce和GoogleFileSystem（GFS）的啟發(fā)。2006年3月份，Map/Reduce和NutchDistributedFileSystem（NDFS）分別被納入稱為Hadoop的項目中。6.1.3Hadoop數(shù)據(jù)處理基礎MapReduce指的是一種分布式處理的方法，而Hadoop則是將MapReduce通過開源方式進行實現(xiàn)的框架（Framework）的名稱。造成這個局面的原因在于，Google在論文中公開的僅限于處理方法，而并沒有公開程序本身。也就是說，提到MapReduce，指的只是一種處理方法，而對其實現(xiàn)的形式并非只有Hadoop一種。反過來說，提到Hadoop，則指的是一種基于Apache授權協(xié)議，以開源形式發(fā)布的軟件程序。Hadoop原本是由三大部分組成的，即用于分布式存儲大容量文件的HDFS（HadoopDistributedFileSystem）分布式文件系統(tǒng)，用于對大量數(shù)據(jù)進行高效分布式處理的HadoopMapReduce框架，以及超大型數(shù)據(jù)表HBase。這些部分與Google的基礎技術相對應（見圖6-4）。6.1.3Hadoop數(shù)據(jù)處理基礎圖6-4Google與開源基礎技術的對應關系6.1.3Hadoop數(shù)據(jù)處理基礎從數(shù)據(jù)處理的角度來看，HadoopMapReduce是其中最重要的部分。HadoopMapReduce并非用于配備高性能CPU和磁盤的計算機，而是一種工作在由多臺通用型計算機組成的集群上的，對大規(guī)模數(shù)據(jù)進行分布式處理的框架。在Hadoop中，是將應用程序細分為在集群中任意節(jié)點上都可執(zhí)行的成百上千個工作負載，并分配給多個節(jié)點來執(zhí)行。然后，通過對各節(jié)點瞬間返回的信息進行重組，得出最終的回答。雖然存在其他功能類似的程序，但Hadoop依靠其處理的高速性脫穎而出。6.1.3Hadoop數(shù)據(jù)處理基礎對Hadoop的運用，最早是雅虎、臉書、推特、AOL、Netflix等網(wǎng)絡公司先開始試水的。然而現(xiàn)在，其應用領域已經(jīng)突破了行業(yè)的界限，如摩根大通、美國銀行、VISA等在內(nèi)的金融公司，以及諾基亞、三星、GE等制造業(yè)公司，沃爾瑪、迪士尼等零售業(yè)公司，甚至是中國移動等通信業(yè)公司。與此同時，最早由HDFS、HadoopMapReduce、HBase這三個組件所組成的軟件架構，現(xiàn)在也衍生出了多個子項目，其范圍也隨之逐步擴大。6.1.3Hadoop數(shù)據(jù)處理基礎2.Hadoop的優(yōu)勢Hadoop的一大優(yōu)勢是，過去由于成本、處理時間的限制而不得不放棄的對大量非結(jié)構化數(shù)據(jù)的處理，現(xiàn)在則成為可能。也就是說，由于Hadoop集群的規(guī)?？梢院苋菀椎財U展到PB甚至是EB級別，因此，企業(yè)里的數(shù)據(jù)分析師和市場營銷人員過去只能依賴抽樣數(shù)據(jù)來進行分析，而現(xiàn)在則可以將分析對象擴展到全部數(shù)據(jù)的范圍了。而且，由于處理速度比過去有了飛躍性的提升，現(xiàn)在我們可以進行若干次重復的分析，也可以用不同的查詢來進行測試，從而有可能獲得過去無法獲得的更有價值的信息。6.1.3Hadoop數(shù)據(jù)處理基礎Hadoop是一個能夠?qū)Υ罅繑?shù)據(jù)進行分布式處理的軟件框架。但是Hadoop是以一種可靠、高效、可伸縮的方式進行處理的。Hadoop是可靠的，因為它假設計算元素和存儲會失敗，因此它維護多個工作數(shù)據(jù)副本，確保能夠針對失敗的節(jié)點重新分布處理。Hadoop是高效的，因為它以并行的方式工作，通過并行處理加快處理速度。Hadoop還是可伸縮的，能夠處理PB級數(shù)據(jù)。此外，Hadoop依賴于社區(qū)服務器，因此它的成本比較低，任何人都可以使用。6.1.3Hadoop數(shù)據(jù)處理基礎Hadoop是一個能夠讓用戶輕松架構和使用的分布式計算平臺。用戶可以輕松地在Hadoop上開發(fā)和運行處理海量數(shù)據(jù)的應用程序。它主要有以下幾個優(yōu)點：（1）高可靠性。Hadoop按位存儲和處理數(shù)據(jù)的能力值得人們信賴。（2）高擴展性。Hadoop是在可用的計算機集簇間分配數(shù)據(jù)并完成計算任務的，這些集簇可以方便地擴展到數(shù)以千計的節(jié)點中。（3）高效性。Hadoop能夠在節(jié)點之間動態(tài)地移動數(shù)據(jù)，并保證各個節(jié)點的動態(tài)平衡，因此處理速度非?？?。（4）高容錯性。Hadoop能夠自動保存數(shù)據(jù)的多個副本，并且能夠自動將失敗的任務重新分配。6.1.3Hadoop數(shù)據(jù)處理基礎Hadoop帶有用Java語言編寫的框架，因此運行在Linux平臺上是非常理想的。Hadoop上的應用程序也可以使用其他語言編寫，比如C++。6.1.3Hadoop數(shù)據(jù)處理基礎3.Hadoop的發(fā)行版本Hadoop軟件目前依然在不斷引入先進的功能，處于持續(xù)開發(fā)的過程中。因此，如果想要享受其先進性所帶來的新功能和性能提升等好處，在公司內(nèi)部就需要具備相應的技術實力。對于擁有眾多先進技術人員的一部分大型系統(tǒng)集成公司和慣于使用開源軟件的互聯(lián)網(wǎng)公司來說，應該可以滿足這樣的條件。相對地，對于一般企業(yè)來說，要運用Hadoop這樣的開源軟件，還存在比較高的門檻。企業(yè)對于軟件的要求，不僅在于其高性能，還包括可靠性、穩(wěn)定性、安全性等因素。然而，Hadoop是可以免費獲取的軟件，一般公司在搭建集群環(huán)境的時候，需要自行對上述因素做出擔保，難度確實很大。6.1.3Hadoop數(shù)據(jù)處理基礎于是，為了解決這個問題，Hadoop也推出了發(fā)行版本。所謂發(fā)行版本（Distribution），和同為開源軟件的Linux的情況類似，是一種為改善開源社區(qū)所開發(fā)的軟件的易用性而提供的一種軟件包服務（見圖6-5），軟件包中通常包括安裝工具，以及捆綁事先驗證過的一些周邊軟件。最先開始提供Hadoop商用發(fā)行版的是Cloudera公司。如今，Cloudera已經(jīng)成為名副其實的Hadoop商用發(fā)行版頭牌廠商。6.1.3Hadoop數(shù)據(jù)處理基礎圖6-5Cloudera公司的Hadoop發(fā)行版6.1.3Hadoop數(shù)據(jù)處理基礎4.Hadoop與NoSQL作為支撐大數(shù)據(jù)的基礎技術，能和Hadoop一樣受到越來越多關注的，就是NoSQL數(shù)據(jù)庫了。在大數(shù)據(jù)處理的基礎平臺中，需要由Hadoop和NoSQL數(shù)據(jù)庫來擔任核心角色。Hadoop已經(jīng)催生了多個子項目，其中包括基于Hadoop的數(shù)據(jù)倉庫Hive和數(shù)據(jù)挖掘庫Mahout等，通過運用這些工具，僅僅在Hadoop的環(huán)境中就可以完成數(shù)據(jù)分析的所有工作。6.1.3Hadoop數(shù)據(jù)處理基礎然而，對于大多數(shù)企業(yè)來說，要拋棄已經(jīng)習慣的現(xiàn)有平臺，從零開始搭建一個新的平臺來進行數(shù)據(jù)分析，顯然是不現(xiàn)實的。因此，有些數(shù)據(jù)倉庫廠商提出這樣一種方案，用Hadoop將數(shù)據(jù)處理成現(xiàn)有數(shù)據(jù)倉庫能夠進行存儲的形式（即用作前處理），在裝載數(shù)據(jù)之后再使用傳統(tǒng)的商業(yè)智能工具來進行分析。Hadoop和NoSQL數(shù)據(jù)庫，是在現(xiàn)有關系型數(shù)據(jù)庫和SQL等數(shù)據(jù)處理技術很難有效處理非結(jié)構化數(shù)據(jù)這一背景下，由谷歌、亞馬遜、臉書等企業(yè)因自身迫切的需求而開發(fā)的。因此，作為一般企業(yè)不必非要推翻和替換現(xiàn)有的技術，在銷售數(shù)據(jù)和客戶數(shù)據(jù)等結(jié)構化數(shù)據(jù)的存儲和處理上，只要使用傳統(tǒng)的關系型數(shù)據(jù)庫和數(shù)據(jù)倉庫就可以了。6.1.3Hadoop數(shù)據(jù)處理基礎由于Hadoop和NoSQL數(shù)據(jù)庫是開源的，因此和商用軟件相比，其軟件授權費用十分低廉，但另一方面，想招募到精通這些技術的人才卻可能需要付出很高的成本。處理工作量6.1.46.1.4處理工作量大數(shù)據(jù)的處理工作量被定義為一定時間內(nèi)處理數(shù)據(jù)的性質(zhì)與數(shù)量。處理工作量主要分為批處理和事務兩種類型。（1）批處理型。也稱為脫機處理，這種方式通常成批地處理數(shù)據(jù)，因而會導致較大的延遲。通常我們采用批處理完成大數(shù)據(jù)有序的讀/寫操作，這些讀/寫查詢通常是成批的。這種情形下的查詢一般涉及多種連接，非常復雜。聯(lián)機分析處理（OLAP）系統(tǒng)通常采用批處理模式處理數(shù)據(jù)。商務智能與分析需要對大量的數(shù)據(jù)進行讀操作，因而一般使用批處理模式，批量地進行讀/寫操作，以插入、選擇、更新與刪除數(shù)據(jù)。批處理型的工作量包括大量數(shù)據(jù)的成批讀/寫操作，并且會涉及多種連接，從而導致較大的延遲。6.1.4處理工作量（2）事務型。也稱為在線處理，這種處理方式通過無延遲的交互式處理使得整個回應延遲很小。事務型處理一般適用于少量數(shù)據(jù)的隨機讀/寫操作。聯(lián)機事務處理（OLTP）系統(tǒng)與操作系統(tǒng)的寫操作比較密集，是典型的事務型處理系統(tǒng)，盡管它們通常讀操作與寫操作混雜著進行，但寫操作相對讀操作還是密集許多的。事務型處理適用于僅含少量連接的隨機讀/寫需求，企業(yè)的事務處理對實時性要求較高，因此一般采用回應延遲小、數(shù)據(jù)量小的事務型處理方式。相比于批處理型，事務型處理含有少量的連接操作，回應延遲也更小。批處理模式6.1.56.1.5批處理模式在批處理模式中，數(shù)據(jù)總是成批地脫機處理，響應時長從幾分鐘到幾小時不等。在這種情況下，數(shù)據(jù)被處理前必須在磁盤上保存。批處理模式適用于龐大的數(shù)據(jù)集，無論這個數(shù)據(jù)集是單個的還是由幾個數(shù)據(jù)集組合而成的，該模式可以本質(zhì)上解決大數(shù)據(jù)數(shù)據(jù)量大和數(shù)據(jù)特性不同的問題。批處理是大數(shù)據(jù)處理的主要方式，相較于實時模式，它比較簡單，易于建立，開銷也比較小。像商務智能、預測性分析與規(guī)范性分析、ETL操作，一般都采用批處理模式。6.1.5批處理模式1.MapReduce批處理MapReduce是一種廣泛用于實現(xiàn)批處理的架構，它采用“分治”的原則，把一個大的問題分成可以被分別解決的小問題的集合，擁有內(nèi)部容錯性與冗余，因而具有很高的可擴展性與可靠性。MapReduce結(jié)合了分布式數(shù)據(jù)處理與并行數(shù)據(jù)處理的原理，并且使用商業(yè)硬件集群并行處理龐大的數(shù)據(jù)集，是一個基于批處理模式的數(shù)據(jù)處理引擎。MapReduce不對數(shù)據(jù)的模式作要求，因此它可以用于處理無模式的數(shù)據(jù)集。在MapReduce中，一個龐大的數(shù)據(jù)集被分為多個較小的數(shù)據(jù)集，分別在獨立的設備上并行處理，最后再把每個處理結(jié)果相結(jié)合得出最終結(jié)果。6.1.5批處理模式MapReduce是2000年年初谷歌的一項研究課題發(fā)表的，它不需要低延遲，因此一般僅支持批處理模式。MapReduce處理引擎與傳統(tǒng)的數(shù)據(jù)處理模式的工作機制有些不同。在傳統(tǒng)的數(shù)據(jù)處理模式中，數(shù)據(jù)由存儲節(jié)點發(fā)送到處理節(jié)點后才能被處理，這種方式在數(shù)據(jù)集較小的時候表現(xiàn)良好，但是數(shù)據(jù)集較大時發(fā)送數(shù)據(jù)將導致更大的開銷。而MapReduce是把數(shù)據(jù)處理算法發(fā)送到各個存儲節(jié)點，數(shù)據(jù)在這些節(jié)點上被并行地處理，這種方式可以消除發(fā)送數(shù)據(jù)的時間開銷。由于并行處理小規(guī)模數(shù)據(jù)速度更快，MapReduce不但可以節(jié)約網(wǎng)絡帶寬的開銷，更能大量節(jié)約處理大規(guī)模數(shù)據(jù)的時間開銷。6.1.5批處理模式2.Map和Reduce任務一次MapReduce處理引擎的運行被稱為MapReduce作業(yè)，它由映射（Map）和歸約（Reduce）兩部分任務組成，這兩部分任務又被分為多個階段。其中映射任務被分為映射（map）、合并（combine）和分區(qū)（partition）三個階段，合并階段是可選的；歸約任務被分為洗牌和排序（shuffleandsort）與歸約（reduce）兩個階段。6.1.5批處理模式（1）映射。MapReduce的第一個階段稱為映射。映射階段首先把大的數(shù)據(jù)文件分割成多個小數(shù)據(jù)文件。每個較小的數(shù)據(jù)文件的每條記錄都被解析為一組鍵-值對，通常鍵表示其對應記錄的序號，值則表示該記錄的實際值。通常每個小數(shù)據(jù)文件由多組鍵-值對組成，這些鍵-值對將會作為輸入由一個映射模塊處理，映射階段的邏輯由用戶決定，其中一個映射模塊僅處理一個小數(shù)據(jù)文件，且僅執(zhí)行一次。每組鍵-值對會按用戶自定義邏輯被映射為一組新的鍵-值對作為輸出。輸出的鍵可以與輸入的鍵相同，可以是由輸入值得出的一組字符串，還可以是用戶自定義的有序?qū)ο?。同樣，輸出的值也可與輸入值相同，可以是由輸入值得到的一組字符串，還可以是用戶自定義的有序?qū)ο蟆?.1.5批處理模式在這些輸出的鍵-值對中，可以存在多組鍵-值對的鍵相同的情況。另外要注意一點，在映射過程中會發(fā)生過濾與復用。過濾是指對于一個輸入的鍵-值對，映射可能不會產(chǎn)生任何輸出鍵-值對；而復用是指某組輸入鍵-值對對應多組輸出鍵-值對。映射階段的數(shù)據(jù)變化如圖6-6所示。圖6-6數(shù)據(jù)在映射階段的變化6.1.5批處理模式（2）合并。在MapReduce模型中，映射任務與歸約任務分別在不同的節(jié)點上進行，而映射模塊的輸出需要被送到歸約模塊處理，這就要求把數(shù)據(jù)由映射任務節(jié)點傳輸?shù)綒w約任務節(jié)點，這個過程往往會消耗大量的帶寬，并直接導致處理延時。因此就要對大量的鍵-值對進行合并，以減少這些消耗。在大數(shù)據(jù)處理中，節(jié)點傳輸過程所花費的時間往往大于真正處理數(shù)據(jù)的時間。MapReduce模型提出了一個可選的合并模塊。在映射模塊把多組鍵-值對輸入合并模塊之前，已經(jīng)將這些鍵-值對按鍵進行排序，將對應同一鍵的多條記錄變?yōu)橐粋€鍵對應一組值，合并模塊則將每個鍵對應的值組進行合并，最終輸出僅為一條鍵-值對記錄。圖6-7描述了數(shù)據(jù)由映射階段到合并階段的變化。6.1.5批處理模式圖6-7數(shù)據(jù)在合并階段的變化6.1.5批處理模式由此可見，合并模塊本質(zhì)上還是一種歸約模塊，另外，歸約模塊還可被作為用戶自定義模塊使用。最后值得一提的是，合并模塊僅僅是一個可選的優(yōu)化模塊，在MapReduce模型中不是必備的。比如運用合并模塊我們可以得出最大值或最小值，但無法得出所有數(shù)據(jù)的平均值，畢竟合并模塊的數(shù)據(jù)僅僅是所有數(shù)據(jù)的一個子集。6.1.5批處理模式（3）分區(qū)。在這個階段，當使用多個歸約模塊時，MapReduce模型就需要把映射模塊或合并模塊（如果該MapReduce引擎指明調(diào)用合并功能）的輸出分配給各個歸約模塊。在此我們把分配到每個歸約模塊的數(shù)據(jù)叫做一個分區(qū)，也就是說，分區(qū)數(shù)與歸約模塊數(shù)是

相等的。圖描述了數(shù)據(jù)在分區(qū)階段

的變化。圖6-8數(shù)據(jù)在分區(qū)階段的變化6.1.5批處理模式盡管一個分區(qū)包含很多條記錄，但是對應同一鍵的記錄必須被分在同一個分區(qū)，在此基礎上，MapReduce模型會盡量保證隨機公平地把數(shù)據(jù)分配到各個歸約模塊當中。由于上述分區(qū)模塊的特性，會導致分配到各個歸約模塊的數(shù)據(jù)量有差異，甚至分配給某個歸約模塊的數(shù)據(jù)量會遠遠超過其他的。不均等的工作量將造成各個歸約模塊工作結(jié)束時間不同，這樣最后總共消耗的時間將會大于絕對均等的分配方式。要緩解這個問題，就只能依靠優(yōu)化分區(qū)模塊的邏輯來實現(xiàn)了。分區(qū)模塊是映射任務的最后一個階段，它的輸出為記錄對應歸約模塊的索引號。6.1.5批處理模式（4）洗牌和排序。洗牌包括由分區(qū)模塊將數(shù)據(jù)傳輸?shù)綒w約模塊的整個過程，是歸約任務的第一個階段。由分區(qū)模塊傳輸來的數(shù)據(jù)可能存在多條記錄對應同一個鍵。這個模塊將把對應同一個鍵的記錄進行組合，形成一個唯一鍵對應一組值的鍵-值對列表。隨后該模塊對所有的鍵-值對進行排序。組合與排序的方式在此可由用戶自定義。整個階段

的數(shù)據(jù)變化如圖所示。圖6-9數(shù)據(jù)在洗牌和排序階段的變化6.1.5批處理模式（5）歸約。這是歸約任務的最后一個階段，該模塊的邏輯由用戶自定義，它可能對輸入的記錄進行進一步分析歸納，也可能對輸入不作任何改變。在任何情形下，這個模塊都在處理當條記錄的同時將其他處理過的記錄輸出。歸約模塊輸出的鍵-值對中，鍵可以與輸入鍵相同，也可以是由輸入值得到的字符串，或其他用戶自定義的有序?qū)ο?，值可以與輸入值相同，也可以是由輸入值得到的字符串，或其他用戶自定義的有序?qū)ο?。值得注意的是，映射模塊輸出的鍵-值對類型需要與歸約或合并模塊的輸入鍵-值對類型相對應。另外，歸約模塊也會進行過濾與復用，每個歸約模塊輸出的記錄組成單獨一個文件，也就是說被分配到每個歸約模塊的分區(qū)都將合并成一個文件，其數(shù)據(jù)變化如圖6-10所示。6.1.5批處理模式圖6-10數(shù)據(jù)在歸約階段的變化6.1.5批處理模式歸約模塊的數(shù)目是由用戶定義的，當然，類似對數(shù)據(jù)記錄進行過濾篩選，一個MapReduce作業(yè)可以不使用歸約模塊。6.1.5批處理模式3.MapReduce的簡單實例圖6-11展示了一個MapReduce作業(yè)的簡單實例，其主要步驟如下：圖6-11MapReduce實例6.1.5批處理模式（1）輸入文件sales.txt被分為兩個較小的數(shù)據(jù)文件：文件1，文件2。（2）文件1、文件2分別在節(jié)點A、節(jié)點B上，提取相關紀錄并完成映射任務。該任務的輸出為多組鍵-值對，鍵為產(chǎn)品名稱，值為產(chǎn)品數(shù)量。（3）該作業(yè)的合并模塊將對應同一產(chǎn)品的數(shù)量相加，得出每種產(chǎn)品的總量。（4）由于該作業(yè)僅使用一個歸約模塊，因而不需要對數(shù)據(jù)進行分區(qū)。（5）節(jié)點A、B的處理結(jié)果被送到節(jié)點C，在節(jié)點C上首先對這些記錄進行洗牌和排序。（6）排序后的數(shù)據(jù)輸出為一個產(chǎn)品名，對應一組產(chǎn)品數(shù)量。（7）最后該作業(yè)的歸約模塊的邏輯與其合并模塊相同，將每種產(chǎn)品的數(shù)量相加，得到每種產(chǎn)品的總量。6.1.5批處理模式4.理解MapReduce算法與傳統(tǒng)的編程模式不同，MapReduce編程遵循一套特定的模式。那么如何在該模式上設計算法呢？首先我們要對算法的設計原則進行探索。前文已經(jīng)提到，MapReduce采用了“分治”的原則，在MapReduce中如何理解“分治”是極為重要的，“分治”常用的幾種方式時：任務并行：任務并行指的是將一個任務分為多個子任務在不同節(jié)點上并行進行，通常并行的子任務采用不同的算法，每個子任務的輸入數(shù)據(jù)可以相同也可不同，最后多個子任務的結(jié)果組成最終結(jié)果。數(shù)據(jù)并行：數(shù)據(jù)并行指的是將一個數(shù)據(jù)集分為多個子數(shù)據(jù)集在多個節(jié)點上并行地處理，數(shù)據(jù)并行的多個節(jié)點采用同一算法，最后多個子數(shù)據(jù)集的處理結(jié)果組成最終結(jié)果。6.1.5批處理模式對于大數(shù)據(jù)應用環(huán)境，某些操作需要在一個數(shù)據(jù)單元上重復多次，比如，當一個數(shù)據(jù)集規(guī)模過大時，通常需要將其分為較小的數(shù)據(jù)集在不同節(jié)點進行處理。MapReduce為了滿足這種需求，采用分治中數(shù)據(jù)并行的方法，將大規(guī)模數(shù)據(jù)分成多個小數(shù)據(jù)塊，每個數(shù)據(jù)塊分別在不同的節(jié)點上進行映射處理，這些節(jié)點的映射函數(shù)邏輯都是相同的?，F(xiàn)今大部分傳統(tǒng)算法的編程原則是基于過程的，也就是說對數(shù)據(jù)的操作是有序的，后續(xù)的操作依賴于它之前的操作。而MapReduce將對數(shù)據(jù)的操作分為“映射”與“歸約”兩部分，它的映射任務與歸約任務是相互獨立的，甚至每個映射實例或歸約實例之間都是相互獨立的。6.1.5批處理模式在傳統(tǒng)編程模型中，函數(shù)簽名是沒有限制的。而MapReduce編程模型中，映射函數(shù)與歸約函數(shù)的函數(shù)簽名必須為鍵-值對這一形式，只有這樣才能實現(xiàn)映射函數(shù)與歸約函數(shù)之間的通信。另外，映射函數(shù)的邏輯依賴于數(shù)據(jù)記錄的解析方式，即依賴于數(shù)據(jù)集中邏輯數(shù)據(jù)單元的組織方式。例如，通常情況下文本文件中每一行代表一條記錄，然而一條記錄也可能由兩行或多行文本組成。對于歸約函數(shù)，基于它的輸入為單個鍵對應一組值的記錄，它的邏輯與映射函數(shù)的輸出密切相關，尤其是與它最終輸出什么鍵密切相關。值得一提的是，在某些應用場景下，例如文本提取，我們不需要使用歸約函數(shù)。6.1.5批處理模式總結(jié)一下，在設計MapReduce算法時，我們主要考慮以下幾點：盡可能使用簡單的算法邏輯，這樣才能采用同一函數(shù)邏輯處理某個數(shù)據(jù)集的不同部分，最終以某些方式將各部分的處理結(jié)果進行匯總。數(shù)據(jù)集可以被分布式地劃分在集群中，如此才能保證映射函數(shù)并行地處理各個子數(shù)據(jù)集。理解數(shù)據(jù)集的數(shù)據(jù)結(jié)構以保證選取有用的記錄。將算法邏輯分為映射部分與歸約部分，如此才能實現(xiàn)映射函數(shù)不依賴于整個數(shù)據(jù)集，畢竟它處理的僅僅是該數(shù)據(jù)集的一部分。保證映射函數(shù)的輸出是正確有效的，由于歸約函數(shù)的輸入為映射函數(shù)輸出的一部分，只有這樣才能保證整個算法的正確性。保證歸約函數(shù)的輸出是正確的，歸約函數(shù)的輸出則為整個MapReduce算法的輸出。SCV原則6.1.66.1.6SCV原則大數(shù)據(jù)處理遵循SCⅤ分布式數(shù)據(jù)處理基本原則，該原則對大數(shù)據(jù)處理施加的基本限制對實時模式處理有巨大的影響。6.1.6SCV原則SCV原則是，設計一個分布式數(shù)據(jù)處理系統(tǒng)時僅需滿是以下3項要求中的2項：（1）速度（Speed）。是指數(shù)據(jù)一旦生成后處理的快慢。通常實時模式的速度快于批處理模式，因此僅有實時模式會考慮該項性能，并且在此忽略獲取數(shù)據(jù)的時間消耗，專注于實際數(shù)據(jù)處理的時間消耗，例如生成數(shù)據(jù)統(tǒng)計信息時間或算法的執(zhí)行時間。（2）一致性（Consistency）。指處理結(jié)果的準確度與精度。如果處理結(jié)果的值接近于正確的值，并且二者有著相近的精度，則認為該大數(shù)據(jù)處理系統(tǒng)具有高一致性。高一致性系統(tǒng)通常會利用全部數(shù)據(jù)來保證其準確度與精度，而低一致性系統(tǒng)則采用采樣技術，僅保證精度在一個可接受的范圍，結(jié)果也相對不準確。6.1.6SCV原則（3）容量（Volume）。指系統(tǒng)能夠處理的數(shù)據(jù)量。大數(shù)據(jù)環(huán)境下，數(shù)據(jù)量的高速增長導致大量的數(shù)據(jù)需要以分布式的方式進行處理。要處理規(guī)模如此大的數(shù)據(jù)，數(shù)據(jù)處理系統(tǒng)無法同時保證速度與一致性。如圖所示，如果要保證數(shù)據(jù)處理系統(tǒng)的速度與

一致性，就不可能保證大容量，因為大量的

數(shù)據(jù)必然會減慢處理速度。圖6-12SCV原則維恩圖6.1.6SCV原則如果要保證高度一致地處理大容量數(shù)據(jù)，處理速度必然減慢。如果要高速處理大容量的數(shù)據(jù)，則無法保證系統(tǒng)的高一致性，畢竟處理大規(guī)模數(shù)據(jù)僅能依靠采樣來保證更快的速度。實現(xiàn)一個分布式數(shù)據(jù)處理系統(tǒng)，選擇SCV中的哪兩項特性主要以該系統(tǒng)分析環(huán)境的具體需求為依據(jù)。在大數(shù)據(jù)環(huán)境中，可能需要最大限度地保證數(shù)據(jù)規(guī)模來進行深入分析，例如模式識別，也可能需要對數(shù)據(jù)進行批處理以求進一步研究。因此，選擇容量還是速度或一致性值得慎重考慮。6.1.6SCV原則在數(shù)據(jù)處理中，實時處理需要保證數(shù)據(jù)不丟失，即對數(shù)據(jù)處理容量（V）需求大，因此大數(shù)據(jù)實時處理系統(tǒng)通常僅在速度（S）與一致性（C）中做權衡，實現(xiàn)S+V或C+V。實時大數(shù)據(jù)處理包括實時處理與近實時處理。數(shù)據(jù)一旦到達企業(yè)就需要被低延遲地處理。在實時模式下，數(shù)據(jù)剛到達就在內(nèi)存中進行處理，處理完畢再寫入磁盤供后續(xù)使用或存檔。而批處理模式恰與之相反，該種模式下數(shù)據(jù)首先被寫入磁盤，再被批量處理，從而將導致高延遲。實時處理模式6.1.76.1.7實時處理模式實時模式中，數(shù)據(jù)通常在寫入磁盤之前在內(nèi)存中進行處理，它的延遲由亞秒級到分鐘級不等。實時模式側(cè)重的是提高大數(shù)據(jù)處理的速度。在大數(shù)據(jù)處理中，實時處理由于其處理的數(shù)據(jù)既可能是連續(xù)（流式）的也可能是間歇（事件）的，因而也被稱作流式處理或事件處理。這些流式數(shù)據(jù)或事件數(shù)據(jù)通常規(guī)模都比較小，但源源不斷處理這樣的數(shù)據(jù)得到的結(jié)果將構成龐大的數(shù)據(jù)集。另外，交互模式也是實時模式的一種，該模式主要是基于查詢操作的。運營商務智能或分析通常在實時模式下進行。6.1.7實時處理模式實時模式分析大數(shù)據(jù)需要使用內(nèi)存設備（IMDG或IMDB），數(shù)據(jù)到達內(nèi)存時被即時處理，期間沒有硬盤I/O延遲。實時處理可能包括一些簡單的數(shù)據(jù)分析、復雜的算法執(zhí)行以及當檢測到某些度量發(fā)生變化時，對內(nèi)存數(shù)據(jù)進行更新。為了增強實時分析的能力，實時處理的數(shù)據(jù)可以與之前批處理的數(shù)據(jù)結(jié)果或與磁盤上存儲的非規(guī)范化數(shù)據(jù)相結(jié)合，磁盤上的數(shù)據(jù)均可傳輸?shù)絻?nèi)存中，這樣有助于實現(xiàn)更好的實時處理。除了處理新獲取的數(shù)據(jù)，實時模式還可以處理大量查詢請求以實現(xiàn)實時交互。在該種模式下，數(shù)據(jù)一旦被處理完畢，系統(tǒng)就將結(jié)果公布給感興趣的用戶，在此我們使用實時儀表板應用或Web應用將數(shù)據(jù)更新展示給用戶。6.1.7實時處理模式根據(jù)某些系統(tǒng)的需求，實時模式下處理過的數(shù)據(jù)和原始數(shù)據(jù)將被寫入磁盤供后續(xù)復雜的批量數(shù)據(jù)分析。圖6-13展示了典型的實時模式處理流程：圖6-13實時處理示例6.1.7實時處理模式（1）在數(shù)據(jù)傳輸引擎獲取流式數(shù)據(jù)。（2）數(shù)據(jù)同時被傳輸?shù)絻?nèi)存設備（a）與磁盤設備（b）。（3）數(shù)據(jù)處理引擎以實時模式處理存儲在內(nèi)存的數(shù)據(jù)。（4）處理結(jié)果被送到儀表板供操作分析。6.1.7