【轉】Twitter Storm: 在生產叢集上運行topology

標籤：

Twitter Storm: 在生產叢集上運行topology發表於 2011 年 10 月 07 日 由 xumingming作者: xumingming | 可以轉載, 但必須以超連結形式標明文章原始出處和作者資訊及著作權聲明
網址: http://xumingming.sinaapp.com/185/twitter-storm-在生產叢集上運行topology/

 
本文翻譯自: https://github.com/nathanmarz/storm/wiki/Running-topologies-on-a-production-cluster 。

在生產叢集上運行topology跟本地模式差不多。下面是步驟：

1）定義topology（如果是java的話， 用TopologyBuilder)

2) 使用StormSubmitter來把topology提交到叢集。StormSubmitter的參數有：topology的名字，topology的設定物件，以及topology本身。比如:

協助

12345

Config conf = newConfig();conf.setNumWorkers(20);conf.setMaxSpoutPending(5000);StormSubmitter.submitTopology("name",                   conf, topology);

3) 建立一個包含你的程式碼以及你代碼所依賴的依賴包的jar包（有關storm的jar包不用包括， 這些jar包會在工作節點上自動被添加到classpath裡面去)。如果你使用maven, 那麼外掛程式:Maven Assembly Plugin可以幫你打包，只要把下面的配置加入你的pom.xml。

協助

01020304050607080910111213

<plugin>  <artifactId>maven-assembly-plugin</artifactId>  <configuration>    <descriptorRefs>      <descriptorRef>jar-with-dependencies</descriptorRef>    </descriptorRefs>    <archive>      <manifest>        <mainClass>com.path.to.main.Class</mainClass>      </manifest>    </archive>  </configuration></plugin>

然後運行mvn assembly:assembly就可以打包了. 再說一下，不用包括storm相關的jar包，它們會自動加到classpath裡面。

4）用storm用戶端去提交jar包:

協助

1	storm jar allmycode.jar org.me.MyTopology arg1 arg2 arg3

storm jar 會把代碼提交到叢集並且配置StormSubmitter類以讓它和正確的叢集進行通訊。在這個例子裡面，上傳jar包之後storm jar命令會調用org.me.MyTopology的main函數，參數是 arg1, arg2, arg3。關於如何配置你的storm用戶端去和storm叢集進行通訊可以看下配置storm開發環境。

常見配置

有很多topology級的配置可以設。這裡有關於所有配置的清單， 以”TOPOLOGY”打頭的配置是topology層級的配置，可以覆蓋全域層級的配置。下面是一些比較常見的：

1）Config.TOPOLOGY_WORKERS:  這個設定用多少個背景工作處理序來執行這個topology。比如，如果你把它設定成25， 那麼叢集裡面一共會有25個java進程來執行這個topology的所有task。如果你的這個topology裡面所有組件加起來一共有150的並行度，那麼每個進程裡面會有6個線程(150 / 25 = 6)。

2）Config.TOPOLOGY_ACKERS: 這個配置設定acker線程的數目。Ackers是Storm的可靠性API的一部分，關於storm的可靠性API可以看下：Twitter Storm如何保證訊息不丟失。

3）Config.TOPOLOGY_MAX_SPOUT_PENDING:  這個設定一個spout task上面最多有多少個沒有處理的tuple（沒有ack/failed）回複， 我們推薦你設定這個配置，以防止tuple隊列爆掉。

4）Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS: 這個配置storm的tuple的逾時時間  – 超過這個時間的tuple被認為處理失敗了。這個設定的預設設定是30秒，對於大多數的topology都已經足夠了。關於storm的可靠性API可以看看Twitter Storm如何保證訊息不丟失。

5）Config.TOPOLOGY_SERIALIZATIONS: 為了在你的tuple裡面使用自訂類型，你可以用這個配置註冊自訂serializer。

終止一個topology

要終止一個topology, 執行:

協助

1	storm kill{stormname}

其中{stormname}是提交topology給storm叢集的時候指定的名字。

storm不會馬上終止topology。相反，它會先終止所有的spout，讓它們不再發射任何新的tuple， storm會等Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS秒之後才殺掉所有的背景工作處理序。這會給topology足夠的時間來完成所有我們執行storm kill命令的時候還沒完成的tuple。

更新一個運行中的topology

為了更新一個正在啟動並執行topology, 唯一的選擇是殺掉正在啟動並執行topology然後重新提交一個新的。一個計劃中的命令是實現一個storm swap命令來運行時更新topology， 並且保證前後兩個topology不會同時在運行，同時保證替換所造成的“停機”時間最少。

監控topology

監控topology的最好的方法是使用Storm UI。Storm UI提供有關task裡面發生的錯誤以及topology裡面每個組件的輸送量和效能方面的統計資訊。同時你可以看看叢集裡面工作機器上面的日誌。

 

【轉】Twitter Storm: 在生產叢集上運行topology