大數據下的數據分析平臺架構zz

轉自http://www.cnblogs.com/end/archive/2012/02/05/2339152.html

隨着互聯網、移動互聯網和物聯網的發展，誰也沒法否定，咱們已經切實地迎來了一個海量數據的時代，數據調查公司IDC預計2011年的數據總量將達到1.8萬億GB，對這些海量數據的分析已經成爲一個很是重要且緊迫的需求。

做爲一家互聯網數據分析公司，咱們在海量數據的分析領域那真是被「逼上梁山」。多年來在嚴苛的業務需求和數據壓力下，咱們幾乎嘗試了全部可能的大數據分析方法，最終落地於Hadoop平臺之上。

Hadoop在可伸縮性、健壯性、計算性能和成本上具備無可替代的優點，事實上已成爲當前互聯網企業主流的大數據分析平臺。本文主要介紹一種基於Hadoop平臺的多維分析和數據挖掘平臺架構。

大數據分析的分類

Hadoop平臺對業務的針對性較強，爲了讓你明確它是否符合你的業務，現粗略地從幾個角度將大數據分析的業務需求分類，針對不一樣的具體需求，應採用不一樣的數據分析架構。

• 按照數據分析的實時性，分爲實時數據分析和離線數據分析兩種。

實時數據分析通常用於金融、移動和互聯網B2C等產品，每每要求在數秒內返回上億行數據的分析，從而達到不影響用戶體驗的目的。要知足這樣的需求， 能夠採用精心設計的傳統關係型數據庫組成並行處理集羣，或者採用一些內存計算平臺，或者採用HDD的架構，這些無疑都須要比較高的軟硬件成本。目前比較新 的海量數據實時分析工具備EMC的Greenplum、SAP的HANA等。

對於大多數反饋時間要求不是那麼嚴苛的應用，好比離線統計分析、機器學習、搜索引擎的反向索引計算、推薦引擎的計算等，應採用離線分析的方式，經過 數據採集工具將日誌數據導入專用的分析平臺。但面對海量數據，傳統的ETL工具每每完全失效，主要緣由是數據格式轉換的開銷太大，在性能上沒法知足海量數 據的採集需求。互聯網企業的海量數據採集工具，有Facebook開源的Scribe、LinkedIn開源的Kafka、淘寶開源的 Timetunnel、Hadoop的Chukwa等，都可以知足每秒數百MB的日誌數據採集和傳輸需求，並將這些數據上載到Hadoop中央系統上。

• 按照大數據的數據量，分爲內存級別、BI級別、海量級別三種。

這裏的內存級別指的是數據量不超過集羣的內存最大值。不要小看今天內存的容量，Facebook緩存在內存的Memcached中的數據高達 320TB，而目前的PC服務器，內存也能夠超過百GB。所以能夠採用一些內存數據庫，將熱點數據常駐內存之中，從而取得很是快速的分析能力，很是適合實 時分析業務。圖1是一種實際可行的MongoDB分析架構。

 

圖1 用於實時分析的MongoDB架構

MongoDB大集羣目前存在一些穩定性問題，會發生週期性的寫堵塞和主從同步失效，但仍不失爲一種潛力十足的能夠用於高速數據分析的NoSQL。

此外，目前大多數服務廠商都已經推出了帶4GB以上SSD的解決方案，利用內存+SSD，也能夠輕易達到內存分析的性能。隨着SSD的發展，內存數據分析必然能獲得更加普遍的
應用。

BI級別指的是那些對於內存來講太大的數據量，但通常能夠將其放入傳統的BI產品和專門設計的BI數據庫之中進行分析。目前主流的BI產品都有支持TB級以上的數據分析方案。種類繁多，就不具體列舉了。

海量級別指的是對於數據庫和BI產品已經徹底失效或者成本太高的數據量。海量數據級別的優秀企業級產品也有不少，但基於軟硬件的成本緣由，目前大多 數互聯網企業採用Hadoop的HDFS分佈式文件系統來存儲數據，並使用MapReduce進行分析。本文稍後將主要介紹Hadoop上基於 MapReduce的一個多維數據分析平臺。

