一種基於Storm的可擴充即時資料處理架構思考

一種基於Storm的可擴充即時資料處理架構思考
問題引入

使用storm可以方便的構建一種叢集式的資料架構，並通過定義topo來實現商務邏輯。

但使用topo存在一個缺點， topo的處理能力來自於其啟動時設定的worker數目，在很多情況下，我們需要能夠根據業務壓力來調整叢集的處理能力，這時候單一的topo就無法解決這個問題了。

為了能夠更加靈活的定義處理能力，可以考慮將原有的topo根據業務域進行拆分，做到互不干擾，靈活控制，而且為了能夠更加經濟的利用處理資源，可以考慮引入worker資源集區的概念，達到對資源的充分利用。

但使用這種多topo架構存在一個致命問題，storm中的topo是各自獨立，無法直接通訊的，因此在擷取某些關鍵資源時，可能會出現資源爭搶的情況的。面對此種情境，有兩種處理思路：

其一：使用zookeeper等提供的分布式鎖，來實現對關鍵資源的控制，缺點是可靠性及效率存在問題，使用與對處理效率要求不高的情境。

其二：由第三方對關鍵資源進行分配，規避由topo本身對資源的爭搶，這種方案引入了新的構建，提高了系統的複雜度。

 

處理架構

叢集的優點是處理能力可擴充，但會帶來資料同步、開發維護複雜度以及資料一致性等問題。

我們現在雖然已經有了很多叢集處理架構及相應組件用來簡化相應的開發及維護工作量，但從項目開發的實際來看，我們還是需要處理一些沒有被成熟組件包含但又非常棘手的問題。

storm定義的叢集可以提供方便的可擴充處理能力，在整個叢集中，topo都是等價的，在storm運行環境內部，topo之間也無法交流。

回到上面的問題，通過storm，我們獲得了即時的叢集處理能力；通過topo，我們可以自訂業務，並方便的在節點中分發；通過worker數目的變化，可以調整其處理能力。

如果輔以Hadoop等大資料存放區平台及Redis緩衝，加以使用zookeeper構成的分布式鎖，已經基本可以構建一套即時的可擴充的大資料處理平台。

元件圖表

 

多top的初始化

下面是一個基於storm的多拓撲初始化的類別檢視：

 

關鍵點與思考緩衝策略

因為是即時的資料處理平台，其存在對效率的要求，而資料庫儲存的訪問通常稱為瓶頸，因此在此設計了緩衝，選型Redis是引起使用已經較為廣泛和穩定，業界也存在較為成熟的緩衝構建策略。

分布式鎖

分布式鎖至關重要，尤其是如果storm叢集中存在多個topo的情況下，非常可能存在對關鍵資源的爭奪。

使用zookeeper構建分布式鎖已經存在較為成為的應用，但使用zookeeper構建的分布式鎖必定也存在健壯性不足和鎖的效率問題，需要在設計時加以考慮。

Hadoop和Oracle的協作

從使用成本和使用情境上，這兩個組件就存在很大不同。

在應用時，Hadoop可以用以儲存非結構化的資料，例如原始結果。由於Oracle在儲存結構化數、可靠性以及易用性上的巨大優勢，可以選擇將最終處理結果存放於Oracle之中，利於維護和展示。

Storm如何分配任務和負載平衡？ 

Storm進程通訊機制分析

Apache Storm 的曆史及經驗教訓 

Apache Storm 的詳細介紹：請點這裡
Apache Storm 的：請點這裡

本文永久更新連結地址：