stack

README.md

@@ -73,10 +73,10 @@ TODO
 
 ## 五、Storm
 
-1. Strom简介
+1. [Strom和流处理简介](https://github.com/heibaiying/BigData-Notes/blob/master/notes/installation/Storm和流处理简介.md)
 2. [Storm核心概念详解](https://github.com/heibaiying/BigData-Notes/blob/master/notes/Storm核心概念详解.md)
 3. [Storm单机版本环境搭建](https://github.com/heibaiying/BigData-Notes/blob/master/notes/installation/Storm%E5%8D%95%E6%9C%BA%E7%89%88%E6%9C%AC%E7%8E%AF%E5%A2%83%E6%90%AD%E5%BB%BA.md)
-4. Storm编程模型
+4. [Storm编程模型详解](https://github.com/heibaiying/BigData-Notes/blob/master/notes/installation/Storm编程模型详解.md)
 
 ## 六、Flume
 

notes/Storm和流处理简介.md

@@ -0,0 +1,53 @@
+Storm和流处理简介
+
+一、storm简介
+
+1.1 简介
+
+storm 是一个开源的分布式实时计算系统，可以简单、可靠进行大数据流的处理。通常用于实时分析，在线机器学习、持续计算、分布式RPC、ETL等场景。其具有以下特点：
+
++ 支持水平横向扩展；
++ 具有高容错性，通过ACK机制每个消息都不丢失；
++ 处理速度非常快，每个节点每秒能处理超过一百万个tuples ；
++ 易于设置和操作，并可以与任何编程语言一起使用；
++ 支持本地模式，这意味着你开发的代码不必每次都要提交到服务器上才能运行，对于开发人员来说非常友好；
++ 支持图形化管理界面。
+
+
+
+1.2 Storm与Hadoop对比
+
+Hadoop采用HDFS存储数据，采用MapReduce处理数据。MapReduce主要是进行数据的批处理，这使得Hadoop更适合于海量数据的离线处理，却不适合于实时性要求比较高的场景。而Strom的设计目标就是就是对数据进行实时计算，这使得其更适合实时数据分析等场景。
+
+1.3 Strom与spark Streaming对比
+
+严格意义上说spark Streaming并不是实时计算框架。 Spark Streaming接收实时输入的数据流，并将数据拆分为批处理，由Spark引擎处理后批量生成结果流。只不过 Spark Streaming 能够将数据流按秒级进行拆分，使得其能够得到接近于流处理的效果，但其本质上还是批处理（或微批处理）。
+
+![streaming-flow](D:\BigData-Notes\pictures\streaming-flow.png)
+
+1.4 Strom 与 Flink对比
+
+storm和Flink都是真正意义上的实时计算框架。其对比如下：
+
+|          | storm                                                        | flink                                                        |
+| -------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| 状态管理 | 无状态                                                       | 有状态                                                       |
+| 窗口支持 | 对事件窗口支持较弱，缓存整个窗口的所有数据，窗口结束时一起计算 | 窗口支持较为完善，自带一些窗口聚合方法，并且会自动管理窗口状态 |
+| 消息投递 | At Least Once                                                | Exactly Once                                                 |
+| 容错方式 | ACK机制：对每个消息进行全链路跟踪，失败或者超时时候进行重发  | 检查点机制：通过分布式一致性快照机制，对数据流和算子状态进行保存。在发生错误时，使系统能够进行回滚。 |
+
+
+> 注 : 一般来说，对于消息投递，一般有以下三种方案：
+> + At Most Once : 投递保证每个消息会被投递0次或者1次，在这种机制下消息很有可能会丢失；
+> + At Least Once :投递保证了每个消息会被默认投递多次，至少保证有一次被成功接收，信息可能有重复，但是不会丢失；
+> + Exactly Once  : 每个消息对于接收者而言正好被接收一次，保证即不会丢失也不会重复。
+
+二、流计算
+
+
+
+
+
+参考资料
+
+1. [流计算框架Flink与Storm的性能对比](http://bigdata.51cto.com/art/201711/558416.htm)