以下為原文：

　　夜深了，電話鈴聲響起！這不是恐怖片的開頭，卻是我們工作的開始。

　　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的互動式分析，對系統進行了多個層面的優化。

　　結束語

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

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