推薦慕課網視頻：http://www.imooc.com/video/10055

====Storm的起源。

Storm是開源的、分布式、流式計算系統

什么是分布式呢？就是將一個任務拆解給多個計算機去執行，讓許多機器共通完成同一個任務，

把這個多機的細節給屏蔽，對外提供同一個接口、同一個服務，這樣的系統就是分布式系統。

在多年以前并沒有非常范用的分布式系統，即使存在，也都是限定在指定的領域，

當然，也有人嘗試從中提取出共通的部分，發明一個通用的分布式系統，但是都沒有很好的結果。

后來，Google發表了3篇論文，提出了分布式計算的模型，在分布式系統上有了一個質的突破。

有一位大牛看了這3篇論文之后，深受啟發，然后就發明了Hadoop系統。

然后，基于Hadoop的改造系統就如雨后春筍一般，接二連三的出現了。

以至于，Hadoop已經不是一套軟件，而是一整套生態系統了。

于是，人們談到分布式，就必談Hadoop了。

但是，Hadoop并不是萬能的，它只能處理適合進行批量計算的需求。對于，非批量的計算就不能夠滿足要求了。

很多時候，我們只能先收集一段時間數據，等數據收集到一定規模之后，我們才開始MaPReduce處理。

有這么一個故事：

-------------------

路人甲是在一家媒體公司A工作，他的主要工作內容很簡單，就是在一些搜索引擎上做廣告，

眾所周知，搜索引擎上的廣告是競價排名的，誰土豪誰就排前面，出錢少的就只能排在后面。

公司A的競爭對手都比較土豪，所以呢，公司A的廣告就一直排在后面，也沒什么好的辦法。

后來，路人甲想出了一個餿主意，就是用程序不斷的去點擊競爭對手的廣告，讓對手的廣告費

很快的花費調，這樣公司A就可以廉價的將廣告排在前面了。

搜索引擎公司試圖識別出這些惡意點擊屏來保護商家，將這些惡意點擊扣除的費用返還給商家。

一般來說呢，如果利用MapReduce，一般情況下，都需要收集一段時間數據，然后根據這些

數據來算出哪些點擊是惡意的，本身收集數據就已經很耗費時間了，再等計算完畢之后，

土豪商家的廣告費也基本上不剩什么了。

所以呢，我們希望在點擊發生的時候就算出來該點擊是否是作弊行為，及時不能馬上判斷出，

也應該盡早的計算出來。

-------------------

 為了解決上面這個故事的需求，分布式流式計算系統就產生了，比較知名的有：

?【Yahoo】S4

?【IBM】StreamBase

?【Amazon】Kinesis

?【Spark】Streaming

?【Google】Millwheel

?【Apache】Storm（目前業界中最知名、流程）

批量計算（以Hadoop為代表）與流式計算的區別有哪些呢？

###################

目前已經有人在做一些前瞻性的項目，這些人試圖將批量計算和流式計算進行整合

試圖使用同一套API，即搞定流式計算，又搞定批量計算。

使一段代碼不要任何改動，就可以同時執行在批量計算和流式計算兩種系統之上。

這種系統目前比較有名的有：

【Twitter】Summing Bird

【Google】CloudDataflow

兩個接口都已經開源了。等以后有機會一定要提前接觸一下。

###################

====Storm組件

Storm采用的是主從結構，就是使用一臺主節點來管理整個集群的運行狀態。

這個主節點被稱為：Nimbus，從節點用來維護每臺機器的狀態，被稱為：Supervisor

為什么采取主從結構呢？主從結構比較簡單，不需要進行主節點仲裁等工作。

從前面的結構圖中我們還可以看出，采取主從結構之后，Nimbus是一個單點，

但是，我們知道分布式領域里，大家都比較討厭自己的系統設計中存在單點，

因為單點如果發生故障，很有可能影響到整個集群的可用性。

所以，如果一個系統設計中如果存在單點，一般情況下這個單點的作業必然比較輕，

掛了之后，短時間之內也不影響真個系統的運行，并且一般情況下都是沒有狀態的，

宕機之后至需要重啟就能夠恢復并正確處理。

Nimbus的角色是只負責一些管理性的工作，它并不關心Worker之間的數據是如何傳輸的，

它的一些主要狀態都存在分布式協調服務(Zookeeper)中，內存里面的東西都是可以丟失的，

如果它掛掉，只要沒有運算節點發生故障，那么整個作業還是能夠正常的進行數據處理的。

Nimbus重啟之后，就可以正確處理真個系統的事務了。