• 數據分析的算法複雜度

根據不一樣的業務需求，數據分析的算法也差別巨大，而數據分析的算法複雜度和架構是緊密關聯的。舉個例子，Redis是一個性能很是高的內存Key- Value NoSQL，它支持List和Set、SortedSet等簡單集合，若是你的數據分析需求簡單地經過排序，鏈表就能夠解決，同時總的數據量不大於內存 （準確地說是內存加上虛擬內存再除以2），那麼無疑使用Redis會達到很是驚人的分析性能。

還有不少易並行問題（Embarrassingly Parallel），計算能夠分解成徹底獨立的部分，或者很簡單地就能改造出分佈式算法，好比大規模臉部識別、圖形渲染等，這樣的問題天然是使用並行處理集羣比較適合。

而大多數統計分析，機器學習問題能夠用MapReduce算法改寫。MapReduce目前最擅長的計算領域有流量統計、推薦引擎、趨勢分析、用戶行爲分析、數據挖掘分類器、分佈式索引等。

 

圖2 RCFile的行列混合存

 

面對大數據OLAP分析的一些問題

OLAP分析須要進行大量的數據分組和表間關聯，而這些顯然不是NoSQL和傳統數據庫的強項，每每必須使用特定的針對BI優化的數據庫。好比絕大多數針對BI優化的數據庫採用了列存儲或混合存儲、壓縮、延遲加載、對存儲數據塊的預統計、分片索引等技術。

Hadoop平臺上的OLAP分析，一樣存在這個問題，Facebook針對Hive開發的RCFile數據格式，就是採用了上述的一些優化技術，從而達到了較好的數據分析性能。如圖2所示。

然而，對於Hadoop平臺來講，單單經過使用Hive模仿出SQL，對於數據分析來講遠遠不夠，首先Hive雖然將HiveQL翻譯MapReduce的時候進行了優化，但依然效率低下。多維分析時依然要作事實表和維度表的關聯，維度一多性能必然大幅降低。其次，RCFile的行列混合存儲模式，事實上限制死了數據格式，也就是說數據格式是針對特定分析預先設計好的，一旦分析的業務模型有所改動，海量數據轉換格式的代價是極其巨大的。最後，HiveQL對OLAP業務分析人員依然是很是不友善的，維度和度量纔是直接針對業務人員的分析語言。

並且目前OLAP存在的最大問題是：業務靈活多變，必然致使業務模型隨之常常發生變化，而業務維度和度量一旦發生變化，技術人員須要把整個 Cube（多維立方體）從新定義並從新生成，業務人員只能在此Cube上進行多維分析，這樣就限制了業務人員快速改變問題分析的角度，從而使所謂的BI系 統成爲死板的平常報表系統。

使用Hadoop進行多維分析，首先能解決上述維度難以改變的問題，利用Hadoop中數據非結構化的特徵，採集來的數據自己就是包含大量冗餘信息 的。同時也能夠將大量冗餘的維度信息整合到事實表中，這樣能夠在冗餘維度下靈活地改變問題分析的角度。其次利用Hadoop MapReduce強大的並行化處理能力，不管OLAP分析中的維度增長多少，開銷並不顯著增加。換言之，Hadoop能夠支持一個巨大無比的Cube， 包含了無數你想到或者想不到的維度，並且每次多維分析，均可以支持成千上百個維度，並不會顯著影響分析的性能。

 

圖3 MDX→MapReduce簡略示意圖

所以，咱們的大數據分析架構在這個巨大Cube的支持下，直接把維度和度量的生成交給業務人員，由業務人員本身定義好維度和度量以後，將業務的維度 和度量直接翻譯成MapReduce運行，並最終生成報表。能夠簡單理解爲用戶快速自定義的「MDX」（多維表達式，或者多維立方體查詢）語言 →MapReduce的轉換工具。同時OLAP分析和報表結果的展現，依然兼容傳統的BI和報表產品。如圖3所示。

