Spark Streaming（一）概述

需求

统计主站每个(指定)课程访问的客户端、地域信息分布
地域：IP转换
客户端： useragent获取
===> 如上两个操作：采用(Spark/MapReduce)的方式进行统计

实现步骤：
课程编号、ip信息、useragent
进行相应的统计分析操作：MapReduce/Spark

项目架构
日志收集：Flume
离线分析：MapReduce/Spark
统计结果图形化展示

问题

按小时级别统计没问题
如果按秒级进行统计，MapReduce则不现实,MapReduce时效性不好，处理时间较长。因为MapReduce是适合做离线批处理的，对于数据量并不关心(只要硬盘容量够用就可以), 但是MapReduce并不能快速的处理一个作业，并显示结果。因为MapReduce分为Map Task和Reducer Task, 他们都是进程级别的，每一次都需要启动进程，运行完之后销毁进程，这一过程是占用一定的时间的。虽然可以通过JVM复用，让多个Task跑在一个jvm上，但是他的计算模型导致了他并不适合做我们的实时计算(中间过程还需要写磁盘)

如何解决？ 实时流处理框架

实时流处理的产生背景

1. 时效性高
2. 数据量大。原始数据价值密度很低，但是数据量大

实时流处理概述

1. 实时计算：响应时间比较短, 离线批处理没有响应时间限制（只要把结果跑出来就可以，有时需要跑十几个小时），实时计算往往需要精确到秒级或毫秒级
2. 流式计算：在不断产生的数据流上进行计算。数据是源源不断进来，永远没有尽头。犹如滔滔江水连绵不绝又如黄河泛滥一发不可收拾。
3. 实时流式计算：在不断产生数据流的过程中实时计算。

离线计算与实时计算对比

1. 数据来源
   离线：HDFS历史数据 数据量比较大
   实时：消息队列(Kafka), 实施新增/修改记录过来的某一笔数据。
2. 处理过程
   离线：MapReduce：map + reduce
   实时：Spark(DStream/SS)
3. 处理速度
   离线：速度慢
   实时：快速
4. 进程
   离线：启动+销毁
   实时：7*24 运行

实时流处理框架对比

通常情况下, 一种业务场景有多个框架能够满足需求。

1. Apache Storm
2. Apache Spark Streaming：基于spark API做了一个扩展，并不会像Storm那样每一次处理一个数据。而是把时间间隔内所有数据拆封成一个个小批处理。所以Spark Streaming严格意义上来说并不是实时处理框架，而是一个微批处理框架。
3. Flink
4. IBM Stream
5. Yahoo! S4
6. LinkedIn Kafka

实时流处理架构与技术选型

为什么不能直接将Flume手机的日志直接丢给Spark/Storm中呢？因为一般的访问行为会有高峰期和低谷期，如果在高峰期直接发送给Spark中后，spark有可能会扛不住这么大的数据量导致崩溃，所以一般将数据先存放至Kafka中去，然后spark/storm直接从Kafka中获取数据，这里的Kafka就可以起到一个缓冲的作用，然后将处理后的结果存放在关系型数据库中去，然后可视化展示。

实时流处理在企业中的应用

1. 电信行业：当你手机流量快要用光的时候，运营商会给你发送一个提醒短信。会实时根据流量使用情况告诉你。你就可以快速的知道流量使用情况。如果采用离线批处理，时效性就很不好。这就是一个实时流处理。
2. 电商行业：双十一大屏