3.storm周邊框架

• ZooKeeper（zookeeper.apache.org）

可以再cdh5上面下載（話說這個網站好強大）
安裝zookeeper到hdp3
啟動server端和cli端
可以在cli help ls（檢視zookeeper的檔案系統）

cli:
建立一個znode ：create /zk_test my_data(字串繫結到這個node上面了)

• LogStash（收集日誌資料的工具，類似Flume）

ELK框架(elastic.co ELK是三個開源軟體的縮寫，分別表示：Elasticsearch , Logstash, Kibana）
下載連結

https://www.elastic.co/cn/downloads/past-releases/logstash-2-4-1
實際工作都是些配置檔案
有很多可以收集資料的流，如es elasticSearch file stdin等等，輸出可以指定codec（json格式等）

• Kafka （0.9.0.0版本2015）

見kafka章節：https://blog.csdn.net/qq_33907408/article/details/85202666
原始碼：scala（2.11）

• Logstash整合Kafka

logstach向kafka producer API中寫訊息
注意版本（kafka client版本0.9—logstach版本(2.4-5.x)—plugin(4.x)版本）

4. Storm架構（重要）

• 架構

和hadoop中的namenode和datanode一樣
在storm中nimbus表示主節點，supervisor表示從節點
不同的是：他們都是無狀態的，所有的元資料都存放zookeeper上面某一個znode裡面
nimbus主節點：負責任務（task）的指派和分發，資源的分配，是總經理
supervisor：上面可以啟動或者停止多個worker程序（配置指定），是包工頭；worker是具體幹活的工人
一個topology對應幾個worker也是可以設定的
worker程序上面 的task是指spout和bolts執行緒
executor：spout和bolt可能會共享一個執行緒

• 部署（單機版、叢集版）

jdk 1.8
python centos7 自帶2.6.6

storm1.2.2(161M) https://www.apache.org/dyn/closer.lua/storm/apache-storm-1.2.2/apache-storm-1.2.2.tar.gz
自帶一個zookeeper：dev_zookeeper
drpc:分散式的遠端呼叫

啟動

後臺啟動dev-zookeeper：nohup sh storm dev-zookeeper &

nohup sh storm nimbus & ====>(jps:dev_zoo,config_value)
nohup sh storm ui & ====>(jps:dev_zoo,core,nimbus)(UI預設訪問埠是8080）ziboris3:8080

nohup sh storm supervisor & ====>(jps:dev_zoo,core,nimbus,supervisor)
slot就是worker，預設啟動了4個worker
nohup sh storm logviewer & ====>(jps:dev_zoo,core,nimbus,supervisor,logviewer)能在UI上面檢視log，同時在STORM_HOME裡面生成一個log資料夾，裡面很多log檔案

IDEA程式碼打包：view-tools window-maven projects-package
package三個類才14k（很小）不含執行環境和依賴

storm jar /home/hadoop/ZZBfiles/stormFile/storm-1.0.jar com.imooc.bigdata.ClusterlSumStormTopology
停止這topology可以在ui上面進入topology（類的名稱點進去–kill–設定死亡倒計時）；同時也可以通過命令列kill掉（請不要直接kill -9殺掉worker程序）storm kill topology-name [-w wait-time-sec] (有個預設的時間差)
停止叢集 直接kill -9

叢集部署規劃

5.並行度（executor的數量）

• worker數量設定
• executor數量設定
• task數量設定
• acker數量設定
  不需要對叢集進行擴容，修改程式碼提高並行程度
  一個topology對應一個或者多個worker程序
  worker下面並非直接是task，是executors執行緒們，一個executor執行緒可以是一個或者多個task

【預設情況】
一個supervisor最多啟動4個worker程序（submit函式的Config能調整）
一個topology對應一個worker程序
一個執行緒–一個executor–一個task（builder裡面設定Executor數量）
預設acker是和worker的數量一樣的，一個acker帶一個task（config設定）

n那麼問題來了！
簡單的求和程式碼，見storm（1），應該只有兩個task，就是兩個executor，為什麼顯示會有三個呢？

答案：實際上還有一個acker導致的（單獨的執行緒）

6.storm分組策略（Stream Grouping）

流在bolts應該怎麼分割槽（partition）

• 6.1 Shuffle Grouping

分發tuple的時候，分到每個bolt裡面的tuple數量是保證相等的。

• 6.2 Fields Grouping

tuple根據userId進行分組，相同的userId tuple分到同一個task中，不同去不同
根據奇偶的話 雖然設定了三個執行緒，但是真正幹活的只有兩個執行緒（並行度設定並不合理）
如果奇偶只設定一個執行緒，那麼不會丟失資料，會都在這個bolt的埠上面輸出

• 6.3 Partial Key Grouping

也是根據指定的欄位開始分組，但是不同的是多了一個負載均衡的概念。將會在下游的bolt做負載均衡，如果有資料傾斜（資料分割槽不均勻）的時候可以得到更好的利用。

• 6.4 All grouping（WITH CARE！）

所有資料會被複制傳送到所有的下一級bolt（是否有必要，什麼場景需要？）

7. storm可靠性（容錯性）

• 7.1 程序級別容錯（worker,supervisor,nimbus）

• 如果worker死亡，supervisor會檢視重啟他，如果一直不行，nimbus出面講這個worker在其他supervisor上面啟動
• task節點死亡，在這個節點上面分配的任務超時之後就會被感知到，nimbus會將這些task重新分配

如果是Nimbus、Supervisor程序死亡：
fail-fast快速失敗機制：都是無狀態的，元資料資訊都保持在ZooKeeper上面
zookeeper在監視著，能夠自己重啟，跟沒事人一樣，只是新提交的作業提交不上去了（和hadoop1.0不同，jobtracker掛掉了，所有的正在執行的job都丟失了）

SPOF（單點故障：single point of failure）
如果單點nimbus掛掉，所有的worker因為不在這個機器上面，也不需要往nimbus上面傳輸元資料，因此是沒有關係的，能夠正常跑完
只是worker如果在出故障，不能被重新分配到新的supervisor上面而已

• 7.2 ack/fail確認機制