大数据实时处理--架构分析

• 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出问题，也能保障整个流程运转正常。

 

标签：Flume,实时处理,架构,--,LogServer,Kafka,Streaming,Spark,数据
来源： https://www.cnblogs.com/jieqiong1755/p/15401066.html