大資料下的資料分析平臺架構

隨著互聯網、移動互聯網和物聯網的發展，誰也無法否認，我們已經切實地迎來了一個海量資料的時代，資料調查公司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必將很快迎來下一代產品，屆時其必然擁有更強大的分析能力和更便捷的使用方式，從而真正輕鬆面對未來海量資料的挑戰。

(責任編輯：admin)