Supervisor的角色是聽Nimbus的話，來啟動并監控真正進行計算的Worker的進程，

如果Worker有異常，那么久幫助Worker重啟一下，它也不負責數據計算和數據傳輸，

真正的數據計算和輸出，都是由Worker來進行。

Worker是運行在工作節點上面，被Supervisor守護進程創建的用來干活的JVM進程。

每個Worker對應于一個給定topology的全部執行任務的一個子集。

反過來說，一個Worker里面不會運行屬于不同的topology的執行任務。

====Storm UI

為了方便用戶管理集群，查看集群運行狀態，提供了一個基于Web的UI來監控整個Storm集群

它本身不是集群運行的必須部分，它的啟動停止都不影響Storm的正常運行。

====Storm作業提交運行流程

（1）用戶使用Storm的API來編寫Storm Topology。

（2）使用Storm的Client將Topology提交給Nimbus。

Nimbus收到之后，會將把這些Topology分配給足夠的Supervisor。

（3）Supervisor收到這些Topoligy之后，Nimbus會指派一些Task給這些Supervisor。

（4）Nimvus會指示Supervisor為這些Task生成一些Worker。

（5）Worker來執行這些Task來完成計算任務。

====StormAPI基礎概念

Storm稱用戶的一個作業為Topology（拓撲）。

為什么叫拓撲呢？是因為Storm的一個拓撲主要包含了許多的數據節點，還有一些計算節點，

以及這些節點之間的邊，也就是說Storm的拓撲是由這些點和邊組成的一個有向無環圖。

這些點有兩種：數據源節點（Spout）、普通的計算節點（Bolt），

點之間的邊稱為數據流（Stream），數據流中的每一條記錄稱為Tuple。

如下圖中，每一個“水龍頭”表示一個Spout，它會發送一些Tuple給下游的Bolt，

這些Bolt經過處理周，再發送一個Tuple給下一個Bolt，

最后，在這些Bolt里面是可以執行一些寫數據到外部存儲（如數據庫）等操作的。

在圖中這個Topology里面我們看到了兩個Spout和5個Bolt，

在實際運行的時候，每個Spout節點都可能有很多個實例，每個Bolt也有可能有很多個實例。

就像MapReduce一樣，一個Map節點并不代表只有一個并發，而有可能很多個Map實例在跑。

這些Spout和Bolt的這些邊里面，用戶可以設置多種的Grouping的方式。

有些類似SQL中的Group By。用來制定這些計算是怎么分組的。

*Fields Grouping：保證同樣的字段移動落到同一個Bolt里。

--以WordCount為例，MapReduce和Storm的工作流程對比：

（1）MapReduce

（2）Storm

====各個組件的一些說明

--Topologies

strom jar all-your-code.jar backtype.storm.MyTopology arg1 arg2

--Stream

--數據模型(Data Model)

參考博客：http://blog.itpub.net/29754888/viewspace-1260026/

====StormAPI使用

我們來看看WorldCount的example代碼。

====Storm的并發機制

Task數量：表示每個Spout或Bolt邏輯上有多少個并發。它影響輸出結果。

Worker數量：代表總共有幾個JVM進程去執行我們的作業。

Executor數量：表示每個Spout或Bolt啟動幾個線程來運行。

下面代碼中的數字表示Executor數量，它不影響結果，影響性能。

Worker的數量在Config中設置，下圖代碼中的部分表示Worker數量。

*本地模式中，Worker數不生效，只會啟動一個JVM進行來執行作業。

*只有在集群模式設置Worker才有效。而且集群模式的時候一定要設置才能體現集群的價值。

====Storm數據可靠性

分布式系統都管理很多臺機器，需要保證任意的Worker掛掉之后，我們的系統仍然能正確的處理，那么

Storm如何保證這些數據正確的恢復？

Storm如何保證這些數據不被重復計算？

（1）Spout容錯API：NextTuple中，emit時，指定MsgID。

（2）Bolt容錯API：①emit時，錨定輸入Tuple。②Act輸入Tuple。

====Storm集群搭建

（1）安裝zookeeper集群

配置方法省略。

（2）下載安裝Storm

官網上下載Storm：http://storm.apache.org

上傳至linux并解壓縮。這里將Storm解壓縮到/opt/apache-storm-0.10.0路徑下了。

（3）修改Storm配置文件

配置文件路徑：/opt/apache-storm-0.9.5/conf/storm.yaml

配置內容如下：

----------------

storm.zookeeper.servers:- "192.168.93.128"- "192.168.93.129"- "192.169.93.130"nimbus.host: "192.168.93.128"storm.local.dir: "/opt/apache-storm-0.9.5/status"supervisor.slots.ports:- 6700- 6701- 6702- 6703

