Storm在spider.io應用的經驗教訓

banq發表於2013-10-28
ORMIDE
Storm at spider.io - London Storm

spider.io 是一個為線上廣告提供反惡意軟體，反惡意點選的系統，其任務是如何從大量日誌中發現廣告舞弊點選以騙取廣告費。

spider.io 原先已經使用Queue/Worker來擴充套件其系統，問題：
1.太依賴程式碼，寫太多底層程式碼不是每個人都擅長的。
2.維持in-memory資料庫帶來費用提高，主要是AWS記憶體費用。
3.不能動彈伸縮擴充套件，整個DB叢集需要重啟。

遷移到Storm後:
1.將自己的基於事件流驅動event-stream-based遷移到Storm，這樣有整個開源社群來盯著它。
2.從記憶體資料庫移植到HBase，能夠持久資料很長時間。

spider.io在2011年9月花一個月由一個工程師搞定Storm。期間經過幾次波折，他們現在狀況是：

使用 Storm,和Mahout結對
● 使用 Cascading + Mahout來對付億萬級別廣告展現。
● 實時響應使用 Trident + Mahout

使用“壞簽名”識別新的殭屍網路IP地址，以及嫌疑出版商。
能夠線上學習適應新出現的威脅模型

他們的經驗教訓是：
如果你的業務變化，你的架構必須跟隨變化。
● 只有在下面請看選擇Storm:
○ 如果你已經有一個基於事件流的系統，使用Storm能夠更有彈性。
○ 你的業務需要的實時分析元件正好是一個事件流驅動模型。
○ 你樂於在基於底層編碼。

● 下面情況不要使用Storm:
○ 你無需實時資料分析
○ 你只是覺得它很酷。

使用Cascading實現Hadoop jobs，使用Storm用來實現實時分析，這兩者搭配真的很方便：
○ 保留了基於事件流的正規化
○進行升級遷移時，不必換一個角度來思考Sotrm(因為你習慣了EDA方式)
○ 能夠共享程式碼
○ 有一個通用分析元件庫來評估他們。
●一個適當的可管理的Storm叢集能執行很長時間。

相關文章