- Spark是一个实时处理框架
- Spark提供了两套实施解决方案：Spark Streaming（SS）、Structured Streaming（SSS）
- 然后再结合其它框架：Kafka、HBase、Flume、Redis
- 项目流程：架构分析、数据产生、数据采集、数据收集、数据实时交换、实时流处理、结果可视化、调优
- 1）【项目启动】架构分析
- 2）【环境部署】基础开发环境搭建
- 2）【数据产生】
- 3）【数据采集】构建日志服务器（偏重于日志产生及存储）
- 4）【数据收集】基于Flume构建分布式日志收集（偏重于数据从A地方到B地方的操作）
- 5）【消息队列】基于Kafka构建实时数据交换
- 6）【实时流处理】Spark Streaming核心API
- 7）【实时流处理】应用Spark Streaming实现数据分析及调优
- 8）【实时流处理】Structured Streaming应用
- 9）【实时流处理】应用Structured Streaming实现数据分析及调优
- 10）【数据可视化】使用Echarts完成数据展示
- 架构图
- 1）日志采集：自定义一个日志服务
- 2）数据收集交换：使用Flume将日志服务数据收集过来，落在Kafka上
- 3）实时处理：基于Spark Streaming（SS）、Structured Streaming（SSS）来对接Kafka的数据
- 4）数据存储：第3）步处理后的数据，Spark Streaming处理的数据存储至HBase中，Structured Streaming处理的数据存储至Redis
- 5）查询API：页面的请求通过API，即使用Spring Boot、Spring Data来查询HBase和Redis里的数据，并把数据放置可视化里。在可视化里是通过Echarts来展示。也会使用到React来封装Echarts。
- 6）整个项目的运行环境：产商云主机、物理机、虚拟机
- 更详细的流程
- 1）客户端所产生的日志，通过Nginx协议端过来后，给它负载均衡落在LogServer上，其中LogServer是自定义开发的。
- 2）然后，会使用两层的Flume架构，第一层Flume用于收集LogServer上的数据，第二层Flume对接第一层并做聚合操作（这样操作的原因，后续讲解）
- 3）其次，Flume收集的数据，对接到Kafka
- 4）后面交给流处理引擎来处理，处理后的结果存储到存储层
- 5）最后，使用API这层，将存储的结果通过UI进行可视化展示
- Spark和Kafka对接的offsets管理维护
- 1）首先，在Kafka集群里，做分区。
- 2）Kafka分区后，与Spark Streaming做对接
- 3）基于DStream，Spark Streaming可以进行一些处理，处理后将结果存储下来。
- 4）处理的批次对应的offset是哪些呢？需要通过commit offsets存储到HBase/Kafka/ZK/MySQL
- 5）如果作业挂掉/出现异常，机器重启，在DStream处理时，应该从已经存储过的offsets的HBase/Kafka/ZK/MySQL，往后进行操作，这样才能保证数据是准确的。
- 展示效果
- 1）当天每小时用户访问时长（当天零点开始，到某一个时间点的用户访问时长（连带轮动））
- 2）当天用户时长的Top10
- 3）用户访问区域的统计（以地图方式展示），根据具体日期展示各省份访问次数的Top10
- 4）不同性别、年龄段访问人数统计
- 环境参数
- 1）Spark：3*版本
- 2）Hadoop生态：CDH（5.16.2）
- 3）Kafka：2.5.0
- 4）Redis：6.0.6
- 5）JDK：1.8
- 6）Scala：2.12
- 7）Linux版本：CentOS 7
- 8）Maven：3.6.3
- 项目目的
- 1）从总体到细节掌握大数据实时处理的解决方案
- 2）各个框架各司其职，并做好各个框架之间的衔接
- 3）基于第二点，做到框架的高可用。在实际生产中，不仅仅要跑通，还要考虑每个环节的高可用。假如一个环节出问题，不能影响整体的一个流程。
- 技术选型
- 0）基础：Hadoop
- 1）数据产生：SDK来完成，代码的方式
- 2）数据采集：SpringBoot来构建日志服务器
- 3）数据收集：Flume
- 4）数据交换/消息队列：Kafka
- 5）实时流处理：SS、SSS
- 6）结果存储：HBase、Redis
- 7）可视化：Echarts、React
- 项目架构V1版本
- 1）用户---（问题1/2）---->LogServer----(source)--->Flume----(sink)--->Kafka Clauster (Topic)(实时)（问题3）------->Spark------->DB------->API------->UI
- 2）V1版本存在的问题1：实际上LogServer是由很多机器构成，这些机器有着不同的IP地址。不同用户的操作数据，上报到LogServer中不同的机器上，还需要去关注LogServer中不同机器的IP地址吗？当然不应再去关注LogServer相关信息。
- 3）V1版本存在的问题2：每一个用户的操作数据和LogServer中的机器，不可能一一对应，所以这里缺少负载均衡。所以用户的操作数据通过负载均衡，让数据比较均衡的落在LogServer中每个机器上。
- 4）V1版本存在的问题3：离线处理及实时处理的数据源都是一样的。Kafka是实时处理，当然也可以放入HDFS中进行离线处理。单层的Flume是存在隐患的，它没有任何负载均衡和容错性可言，一旦sink出问题，会影响整个流程的运转。
- 项目架构V2版本
- 1）用户------->Nginx Cluster------->LogServer----(source)--->Flume 1----(sink)--->Flume 2------->Kafka Clauster (Topic)(实时)------->Spark------->DB------->API------->UI
- 2）Nginx Cluster来完成负载均衡
- 3）Flume 2 进行聚合操作，相当于是容错机制。如果第一套sink出问题了，采用第二套sink。做一个高可用的配置，使得第一个sink出问题，也能保障整个流程运转正常。