圖3能夠看出，在年收入上，用戶能夠本身定義子維度。另外，用戶也能夠在列上自定義維度，好比將性別和學歷合併爲一個維度。因爲Hadoop數據的非結構化特徵，維度能夠根據業務需求任意地劃分和重組。

 

圖4 Hadoop多維分析平臺架構圖

 

一種Hadoop多維分析平臺的架構

整個架構由四大部分組成：數據採集模塊、數據冗餘模塊、維度定義模塊、並行分析模塊。如圖4所示。

數據採集模塊採用了Cloudera的Flume，將海量的小日誌文件進行高速傳輸和合並，並可以確保數據的傳輸安全性。單個collector宕 機以後，數據也不會丟失，並能將agent數據自動轉移到其餘的colllecter處理，不會影響整個採集系統的運行。如圖5所示。

數據冗餘模塊不是必須的，但若是日誌數據中沒有足夠的維度信息，或者須要比較頻繁地增長維度，則須要定義數據冗餘模塊。經過冗餘維度定義器定義須要 冗餘的維度信息和來源（數據庫、文件、內存等），並指定擴展方式，將信息寫入數據日誌中。在海量數據下，數據冗餘模塊每每成爲整個系統的瓶頸，建議使用一 些比較快的內存NoSQL來冗餘原始數據，並採用盡量多的節點進行並行冗餘；或者也徹底能夠在Hadoop中執行批量Map，進行數據格式的轉化。

 

圖5 採集模塊

 

圖6 核心模塊的邏輯

 

圖7 MapReduce WorkFlow例子

維度定義模塊是面向業務用戶的前端模塊，用戶經過可視化的定義器從數據日誌中定義維度和度量，並能自動生成一種多維分析語言，同時可使用可視化的分析器經過GUI執行剛剛定義好的多維分析命令。

並行分析模塊接受用戶提交的多維分析命令，並將經過核心模塊將該命令解析爲Map-Reduce，提交給Hadoop集羣以後，生成報表供報表中心展現。

核心模塊是將多維分析語言轉化爲MapReduce的解析器，讀取用戶定義的維度和度量，將用戶的多維分析命令翻譯成MapReduce程序。核心模塊的具體邏輯如圖6所示。

圖6中根據JobConf參數進行Map和Reduce類的拼裝並不複雜，難點是不少實際問題很難經過一個MapReduce Job解決，必須經過多個MapReduce Job組成工做流（WorkFlow），這裏是最須要根據業務進行定製的部分。圖7是一個簡單的MapReduce工做流的例子。

MapReduce的輸出通常是統計分析的結果，數據量相較於輸入的海量數據會小不少，這樣就能夠導入傳統的數據報表產品中進行展示。

結束語

固然，這樣的多維分析架構也不是沒有缺點。因爲MapReduce自己就是以蠻力去掃描大部分數據進行計算，所以沒法像傳統BI產品同樣對條件查詢 作優化，也沒有緩存的概念。每每不少很小的查詢須要「興師動衆」。儘管如此，開源的Hadoop仍是解決了不少人在大數據下的分析問題，真可謂是「功德無 量」。

Hadoop集羣軟硬件的花費極低，每GB存儲和計算的成本是其餘企業級產品的百分之一甚至千分之一，性能卻很是出色。咱們能夠輕鬆地進行千億乃至萬億數據級別的多維統計分析和機器學習。

6月29日的Hadoop Summit 2011上，Yahoo!剝離出一家專門負責Hadoop開發和運維的公司Hortonworks。Cloudera帶來了大量的輔助工具，MapR帶來 了號稱三倍於Hadoop MapReduce速度的並行計算平臺。Hadoop必將很快迎來下一代產品，屆時其必然擁有更強大的分析能力和更便捷的使用方式，從而真正輕鬆面對將來 海量數據的挑戰。