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

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

于是乎，開工！

項目價值

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

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

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

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

數據流向

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

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

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

2. Transform: 解析出上網信息，同MySQL的維度表進行關聯，生成包括業務/地域/App/行業/域名等維度的寬表。

3. Load: 將數據裝載入我們的分布式集市。

初期驗證（POC）

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

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

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

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

正式實施

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

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

系統重構

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

上網數據的日志文件是5分鐘粒度的。我們將上網數據按照分析需求分為兩類：

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

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

重構之后的數據流如下：

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

1. 系統定期推送日報、周報和月報。

2. 系統支持探索式BI分析。多數分析請求達到了秒級響應。

案例總結

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

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

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

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

結束語

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

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