Storm_应用设计

1. 理解Storm

   ① storm中的spout、bolt都可以是并行的，它将逻辑上不相互依赖的同一层处理关系复制成多份同时执行，并且，多个执行间的相互协调由storm框架本身提供。

   ② 对于前后依赖的层级间关系，storm提供的强关联性保证只有前面的处理顺利执行完毕，后面的逻辑才能得到执行。

   ③ Storm的实时性一方面源于不对历史数据作过多关注，也正因此，storm作为数据处理框架不提供对历史数据的保存。当然，通过保存tuple值到指定大小queue中，storm可以进行近期批量提交处理，即作为批量和实时的折衷。而批量的大小，取决于内存的大小。

   ④ 为保证storm实时处理，计算逻辑应尽量只依赖于当前数据，且不宜在处理过程中出现过多的交互，如数据的入库出库。变化应尽量只出现在数据本身，而并非交互。当出现交互时，尽量将交互次数降低，例如，通过批量数据与数据库进行交互。

   ⑤ 较好的例子是：Kafka——storm——Kafka，源数据不断的写入到Kafka，storm spout消费者组多点消费以提高并行度、bolt视逻辑复杂度以合适的并行度进行处理，最后由storm bolt将处理后的数据写入Kafka。在此，Kafka充当了两次数据缓冲的作用。第一次缓冲，解决了源数据写入和storm消费之间的耦合和速度不匹配；第二次缓冲解决了storm数据处理和最终数据写入数据库之间的耦合和速度不匹配。

   ⑥ Kafka——storm——Kafka模式，将处理逻辑中的强依赖关系锁在storm topology中；将处理逻辑中的弱依赖关系锁在storm<——>Kafka之间，具体表现为：storm topology1从Kafka topic1中获取源数据进行处理并将结果写入Kafka topic2，storm topology2从Kafka topic2中获取topology1处理的结果进行进一步处理并将结果写入Kafka topic3，以此类推。此时，可根据各topology处理逻辑的复杂度提高相应的并行度，同时，由于Kafka的缓冲作用，弱依赖关系中的某一环节可容忍一定时间的失败，最后，Kafka topic的广播消费可使得数据被同时批量写入数据库而不影响storm处理速度。

   ⑦ Kafka——storm——Kafka模式同时也解耦了不同topology之间的弱依赖关系，一方面Kafka阻塞监听式的消费保证了弱依赖关系下前后处理的实时性，另一方面，保证了各处理逻辑的独立性。

   ⑧ Storm特征分析

   适用场景    不依赖于历史数据的计算
   数据量      每一条数据单独处理或小批量处理（具体视内存大小而定）
   逻辑关系的处理     强依赖由topology内部控制，弱依赖由Kafka解耦
   优势          因为处理的是实时数据，因此保持了计算的实时性
   

2. Storm与Hadoop，实时与离线处理：以日志分析为例

   在网站或者应用的各个页面的事件中嵌入Tracker 系统的API ，设置一定的策略发送到日志服务器，然后再同步到Kafka 等消息队列。对于需要实时日志的应用， 一般通过Storm 等流式计算框架从消息队列中拉取消息，完成相关的过滤和计算， 最后存到HBase 、MySQL 等数据库中；对于实时性要求不高的应用，消息队列中的日志消息通过Cloudera 的Flume 系统Sink 到HDFS 中， 然后一般通过ETL 、Hive 或者批处理的Hadoop 作业等抽取到HBase、MySQL 等数据库中。当然，日志服务器的数据也可以通过Flume 系统Sink 到Kafka等消息队列中，供Storm 实时处理消息。

3. 以Kafka作为数据缓冲或称数据暂存区的意义

   ① 数据源的产生往往是基于“推”的模式向其他分析程序传递数据，而storm是主动抓取数据进行分析处理，属于“拉”。而Kafka则同时支持了“推”和“拉”。
   ② 即使storm实现了一个接受“推”的模型（如在storm中增加内存队列等），当数据源突然增加时有可能导致storm上应用并发度不足而引起其他状态，此时相当于Dos攻击

4. Storm topology设计

   ① 如果没有依赖关系，即多个bolt同时从spout获取数据并同时开始处理，此时，需要所有bolt处理结束才表示该tuple处理结束。这样的场景，对于多个bolt处理时间相差较大的逻辑，将浪费topology的处理时间。即使处理时间相当，多个处理逻辑将加大topology失败的风险，同时也不利于调试。建议将没有依赖关系的逻辑分离，由单独的topology进行处理。

   ② 当多个bolt处理逻辑具有依赖关系时，例如，bolt2需要将bolt1（过滤数据）处理的结果数据进行合并之后才能作进一步的处理，并且bolt1处理的结果数据只用于bolt2的处理。此时，将两个bolt设置为一个topology是合适的。如果bolt1和bolt处理时间上相差很大，应考虑重新设置处理逻辑。

   ③ 当多个bolt处理逻辑具有依赖关系且bolt1处理的结果数据存在多个使用场景时，可将该处理结果缓存至Kafka，只将耗时与bolt1相当的bolt2组成同一个topology。对于耗时过多的bolt可考虑以单独的topology从Kafka进行消费处理。