----------------

置之后的文件如下如所示：

--Storm配置項詳細介紹

?storm.zookeeper.servers：

ZooKeeper服務器列表

?storm.zookeeper.port：

ZooKeeper連接端口

?storm.local.dir：

storm使用的本地文件系統目錄(必須存在并且storm進程可讀寫)

?storm.cluster.mode：

Storm集群運行模式([distributed|local])

?storm.local.mode.zmq：

Local模式下是否使用ZeroMQ作消息系統，如果設置為false則使用java消息系統。默認為false

?storm.zookeeper.root：

ZooKeeper中Storm的根目錄位置

?storm.zookeeper.session.timeout：

客戶端連接ZooKeeper超時時間

?storm.id：

運行中拓撲的id，由storm name和一個唯一隨機數組成。

?nimbus.host：

nimbus服務器地址

?nimbus.thrift.port：nimbus的thrift監聽端口

?nimbus.childopts：

通過storm-deploy項目部署時指定給nimbus進程的jvm選項

?nimbus.task.timeout.secs：

心跳超時時間，超時后nimbus會認為task死掉并重分配給另一個地址

?nimbus.monitor.freq.secs：

nimbus檢查心跳和重分配任務的時間間隔。注意如果是機器宕掉nimbus會立即接管并處理

?nimbus.supervisor.timeout.secs：

supervisor的心跳超時時間，一旦超過nimbus會認為該supervisor已死并停止為它分發新任務

?nimbus.task.launch.secs：

task啟動時的一個特殊超時設置。在啟動后第一次心跳前會使用該值來臨時替代nimbus.task.timeout.secs

?nimbus.reassign：

當發現task失敗時nimbus是否重新分配執行。默認為真，不建議修改

?nimbus.file.copy.expiration.secs：

nimbus判斷上傳/下載鏈接的超時時間，當空閑時間超過該設定時nimbus會認為鏈接死掉并主動斷開

?ui.port：

Storm UI的服務端口

?drpc.servers：

DRPC服務器列表，以便DRPCSpout知道和誰通訊

?drpc.port：

Storm DRPC的服務端口

?supervisor.slots.ports：

supervisor上能夠運行workers的端口列表。每個worker占用一個端口，且每個端口只運行一個worker。

通過這項配置可以調整每臺機器上運行的worker數。(調整slot數/每機)

?supervisor.childopts：

在storm-deploy項目中使用，用來配置supervisor守護進程的jvm選項

?supervisor.worker.timeout.secs：

supervisor中的worker心跳超時時間，一旦超時supervisor會嘗試重啟worker進程.

?supervisor.worker.start.timeout.secs：

supervisor初始啟動時，worker的心跳超時時間，當超過該時間supervisor會嘗試重啟worker。

因為JVM初始啟動和配置會帶來的額外消耗，從而使得第一次心跳會超過supervisor.worker.timeout.secs的設定

?supervisor.enable：

supervisor是否應當運行分配給他的workers。默認為true，該選項用來進行Storm的單元測試，一般不應修改.

?supervisor.heartbeat.frequency.secs：

supervisor心跳發送頻率(多久發送一次)

?supervisor.monitor.frequency.secs：

supervisor檢查worker心跳的頻率

?worker.childopts：

supervisor啟動worker時使用的jvm選項。所有的”%ID%”字串會被替換為對應worker的標識符

?worker.heartbeat.frequency.secs：

worker的心跳發送時間間隔

?task.heartbeat.frequency.secs：

task匯報狀態心跳時間間隔

?task.refresh.poll.secs：

task與其他tasks之間鏈接同步的頻率。(如果task被重分配，其他tasks向它發送消息需要刷新連接)

。一般來講，重分配發生時其他tasks會理解得到通知。該配置僅僅為了防止未通知的情況。

?topology.debug：

如果設置成true，Storm將記錄發射的每條信息。

?topology.optimize：

master是否在合適時機通過在單個線程內運行多個task以達到優化topologies的目的

?topology.workers：

執行該topology集群中應當啟動的進程數量。

每個進程內部將以線程方式執行一定數目的tasks。topology的組件結合該參數和并行度提示來優化性能

?topology.ackers：

topology中啟動的acker任務數。

Acker保存由spout發送的tuples的記錄，并探測tuple何時被完全處理。

當Acker探測到tuple被處理完畢時會向spout發送確認信息。通常應當根據topology的吞吐量來確定acker的數目，但一般不需要太多。

