需求
统计主站每个(指定)课程访问的客户端、地域信息分布
地域:IP转换
客户端: useragent获取
===> 如上两个操作:采用(Spark/MapReduce)的方式进行统计
实现步骤:
课程编号、ip信息、useragent
进行相应的统计分析操作:MapReduce/Spark
项目架构
日志收集:Flume
离线分析:MapReduce/Spark
统计结果图形化展示
问题
按小时级别统计没问题
如果按秒级进行统计,MapReduce则不现实,MapReduce时效性不好,处理时间较长。因为MapReduce是适合做离线批处理的,对于数据量并不关心(只要硬盘容量够用就可以), 但是MapReduce并不能快速的处理一个作业,并显示结果。因为MapReduce分为Map Task和Reducer Task, 他们都是进程级别的,每一次都需要启动进程,运行完之后销毁进程,这一过程是占用一定的时间的。虽然可以通过JVM复用,让多个Task跑在一个jvm上,但是他的计算模型导致了他并不适合做我们的实时计算(中间过程还需要写磁盘)
如何解决? 实时流处理框架
实时流处理的产生背景
- 时效性高
- 数据量大。原始数据价值密度很低,但是数据量大
实时流处理概述
- 实时计算:响应时间比较短, 离线批处理没有响应时间限制(只要把结果跑出来就可以,有时需要跑十几个小时),实时计算往往需要精确到秒级或毫秒级
- 流式计算:在不断产生的数据流上进行计算。数据是源源不断进来,永远没有尽头。犹如滔滔江水连绵不绝又如黄河泛滥一发不可收拾。
- 实时流式计算:在不断产生数据流的过程中实时计算。
离线计算与实时计算对比
- 数据来源
离线:HDFS历史数据 数据量比较大
实时:消息队列(Kafka), 实施新增/修改记录过来的某一笔数据。 - 处理过程
离线:MapReduce:map + reduce
实时:Spark(DStream/SS) - 处理速度
离线:速度慢
实时:快速 - 进程
离线:启动+销毁
实时:7*24 运行
实时流处理框架对比
通常情况下, 一种业务场景有多个框架能够满足需求。
- Apache Storm
- Apache Spark Streaming:基于spark API做了一个扩展,并不会像Storm那样每一次处理一个数据。而是把时间间隔内所有数据拆封成一个个小批处理。所以Spark Streaming严格意义上来说并不是实时处理框架,而是一个微批处理框架。
- Flink
- IBM Stream
- Yahoo! S4
- LinkedIn Kafka
实时流处理架构与技术选型
为什么不能直接将Flume手机的日志直接丢给Spark/Storm中呢?因为一般的访问行为会有高峰期和低谷期,如果在高峰期直接发送给Spark中后,spark有可能会扛不住这么大的数据量导致崩溃,所以一般将数据先存放至Kafka中去,然后spark/storm直接从Kafka中获取数据,这里的Kafka就可以起到一个缓冲的作用,然后将处理后的结果存放在关系型数据库中去,然后可视化展示。
实时流处理在企业中的应用
- 电信行业:当你手机流量快要用光的时候,运营商会给你发送一个提醒短信。会实时根据流量使用情况告诉你。你就可以快速的知道流量使用情况。如果采用离线批处理,时效性就很不好。这就是一个实时流处理。
- 电商行业:双十一大屏