大數(shù)據(jù)處理系統(tǒng)架構(gòu)及技術(shù)大數(shù)據(jù)可通過許多方式來存儲、獲取、處理和分析。每個大數(shù)據(jù)來源都有不同的特征，包括數(shù)據(jù)的頻率、量、速度、類型和真實性。處理并存儲大數(shù)據(jù)時，會涉及到更多維度，比如治理、安全性和策略。選擇一種架構(gòu)并構(gòu)建合適的大數(shù)據(jù)解決方案極具挑戰(zhàn)，因為需要考慮非常多的因素。這個“大數(shù)據(jù)架構(gòu)和模式”系列提供了一種結(jié)構(gòu)化和基于模式的方法來簡化定義完整的大數(shù)據(jù)架構(gòu)的任務(wù)。因為評估一個業(yè)務(wù)場景是否存在大數(shù)據(jù)問題很重要，所以我們包含了一些線索來幫助確定哪些業(yè)務(wù)問題適合采用大數(shù)據(jù)解決方案。（一）從分類大數(shù)據(jù)到選擇大數(shù)據(jù)解決方案如果我們花時間研究過大數(shù)據(jù)解決方案，那么就一定知道它不是一個簡單的任務(wù)。我們首先介紹術(shù)語“大數(shù)據(jù)”所描述的數(shù)據(jù)類型。為了簡化各種大數(shù)據(jù)類型的復(fù)雜性，我們依據(jù)各種參數(shù)對大數(shù)據(jù)進行了分類，為任何大數(shù)據(jù)解決方案中涉及的各層和高級組件提供一個邏輯架構(gòu)。接下來，我們通過定義原子和復(fù)合分類模式，提出一種結(jié)構(gòu)來分類大數(shù)據(jù)業(yè)務(wù)問題。這些模式有助于確定要應(yīng)用的合適的解決方案模式。我們提供了來自各行各業(yè)的示例業(yè)務(wù)問題。（二）依據(jù)大數(shù)據(jù)類型對業(yè)務(wù)問題進行分類業(yè)務(wù)問題可分類為不同的大數(shù)據(jù)問題類型。以后，我們將使用此類型確定合適的分類模式（原子或復(fù)合）和合適的大數(shù)據(jù)解決方案。但第一步是將業(yè)務(wù)問題映射到它的大數(shù)據(jù)類型。下表列出了常見的業(yè)務(wù)問題并為每個問題分配了一種大數(shù)據(jù)類型。表3.1：不同類型的大數(shù)據(jù)業(yè)務(wù)問題業(yè)務(wù)問題大數(shù)據(jù)問題描述公用事業(yè)：預(yù)測功耗機器生成的數(shù)據(jù)公用事業(yè)公司推出了智慧儀表，按每小時或更短的間隔定期測量水、天然氣和電力的消耗。這些智慧儀表生成了需要分析的大量間隔數(shù)據(jù)。公用事業(yè)公司還運行著昂貴而又復(fù)雜的大型系統(tǒng)來發(fā)電。每個電網(wǎng)包含監(jiān)視電壓、電流、頻率和其他重要操作特征的復(fù)雜傳感器。要提高操作效率，該公司必須監(jiān)視傳感器所傳送的數(shù)據(jù)。大數(shù)據(jù)解決方案可以使用智慧儀表分析發(fā)電（供應(yīng)）和電力消耗（需求）數(shù)據(jù)。電信：客戶流失分析Web和社交數(shù)據(jù)交易數(shù)據(jù)電信運營商需要構(gòu)建詳細的客戶流失模型（包含社交媒體和交易數(shù)據(jù)，比如CDR），以跟上競爭形勢。流失模型的值取決于客戶屬性的質(zhì)量（客戶主數(shù)據(jù)，比如生日、性別、位置和收入）和客戶的社交行為。實現(xiàn)預(yù)測分析戰(zhàn)略的電信提供商可通過分析用戶的呼叫模式來管理和預(yù)測流失。市場營銷：情緒分析Web和社交數(shù)據(jù)營銷部門使用Twitter源來執(zhí)行情緒分析，以便確定用戶對公司及其產(chǎn)品或服務(wù)的評價，尤其是在一個新產(chǎn)品或版本發(fā)布之后。客戶情緒必須與客戶概要數(shù)據(jù)相集成，才能得到有意義的結(jié)果。依據(jù)客戶的人口統(tǒng)計特征，客戶反饋可能有所不同。客戶服務(wù)：呼叫監(jiān)視人類生成的IT部門正在依靠大數(shù)據(jù)解決方案來分析應(yīng)用程序日志，以便獲取可提高系統(tǒng)性能的洞察。來自各種應(yīng)用程序供應(yīng)商的日志文件具有不同的格式；必須將它們標準化，然后IT部門才能使用它們。零售：基于面部識別和社交媒體的個性化消息Web和社交數(shù)據(jù)生物識別零售商可結(jié)合使用面部識別技術(shù)和來自社交媒體的照片，根據(jù)購買行為和位置向客戶提供個性化的營銷信息。此功能對零售商忠誠度計劃具有很大的影響，但它具有嚴格的隱私限制。零售商需要在實現(xiàn)這些應(yīng)用程序之前進行適當?shù)碾[私披露。零售和營銷：移動數(shù)據(jù)和基于位置的目標機器生成的數(shù)據(jù)交易數(shù)據(jù)零售商可根據(jù)位置數(shù)據(jù)為客戶提供特定的促銷活動和優(yōu)惠券。解決方案通常旨在在用戶進入一個店鋪時檢測用戶的位置，或者通過GPS檢測用戶的位置。位置數(shù)據(jù)與來自社交網(wǎng)絡(luò)的客戶偏好數(shù)據(jù)相結(jié)合，使零售商能夠根據(jù)購買歷史記錄針對性地開展在線和店內(nèi)營銷活動。通知是通過移動應(yīng)用程序、SMS和電子郵件提供的。FSS、醫(yī)療保健：欺詐檢測機器生成的數(shù)據(jù)交易數(shù)據(jù)人類生成的欺詐管理可預(yù)測給定交易或客戶帳戶遇到欺詐的可能性。解決方案可實時分析事務(wù)，生成建議的立即執(zhí)行的措施，這對阻止第三方欺詐、第一方欺詐和對帳戶特權(quán)的蓄意濫用至關(guān)重要。解決方案通常旨在檢測和阻止多個行業(yè)的眾多欺詐和風險類型，其中包括：信用卡和借記卡欺詐存款帳戶欺詐技術(shù)欺詐壞賬醫(yī)療欺詐醫(yī)療補助計劃和醫(yī)療保險欺詐財產(chǎn)和災(zāi)害保險欺詐工傷賠償欺詐保險欺詐電信欺詐按類型對大數(shù)據(jù)問題分類，更容易看到每種數(shù)據(jù)的特征。這些特征可幫助我們了解如何獲取數(shù)據(jù)，如何將它處理為合適的格式，以及新數(shù)據(jù)出現(xiàn)的頻率。來自不同來源的數(shù)據(jù)具有不同的特征；例如，社交媒體數(shù)據(jù)包含不斷傳入的視頻、圖像和非結(jié)構(gòu)化文本（比如博客文章）。使用大數(shù)據(jù)類型對大數(shù)據(jù)特征進行分類。按特定方向分析大數(shù)據(jù)的特征會有所幫助，例如以下特征：數(shù)據(jù)如何收集、分析和處理。對數(shù)據(jù)進行分類后，就可以將它與合適的大數(shù)據(jù)模式匹配。分析類型對數(shù)據(jù)執(zhí)行實時分析還是批量分析。請仔細考慮分析類型的選擇，因為這會影響一些有關(guān)產(chǎn)品、工具、硬件、數(shù)據(jù)源和預(yù)期的數(shù)據(jù)頻率的其他決策。一些用例可能需要混合使用兩種類型：欺詐檢測、分析必須實時或近實時地完成。針對戰(zhàn)略性業(yè)務(wù)決策的趨勢分析，分析可采用批量模式。處理方法要應(yīng)用來處理數(shù)據(jù)的技術(shù)類型（比如預(yù)測、分析、臨時查詢和報告）。業(yè)務(wù)需求確定了合適的處理方法。可結(jié)合使用各種技術(shù)。處理方法的選擇，有助于識別要在您的大數(shù)據(jù)解決方案中使用的合適的工具和技術(shù)。數(shù)據(jù)頻率和大小—預(yù)計有多少數(shù)據(jù)和數(shù)據(jù)到達的頻率多高。知道頻率和大小，有助于確定存儲機制、存儲格式和所需的預(yù)處理工具。數(shù)據(jù)頻率和大小依賴于數(shù)據(jù)源。按需分析，與社交媒體數(shù)據(jù)一樣，實時、持續(xù)提供（天氣數(shù)據(jù)、交易數(shù)據(jù)時序。數(shù)據(jù)類型、要處理數(shù)據(jù)類型、交易、歷史、主數(shù)據(jù)等。知道數(shù)據(jù)類型，有助于將數(shù)據(jù)隔離在存儲中。內(nèi)容格式結(jié)構(gòu)化、非結(jié)構(gòu)化或半結(jié)構(gòu)化。格式確定了需要如何處理傳入的數(shù)據(jù)，這是選擇工具、技術(shù)以及從業(yè)務(wù)角度定義解決方案的關(guān)鍵。數(shù)據(jù)源--數(shù)據(jù)的來，比如Web和社交媒體、機器生成、人類生成等。識別所有數(shù)據(jù)源有助于從業(yè)務(wù)角度識別數(shù)據(jù)范圍。該圖顯示了使用最廣泛的數(shù)據(jù)源。數(shù)據(jù)使用者—處理的數(shù)據(jù)的所有可能使用者的列表：業(yè)務(wù)流程業(yè)務(wù)流程業(yè)務(wù)用戶企業(yè)應(yīng)用程序各種業(yè)務(wù)角色中的各個人員部分處理流程其他數(shù)據(jù)存儲庫或企業(yè)應(yīng)用程序圖3.1：處理的數(shù)據(jù)的所有可能使用者硬件將在其上實現(xiàn)大數(shù)據(jù)解決方案的硬件類型，包括商用硬件或最先進的硬件。理解硬件的限制，有助于指導(dǎo)大數(shù)據(jù)解決方案的選擇。圖3.2描繪用于分類大數(shù)據(jù)的各種類別。定義大數(shù)據(jù)模式的關(guān)鍵類別已識別并在藍色方框中突出顯示。大數(shù)據(jù)模式來自這些類別的組合。DataTypeContentFomatDataTypeContentFomatDataSourcesDataConsumerHardwareDataFrequrncyProcessingMethodologyAnalysisType圖3.2：大數(shù)據(jù)分類（三）數(shù)據(jù)分析平臺架構(gòu)隨著互聯(lián)網(wǎng)、移動互聯(lián)網(wǎng)和物聯(lián)網(wǎng)的發(fā)展，誰也無法否認，我們已經(jīng)切實地迎來了一個海量數(shù)據(jù)的時代，數(shù)據(jù)調(diào)查公司IDC預(yù)計2011年的數(shù)據(jù)總量將達到1.8萬億GB，對這些海量數(shù)據(jù)的分析已經(jīng)成為一個非常重要且緊迫的需求。作為一家互聯(lián)網(wǎng)數(shù)據(jù)分析公司，我們在海量數(shù)據(jù)的分析領(lǐng)域那真是被“逼上梁山”。多年來在嚴苛的業(yè)務(wù)需求和數(shù)據(jù)壓力下，我們幾乎嘗試了所有可能的大數(shù)據(jù)分析方法，最終落地于Hadoop平臺之上。Hadoop在可伸縮性、健壯性、計算性能和成本上具有無可替代的優(yōu)勢，事實上已成為當前互聯(lián)網(wǎng)企業(yè)主流的大數(shù)據(jù)分析平臺。本文主要介紹一種基于Hadoop平臺的多維分析和數(shù)據(jù)挖掘平臺架構(gòu)。3.3.1大數(shù)據(jù)分析的分類Hadoop平臺對業(yè)務(wù)的針對性較強，為了讓你明確它是否符合你的業(yè)務(wù)，現(xiàn)粗略地從幾個角度將大數(shù)據(jù)分析的業(yè)務(wù)需求分類，針對不同的具體需求，應(yīng)采用不同的數(shù)據(jù)分析架構(gòu)。（1）按照數(shù)據(jù)分析的實時性，分為實時數(shù)據(jù)分析和離線數(shù)據(jù)分析兩種。實時數(shù)據(jù)分析一般用于金融、移動和互聯(lián)網(wǎng)B2C等產(chǎn)品，往往要求在數(shù)秒內(nèi)返回上億行數(shù)據(jù)的分析，從而達到不影響用戶體驗的目的。要滿足這樣的需求，可以采用精心設(shè)計的傳統(tǒng)關(guān)系型數(shù)據(jù)庫組成并行處理集群，或者采用一些內(nèi)存計算平臺，或者采用HDD的架構(gòu)，這些無疑都需要比較高的軟硬件成本。目前比較新的海量數(shù)據(jù)實時分析工具有EMC的Greenplum、SAP的HANA等。（2）按照大數(shù)據(jù)的數(shù)據(jù)量，分為內(nèi)存級別、BI級別、海量級別三種。這里的內(nèi)存級別指的是數(shù)據(jù)量不超過集群的內(nèi)存最大值。不要小看今天內(nèi)存的容量，F(xiàn)acebook緩存在內(nèi)存的Memcached中的數(shù)據(jù)高達320TB，而目前的PC服務(wù)器，內(nèi)存也可以超過百GB。因此可以采用一些內(nèi)存數(shù)據(jù)庫，將熱點數(shù)據(jù)常駐內(nèi)存之中，從而取得非常快速的分析能力，非常適合實時分析業(yè)務(wù)。圖1是一種實際可行的MongoDB分析架構(gòu)。MongoDB大集群目前存在一些穩(wěn)定性問題，會發(fā)生周期性的寫堵塞和主從同步失效，但仍不失為一種潛力十足的可以用于高速數(shù)據(jù)分析的NoSQL。此外，目前大多數(shù)服務(wù)廠商都已經(jīng)推出了帶4GB以上SSD的解決方案，利用內(nèi)存+SSD，也可以輕易達到內(nèi)存分析的性能。隨著SSD的發(fā)展，內(nèi)存數(shù)據(jù)分析必然能得到更加廣泛的應(yīng)用。而大多數(shù)統(tǒng)計分析，機器學習問題可以用MapReduce算法改寫。MapReduce目前最擅長的計算領(lǐng)域有流量統(tǒng)計、推薦引擎、趨勢分析、用戶行為分析、數(shù)據(jù)挖掘分類器、分布式索引等。而大多數(shù)統(tǒng)計分析，機器學習問題可以用MapReduce算法改寫。MapReduce目前最擅長的計算領(lǐng)域有流量統(tǒng)計、推薦引擎、趨勢分析、用戶行為分析、數(shù)據(jù)挖掘分類器、分布式索引等。（四）面對大數(shù)據(jù)OLAP分析的一些問題OLAP分析需要進行大量的數(shù)據(jù)分組和表間關(guān)聯(lián)，而這些顯然不是NoSQL和傳統(tǒng)數(shù)據(jù)庫的強項，往往必須使用特定的針對BI優(yōu)化的數(shù)據(jù)庫。比如絕大多數(shù)針對BI優(yōu)化的數(shù)據(jù)庫采用了列存儲或混合存儲、壓縮、延遲加載、對存儲數(shù)據(jù)塊的預(yù)統(tǒng)計、分片索引等技術(shù)。Hadoop平臺上的OLAP分析，同樣存在這個問題，F(xiàn)acebook針對Hive開發(fā)的RCFile數(shù)據(jù)格式，就是采用了上述的一些優(yōu)化技術(shù)，從而達到了較好的數(shù)據(jù)分析性能。然而，對于Hadoop平臺來說，單單通過使用Hive模仿出SQL，對于數(shù)據(jù)分析來說遠遠不夠，首先Hive雖然將HiveQL翻譯MapReduce的時候進行了優(yōu)化，但依然效率低下。多維分析時依然要做事實表和維度表的關(guān)聯(lián)，維度一多性能必然大幅下降。其次，RCFile的行列混合存儲模式，事實上限制死了數(shù)據(jù)格式，也就是說數(shù)據(jù)格式是針對特定分析預(yù)先設(shè)計好的，一旦分析的業(yè)務(wù)模型有所改動，海量數(shù)據(jù)轉(zhuǎn)換格式的代價是極其巨大的。最后，HiveQL對OLAP業(yè)務(wù)分析人員依然是非常不友善的，維度和度量才是直接針對業(yè)務(wù)人員的分析語言。而且目前OLAP存在的最大問題是：業(yè)務(wù)靈活多變，必然導(dǎo)致業(yè)務(wù)模型隨之經(jīng)常發(fā)生變化，而業(yè)務(wù)維度和度量一旦發(fā)生變化，技術(shù)人員需要把整個Cube(多維立方體)重新定義并重新生成，業(yè)務(wù)人員只能在此Cube上進行多維分析，這樣就限制了業(yè)務(wù)人員快速改變問題分析的角度，從而使所謂的BI系統(tǒng)成為死板的日常報表系統(tǒng)。使用Hadoop進行多維分析，首先能解決上述維度難以改變的問題，利用Hadoop中數(shù)據(jù)非結(jié)構(gòu)化的特征，采集來的數(shù)據(jù)本身就是包含大量冗余信息的。同時也可以將大量冗余的維度信息整合到事實表中，這樣可以在冗余維度下靈活地改變問題分析的角度。其次利用HadoopMapReduce強大的并行化處理能力，無論OLAP分析中的維度增加多少，開銷并不顯著增長。換言之，Hadoop可以支持一個巨大無比的Cube，包含了無數(shù)你想到或者想不到的維度，而且每次多維分析，都可以支持成千上百個維度，并不會顯著影響分析的性能。因此，我們的大數(shù)據(jù)分析架構(gòu)在這個巨大Cube的支持下，直接把維度和度量的生成交給業(yè)務(wù)人員，由業(yè)務(wù)人員自己定義好維度和度量之后，將業(yè)務(wù)的維度和度量直接翻譯成MapReduce運行，并最終生成報表。可以簡單理解為用戶快速自定義的“MDX”(多維表達式，或者多維立方體查詢)語言→MapReduce的轉(zhuǎn)換工具。同時OLAP分析和報表結(jié)果的展示，依然兼容傳統(tǒng)的BI和報表產(chǎn)品。一種Hadoop多維分析平臺的架構(gòu)整個架構(gòu)由四大部分組成：數(shù)據(jù)采集模塊、數(shù)據(jù)冗余模塊、維度定義模塊、并行分析模塊。如圖3.3所示。并行分析并行分析核心模塊報表中心Hadoop分析模塊維度定義維度定義模塊多維分析提交模塊數(shù)據(jù)亢余數(shù)據(jù)亢余亢余維度定義數(shù)據(jù)采集數(shù)據(jù)日志數(shù)據(jù)日志圖3.3：Hadoop多維分析平臺架構(gòu)圖數(shù)據(jù)采集模塊采用了Cloudera的Flume，將海量的小日志文件進行高速傳輸和合并，并能夠確保數(shù)據(jù)的傳輸安全性。單個collector宕機之后，數(shù)據(jù)也不會丟失，并能將agent數(shù)據(jù)自動轉(zhuǎn)移到其他的colllecter處理，不會影響整個采集系統(tǒng)的運行。數(shù)據(jù)冗余模塊不是必須的，但如果日志數(shù)據(jù)中沒有足夠的維度信息，或者需要比較頻繁地增加維度，則需要定義數(shù)據(jù)冗余模塊。通過冗余維度定義器定義需要冗余的維度信息和來源(數(shù)據(jù)庫、文件、內(nèi)存等)，并指定擴展方式，將信息寫入數(shù)據(jù)日志中。在海量數(shù)據(jù)下，數(shù)據(jù)冗余模塊往往成為整個系統(tǒng)的瓶頸，建議使用一些比較快的內(nèi)存NoSQL來冗余原始數(shù)據(jù)，并采用盡可能多的節(jié)點進行并行冗余;或者也完全可以在Hadoop中執(zhí)行批量Map，進行數(shù)據(jù)格式的轉(zhuǎn)化。維度定義模塊是面向業(yè)務(wù)用戶的前端模塊，用戶通過可視化的定義器從數(shù)據(jù)