实时流处理架构示意图

___
|Web|
|   |----------------> WebServer---------->Flume---->Kafka  
|app|             /var/log/access.log                  |
|___|                                                  |
													  \|/
                                                   Spark/Storm
												       |
												      \|/
							可视化展示 <----------RDBMS/NoSql

Spark和MapReduce对比

|
|-MapReduce特点|--1.仅支持Map和Reduce两种操作
|              |--2.处理效率低效。
|              |　　a）Map中间结果写磁盘，Reduce写HDFS，多个MR之间通过HDFS交换数据; 任务调度和启动开销大;
|              |　　b）无法充分利用内存
|              |　　c）Map端和Reduce端均需要排序
|              |--3.不适合迭代计算(如机器学习、图计算等)，交互式处理(数据挖掘) 和流式处理(点击日志分析)
|
|-Spark特点|--1.运行速度快(基于内存计算和引入DAG执行引擎);
|          |    如果数据由磁盘读取，速度是hadoop mapreduce的10倍以上，
|          |    如果数据从内存读取，速度是hadoop mapreduce的100倍以上。
|          |--2.易用性好，spark不仅支持scala编程呢个，还支持java和python编写。
|          |--3.通用性好
|          |--4.随处运行
|          
|-spark和mapreduce的比较|1.spark把中间数据放在内存中，迭代运算效率高。     
|                       |  mapreduce中的计算结果保存在磁盘上，
|                       |  而spark支持DAG图的分布式并行计算的编程框架，减少了迭代过程中数据的落地，提高了处理效率。
|                       |
|                       |2.spark容错性高。
|                       |  引进了RDD,如果数据集一部分丢失，则可以重建。另外，在RDD计算时可以通过checkpoint来实现容错。
|                       |
|                       |3.spark更加通用。不像hadoop只提供map和reduce两种操作。
|                       |  spark提供的数据集操作类型有很多种，大致分为转换操作和行动操作。
|                       |  转换操作包括map,filter,flatmap,sample,groupbykey,reducebykey,union,join,cogroup,mapvalues,sort和partionby等多种操作类型，
|                       |  行动操作包括collect,reduce,lookup和save等操作类型。
|                       |  另外，各个处理节点之间的通信模型不再像Hadoop只有shuffle一种模式，用户可以命名，物化，控制中间结果的存储，分区等。

Spark(Streaming)和Storm对比

|
|_特性对比________________________________________________________
|          |      Stom              |   Spark                     |
|__________|________________________|_____________________________|
|计算模型  | 纯实时,来一条处理一条  |  准实时,对一个时间段内的数据|
|          |                        |  收集起来,作为一个RDD再处理 |
|          |                        |                             |
|计算延时  | 毫秒级                 |  秒级                       |
|          |                        |                             |
|吞吐量    | 低						|  高                         |
|          |                        |                             |
|事务机制  | 支持完善 				|  支持,但不够完善            |
|          |                        |                             |
|健壮性    | Zookeeper,Acker,非常强 |  Checkpoint，WAL，一般      |
|          |                        |                             |
|动态并行度| 支持   				|  不支持                     |
|__________|________________________|_____________________________|
|                                             
|-Storm适用场景|--1.需要纯实时，不能忍受1秒以上延迟的场景下使用，
|              |    比如实时金融系统，要求纯实时进行金融交易和分析       
|              |--2.对于实时计算的功能中，要求可靠的事务机制和可靠性机制，即数据的处理完全精准，
|              |    一条也不能多，一条也不能少，也可以考虑使用Storm
|              |--3.若还需要针对高峰低峰时间段，动态调整实时计算程序的并行度，
|              |    以最大限度利用集群资源（通常是在小型公司，集群资源紧张的情况），也可以考虑用Storm
|              |--4.如果一个大数据应用系统，它就是纯粹的实时计算，
|              |    不需要在中间执行SQL交互式查询、复杂的transformation算子等，那么用Storm是比较好的选择
|
|-Spark适用场景|--1.不要求纯实时，不要求强大可靠的事务机制，不要求动态调整并行度，
|              |    那么可以考虑使用Spark Streaming
|              |--2.如果一个项目除了实时计算之外，还包括了离线批处理、交互式查询等业务功能，
|              |    而且实时计算中，可能还会牵扯到高延迟批处理、交互式查询等功能，
|              |    那么就应该首选Spark生态,三者可以无缝整合
|              |                       |
|              |                       |---用Spark Core     开发离线批处理
|              |                       |---用Spark SQL      开发交互式查询
|              |                       |---用Spark Streaming开发实时计算
|              |--3.吞吐量要求很高的场景(但并不是所有实时计算场景下,都那么注重吞吐量)