铭文一级：
第二章：初识实时流处理
需求：统计主站每个(指定)课程访问的客户端、地域信息分布
地域：ip转换 Spark SQL项目实战
客户端：useragent获取 Hadoop基础课程
==> 如上两个操作：采用离线(Spark/MapReduce)的方式进行统计
实现步骤：
课程编号、ip信息、useragent
进行相应的统计分析操作：MapReduce/Spark
项目架构
日志收集：Flume
离线分析：MapReduce/Spark
统计结果图形化展示
问题
小时级别
10分钟
5分钟
1分钟
秒级别
如何解决？？？ ==》 实时流处理框架
离线计算与实时计算的对比
1) 数据来源
离线： HDFS 历史数据 数据量比较大
实时： 消息队列(Kafka)，实时新增/修改记录过来的某一笔数据
2）处理过程
离线： MapReduce： map + reduce
实时： Spark(DStream/SS)
3) 处理速度
离线： 慢
实时： 快速
4）进程
离线： 启动+销毁
实时： 7*24
第三章：分布式日志收集框架Flume
现状分析：见图
如何解决我们的数据从其他的server上移动到Hadoop之上？？？
shell cp hadoop集群的机器上， hadoop fs -put ..... /
===> Flume
铭文二级：
第二章：初识实时流处理
实时流处理框架的产生背景：时效性高 数据量大
实时流处理与离线处理的对比=>
1.数据来源 2.处理过程 3.处理速度 4.进程（MapReduce进程启动与销毁 需要消耗大量资源 而且实时性跟不上）
实时流框架对比=>
Storm（真正的来一个处理一个）、Spark Streaming（时间间隔小批次处理）、IBM Stream、Yahoo！S4、LinkedIn kafka、Flink（可离线可实时）
实时流处理流程=>
Webapp->WebServer->Flume->Kafka->Spark/Storm->RDBMS/NoSQL->可视化展示
产生 采集 清洗 分析 入库 可视化
实时流处理在企业中的应用： 电信行业（实时监控流量是否超出） 电商行业
第三章：分布式日志收集框架Flume
传统从Server到Hadoop处理上存在的问题=>
1.难以监控 2.IO的读写开销大 3.容错率高，负载均衡差 4.高延时，需隔一段时间启动