本实验在 Ubuntu 24.04 环境下完成采用单机伪分布式方式验证整条数据链路。1. 软件环境操作系统Ubuntu 24.04JDKOpenJDK 8Hadoop3.3.6ZooKeeper已部署并启动Kafka单机模式伪分布式运行Flume1.9.0Spark3.5.1Python3.x2. 硬件环境虚拟机内存8GB系统盘20GB扩展数据盘20GB由于系统盘空间有限实验中将 Hadoop、Kafka、Spark 等大数据软件部署到数据盘目录下。3. 实验目录规划Hadoop/data/hadoopKafka/data2/software/kafkaSpark/data2/software/spark输入日志目录/data/logs/inputHDFS 原始日志目录/course/video_logs/rawHDFS 分析结果目录/course/video_logs/analysis三、系统设计与总体流程本实验系统由五个核心部分组成1. 日志生成模块通过 Python 脚本每 2 秒生成一条 JSON 格式日志并写入 /data/logs/input/access.log。2. Flume 采集模块Flume 监听 /data/logs/input 目录中的日志文件将新增日志发送到 Kafka。3. Kafka 缓冲模块Kafka 作为消息缓冲中间件用于接收 Flume 采集到的日志数据并提供后续消费接口。4. HDFS 存储模块原始日志先写入 HDFS 中的 /course/video_logs/raw 目录作为原始数据存储。5. Spark SQL 分析模块使用 Spark SQL 读取 HDFS 上的原始 JSON 日志对行为类型、电影播放次数、用户总观看时长等指标进行统计并将结果写回 HDFS。四、实验步骤与实现过程4.1 Hadoop/HDFS 环境配置与启动首先完成 Hadoop 环境变量配置包括 JAVA_HOME、HADOOP_HOME、HADOOP_COMMON_HOME 等并在 core-site.xml 与 hdfs-site.xml 中完成 HDFS 基础配置。其中fs.defaultFS 配置为 hdfs://localhost:9000NameNode 数据目录配置为 /data2/hadoop/nameDataNode 数据目录配置为 /data2/hadoop/data完成配置后对 NameNode 执行格式化并通过 start-dfs.sh 启动 HDFS 服务。使用 jps 命令检查进程确认出现NameNodeDataNodeSecondaryNameNode说明 HDFS 启动成功。插入截图Hadoop/HDFS 配置截图4.2 ZooKeeper 与 Kafka 配置实验中先启动 ZooKeeper再启动 Kafka Broker。Kafka 中创建主题 video_logs用于接收 Flume 采集到的日志数据。考虑到本实验在单机伪分布式环境下进行为保证主题创建和功能验证成功最终采用如下设置Topic 名称video_logs分区数3副本数1虽然题目理想要求为副本数 2但由于当前实验为单机环境仅启动了单个 Broker因此副本数设置为 1。若扩展为多 Broker 集群环境可将副本数调整为 2。通过 kafka-topics.sh --describe 查看主题信息确认 video_logs 创建成功。插入截图Kafka topic 创建成功截图4.3 日志模拟生成为了模拟视频网站用户行为日志本实验编写了 Python 日志生成脚本 log_generator.py。该脚本每 2 秒随机生成一条 JSON 日志写入/data/logs/input/access.log生成日志字段包括user_idmovie_idactiontimestampduration示例日志如下{user_id:1001,movie_id:m_302,action:play,timestamp:1780559367284,duration:181}通过 tail -f /data/logs/input/access.log 可以实时观察日志持续写入情况。插入截图access.log 持续生成日志截图4.4 Flume 采集与 Kafka 接入实验中使用 Flume 监听 /data/logs/input 目录下的日志文件。Flume 配置中使用 TAILDIR Source 监控日志文件变化使用 memory Channel 缓冲事件并通过 KafkaSink 将日志发送到 Kafka 的 video_logs 主题。关键配置包括监听目录/data/logs/input/.*\.log$Kafka 地址localhost:9092Kafka Topicvideo_logs启动 Flume 后通过 Kafka 消费者终端实时查看 video_logs 中的数据可以看到日志持续进入 Kafka说明 Flume - Kafka 这段链路已经成功打通。插入截图Flume 启动成功截图插入截图Kafka 消费日志截图-4.5 原始日志写入 HDFS为了完成“数据备份到 HDFS”这一要求实验中将 Kafka 中的原始日志导出为本地 JSON 文件再上传到 HDFS 的原始日志目录/course/video_logs/raw/日期目录/上传完成后通过 hdfs dfs -ls 和 hdfs dfs -cat 验证 HDFS 上确实存在原始日志文件并且内容与 Kafka 消费到的 JSON 日志一致。插入截图HDFS 原始目录截图插入截图HDFS 原始日志内容截图4.6 Spark SQL 离线统计分析在原始日志进入 HDFS 后本实验采用 Spark SQL 读取 HDFS 中的 JSON 数据并完成以下三类离线统计1. 行为分布统计2. 统计 play、pause、seek、stop 等行为出现次数3. 电影播放次数统计4. 统计每个 movie_id 的播放次数5. 用户总观看时长统计6. 统计每个 user_id 的总观看时长核心 SQL 思路如下使用 CREATE OR REPLACE TEMPORARY VIEW 建立临时视图使用 INSERT OVERWRITE DIRECTORY 将统计结果写回 HDFS输出目录包括/course/video_logs/analysis/action_distribution/course/video_logs/analysis/movie_play_count/course/video_logs/analysis/user_duration从实验结果看Spark SQL 成功完成了对日志的离线计算并生成了预期的统计结果。插入截图Spark SQL 统计目录截图插入截图Spark SQL 统计结果截图五、关键代码与配置说明5.1 日志生成脚本核心逻辑日志生成脚本通过 random 随机生成用户、视频、行为、时长等字段并写入 JSON 行到日志文件中。该方式简单直观便于模拟持续产生的点击流数据。5.2 Flume 配置核心逻辑Flume 使用 TAILDIR 监听日志文件变更实时采集新增日志通过 KafkaSink 推送到 Kafka Topic 中。该结构符合“文件日志 - Flume - Kafka”的典型日志采集流程。5.3 Spark SQL 统计逻辑Spark SQL 通过 JSON 数据源直接解析原始日志并利用 SQL 语句完成统计。相对于传统 MapReduceSpark SQL 代码更简洁可读性更强更适合本实验中的离线分析需求。六、实验结果分析根据实验结果可以得到以下分析结论1. 行为分布统计结果不同用户行为如 play、pause、seek、stop 的数量分布基本符合随机生成器设定说明日志生成与 Spark 统计逻辑正确。3.电影播放次数统计结果各电影播放次数存在差异说明日志能够被正确解析并按照 movie_id 进行分组统计。5.用户总观看时长统计结果各用户的观看时长能够正确累计说明 duration 字段在 HDFS 存储和 Spark 读取过程中未出现丢失或格式错误。6.总体来看本实验搭建的数据链路能够完整实现日志生成Flume 实时采集Kafka 消息缓冲HDFS 原始数据落盘Spark SQL 离线分析系统运行结果达到了预期目标。七、实验中遇到的问题与解决方案1. 虚拟机系统盘爆满导致 Ubuntu 无法进入桌面实验初期虚拟机系统盘 / 分区被占满导致 Ubuntu 黑屏、无法正常进入图形界面。通过切换到 TTY 终端、清理系统缓存、删除 Snap 占用以及扩展数据盘挂载目录最终恢复了系统可用状态。2. Hadoop 环境变量配置错误在 Hadoop 初次运行时出现Invalid HADOOP_COMMON_HOME后续通过重新配置 JAVA_HOME、HADOOP_HOME、HADOOP_COMMON_HOME 等变量并确认 Hadoop 安装目录完整成功解决该问题。3. Hadoop 安装目录不完整最初的 Hadoop 目录缺少 share/hadoop/common 等运行时所需内容导致 hdfs version 无法正常执行。通过重新解压完整 Hadoop 安装包后恢复正常。4. Kafka 实际未正确安装开始时虽然存在 /data/kafka/broker1 等目录但实际缺少 Kafka 可执行脚本和配置文件。后续重新将 Kafka 安装到 /data2/software/kafka 目录并完成启动和 Topic 创建。5. Spark 下载包不完整从国外源下载 Spark 时由于网络速度较慢导致压缩包损坏解压时报错。后续改用国内镜像重新下载成功完成 Spark 安装。6. 单机环境下 Kafka 副本数限制由于本实验采用单机伪分布式环境只能启动一个 Broker因此 video_logs 主题副本数设置为 1。尽管与题目理想值 2 存在差异但不影响主链路验证与实验目标实现。八、总结本实验围绕视频网站点击流日志处理场景搭建了一条基于大数据组件的完整处理链路实现了从日志生成、Flume 采集、Kafka 缓冲、HDFS 存储到 Spark SQL 离线分析的全过程。通过本次实验我进一步理解了各大数据组件在实际日志处理系统中的职责与协作关系Flume 适合日志采集Kafka 适合消息缓冲HDFS 适合原始数据持久化存储
本实验在 Ubuntu 24.04 环境下完成采用单机伪分布式方式验证整条数据链路。1. 软件环境操作系统Ubuntu 24.04JDKOpenJDK 8Hadoop3.3.6ZooKeeper已部署并启动Kafka单机模式伪分布式运行Flume1.9.0Spark3.5.1Python3.x2. 硬件环境虚拟机内存8GB系统盘20GB扩展数据盘20GB由于系统盘空间有限实验中将 Hadoop、Kafka、Spark 等大数据软件部署到数据盘目录下。3. 实验目录规划Hadoop/data/hadoopKafka/data2/software/kafkaSpark/data2/software/spark输入日志目录/data/logs/inputHDFS 原始日志目录/course/video_logs/rawHDFS 分析结果目录/course/video_logs/analysis三、系统设计与总体流程本实验系统由五个核心部分组成1. 日志生成模块通过 Python 脚本每 2 秒生成一条 JSON 格式日志并写入 /data/logs/input/access.log。2. Flume 采集模块Flume 监听 /data/logs/input 目录中的日志文件将新增日志发送到 Kafka。3. Kafka 缓冲模块Kafka 作为消息缓冲中间件用于接收 Flume 采集到的日志数据并提供后续消费接口。4. HDFS 存储模块原始日志先写入 HDFS 中的 /course/video_logs/raw 目录作为原始数据存储。5. Spark SQL 分析模块使用 Spark SQL 读取 HDFS 上的原始 JSON 日志对行为类型、电影播放次数、用户总观看时长等指标进行统计并将结果写回 HDFS。四、实验步骤与实现过程4.1 Hadoop/HDFS 环境配置与启动首先完成 Hadoop 环境变量配置包括 JAVA_HOME、HADOOP_HOME、HADOOP_COMMON_HOME 等并在 core-site.xml 与 hdfs-site.xml 中完成 HDFS 基础配置。其中fs.defaultFS 配置为 hdfs://localhost:9000NameNode 数据目录配置为 /data2/hadoop/nameDataNode 数据目录配置为 /data2/hadoop/data完成配置后对 NameNode 执行格式化并通过 start-dfs.sh 启动 HDFS 服务。使用 jps 命令检查进程确认出现NameNodeDataNodeSecondaryNameNode说明 HDFS 启动成功。插入截图Hadoop/HDFS 配置截图4.2 ZooKeeper 与 Kafka 配置实验中先启动 ZooKeeper再启动 Kafka Broker。Kafka 中创建主题 video_logs用于接收 Flume 采集到的日志数据。考虑到本实验在单机伪分布式环境下进行为保证主题创建和功能验证成功最终采用如下设置Topic 名称video_logs分区数3副本数1虽然题目理想要求为副本数 2但由于当前实验为单机环境仅启动了单个 Broker因此副本数设置为 1。若扩展为多 Broker 集群环境可将副本数调整为 2。通过 kafka-topics.sh --describe 查看主题信息确认 video_logs 创建成功。插入截图Kafka topic 创建成功截图4.3 日志模拟生成为了模拟视频网站用户行为日志本实验编写了 Python 日志生成脚本 log_generator.py。该脚本每 2 秒随机生成一条 JSON 日志写入/data/logs/input/access.log生成日志字段包括user_idmovie_idactiontimestampduration示例日志如下{user_id:1001,movie_id:m_302,action:play,timestamp:1780559367284,duration:181}通过 tail -f /data/logs/input/access.log 可以实时观察日志持续写入情况。插入截图access.log 持续生成日志截图4.4 Flume 采集与 Kafka 接入实验中使用 Flume 监听 /data/logs/input 目录下的日志文件。Flume 配置中使用 TAILDIR Source 监控日志文件变化使用 memory Channel 缓冲事件并通过 KafkaSink 将日志发送到 Kafka 的 video_logs 主题。关键配置包括监听目录/data/logs/input/.*\.log$Kafka 地址localhost:9092Kafka Topicvideo_logs启动 Flume 后通过 Kafka 消费者终端实时查看 video_logs 中的数据可以看到日志持续进入 Kafka说明 Flume - Kafka 这段链路已经成功打通。插入截图Flume 启动成功截图插入截图Kafka 消费日志截图-4.5 原始日志写入 HDFS为了完成“数据备份到 HDFS”这一要求实验中将 Kafka 中的原始日志导出为本地 JSON 文件再上传到 HDFS 的原始日志目录/course/video_logs/raw/日期目录/上传完成后通过 hdfs dfs -ls 和 hdfs dfs -cat 验证 HDFS 上确实存在原始日志文件并且内容与 Kafka 消费到的 JSON 日志一致。插入截图HDFS 原始目录截图插入截图HDFS 原始日志内容截图4.6 Spark SQL 离线统计分析在原始日志进入 HDFS 后本实验采用 Spark SQL 读取 HDFS 中的 JSON 数据并完成以下三类离线统计1. 行为分布统计2. 统计 play、pause、seek、stop 等行为出现次数3. 电影播放次数统计4. 统计每个 movie_id 的播放次数5. 用户总观看时长统计6. 统计每个 user_id 的总观看时长核心 SQL 思路如下使用 CREATE OR REPLACE TEMPORARY VIEW 建立临时视图使用 INSERT OVERWRITE DIRECTORY 将统计结果写回 HDFS输出目录包括/course/video_logs/analysis/action_distribution/course/video_logs/analysis/movie_play_count/course/video_logs/analysis/user_duration从实验结果看Spark SQL 成功完成了对日志的离线计算并生成了预期的统计结果。插入截图Spark SQL 统计目录截图插入截图Spark SQL 统计结果截图五、关键代码与配置说明5.1 日志生成脚本核心逻辑日志生成脚本通过 random 随机生成用户、视频、行为、时长等字段并写入 JSON 行到日志文件中。该方式简单直观便于模拟持续产生的点击流数据。5.2 Flume 配置核心逻辑Flume 使用 TAILDIR 监听日志文件变更实时采集新增日志通过 KafkaSink 推送到 Kafka Topic 中。该结构符合“文件日志 - Flume - Kafka”的典型日志采集流程。5.3 Spark SQL 统计逻辑Spark SQL 通过 JSON 数据源直接解析原始日志并利用 SQL 语句完成统计。相对于传统 MapReduceSpark SQL 代码更简洁可读性更强更适合本实验中的离线分析需求。六、实验结果分析根据实验结果可以得到以下分析结论1. 行为分布统计结果不同用户行为如 play、pause、seek、stop 的数量分布基本符合随机生成器设定说明日志生成与 Spark 统计逻辑正确。3.电影播放次数统计结果各电影播放次数存在差异说明日志能够被正确解析并按照 movie_id 进行分组统计。5.用户总观看时长统计结果各用户的观看时长能够正确累计说明 duration 字段在 HDFS 存储和 Spark 读取过程中未出现丢失或格式错误。6.总体来看本实验搭建的数据链路能够完整实现日志生成Flume 实时采集Kafka 消息缓冲HDFS 原始数据落盘Spark SQL 离线分析系统运行结果达到了预期目标。七、实验中遇到的问题与解决方案1. 虚拟机系统盘爆满导致 Ubuntu 无法进入桌面实验初期虚拟机系统盘 / 分区被占满导致 Ubuntu 黑屏、无法正常进入图形界面。通过切换到 TTY 终端、清理系统缓存、删除 Snap 占用以及扩展数据盘挂载目录最终恢复了系统可用状态。2. Hadoop 环境变量配置错误在 Hadoop 初次运行时出现Invalid HADOOP_COMMON_HOME后续通过重新配置 JAVA_HOME、HADOOP_HOME、HADOOP_COMMON_HOME 等变量并确认 Hadoop 安装目录完整成功解决该问题。3. Hadoop 安装目录不完整最初的 Hadoop 目录缺少 share/hadoop/common 等运行时所需内容导致 hdfs version 无法正常执行。通过重新解压完整 Hadoop 安装包后恢复正常。4. Kafka 实际未正确安装开始时虽然存在 /data/kafka/broker1 等目录但实际缺少 Kafka 可执行脚本和配置文件。后续重新将 Kafka 安装到 /data2/software/kafka 目录并完成启动和 Topic 创建。5. Spark 下载包不完整从国外源下载 Spark 时由于网络速度较慢导致压缩包损坏解压时报错。后续改用国内镜像重新下载成功完成 Spark 安装。6. 单机环境下 Kafka 副本数限制由于本实验采用单机伪分布式环境只能启动一个 Broker因此 video_logs 主题副本数设置为 1。尽管与题目理想值 2 存在差异但不影响主链路验证与实验目标实现。八、总结本实验围绕视频网站点击流日志处理场景搭建了一条基于大数据组件的完整处理链路实现了从日志生成、Flume 采集、Kafka 缓冲、HDFS 存储到 Spark SQL 离线分析的全过程。通过本次实验我进一步理解了各大数据组件在实际日志处理系统中的职责与协作关系Flume 适合日志采集Kafka 适合消息缓冲HDFS 适合原始数据持久化存储
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