當設置為0時，相當于禁用了消息可靠性。storm會在spout發送tuples后立即進行確認

?topology.message.timeout.secs：

topology中spout發送消息的最大處理超時時間。

如果一條消息在該時間窗口內未被成功ack，Storm會告知spout這條消息失敗。而部分spout實現了失敗消息重播功能。

?topology.kryo.register：

注冊到Kryo(Storm底層的序列化框架)的序列化方案列表。序列化方案可以是一個類名，或者是com.esotericsoftware.kryo.Serializer的實現

?topology.skip.missing.kryo.registrations：

Storm是否應該跳過它不能識別的kryo序列化方案。如果設置為否task可能會裝載失敗或者在運行時拋出錯誤

?topology.max.task.parallelism：

在一個topology中能夠允許的最大組件并行度。該項配置主要用在本地模式中測試線程數限制.

?topology.max.spout.pending：

一個spout task中處于pending狀態的最大的tuples數量。該配置應用于單個task，而不是整個spouts或topology

?topology.state.synchronization.timeout.secs：

組件同步狀態源的最大超時時間(保留選項,暫未使用)

?topology.stats.sample.rate：

用來產生task統計信息的tuples抽樣百分比

?topology.fall.back.on.java.serialization：

topology中是否使用java的序列化方案

?zmq.threads：

每個worker進程內zeromq通訊用到的線程數

?zmq.linger.millis：

當連接關閉時，鏈接嘗試重新發送消息到目標主機的持續時長。這是一個不常用的高級選項，基本上可以忽略.

?java.library.path：

JVM啟動(如Nimbus,Supervisor和workers)時的java.library.path設置。該選項告訴JVM在哪些路徑下定位本地庫

（4）配置Storm環境變量

環境變量位置：/etc/profile

配置內容之后如下圖所示：

注意：環境變量修改只有，一定要使用Source命令來使之生效。

（5）啟動Storm

--啟動Storm UI

命令：storm ui >/dev/null 2>&1 &

我們可以它啟動的時候相關的輸出指向到/def/null，并且把錯誤也重新定向到正常輸出。

--啟動主節點（Nimbus節點）

命令：storm nimbus >/dev/null 2>&1 &

在第1臺Linux虛擬機上執行。正常啟動時的jps結果如下圖所示：

--啟動工作節點（Supervisor節點）

命令：storm supervisor >/dev/null 2>&1 &

在第2、3臺Linux虛擬機上執行。正常啟動時的jps結果如下圖所示：

（6）啟動StormUI監控頁面：

Storm正常啟動之后，應該可以打開StormUI畫面。在瀏覽器中輸入地址和端口即可

正確啟動時應該如下圖所示：

--Mainpage：

main頁面主要包括3個部分

 【Cluster Summary】

?Nimbus uptime: nimbus的啟動時間

?Supervisors: storm集群中supervisor的數目

?used slots: 使用了的slots數

?free slots: 剩余的slots數

?total slots: 總的slots數

?Running tasks: 運行的任務數

【topology summary】

?Name: topology name

?id: topology id (由storm生成)

?status: topology的狀態，包括(ACTIVE, INACTIVE, KILLED, REBALANCING)

?uptime: topology運行的時間

?num workers: 運行的workers數

?num tasks: 運行的task數

【supervisor summary】

?host: supervisor(主機)的主機名

?uptime: supervisor啟動的時間

?slots: supervisor的端口數

?used slots: 使用的端口數

--Topology page

topology頁面主要包括4個部分

【topology summary】

(同主頁)

【topology stats】

?window: 時間窗口，顯示10m、3h、1d和all time的運行狀況

?emitted: emitted tuple數

?transferred: transferred tuple數, 說下與emitted的區別：如果一個task，emitted一個tuple到2個task中，則transferred tuple數是emitted tuple數的兩倍

?complete latency: spout emitting 一個tuple到spout ack這個tuple的平均時間

?acked: ack tuple數

?failed: 失敗的tuple數

【spouts】

?id: spout id

?parallelism: 任務數

?last error: 最近的錯誤數，只顯示最近的前200個錯誤

?emitted、transferred、complete latency、acked和failed上面已解釋

【bolts】

?process latency: bolt收到一個tuple到bolt ack這個tuple的平均時間

其他參數都解釋過了

還有componentpage和taskpage，參數的解釋同上。

taskpage中的Component指的是spoutid或者boltid，time指的是錯誤發生的時間，error是指錯誤的具體內容。

====Storm常用命令

【提交Topologies】

命令格式：storm jar 【jar路徑】 【拓撲包名.拓撲類名】 【拓撲名稱】

