2013年5月，我們收到一個電話線索，客戶需要支持幾十億數(shù)據(jù)量的實時查詢與分析，包括數(shù)據(jù)抓取和存儲，我們經(jīng)過一番努力提出一個解決方案，客戶覺得有些不妥，決定自己招聘Hadoop團隊，實施該系統(tǒng)……

半個月后，客戶打來第二個電話，明確表示Hadoop未能滿足實時大數(shù)據(jù)分析的需求，決定接受我們的方案，但是客戶要求我們不僅出產(chǎn)品，還要負責實施……

于是乎，開工！

項目價值

CMNET網(wǎng)間流量分析與監(jiān)控系統(tǒng)（簡稱流控系統(tǒng)），是中國移動分公司的一個項目。項目要求能基于時間、地區(qū)、運營商、業(yè)務、App、IP分組、域名等維度對全省的上網(wǎng)流量進行實時分析和報告。這些分析報告能給客戶帶來如下好處：

1. 實現(xiàn)對接入鏈路和基站的全程監(jiān)控。例如，一旦來自某鏈路或基站的流量很低，可及時對鏈路和基站進行檢修，這將大大降低故障率。

2. 由于具備了對鏈路和基站進行全程監(jiān)控的能力，客戶可以對鏈路和基站的帶寬進行動態(tài)調整，基于需求進行合理的資源配置。

3. 覆蓋全省的全量數(shù)據(jù)，能提供基于業(yè)務/地域/App/行業(yè)/域名等維度的數(shù)據(jù)分析報告，具備100%的可信度和極高的商業(yè)價值。

數(shù)據(jù)流向

上網(wǎng)數(shù)據(jù)從硬件設備中抓取出來，形成壓縮的日志文件存儲在服務器上，服務器每五分鐘生成新的日志文件。該服務器提供FTP訪問。

我們方案中承擔的流控系統(tǒng)，將通過FTP每五分鐘訪問一次日志文件服務器，將新生成的壓縮日志文件抽取出來。這是一個典型的、增量更新的ETL過程，如下：

1. Extract: 定期抽取的日志文件并解壓縮。

2. Transform: 解析出上網(wǎng)信息，同MySQL的維度表進行關聯(lián)，生成包括業(yè)務/地域/App/行業(yè)/域名等維度的寬表。

3. Load: 將數(shù)據(jù)裝載入我們的分布式集市。

初期驗證（POC）

中國移動的日志數(shù)據(jù)分G類和A類，各取幾塊樣本日志文件，驗證數(shù)據(jù)流向的可行性以及性能。

我們很快完成了ETL的整個過程，寬表數(shù)據(jù)被成功地裝載入我們的分布式集市。

性能上，我們按照用戶提出的每天數(shù)據(jù)量5000萬條增量，計算出支持100天50億數(shù)據(jù)量的分布式集群所需的磁盤空間、內存總量、和CPU總量。由于客戶一再強調預算有限，于是配置了6臺低配PC server：1cpu x 4core，32G內存，1T硬盤。

我們模擬了常用的用戶場景，整個系統(tǒng)的響應能力基本滿足需求。系統(tǒng)架構如下：

正式實施

中國移動分公司的上網(wǎng)數(shù)據(jù)在內網(wǎng)，一般不提供外網(wǎng)連接，需要嚴格申請之后才能在一定時間內提供外網(wǎng)連接。因而，我們先把整個系統(tǒng)的ETL工作開發(fā)完成之后，才正式申請了外網(wǎng)連接進行數(shù)據(jù)裝載。

從開始進行上網(wǎng)數(shù)據(jù)的ETL工作，我們就發(fā)現(xiàn)數(shù)據(jù)量與預期嚴重不符。預期的上網(wǎng)數(shù)據(jù)是每天不超過5000萬條，但實際上每天的上網(wǎng)數(shù)據(jù)在6億條以上，100天保存的數(shù)據(jù)量將會達到驚人的六百億條。6臺低配PC server有點小馬拉大車的感覺，完全達不到“海量數(shù)據(jù)、實時分析”的設計目標。我們趕緊聯(lián)系客戶，確定上網(wǎng)數(shù)據(jù)每天6億條以上，而不是之前預估的每天5000萬條左右。怎么辦？

系統(tǒng)重構

經(jīng)過與客戶的詳細溝通和理性分析，大家一致決定進行系統(tǒng)重構。

上網(wǎng)數(shù)據(jù)的日志文件是5分鐘粒度的。我們將上網(wǎng)數(shù)據(jù)按照分析需求分為兩類：

1. 細節(jié)數(shù)據(jù)：保留三天的細節(jié)數(shù)據(jù)（5分鐘粒度），共約20億條。這樣，由于保留了細節(jié)數(shù)據(jù)，客戶可以對近三天的上網(wǎng)數(shù)據(jù)進行任意的探索式BI分析。

2. 匯總數(shù)據(jù)：在認真研究了流控系統(tǒng)的分析報告需求之后，我們將五分鐘的細節(jié)數(shù)據(jù)匯總為兩小時的匯總數(shù)據(jù)。這樣數(shù)據(jù)量可以降到約為原來的1/10，100天的數(shù)據(jù)總量大約60億條。

重構之后的數(shù)據(jù)流如下：

后期，我們陸續(xù)進行了一些系統(tǒng)調優(yōu)，包括JVM調優(yōu)、存儲調優(yōu)、計算調優(yōu)等等。客戶打開一個Dashboard的響應時間基本控制在秒級，最極端的分析報告也能在一分鐘之內生成。基本實現(xiàn)了“海量數(shù)據(jù)、實時分析”：

1. 系統(tǒng)定期推送日報、周報和月報。

2. 系統(tǒng)支持探索式BI分析。多數(shù)分析請求達到了秒級響應。

案例總結

1. 項目的數(shù)據(jù)量非常大，100天超過600億條日志；

2. 項目的預算非常有限，采購了6臺低端PC Server。硬件投入不大，軟件性價比也很高；

3. ETL過程難度較高，隨著降維的需求加入，BI層難度也相應提高；

4. 為達到秒級響應，以支持探索式BI的交互式分析，對系統(tǒng)進行了多個層面的優(yōu)化。

結束語

有了大數(shù)據(jù)，還要從大數(shù)據(jù)中提取價值，離不開分析工具，通過豐富的分析功能，在繁雜的數(shù)據(jù)中找到其中的價值。而大數(shù)據(jù)給分析提供了一定的挑戰(zhàn)，需要高性能計算做支撐，才能在大數(shù)據(jù)的金礦中挖到金子。

這些案例的成功實施和上線，完美詮釋了我們的大數(shù)據(jù)之道：大數(shù)據(jù)，小投入。