解讀《大數據下的數據分析平台架構》

再看《大數據下的數據分析平台架構》：

來源於Admaster數據挖掘總監 謝超

看名字Admaster，是一個廣告推薦公司。

就是幫廣告公司分銷廣告的公司。

廣告公司接到各種企業來的廣告，而自己本身沒有能力做網路推銷

那麼只有依託Admaster這類可以精準定位產品用戶的公司，來幫其分發廣告

Admaster可以說是二道販子，但是隨著互聯萬的越來越成熟，這類公司反而更容易稱為主流

回到主題上來，這文章主要講解的是大數據下的數據分析平台架構。

首先，離開場景討論架構，那都不切實際。

因此首先要明確，我們的場景是什麼

作者在他的文中，解釋了幾個常見的需要用到大數據分析架構的應用場景：

1. 按照數據分析的實時性，分為實時數據分析和離線數據分析

傳統的實時數據分析，通過精心設計的RDBMS集群可以完成，比如 EMC的 GreenPlum, SAP HANA

但對於數秒內返回上億行數據的分析結果，這時候就要引入Storm, Spark 等新型實時流處理技術了。

這一點鑒於當時作者的寫作時間來看，他也是沒預料到生態發展這麼快。

而離線大數據分析，依然是Hadoop的強項。

因為大量數據的轉換，傳統的ETL造成的開銷太大，因此採用kafka, Chukwa, Timetunnel這類工具，才能實現在每秒數百MB的數據採集操作，將數據上載到Hadoop的分散式存儲上，

調用MapReduce 來處理。

同樣的，現在已經可以說由 Spark 替代了

2. 按照大數據的數據量，分為內存級別，BI級別，海量級別

內存級別就是分散式內存計算。總量不超過集群的總內存量。

可以是各種NoSQL, MongoDB, Redis, Memcached 的集群應用

也可以是Spark 集群的並行計算。

BI級別，就是傳統的數據倉庫那個量，但是比 NoSQL 這種只將數據存入內存的場景，數據顯然多很多。但是這類應該放入 傳統的BI，作者放在這裡，應該只是為了提供比較

海量級別，就是傳統的BI無法處理的數據量了。一般的BI數據倉庫，TB級以上就算很大了。但是互聯網企業中，海量的意思，可能是PB，也就是1024個BI數據倉庫的規模。因此傳統BI的工具，比如 SSIS, Informatic, Data Stage, BO 等ETL, 報表工具就無法完成計算與存儲了。此時，hadooop 的HDFS 就應運而生了。分散式存儲，意味著增加機器就能線性擴容。

3. 按照數據分析的演算法複雜度：

簡單的排序分析，總數據量不大於內存，使用 Redis 就能輕鬆完成了

大規模的人臉識別，圖形渲染，自然是使用並行處理集群

流量統計，推薦引擎，趨勢分析，用戶行為分析，分散式索引等統計分析，機器學習等問題

則可以使用 MapReduce 演算法改寫。

還有一類 大數據OLAP分析，使用NoSQL, RDBMS並不是處理強項，

甚至使用Hive也是僅能解決數據量大小的問題，而不是徹底解決靈活維度分析的難點

所以還是需要使用 Hadoop MapReduce開發程序

但是在這裡，Spark 的出現可以有效緩解以上「陣痛」。作者的這篇文章是寫於 2011 年。

而 Spark 則出身於2009年, 但被世人所知是2012年，那年開始在 Bay Area 推廣。

所以MapReduce不再是唯一的大數據 OLAP 選擇

更別說之後，生態圈又出現了 Apache Kylin, Kyvos, AtScale 等等

Google 上（沒有在百度搜過）輸入 Big Data OLAP tool 會出現一堆

只有熟悉了整個大數據生態圈，才會挑合適的工具來完成適合你業務場景的平台架構

努力吧！