樣例：storm jar /storm-starter.jar storm.starter.WordCountTopology wordcountTop

#提交storm-starter.jar到遠程集群，并啟動wordcountTop拓撲。

【停止Topologies】

命令格式：storm kill 【拓撲名稱】

樣例：storm kill wordcountTop

#殺掉wordcountTop拓撲。

【啟動nimbus后臺程序】

命令格式：storm nimbus

【啟動supervisor后臺程序】

命令格式：storm supervisor

【啟動drpc服務】

命令格式：storm drpc

【啟動ui服務】

命令格式：storm ui

【啟動REPL】

REPL — read-evaluate-print-loop。

雖然clojure可以作為一種腳本語言內嵌在java里面，但是它的首選編程方式是使用REPL，這是一個簡單的命令行接口，

使用它你可以輸入你的命令，執行，然后查看結果， 你可以以下面這個命令來啟動REPL：

命令格式：storm repl

【打印本地配置】

命令格式：storm localconfvalue [配置參數關鍵字]

舉例：storm localconfvalue storm.zookeeper.servers

#根據指定參數打印本地配置的值。

【打印遠程配置】

命令格式：storm remoteconfvalue [配置參數關鍵字]

舉例：storm remoteconfvalue storm.zookeeper.servers

#根據指定參數打印遠程配置的值。

【執行Shell腳本】

命令格式：storm shell resourcesdir command args

【打印CLASSPATH】

命令格式：storm classpath

====Storm調優：

--調優對象

當一個topology在storm cluster中運行時，它的并發主要跟3個邏輯對象相關：worker => executor =>task。(=>代表1對N)

（1）Worker

Worker是運行在工作節點上面，被Supervisor守護進程創建的用來干活的JVM進程。

每個Worker對應于一個給定topology的全部執行任務的一個子集。

反過來說，一個Worker里面不會運行屬于不同的topology的執行任務。

它可以通過[storm rebalance]命令任意調整。

（2）Executor

可以理解成一個Worker進程中的工作線程。

一個Executor中只能運行隸屬于同一個component（spout/bolt）的task。

一個Worker進程中可以有一個或多個Executor線程。在默認情況下，一個Executor運行一個task。

它可以通過[storm rebalance]命令任意調整。

（3）Task

Task則是spout和bolt中具體要干的活了。一個Executor可以負責1個或多個task。

每個component（spout/bolt）的并發度就是這個component對應的task數量。

同時，task也是各個節點之間進行grouping（partition）的單位。無法在運行時調整。

--設置方法：

conf.setNumWorkers(workers);                                        //設置worker數量

uilder.setBolt("2", new WordSpliter(),4)                             //設置Executor并發數量

builder.setBolt("2", new WordSpliter(),4).setNumTasks(1); //設置每個線程處理的Task數量

--任務分配：

任務分配是有下面兩種情況：

①、task數目比worker多：

例如task是[1 2 3 4]，可用的slot(所謂slot就是可用的worker)只有[host1:port1，host2:port1]，那么最終是這樣分配1：[host1:port1]

2：[host2:port1]

3：[host1:port1]

4：[host2:port1]

②、task數目比worker少：

例如task是[1 2]，而worker有[host1:port1，host1:port2，host2:port1，host2:port2]，

那么首先會將woker排序，將不同host間隔排列，保證task不會全部分配到同一個機器上，也就是將worker排列成

[host1:port1，host2:port1，host1:port2，host2:port2]

然后分配任務為：

1：[host1:port1]

2：[host2:port1]

--簡單舉例：

通過Config.setNumWorkers(int))來指定一個storm集群中執行topolgy的進程數量，所有的線程將在這些指定的worker進程中運行。

比如說一個topology中要啟動300個線程來運行spout/bolt，而指定的worker進程數量是60個。

那么storm將會給每個worker分配5個線程來跑spout/bolt。

如果要對一個topology進行調優，可以調整worker數量和spout/bolt的parallelism(并發度，即executor)數量。

(調整參數之后要記得重新部署topology，后續會為該操作提供一個swapping的功能來減小重新部署的時間)。

例如：builder.setBolt("cpp", new CppBolt(), 3).setNumTasks(5).noneGrouping(pre_name); 會創建3個線程，但有內存中會5個CppBolt對象，3個線程調度5個對象。

--網上搜羅的一些經驗：①、對于worker和task之間的比例，網上也給出了參考,。即1個worker包含10~15個左右。當然這個參考，實際情況還是要根據配置和測試情況。

②、executor數最大不能超過該bolt的task數。

--Strom集群命令

--END--