講鋒刃大資料方案之前，我們先整體看看大資料平臺架構，有諸形於
內必形於外，很多區域性狀況的問題，需要從整體來看，為此，我們按照集
群狀況，典型業務流程和資料流、系統架構瓶頸點的思路順序，以表知裡
的進行一下梳理。
一、叢集狀況的反饋
當前 Hadoop 集群系統效能繁忙（3 大區域 7 大機房）， 1000 多儲存
機器對應 4000 多計算機器， cpu 平均值 70%-80%（晚 20 點到 0 點較低），
分鐘負載很高，任務積壓重； ech1 幾百兆，峰值幾個 g；磁碟 io 約幾
百兆，峰值幾 g，讀寫 iops3000。儲存計算比為 1： 2，業務 job 還在增長之勢，
： 3 到 1： 4 將達到叢集瓶頸。
很多時候我們看到叢集繁忙，只當作運維問題去解決，擴容叢集機器，
調整機房部署，優化排程能力和虛擬化，增強任務監控管理等。卻很少關
心叢集上跑的都是些什麼任務，為什麼會給叢集造成這麼大的壓力，我們
接下來通過梳理業務流程和資料流來搞清楚這個問題。
 

過對叢集、採集、通道、統計、儲存、資料治理、
idc、業務場景的全鏈路架構分析，歸納出以下瓶頸點：
1. Hadoop 叢集的繁忙壓力
2. 所有業務全部依賴離線 m/r 計算和 Hive SQL
3. log 採集的大量重複內容
4. MQ 叢集每日訊息總量萬億但無法提供內容過濾
5. 冷熱儲存、短期儲存（天內）、長期儲存（T+1，周、月、年）
混一起
6. 做到小時和分鐘級別統計很難。
7. 沒有一個統一精簡的資料模型形成標準。
8. 業務的儲存和計算還在迅速增長……
但是不可能所有的架構瓶頸都能在短時間內進行優化改進，我們需要
尋找一個最合適的切入點，先解決最迫切的問題
 

遷入實時計算進行優化的考慮
1. 經過分析了燈塔、應用寶、手機瀏覽器和手機管家，業務的相似主
線模式如下，更適合實時處理。
2. 清洗部分實時處理 DEMO 驗證：相對於離線計算 MAP/REDUCE
的時間消耗換算，耗用機器數從 84 臺降低到 15 臺 m10，完成了 90% 的
資料量進行流式清洗，包括：從 kafka 拉資料 -> 解包 ->byte2string-> 清洗
->string2byte->， 5 分鐘處理 10 億訊息資料， 333w/s，接近 mq 純拉取消
費的 360w/s。
3. 清洗轉換步驟，採用實時流處理架構如 Storm，通過 spout 從 MQ
獲取輸入流，自定義多個 bolt 並行處理輸入流，再依此組合設計。